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

share|improve this question

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
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 '12 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). –  Andre Joost Dec 4 '12 at 16:01

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.

share|improve this answer
    
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 '12 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 '12 at 18:19

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.