#9623 closed defect (fixed)
Small issue with multipolygon having fence and fence_type
| Reported by: | naoliv | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | 14.01 (hotfix) |
| Component: | Core | Version: | |
| Keywords: | Cc: |
Description
With two ways forming a closed polygon, both having barrier=fence + fence_type=chain_link, select them and create a multipolygon. Note how barrier=fence is kept on the ways but fence_type=chain_link is thrown inside the relation.
Shouldn't fence_type stay together with barrier, at the way?
Attachments (1)
Change History (5)
comment:1 by , 12 years ago
by , 12 years ago
| Attachment: | example.osm added |
|---|
comment:2 by , 12 years ago
I think that barrier shouldn't be moved, even if both ways have the same barrier value.
See the example.
Select ways tagged with m1=yes and create a multipolygon
Then select ways tagged with m2=yes and create another multipolygon
Note that m1 will have the same type of barriers while m2 will have two types (it won't be possible to move barrier inside the relation then).
This makes me think that barrier (plus fence_type and other properties related to the barrier) should always be part of the way.
comment:4 by , 12 years ago
| Milestone: | → 14.01 (hotfix) |
|---|



Since r5225, barriers (as well as
source) are considered to be "linear tags" which are excluded from being moved to relation tags. In this case, I agree, that the result is wrong/unwanted.In this case, the multipolygon is a "barrier multipolygon" and thus the
barriertag should be moved. Not too easy to determine this automatically …