|
So I have a number of fields in an area I'm working on that are bounded by different boundaries - hedges, fences, ditches etc. It seems to make sense to draw all the boundaries in for a number of fields at once. For example, several fields may be bounded at some point by a single hedge that runs for some distance. So I can add and tag lines representing all the boundaries. But how can I then select multiple lines in iD and create an area within them? Example: If I drew on all the boundaries in this area, how could I then create individual areas for the fields within those boundaries, without adding the areas manually? Thanks in advance. David |
|
As already mentioned, one option is to add all the boundaries (hedges, gates, walls, etc.) and then use those linear features to create multipolygons. Unfortunately, if taken to the extreme, this will result in data that is essentially unmaintainable. An example of the problem can be seen here. At that location, "Walton Wood" is composed of a series of other patches of woodland, with different tree types, such as this one. It was originally mapped exactly like this, with the individual patches of woodland as constituent parts of one named multipolygon relation "Walton Wood". Unfortunately, an armchair mapper edited it and the result is as you see now - there's no relation between the individual logical parts of the wood and the whole. Try editing it and you'll see the problem straight away - in order to map anything else here, I'll have to revert the problem changeset, separately resolve any other problems that it tried to resolve (as the same issue may be present there too), and then continue mapping. There are lots of places (islands in lakes is an obvious example) where multipolygons make perfect sense, and the geometry of the multipolygon matches the real world. However, in cases where you're using unrelated items to create a multipolygon I'd argue that the result probably doesn't match the real world, will be difficult to maintain going forward and therefore isn't a good idea. Instead, create an area (using the same nodes as fences etc. if appropriate) for farmland, so that it's clear to all future mappers what it is and how to maintain it. |
|
@aseerel4c26: what I was doing was with areas; I've not tried with multipolygons. In iD I was creating an area, tagging it by landuse, then using the Split feature at different points on the area to break down the single boundary line into several lines; then tagging each line by boundary type. Note that this contradicts the concept raised here about leaving areas and boundaries as separate mapped entities. iD automatically creates a multipolygon relation if you split an area previously consisting of a single closed way. You can see it in the left side planel (although not very easily).
(30 Oct '15, 06:21)
aseerel4c26 ♦
(semi-offtopic continued) regarding the contradiction: not to me that much (compared to sharing nodes with areas mapped as closed way), since the multipolygon refers to linear objects as borders instead of points. The width of those linear objects may be implicitly (e.g. hedges are about 1 metre wide) or explicitly (e.g.
(30 Oct '15, 06:30)
aseerel4c26 ♦
|
|
sounds like you are searching to create a multipolygon relation with the boundaries as "outer" (role) ways. Like this example but without the inner hole. Select all the outer ways and add them to a relation with the role "outer". The outer ways need to share a node (at the corners), otherwise the outer ring would not be closed. How you can in iD? I do not know (and could find out while giving it a short try). iD seems to support areas with holes as multipolygons, though. I suggest to use Potlatch 2 or, better, JOSM (at least for such advanced editing). Thanks. I did try in JOSM but when I selected Create Multipolygon I got "Each node must connect exactly two ways", which suggests I'm not using it properly. My understanding of a multipolygon was that it was a construction of several areas, not an area constructed of several ways, so I'm not clear on how to use it in this context.
(28 Oct '15, 20:29)
David R French
@David R French: I have extended my answer. Yes, you can use the "create multipolygon" shortcut for this. It automatically sets the multipolygon tag to the relation object and sets the roles. As an alternative you can create a new relation and add the boundary ways manually to it. The error message suggests that you did not had a complete ring of ways in your selection. See my example image and try again. First try with just two or three test ways which form a ring (don't save them, of course).
(29 Oct '15, 06:00)
aseerel4c26 ♦
1
If I understand it question correctly, David has a number of non-closed ways that he wants to turn into a area. I don't know whether this is possible with the Create Multipolygon functionality of JOSM. AFAIK you have to draw the area as a separate object.
(29 Oct '15, 06:42)
escada
1
Having had a further play in iD, it seems I should probably look at this from the other angle. I can create areas corresponding to fields, then split the area into lines and tag each line as a different barrier type (hedge, ditch, fence etc). This is slightly more long-winded but will give the desired outcome. Now I need to decide whether to dedicate many hours to do this in my area; I don't want to end up with a patchwork map, but some other local areas already have this :) By the way, the reason I'm looking at mapping individual fields rather than tagging the whole area as farmland is that I have individual field names in many cases. Like everything I'm attempting in OSM, going down one course of action tends to throw up ten times as many questions as it solves.
(29 Oct '15, 10:19)
David R French
5
IMHO, you should map the field as an area, and draw a separate way for the hedges and fences. Do not reuse the lines for both things. Suppose the hedge is removed one day, then the area representing the field will be missing a part when you delete the line for the hedge. It's much easier to remove the way (aka line) representing the way in that case.
(29 Oct '15, 14:51)
escada
meta: @David R French: please, could you add your "long-winded" approach how to create such a multipolygon as an "answer" here? Great that you found out how it works!
(29 Oct '15, 19:10)
aseerel4c26 ♦
@escada: yes, turning a number of non-closed ways into an area works automatically with "create multipolygon" in JOSM - but the ways together need to really enclose an area, each of the ways (hedge) needs to be connected (shared node) with the next way (next hedge).
(29 Oct '15, 19:12)
aseerel4c26 ♦
@aseerel4c26: thanks, I didn't know that
(29 Oct '15, 19:13)
escada
showing 5 of 8
show 3 more comments
|
|
Years late to the party, but only now managed to wrap my head around the discussed issue in the last few days and frankly love it, while practically, I came only to research the subject because of 'duplicate edge' issues amongst highway areas, e.g. a bordering square and pedestrian area and a highway drawn across the edge of a pedestrian area, boom 'duplicate edge' pops up (and a few telling me to just thoroughly ignore it, an Osmose or other system analytical and/or render problem)... Complex 20/30/40 node long lines and drawn only once and shared amongst several adjacent multipolygon areas is great which brings me to the hedge comment above. If the hedge is removed, only remove the hedge related tag(s) from the line and it leaves the area(s) undisturbed. More precise ID editor 2020 wont even allow you to delete the line without first removing the M.poly relations, an excellent safeguard against damaging areas. It get's interesting if a plot's borders are changed, i.e. a vineyard was split in part vineyard, part orchard, integrated in other adjacent areas of same cover... it's a little work, and if setup right far from undecipherable. And how often does that happen? |
you might be interested in this question too: is-it-okay-if-landuse-borders-share-nodes-with-streets-rivers (and the others linked there). However, let's focus on the technical part of your question (as the title suggests) here.
Thanks, lots of useful information there. I think in this case one could argue that fields do extend to the centreline of their boundary as conceptual entities, although not as functional objects. I'll deal with it case-by-case.