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?

asked 18 Oct '10, 18:47

Alexander%20Roalter's gravatar image

Alexander Ro...
261151624
accept rate: 0%


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.

permanent link

answered 21 Oct '10, 16:16

Richlv's gravatar image

Richlv
1.6k142936
accept rate: 29%

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.

permanent link

answered 21 Oct '10, 16:24

EdLoach's gravatar image

EdLoach ♦
18.1k14148263
accept rate: 23%

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,

  • if the name is used for an administrative area of level n, it will be prefered to a name for an administrative area of level n+1 or more.
  • When the labels are at the same administrative level, another metric could be used:
  • population living in each area
  • or relative surface (in square meters) of areas (giving priority to the larger area, but after trying to slightly move the center of label of the larger area)

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.

permanent link

answered 02 Sep '11, 02:08

Verdy_p's gravatar image

Verdy_p
14181115
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×389
×190
×181

question asked: 18 Oct '10, 18:47

question was seen: 6,388 times

last updated: 02 Sep '11, 02:08

powered by OSQA