Fenced landuse?

[Minh_Nguyen (Minh Nguyễn)]

@dieterdreist

I don’t experience this. With iD you do not even notice it is a multipolygon, you only see a school and a fence. If you have to add more details on the fence, you can add nodes to it and split the way. All the editors I am using will keep (add) the way parts in the multipolygon-relation automatically. On the other hand, with overlapping ways, the problems start (which way do you want to split, and into which do you want to add the nodes, etc.)

Let’s suppose the fence does not have an opening in it, but it does have a concave section. A perimeter fence is very often set further back around a road entrance, but the mapper may not want to exclude that entrance area from the grounds. Once they’ve split the way, do they know that they can’t move the small section of fence inward but instead have to draw a new way?

Then again, even adopting multipolygon-basd approach in the first place would be challenging. How many iD users know how to create a single-member multipolygon relation? (The easiest trick is to pretend there’s a hole in the geometry: map a closed line inside and C Combine it with the outer area. Then you can remove the inner line from the relation and delete it.)

@dieterdreist

with the multipolygon approach, you simply draw the new geometry you like and remove the tag from the part of the outer way (select 2 nodes and split if required). No need to select and detach (potentially many) nodes. If the geometry is different, you also may not want to use the same amount of nodes for both, so after detaching you will also potentially have to delete nodes you do not need if you are going to develop the new geometry by transforming the other.

To clarify, I was referring to the G Unglue Ways command in JOSM and the D Disconnect command in iD, both of which can disentangle the two features immediately. But even if a more surgical approach is warranted, leaving the two features mostly attached, I suspect that more users would intuit the correct steps on their own when the two features are already present, versus having to correct the abstraction of a shared-geometry way.

Perhaps a fence is unlikely to have many tags or much history worth preserving, but suppose it’s a wall instead. Also, there may be other complicating factors, such as a mural on one section of the wall – do we recommend splitting this shared-geometry way so that part of it can be part of a multilinestring relation? If extraneous nodes is a problem, what about extraneous ways or relations?

[dieterdreist]

|
|

• | - |

Let’s suppose the fence does not have an opening in it, but it does have a concave section. A perimeter fence is very often set further back around a road entrance, but the mapper may not want to exclude that entrance area from the grounds. Once they’ve split the way, do they know that they can’t move the small section of fence inward but instead have to draw a new way?

Then again, even adopting multipolygon-basd approach in the first place would be challenging. How many iD users know how to create a single-member multipolygon relation? (The easiest trick is to pretend there’s a hole in the geometry: map a closed line inside and C Combine it with the outer area. Then you can remove the inner line from the relation and delete it.)

ok, I did not say the multipolygon is the best approach always and for everybody, just that it is a viable solution, which also has sufficient editor support to make braking it more difficult for unexperienced users, even if they are not aware of the nature of the relation they will not always break it

I am myself also using sometimes overlapping ways, although most of the time, I find it harder and more bothersome to edit later on, so if I am editing with JOSM I almost always create the relation.

To clarify, I was referring to the G Unglue Ways command in JOSM and the D Disconnect command in iD, both of which can disentangle the two features immediately. But even if a more surgical approach is warranted, leaving the two features mostly attached, I suspect that more users would intuit the correct steps on their own when the two features are already present, versus having to correct the abstraction of a shared-geometry way.

I wasn’t aware you could use unglue also on ways rather than specific nodes, but even if you do it like this, you end up having to deal (select and move or delete) with each and every node, even if it just derives from the other geometry, the existing one, and not the new one you are going to use for the fence, and which potentially could be much simpler and not need all these nodes. It may depend on the situation.

Perhaps a fence is unlikely to have many tags or much history worth preserving, but suppose it’s a wall instead. Also, there may be other complicating factors, such as a mural on one section of the wall – do we recommend splitting this shared-geometry way so that part of it can be part of a multilinestring relation? If extraneous nodes is a problem, what about extraneous ways or relations?

the fence way will preserve the history, similarly to 2 ways: as soon as you split a way to add more detail, only one of the results will get the history (if we were much interested in this history, we should store a reference to it when a new way is created by a split, something that likely has already been proposed since API 0.6 was introduced?), so if you redraw the whole fence, you will not have a history connection, but if you keep a part of the former fence way, it will remain. For murals I tend to use nodes, but a linear way would also be ok.