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

[Talk-es] Me presento y pregunto:

[Santiago Díaz de Argandoña]

Hola:
Hace bastante tiempo que me suscribí a esta lista, pero ahora me animo a
escribir. Mi lugar de mapeo habitual es Álava (creo que soy el único
usuario activo por aquí), aunque de vez en cuando edito otras zonas.
Últimamente estoy añadiendo la cobertura de suelo en la Llanada Alavesa,
aunque hasta hace poco estuve arreglando la infraestructura ferroviaria en
Bilbao. Precisamente, después de editar esta zona me han surgido un par de
dudas respecto al ferrocarril, pero en Cataluña. Son las siguientes:

1º La línea Llobregat-Anoia, a partir de Molí Nou (donde acaba la L8), creo
que debería ser railway=narrow_gauge + gauge=1000 (no railway=rail, como
ahora). La definición que se da en OSMWiki para este tipo de ferrocarriles
es: "trenes con un ancho de vía
 (trocha) menor que el
llamado "ancho estándar" de 1435mm.".

2º Los tranvías de Barcelona (Trambaix/Trambesòs) tienen a lo largo de todo
su trazado service=yard. En principio, esta etiqueta solo debería usarse en
desvíos; las vías con servicio comercial tendrían que llevar usage=main. No
solo es incorrecto el uso de service=yard, sino que además dificulta la
visualización de las vías.

Si estos supuestos fallos estuvieran en una zona que conociera, los hubiera
arreglado sin más; pero en este caso no he tocado nada, por si acaso se
utiliza otro criterio. Además, me chocaba que con una comunidad tan activa
nadie se hubiera dado cuenta de los fallos.

En resumen, si no hay problema, yo mismo me ofrezco para editar las vías.
Saludos, Santi.

PD: Suelo editar como Santi.
___
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] Fusión de municipios

[Diego García]

Por cierto, que he visto que alguien ha definido el landuse residential de
Cerdedo como outer de un multipolígono etiquetado como:

name=Cerdedo
place=county
population=Cerdedo

y como inner un trozo alrededor de la iglesia del pueblo. Como mínimo, me
parece una edición algo dudosa.



Un saludo,


El lun., 6 feb. 2017 a las 18:25, Diego García ()
escribió:

> Buenas tardes, Jesús.
>
> En realidad, si todo está ahora mismo bien hecho, es sencillo. Te aconsejo
> que utilices el JOSM para todo esto.
>
> La cabecera del nuevo municipio pasará a Cotobade, por lo que lo suyo es
> mantener la relación boundary de Cotobade. Entre los dos antiguos
> municipios sólo hay una vía (la 45341181), por lo que lo mejor es
> eliminarla, con lo que desaparecerá de las dos relaciones. A continuación
> edita la relación de Cotobade, añadiendo vías a partir del hueco dejado por
> la que has quitado, siguiendo el límite de Cerdedo (vías 45341272, 45341110
> y 45341195), y ponle a todas el rol outer. Cuando la hayas completado
> recuerda añadir el nodo de A Chan a la relación, con rol admin_centre
> (ahora mismo no hay ningún nodo, y debería haberlo). Y por supuesto, cambia
> el name de la relación por "Cerdedo-Cotobade".
>
> Por último, ya puedes eliminar la relación de Cerdedo. Respecto a la
> relación padre (Pontevedra), se seguirá manteniendo la jerarquía sin
> problemas, porque no estás eliminando la relación Cotobade, que ya es hija
> de la relación Pontevedra.
>
> Hazlo todo en un mismo changeset, sin tocar nada más en él, por si se
> rompe algo poder dar marcha atrás con facilidad. En el source de ese
> changeset lo suyo sería poner el enlace al BOE que recoge este cambio.
>
>
>
> Un saludo,
>
>
>
>
> El lun., 6 feb. 2017 a las 16:25, Jesús Lopez ()
> escribió:
>
> Buenas tardes. El pasado día 27 el Boletín Oficial del Estado [1] publicó
> de forma definitiva la aprobación de la fusión de los municipios de Cerdedo
> y Cotobade en un nuevo ayuntamiento que se denomina Cerdedo-Cotobade y el
> Instituto Nacional de Estadística [2] también se ha adaptado ya a la nueva
> denominación. En OSM aún figuran ambos de forma independiente y me gustaría
> consultaros como se puede abordar el proceso para reflejar este cambio.
> ¿Simplemente borramos la frontera entre ambos y adoptamos la nueva
> denominación o hay que tener en cuenta otras relaciones?. Espero vuestra
> ayuda,
>
> Saludos.
> Jesús
>
> ——
> [1] http://boe.es/boe/dias/2017/01/27/pdfs/BOE-A-2017-898.pdf
> [2] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
> ___
> 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] Fusión de municipios

[Diego García]

Buenas tardes, Jesús.

En realidad, si todo está ahora mismo bien hecho, es sencillo. Te aconsejo
que utilices el JOSM para todo esto.

La cabecera del nuevo municipio pasará a Cotobade, por lo que lo suyo es
mantener la relación boundary de Cotobade. Entre los dos antiguos
municipios sólo hay una vía (la 45341181), por lo que lo mejor es
eliminarla, con lo que desaparecerá de las dos relaciones. A continuación
edita la relación de Cotobade, añadiendo vías a partir del hueco dejado por
la que has quitado, siguiendo el límite de Cerdedo (vías 45341272, 45341110
y 45341195), y ponle a todas el rol outer. Cuando la hayas completado
recuerda añadir el nodo de A Chan a la relación, con rol admin_centre
(ahora mismo no hay ningún nodo, y debería haberlo). Y por supuesto, cambia
el name de la relación por "Cerdedo-Cotobade".

Por último, ya puedes eliminar la relación de Cerdedo. Respecto a la
relación padre (Pontevedra), se seguirá manteniendo la jerarquía sin
problemas, porque no estás eliminando la relación Cotobade, que ya es hija
de la relación Pontevedra.

Hazlo todo en un mismo changeset, sin tocar nada más en él, por si se rompe
algo poder dar marcha atrás con facilidad. En el source de ese changeset lo
suyo sería poner el enlace al BOE que recoge este cambio.



Un saludo,




El lun., 6 feb. 2017 a las 16:25, Jesús Lopez ()
escribió:

> Buenas tardes. El pasado día 27 el Boletín Oficial del Estado [1] publicó
> de forma definitiva la aprobación de la fusión de los municipios de Cerdedo
> y Cotobade en un nuevo ayuntamiento que se denomina Cerdedo-Cotobade y el
> Instituto Nacional de Estadística [2] también se ha adaptado ya a la nueva
> denominación. En OSM aún figuran ambos de forma independiente y me gustaría
> consultaros como se puede abordar el proceso para reflejar este cambio.
> ¿Simplemente borramos la frontera entre ambos y adoptamos la nueva
> denominación o hay que tener en cuenta otras relaciones?. Espero vuestra
> ayuda,
>
> Saludos.
> Jesús
>
> ——
> [1] http://boe.es/boe/dias/2017/01/27/pdfs/BOE-A-2017-898.pdf
> [2] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
> ___
> 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] Fusión de municipios

[Jesús Lopez]

Buenas tardes. El pasado día 27 el Boletín Oficial del Estado [1] publicó de 
forma definitiva la aprobación de la fusión de los municipios de Cerdedo y 
Cotobade en un nuevo ayuntamiento que se denomina Cerdedo-Cotobade y el 
Instituto Nacional de Estadística [2] también se ha adaptado ya a la nueva 
denominación. En OSM aún figuran ambos de forma independiente y me gustaría 
consultaros como se puede abordar el proceso para reflejar este cambio. 
¿Simplemente borramos la frontera entre ambos y adoptamos la nueva denominación 
o hay que tener en cuenta otras relaciones?. Espero vuestra ayuda,

Saludos.
Jesús

——
[1] http://boe.es/boe/dias/2017/01/27/pdfs/BOE-A-2017-898.pdf
[2] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] TRAZAS GPX

[se...@ono.com]

Gracias Emilio. No utilizo JOSM. Ya lo he conseguido a traves de Datos 
del mapa- archivo local. Pero sigo sin poder ver los tacks descagados en trazas 
GPS.

Saludos,

Sergio

 Mensaje original De: emilio.gomez.f...@gmail.com Fecha: 06/02/2017 
13:05 Para: , "Discusin en Espaol de 
OpenStreetMap" Asunto: Re: [Talk-es] TRAZAS GPX


Te aparece el archivo GPX en el panel de capas? Si te descargas 
cualquier otro datos en bruto GPX desde OSM puedes verlos? O solo 
ocurre con los tuyos?Por ltimo, mndanos una captura de pantalla 
de JOSM de la pestaa Preferencias -> Opciones de visualizacin 
-> Puntos GPS, a ver como lo tienes configurado.
Saludos.
Emilio Gmez

El 6 de febrero de 2017, 11:59, se...@ono.com  escribi:


Buenas, llevo 2 das sin poder ver las trazas GPS sobre la imagen del 
satlite con lo que no puedo mapear. Alguine sabe si pasa algo 
con las trazas GPS?.

 

Saludos,

Seraq
___ 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] TRAZAS GPX

[Emilio Gómez Fernández]

¿Te aparece el archivo GPX en el panel de capas?
¿Si te descargas cualquier otro datos en bruto GPX desde OSM puedes verlos?
¿O solo ocurre con los tuyos?
Por último, mándanos una captura de pantalla de JOSM de la pestaña
Preferencias -> Opciones de visualización -> Puntos GPS, a ver como lo
tienes configurado.

Saludos.

Emilio Gómez

El 6 de febrero de 2017, 11:59, se...@ono.com  escribió:

>
> Buenas, llevo 2 días sin poder ver las trazas GPS sobre la imagen del
> satélite con lo que no puedo mapear. ¿Alguine sabe si pasa algo con las
> trazas GPS?.
>
>
>
> Saludos,
>
> Seraq
>
> ___
> 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] Error en etiquetado de vértices geodésicos importados del IGN

[Jorge Sanz Sanfructuoso]

He añadido enlace desde
https://wiki.openstreetmap.org/wiki/ES:Limpieza_de_etiquetas a tu propuesta
para solucionar el error.
Estoy de acuerdo con la solución dada para corregir de manera automática el
error de la etiqueta "ele".
Yo tocaría primero esta etiqueta y las otras las discutiría aparte
posteriormente. Para ir solucionando errores.

Un saludo.

El lun., 6 feb. 2017 a las 10:20, Carlos Dávila ()
escribió:

El 06/02/17 a las 09:07, Agustin Diez Castillo escribió:
> En el wiki [1] pone colon donde debería poner semicolon.

Cambiado, gracias por la corrección. No sé porqué te pide confirmar el
correo.



___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-es] TRAZAS GPX

[se...@ono.com]

Buenas, llevo 2 das sin poder ver las trazas GPS sobre la imagen del 
satlite con lo que no puedo mapear. Alguine sabe si pasa algo 
con las trazas GPS?.

 

Saludos,

Seraq___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Error en etiquetado de vértices geodésicos importados del IGN

[Carlos Dávila]

El 06/02/17 a las 09:07, Agustin Diez Castillo escribió:

En el wiki [1] pone colon donde debería poner semicolon.


Cambiado, gracias por la corrección. No sé porqué te pide confirmar el 
correo.




___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Error en etiquetado de vértices geodésicos importados del IGN

[Agustin Diez Castillo]

Hola,
En el wiki [1] pone colon donde debería poner semicolon. He tratado de editarlo 
pero me dice que debo confirmar mi correo (no encuentro la manera de hacerlo).
https://wiki.openstreetmap.org/wiki/Automated_Edits/cdavila
El 5Feb, 2017, a las 8:53 PM, Diego García  escribió:
[1] https://wiki.openstreetmap.org/wiki/Automated_Edits/cdavila
> Por supuesto, hacerlo todo de golpe es mejor, teniendo en cuenta la cantidad 
> de nodos que hay. Eso no lo permite osmose.
> 
> Un saludo
> 
> 
> El dom., 5 feb. 2017 20:51, Carlos Dávila  escribió:
> Con osmose se pueden editar de golpe o hay que ir uno por uno? Yo ayer
> empecé a corregir en JOSM hasta que me dio por mirar los números y al
> ver la cantidad me pareció absurdo hacerlo a mano, cuando se puede hacer
> en menos de un minuto.
> A mi las etiquetas que hay tampoco me parece necesario eliminarlas
> 
> El 05/02/17 a las 20:35, Diego García escribió:
> >
> > Escribo desde el móvil, no me extenderé mucho.
> >
> > El error de la etiqueta ele lo detecta osmose, y se arregla fácilmente
> > desde allí. Los que están reparados alrededor de Huesca se han editado
> > de esa manera.
> >
> > El resto de etiquetas yo las conservaría. Los vértices pueden
> > pertenecer a distintas redes, y además tienen una referencia de forma
> > que se puede localizar información en IGN rápidamente, y que los
> > identifica. Normalmente estoy en contra de poner o mantener
> > información innecesaria o redundante, pero en este caso lo veo útil.
> >
> > Un saludo,
> >
> >
> > El dom., 5 feb. 2017 18:54, Carlos Dávila  > > escribió:
> >
> > Hola
> >
> > Ayer me di cuenta de que los vértices geodésicos que se importaron del
> > IGN en 2012 tienen varios errores en la etiqueta "ele". Por un
> > lado, se
> > usa la coma como separador decimal, lo que es contrario a la norma
> > general en OSM, y por otro tienen como unidad " m.". En OSM las
> > alturas,
> > como otras magnitudes, tienen una unidad predeterminada, metros en
> > este
> > caso, por lo que no se debe indicar la unidad salvo que sea
> > distinta de
> > la predeterminada, y en todo caso no debería llevar punto después
> > de la
> > m. Aunque algunos nodos ya han sido corregidos (una zona amplia
> > alrededor de Salamanca y Huesca básicamente), la gran mayoría siguen
> > igual que se importaron, concretamente 8.546 de 9.690.
> >
> > Estos errores se pueden corregir fácilmente con un poco de
> > buscar/reemplazar, pero como eso es una edición automatizada hay que
> > seguir las directrices indicadas en [1] y por eso lo comento aquí,
> > para
> > que se debata en la lista. He creado la página [2] en la wiki
> > describiendo el proceso propuesto.
> >
> > Otro error que había es que hay vértices que tienen dos valores en la
> > altura, uno entero y otro decimal, separados por punto y coma, por
> > ejemplo "1527;1527.12". Como esos eran pocos los he corregido a mano
> > dejando el valor más preciso, salvo un par de ellos en los que no
> > coinciden los dos valores.
> >
> > Como recientemente se comentó la posibilidad/conveniencia de eliminar
> > algunas etiquetas innecesarias de objetos importados, quizá se pudiera
> > aprovechar la ocasión para hacerlo. Estas son las etiquetas de la
> > importación que contienen los vértices geodésicos:
> >
> >   * ign:latitud (en mi opinión se debería mantener, el valor es más
> > preciso que el que tienen los objetos de OSM).
> >   * ign:longitud (idem).
> >   * ign:red
> >   * source:ref
> >   * ref: supongo que es una referencia interna usada por el IGN, no
> > utilizada de forma general.
> >
> > [1]https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
> >
> > [2]https://wiki.openstreetmap.org/wiki/Automated_Edits/cdavila
> >
> >
> 
> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es