Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[Santiago Higuera]

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
> > 

Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[David Marín Carreño]

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 

Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[David Marín Carreño]

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 

Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[Santiago Higuera]

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
> 

Re: [Talk-es] Proposed_features/Extended_traffic_signs_tagging

[yo paseopor]

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

[Santiago Higuera]

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

[yo paseopor]

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

[Diego García]

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

[Santiago Higuera]

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