Bug report #9863

sometimes data in 900913 crs is not shown

Added by Regina Obe about 10 years ago. Updated almost 10 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Projection Support
Affected QGIS version:2.2.0 Regression?:No
Operating System:Windows 7 Easy fix?:No
Pull Request or Patch supplied:No Resolution:worksforme
Crashes QGIS or corrupts data:No Copied to github as #:18391

Description

I'm not sure if this is a similar issue to #9266 (which should be fixed), but after loading OSM data In PostGIS 2.1.1 with osm2pgsql on Windows. If I select for example the planet_osm_polygon layer (which is in srid: 900913), it prompts for SRID and regardless what I pick (EPSG:3785) or if I cancel, most of the time it does not draw the layer and doesn't give an error though somtimes it does (very odd).

However if I change my table way column with:

 ALTER TABLE planet_osm_polygon ALTER COLUMN way TYPE geometry(Geometry, 3785) USING ST_SetSRID(way,3785);

It no longer prompts and works fine.

This is running QGIS version 2.2.0-Valmiera 64-bit, PROJ.4 Version 480 on Windows

osm_sample.zip (13.6 KB) Regina Obe, 2014-06-29 12:06 PM

History

#1 Updated by Jürgen Fischer almost 10 years ago

  • Status changed from Open to Feedback

which errors do you get?

#2 Updated by Jürgen Fischer almost 10 years ago

  • Target version changed from Version 2.2 to Future Release - Lower Priority

#3 Updated by Jürgen Fischer almost 10 years ago

  • Category set to Projection Support
  • Subject changed from QGIS 2.2 sometimes doesn't show 900913 data to sometimes data in 900913 crs is not shown

#4 Updated by Regina Obe almost 10 years ago

Haven't had a chance to test this again. I have to refind the data I was working with. It didn't give an error just didn't show anything. I'll check the logs next time to see what it shows.

#5 Updated by Giovanni Manghi almost 10 years ago

  • Status changed from Feedback to Closed
  • Resolution set to worksforme

Regina Obe wrote:

Haven't had a chance to test this again. I have to refind the data I was working with. It didn't give an error just didn't show anything. I'll check the logs next time to see what it shows.

then maybe we can close this ticket as we can't replicate the issue, and eventually reopen it again should it show again.

#6 Updated by Regina Obe almost 10 years ago

Keep this closed for now. Might be a PostGIS issue (testing with PostGIS 2.1.2 on windows with QGIS 2.4 OSGEO4W)

I finally found the dataset in question and tested in QGIS 2.4. QGIS 2.4 doesn't seem to have quite same issue and doesn't prompt so its better but the extent it uses is way off and all I see is a tiny speckle. Might be a postgis bug and not a QGIS bug.
I see a tiny speckle on the screen when I load this and can zoom in to the speckle to see all the data.

I suspect maybe QGIS is relying on the ST_EstimatedExtent value, which seems to be way off for this dataset and maybe it didn't in previous versions I used of QGIS. If I load the polygon layer first it works fine (presumably because no estimates for polygon so QGIS is using the true extent).

Attached is the sql for the linestring set in question and related polygon set.

For reference:
SELECT ST_Extent(way) from planet_osm_line;

BOX

--note how this is way different from real extent --
SELECT ST_EstimatedExtent('planet_osm_line', 'way');
BOX

SELECT ST_Extent(way) from planet_osm_polygon;
BOX

SELECT ST_EstimatedExtent('planet_osm_polygon', 'way');
ERROR: stats for "planet_osm_polygon.way" do not exist

#7 Updated by Regina Obe almost 10 years ago

Nevermind if it was a PostGIS bug, its fixed. I did a vacuum analyze on the table and now it displays fine. Sorry for the noise.

Also available in: Atom PDF