For various reasons, I can’t attend today’s inaugural FedGeoDay at the Woolly Mammoth Theatre in Washington, DC, though I’ll be watching the hashtag with great interest. Jack Flood of Arc2Earth, however, has already posted his slides to SlideShare:
While neither ArcMap nor Arc2Earth are open-source themselves, Jack points out that Arc2Earth acts as a bridge between ArcMap and several geospatial hosting platforms that are built on open-source technology but, also just as important, are successful at making data more openly available. These platforms include CartoDB and MapBox, among many others.
Over the past year, I’ve been involved in searching for GIS analysts a number of times. As a result, I’ve noticed a few patterns:
There are a lot of analysts out there looking for jobs. Every time I run an ad, I get at least 100 resumes from people of various levels of experience and education.
The vast majority of those that I call to pre-screen have not done any meaningful coding of any kind. This includes Python, which has been shipping with ArcGIS for several versions now.
Of those that do have some coding experience, many do not show it on their resumes. I find this particularly interesting as I can’t imagine why a person would choose not to list all relevant skills or experience.
I am very publicly on the record that I think some form of coding skill is essential for any GIS analyst entering the workforce today. My reasoning here is fairly straightforward.
What follows is an overview based on some of the notes I took. I wasn’t always writing as I sometimes just stopped to listen and I’ll probably follow up with more details later.
The Open Geospatial Consortium (OGC) has published a draft GeoPackage specification for comment. The GeoPackage specification attempts to create a non-proprietary means for packaging and exchanging all geospatial data in all its forms (vector, raster, and tiles). A couple of things that jump out at me:
It calls out SQLite as the reference implementation of a GeoPackage container
It calls out SpatiaLite 4 as the reference implementation of a vector feature store
It does not call out a reference implementation for rasters or tiles
On the SpatiaLite Google Group this morning, Sandro Furieri announced the availability of a beta preview of SpatiaLite 4.1.0. The primary focus of this preview is to get early comment on new capabilities supporting the storage, validation, and query of XML documents.
The main goals of these recently introduced enhancements are:
– storing XML Documents directly within the DBMS
– supporting XML validation
– supporting plain SQL queries on behalf of XML Documents
via canonical XPath expressions
Implementing directly into the Spatial DBMS a common core of XML-oriented features surely is an interesting and useful option, just considering that ISO- and INSPIRE-Metadata or SLD/SE Styles are fully based on XML.
Although I find myself working more with GeoJSON and CartoCSS these days, I think support for XML is a good step for SpatiaLite. There are some very mature use cases based on XML, as Sandro points out. While SLD is not my favorite, this may keep it on my radar. Also, it would be interesting to see how this new capability would possibly affect the evolution of the OGC GeoPackage draft specification.