[Talk-it-piemonte] R: Caricati hotel

Mer 2 Feb 2022 18:41:57 UTC

Scusate, scrivendo dei 40 negozi con lo stesso indirizzo, potete pensare
che io sia per la duplicazione.
Non è così, come si capisce dalla conclusione del mio post:
"Concludendo: l'ingresso ad un edificio e l'indirizzo di un POI sono due
cose diverse, e probabilmente sarebbe giusto avere due tag diversi; in loro
mancanza, considero più importante qualificare l'indirizzo del POI rispetto
al suo ingresso."
Il problema dei negozi nei centri commerciali sarebbe risolto tenendo conto
dell'indirizzo che ha scritto prima Andrea, che inizia con "Sig. Rossi":
per avere l'univocità bisognerebbe esistesse il concetto di "campo
composto" nel db OSM, dove l'indirizzo "completo" di un POI viene composto
concatenando il name con l'indirizzo... ma pazienza, non so se Postgres
implementi una simile feature e - se anche fosse - chissà mai se e quando
OSM la utilizzerebbe.
Sicuramente, mi rifiuto di introdurre l'ennesima duplicazione proponendo di
ripetere il name anche nell'indirizzo!

Quello che non mi piace è che un bar, o una pizzeria, che sono per es. al
pianoterra di un condominio, siano mappati (giustamente) come nodi, e
quindi insieme al name trovi il telefono, l'indirizzo, e quant'altro. Per
un albergo invece non si potrebbe avere la stessa funzionalità, perché
l'indirizzo deve essere messo su un'altra feature.

Capisco Andrea che con la tua regola riproduci l'indirizzario del Comune,
ma io vorrei anche che OSM riproducesse le pagine gialle (o la funzionalità
di googlemaps...)
E se facessimo un sondaggio pubblico a quale delle due funzionalità la
gente è più interessata, scommetto che vincerebbe la seconda! (ma per
carità, cerchiamo di ottenerle tutte e due)

Quanto alla tua indicazione, Francesco, di disegnare un poligono contenente
l'edificio-albergo, e mettere tutti i tag sul poligono: certo, è giusto ed
è previsto anche dalla wiki (si veda per es. tourism=hotel). Ma questo
purché ci siano altri elementi esterni dell'edificio che fanno parte
dell'abergo (parcheggio, giardino, ecc.)
In un albergo cittadino, ricavato da un condominio e concatenato ad altri
condomini (che quindi non ha nessun elemento esterno di sua pertinenza),
non puoi far altro
che associare i tag al building stesso.

@Stefano, mi allarga il cuore il tuo intervento: fosse vero che
agid/ade/istat trovino una soluzione, e soprattutto che sia replicabile in
OSM!  Tienici aggiornati!

Buona serata a tutti,
Marco

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Mail
priva di virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 2 feb 2022 alle ore 18:07 Francesco Ansanelli <
francians a gmail.com> ha scritto:

> Ciao Cristiano,
>
> Non è una buona idea e soprattutto relazione non vuol dire collezione.
> Serve un po' di esperienza in OSM per capire che le relazioni non servono a
> salvare bit o creare categorie, è per questo che è abbandonata e
> sicuramente sconsigliabile.
>
> Francesco
>
> Il mer 2 feb 2022, 16:06 Cristiano Giovando <giovand a gmail.com> ha
> scritto:
>
>> Quella relazione in effetti potrebbe tornare utile  :) ...specialmente
>> per la situazione italiana dove abbiamo linee guida diverse da altri
>> paesi. Forse è stata abbandonata proprio perchè di solito il tag
>> address si può applicare tranquillamente sia ai nodi, che ai poligoni,
>> che ai POI?
>>
>> Se suggeriamo di seguire un formato specifico
>> (
>> https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia
>> ),
>> penso sia importante anche includere indicazioni su come risolvere il
>> problema della disgiunzione tra il nodo dell'indirizzo e il POI (punto
>> o area) cui è associato.
>>
>> Il Bremen Schema mi sembra un po' ridondante e non è ancora stato
>> approvato dopo molti anni, ma se c'è consenso a livello nazionale,
>> forse è il modo più pratico per risolvere il problema e bisognerebbe
>> indicarlo nelle linee guida italiane. Che dite?
>>
>> On Wed, Feb 2, 2022 at 2:54 PM Andrea Musuruane <musuruan a gmail.com>
>> wrote:
>> >
>> > Ciao Cristiano,
>> >
>> > On Wed, Feb 2, 2022 at 2:08 PM Cristiano Giovando <giovand a gmail.com>
>> wrote:
>> >>
>> >> Premetto che non ho molta esperienza al riguardo, ma a rigor di logica
>> non si dovrebbe usare una relazione invece di ripetere le informazioni
>> sotto un altro tipo di tag? So che le relazioni sono elementi abbastanza
>> "fragili" in OSM e spesso i software di rendering o navigazione non li
>> prendono in considerazione, ma sarebbe un modo per mantenere l'indirizzo
>> sul nodo dell'ingresso e associarlo al poligono dell'edificio dove si
>> possono indicare poi il resto dei tag (nome, orari, etc).
>> >
>> >
>> > Nel passato sono state fatte diverse proposte che usano una relazione,
>> come questa:
>> > https://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress
>> >
>> > Per un po' l'ho anche usata e non credo sia la corretta soluzione
>> perché, oltre ad essere poco mantenibile, è anche difficile da usare da
>> parte di un principiante.
>> >
>> > Soffre degli stessi problemi della relazione associatedStreet, che
>> infatti è raramente utilizzata (e spesso, quando viene usata, è usata in
>> modo errato).
>> >
>> > Ciao,
>> >
>> > Andrea
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Talk-it-piemonte mailing list
>> > Talk-it-piemonte a openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-it-piemonte
>>
>> _______________________________________________
>> Talk-it-piemonte mailing list
>> Talk-it-piemonte a openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it-piemonte
>>
> _______________________________________________
> Talk-it-piemonte mailing list
> Talk-it-piemonte a openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-piemonte
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.openstreetmap.org/pipermail/talk-it-piemonte/attachments/20220202/a0100c81/attachment.htm>