[Tagging] Feature Proposal - RFC - Place areas

Martin Koppenhoefer dieterdreist at gmail.com
Mon Jun 19 11:04:03 UTC 2017


2017-06-19 12:44 GMT+02:00 Christoph Hormann <osm at imagico.de>:

> by the way is wrong.  Nodes and areas are two abstract concepts within
> OSM used to represent elements of reality.  While there are features
> that would normally be represented as areas that are occasionally as a
> simplified representation mapped as nodes (like a lake) there are also
> many things that are represented as nodes that should never be
> attempted to be mapped as areas - either by convention (like
> place=ocean) or due to their nature (like natural=peak).
>


yes, features that are a spot in reality (like a peak) should be
represented as a node.

But already when it comes to very small areas, like an amenity=post_box or
atm for example, mapping them as a node has some disadvantages (e.g. if the
post box is attached to a building wall, you don't know whether the post
box is inside or outside when the building is just an area (as opposed to
walls etc. mapped in detail) and the post box is only a node). So clearly
there is a tradeoff to be made, and we have to weigh in pros and cons to
see what we recommend (and what mappers find practicable). In the case of a
post box, a telephone booth, a drinking water fountain or an atm I guess
there will not be much opposition to map these as nodes. When it comes to
gates, benches and others, the situation might already change (often easier
to map a gate as a linear way rather than estimating the width and add it
as an attribute, especially if you want to add information about the
orientation, like for the benches)

For mapping an ocean or continent as a node there really aren't any good
arguments besides technical limitations and the way we have structured our
data (e.g. if the ocean boundary consisted of several segments (linear
relations themselves) rather than a single multipolygon relation with ways
as members, we could reduce the probability of editing conflicts to an
amount that it would become possible to map them, similar to how we do with
very long routes).

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170619/ab5bf512/attachment-0001.html>


More information about the Tagging mailing list