Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I'm using ogr2ogr to convert some OSM data for Greenland (not really important for the question), from a PostGIS database to a file containing GeoJSON.

The problem is that the GeoJSON gets written without the crs attribute, even though I'm reprojecting to a non-4326 coordinate system (3189 to be specific). See below how I do this.

The srid of data in geometry column in the database table is 4326. I use the t_srs "epsg:3189" option to transform the coordinates, and this seems to work, i.e. the coordinates are not Lat/Lon.

Command used:

ogr2ogr -f "GeoJSON" greenland_coast.geojson \
  PG:"host=localhost user=xxx dbname=greenland_osm password=xxx" \
  -sql "select linestring from ways" -t_srs "epsg:3189"

Snippet of GeoJSON result:

Notice the missing crs attribute that should indicate that the coordinates are in EPSG:3189.

{
"type": "FeatureCollection",                                                                         
"features": [
  { "type": "Feature", 
    "properties": { }, 
    "geometry": { 
      "type": "LineString", 
       "coordinates": [ 
         [ -548886.066167875193059, 9361706.390365654602647 ], ...]
     }
  },
  ...
]}

The coordinates seem to have been transformed correctly, but there is no crs field telling a reader of the GeoJSON file that the coordinates are in epsg:3189

The GeoJSON spec states:

If no crs member can be so acquired, the default CRS shall apply to the GeoJSON object ... The default CRS is a geographic coordinate reference system, using the WGS84 datum, and with longitude and latitude units of decimal degrees.

I assumed that since I'm reprojecting to a non-geographic coordinate system, a crs key-value pair would be written to the GeoJSON (indicating EPSG:3189 in my case).

My question

Which of the following statements is more true?

  • I'm using ogr2ogr wrong
  • My expectations of ogr2ogr are too high
  • There an error in the GeoJSON driver
share|improve this question
add comment

1 Answer 1

up vote 1 down vote accepted

I had a look at the OGR source, and I think option 2 applies.

#ifdef notdef
    if (poSRS)
    {
        const char* pszAuthority = poSRS->GetAuthorityName(NULL);
        const char* pszAuthorityCode = poSRS->GetAuthorityCode(NULL);
        if (pszAuthority != NULL && pszAuthorityCode != NULL && strcmp(pszAuthority, "EPSG") == 0)
        {
            json_object* poObjCRS = json_object_new_object();
            json_object_object_add(poObjCRS, "type", json_object_new_string("name"));
            json_object* poObjProperties = json_object_new_object();
            json_object_object_add(poObjCRS, "properties", poObjProperties);

            if (strcmp(pszAuthorityCode, "4326") == 0)
            {
                json_object_object_add(poObjProperties, "name", json_object_new_string("urn:ogc:def:crs:OGC:1.3:CRS84"));
            }
            else
            {
                /* FIXME?: the issue is that for geographic SRS, OGR will expose a latitude/longitude axis order */
                /* which is probably not what is written in the file! */
                json_object_object_add(poObjProperties, "name", json_object_new_string(CPLSPrintf("urn:ogc:def:crs:EPSG::%s", pszAuthorityCode)));
            }

            const char* pszCRS = json_object_to_json_string( poObjCRS );
            VSIFPrintfL( fpOut_, "\"crs\": %s,\n", pszCRS );

            json_object_put(poObjCRS);
        }
    }
#endif

That #ifdef notdef was added by this commit but I couldn't say why.

Perhaps you can try rebuilding gdal without the #ifdef and #endif?

share|improve this answer
    
I see. So one approach is to hack the ogr2ogr source. Perhaps writing a script that post-processes the result and adds the crs is faster and at least more portable (although not ideal of course). –  Pimin Konstantin Kefaloukos Jan 13 '13 at 12:09
    
A bug report might also be worth a try? –  BradHards Jan 13 '13 at 20:05
    
I went ahead and filed a bug: trac.osgeo.org/gdal/ticket/4995 –  Nelson Feb 18 '13 at 16:38
    
And my bug ticket was marked fixed, looks like it'll be changed in the 1.10.0 release. Here's the patch: trac.osgeo.org/gdal/changeset/25665 –  Nelson Feb 22 '13 at 18:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.