Bug report #9350

reprojected postgresql layers are plotted with offset and very slow

Added by Thomas Baumann over 6 years ago. Updated over 6 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Data Provider/PostGIS
Affected QGIS version:2.0.1 Regression?:No
Operating System:Linux Easy fix?:No
Pull Request or Patch supplied:No Resolution:invalid
Crashes QGIS or corrupts data:No Copied to github as #:17952

Description

Running QGIS master as of 2014-01-15, Postgis 2.1.1, osm2pgsql 0.85.0_20140107

Attached is a screenshot which displays the result of plotting the streets from OSM (stored in a postgis database EPSG:900913) onto a shapefile (EPSG:31468)
with essentially the same information.

Transformation was done with EPSG:1777 as applicable to Bavaria.

Please note that all streets are shifted to the south-west while the street names are ok.

Also postgis layers in EPSG:31468, thus requiring no reprojection plot ok.

The second plot shows the same file with QGIS master from 2013-11-04 which was the last stable version with respect to postgis interaction.

Still all postgis action seem to take for ages compared to the version from 20131104.

Thanks for your help
Thomas

Screenshot-qgis-master-20140115.png (775 KB) Thomas Baumann, 2014-01-15 11:42 AM

Screenshot-qgis-master-20131104.png (766 KB) Thomas Baumann, 2014-01-15 11:42 AM

ctrn-koordinatenproblem1.jpg (77.1 KB) Kay F. Jahnke, 2014-02-05 11:09 PM

lizmap.png (485 KB) leolami -, 2014-02-21 01:42 AM

teste.png (826 KB) Giovanni Manghi, 2014-02-23 03:53 AM

History

#1 Updated by Kay F. Jahnke over 6 years ago

I also have a problem with the on-the-fly reprojection, using QGIS 2.0.1 on a Kubuntu 12.04 system. Find attached a screenshot of a QGIS session with the same shapefile data loaded twice. One layer (red stars) is in the same coordinate system as the project (EPSG:32632 - WGS 84 / UTM zone 32N), the other one (green dots) is in EPSG:3003, created from the original shapefile by running ogr2ogr on it with a coordinate system transform:

ogr2ogr -a_srs EPSG:3003 -t_srs EPSG:3003 CTRN_s051080p_point_3003.shp CTRN_s051080p_point.shp

There is a systematic error; the on-the-fly reprojection should place the red stars and green dots at the same location.

#2 Updated by Kay F. Jahnke over 6 years ago

I found the error: The definition of one of my CRSs was incomplete. The Proj4 string QGIS provided for EPSG:3003 was

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs

when I browsed in postgis...

select proj4text from spatial_ref_sys where auth_srid = 3003 ;

... I found another definition for EPSG:3003:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs

using a custom CRS with this specification instead of the QGIS-provided spec for EPSG:3003 solved my problem. What was missing was the towgs part in the definition.

#3 Updated by Giovanni Manghi over 6 years ago

  • Status changed from Open to Closed
  • Resolution set to invalid

without those parameters is normal that you get a shift.

#4 Updated by Thomas Baumann over 6 years ago

  • Status changed from Closed to Reopened

Thank you for the feedback and sorry to reopen this bug.

It might well be that there are some parameters missing for the on-the-fly reprojection. However, this does not explain why

a) a file will work correctly if used with qgis-master as of November 2013 and not with current versions, which is a real show stopper.

b) the street names are plotted correctly and the streets are not.

Maybe this is not related to postgis at all, but it seems that someone should look into the way those parameters are handled. As Kay said, he had to add the missing parameters manually, because they were missing in the proj4 string provided by QGIS.

Thanks again.

#5 Updated by Jürgen Fischer over 6 years ago

Kay F. Jahnke wrote:

I found the error: The definition of one of my CRSs was incomplete. The Proj4 string QGIS provided for EPSG:3003 was

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs

I suppose this comes from you GDAL install. The current resources/srs.db in master has

sqlite> select parameters from tbl_srs where auth_id='3003';
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs

But the srs.db get synced with GDAL by running crssync on package install. So I suppose you're output comes from an older GDAL version.
GDAL 1.10 for instance also has:

gdalsrsinfo epsg:3003

PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs '
...

Which version of GDAL are you running?

#6 Updated by Jürgen Fischer over 6 years ago

  • Status changed from Reopened to Feedback

#7 Updated by leolami - over 6 years ago

  • File lizmap.png added
  • OS version changed from openSUSE 13.1 to openSUSE 13.1, Ubuntu 12.04 LTS
  • Affected QGIS version changed from master to 2.0.1

Hi all,

I have the same problem with the same srs (3003).
In my QGis project I set a on-the-fly reprojection to 3857 and all is ok
In Lizampa webgis my 3003 layers are offset than OSM of 100 mt about.

I'm using:
Ubuntu Server 12.04 LTS
Lizmap 2.9.0
qgis-mapserver: 2.0.1-2+precise1
gdal-bin: 1.10.0-1~precise1
proj4: 4.8.0-3~precise5

gdalsrsinfo epsg:3003
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs '

There is also a strange thing:
By Lizmap plugin I have setted a search on my 3003 street layer, with geometry visualization option.

The highlight result geometry is correctly positioned on OSM, like you can see on the attacched picture....
The red arrow shows the offset from my 3003 layer and OSM, the green arrow show the search result of the same street.

Thank of all
Leonardo

#8 Updated by Giovanni Manghi over 6 years ago

  • Status changed from Feedback to Closed

Which version of GDAL are you running?

at the time the ticket was filed qgis master in the nightly repo was buiding against gdal 1.7, probably the source of this issue.

closing for lack of feedback.

#9 Updated by Giovanni Manghi over 6 years ago

leolami - wrote:

Hi all,

I have the same problem with the same srs (3003).
In my QGis project I set a on-the-fly reprojection to 3857 and all is ok
In Lizampa webgis my 3003 layers are offset than OSM of 100 mt about.

I'm using:
Ubuntu Server 12.04 LTS
Lizmap 2.9.0
qgis-mapserver: 2.0.1-2+precise1
gdal-bin: 1.10.0-1~precise1
proj4: 4.8.0-3~precise5

gdalsrsinfo epsg:3003
PROJ.4 : '+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs '

There is also a strange thing:
By Lizmap plugin I have setted a search on my 3003 street layer, with geometry visualization option.

The highlight result geometry is correctly positioned on OSM, like you can see on the attacched picture....
The red arrow shows the offset from my 3003 layer and OSM, the green arrow show the search result of the same street.

seems ok here, same OS, same version, latest LizMap, OSM data downloaded and saves into PostGIS with 3003 CRS

#10 Updated by Thomas Baumann over 6 years ago

Ok with QGIS 2.2 and gdal was never below 1.8, currently 1.10.
Also speed of postgis operations is back to normal with the released version 2.2. Any kind of debug code in qgis-master?

Thanks.

Also available in: Atom PDF