Mapa GPS

Respecto a las busquedas por nombre de calle…

Tengo un Garmin Nuvii 1450, la busqueda tiene dos pasos obligatorios: ciudad, nombre de calle.

Para cada ciudad, solo encuentra aquellas calles que tienen la etiqueta addr:city.
Es decir, las calles no “heredan” el poligono de la ciudad, por lo menos para el soft del GPS.

¿Que se puede hacer? Mi chica me vuelve loco con que el mapa “no anda” :stuck_out_tongue:

Consulto para no ir a poner el tag a todas las calles de Mendoza…
De paso: es que deberian tener todas las calles este tag???

Gracias. Saludos

Tendria que “heredar” la ciudad del poligono admin_level 8 que las contiene.
Proba con el ultimo mapa y postea algunas busquedas que no te funcionen para revisarlas.

Las calles no tendrian que tener el addr:city, es para las direcciones. Creo que para las calles en todo caso seria el tag “is_in:city”

Para Mendoza no encontre boundary con admin_level 8, asi que creo que ahi empieza la punta para solucionar el problema.
Sin los limites adecuados creo que solo coloca en la ciudad a las calles bien cercanas al nodo “place”.
Por experiencia propia te lo comento, porque en Montevideo pasaba lo mismo hasta que arme el limite.

No me queda claro como es la division administrativa y/o como tienen convenida la jerarquia de los limites, porque lo normal es que los niveles mayores contengan a los menores, en el caso de Mendoza no estaria pasando eso.
Si mi suposicion es cierta, Mendoza ciudad es la parte del Departamento Capital que queda al oeste del Parque San Martin. https://www.openstreetmap.org/relation/2204157
y el tema es que si pones un limite con 8 adentro quedarian todas las secciones que tienen ahora admin_level 6 y eso rompe la jerarquia, entonces no se si es que estan mal puestos los admin_level a las secciones y devieran ser admin_level mayor a 8, o es otro el problema.

En ese caso se podría poner las secciones con admin_level=9.

Ah, huuuy… La verdad tendria que haber revisado esta cuestion, pasa que esta hecho el trabajo de secciones/barrios y nunca pense que no estaria este limite, me fijo tambien.

Si, supones bien, la relacion que citas es la correspondiente: Ciudad de Mendoza, es un caso especial en el que es un departamento de una sola ciudad.

Respecto a is_in, tenia entendido (lei por ahi) que no se anima a usarlo por que redunda (por que los elementos heredan a sus padres :slight_smile: )

Luego publico unas busquedas y vemos casos… gracias!

Saludos.

Es como BsAs que es ciudad y distrito federal a la vez, y Vicente Lopez que es ciudad y partido. En ambos casos se hicieron 2 relaciones idénticas pero con diferente admin_level.

Estoy trabajando en una regla de estilo para re-indexar el nombre de las avenidas, lo cual permite por ejemplo buscar la “Avenida 9 de Julio” adicionalmente como “9 de Julio, Avenida”.

El tema de los apellidos es díficil, habrá que crear una regla para cada apellido compuesto, no le veo otra salida.

¿y con el tag sorting_name como se habló acá: http://forum.openstreetmap.org/viewtopic.php?id=26738?

Podria ser, pero creo que la intencion era hacerlo dentro de lo posible lo mas automatico e independiente de los tags y sin tener que cargarlos.
Quizas una mezcla de ambas soluciones sea lo mas adecuado.

  1. A las que tienen tag sorting_name, usarlo
  2. A las que no, usar el metodo heuristico (e irlo mejorando agregando las reglas que correspondan)

Otra opcion podria ser usar reglas equivalentes para ir cargando el sorting_name, aunque hacerlo de forma general me parece que es una linea muy finita entre hacerlo bien y caer en el “tagging for the renderer”

Caso etiqueta “sorting_name”, me parece el camino a seguir.

Como en la especificacion de epub, que usa muchisimo para los autores (precisamente problema similar!), y para aquellos titulos con el,la,las,etc

Tal vez se pueda cargar sólo a las calles con nombres ya conocidos: Lavalle, Sarmiento, Saavedra… y demás próceres.

Hasta donde sé, mkgmap no hace uso de la etiqueta sorting_name, al menos busque en su código fuente y la no encontré.

Muralito, tenes idea si mkgmap permite usar la etiqueta sorting_name, yo estuve buscando información al respecto y no he encontrado nada. Por otro lado recuerdo haber leído hace tiempo en la lista de desarrollo de mkgmap a Steve Ratcliffe en una respuesta a Carlos Dávida hablar de generar un índice mas potente para mkgmap que permitiría resolver el problema de las búsquedas. Incluso había una rama testing para ello, pero no se en que quedó. Voy a seguir investigando más al respecto.

Acabo de modificar el TYP eliminando los POIs con estilo Mapnik, de este modo los navegadores GPS utilizarán los que traen por defecto. Por otro lado para Qlandkartegt se utiliza un TYP que si los incluye.

Esta modificación será publicada el próximo fin de semana.

No, no he visto nada.
En principio supuse que agregarlo al --name-tag-list podria ser, pero en realidad es otra cosa, porque no queremos que elija uno en favor del otro, sino que quede con el que tiene que ser y el otro lo use para el indice.

Pensandolo un poco mas, si se logra encontrar, la misma solucion podria tambien usarse para indizar los alt_name o los official_name, asi se pueden encontrar en el GPS.

Dentro del tema, recien vi los scripts (viejos) tuyos, y por ejemplo, le agregaria el name:es al parametro name-tag-list para preferir el nombre en español si es que lo tiene. En la frontera con Brasil hay algunos casos de estos.

Martin:

En Chile tienen definidos los admin_level=8 como las comunas. Las ciudades no tienen definido nada (al menos en http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative))
¿Has visto eso como afecta las busquedas y otras cuestiones?
¿Al estar distinto que el resto de los paises, le haces algun tratamiento diferente?

Anduve haciendo busquedas en el Garmin (Nuvii 1450) para sacar conclusiones: encuentra aquellas calles en el que algun POI le haga referencia.
Por ejemplo: si busco “Mza(ciudad); San Martin (calle)” , y unos POIs tienen “addr:street=Av. San Martin” y otro “Avenida San Martin”, estos nombres seran el resultado

Otro ej.: Buscar “Mza-calle Necochea”, (supongamos) no hay ningun POI con etiqueta “addr:street=Necochea”, entonces aunque la calle tenga is_in:city=Mendoza, no da resultados!

Tambien nunca anduvo la busqueda por cruce de calles : ciudad; calle 1; calle2 …

A mi chica le compre un cel/android, le cargue OSMAnd y va joya :-/

Re-valoro tooodo el esfuerzo que se hace con el mapa!

Mi queja es que Garmin es una mier#% para callejear!

Saludos.

Mi impresion es otra, el OSMAnd no me termina de convencer y no me acostumbro, y el Garmin anda volando (ya sea con el mapa de OSM de Martin o con otros), encuentro todo lo que busco, rutea mejor, etc.
Antes en algunos casos pasaba como a vos, pero esos problemas se solucionaron definiendo bien los limites de nivel 8.

El problema que se ha mantenido en el mapa de Martin (y en otros compilados por el mkgmap) es el ruteo de largas distancias, lo cual es un tema menor para mi porque le agrego los waypoint intermedios de las estaciones en las que planeo cargar nafta y listo. Esto pasa no solo en el Nuvi sino tambien en el BaseCamp.

He probado con mapas de JUL y de OCT, en estos dias pruebo el ultimooo de http://www.i-nis.com.ar/osm/garmin
… y comento.

@muralito : me siento honrado que me citaste completo , no hacia falta! :wink:
Que modelo tenes?
Cual mapa bajas (URL)?
Gracias!

Saludos.
edit: ortografia

Eso de que callejear es una mierda en Garmin lo vi también en los foros de Mapear, les interesa 3 pepinos facilitarles la vida a los usuarios comunes que hacen proyectos para sostener mapas colaborativos. Y eso que ellos usan las herramientas que Garmin provee, no conversores hechos por terceros.