Proposal:Geographical Places

From OpenStreetMap Wiki
Jump to navigation Jump to search
Geographical places
Proposal status: Rejected (inactive)
Proposed by: polderrunner
Tagging: place=land/water + size_level=1 to 10
Applies to: node, way, area
Definition: To improve labeling (naming) of geographical features
Statistics:

Rendered as: *
Draft started:
Proposed on: 2008-11-01
RFC start: 2008-11-11
Vote start: 2009-05-13
Vote end: 2009-06-01

Rationale

There is a need for a better way of labeling geographic features, such as seas, mountain ranges, large lakes, archipelagos, peninsulas etc. Currently, such features cannot be adequately labeled to have their names rendered according to the size etc of the feature. Smaller features defined by a natural=* tag can have a name tag added but this does not allow any control of how the name is rendered (zoom levels, font size etc). And for larger features that are too big to be defined as a closed area or for which no natural=* tag exists this solution is not applicable. Neither is place=locality with a name tag a useful solution in most situations as such names will only render at the highest zoom levels. And water bodies cannot be reasonably handled by any of these solutions.

Therefore, a tagging scheme that will support the name rendering of natural features according to their type and size is needed.

Proposal

Land features

place=land + size_level=1 to 10 for tagging land features according to size (see below).

Water features

place=water + size_level=1 to 10 for tagging water features. Having separate values for land and water features allows a renderer to use different colours for the two types of features, such as blue text for water bodies and black for land features.

Size level

size_level=1 to 10 is introduced for the purpose of classifying the linear size of the feature and hence its importance. This tag may be used by renderers to decide at which zoom levels the name should be rendered, font size to use etc.

Suggested values for size_level:

size_level Linear size Examples
1 >3000 km Pacific Ocean (ocean), Europe (continent)
2 1000-3000 km Red Sea (sea), The Alps (mountain range), Hawaiian Islands (archipelago)
3 300-1000 km North Sea (sea), Grand Canyon (canyon), Windward Islands (archipelago)
4 100-300 km Bretagne (peninsula), Everglades (wetland), Vänern (lake)
5 30-100 km Mallorca (island), Bodensee (lake), Etna (volcano)
6 10-30 km Cape of Good Hope (peninsula), Thira (island)
7 3-10 km
8 1-3 km
9 0.3-1 km
10 <0.3 km

If size_level is missing a default value of 9 is assumed.


An optional type=* may be used to indicate the type of feature, e.g. sea, fjord, island, peninsula, desert.


This proposal does not affect the use of place=* when applied to populated places (cities, towns etc).

Tagging examples

Land feature: place=land + size_level=2 + name=The Alps + (optional) type=mountain_range

Water feature: place=water + size_level=3 + name=North Sea + (optional) type=sea


Rendering

Affects rendering of associated name tag (position, zoom levels, font size, angle, colour etc)

node Use on node: Render associated name centered at this location.

way Use on (linear) way: Render name at midpoint of way and along the way (like names for waterway=river or highway=*). Useful for features having a principal direction like mountain ranges, fjords and archipelagos.

area Use on area: Render name at "center of gravity". May be combined with a natural=* tag for the area.

Deprecates

place=continent, place=island, place=islet and (when used for "geographical" features) place=locality .

Acknowledgement

This proposal is inspired by a suggestion made by Bengibollen in Talk:Key:Place.

Please use the discussion page for comments.

Voting

Type {{vote|yes/no}} -- ~~~~ to approve/oppose this proposal and sign with your user name & date.

  • I approve this proposal I approve this proposal. Polderrunner 20:13, 13 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. -- Thomas Wood 20:20, 13 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. The size_level is unnecessary. It should be an area, and if it's an area a renderer can calculate the size and render accordingly. It's already happening in current mapnik rendering for example (but rather to decide whether to display a name or not at the moment). Secondly, I wonder how one will make a polygon the size of an ocean... --Eimai 20:37, 13 May 2009 (UTC). --- That is precisely the reason for the proposal. It is impractical to draw a polygon around big features and also completely unnecessary when you can just place a node at the center where you want the name rendered. Polderrunner 21:17, 13 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. If this is a size estimation, use est_size and the "real value", not some arbitrary level that everyone needs to have a look at the table to use it. -- Ulfl 07:03, 14 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. never add rendering related tags in features -- unsigned vote by User:Ulfl 07:03, 14 May 2009
  • I oppose this proposal I oppose this proposal. We really need better rendering support for these kinds of things, but manually tagging for the renderer like this when we should infer the values based on our data isn't the proper way to go about it. --Ævar Arnfjörð Bjarmason 12:19, 14 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. I'm not opposed to the general idea of providing hints for renderers, but this is as close to a pure rendering instruction as I can think of, and that I do not support. --Stefan Bethke 13:51, 15 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal. MikeCollinson 11:50, 21 May 2009 (UTC)
  • I oppose this proposal I oppose this proposal, because this becomes too complicated, rather add values to the existing system if none fits your need. --Skippern 23:25, 25 May 2009 (UTC)
  • I approve this proposal I approve this proposal. because there is current no possibility to get an boundary of an area like a mountain range --fossy 11:21, 7 June 2009 (UTC)
  • I oppose this proposal I oppose this proposal. -- Dezhin 12:17, 9 July 2009 (UTC)