The future of the Shapefile format?

Shapefiles will stay with us forever!
35% (120 votes)
ESRI's Geodatabase format will eventually replace it
8% (28 votes)
The GML standard will become widely-used
8% (28 votes)
SpatiaLite will become the choice of many
25% (88 votes)
Web services will replace flat files
11% (38 votes)
I don't know
13% (45 votes)
Total votes: 347

Re: The future of the Shapefile format?

The problem is you have not defined a requirement other than to replace ShapeFile.
ShapeFile can be used for a multitude of things.

You have also allowed only one choice in the list.
I think we will use multiple formats depending on what we are trying to do and whether we are online or not.

So I think we should try to use GML where ever possible. It works in both file transfers using media or when using a WFS web service. Someone made a comment about complexity, multiple application specs and having to download schemas, but this would be the same whatever the exchange mechanism. The beauty is there is a single file to move about (you only need the schemas one time.

When delivering complex datasets, it is likely we will use File Geodatabase when exchanging between ESRI servers.

There are others suggesting KML and NATO has a standard called NVG (NATO Vector Graphics) which is an adaptation of SVG.

Keith

Re: The future of the Shapefile format?

  • Shapefiles are not a good choice as they require 3+ files so they make it difficult to share data via web services. They also have limitations on the size of field names which restricts the use of descriptive names.
  • The ESRI File geodatabase format is a proprietary format which is good for editing on your own machine but due to the directory based structure is not a good choice for exchange via web services. There is an XML export option but it is too verbose so creates very large files.
  • GML is way too complicated and verbose for data exchange. You have to download and parse a complex schema just to get at the data and it allows too many variations in application schemas to be able to create a generic GML reader.
  • Spatial lite again is a good choice for editing of data but databases are not a good choice for data exchange.
  • Web services still require the use of flat files to exchange the data to and from the service. So this is not really a separate option from the above. Web services should be able to consume and output data in many different formats.
  • The list is missing an "Other" option. For example a CSV encoding of the data with a header and other tagged properties before the data table is a remarkably simple and compact way of sending data. Use of WKT for geometries makes even the geometries easily readable. Although WKT is missing some concepts and is slightly too verbose.

So in summary file database type formats (spatiallite and ESRI File Geodatabase) are great for interactive editing of data. Simple ASCII formats such as CSV are a nice compact way of sharing data and with the use of gzip or zip can have transmission file sizes less than that of a binary format. Paul

Re: The future of the Shapefile format?

You are missing to point about interoperability (which is why we all use Shapefiles to transport files) - if a format is closed and proprietary (ESRI * GeoDatabase) or prone to changing with out warning (SpatialLite) then they won't catch on.

We seem to be still waiting for a good solution but GML seems to be the way to go at present: a well defined standard, easy to read/write, compress well, good Web Service support (WFS). But for one thing ESRI doesn't handle it well so I guess we're stuck with shapefiles.

Re: The future of the Shapefile format?

I agree with some of the points shared in this post.

SpatialLite seems to be reliable and it may become a major player. All we need is ESRI to support it. Once that happens (I'm not sure that it does in V.10) it can be largely adopted, because it can store multiple tables, contains schema and geometry and it's only one file.

Shapefile will eventually die, at least I hope so, it has too many constraints and they can easily "break" (imagine a user messing with it in Excel).