With the release of ArcGIS 10.2, Esri quietly added support for SQLite as a geodatabase container. This is big news as the community has been looking for such support for some time. An open-source RDBMS originally designed for embedded systems, SQLite has a very small footprint and is arguably the most widely deployed RDBMS in the world. (Thanks, in part, to the fact that it is embedded into Adobe Reader and other commonly used software.) Over the years numerous strategies for storing spatial data in SQLite have been developed, ranging from simply storing WKT or WKB geometries in a column up to full extensions like SpatiaLite, which adds OGC-compliant data types and methods. SQLite is also the engine that drives the popular MBTiles implementation used by TileMill and MapBox.
A while back, I blogged the availability of a GDAL/OGR plug-in for ArcGIS desktop by Ragi Burhum at AmigoCloud. At the time, I was hoping to dig into it fairly quickly but that didn’t happen and I’m finally getting to it. Anyone who has followed this blog for a while knows that I have had more than a passing interest in integrating new data sources with ArcGIS over the years. This comes from the fact that, as a technology geek, I am fascinated by all forms of technology and enjoy the process of integration and, as a consultant providing services to the Federal Government, most of my customers have standardized on Esri tools. Integrations such as GeoRSS, PostGIS, GeoCommons and GeoJSON have directly benefitted my customers for real-world applications so I continue look for ways to remove the barriers between them and the data they seek.
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
- It does not mention exchange of cartography.
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. More information about this update can be found here. Says Sandro: The main … Read more SpatiaLite 4.1.0 Beta Preview Available
On what seems to be turning into SpatiaLite Monday, Sandro Furieri also announced on the SpatiaLite Google Group the availability of a stable version of SpatiaLite for Android. I am happy to see that this version was developed and contributed back by the US Army Geospatial Center. The fact that they contributed back to the … Read more SpatiaLite for Android Available
It looks like it was a busy weekend for Sandro Furieri and the rest of the SpatiaLite team as version 4.0 was announced on Sunday. There are a number of changes, so it’s best to catch up on them before switching over. I have a couple of Federal customers that are integrating SpatiaLite into their … Read more SpatiaLite 4.0 Released
In support of some of our ongoing PIM work, we’ve been integrating the Esri File Geodatabase (FGDB) API into some tools. Without going into a level of detail that would hijack this post, one of the many functions performed by some of the tools is to validate physical spatial databases against established data models to analyze compliance and identify differences. These databases may be in Esri or non-Esri formats and we have traditionally handled Esri geodatabases through ArcObjects since it provides a relatively uniform interface across the various flavors of geodatabase.
Of course, ArcObjects requires an ArcGIS license of some sort and we are finding out that this is not always available to users in the field under many situations so the FGDB API gets past that for file geodatabases, at least.
Things have been kind of quiet on the blog lately due to things being busy at work. I call that a good problem to have. Since the beginning of the year, I’ve written a a lot of proposals for a mixture of potential customers. Interestingly, I’m seeing a lot more call for “GIS Analyst” work. One trend I’ve noticed, at least in the Federal sector, is that the time between proposal due dates and award announcements seems to be lengthening. That may be an indication of the ongoing flux in funding and organizations try to figure out how to fund their requirements. It will be interesting to see how it shakes out. Of course, it’s good that the opportunities are there in the first place.
One the technical side of things, I’ve been involved in a smattering of things that’s made it hard to roll up one good post. I’m pretty heavily involved in the PIM efforts that my colleague, Barry Schimpf, has been blogging about over on the Zekiah blog.
Over on the SpatiaLite Google Group, Stine Consulting announced the availability of 2011 TIGER Boundary files in SpatiaLite format. Despite initial enthusiasm, mainstream uptake of SpatiaLite has been slow but I think that’s about to change. Large organizations, such as the US Army, are showing a much more serious interest in SpatiaLite as they expand … Read more 2011 TIGER Boundary Files in SpatiaLite Format
I wanted to take a opportunity to do something I don’t often do, and draw attention to a series of posts that’s going on over on my company’s blog. About a year ago, my company, Zekiah Technologies joined forces with Upper 90 Systems. Upper 90 was probably best known for their work building tools that supported the Spatial Data Standard for Facilities, Infrastructure, and Environment (SDSFIE), which is a data model that is used by the US DOD to standardize the representation of GIS data for the purpose of performing facilities management on military installations.
SDSFIE (PDF) has existed for some time, with several versions of the standard being rolled out to its diverse user community. Through that process, we’ve learned a thing or two about configuration management of widely-implemented geospatial data models. This understanding has been turned into a series of tools designed to help with the issues surround lifecycle management of a data model (as opposed to physical databases themselves).