3

I try to convert .shp files to OSM data with shp2osm and ogr2osm but the output data is shifted.

Semi-Cross-Posting Warning: I have already asked a questions on the OSM help site, but this questions is more theoretical.

The .prj file I have contains the following (line-breaks added for readability) and the source data was saved using ArcGIS:

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]]

I am using ogr2ogr for the coordinate transformation:

ogr2ogr -t_srs WGS84 -s_srs "ESRI::subcities.prj" "subcities_converted.shp" "subcities.shp"

When I finally import the data in the OpenStreetMap editor, the data is shifted by around 176m, 222°.

Does this mean the source data and the .prj file is plain wrong? Or I am doing something wrong on the way?

Improve this question

2 Answers 2

Reset to default
2

Adindan UTM 37N is EPSG:20137. Latest build of Quantum Gis has this code incorporated. Alternatively you can use the following proj string:

+proj=utm +zone=37 +ellps=clrk80 +towgs84=-166,-15,204,0,0,0,0 +units=m +no_defs

Full command:

ogr2ogr -t_srs WGS84 \
-s_srs "+proj=utm +zone=37 +ellps=clrk80 +towgs84=-166,-15,204,0,0,0,0 +units=m +no_defs"\
"subcities_converted.shp" "subcities.shp"

Note that the towgs84 parameters are not null.

The prj file only contains the datum information "Adindan", and leaves it to the software to determin the towgs84 parameter. This can go wrong.

Improve this answer
2
  • Thanks a lot - with the proj string it works fine. With -s_srs "EPSG:20137" it did not. (I am using ogr2ogr from the Ubuntu package gdal-bin, Version 1.7.3-6ubuntu3)
    – Alex
    Dec 4, 2012 at 14:14
  • OK, thats rather old. Current stable is 1.9.2, and 1.10.0 will be out by the end of the year (hopefully).
    – AndreJ
    Dec 4, 2012 at 16:01
2

Adindan != WGS84. The offsets you're seeing look like a datum mismatch. I don't remember if ogr2ogr will automaticlaly apply a datum transformation or not. There's some information here: OGR transformation tutorial. It's possible that if a transformation is automatically being applied, it's not the correct one for the data. Based on the tutorial, you may need to add a TOWGS84 to the input data's prj file. Possibly check the EPSG Geodetic Parameter Dataset for possibilities. If the transformation you want to implement is a "seven parameter", OGR/GDAL/PROJ4 uses the position vector convention for the rotations.

Improve this answer
2
  • I do not understand a word - I am such a GIS noob :-) But I see that DATUM and PROJECTION are some different things and in my case they differ both. Would it be enough to have add TOWGS84[0,0,0,0,0,0,0] ? Or must there be some parameters to translate Adindan to WGS84? I think so?
    – Alex
    Dec 3, 2012 at 17:56
  • 1
    You will need some parameters to translate to WGS84. The Adindan datum assumes a different shape of the Earth than the WGS84 datum, so you need to tell your program how to get from one to the other with as little distortion as possible. What you're looking for is the seven parameters to get from the Clarke 1880 ellipsoid to the WGS84 ellipsoid.
    – Mintx
    Dec 3, 2012 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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