[gdal-dev] Internal Metadata Management

Howard Butler hobu.inc at gmail.com
Wed Dec 15 10:47:33 EST 2010


On Dec 15, 2010, at 9:30 AM, Ari Jolma wrote:

> On 12/15/2010 05:11 PM, Frank Broniewski wrote:
>> 
>> Hello Ari,
>> 
>> yes that is definitely helpful. But I still wonder if it might be easier/quicker to use GeoJSON as a interchange format and tranform from geojson to other formats than using OGRs internal structure. I already have some convenience classes for creating GeoJSON structures in Python. I know there is already a geojson python module [1], but onfortunately it doesn't deal with projections afaik.
> 
> GDAL has support for GeoJSON too. And it seems to support projections.

GeoJSON explicitly supports projections, and OGR's implementation tries its best to deal with them.  GeoJSON's original intent is as a slightly-more-up-to-date, Javascript-consumable interchange format.  A better WKT, if you will.  With a light concept of features and feature collections.  It's a great way to interchange geometries and (sometimes) features between softwares of the Python world, the Javascript world, and the PostGIS world.

There are some gotchas with GeoJSON as far as features are concerned though.  A GeoJSON feature object is essentially free-standing, and an array of them need not have a common schema to describe the layout of all of the features in that array.  In practice, the features of an array typically have a common schema, but this requirement is not enforced in any way.  This property of GeoJSON can cause some leakage in that respect.

ESRI's JSON output is not GeoJSON, and AFAIK there is no interchange capability there.

Howard


More information about the gdal-dev mailing list