Say there are several adjacent properties (residential, retail, school, hospital, whatever), all of which have surrounding fences. I see several ways to map these areas, but do all of them work? And which is best?

  1. Map each property as an enclosed area, with adjacent properties sharing nodes. Also tag each area with barrier=fence. This is simple but dependent on the renderer's ability to interpret the way both as an area (for the property) and as a closed way (for the fence). This would also result in overlapping fences, which I'm not sure would be a problem.

  2. Also map properties as enclosed areas sharing nodes, but map the fence as a separate way sharing the areas' boundary nodes. This is less ambiguous, and would allow the fence to be tagged with its own properties, but would result in nodes being shared by at least three ways which may be confusing to editors.

  3. Map each shared border separately, tagging it with barrier=fence, and use multipolygon relations to tag the areas using these ways as members. This seems to be the clearest and least redundant method, but also the most complicated, requiring a lot of relations.

asked 13 Jan '13, 11:36

Paul_012's gravatar image

Paul_012
686131731
accept rate: 33%

edited 13 Jan '13, 13:10

Please also bear in mind that unlike a lot of fences mapped in the UK it is unlikely that a fence would go through the middle of a semi-detached pair of houses.

(08 Feb '17, 18:13) BCNorwich

I think your second option is preferable. As you say, it avoids possible confusion of a way representing both a line and an area. There's nothing wrong sharing nodes between different ways.

Plus you can tag other details of the barrier, eg the height or width. Also the fence may not go all of the way around the area, part of it might be a wall or a hedge or a gate etc, so they can be mapped as separate ways. Or leave a gap for a an entrance.

Your third option of using multipolygon relations would be equivalent to this. Though as you say, relations can be more complicated, and confusing to new users, and may get broken. In general I wouldn't use a relation unless it was a large/complicated area - ie made up of dozens of separate ways, or several hundred nodes.

permanent link

answered 13 Jan '13, 13:52

Vclaw's gravatar image

Vclaw
9.1k891140
accept rate: 22%

1

Both 2) and 3) are semantically correct, so the choice comes down to what is easyer to create/maintain. Annoyingly, this is slightly subjective, depending on the mapper's proficiency and editor of choice. Because it is subjective, that kind of question comes up often.

I have a slight (subjective :p) preference for 3), unless you have a whole neighbourhood of them to map. Hopefully relations will only get easyer to handle. They need not be restricted to big/complicated areas, I'd say most relations have only a handfull of members.

(14 Jan '13, 09:28) Vincent de P... ♦

Create seperate ways for landuse areas and fences, it's alot easier to handle, and fences will not follow the edge of a property.

My second argument is weak, but the first one isn't, it's not fun explaining stacked ways for newbies.

permanent link

answered 16 Jan '13, 13:49

emj's gravatar image

emj
1.9k123447
accept rate: 15%

2

Well, in many cases fences do indeed follow the edge of a property. Actually, in many cases fences are the only indicator of the property boundary, so for practical purposes, they are the boundary.

(07 Feb '17, 08:30) sleske

I would also support option 2, for two reasons.

  1. It follows the general principle of mapping what we find on the ground. A school's grounds, a residential area and a fence are three separate entities, and are best mapped as three separate ways.
  2. The method can be extended to represent more complicated areas. Suppose that the school were separated from a residential area by a wall, and had a fence along the rest of its perimeter. The school's grounds are a single closed way, but the perimeter wall and fence are two separate linear ways.

A node that is shared between several ways is not really a problem. In Potlatch 2, it can be separated into several separate nodes by pressing shift-J, and each node can then be moved or deleted independently of the others. Any nodes that have not been moved can be recombined by selecting them and pressing J.

permanent link

answered 14 Jan '13, 17:57

Madryn's gravatar image

Madryn
2.2k355180
accept rate: 13%

These arguments are all perfectly valid for option 3 (relation) too. You have one osm entity per real-world entity, and it can be extended to more complicated cases (it's actually better than option 2 in that respect).

Relations are slightly more work to create (a few more clicks, which you save by not creating the same way 3 times), but are easyer to maintain afterwards (no cumbersome glued nodes).

(14 Jan '13, 22:28) Vincent de P... ♦
1

Having read some more about multipolygons (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) I would accept that method 3 is a perfectly good alternative to method 2. The choice probably depends which is easier to create, and which is easier to edit if anything changes. Does anyone know where I can find an example of method 3 in the map?

(15 Jan '13, 18:52) Madryn
2

Here is an example of method 3 with drains in stead of fences.

The parcels were imported (not by me) as polygons. So there were two lines on top of each other. Adding the drains would have added a third line, which is irritating to edit in JOSM (the editor I use mainly). So I converted the polygons to "multipolygons", deduplicated the lines and added the waterway tags where appropriate.

(15 Jan '13, 20:30) cartinus

<continued>

One of the reasons I didn't continue with this, is that this method of mapping turned out to be confusing for people working with Potlatch. Potlatch does not fill the "advanced multipolygons" so these people tend to overlook all the grass.

(15 Jan '13, 20:30) cartinus
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×820
×188
×164
×44

question asked: 13 Jan '13, 11:36

question was seen: 3,606 times

last updated: 08 Feb '17, 18:13

powered by OSQA