2

I am trying to import to my Postgresql (9.1+129ubuntu1) + PostGIS (1.5.3-2) database a Shapefile with polygons with the ogr2ogr tool from Gdal-Bin package (1.7.3-6ubuntu3).

I know the origin SRS of the Shapefile (EPSG:23031), and I know the destination SRS used in the database so I can represent all the diferent objects together (EPSG:25831), so I use this command:

ogr2ogr -f "PostgreSQL" "PG:dbname=DBNAME host=127.0.0.1 user=DBUSER password=DBPASS" "/PATH_TO_SHAPEFILES/SHAPEFILE.shp" -s_srs EPSG:23031 -t_srs EPSG:25831 -lco PRECISION=NO -lco GEOM_TYPE=geometry -lco GEOMETRY_NAME=the_geom -lco EXTRACT_SCHEMA_FROM_LAYER_NAME=NO -nlt GEOMETRY -nln DBTABLENAME

And of course in the path "/PATH_TO_SHAPEFILES/" I have the files SHAPEFILE.shp, SHAPEFILE.shx, SHAPEFILE.dbf and SHAPEFILE.prj

But after the import, I try to represent that polygons and they seem moved to de East, so I guess is a projection transform problem or definition.

Here is an snapshot of the representation in the map by OpenLayers. The correct situation of the polygons should be the grey lines, and the imported polygons are the blue polygons with black lines:

enter image description here

EDIT: As @tilt recommended me I tried to do the same process but converting from shapefile to shapefile, with this command:

ogr2ogr -f "ESRI Shapefile" pruebashp2shp.shp "/PATH_TO_SHAPEFILES/SHAPEFILE.shp" -s_srs EPSG:23031 -t_srs EPSG:25831

I opened the result by QuantumGIS together with the original layer, and it is also moved to the East, as the following image shows:

enter image description here

Improve this question
13
  • Can you try to convert from shapefile to shapefile first and see how that result looks? In that way you can see wether the problem is in gdal or postgis (it might be in both, if the EPSG parameters are wrong)
    – tilt
    Commented Feb 2, 2016 at 11:37
  • Thank you @tilt, I tried it and the result shapefile is also moved to the East in the same way, I opened it with QGIS to compare it with the origin layer.
    – Aleix
    Commented Feb 2, 2016 at 11:51
  • Maybe it's only a display problem with on the fly transformation in QGis? To check this you could compare your transformed data to a native EPSG:25831 layer (from the cadastral services maybe).
    – til_b
    Commented Feb 2, 2016 at 12:20
  • 1
    I start to think about upgrading my Gdal-Bin package version cause I know it is quite old and that could be some bug that have been solved in later versions..
    – Aleix
    Commented Feb 2, 2016 at 12:32
  • 1
    Proj4 string in fresh GDAL seems to be # ED50 / UTM zone 31N <23031> +proj=utm +zone=31 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m +no_defs <> It is not uncommon at all that some program versions have different values for +towgs84 or nothing at all. Newer versions tend to have less bugs but if the data are old they may have been created with buggy parameters and you should use the same buggy parameters for reading.
    – user30184
    Commented Feb 5, 2016 at 13:59

1 Answer 1

Reset to default
3

I'd check the following:

  1. first of all, I'd like to be sure that source data are OK, by comparing them with official/cadastral data

  2. I'd try to use the qgis openlayers plugin to check if the transformation to 3857/900913 works properly for both 23031 and 25831

  3. Try to reproject using QGIS, just saving the shapefile with the target srid.

  4. If using QGIS works properly and using ogr does not, you probably have different projection definitions. Proj definitions are stored in a file called "epsg". Search for it and check the projection definitions, comparing them with the QGIS definitions and with spatialreference.org or epsg.io

Consider that qgis, ogr and postgis are using proj4 for repojections, so they should give you the same results (using the same proj definitions).

Also consider that I repojected data from 23032 to 25832 succesfully in the past, without specifying correction parameters, so it should be the same for your projections...

Improve this answer
4
  • Ok Francesco: 1) I checked it and data source are OK. 2-3) On my windows computer QGIS reprojection works OK! So as you said in the 4) it has to be some problem with the projection definitions in my ubuntu server. I checked the 23031 definition: "<23031> +proj=utm +zone=31 +ellps=intl +units=m +no_defs <>", and it seems that there is missing the parameter "+towgs84=-87,-98,-121,0,0,0,0" as @user30184 has said in another comment. How would you recommend to fix it? Editing the "epsg" file with that parameter?
    – Aleix
    Commented Feb 9, 2016 at 17:09
  • I checked in the spatialreference web site and there is also the wrong projection definition (spatialreference.org/ref/epsg/ed50-utm-zone-31n/proj4). Is there some better oficial place where to reference for up to date information about the projections definitions? Thanks
    – Aleix
    Commented Feb 9, 2016 at 17:13
  • Yes, I'd edit the epsg file. If you don't want to override the native definition, you could add a new srid, with a different code.
    – fradal83
    Commented Feb 9, 2016 at 17:42
  • You can download the EPSG dataset from here epsg.org , but maybe you can also have a look at local gov geoportals..
    – fradal83
    Commented Feb 9, 2016 at 17:44

Your Answer

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

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