Modify

Opened 15 years ago

Closed 14 years ago

#5175 closed defect (fixed)

wrong displayed color of multipolygon relation area

Reported by: anonymous Owned by: ulfl
Priority: minor Milestone:
Component: Internal mappaint style Version: tested
Keywords: multipolygon Cc:

Description

As soon as a multipolygon relation contains a member which is a way marked as highway=pedestrian, the color of the multipolygon turns to transparent green although the multipolygon relation has property highway=pedestrian


example multipolygon not displaying OK:

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

displayed area turns to transparent green when the following two ways are contained:

http://www.openstreetmap.org/browse/way/62688821

http://www.openstreetmap.org/browse/way/40365393

changing them from highway=pedestrian to something different makes multipolygon display OK


example multipolygon displaying OK:

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


Josm version used: 3329

Attachments (0)

Change History (7)

comment:1 by anonymous, 15 years ago

typing error: forget a "no":

As soon as a multipolygon relation contains a member which is a way marked as highway=pedestrian, the color of the multipolygon turns to transparent green although the multipolygon relation has no property highway=pedestrian

comment:2 by bastiK, 15 years ago

The wiki is quite clear that Multipolygon properties should not go on the way if the outer polygon consists of more than one (closed) way.

Should we enforce this? (Currently it loops over the outer ways and picks the first area style it finds.)

comment:3 by stoecker, 15 years ago

We can improve MapPaintVisitor, so that it does not stop for first outer style, but parses all and breaks when they differ. Question is how to handle empty styles - as difference or ignore them?

The issue here is, that the multipolygon has no area drawing style and thus the drawing of outer ways is used where it shouldn't. This is one of the issues why I favour type=boundary over type=multipolygon for boundaries.

in reply to:  3 comment:4 by bastiK, 15 years ago

Replying to stoecker:

The issue here is, that the multipolygon has no area drawing style and thus the drawing of outer ways is used where it shouldn't. This is one of the issues why I favour type=boundary over type=multipolygon for boundaries.

First rule of thumb could be: If multipolygon relation itself has interesting tags (other than type=multipolygon) then assume, that the outer ways are irrelevant for area rendering.

We can improve MapPaintVisitor, so that it does not stop for first outer style, but parses all and breaks when they differ.

What if 2 different tag combinations happen to result in exactly the same style... OK, let's ignore this generously and wait for the bug report of someone noticing it.

comment:5 by stoecker, 15 years ago

First rule of thumb could be: If multipolygon relation itself has interesting tags (other than
type=multipolygon) then assume, that the outer ways are irrelevant for area rendering.

I fear this will not produce expected results. The tag relation instead of way is to new to be really reliable ATM. Maybe in 1-2 years.

in reply to:  5 comment:6 by bastiK, 15 years ago

Replying to stoecker:

First rule of thumb could be: If multipolygon relation itself has interesting tags (other than
type=multipolygon) then assume, that the outer ways are irrelevant for area rendering.

I fear this will not produce expected results. The tag relation instead of way is to new to be really reliable ATM. Maybe in 1-2 years.

Either you put the attribute on the outer way(s) or on the relation. I haven't seen a mix of both styles. E.g. if the relation is tagged as admin_level=*, it is clear that the multipolygon is not supposed to be a pedestrian area, even if one of the boundary ways happens to be tagged with highway=pedestrian.

comment:7 by bastiK, 14 years ago

Resolution: fixed
Status: newclosed

It seems with the recent changes in multipolygon handling, this is no longer an issue.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain ulfl.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.