On Saturday 11 July 2009 19:46:43 Francisco Herrero wrote:
> 2009/7/11 Francisco Herrero <[email protected]>
>
> > Se acaban de generar 2 threads sobre una discución interesante asi que
> > decidi agruparlos en esta respuesta.
> >
> > 2009/7/11 Matias D'Ambrosio <[email protected]>
> >
> >>   Los ways son una lista ordenada de nodos, y tienen cero o mas tags.
> >> Nuestro
> >> concepto de calle raramente coincide uno a uno con los ways,
> >> generalmente una
> >> calle esta formado por varios ways.
> >
> > Es un buen punto, a tener en cuenta. Nosotros estubimos usando la
> > política de poner el mismo name cuando se trataba de la misma calle.
> > Muchas veces nos resulto dificil distinguir una calle de otra ya que lo
> > unico que lo define es su nombre, y muchas veces no se sabe si dos calles
> > disconexas son la misma o no. Tal vez necesitemos refinar esa información
> >
 Especialmente porque a veces el nombre de la calle no esta muy claro. Aca no 
es nada raro que haya diferencias en el nombre de una calle entre una esquina 
y otra (Hernande, J. Hernandez, Jose Hernandez, etc), lo que hace que calles 
que no tienen nada que ver tengan el 'mismo' nombre (Hernandez debe haber un 
par, me imagino).

> >>  Creo que el consenso es usar una relacion que contenga los ways que
> >> corresponden a la calle y los nodos miembros de los ways. Cada role
> >> tendria
> >> asignada una altura, y para alturas intermedias se podria hacer una
> >> interpolacion (esto permite tener cuadras de largo variable).
> >
> > Excelente! Me parece superadora tu idea. Con respecto a la interpolación
> > justamente estoy pensando en un esquema flexible para mis algoritmos de
> > busqueda, que probablemente los libere en poco tiempo (app de geodjango).
 Excelente!

> > La idea nuestra es apostar a un crecimiento paulatino de la información,
> > y mientras tanto seguir ofreciendo el servicio de búsqueda. Actualmente
> > no contamos con todas las alturas por esquina sino unas cuantas, con lo
> > que la idea de buscar calles por altura interpolando es mas flexible
> > ahun, buscando alturas por aproximacion y con un radio de error.
 Si, el sistema tiene que ser flexible ante la falta de datos, especialmente 
considerando que la mayoria de Argentina esta sin mapear.

> >>  La relacion tendria que tener al menos un tag diciendo que tipo de
> >> relacion
> >> es, si los pares e impares van a lados diferentes (y de que lado), y
> >> puede que
> >> algun otro dato.
> >
> > Sobre asociar muchos ways me parece que puede generar complicaciones, ya
> > que una misma calle suele cambiar sus cualidades, como pasar de doble
> > mano a mano simple o cambiar la numeracion (no estoy seguro de este
> > caso).
 La mano no afecta a la numeracion, y nunca vi que cambie la numeracion sin 
cambiar el nombre de la calle. Creo que lo normale en Argentina es tener 4 
calles que nace en la plaza central y de ellas nacen el resto de las calles, o 
me equivoco? De todas maneras, 'calle' es un concepto medio nebuloso, de 
ultima nos restringimos a ways, pero creo que no hace falta.

> > Tiro una propuesta y lo seguimos afinando:
> > Que sea una relacion que contenga un way y points, con la altura en los
> > role
> >
> > Tags de la relacion:
> > type=door-numbers
> >
> > distribution=
> >  * even-right: Significa que, tomando el sentido del way (el sentido del
> > vector, no de la calle), los pares estan a la derecha, y los impares a la
> > izquierda.
> >  * even-left: El caso contrario
> >  * unknow: No se save ahun. Seria como cuando no se sabe el sentido de la
> > calle.
> > Tal vez faltaria algun caso en el que no se puede aplicar una regla.
> >
 Hice una pagina en la wiki para que podamos poner las propuestas y agregar 
comentarios directamente (especialmente pros y contras).
 Puse una propuesta casi igual a la tuya, salvo que use 'street_number' como 
tipo de relacion (door number no me suena bien, y ademas esta relacion se 
aplica a la calle, no a las puertas, eso seria mas de Karlsruhe). No puse el 
unknown, si no hay tag de como va la secuencia, es desconocido :-) Y tambien 
es diferente la manera de definir izquierda y derecha, no me gusta lo de usar 
la direccion del vector, que afecta demasiadas cosas. Agregue 'mixed' en caso 
de que no se separen pares e impares. Y el uso de un scheme permite agregar 
otros sistemas en el futuro.

http://wiki.openstreetmap.org/wiki/Argentina:Altura_de_las_Calles

> > > no se , pero tambien deben pensar en que algun dia querremos hecer el
> >
> > render de esa info .Se puede usar Mapnik o osmarender , en el primero hay
> > un proceso de convertir los datos de formato openstreetmap a bases de
> > postgres . En esa conversion podemos influir porque los datos que deja en
> > las bases estan orientados al render asi que modificando las bases
> > postgres antes del render resolveria las cosas . Para el otro hay que
> > investigar mas.
> >
> > > Ademas seria deseable que para el render en zooms grandes se vean todos
> >
> > los numeros de alturas y en otros mas pequeños las alturas de los miles o
> > algo asi .
> >
 Creo que primero tenemos que decidir bien el formato de los datos, y despues 
vemos el render, que no es nada simple. Ademas si tenemos un sistema en uso, 
es mucho mas facil que nos den bolilla en el resto de OSM.

_______________________________________________
Talk-ar mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ar

Responder a