Mapa GPS

Martin:

La semana pasada hice una reclasificacion grande de las rutas de Uruguay, y lo que note es que en esta ultima version del mapa, es como si en los zooms mas lejanos no se hubiera actualizado nada, aunque en el zoom mas cercano si estan correctamente actualizadas.
Tambien hay cosas al hacer zoom acercando y alejando que se ven inconsistentes. Por ejemplo, rutas trunks que no se muestran y si se muestran primary al alejar, o del lado Argentino, rutas que se muestran, p. ej .la 9, pero al mismo zoom que muestra la ruta muestra la autopista AU9, y en el zoom siguiente si muestra las dos. Con la 9 tambien pasa en el tramo BsAs-Rosario que se muestra como verde (trunk) y recien al acercarse lo muestra como azul (motorway)

Tambien dezaparece la linea costera del Rio de la Plata y toda costa la oceanica, ademas de los limites maritimos.

¿Hay algo en como se hace la compilacion que lo explique?

Com tema extra, note que en algunos casos ruteaba usando el ferry de Buquebus, pero en esos casos le ponia como demora al cruce 6 horas 37 min, cuando con el barco lento lleva unas 3 horas, y con el rapido como 1 hora.
¿Esto donde se ajusta?
¿Si le pongo el tag duration lo tiene en cuenta?
Si lo toma, ¿Cual duracion hay que poner?, ¿1 hora, o 3 horas, o ambas armando relaciones de rutas distintas para el barco rapido y el lento?

Sobre lo del mensaje anterior y los zooms, primero pense que podia ser por el cache del Base Camp, pero lo limpie y no era eso.

Un detalle lindo es que empezaron a mostrarse los lomos de burros con el signo vial correspondiente.

Con respecto a otros temas anteriores, como el de las estimaciones de tiempo Rosario-Cordoba, se corrigieron con el tag maxspeed en toda la autopista.
El tema que vi fue que si en el Nuvi se hace la simulacion Rosario-Cordoba e el Nuvi, el velocimetro muestra 253 Km/h.

Me parece que el tiempo real está más cerca de las 6 horas, ya que hay que entrar el auto al barco, hacer la cola en el check-in, luego la cola de migraciones, y en destino te revisan (aunque algo “light” la última vez que fui) el baúl. Si el auto está estacionado en la parte de atrás del barco podés tardar como media hora más en salir del puerto.

Hola Muralito, estoy trabajando en el TYP y los estilos (sobre todo los zoom). En el TYP se crearon nuevos POIs, entre ellos los del lomo de burro que mencionás. Me falta ver alguno de los temas que estás mencionando, pero poco a poco los iré viendo.

Martín, en este hilo http://forum.openstreetmap.org/viewtopic.php?id=21502 hice un planteo sobre un problema de ruteo con los valores predeterminados del mkgmap. ¿Cual es tu opinión?

Gracias por la respuesta al anterior #209. Lo probaré en la nueva versión.

Con respecto a los POIs de alerta, los empece a probar en circulacion y me surgio una duda.
Por ejemplo este cartel de “Pare”, http://www.openstreetmap.org/browse/node/2356516221
salta la alerta de “a 200 metros”, cuando la situacion es que se viene circulando por la avenida, y ese cartel de pare esta para los que vienen por la transversal, y en principio no deberia advertir nada.
Lo mismo pasa con este http://www.openstreetmap.org/browse/node/1986991563 y con otros mas que hay en la zona, que se produce una “lluvia de alertas” porque hay al menos 6 “Pare” cercanos.

¿Se podra hacer que los “Pare” afecten solo la via donde se esta circulando, o algo similar?

Te contesté en http://forum.openstreetmap.org/viewtopic.php?pid=344081#p344081

Posible problema de ruteo (es puntual).

En esta ultima version, 20130630, rechequeando las rutas fijas (las que uso como casos de prueba casi siempre), viendo como variaban me encontre con un problema de ruteo que no le encuentro explicacion.

Al calcular la ruta de Montevideo a Minas, pueden haber algunas variantes al principio, pero siempre se llega por la ruta 8.
Lo que encontre fue que calculando ruta de Montevideo a puntos sobre la ruta 8, si el punto esta antes de este http://www.openstreetmap.org/browse/node/1870876625 la ruta se calcula bien. Unos 103 km segun mi inicio.
Si corremos el destino unos metros mas alla del punto referido, como que no hay continuidad en ese punto y calcula la ruta dando una vuelta grande, de 263km.

Los objetos en OSM no han sido tocados en meses, y en ese punto la via es continua y no hay barrier.

Tambien hay cosas raras por rutas que tendrian que pasar rutear por una trunk y lo rutea por una primary.
Manda por aca http://www.openstreetmap.org/browse/way/164082693
y debiera mandar por http://www.openstreetmap.org/browse/way/78113905
(Pongo solo un tramo de cada una pero me refiero al total de ambas)

La primary es zona urbana y tiene maxspeed=60. La trunk no tiene maxspeed establecido.
¿Vendra por ahi el problema?

Suponiendo que, en el último ejemplo, no está seteado en las opciones del GPS “Ir por la ruta más corta” en vez de “Ir por la ruta más rápida”…

Habría que setearle el valor maxspeed a la que es “trunk”, porque puede venir por ahí el problema, aunque debería preferir una “trunk” antes que una “primary”. Por otro lado revisá que no esté pasando lo que dice Tuentibiker

Nunca uso “camino mas corto” salvo que especificamente quiera probar algo. Uso o “Via rapida” o “Ahorro de combustible”, generalmente mas este ultimo que es el que me da mejores resultados.

Estoy de acuerdo, seteando el maxspeed haría que mkgmap la clasifique distinto y que el Garmin la prefiera.
El tema es que para setearlo hay que setearlo bien, y para eso hay que conocerlo y/o relevarlo, sino (por ahora) prefiero no setearlo. Tiene tramos que son de 110, tramos de 90, y algunos sectores de empalmes, donde en vez de hacer la obra publica que corresponde desvian, la ruta nacional pierde preferencia con respecto al que la cruza,y bajan la velocidad.

Lo que me preocupa es que avanzar en el mapeo con los maxspeed correctos donde corresponde, no deberia provocar un problema como lo está haciendo.
¿Saben si para el ruteo usa solo el road_speed o tambien el road_class?
¿Puede ser que el problema viene de que segun la compilacion toma ambas vias como misma road_speed y por eso usa el mas corto?

highway=primary & (maxspeed>=60 & maxspeed<80) [0x03 road_class=3 road_speed=3 resolution 19]

highway=trunk & maxspeed!=* [0x02 road_class=4 road_speed=3 resolution 18]

PD: Tu pagina esta tirando un codigo php en vez de mostrarse.

Me parece que la version actual no esta resultando confiable en cuanto a los ruteos que ofrece.
Desde S34 21.379 W57 06.121
Hasta S34 13.063 W57 20.329 lo calcula bien.

Moviendo el origen hacia atras,
Desde S34 21.389 W57 06.039 lo sigue calculando bien.

Pero si el origen lo movemos hacia atras unos metros por esa misma ruta,
Desde S34 21.390 W57 06.032 ya no rutea.

o inclusive mas cerca
Desde S34 21.389 W57 06.037 tampoco rutea

Esta funcionando raro. No encuentro el porque.

Despues de escribir lo anterior, probe con otros mapas basados en OSM y tienen el mismo problema. El de Lambertus y el de Alternativas Libres y otro compilado por mi hace ya meses en base al uruguay.pbf y todos tienen el mismo problema con esos puntos.

Todo esto con el BaseCamp, y el mapa cargado en el nuvi, y los otros mapas que menciono cargados tanto en el nuvi como registrados en la PC windows.

Martin, ¿podras confirmarme la fecha de los datos de OSM que usaste para esta version?

Despues, hay otros problemitas con el zoom, que no es consistente. Por ejemplo, si me alejo, me muestra la RN9 pero no la AU9, cuando la idea intuitiva es que si te alejas ves lo mas importante, dejando de ver rutas de menor categoria, ¿no?
Eso ultimo de los zooms inconsistentes, es propio de esta compilacion, no pasa con los otros mapas basados en OSM.

PD: A los administradores del foro: ¿Se puede o convendrá poner un subforo para estos temas de la compilacion de mapas para Garmin, asi va quedando algo mas organizado, porque en este hilo se están mezclando muchos temas independientes?

Mártin, por los criterios alimenticios de esta zona del mundo, y para el buen aprovechamiento de los carnivoros, me parece conveniente tratar de categorizad los lugares con actividad principal de parrila en la categoria especifica
“Steak or Grill” documentada en http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types , con lo cual en el nuvi en español aparecerian como “Carnes o Parrilladas” (Aunque no tengo claro cual seria el motivo de distincion entre este y el “Barbacoa”)

Para eso, ¿como deberiamos etiquetar los restaurantes? ¿se precisan cambios en los estilos de tu compilacion?
¿Podria ser poniendole un cuisine=steak house?
¿El cuisine puede ser multivaluado?

Martin:

¿Se podra agregar al archivo de estilo de lineas lo siguiente?
amenity=restaurant & cuisine=steak_house [0x2a0c resolution 24]
para categorizar especificamente los restaurantes de parrilla.

Ademas, las areas verdes, canteros y separadores viales, que son poligonos con landuse=grass
segun http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types
¿se podria probar de poner como 0x1b 0x1c o 0x1d?
O sea en el inc/landuse_polygons, por ejemplo
landuse=grass [0x1b resolution 20] (la el garmin type y la resolucion podrian ser diferentes)

Martin:

Por lo que estuve leyendo, la disminucion relativa del road_class en algunos casos, puede estar haciendo imposible el calculo de rutas en largas distancias, que usa basicamente las rutas principales.
Por ejemplo, en el estilo de lineas, las trunk estan casi todas como road_class=4, con alguna excepcion como esta.
highway=trunk & (maxspeed<40) [0x03 road_class=3 road_speed=1 resolution 18]

Ademas, no tengo claro si en el caso de las motorway_link y trunk_link tambien les corresponderia un road_class=4 por el mismo motivo.

Estoy agregando este y otros POIs. El domingo próximo saldra el mapa con estas características.

Esto último lo voy a investigar e implementar si es factible.

Está mal el estilo, todas las trunk pavimentadas deben ser del mismo tipo. Ya corregí y le asigné road_class=4.

Gracias por reportar el problema.

No hay porque.

Cuando vos decis en el changelog del 2013-06-02:
“Nuevo mapa general para mostrar áreas en baja resolución a nivel de países y continentes.”

¿te referis al uso del overview-levels de http://www.mkgmap.org.uk/news/2013/05/31/now-mkgmap-has-a-real-overview-map ?

Siendo asi, entiendo que el ultimo mkgmap de 05_mkgarminmap.sh que junta los .img solo esta teniendo en cuenta los 980*.img y el mapnik_ar.TYP, pero no lista los ovm_*.img,
asi no los estaria incluyendo en el .img final.
Tampoco lo he visto el mapa general en el nuvi, pero no tengo claro que despliegue esperar asi que estoy dudando.

Martin:

¿Podras pegarle una revisada a algunos ruteos? Porque a esta ultima version la veo como un retroceso.

Por ejemplo, de Montevideo a San Jose, tendria que ir por http://osrm.at/4zg opcion A (1 y 3) y lo manda por la opcion B (5 y 11).
En la practica la diferencia es peor que en los papeles. Una ruta es mayormente doble via y la otra no, aunque las velocidades maximas sean iguales, los promedios son mucho mejores en la doble via por la fluidez del transito.
¿Se puede penalizar una ruta por eso o priorizar la otra?

Tampoco es capaz de calcular la ruta entre Montevideo y Colonia del Sacramento. http://osrm.at/4zj o entre Montevideo y Rosario (depto de Colonia) aun mas cerca.
Toma como rutas invisibles, poligonales con largos tramos rectos.
Decime si te sirven capturas de pantalla del Nuvi para ilustrarte esto o lo pudiste reproducir.

Lo de los POIs de parrillada quedo bien. Ahora solo falta etiquetarlos bien en OSM.