Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Multipolygon sharing boundary with shore renders incorrectly #3183

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 8 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: Wim L
[Submitted to the original trac issue database at 7.29pm, Sunday, 22nd August 2010]

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.

@openstreetmap-trac
Copy link
Author

Author: simone.saviolo[at]gmail.com
[Added to the original trac issue at 10.56am, Tuesday, 26th October 2010]

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.

@openstreetmap-trac
Copy link
Author

Author: tms13
[Added to the original trac issue at 9.25pm, Wednesday, 27th October 2010]

A couple more examples, in case that helps:

(the last is waiting for a Mapnik redraw, but it definitely looks wrong with osmarender).

@openstreetmap-trac
Copy link
Author

Author: tms13
[Added to the original trac issue at 9.36pm, Wednesday, 27th October 2010]

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?

@openstreetmap-trac
Copy link
Author

Author: simone.saviolo[at]gmail.com
[Added to the original trac issue at 7.36am, Thursday, 28th October 2010]

Replying to [comment:4 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.

@openstreetmap-trac
Copy link
Author

Author: tms13
[Added to the original trac issue at 12.48pm, Thursday, 28th October 2010]

Replying to [comment:5 simone.saviolo@]:

That is not the only problem. If you look at my [http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=tah&lon=8.42239&lat=45.32467&zoom=17 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 [http://www.openstreetmap.org/browse/way/82142270 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 [http://ra.osmsurround.org/analyze.jsp?relationId=1231156 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!

@openstreetmap-trac
Copy link
Author

Author: monxton
[Added to the original trac issue at 12.14am, Thursday, 3rd February 2011]

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

@openstreetmap-trac
Copy link
Author

Author: monxton
[Added to the original trac issue at 5.04pm, Saturday, 5th February 2011]

Replying to [comment:7 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?

@openstreetmap-trac
Copy link
Author

Author: iandees
[Added to the original trac issue at 9.02pm, Monday, 9th September 2013]

Cleaning aging tickets.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant