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/

_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to