Pues con el tema de nombrar las direcciones por locales me habéis recordado
que, por lo menos en Madrid, los locales que dan a la calle sí tienen la
obligación de tener un código de identificación para su localización. Son
código que van de 10 en 10, del tipo L-10, L-20, etc. y los comercios
tienen la obligación de tener la identificación en la puerta de manera
visible. Se puede ver la información en
https://sede.madrid.es/portal/site/tramites/menuitem.1f3361415fda829be152e15284f1a5a0/?vgnextoid=2f5c57299115c410VgnVCM2000000c205a0aRCRD&vgnextchannel=37f637c190180210VgnVCM100000c90da8c0RCRD

No sé si esto es exclusivo de Madrid o es obligatorio en toda España. Para
Madrid, en
http://www.madrid.es/portales/munimadrid/es/Inicio/El-Ayuntamiento/Estadistica/Censo-de-locales/Censo-de-Locales?vgnextfmt=default&vgnextoid=4ba708e2a77bd210VgnVCM2000000c205a0aRCRD&vgnextchannel=2bd6eea8e3e5d210VgnVCM1000000b205a0aRCRD
existe un visualizador que permite conocer el código de cada local.

Entiendo que si añadimos la etiqueta addr:door se podría dar por cierto que
si varios nodos tienen el mismo código de portal para saber cual es el
principal se utilizaría el siguiente algoritmo:

   1. Se coge como principal el nodo con entrance:main
   2. Si no hay ninguna entrada principal se coge nodo que no tenga
   informado el atributo addr:door

Para que esto fuese útil a nivel mundial habría que hacer la propuesta y
que fuese aprobada.

¿Qué os parece?




El 8 de febrero de 2016, 20:15, Diego García <dgerv...@gmail.com> escribió:

> Coincidimos en descartar cosas como "local 1", "local 2". No se
> corresponde a la realidad, y es un dato que, en la práctica, sería casi
> imposible de conseguir.
>
> Veo que está aprobado addr:floor, hoy cambiaré alguno y mañana comprobaré
> si osmose sigue con sus números de portal repetidos. De momento, veo que
> nominatim lo descarta y no lo utiliza en la búsqueda, aunque saca todos los
> resultados bien para ese número de calle.
>
>
> Saludos,
>
> El 8 de febrero de 2016, 19:57, Jorge Sanz Sanfructuoso <sanc...@gmail.com
> > escribió:
>
>>
>>
>> El lun., 8 feb. 2016 a las 18:56, Diego García (<dgerv...@gmail.com>)
>> escribió:
>>
>>> Es cierto que la solución parece estar lejos. Por mi parte, lo venía
>>> observando desde no hace muchos meses, debido a que osmose muestra como
>>> errores los números duplicados que se producen, y justo este fin de semana
>>> se me ocurrió una posible solución, que decidí probar:
>>>
>>> La dirección real de una tienda que está en los bajos de un edificio, no
>>> es el número de portal de ese edificio, sino algo así como "número 2,
>>> bajo". De este modo, coloco el punto con la dirección del portal donde
>>> corresponde, a su entrada, y en el tag addr:housenumber de la tienda
>>> etiqueto el número y le añado "bajo". El tag lo admite (osmose daría error
>>> si dicho tag no comienza por un número), y leida la dirección completa es
>>> totalmente correcta: Avenida de los Pirineos 15, bajo. Y el wiki parece que
>>> no se opone a ello, aunque mi inglés es lamentable.
>>>
>>
>> Existe "addr:floor" que se supone que es para poner la planta, o también
>> "level". La primera esta como propuesta pero no se cual sera mas adecuada.
>> "level" es más usada. No creo que la tengan en cuenta los diferentes
>> programas para hacer la dirección. Habría que comprobarlo.
>>
>>>
>>> Como en Huesca tenemos la mayoría de tiendas y comercios sin poner su
>>> dirección, he aprovechado para probarlo este fin de semana en los que sí la
>>> tenían y además estaban reportando el error de numeración duplicada de
>>> osmose. No son muchas, unas veinte, por lo que en caso de chapuza lo tengo
>>> fácil para dar marcha atrás. Con nominatim funciona, y osmose no reporta
>>> error:
>>>
>>> - Si busco el nombre de la tienda, sale, y me ofrece su dirección
>>> completa y real. Por ejemplo "restaurante martín viejo, huesca", daría
>>> "Restaurante Martín Viejo, 15 bajo, Avenida de los Pirineos, Barrio de
>>> Santiago, Huesca, Aragón, 22004, España"
>>> <http://www.openstreetmap.org/node/2538194434>
>>> - Si busco la dirección, nominatim me ofrece como soluciones el propio
>>> portal y los comercios que coinciden: "avenida de los pirineos, 15, huesca"
>>> saca el mismo resultado de antes, y además añade "Casa 15, Avenida de los
>>> Pirineos, Barrio de Santiago, Huesca, Aragón, 22004, España"
>>>
>>> Como extrapolación, un comercio situado en la planta primera del número
>>> siete (por poner un ejemplo), se etiquetaría como "7 piso 1", y seguiría
>>> funcionando de la misma manera.
>>>
>>> La segunda parte viene cuando hay varios comercios en un mismo edificio.
>>> Aquí le he echado algo de imaginación, y he etiquetado como "local 1",
>>> "local 2", etc. Lo cierto es que son direcciones reales (dentro de un mismo
>>> edificio los locales comerciales suelen numerar de esa forma), pero de no
>>> ser que entremos a preguntar al comerciante, desde la calle no vemos esa
>>> información. En nominatim sigue funcionando bien: "avenida de monreal, 7,
>>> huesca"
>>>
>>
>> Lo de local 1, local 2 para una zona comercial si lo veo pero a pie de
>> calle puffff, ni el que tiene el local lo sabe. Tampoco se usa cuando se
>> mandan cartas, se pone el numero el nombre del comercio y si acaso que es
>> el bajo. El número de local es raro, por lo mismo. Al final toca
>> inventarselo cosa que descarto hacer. Además para esto se usa "addr:door"
>> si no me equivoco.
>>
>>>
>>> En general, como solución no me parece mala, aunque no me acaba de
>>> gustar por dos motivos: el tag addr:housenumber ¿debe limitarse al número
>>> de portal, o está permitida la extensión de su significado a más datos,
>>> como el número de planta? ¿habría que tirar del tag addr:place?. Y en
>>> segundo lugar, está lo de los multiples comercios en el mismo número, que
>>> no deja de ser una dirección "inventada", a no ser que entre tienda por
>>> tienda a preguntar el número de local.
>>>
>>
>> Yo entiendo que se limita al número del portal pero tampoco está claro.
>> Podría darse el uso que sugieres, habría que consultarlo a toda la
>> comunidad de OSM.
>> Al final el problema de Osmand creo que no se soluciona porque seguirán
>> saliendo todos los números pero uno como 15 y otro como 15 bajo. Parece más
>> bonito pero a la hora de la verdad no cambia mucho, sigues teniendo
>> información doble e inútil. A lo mejor sería más correcto buscar que Osmand
>> trate los datos de otra manera y no cambiar la información de la base de
>> datos. Que si esta el numero etiquetado como entrada=main coja ese número y
>> descarten el resto por ejemplo.
>>
>> addr:door y addr:floor no se si los tienen en cuenta nominatim y osmand,
>> habría que comprobarlo. Tampoco los he usado. Los tenemos que añadir a la
>> wiki en español que no salen por falta de actualización de la wiki.
>>
>>
>>>
>>> Un cordial saludo,
>>>
>>>
>>> El lun., 8 feb. 2016 a las 12:18, Jorge Sanz Sanfructuoso (<
>>> sanc...@gmail.com>) escribió:
>>>
>>>> Es otra de las cosas que no hay consenso. Nominatim si lo tiene en
>>>> cuenta y si una tienda esta dentro de un edificio que tiene puesto el área
>>>> del edificio la numeración la coge del edificio ( si la tienda no tiene
>>>> numeración propia claro).
>>>> Pero claro para eso se tendría que poner numeración al edificio y no a
>>>> la entrada del edificio. Cosa que tampoco hay consenso, pero por aquí la
>>>> mayoría parece que prefiere ponerlo a la entrada y no al área del edificio.
>>>> Yo actualmente los estoy poniendo a la entrada normalmente.
>>>>
>>>> Es por una de las cosas que yo defiendo más el método de etiquetar la
>>>> numeración en el área del edificio cuando sea posible. Igualmente tampoco
>>>> es perfecto porque un edificio si da para 3 calles en 2 calles te toca
>>>> poner igualmente la numeración de los locales si o si. También hay casos
>>>> que el edificio tiene por ejemplo numeración del 10-20 y una tienda coge el
>>>> número 10, otro el 16 y otro el 20 por lo que estás en las mismas. No hay
>>>> una solución que arregle todos los casos y veo difícil que exista.
>>>>
>>>> Resumiendo, si el área del edificio tiene numeración por lo menos con
>>>> nominatim no hace falta ponerlo en la tienda, habría que comprobarlo con
>>>> otros programas. Si no es así hay que ponerle numeración a la tienda si o
>>>> si y pasaría lo que has comentado.
>>>>
>>>> El lun., 8 feb. 2016 a las 11:55, Alejandro Moreno Calvo (<
>>>> almo...@gmail.com>) escribió:
>>>>
>>>>> Reabro este tema ya que me ha surgido la duda de como mapear edificios
>>>>> que tienen tiendas todos con el mismo número de portal. Es decir, tengo un
>>>>> edificio con varios nodos, uno corresponde a la entrada a las viviendas y
>>>>> los otros de entradas a tiendas que hay dentro del edificio.
>>>>> Si se pone el número de portal al edificio, ¿se asume que los nodos de
>>>>> ese edificio tienen ese número de portal?
>>>>> Lo que he visto hasta ahora en Madrid es edificios con esta casuística
>>>>> tienen repetido por cada nodo el número de portal y el "problema" de esto
>>>>> es que en programas como Osmand te sale cada número de portal repetido n
>>>>> veces, cosas que queda bastante fea.
>>>>>
>>>>> El 18 de diciembre de 2015, 16:01, Rodrigo Rega <rodrigor...@gmail.com
>>>>> > escribió:
>>>>>
>>>>>>
>>>>>> El 18 de diciembre de 2015, 15:53, Carlos Cabezas <r0u...@r0uzic.net>
>>>>>> escribió:
>>>>>>
>>>>>>> Voto por lo mismo, en el peor caso podemos dejar los polígonos con
>>>>>>> un número pero sería útil empezar a añadir un nodo del área en la 
>>>>>>> ubicación
>>>>>>> de la portería e ir retirando los nodos sueltos. ¿Qué opináis el resto?
>>>>>>
>>>>>>
>>>>>> Yo también creo que la opción buena es poner el número en el nodo que
>>>>>> tiene la etiqueta de entrada al edificio. En las importaciones de 
>>>>>> Catastro
>>>>>> que he hecho he eliminado los nodos sueltos.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.rodrigorega.es
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> --
>>>> 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 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 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

Responder a