Opened 5 years ago

Closed 18 months ago

#3183 closed defect (wontfix)

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 (3)

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

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by Wim L

osmarender rendering

Changed 5 years ago by Wim L

mapnik rendering

comment:1 Changed 5 years ago by Wim L

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

Changed 5 years ago by osm@…

Simple testcase reproducing the problem

comment:2 Changed 4 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: Changed 4 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: Changed 4 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 4 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: Changed 4 years ago by monxton

  • Cc monxton added

comment:8 in reply to: ↑ 7 Changed 4 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 18 months ago by iandees

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

Cleaning aging tickets.

Note: See TracTickets for help on using tickets.