This is a static archive of our old OpenStreetMap Help Site. Please post any new questions and answers at community.osm.org.

Ogr2Osm: Imported data shifted by 176m, 222°(exported from ArcGIS)

1
1

We were given city administrative boundary data as .shp files with the permission to import those to OSM / use on AddisMap.com.

I have used the Ogr2Osm scripts to convert this data to the OSM format. I tried all three versions (old SVN, UVM rewrite, pnorman's updated version) which are linked in the Wiki.

All of them produce the same results, but when I load the data in JOSM and compare them with the existing city data (Addis Ababa, Ethiopia), the imported data seems to be shifted by 176m, 222° (I measured this by drawing a way from the point where it should be to the imported point in JOSM)

When using Ogr2Osm it produces the following output:

Detected projection metadata:
PROJCS["Adindan_UTM_Zone_37N",
    GEOGCS["GCS_Adindan",
        DATUM["Adindan",
            SPHEROID["Clarke_1880_RGS",6378249.145,293.465]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",39.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]]

The .prj file we received has the following content:

PROJCS["Adindan_UTM_Zone_37N",GEOGCS["GCS_Adindan",DATUM["D_Adindan",SPHEROID["Clarke_1880_RGS",6378249.145,293.465]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",39.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

The data was exported from ArcGIS.

What can be the source for the error? How can it be fixed?

EDIT: Same problem when I use ogr2ogr and shp2osm

ogr2ogr -t_srs WGS84 -s_srs "ESRI::subcities.prj" "subcities_converted.shp" "subcities.shp" 
perl shp2osm.pl subcities_converted.shp > subcities.osm

Semi cross-posted to Stackexchange GIS

asked 03 Dec '12, 13:00

AddisMap_Alexander's gravatar image

AddisMap_Ale...
1.1k●31●40●62
accept rate: 0%

edited 07 Apr '15, 09:54

One Answer:

4

As found out on GIS.stackexchange I need to specify the projection string manually, because the ogr library does not detect it properly / does not do the datum conversion:

python ogr2osm.py -p "+proj=utm +zone=37 +ellps=clrk80 +towgs84=-166,-15,204,0,0,0,0 +units=m +no_defs" inputfile.osm

answered 04 Dec '12, 14:26

AddisMap_Alexander's gravatar image

AddisMap_Ale...
1.1k●31●40●62
accept rate: 0%

I think we used to have a similar problem with EPSG:27700.

(14 Aug '13, 18:52) SK53 ♦

@SK53: did you solve it the same way? Or another?

(18 Aug '13, 18:28) AddisMap_Ale...

yes I added the explicit Helmert factors (the 7 towgs84 parameters), Chris Hill blogged about it at the time (http://chris-osm.blogspot.co.uk/2010/04/getting-boundaries-right.html), but IIRC there were still bugs in proj4 (and therefore ogr2ogr, PostGIS) relating to WGS84 and OSGB transformations in 2011.

A useful test if you have postgis, but I expect can be done with ogr2ogr is to use a well-defined point and perform transforms between various projections to test accuracy (particularly if there is a non-porj4 transformation available for comparison, as was the case for OSGB).

(18 Aug '13, 19:36) SK53 ♦

Source code available on GitHub .