Opened 7 years ago

Closed 6 years ago

#4525 closed defect (fixed)

Polygons not rendering after removing them from relation

Reported by: andrzej_aa Owned by: jburgess777@…
Priority: major Milestone:
Component: osm2pgsql Version:
Keywords: relations, polygons Cc:

Description

Hi, I have some problems here. Some time ago I had a big relation of polygons and multipolygons. I've splited it up by removing all forests from relation and then I've removed that relation too. Now some of these polygons can't show on the map. At my example you can see one polygon visible. I edited it by moving one of its nodes by few millimeters and submited tile for rendering. I use latest version of JOSM. I put it as osm2pgsql in response to this question.

Attachments (1)

Bug4525.patch (3.7 KB) - added by amm 7 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 Changed 7 years ago by amm

If a way is part of a multi polygon relation, it gets processed via the relation and not as an individual way.

However, if a way is removed from a relation, osm2pgsql does not reprocess the way to see if it needs to be added back to the db as an individual way, and thus those ways do not show up in the rendering tables.

When modifying / deleting a relation, osm2pgsql has to do something like mark the ways in the relation as pending. But I am not yet sure if that is valid for those ways that remain in the relation. I am also not sure if it is valid if a way is a member of multiple relations and only gets removed from one of them.

A fix might also slow down diff processing depending on how it is fixed.

Changed 7 years ago by amm

Attachment: Bug4525.patch added

comment:2 Changed 7 years ago by amm

I think this bug can be solved by adding a "PREPARE rel_delete_mark(" POSTGRES_OSMID_TYPE ") AS UPDATE %p_ways SET pending = true WHERE id IN (SELECT unnest(parts[way_off+1:rel_off]) FROM %p_rels WHERE id = $1) AND NOT pending;" into the rels_delete() in middle-pgsql.

I.e. it would mark all ways as pending (for reprocessing) that are part of a relation that is modified. So if the relation gets deleted or changed from a multi-polygon, it will process the ways again to see if now that they aren't in the relation anymore they need to be added to the rendering tables by them selves.

I am not sure what this does to processing speed of diffs though, or if there is a more efficient way of doing this.

comment:3 Changed 6 years ago by amm

Resolution: fixed
Status: newclosed

Closing this, as I have just committed a fix for this.

Note: See TracTickets for help on using tickets.