SpatiaLite is not the Shapefile of the Future

September 16, 2010 32 Comments

So we’ve got yet another blog touting the future of the SpatiaLite format as being the next Shapefile. Now don’t you dare look over at that search feature on the right side of my blog and type in SpatiaLite because you’ll probably see the same thing (though honestly I can’t recall if I was of sound mind when writing it). The simple fact is SpatiaLite is a favorite format for those of us with nothing better to do than tell the rest of the world what they should be looking at.

GeoMonkey loves the shapefile because it just works.

Ah! But like most things, just because a bunch of bloggers think it is a good idea doesn’t mean it will actually matter. In this case SpatiaLite is dying a slow death because no one is actually implementing it. Now yes OGR, FDO and other libraries support it, but you don’t see that making its way into mainline software (QGIS aside, but even its support is poor) and in turn you rarely see it in the real world. Offhand I can only think of the “beta” format that GeoCommons has on their service (and they’ve had beta attached to it for almost a year).

Now yes, I think we all need a better format than the venerable shapefile (and it’s three amigos) which as a transmission format fails miserably. But there doesn’t seem to be any indication that this is a problem people actually want solved. I’ve seen much more effort put into KML, GeoJSON and LAS by the community than SpatiaLite or even SQLite. This isn’t because the SpatiaLite project hasn’t given tools to us to implement, it has been the community could care less about it. SHP works for them and there isn’t any reason to change.

So what is going to change things? Well it will be web services, not GIS formats that matter for users moving forward. So I say lets stop focusing on SpatiaLite as a consumer format and actually work harder at making better web services for these users (like stop it already with the WxS please). SpatiaLite still has its place in the world, but does anyone really want to bother downloading GIS files anymore? Of course not…

Shapefile can’t #FAIL!

Oh and the FGDB API – just assume it is dead as well.  ESRI can’t get it out the door and in reality, no one give a hoot other than federal agencies that have to provide open data, but are locked into to the ESRI stack.

Filed under GIS Tagged with , , , ,

5 predictions Geo for 2010 and 5 things that won’t happen

December 31, 2009 59 Comments

Here are 5 predictions for Twenty Ten.

  1. The shapefile dies: SpatiaLite + ESRI’s File Geodatabase API finally put a dagger in the shapefile.
  2. GIS on iPhone/iSlate (Apple Tablet) and Android/Chrome OS: With Apple and Google owning the mobile space, we’ll see more proprietary and open source projects being ported to these platforms.  Microsoft Tablet PCs and Windows Mobile/CE begin to die off.
  3. 64-bit: There will be some holdouts (*cough* ESRI), but most of us will be running native 64-bit code on our desktops and servers.  Now to just get more RAM in this laptop.
  4. Mobile: If you aren’t running on the iPhone/Android/Blackberry you aren’t relevant.  Web mapping apps become mobile browser aware.   Those that aren’t were probably irrelevant anyway.
  5. Google: Google’s APIs continue to push the envelope and they continue to be the standard for everyone mapping on the interweb.  Google is able to throw so much money and manpower at “problems” and their solutions are coming faster than anyone else can match.

Here are 5 things that won’t happen:

  1. Augmented Reality: Much like the Nintendo Virtual Boy, it sounds great until you try and use it.
  2. OpenStreetMap Dominates: Between Google’s quick improving of their database and continued licensing issues OSM plateaus.  Companies will continue to try and figure out how to monetize OSM, but fail.
  3. ESRI + Microsoft: This was on the top 10 lists for many people in 2009, but I don’t think we’ll be seeing deeper integration.  ESRI will continue to support multiple platforms (Google, OSM, Microsoft, “other”) and not become a Microsoft shop.  As Google continues to erode away at SharePoint and Bing Maps, ESRI will make sure that they don’t get caught in Microsoft’s blind spot.
  4. Geolocation other than Twitter, Apple and Google (TAG): Foursquare, Brightkite, and others will fade as TAG rolls out new APIs and ensure their mobile devices are tagging everything you do.
  5. MySQL falls apart:  Despite the dire predictions of Oracle or Monty destroying the project, too many people have too much invested in the project to let it fail.  MySQL will be fine and LAMP will continue to power Badgers.

Hey, don’t worry…  It’s gonna be a bright, sun-shiny day!

 

Filed under GIS Tagged with , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

The GIS Interchange File

May 5, 2008 36 Comments

All too often we have to request people resend datasets to each other because they get blocked by email, one important file gets left off or systems just don’t recognize a file type. I’ve run into a problem today where a company FTP site is rejecting a shapefile because it doesn’t recognize the .shp, .shx, .dbf extensions. I thought I could get around by zipping the data, but it appears to scan the zip file for extension types. So the “solution” was to zip the shapefile, change its extension to .doc and tell the recipient that they need to change the extension back to .zip.

This kind of stuff happens way too often. Personal Geodatabases have the problem of the .mdb extension that is rejected outright by most email systems and other formats aren’t readily usable by folks systems. The “old days” were easy because we all used coverages and shared them via the .e00 format that was almost always acceptable by everyone. Amazing how we take such steps back over time and you’d think data sharing would be easier than it was in 1995.

How do you folks share data? KML, GML, Etch A Sketch, e00, zip, web services, etc?

Update: Jason Birch has some ideas about using SQLite as an interchange format. Well worth the read.

Filed under GIS Tagged with , , , ,