Bug report #9863
sometimes data in 900913 crs is not shown
| 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
History
#1
Updated by Jürgen Fischer over 10 years ago
- Status changed from Open to Feedback
which errors do you get?
#2
Updated by Jürgen Fischer over 10 years ago
- Target version changed from Version 2.2 to Future Release - Lower Priority
#3
Updated by Jürgen Fischer over 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 over 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 over 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 over 10 years ago
- File osm_sample.zip added
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 over 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.