[Tagging] Request for new tag "natural=upland" (as way) or enabling "way" for "place" tags
Christoph Hormann
chris_hormann at gmx.de
Thu Jun 9 16:50:59 UTC 2016
On Thursday 09 June 2016, Amacri wrote:
>
> Provided that marking such areas with polylines can lead to
> inappropriate tagging as the boundaries are not well definable, they
> do not deserve just a point, as they may represent an extended area,
> that can be shaped through its text (often the original shape can be
> found in historic maps too, e.g., available in municipal archives.
>
> For these reasons, I would consider appropriate representing such
> places as areas when boundaries are well definable, or through lines
> when there is no deterministic way to define an actual boundary. I
> anyway would limit visibility of points (nodes) to very high zoom
> levels (e.g., zoom level
The thing is if something is not verifiably defined in its basic
localization - like if you have a certain name known to refer to a
place of some sort but if you ask a number of knowledgeable locals
where it is they all point vaguely at some place but each of them a
distinctly different one - that place is not mappable in OSM at all -
neither as a node, a linear way or an area.
If on the other hand there is a verifiable localization of the place -
which does not necessarily have to be in the form of either of these
three well established feature types - it can be mapped in that form.
However if you think the place is not well suited to be mapped as a node
and neither as an area this does dot necessarily make it a good
candidate to be mapped as a linear way. So far you have not given a
reason why for the type of place you are thinking of a way as a good
representation (except for the fact that creating a label for it in a
map in a basic form is fairly easy).
When thinking about mapping and tagging it is usually best to completely
ignore the question of how something can be possibly rendered in a map
at first and simply consider how it can be represented in the database
in a way that allows following mappers visiting the area to objectively
verify if the mapping is accurate or not.
> In case a new feature would be needed, which would be the most
> appropriate name? natural=upland? Please, suggest.
Actually you have not really said how you want to define natural=upland.
If it is as unspecific as place=locality there is no point in creating
a new tag. If it is more specific you need to tell how a mapper can
decide if something is to be tagged natural=upland. Note
the 'natural'-key generally implies something to be a verifiable
feature even without a name.
>
> Otherwise, would you consider appropriate requesting to enable lines
> for place=isolated_dwelling, place=hamlet or place=locality?
I cannot at the moment think of a situation where mapping
place=isolated_dwelling or place=hamlet as a linear way makes sense.
If you can verifiably map a settlement as a linear way you can also map
it as an area. Usually neither is the case so most populated places
are mapped as nodes. In case of a settlement consisting exclusively of
buildings densely located along a road at both sides tagging that
stretch of road as place=hamlet or similar might be a good compact way
to map it but i have not yet seen a case like this in reality.
place=locality is simply too vague to give a definite answer. You could
for example think of a certain stretch of coast with a certain name.
But in this case place=locality would be wrong anyway because
natural=coastline + name=foo would be perfectly sufficient.
On a general note - when things are mapped as nodes this is frequently
done with the implicit notion that this is a location with a certain
tolerance margin. You might think of mapping something with a linear
way as a method to specify an anisotropic tolerance, well localized in
one direction but poorly in another. However that is not what you
actually do when you map it as a way - on the contrary you much more
specifically localize it.
--
Christoph Hormann
http://www.imagico.de/
More information about the Tagging
mailing list