Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Discrepo de que la utilidad en la base de datos de una señal de tráfico sea la misma que la de la descripción 3d de un edificio, ni de que la importancia relativa de ambos elementos sea la misma. También pienso que el esquema de etiquetado propuesto para las señales está más pensado para que determinados renderizadores puedan dibujarlas, que en el sentido de aportar información útil a la base de datos de una manera eficiente. Hay señales que pueden aportar información útil a la base de datos, pero muchas otras solo aportan ruido. Es mi opinión Santiago Higuera El mar, 07-02-2017 a las 04:51 +, David Marín Carreño escribió: > Santiago: tiene exactamente la misma utilidad que mapear un edificio > 3D, o un árbol, o una farola. Estamos reflejando la reaildad de una > manera verificable y modificable de manera universal. Si es > complicado (que, en ciertos casos, lo es), pues habrá que trabajar en > un editor que lo simplifique. Digamos que mapear un edificio en 3D no > es la cosa más sencilla y mira, ahí tenemos a unos cuantos > haciéndolo. > yopaseopor: tengo alguna duda/objeción respecto al tema de los > destinations como relaciones. Me explico: > El hecho de colocar los destinations como relaciones tiene todo el > sentido del mundo desde el punto de vista de saber qué carretera del > cruce debo tomar para ir a X. > El nuevo esquema propuesto sirve para mapear las señales (lo cual me > parece fantabuloso), pero no para interpretarlas. Es decir, si sólo > se usa el esquema de mapeo de señal y se elimina la relación > "destination" actual, un ruteador no va a tener ni idea de cómo > avisar al conductor de qué camino tomar para ir a X. > Creo que sería muy bueno mantener ambas perspectivas en el nuevo > esquema (no llamarlas modo "viejo" o "nuevo"), ya que ambas son > útiles y necesarias. > > Sólo mi opinión. > -- > David > > El mar., 7 feb. 2017 a las 1:31, Santiago Higuera ( g>) escribió: > > A ver, yopaseopor: > > Lo que no me has respondido es a la pregunta de para qué sirve o en > > qué > > mejora el mapa por el hecho de indicarse, mediante etiquetas en las > > señales informativas, que determinada información aparece en > > determinada línea del panel, o que determinada información va > > acompañada de determinado icono. No le veo la utilidad. Si acaso > > puede > > ser útil la información del panel en sí, pero ¿qué importancia > > tiene en > > qué posición aparece dentro del panel o que icono la acompaña?. > > Bastaría poner las informaciones del panel en una etiqueta 'info', > > separadas por punto y coma, por ejemplo, y cualquier navegador > > podría > > leerlo (como hace el de google). > > > > Respecto de argumentar que tampoco sería necesario entonces > > etiquetar > > los tramos, ahí está parte del problema. El hecho de poner la misma > > información en dos sitios diferentes, el tramo de carretera y la > > señal, > > dificulta mucho el trabajo de actualización y podría hacer que al > > final > > no fuera fiable ninguno de los dos sistemas. Si el tramo está > > correctamente etiquetado, el navegador correspondiente, al detectar > > que > > entra en un tramo con determinada restricción, puede dibujar en > > pantalla una señal, sin necesidad de comprobar si existe además un > > elemento 'señal' en el mapa. Así suelen hacer los navegadores con > > la > > velocidad máxima permitida en un tramo: pintan la señal en pantalla > > mientras estás dentro de ese tramo, les da igual si hay o no, en > > ese > > momento, una señal vertical sobre el terreno. La información es > > 'este > > tramo tiene una restricción determinada'. Debemos poner la > > información > > solo en un sitio, en mi opinión en el tramo, y luego los programas > > navegadores ya pintarán las señalitas que correspondan. El elemento > > 'señal' en sí no es importante, lo importante es la restricción que > > afecta a la circulación de un tramo. Por ejemplo, una prohibición > > de > > adelantamiento se puede indicar mediante la raya continua en el eje > > de > > la carretera, y tiene plena valided. La información que nosotros > > debemos trasladar al mapa, si es que tenemos que trasladar ese tipo > > de > > informaciones, es que ese tramo tiene restringido el > > adelantamiento. La > > existencia o no de una señal vertical es lo de menos. > > > > Otro ejemplo podrían ser las señales de llegada a un municipio. La > > información importante para el mapa es donde está la línea del > > límite > > municipal. El navegador, al detectar que atraviesa esa línea, podrá > > dibujarte en pantalla la señal correspondiente. Con la información > > de > > las poblaciones a las que se accede por determinado desvío pasa > > igual. > > Lo normal es que no aparezca más que alguna de ellas. El navegador > > calculará la ruta y nos indicará qué desviación debemos tomar, al > > margen de que haya o no señales que lo indiquen. Ningún navegador > > va a > > utilizar la información de las señales para establecer las rutas. > > Sería > > un absurdo. Lo que ut
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Sobre el tema de mantener actualizada la información, y sin discrepancias, eso se arregla con herramientas. Todo esto se ha relanzado desde el momento en que ha llegado a nosotros un excel con las coordenadas de todas las señales verticales de la red nacional de carreteras. Son elementos físicos, verificables, que están ahí. EMHO, deberían introducirse en el mapa *tal cual*. Para ello el nuevo esquema de yopaseopor es ideal. Ahora bien, también debe introducirse "la semántica": límites de velocidad, prohibición de adelantar, etc. Son dos pasos distintos y complementarios el uno al otro. Al igual que tenemos validadores de sentido de rotondas, pues alguien tendrá que currarse el validador de límites de velocidad o el de prohibición de adelantar para llevar la semántica de la señal a la vía correspondiente. -- David El mar., 7 feb. 2017 a las 5:51, David Marín Carreño () escribió: > Santiago: tiene exactamente la misma utilidad que mapear un edificio 3D, o > un árbol, o una farola. Estamos reflejando la reaildad de una manera > verificable y modificable de manera universal. Si es complicado (que, en > ciertos casos, lo es), pues habrá que trabajar en un editor que lo > simplifique. Digamos que mapear un edificio en 3D no es la cosa más > sencilla y mira, ahí tenemos a unos cuantos haciéndolo. > > yopaseopor: tengo alguna duda/objeción respecto al tema de los > destinations como relaciones. Me explico: > >- El hecho de colocar los destinations como relaciones tiene todo el >sentido del mundo desde el punto de vista de saber qué carretera del cruce >debo tomar para ir a X. >- El nuevo esquema propuesto sirve para mapear las señales (lo cual me >parece fantabuloso), pero no para interpretarlas. Es decir, si sólo se usa >el esquema de mapeo de señal y se elimina la relación "destination" actual, >un ruteador no va a tener ni idea de cómo avisar al conductor de qué camino >tomar para ir a X. > > Creo que sería muy bueno mantener ambas perspectivas en el nuevo esquema > (no llamarlas modo "viejo" o "nuevo"), ya que ambas son útiles y necesarias. > > Sólo mi opinión. > -- > David > > El mar., 7 feb. 2017 a las 1:31, Santiago Higuera () > escribió: > > A ver, yopaseopor: > Lo que no me has respondido es a la pregunta de para qué sirve o en qué > mejora el mapa por el hecho de indicarse, mediante etiquetas en las > señales informativas, que determinada información aparece en > determinada línea del panel, o que determinada información va > acompañada de determinado icono. No le veo la utilidad. Si acaso puede > ser útil la información del panel en sí, pero ¿qué importancia tiene en > qué posición aparece dentro del panel o que icono la acompaña?. > Bastaría poner las informaciones del panel en una etiqueta 'info', > separadas por punto y coma, por ejemplo, y cualquier navegador podría > leerlo (como hace el de google). > > Respecto de argumentar que tampoco sería necesario entonces etiquetar > los tramos, ahí está parte del problema. El hecho de poner la misma > información en dos sitios diferentes, el tramo de carretera y la señal, > dificulta mucho el trabajo de actualización y podría hacer que al final > no fuera fiable ninguno de los dos sistemas. Si el tramo está > correctamente etiquetado, el navegador correspondiente, al detectar que > entra en un tramo con determinada restricción, puede dibujar en > pantalla una señal, sin necesidad de comprobar si existe además un > elemento 'señal' en el mapa. Así suelen hacer los navegadores con la > velocidad máxima permitida en un tramo: pintan la señal en pantalla > mientras estás dentro de ese tramo, les da igual si hay o no, en ese > momento, una señal vertical sobre el terreno. La información es 'este > tramo tiene una restricción determinada'. Debemos poner la información > solo en un sitio, en mi opinión en el tramo, y luego los programas > navegadores ya pintarán las señalitas que correspondan. El elemento > 'señal' en sí no es importante, lo importante es la restricción que > afecta a la circulación de un tramo. Por ejemplo, una prohibición de > adelantamiento se puede indicar mediante la raya continua en el eje de > la carretera, y tiene plena valided. La información que nosotros > debemos trasladar al mapa, si es que tenemos que trasladar ese tipo de > informaciones, es que ese tramo tiene restringido el adelantamiento. La > existencia o no de una señal vertical es lo de menos. > > Otro ejemplo podrían ser las señales de llegada a un municipio. La > información importante para el mapa es donde está la línea del límite > municipal. El navegador, al detectar que atraviesa esa línea, podrá > dibujarte en pantalla la señal correspondiente. Con la información de > las poblaciones a las que se accede por determinado desvío pasa igual. > Lo normal es que no aparezca más que alguna de ellas. El navegador > calculará la ruta y nos indicará qué desviación debemos tomar, al > margen de que haya o no señales que lo indiquen. Ningún nave
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Santiago: tiene exactamente la misma utilidad que mapear un edificio 3D, o un árbol, o una farola. Estamos reflejando la reaildad de una manera verificable y modificable de manera universal. Si es complicado (que, en ciertos casos, lo es), pues habrá que trabajar en un editor que lo simplifique. Digamos que mapear un edificio en 3D no es la cosa más sencilla y mira, ahí tenemos a unos cuantos haciéndolo. yopaseopor: tengo alguna duda/objeción respecto al tema de los destinations como relaciones. Me explico: - El hecho de colocar los destinations como relaciones tiene todo el sentido del mundo desde el punto de vista de saber qué carretera del cruce debo tomar para ir a X. - El nuevo esquema propuesto sirve para mapear las señales (lo cual me parece fantabuloso), pero no para interpretarlas. Es decir, si sólo se usa el esquema de mapeo de señal y se elimina la relación "destination" actual, un ruteador no va a tener ni idea de cómo avisar al conductor de qué camino tomar para ir a X. Creo que sería muy bueno mantener ambas perspectivas en el nuevo esquema (no llamarlas modo "viejo" o "nuevo"), ya que ambas son útiles y necesarias. Sólo mi opinión. -- David El mar., 7 feb. 2017 a las 1:31, Santiago Higuera () escribió: > A ver, yopaseopor: > Lo que no me has respondido es a la pregunta de para qué sirve o en qué > mejora el mapa por el hecho de indicarse, mediante etiquetas en las > señales informativas, que determinada información aparece en > determinada línea del panel, o que determinada información va > acompañada de determinado icono. No le veo la utilidad. Si acaso puede > ser útil la información del panel en sí, pero ¿qué importancia tiene en > qué posición aparece dentro del panel o que icono la acompaña?. > Bastaría poner las informaciones del panel en una etiqueta 'info', > separadas por punto y coma, por ejemplo, y cualquier navegador podría > leerlo (como hace el de google). > > Respecto de argumentar que tampoco sería necesario entonces etiquetar > los tramos, ahí está parte del problema. El hecho de poner la misma > información en dos sitios diferentes, el tramo de carretera y la señal, > dificulta mucho el trabajo de actualización y podría hacer que al final > no fuera fiable ninguno de los dos sistemas. Si el tramo está > correctamente etiquetado, el navegador correspondiente, al detectar que > entra en un tramo con determinada restricción, puede dibujar en > pantalla una señal, sin necesidad de comprobar si existe además un > elemento 'señal' en el mapa. Así suelen hacer los navegadores con la > velocidad máxima permitida en un tramo: pintan la señal en pantalla > mientras estás dentro de ese tramo, les da igual si hay o no, en ese > momento, una señal vertical sobre el terreno. La información es 'este > tramo tiene una restricción determinada'. Debemos poner la información > solo en un sitio, en mi opinión en el tramo, y luego los programas > navegadores ya pintarán las señalitas que correspondan. El elemento > 'señal' en sí no es importante, lo importante es la restricción que > afecta a la circulación de un tramo. Por ejemplo, una prohibición de > adelantamiento se puede indicar mediante la raya continua en el eje de > la carretera, y tiene plena valided. La información que nosotros > debemos trasladar al mapa, si es que tenemos que trasladar ese tipo de > informaciones, es que ese tramo tiene restringido el adelantamiento. La > existencia o no de una señal vertical es lo de menos. > > Otro ejemplo podrían ser las señales de llegada a un municipio. La > información importante para el mapa es donde está la línea del límite > municipal. El navegador, al detectar que atraviesa esa línea, podrá > dibujarte en pantalla la señal correspondiente. Con la información de > las poblaciones a las que se accede por determinado desvío pasa igual. > Lo normal es que no aparezca más que alguna de ellas. El navegador > calculará la ruta y nos indicará qué desviación debemos tomar, al > margen de que haya o no señales que lo indiquen. Ningún navegador va a > utilizar la información de las señales para establecer las rutas. Sería > un absurdo. Lo que utilizan los navegadoreses la conectividad entre > tramos y las características del mismo, para saber a qué velocidad se > puede circular. > > Respecto del tema de señalizar la accesibilidad para personas con > minusvalías, sí que le veo mucha utilidad, y creo que es mucho más > importante que el trabajo arduo de inventariar todas las señales de > tráfico de España, que creo que sirve para muy poco. > > Santiago > > > El mar, 07-02-2017 a las 00:16 +0100, yo paseopor escribió: > > El criterio de ponerlas o no ponerlas no lo entiendo: o las pones o > > no las pones. ¿Me puedes explicar cual es el criterio para mapear un > > semáforo o una marca vial como es un paso de cebra? El objetivo de > > OSM es el mapa más completo posible: podemos poner farolas y árboles > > pero no podemos poner un elemento imprescindible en cualquier > > co
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
A ver, yopaseopor: Lo que no me has respondido es a la pregunta de para qué sirve o en qué mejora el mapa por el hecho de indicarse, mediante etiquetas en las señales informativas, que determinada información aparece en determinada línea del panel, o que determinada información va acompañada de determinado icono. No le veo la utilidad. Si acaso puede ser útil la información del panel en sí, pero ¿qué importancia tiene en qué posición aparece dentro del panel o que icono la acompaña?. Bastaría poner las informaciones del panel en una etiqueta 'info', separadas por punto y coma, por ejemplo, y cualquier navegador podría leerlo (como hace el de google). Respecto de argumentar que tampoco sería necesario entonces etiquetar los tramos, ahí está parte del problema. El hecho de poner la misma información en dos sitios diferentes, el tramo de carretera y la señal, dificulta mucho el trabajo de actualización y podría hacer que al final no fuera fiable ninguno de los dos sistemas. Si el tramo está correctamente etiquetado, el navegador correspondiente, al detectar que entra en un tramo con determinada restricción, puede dibujar en pantalla una señal, sin necesidad de comprobar si existe además un elemento 'señal' en el mapa. Así suelen hacer los navegadores con la velocidad máxima permitida en un tramo: pintan la señal en pantalla mientras estás dentro de ese tramo, les da igual si hay o no, en ese momento, una señal vertical sobre el terreno. La información es 'este tramo tiene una restricción determinada'. Debemos poner la información solo en un sitio, en mi opinión en el tramo, y luego los programas navegadores ya pintarán las señalitas que correspondan. El elemento 'señal' en sí no es importante, lo importante es la restricción que afecta a la circulación de un tramo. Por ejemplo, una prohibición de adelantamiento se puede indicar mediante la raya continua en el eje de la carretera, y tiene plena valided. La información que nosotros debemos trasladar al mapa, si es que tenemos que trasladar ese tipo de informaciones, es que ese tramo tiene restringido el adelantamiento. La existencia o no de una señal vertical es lo de menos. Otro ejemplo podrían ser las señales de llegada a un municipio. La información importante para el mapa es donde está la línea del límite municipal. El navegador, al detectar que atraviesa esa línea, podrá dibujarte en pantalla la señal correspondiente. Con la información de las poblaciones a las que se accede por determinado desvío pasa igual. Lo normal es que no aparezca más que alguna de ellas. El navegador calculará la ruta y nos indicará qué desviación debemos tomar, al margen de que haya o no señales que lo indiquen. Ningún navegador va a utilizar la información de las señales para establecer las rutas. Sería un absurdo. Lo que utilizan los navegadoreses la conectividad entre tramos y las características del mismo, para saber a qué velocidad se puede circular. Respecto del tema de señalizar la accesibilidad para personas con minusvalías, sí que le veo mucha utilidad, y creo que es mucho más importante que el trabajo arduo de inventariar todas las señales de tráfico de España, que creo que sirve para muy poco. Santiago El mar, 07-02-2017 a las 00:16 +0100, yo paseopor escribió: > El criterio de ponerlas o no ponerlas no lo entiendo: o las pones o > no las pones. ¿Me puedes explicar cual es el criterio para mapear un > semáforo o una marca vial como es un paso de cebra? El objetivo de > OSM es el mapa más completo posible: podemos poner farolas y árboles > pero no podemos poner un elemento imprescindible en cualquier > conducción. > Dices que la información de los iconos contenidos en las señales no > es tan importante. De acuerdo: ¿qué lo es? El mapear los bares es > importante? es estable? (porque mira que hay comercios que cierran > más que cambian las señales) El mapear un pipican (y las discusiones > que se han derivado en tagging) es importante? El hacerlo a la manera > española no es importante. ¿Tú te comprarías un GPS que te mostrara > los paneles más parecidos a los que ves en la carretera o idénticos a > los de EEUU? > ¿Desde cuando una señal de tráfico en el tiempo "cambia" cada "poco" > ? A no ser que haya una dictadura y le cambien el nombre al pueblo > dudo mucho que la mayoría de 8000 municipios españoles varíen cada > año de nombre. Madrid seguirá siendo Madrid, y a no ser que haya una > nueva obra la señal que indica hacia dónde va no se mueve de sitio ni > cambia. > ¿Qué indican las señales de tráfico? INFORMACIÓN. ¿Es importante esa > información? Yo opino que sí, y la DGT también pues si no no las > pondrían. Y por eso abogo por darla TODA. > Sobre el argumento de que varían las restriccionescomo varían > tampoco marcamos los tramos, no? porque van a variar, no hace falta > marcarlos ni con señales ni sin ellas. > Dices que no se renderizan en ningún sitio. Llevo dos años peleándome > para que sí lo hagan, aunque pueda parecer cutre. Admito que el > Kendzi
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
El criterio de ponerlas o no ponerlas no lo entiendo: o las pones o no las pones. ¿Me puedes explicar cual es el criterio para mapear un semáforo o una marca vial como es un paso de cebra? El objetivo de OSM es el mapa más completo posible: podemos poner farolas y árboles pero no podemos poner un elemento imprescindible en cualquier conducción. Dices que la información de los iconos contenidos en las señales no es tan importante. De acuerdo: ¿qué lo es? El mapear los bares es importante? es estable? (porque mira que hay comercios que cierran más que cambian las señales) El mapear un pipican (y las discusiones que se han derivado en tagging) es importante? El hacerlo a la manera española no es importante. ¿Tú te comprarías un GPS que te mostrara los paneles más parecidos a los que ves en la carretera o idénticos a los de EEUU? ¿Desde cuando una señal de tráfico en el tiempo "cambia" cada "poco" ? A no ser que haya una dictadura y le cambien el nombre al pueblo dudo mucho que la mayoría de 8000 municipios españoles varíen cada año de nombre. Madrid seguirá siendo Madrid, y a no ser que haya una nueva obra la señal que indica hacia dónde va no se mueve de sitio ni cambia. ¿Qué indican las señales de tráfico? INFORMACIÓN. ¿Es importante esa información? Yo opino que sí, y la DGT también pues si no no las pondrían. Y por eso abogo por darla TODA. Sobre el argumento de que varían las restriccionescomo varían tampoco marcamos los tramos, no? porque van a variar, no hace falta marcarlos ni con señales ni sin ellas. Dices que no se renderizan en ningún sitio. Llevo dos años peleándome para que sí lo hagan, aunque pueda parecer cutre. Admito que el Kendzi3D es mejorable, y que el estilo de JOSM o mapa de Overpass no es el mejor. Pero sí, se muestran. Y si este etiquetado se aprueba no dudes que habrá empresas que se podrán aprovechar de él, pues lo da todo mascado, no hay ni siquiera que dividir, ni hacer correspondencias de órdenes, a cada etiqueta le da su valor. Es una faenón? De cojones, como lo es poner cada paso adaptado a minusválidos, o algo de lo que hay más que señales: portales. Es importante esa información.Como considero yo que son las señales de tráfico. Porque si empezamos a dudar de la importancia de mapear elementos...no mapeemos nada, nada es importante, y el mundo cambia costantemente y más con Donald Trump al mando del botón nuclear. Salut i change the world yopaseopor PD: sin acritud ninguna, pero las señales son un nodo más de OSM, y ese nodo debe dar el máximo de información útil posible.Y por si las moscas...aunque no sean importantes...no te saltes ninguna, especialmente una rara, roja con una forma extraña y que pone algo de POTS o OTPS, no recuerdo bien , tengo entendido que a unos hombrecillos de azul , verde o rojo...les mola mucho que te las saltes y después te paran para felicitarte por ello ;) ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Hola: Pues me vas a perdonar, yopaseopor, pero a mí me recuerda al típico error que se comete cuando se empieza a programar orientado a objetos de 'querer modelizar el mundo'. Yo creo que hay que esquematizar y simplificar. No quiero ni pensar en el trabajo que supondría mantener actualizado ese esquema de señalización. Yo creo que la información que aparece en los paneles informativos no es tan importante, ni tampoco el icono concreto que lleva, que además cambian a lo largo del tiempo y del territorio. Quizás especificar las señales de peligro (triangulares, fondo blanco, borde rojo) y las de reglamentación (circulares, fondo blanco, borde rojo) que especifican prohibiciones y limitaciones de velocidad y cosas así. Un caso que sí considero del máximo interés son los hitos kilométricos. En los tres casos, son señales que varían menos en el tiempo. Pero el resto de señales, veo un trabajo ímprobo y poco útil tratar de detallarlas tanto, sobre todo porque sería casi imposible mantenerlo actualizado y en poco tiempo nadie (ningún programa) lo utilizaría, por haber dejado de ser fiable. ¿cuál es el objetivo o la ventaja de tener modelizadas hasta el último detalle el contenido de todas las señales de tráfico? ¿En qué mejora el mapa, si luego no salen renderizadas en ningún sitio? Incluso las restricciones de velocidad máxima, restricciones de giro y otras consideraciones similares creo que lo suyo es aplicarlas al tramo de la vía al que se aplican. ¿vamos a marcar las señales de inicio de prohibición de adelantamiento y las del final de dicha prohibición? ¿Has pensado lo a menudo que varían esas restricciones a medida que evolucionan las carreteras? Sinceramente, no acierto a comprender el objetivo de ese etiquetado tan complejo Sin acritud, buscando la eficiencia del trabajo que se dedica al objetivo de tener un buen mapa Santiago Higuera El lun, 06-02-2017 a las 22:11 +0100, yo paseopor escribió: > No es porque la propuesta la haya ejecutado uno mismo pero niego la > mayor. No estoy para nada de acuerdo. > Lo que precisamente muestra la wiki es lo contrario: > -Con una clave y una subclave cubres la posición clara de más de 8000 > señales de 29 países. Evidentemente cada señal indica una cosa > diferente, lo siento, en nuestro país hay más de 300 según el BOE y > contando variaciones sale un índice de más de 700. > -Con un sistema basado en 6 claves más tienes en tu mano TODAS las > señales de destino (orientación , confirmación) españolas (y por ende > todas las mundiales) con TODOS sus elementos). Es cierto que los > modelos Kendzi3D hay que hacerlos... (mentira , hay que hacer los > interiores, y sólo se hacen una vez, después ya sirven para todas las > señales: ej:El nombre de tu ciudad lo escribirás sólo una vez en SVG, > después replicando código aparecerá sin ningún trabajo extra , en la > señal de destino que desees). > -Y más te diría, para que te hagas una idea las subclaves de TODAS > las señales se controlaban con sólo 9 posiciones, que se conseguían > con las letras B y C y con los números 1 y 3, pero a la gente > "importante" de tagging no le gustó el tema de eliminar los > multivalores, y replicaron que las subetiquetas debían tener un valor > "añadido" por lo cual tuve que diferenciar entre los paneles (antes > con la B cubría lower panel,main panel y las direcciones de la > rotonda se gestionaban de manera diferente) y darles "valor legible" > a las subetiquetas. > > Los ejemplos de la wiki lo que revelan es que este sistema es muy > exhaustivo (quien desee completarlo) y a la vez muy versátil, y sin > exagerar, válido para ser considerado la opción para todos los > sitemas de señales de tráfico del mundo, en OSM. > > Los preset pormenorizados de cada país llegarán (existen el de España > como más completo, Holanda, Bélgica y Finlandia con todas las señales > genéricas) y los demás países en un modo básico. > > El estilo funciona para esos 29 países y es fácilmente ampliable. > > Por lo que respeta a Kendzi, de acuerdo, hay cosas por hacer, los > colores están teorizados, salen en el preset pero aún no están > implementados en los paneles (puesto que los españoles son blancos o > azules) así cómo los símbolos. Pero también os digo que aunque es > cierto que hay que hacer cada contenido que se quiera ver sólo hay > que hacerlo una sola vez (no hablo de las 8000 genéricas de 29 > países, que ya están todas hechas). Es decir, los textos contenidos > en esta señal de Zaragoza http://i.imgur.com/AvMOXwg.jpg (...no habrá > que volverlos a hacer y aparecerán en todos los sitios dónde se les > "reclame" cuando esté todo finalizado (hice la wiki por la presión > ejercida sobre la necesidad de documentación, hubiera preferido > hacerla al estar todo acabado pero eso podía tardar meses). > > -Queda por hacer? Sí, queda, pero ya es plenamente funcional. Dado > que el preset que es lo básico para "ayudar" a facilitar la > información y el estilo están ya finalizados (en el caso español) no >
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
No es porque la propuesta la haya ejecutado uno mismo pero niego la mayor. No estoy para nada de acuerdo. Lo que precisamente muestra la wiki es lo contrario: -Con una clave y una subclave cubres la posición clara de más de 8000 señales de 29 países. Evidentemente cada señal indica una cosa diferente, lo siento, en nuestro país hay más de 300 según el BOE y contando variaciones sale un índice de más de 700. -Con un sistema basado en 6 claves más tienes en tu mano TODAS las señales de destino (orientación , confirmación) españolas (y por ende todas las mundiales) con TODOS sus elementos). Es cierto que los modelos Kendzi3D hay que hacerlos... (mentira , hay que hacer los interiores, y sólo se hacen una vez, después ya sirven para todas las señales: ej:El nombre de tu ciudad lo escribirás sólo una vez en SVG, después replicando código aparecerá sin ningún trabajo extra , en la señal de destino que desees). -Y más te diría, para que te hagas una idea las subclaves de TODAS las señales se controlaban con sólo 9 posiciones, que se conseguían con las letras B y C y con los números 1 y 3, pero a la gente "importante" de tagging no le gustó el tema de eliminar los multivalores, y replicaron que las subetiquetas debían tener un valor "añadido" por lo cual tuve que diferenciar entre los paneles (antes con la B cubría lower panel,main panel y las direcciones de la rotonda se gestionaban de manera diferente) y darles "valor legible" a las subetiquetas. Los ejemplos de la wiki lo que revelan es que este sistema es muy exhaustivo (quien desee completarlo) y a la vez muy versátil, y sin exagerar, válido para ser considerado la opción para todos los sitemas de señales de tráfico del mundo, en OSM. Los preset pormenorizados de cada país llegarán (existen el de España como más completo, Holanda, Bélgica y Finlandia con todas las señales genéricas) y los demás países en un modo básico. El estilo funciona para esos 29 países y es fácilmente ampliable. Por lo que respeta a Kendzi, de acuerdo, hay cosas por hacer, los colores están teorizados, salen en el preset pero aún no están implementados en los paneles (puesto que los españoles son blancos o azules) así cómo los símbolos. Pero también os digo que aunque es cierto que hay que hacer cada contenido que se quiera ver sólo hay que hacerlo una sola vez (no hablo de las 8000 genéricas de 29 países, que ya están todas hechas). Es decir, los textos contenidos en esta señal de Zaragoza http://i.imgur.com/AvMOXwg.jpg (...no habrá que volverlos a hacer y aparecerán en todos los sitios dónde se les "reclame" cuando esté todo finalizado (hice la wiki por la presión ejercida sobre la necesidad de documentación, hubiera preferido hacerla al estar todo acabado pero eso podía tardar meses). -Queda por hacer? Sí, queda, pero ya es plenamente funcional. Dado que el preset que es lo básico para "ayudar" a facilitar la información y el estilo están ya finalizados (en el caso español) no va a haber necesidad de grandes reetiquetados, siendo esta herramienta muy útil en casos como la posible importación de más de 50 señales en nuestro país. -Y, si el esquema nuevo no satisface porque eso de hacer señales de destino "clavadas", con toda la información es una sandez y con la notación de valores múltiples y las etiquetas básicas de destino ya vale...pues se puede usar la opción nº 2 de cada señal, que acostumbra a ser la que no tiene asignada ninguna subclave o etiqueta numérica. Además, y sin ser presuntuoso, está abierto en github y el que lo hace es este mismo que os habla, así que si teneis dudas, sugerencias...pedidlo y se os dará ;) Salut i senyals yopaseopor ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Buenas tardes a todos. En líneas generales a mí me parece correcto. Puntos que querría destacar: - Es compatible con el etiquetado actual, no obliga a cambiar lo que ya está etiquetado. - La notación para separar valores múltiples propuesta me parece genial, totalmente correcta respecto al punto y coma. Ojalá se adoptara para el resto de ejemplos con los que peleamos de vez en cuando. - En la parte dedicada a señales informativas de destino, no acabo de entender el esquema general. En parte porque no domino lo que tenemos actualmente, para poder comparar, y en parte porque le tengo manía al inglés. - La información de rotondas es bastante compleja, pero es que quizá no haya otra forma tan esquemática de hacerlo. En este punto se hace necesario alguna ayuda en forma de plugin de JOSM para etiquetar. En resumen, desde el momento en que no es incompatible con el etiquetado actual, sino que añade posibilidades, creo que debería seguir adelante. Quizá haya que pulir puntos y simplificar algún esquema, de cara a su comprensión y legibilidad, pero no ser rechazado. Un saludo, _ > Talk-es mailing list > Talk-es@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-es > ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging
Reconozco el trabajo realizado, pero a mí me parece una locura. Practicamente supone hacer un etiquetado concreto para cada señal. Habría que buscar puntos comunes, que permitan resumir las cosas. No lo veo práctico,la verdad El dom, 05-02-2017 a las 19:44 +0100, yo paseopor escribió: > Buenas gente!! > > Supongo que a estas alturas de la película ya sabeis que mi pasión > son las señales de tráfico y sabreis que he hecho mis pinitos en > varias herramientas vinculadas a OSM con respecto a ellas. Por > recordarlo y evitando repetirme lo máximo posible me refiero a: > > -Presets señales de tráfico para JOSM > -Estilo señales de tráfico para JOSM > -Modelos generales y españoles para plug-in JOSM Kendzi3D > > Y a estas alturas sabreis también que la puesta en práctica de un > esquema de etiquetaje que difiere algo del original (sobretodo por lo > que hace referencia al tema de los multivalores y el que las señales > de destino no sean relaciones en mi caso) me ha provocado algún dolor > de cabeza, especialmente cuando lo he mencionado en la lista de > tagging, dónde gente como Jan Mueschel (creador del OSM Lane > visualizer) ha mostrado "de forma vehemente" su desacuerdo http://www > .openstreetmap.org/changeset/45668406 . Mi respuesta fue algo aciaga > http://yopaseopor.blogspot.com.es/2017/01/yomapeo-ok-you-win.html > > Pasado un poco el calentón y para no tener más problemas en ese > sentido he decidido documentar la propuesta de forma extensa y espero > que intensa. Os pido que si teneis un par de minutos os la mireis y > la critiqueis, la mejoreis, o simplemente opineis sobre ella, pues > vosotros sois los usuarios finales quienes vais a usarla (recordad > que tenemos encima una posible importación de más de 50 señales > de tráfico en territorio nacional, así que necesitamos herramientas). > La encontrareis en https://wiki.openstreetmap.org/wiki/Proposed_featu > res/Extended_traffic_signs_tagging > Muchas gracias a toda la gente que ya lo ha hecho o almenos se ha > leído este correo y a todos y todas los que habeis ayudado en alguna > fase del proceso en alguno de los componentes. > > Salut i senyals > yopaseopor > > PD: la propuesta está en inglés puesto que la gente que ha tenido sus > más y sus menos conmigo por este tema no hablan castellano, pero > evidentmente si finalmente no la eliminan lo traduciré todo. Al fin y > al cabo el único preset de todos que tiene señales de destino es el > español, incluida la señalética catalana que es un poco diferente, > con traducciones al castellano, catalán e inglés. > > PD2: ni aunque el esquema extendido propuesto no fuere aceptado las > herramientas funcionan igualmente con el esquema básico, usando la > opción que no tenga subetiquetas y volcando allí todos los > multivalores. > ___ > Talk-es mailing list > Talk-es@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Proposed_features/Extended_traffic_signs_tagging
Buenas gente!! Supongo que a estas alturas de la película ya sabeis que mi pasión son las señales de tráfico y sabreis que he hecho mis pinitos en varias herramientas vinculadas a OSM con respecto a ellas. Por recordarlo y evitando repetirme lo máximo posible me refiero a: -Presets señales de tráfico para JOSM -Estilo señales de tráfico para JOSM -Modelos generales y españoles para plug-in JOSM Kendzi3D Y a estas alturas sabreis también que la puesta en práctica de un esquema de etiquetaje que difiere algo del original (sobretodo por lo que hace referencia al tema de los multivalores y el que las señales de destino no sean relaciones en mi caso) me ha provocado algún dolor de cabeza, especialmente cuando lo he mencionado en la lista de tagging, dónde gente como Jan Mueschel (creador del OSM Lane visualizer) ha mostrado "de forma vehemente" su desacuerdo http://www.openstreetmap.org/changeset/45668406 . Mi respuesta fue algo aciaga http://yopaseopor.blogspot.com.es/2017/01/yomapeo-ok-you-win.html Pasado un poco el calentón y para no tener más problemas en ese sentido he decidido documentar la propuesta de forma extensa y espero que intensa. Os pido que si teneis un par de minutos os la mireis y la critiqueis, la mejoreis, o simplemente opineis sobre ella, pues vosotros sois los usuarios finales quienes vais a usarla (recordad que tenemos encima una posible importación de más de 50 señales de tráfico en territorio nacional, así que necesitamos herramientas). La encontrareis en https://wiki.openstreetmap.org/wiki/Proposed_features/Extended_traffic_signs_tagging Muchas gracias a toda la gente que ya lo ha hecho o almenos se ha leído este correo y a todos y todas los que habeis ayudado en alguna fase del proceso en alguno de los componentes. Salut i senyals yopaseopor PD: la propuesta está en inglés puesto que la gente que ha tenido sus más y sus menos conmigo por este tema no hablan castellano, pero evidentmente si finalmente no la eliminan lo traduciré todo. Al fin y al cabo el único preset de todos que tiene señales de destino es el español, incluida la señalética catalana que es un poco diferente, con traducciones al castellano, catalán e inglés. PD2: ni aunque el esquema extendido propuesto no fuere aceptado las herramientas funcionan igualmente con el esquema básico, usando la opción que no tenga subetiquetas y volcando allí todos los multivalores. ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es