El jue., 30 abr. 2020 a las 17:27, Daniel Callejas Sevilla (< daniel.callejas.sevi...@gmail.com>) escribió:
> Hola a todos, > > tras algo de debate en el grupo Telegram OSM España sobre esta etiqueta, > se perfilan trés puntos de vista que vienen a añadirse a los que ya existen > en la página de debate en el Wiki en inglés: > > - Idéntico: El contenido de destination= debe ser idéntico al texto > presente en el cartel informativo o texto escrito en el firme. > > - Normalizado: El contenido de destination= no debe seguir el texto del > cartel o firme estrictamente, sino que debe quitar abreviaturas y > similares, de acuerdo con la tendencia similar en otras etiquetas (e.g. > name=). > > - Intermedio: El contenido debería ser idéntico al texto presente en el > cartel o firme, pero en ciertos casos se pueden reescribir partes si no hay > riesgo de confusión. > > > Para juzgar estas posiciones, mi impresión es que debemos entender cuál es > el propósito de la etiqueta destination=. Y según el wiki, este propósito > es (textualmente) representar lo que el conductor ve cuando conduce y se > aproxima a una bifurcación, para ayudar en situaciones como navegación GPS. > ¿Dónde pone eso textualmente? Traducción compartida en Telegram de las partes que se han comentado en el Telegram que son importantes de la wiki https://wiki.openstreetmap.org/wiki/Key:destination Destino de caminos En el sistema de carreteras, la clave destination=* describe el contenido de las señales o la escritura en el suelo indicando los nombres de las ubicaciones a las que se dirige la ruta etiquetada. Así, los sistemas de navegación pueden referirse a las señales de tráfico que el conductor ve realmente. Valor El valor de la etiqueta de destino debería ser el contenido de la señal, como se leería de principio a fin. Los diferentes destinos en la misma señal están separados por punto y coma. (Ver ejemplos a continuación). Esta clave es solo para valores que se indican explícitamente en señales o escrituras básicas. Si las abreviaturas (tal como aparecen exactamente en un letrero) deben usarse en una etiqueta de destino se está discutiendo y se está disputando, en la página de discusión de esta etiqueta. Numéricamente hablando, en una proporción de 20:1, el consenso de edición sobre si usar abreviaturas que aparecen en las señales es no, y usar los mismos estándares que se dan en Información de salida y como se especifica en los nombres estándar de OSM: ("No lo hagas": si el nombre se puede deletrear sin una abreviatura, entonces no lo abrevies"). > destination= no tiene el propósito de describir el nombre oficial de un > destino, y por lo tanto no tiene sentido querer aplicar las reglas > generales de "no abreviamos en OSM". Aquí no deben aplicarse, por las > razones que siguen. > > Tengamos en cuenta que el público a quien se dirige esta etiqueta > destination= puede ser de cualquier origen, y puede no hablar la lengua > local o incluso no conocer suficientemente el alfabeto local. > > También hay que valorar que el propósito de destination= es de no crear > distracciones y dar una indicación precisa y rápida, exactamente en el > instante en el que es necesaria, puesto que el usuario está conduciendo. > > Adicionalmente, un GPS puede tener restricción en la cantidad de texto que > puede mostrar al conductor, por lo que es posible que un texto demasiado > largo se corte de forma desafortunada, ocultando información esencial. > Esto no aplica para este caso. El espacio de la señal no representa el texto que puede hablar el GPS. Este es el mismo caso que en el name y él porque no se abrevia entre otros motivos. Es fácil coger un nombre completo y adaptarlo, como abreviarlo para cada situación o espacio que pueda mostrar el GPS en este espacio. Pero si esta abreviado es bastante más complicado adaptarlo a las necesidades. > > Cabe añadir también que, para un GPS que tenga función de síntesis vocal, > puede ser recomendable una etiqueta adicional destination:speech=<texto > apto para un sintetizador de voz>. No obstante, los argumentos de arriba se > siguen aplicando: alguien que no hable la lengua tendría bastante > dificultad en asociar la abreviatura que ve en el cartel, con el texto no > abreviado. > > Por último, creo que es más correcto "mapear lo que esta en el terreno" > sin hacer interpretaciones, que pueden partir de una buena intención y > falsear el propósito de esta etiqueta. > > Por esto, la opcion "Normalizado" me parece desafortunada. Si cambiamos > abreviaturas por sus textos completos, un conductor que no esté > familiarizado previamente con el significado de la abreviatura perderá > segundos preciosos en asociar un texto largo con una señal textual corta. > > Ejemplo: https://www.mapillary.com/map/im/VZytigI7an53gkHvSn13ow > > Idéntico: destination=Armilla;P.T. Ciencias de la Salud > Normalizado: destination=Armilla; Parque Tecnológico Ciencias de la Salud > > Creo más razonable que el criterio sea el "Intermedio" propuesto arriba, > siempre y cuando la persona que mapea tenga un motivo claro y justificado > para desviarse del contenido del cartel que quiere representar. > > > Leeré con mucho gusto otras ideas y propuestas. > > Un saludo confinado! > Daniel. > _______________________________________________ > Talk-es mailing list > Talk-es@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-es > Hay otro problema añadido. destination representa la vía de salida no la señal en sí aunque es extrapolable claro esta y se termina usando en la señal. También sucede en algunos casos que ya que las salidas de autovía tienen varías señales indicando el destino de diferentes tamaños, las abreviaturas usadas no siempre coinciden de una señal a otra para la misma salida. Yo estoy más de acuerdo con el Normalizado. Es cómo se esta haciendo con otro etiquetado para evitar diferentes problemas bastante pulidos. Entiendo lo que se plantea aunque no lo comparta. Y puedo ver lógico el planteamiento intermedio. Cosas como P.Industrial creo que hay que ponerlas como Polígono Industrial, pero otras como ZIP que se comento en Telegram puede que tengan significado suficiente para dejarla como esta. Saludos. -- Jorge Sanz Sanfructuoso - Sanchi Blog http://jorgesanzs.es/
_______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
