Bug report #10044

OSM Polygons not rendering

Added by Joao Paulouro almost 10 years ago. Updated about 8 years ago.

Category:Map Canvas
Affected QGIS version:2.2.0 Regression?:No
Operating System:OSX Easy fix?:No
Pull Request or Patch supplied:No Resolution:not reproducable
Crashes QGIS or corrupts data:No Copied to github as #:18525



I'm having a serious problem with the latest QGIS 2.2 (Mac install from kyngchaos on OSX 10.9). QGIS does not seem to be able to render OSM polygons properly, regardless of their origin.
At first i thought something was wrong with the OSM import, but now I realise that the same features render properly in OpenJump and uDig. I'll try to describe what I've found out so far:

1. Summary:
- QGIS seems to render OSM polygons properly at very low zoom levels, but when zooming in, polygons disappear from the window.
- This happens regardless of the origin of the layer or how it was imported. Depending on how it was importunes ed however, the severity of the problem changes.
- The features affected seem to be just polygon layers. They did not accidentally end up in the line string tables.
- I've tested this with a direct API download as well as using country and city extracts (.osm). The problem surfaces in all situations.
- The polygon features are recognised by QGIS in the attribute table, they can be labeled and the labels render properly - only the polygons fails to render on the canvas.
- I can see no difference in the attribute table between polygons that render properly and those that do not. Geometries seem to be fine (only two errors for the entire file, self-intersecting 8-type polygons).
- The location in question is Lisbon.

2. Osmosis, core plugin, imposm, and osm polygon:
- When bringing in a Postgis layer of OSM features from Osmosis, QGIS displays everything correctly (but osmosis only produces line strings).
- When importing using the core plugin through spatialite, a large number of features (building polygons mostly) fail to render.
- When importing a Postgis layer from an imposm import, I get better results but still several polygon features fail to render.
- When importing the multi polygons layer directly through add vector layer on the .osm file, several polygons are missing. QGIS hanged while trying to import the rest of the layers.

3. Osm2pgsql:
- When importing a Postgis layer from an osm2pgsql import (with hstore and -multi-geometry options (but switching these off makes no difference) the result is similar to using the core plugin.
Looking at the layer through QGIS' DB Manager, it tells me that the polygon table is missing a primary key (from my understanding, osm2pgsql uses non-unique keys to compensate for multi-geometries). If I add an extra column with unique primary keys and re-import, I get the best results. The vast majority of polygons render properly. But a a few still fail to render.
- DB Manager also tells me that the table has no "entry in geometry_columns". Not sure what to do about that.

- I can confirm that all features get imported and are recognised by QGIS by looking at the attributes table. I also decided to give all polygons a label of their id. The id labels render properly for all polygons, including those that are not displayed.

I am at a loss as to what is going on. Could someone check if QGIS is rendering OSM polygons properly by comparing their files with the OSM website to see if it is platform specific or version specific (or I'm doing something terribly wrong).

Thanks for any help.



#1 Updated by Joao Paulouro almost 10 years ago


Found a fix for this problem. Leaving the info here for others who might come across it.
This seems to be related to Bug #9863 (Open) and possibly Bug #9266 (Closed).

Whilst adding a primary key seems to help quite a lot, it is not necessary.
The fix to get an osm2pgsql postgis table (and I now assume imposm as well) to display properly, has to do with the SRID. Regina's fix for Bug #9863 also takes care of the problem above.

Doing the following query on psql takes care of the problem :

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

Not sure I understand why, as SetSRID only changes the metadata and doesn't touch the geometry. But all is well after that query.

That said, after an osm2pgsql import, I would recommend, for each relevant table:

CREATE UNIQUE INDEX planet_osm_point_gid_idx ON planet_osm_point (gid);

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

Having said that, something seems to be not working properly in QGIS. There was no need for this in uDig or OpenJump, and there is still the problem with the QGIS OSM core plugin, which is probably related to this.

Hope this helps someone,

#2 Updated by Giovanni Manghi almost 10 years ago

  • Status changed from Open to Feedback

Olá João, does this issue affects also previous qgis versions?

#3 Updated by Joao Paulouro almost 10 years ago

Sorry, I wouldn't know. Only have 2.2 installed here, and Kyngesburye's package installer doesn't seem to let you have more than one version installed at a time (that's why I was asking for some feedback from others with other versions and platforms). The nightly dev crashes when connecting to Postgis so can't see what's going on there.
Its an issue that is easy to overlook, since it only affects the rendering of some polygon features and not all. But it is serious, since that might make people do updates on OSM that are not required, or bad analysis thinking everything is fine.
I noticed that when importing without updating the SRID, QGIS automatically zooms out much further than needed on the layer and doesn't center it properly. After updating, it will zoom into the extents properly upon import. This is the easiest way to confirm something is wrong.

#4 Updated by Joao Paulouro almost 10 years ago

An update on this issue.

The fix above, while it seems to work at first, has a major problem. If the ANALYZE statement is used on the postgresql table, the problem reappears. As this statement is normally used in conjunction with VACUUM for maintenance in postgis databases, people might not be aware that this is happening. After reading the postgres docs I don't understand why analysing a table should produce this behaviour.
However, I've since been updating the planet_osm tables with the following postgis query:

SELECT UpdateGeometrySRID('planet_osm_polygon','way',3857);

This is also not a transform, but (quoting the postgis manual), "Updates the SRID of all features in a geometry column, updating constraints and reference in geometry_columns".
Following common maintenance statements, the problem does not re-occur as it did with ST_SetSRID. Thought someone might find this useful (also for bug #9863).

(Giovanni, I haven't tried installing earlier versions of QGIS, but I've just moved to a homebrew install of QGIS 2.2, and the issue persists. So at least it should not be related to the kyngchaos build and dependencies).)

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

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

#6 Updated by Giovanni Manghi about 8 years ago

this a very detailed report, but very difficult also to try replicate.

Could you test is using a recent release makes any difference?

If not could you provide the exact steps to replicate?

I import myself osm data into postgis (see https://mygisnotes.wordpress.com/2015/10/09/openstreepmap-import-data-into-a-postgis-database-and-incrementally-update-it/ ) and can't see this issue.

#7 Updated by Giovanni Manghi about 8 years ago

  • Resolution set to not reproducable
  • Status changed from Feedback to Closed

closing for lack of feedback, please reopen if necessary.

Also available in: Atom PDF