WikiProject Spain/Buenas prácticas

From OpenStreetMap Wiki
Jump to: navigation, search

Esta página nace de la necesidad de pequeñas explicaciones que guíen a usuarios de todo tipo sobre cómo mapear cosas muy concretas. A veces nos guiamos por el sentido común (que es el sentido menos común de todos los sentidos porque todo el mundo tiene el suyo propio) y no siempre coincide con la forma de funcionar ni de Openstreetmap ni de los programas que nos ayudan a editar el mapa. A partir de aquí algunos ejemplos:

Vías

Rotondas

Cada salida que dibujemos de la rotonda debe tener un único nodo compartido con la rotonda, para que los GPS puedan distinguir entre ellas al describir la ruta. No vale por tanto que dos salidas compartan un único nodo, ni que sea realmente así.

Transportes

Por carretera

Líneas de bus

  • No hacer líneas vacías sin propiedades superpuestas al recorrido de una línea de bus ni asignarles rol alguno dentro de una relación. Una línea vacía sin propiedades es eso, una línea vacía, en este caso el recorrido transcurrirá por líneas (no calles) sin nombre ninguno, con ninguna propiedad reconocida. Además el hecho de haber elementos superpuestos dificulta mucho el trabajo a los mapeadores posteriores.
  • Para seleccionar una línea oculta en JOSM se puede hacer clic con el botón del medio y seleccionar de una lista o bien hacer clic con el izquierdo+ALT para ir pasando de elemento en elemento aunque estén superpuestos y así poder ver sus propiedades y pertenencias

Ferroviarios

Bocas de metro

Las bocas de metro se mapean con la clave=valor railway=subway_entrance . Además se debe añadir , si se conoce, el nombre de la salida en cuestión con la clave name=nombredelasalida, NO de la estación en sí. En el siguiente gráfico podeis ver las diferencias sobre cómo y cómo no hacerlo

Subway entrance JOSM.png


Etiquetado en general

Etiqueta "name"

No se debe poner nombre a cosas que no lo tienen. Cuando vamos dibujando elementos en el mapa, es muy tentador ir rotulando absolutamente todo lo que vamos viendo, para que "salga en el mapa", pero esto es cartografiar para el render. Y en otros casos, simplemente se trataría de información redundante o de poner nombre a algo que, quizá sí lo tenga, pero que desconocemos. Lo mejor es verlo con algunos ejemplos:

Name redundante

Si un elemento ya está definido por su etiqueta, la etiqueta name conteniendo el tipo de elemento, sobra. En la primera imagen, el rectángulo verde es un polígono etiquetado como leisure=park. Sin embargo, lleva también la etiqueta name=Parque. La primera etiqueta ya lo define como tal; por ello, a no ser que tenga un nombre que lo designe específicamente, la etiqueta name no debe incluírse.

Captura OSM Parque.png

En esta segunda captura vemos un caso que sí es correcto, ya que se trata del nombre oficial del parque.

Captura OSM parque2.png

Name que no existe

Un árbol, por lo general, no tiene nombre, luego no necesita name. Por supuesto, como en el caso anterior, hay excepciones: un árbol singular, una pequeña plaza, un monumento que sí tiene nombre oficial o local... Para los árboles, si se conoce el tipo de árbol que es, tienes la etiqueta species:es. Vemos un ejemplo incorrecto:

Captura OSM arbol.png

La segunda captura de pantalla es correcta: se trata de un árbol singular etiquetado como name=Carrasca de Becha, species=Quercus ilex y species:es=Encina

Captura OSM arbol2.png

Name subjetivo

Cosas como "farola grande" o "islote ahí enmedio", no deberían aparecer como name de ningún elemento. No son oficiales ni locales, son apreciaciones subjetivas que deben evitarse en OSM:

Captura OSM nombre incorrecto.png Captura OSM nombre incorrecto2.png

Name incluído en vías

En el caso de algunos caminos y senderos, suele darse a menudo la inclusión de etiquetas name con cosas como "pista que va de Tal a Cual sitio", o bien "GR-11". En el primer caso, esa etiqueta sobra, porque es una descripción, no un nombre. Y para las referencias de rutas de senderismo, BTT, etc, (como GR-11), deben llevar la etiqueta ref en la relación que describe la ruta, nunca como name ni ref en ese tramo de sendero.

Captura OSM nameincorrecto1.png Captura OSM nameincorrecto2.png

Para el caso general de vías y carreteras referenciadas que forman parte de la red de carreteras, en name debe ir el nombre oficial de dicha vía. Y para caminos y senderos irá, únicamente si existe, el nombre con el que se conoce (a veces, desde hace siglos) ese camino o sendero. Por ejemplo:

Captura OSM namecorrecto1.png Captura OSM namecorrecto2.png

,son dos ejemplos correctos de uso de la etiqueta name

En el caso de que un tramo de carretera transcurra por una área urbana este debe llevar la denominación de la calle en la etiqueta name mientras que el nombre oficial de la vía pasa a alt_name. En la siguiente imagen, la carretera con denominación "Carretera Santander-Vinaroz" en la etiqueta name, cambia a "Calle de Nicolás García" a su paso por la localidad de Soncillo. Para no perder el nombre de toda la carretera se traslada "Carretera Santander-Vinaroz" a alt_name.

Nombre-carretera-calle-urbana.png

Edición

Changeset

En OSM llamamos changeset al conjunto de cambios individuales que, agrupados al subirse a la base de datos, forman una edición. En la práctica, nos encontramos con que no se le pone ningún cuidado a este elemento, que en realidad es la parte más importante del flujo de trabajo en OSM. Enciendes el ordenador, miras el mapa (ojo, porque no estás viendo el mapa, sino el resultado del render), y te pones a editar a lo loco esa zona que no te gusta, que ves demasiado vacía, o que conoces tan bien pero en la que ves errores. Seguro que lo que estás metiendo tiene todo el sentido del mundo y son datos correctos (o no), pero si no sigues estas sencillas indicaciones, puedes conseguir que otros editores no entiendan lo que haces, con todo lo que conlleva. Este es un proyecto colaborativo, lo que quiere decir que entre todos se está llevando adelante y, sobre todo, que el editor que venga detrás tiene que entender lo que está viendo y lo que se ha hecho hasta ese momento.

  • Agrupar correctamente el trabajo en un changeset: hay que procurar que cada changeset atienda a un tema concreto. No es recomendable ponerse a editar una zona mezclando en el mismo changeset cosas tan diversas como edificios, aceras, un parque que había por allí, una farmacia que no salía, las farolas del parque, dos gimnasios, las casetas de perro de esa urbanización que visitaste el fin de semana pasado y un bosque de abetos junto a un pueblo casi perdido en los Pirineos, aunque queda a cuarenta y siete kilómetros de la zona que empezaste a editar en un principio. Edita en zonas discretas, y agrupa por temas cada changeset.
  • No hagas changeset demasiado grandes: si cometes errores que no puedan arreglarse fácilmente, y te echan atrás el changeset (lo que llamamos revertir), se está perdiendo un montón de trabajo. O estás volviendo loco a alguien que busca porqué se ha vuelto rosa media Manga del Mar Menor entre dos mil doscientos nodos editados en el mismo changeset.
  • No hagas changeset demasiado pequeños: el otro extremo tampoco es bueno, porque no es sencillo rastrear qué ha hecho un editor (esté bien o mal), con treinta y dos changeset editados esa tarde y todos con el mismo título. Si trabajas con iD no seas de gatillo fácil, no pulses "Guardar" cada vez que muevas dos nodos.
  • Documenta el changeset: pon un título en condiciones. "Cambios añadidos", "Esto es así", "Pista al castillo, visita recomendada" o "Tened más cuidado con los cruces, por favor... " NO son títulos adecuados. En los dos primeros casos no se aporta ninguna información, los dos últimos son observaciones subjetivas. Sin embargo si, por ejemplo, escribimos "Arreglados cruces calle X según " y luego ponemos el enlace a la página de la wiki donde se documenta cómo debe hacerse ese tipo de vía, aportamos un mundo de información para futuros editores, tanto veteranos como noveles, en una sola frase.
  • Documenta la fuente (source): FUNDAMENTAL. Si un editor ve un cambio mal documentado, que no se entiende, que parece sospechoso y que no tiene documentada la fuente, lo va a revertir seguro, incluso pudiendo ser correcto. Siempre hay que poner la fuente de tus datos, para que otro editor pueda contrastarlos si es necesario. Si todo el changeset tiene una temática concreta, seguramente todo tendrá la misma fuente y lo podrás poner en el campo adecuado al subir el changeset. Si no es así, añade la etiqueta source a cada elemento que lo necesite. También puedes añadir varias fuentes en el changeset separándolas con punto y coma (";"). Aquí tienes una lista de cómo documentar correctamente algunas de las fuentes más usadas:
Origen de los datos Source
Por conocimiento personal de la zona knowledge
Por visita de la zona y tomar notas survey
Por visita de la zona y traerse un track en el GPS survey; track gps
Ortofoto del PNOA PNOA© Instituto Geográfico Nacional
Catastro Catastro de España