<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-06-03 18:46 GMT+02:00 Christoph Hormann <span dir="ltr"><<a href="mailto:chris_hormann@gmx.de" target="_blank">chris_hormann@gmx.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":f6b" class="" style="overflow:hidden">This is of course a fairly ressource intensive process with all building<br>

and road data in the database being used as basis.  But in principle it<br>
would be possible to run this with periodic updates in a similar way as<br>
currently done for the coastline.<br>
<br>
Everyone feel free to try out these polygons in your maps.  I have not<br>
tried this myself in the standard style yet, it is likely that<br>
adaptations in either the generalization process or the style (or both)<br>
are necessary for best results.  Comments and examples on that are<br>
welcome.</div></blockquote></div><br><br>First of all I really appreciate the work and dedication you have invested into this topic. Using external datasets from natural earth data has helped us in the beginning of the project to produce better maps, but it is IMHO clearly desirable to move these few uses in the future to osm-only derived datasets. Your blog post and process is for sure an important contribution to this discussion.<br>
<br><div class="">As a sidenote I wanted to point out that there are currently already 281547 ways (I suspect most of them to represent areas) tagged with place=* (not much compared to a total of 3.1M places in OSM) which could serve as an alternative to your (preprocessing intensive) process if more mappers could be convinced for this concept of mapping settlement extensions.<br>
<br></div><div class="">The reasons why settlements mostly aren't mapped as areas lie mainly in the current main map style sheet (read: "mapnik"), which ignores places on areas due to technical limitations and because the place-nodes are needed for routing and label placement, something that might change with the progress of the project and new ways of structuring the data (e.g. place-nodes and place-areas could co-exist, with appropriate rules how to avoid redundancy, e.g. a place-relation combining the two and getting the tags, the place-node could get the role "centre" or "central_point" or "label"...). Currently doing both, place on an area and on a node, is perceived as "duplication" and violation of the "one feature, one object"-rule, but this is really just a question of definitions (e.g. the node could be called "place centre" and the area "place extension"). I think it is obvious that a node will never be the best representation for something as large as a settlement (go and ask the Nominatim coders ;-) ).<br>
<br></div><div class="">The main problems of your approach --- it is still only "guessing" and the derived dataset might have a high probability to identify "built-up" areas but it will not in all cases be able to tell which settlement an area belongs to and it is a ressource intensive process that reasonably cannot be done on the fly --- could be overcome with explicit place polygons. On the downside it will of course take us quite some time to manually map all those settlements, and it is not even clear if people are interested in general to map this kind of feature (in addition to landuse etc.). If the main style picked this up and rendered areas with place=(city,town,village,hamlet,isolated_dwelling) as "built-up-area" this would surely help promoting the cause ;-)<br>
<br></div><div class="">cheers,<br>Martin<br></div></div></div>