[OSM-newbies] Adjacent areas

[Phil! Gold]

* Werner Horsch <werner.horsch at gmail.com> [2011-08-19 10:21 -0300]:
> Make a relation using the 4 ways around the block, if someone moves the ways
> your prison moves too, the same can be done with a park, etc, etc

I recommend against this.

I've gone through several phases of how I model areas, and I've been
editing long enough to see the effects of each on data consumers and
subsequent editing (both mine and others').  In my opinion, using multiple
outer ways on an area needlessly complicates things.  (Unless it's an area
large enough that the outer edge would exceed the OSM limit of 2000 nodes
per way, in which case it's a necessary complication.)  On top of that, it
ends up splitting the road at a point where the road's features don't
change, which seems an unnecessary tangling of information.

My preference is to put the area's nodes beside the way, along the edge of
the road.  In my opinion, that best models the extent of the area.  The
main drawback here is that it makes the process of moving the road's way
more difficult, since the nodes on the side of the road would have to be
moved also.

There are a lot of people who prefer to have areas share nodes with the
road ways.  This makes editing and re-editing a lot simpler: both JOSM and
Potlatch have follow-ways functionality, where you start following the
nodes of a way and then keep pressing the 'F' key to continue, and both of
them will do the right thing when moving or adding nodes to a section of
shared ways.  The biggest drawback to this style is that selecting the
right way from a set of overlapping ways gets more annoying.  Both
Potlatch and JOSM have mechanisms to do it, but it's more work than just
clicking on a lone way.  The other argument against this is that it
doesn't reflect the actual location of the edge of the area in question,
although proponents sometimes argue that the road's way logically includes
the road's width, so the method is topologically correct.

As I indicated, I prefer the former approach, but either is
widely-accepted.  But please don't make multiple-ways-per-ring
multipolygons unless you have to.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
Out of register space (ugh)
                       -- vi
---- --- --