ES:Claves homónimas

From OpenStreetMap Wiki
(Redirected from ES:Homonymous keys)
Jump to navigation Jump to search

broom

Help (89606) - The Noun Project.svg

Unas claves tienen un propósito o tipo de dato distinto según la etiqueta primaria del elemento. En otros casos, una clave homónima puede tiene los sentidos diferentes cuando se ha aplicado en nodos y vías. Estos conflictos ocurren frecuentemente cuando usamos los esquemas de "refinamiento iterativo" junto con las palabras que son homónimas en el idioma inglés.

Lista de las claves homónimas

information sign

Este artículo es un esbozo. Puedes ayudar a OpenStreetMap ampliándolo.

Homónimas en inglés

Refinar la característica contra algo tangencial

  • admin_level=*
    • cuando se usa con boundary=* – el nivel administrativo de la frontera sí misma
    • cuando se usa con government=* – el nivel administrativo del entidad gubernamental que administra la característica
  • distance=*
  • min_height=*
    • cuando se usa con attraction=* – la estatura (height) mínima de los pasajeros
    • cuando se usa con building=* – la altura (height) sobre el suelo en que el edificio empieza

Contenemiento contra refinamiento

  • bench=*
  • emergency=*
    • cuando se usa como una etiqueta primaria de una característica – the kind of public safety feature
    • cuando se usa con highway=* – whether emergency vehicles are allowed
  • junction=*
    • cuando se usa como una etiqueta primaria de una característica – whether two or more ways form a junction at the node
    • cuando se usa con highway=* – the kind of junction
  • kerb=*
    • cuando se usa como una etiqueta primaria de una característica – the kind of kerb
    • cuando se usa con crossing=* – whether there is a kerb at either end of the crossing
  • swimming_pool=*

Formatos distintos

Otros matices

Desventajas

An editor's developers may find it difficult to implement a field for a key that has a homonym associated with a different preset, especially if the homonymous keys have different data types or acceptable values. iD's fields suggest likely values based on taginfo lists of most common values by key. Since taginfo does not segment these lists by primary feature tag, irrelevant suggestions may appear.

If an element is tagged with multiple feature tags and each feature tag can potentially be used with a different homonym, a renderer or other data consumer may produce inconsistent, nondeterministic, or nonsensical results. For example, if a feature is simultaneously tagged building=yes and attraction=carousel, min_height=* may indicate either the height of the space beneath the carousel (if it sits on an elevated structure) or the minimum height required to ride the carousel. Indeed, every renderer that conforms to the Simple 3D buildings specification inaccurately depicts way 161214224 floating above the ground. A renderer may need to ignore the tag when set to a typical child height, which may be neither desirable nor feasible.

As an extreme example, various uses of type=* had to be deprecated in favor of other keys because it was impossible to indicate the type of a reservoir etc. that is mapped as a multipolygon, which requires type=multipolygon.

Mitigación

Some tagging schemes have made use of namespaces, subkeys, or more descriptive keys to avoid key conflicts. For example, construction=* is now used as a namespace to quality most feature tags; its use as a key only continues with certain feature keys that are unlikely to be tagged on the same feature. aerodrome=* replaced type=* on aeroway=aerodrome features, making it possible to map an airport as a multipolygon relation. man_made=flagpole features are tagged flag:type=* and potentially tower:type=*.

Some mappers avoid tagging multiple primary feature tags on a single feature, instead mapping multiple features to represent the same physical object. However, this approach can violate the "One feature, one OSM element" principle.