|
I have a place that is called Haselstauder, which consists of two hamlets, one Oberhaselstauder, the other Unterhaselstauder. When at a higher zoom level, the common name for the place, Haselstauder, should be shown and not one of the lesser names take the space away from each other. When zooming in, the single names should take precedence. Is there any way to specify this behavior? Something like a relation to the three points exists, as they are both part of the larger name, but are there any guidelines on how to do this? |
|
That is mostly rendering related question, and often tagging "for the renderer" is discouraged. On the other hand, it might be possible to use existing location "hierarchy" to achieve the desired result. If documentation at http://wiki.openstreetmap.org/wiki/Place is correct, you could try using "village" for Haselstauder, which should render higher level name on higher zoom levels. |
|
I'd agree with Richlv that you could think of Haselstauder as a village consisting of two hamlets. There are towns near here which incorporate villages (because they got bigger over time) which is perhaps a similar situation. However, this still doesn't guarantee it will only render the label you want. It is more likely you'll get both the village and hamlet place labels if they don't overlap. |
|
That's a good question, but the solution is not found by trying to tag place names by types. The relevant tagging should still be structured: How is a name representative of an area? What areas is it used for, if there are several ones at different sizes. Then the name should be associated with each area, and conveniently placed for that area, so that it will effectively fit in it, and will not be centered outside of it. Then renderers could be able to choose with label to display, by comparing the surfaces of each area, seeing if the name can fit reliably in it (or not too far away outside of it) without creating superpositions of labels. If labels can't be placed together without creating superpositions, the renderer has to find a way to determine which one to display. Generally,
Of course, this requires an organization of administrative areas. Note also that the name of an area is not necessarily the name of its administrative center (most often the name of a city/commune), and the location of this area name will not match the location of its administrative center. In addition, the concept of a single administrative center for an area is flawed (I mean the "admin_centre" role added to a boundary relation). But the concept of a single "label" role for a boundary relation is correct: not only it provides a convenient location (which is definitely not the center of the centroid, notably when the area is definitely not convex, or surrounds enclaves), but this "label" role can also collect all the translations. It can also provide the exact label to display on maps, which will be distinct from the (often more precise) "name" property of an area, which is more convenient to perform global searches of names (for example the "name" property can provide disambiguating precisions, for homonyms, and these precisions are most often not needed and not wanted once you have placed the displayed label on an actual map, where you'll want this label to be short, even if it's not abbreviated). Note also that the "label" role can also provide alternate names (including abbreviations, incluiding for each translation) which will allow a render to select the abbreviation if it cannot fit the longer one without creating collisions or having to drop some surrounding labels. |
