Ticket #3183 (closed defect: wontfix)

Opened 4 years ago

Last modified 8 months ago

Multipolygon sharing boundary with shore renders incorrectly

Reported by: Wim L Owned by: osm@…
Priority: major Milestone:
Component: osmarender Version:
Keywords: multipolygon Cc: simone.saviolo@…, monxton

Description

Actually I'm not sure that the shore is the problem. But anyway, there is a park here which is bounded on one side by the lake shore:

http://www.openstreetmap.org/browse/relation/907023

http://www.openstreetmap.org/?lat=47.62702&lon=-122.33772&zoom=17&layers=O&relation=907023

Notice how Osmarender draws a straight line for the north boundary of the park rather than following the lakeshore.

Attachments

Screen shot 2010-08-22 at 2.31.33 PM.2.png Download (34.0 KB) - added by Wim L 4 years ago.
osmarender rendering
Screen shot 2010-08-22 at 2.31.46 PM.2.png Download (26.8 KB) - added by Wim L 4 years ago.
mapnik rendering
lakeshore.osm Download (16.0 KB) - added by osm@… 4 years ago.
Simple testcase reproducing the problem

Change History

Changed 4 years ago by Wim L

osmarender rendering

Changed 4 years ago by Wim L

mapnik rendering

comment:1 Changed 4 years ago by Wim L

  • Keywords multipolygon added
  • Owner changed from tom@… to osm@…
  • Component changed from admin to osmarender

Changed 4 years ago by osm@…

Simple testcase reproducing the problem

comment:2 Changed 3 years ago by simone.saviolo@…

  • Cc simone.saviolo@… added

Another example of the bug happening:

 http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=tah&lon=8.42239&lat=45.32467&zoom=17

The pedestrian area is drawn as a multipolygon, and there is no coastline involved.

comment:4 follow-up: ↓ 5 Changed 3 years ago by tms13

The common feature appears to be that ways that are tagged natural=coastline or part of another (correctly rendered) multipolygon get dropped, and replaced with a straight line to close the area. Does the multipolygon code somehow eat its arguments?

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 3 years ago by simone.saviolo@…

Replying to tms13:

The common feature appears to be that ways that are tagged natural=coastline or part of another (correctly rendered) multipolygon get dropped, and replaced with a straight line to close the area. Does the multipolygon code somehow eat its arguments?

That is not the only problem. If you look at my example

 http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=tah&lon=8.42239&lat=45.32467&zoom=17

in the west-most part of the multipolygon you'll notice huge interpretation errors, even though the ways are not shared with any other multipolygon, or any other relation at that.

In my specific case, this may be due to the fact that certain members (the ways that run across the road, perpendicular to the blocks) have not been given any role, while all the others are tagged as "outer". Mapnik, though, handles this correctly, and the multipolygon has no inner member anyway.

I suggest the priority of this bug be elevated. Multipolygons are a long-accepted official feature of OSM, and the fact that Osmarender itself doesn't handle them correctly seems to me more than a "major" bug.

comment:6 in reply to: ↑ 5 Changed 3 years ago by tms13

Replying to simone.saviolo@…:

That is not the only problem. If you look at my  example, in the west-most part of the multipolygon you'll notice huge interpretation errors, even though the ways are not shared with any other multipolygon, or any other relation at that.

Some of the other ways in the relation are shared - for example 82142270 - so it might be relevant.

In my specific case, this may be due to the fact that certain members (the ways that run across the road, perpendicular to the blocks) have not been given any role, while all the others are tagged as "outer". Mapnik, though, handles this correctly, and the multipolygon has no inner member anyway.

It's probably worth fixing those, and checking the result is fully closed, using  Relation Analyzer. As you say, there may well be two different but related issues, and it's probably worth having separate examples of both. Labelling all the roles shouldn't be necessary, but it can't hurt!

comment:7 follow-up: ↓ 8 Changed 3 years ago by monxton

  • Cc monxton added

comment:8 in reply to: ↑ 7 Changed 3 years ago by monxton

Replying to monxton:

is this another example: http://www.openstreetmap.org/browse/relation/1400796 ?

This eventually healed itself - perhaps one tile was updated several days before its neighbour?

comment:9 Changed 8 months ago by iandees

  • Status changed from new to closed
  • Resolution set to wontfix

Cleaning aging tickets.

Note: See TracTickets for help on using tickets.