<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/12 Steve Bennett <span dir="ltr"><<a href="mailto:stevagewp@gmail.com" target="_blank">stevagewp@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>(a "mountain range" is really an abstraction over a number of individual mountains, and it's up to some sort of geologists' consensus where it begins and ends).<br></div></blockquote><div><br><br></div>
<div>+1, and it won't be a clearly defined border where some meters more or less matter or are clearly definable (in contrast e.g. to the position of the center of a road, which is quite precisely definable).<br><br> <br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<br></div><div>IMHO it would be nice to have an alternative dataset in lower zoomlevels for geographic regions and extended/blurry features, something like a set of shapefiles with translations into all languages we can provide, something similar to what natural earth data provides, but distributed and modified/translated by us, not just English and for higher zoom levels (i.e. more detailed) than what NE has. Still we could start with their geographic regions dataset and refine it, as "All versions of <i>Natural Earth</i> raster + vector map data found on this website are in the public domain."</div>

<div>
<div><br></div></div></div></div></div></blockquote><div><br></div></div><div>Are you saying that this kind of data is a poor fit for OSM itself?<br></div></blockquote><div><br><br></div><div>yes, for the reasons described above: no clear boundaries / fuzzy borders.<br>
</div><div>A solution could also be a new datatype in OSM for fuzzy objects, (e.g. a collection of objects and the consumer would create a hull area around them, possibly also roles for objects that are to exclude), but at least currently this kind of stuff does not fit into how osm works. <br>
<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div class="im"><div class="gmail_extra"> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra">if you don't know what it is (i.e. "generic feature") place=locality seems perfectly fitting, otherwise be more precise and tag or subtag it as what it is (e.g. a cluster of rocks).<br>


<br></div></div></blockquote><div><br></div></div><div>My issue with place=locality is that the place=* are basically for human habitation</div></blockquote><div><br><br><br><br></div><div>I wish it was like that ;-) (i.e. it was used only for settlements and parts of them). <br>
</div><div>There is a majority of values that are intended for settlements, but there are also others like place=locality (explicitly uninhabited), place=islet, island, archipelago (uncertain if inhabited) and there are those that are basically used to put a label for a big administrative entity on the map (like county, region, state, municipality, borough, country, etc.).<br>
<br></div><div>IMHO the island-stuff would fit better in "natural", and the labels for admin entities do not need "place" either (e.g. could be nodes with the role "label" on an object tagged with boundary=administrative admin_level=* name=*). Still place=locality would remain for more or less unspecific labels for uninhabited place.<br>
<br></div><div>Cheers,<br>Martin<br></div></div><br></div></div>