[Talk-cl] Normas para etiquetado de caminos en OSM

[Andrés Pino Herrera]

Estoy de acuerdo en gran parte con Cristián. Es evidente que los objetivos
de Vialidad (la repartición del Estado, por eso con mayúscula) no tienen
por qué ser los mismos de OSM. Por ello viene lo que tiene que ver con el
objetivo específico de la etiqueta highway=*, que ya se dijo que es sólo
clasificar los caminos según lo que dice la Wiki. Debo insistir, eso sí,
que de partida la propuesta es interpretación de las categorías oficiales,
y las consideraciones que ya tiene, más las eventuales excepciones que se
podrían agregar, refuerzan que se trata de una adecuación de estos datos
 Por esto creo que desde el comienzo la categorización que hace la
Dirección de Vialidad es considerada como "fuente" y no como "autoridad"
para generar esta propuesta.

Qué bueno que se diga también que tiene que haber una cierta consistencia a
nivel internacional. En particular ese es uno de los motivos para proponer
etiquetar los caminos Nacionales con highway=trunk, lo que es una práctica
más extendida de lo que yo creía, junto con considerar una jerarquización
para las etiquetas highway=* y no características físicas, a pesar de que
al principio se me dijo que no había porqué tomar en cuenta lo que se
hiciera en otros lados.

Sobre que los criterios de Vialidad pueden variar, sí, es cierto, pero como
ya se ha dicho, la propuesta no es una adopción "a ciegas" de la
categorización oficial. En lo personal creo que lo vigente en este momento
es lo adecuado para basarse en ello y adoptar una categorización en OSM
(con modificaciones y consideraciones especiales). No lo era la
categorización anterior, que databa de los años 60, y que era mucho más
subjetiva e irregular que la actual. Es importante también que otras
modificaciones pudieran surgir de esta discusión.

Lo que nunca debe perderse de vista es, justamente, que OSM debe ser fiel a
la realidad, pero parece que lo difícil es ver cómo hacerlo. Se dijo antes
que no debía mapearse para el render, lo que es lógico porque ello puede
incurrir en malinterpretar etiquetas y alejarse de la realidad. Pero no veo
qué tan alejado de la realidad puede estar establecer una jerarquización
basada en la función territorial de los caminos, y con una cierta consistencia
interna entre sus directrices (una vez más, la categorización oficial es
sólo la base).

Tengo que insistir en que si nos vamos a preocupar de que un motor de
enrutamiento me va a generar una ruta que no es la "lógica", eso también es
como mapear "para el render". Para ello pongo un ejemplo concreto: para ir
desde la plaza de Yungay a la plaza de Monte Águila el camino "lógico" y
más usado es tomar la ruta Q-97-N hasta Cabrero, seguir por parte de la
Ruta 146 y luego tomar la ruta Q-60-O para entrar a Monte Águila, todos
pavimentados, con estándar muy bueno y con un límite de velocidad de 100
km/h hasta Cabrero, pero los dos enrutadores disponibles en la página de
OSM ([1], [2]) me hacen tomar el camino interior que pasa por la localidad
de Charrúa, en parte no pavimentado, tomando para ello 46 y 40 minutos
(dependiendo de cuál se utiliza). En cambio, si muevo el destino a la
Estación de Monte Águila, a tres cuadras de la plaza, sí siguen la ruta
descrita antes ([3], [4]), calculando un tiempo de viaje de 46 y 39 minutos
en el mismo orden. Esto demuestra que poco importa el valor de la etiqueta
highway=* del camino (y tal vez ni siquiera el de surface=*), ya que prima
el tiempo de viaje. Además ninguno de los caminos interiores tiene
etiquetadas las velocidades máximas ([5], [6], [7]) por lo que el motor
solo los asume (se puede ver moviendo origen y destino a un tramo de estos
caminos, que en promedio se considera 45-50 km/h). Se puede también jugar
moviendo el destino para un punto en que hayan varias alternativas, y se
comprueba que el cambio de una ruta por otra se produce en el punto en que
el tiempo de viaje es igual. De todas formas falta comprobar el efecto de
etiquetar con maxspeed=* las rutas, ya que los cambios no son considerados
automáticamente. Ahora, desconozco si hay otros motores que trabajen de
otra forma, ya que se puso como ejemplo un viaje de Casablanca a Melipilla
más atrás. Se da en ese caso que las dos alternativas comparadas son muy
similares en cuanto al tiempo de viaje que los enrutadores calculan.

En resumen, no creo que las opciones que para un caso dado entregue un
motor de enrutamiento sean un elemento tan relevante a considerar para
generar una clasificación. Casi me colgaron por decir que es "problema del
enrutador" el que las opciones que éste entregue no sean las óptimas, pero
también va en cada uno si le entrega completamente la tarea de navegación a
un algoritmo al momento de efectuar un desplazamiento. Si es por eso,
entonces para qué tenemos una página que renderiza un mapa con los datos de
OSM.


Saludos


[1] https://www.openstreetmap.org/directions?engine=osrm_car
&route=-37.1200%2C-72.0188%3B-37.0880%2C-72.4385
[2] https://www.openstreetmap.org/directions?engine=mapzen_c
ar&route=-37.1200%2C-72.0188%3B-37.0880%2C-72.4385

[3] https://www.openstreetmap.org/directions?engine=osrm_car
&route=-37.1200%2C-72.0188%3B-37.0855%2C-72.4418
[4] https://www.openstreetmap.org/directions?engine=mapzen_c
ar&route=-37.1200%2C-72.0188%3B-37.0855%2C-72.4418

[5] https://www.openstreetmap.org/way/366169189
[6] https://www.openstreetmap.org/way/84927018
[7] https://www.openstreetmap.org/way/350240234

Andrés Pino Herrera
Estudiante de Ingeniería Civil - Universidad de Concepción
Socio de la Asociación Chilena de Conservación del Patrimonio Ferroviario
apinohe en gmail.com - apinoh en udec.cl



El 3 de octubre de 2016, 18:27, Cristián Serpell <cristian en serpell.cl>
escribió:

> Lo malo de mi planteamiento es que habla de los objetivos pero no hay
> ninguna propuesta concreta...
>
> _______________________________________________
> Talk-cl mailing list
> Talk-cl en openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-cl/attachments/20161004/081cbca0/attachment-0001.html>