QGIS » QGIS Application

Ok,

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);

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

ALTER TABLE planet_osm_point ADD gid SERIAL UNIQUE PRIMARY KEY;
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,
Joao

Olá,
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.

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).)

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.