Come correggere gli indirizzi errati a Venezia?

Gentile comunità IT,

Come sapete, sto lavorando da un po’ di tempo alla ripresa dell’importazione degli indirizzi di Venezia di Cascafico.

Da quando ho ripreso il lavoro, ho finora importato indirizzi per Burano, Murano e Sant’Erasmo.

Vorrei iniziare presto l’importazione per le isole veneziane.

Pertanto, vorrei chiedere il vostro aiuto.

Gli indirizzi a Venezia (le isole) hanno ufficialmente uno schema specifico di sestiere + numero civico, storicamente derivato dal sistema di numerazione austriaco.
In OSM, questo corrisponde alla combinazione “addr:place” + “addr:housenumber”.
Le informazioni sulla strada sono solo facoltative, poiché le stesse vie esistono in sestieri diversi.

Tuttavia, molti POI sulle isole includono anche gli indirizzi stradali nei loro indirizzi; ecco solo alcuni esempi [1],[2],[3]. Ciò significa che attualmente ci sono quasi 800 indirizzi per le isole veneziane con la combinazione “addr:street” + “addr:place”, proibita in OSM e non supportata da Nominatim o altri geocodificatori.
Tali indirizzi non sono ricercabili e devono essere corretti per essere utili (cosa posso fare insieme all’importazione).
Ci sono quindi due opzioni:

  • rimuovere completamente “addr:street” dagli indirizzi, lasciando solo i tag corretti “addr:place” + “addr:housenumber”
  • spostare le informazioni presenti da “addr:street” a un altro tag, ad esempio “contact:street

La prima opzione ha il vantaggio di conservare solo i dati corretti. Tuttavia, dato che i POI spesso includono anche l’indirizzo stradale, è più che probabile che col tempo gli utenti che non hanno familiarità con l’indirizzo specifico di Venezia aggiungano nuovamente il tag “addr:street”, rendendo gli indirizzi nuovamente inutili.

La seconda opzione ha il vantaggio di mantenere visibili le informazioni stradali, riducendo al minimo il rischio che vengano aggiunte di nuovo. Tuttavia, questa soluzione non è stata ancora ampiamente implementata e richiede l’approvazione della comunità.

Un utente locale con cui lavoro è entusiasta dell’utilizzo di “contact:street” e ha persino creato un ticket per Nominatim per supportare questa informazione.

Cosa ne pensi?
Saluti
Premislav

1 Like

Io inserirei solo addr:place e addr:housenumber. Dato che il numero civico non e’ legato alla strada ma al sestriere, l’uso di addr:street e’ errato. Per questo motivo anche l’uso di contact:street lo trovo errato. Inoltre, quest’ultimo sarebbe l’unico caso al mondo con questo schema di tagging e non sarebbe supportato da nessun data consumer.

Se uno vuole mappare (o ricercare un indirizzo) a Venezia spero abbia conoscenza di cosa deve cercare. Spesso non e’ cosi’ ma non possiamo cambiare il modo di mappare perche’ c’e’ gente che ignora il suo peculiare schema dei numeri civici (come lo ignora anche da altre parti, tipo Genova).

Però facendo così ti perdi la ricercabilità per nome della strada.

Se non ricordo male, il geocoding dovrebbe essere in grado di associare il place ai punti che si trovano al’interno del boundary (sempre che ci sia), per cui in questo caso ci potrebbe stare addr:street + addr:housenumber, e il place verrebbe da sè (una volta si usava is_in).

Certo ci sarebbe una numerazione un po’ strana, non coerente con quella delle altre città, ma se la realtà è quella…

2 Likes

L’inserimento dell’informazione della strada è necessario e utile per molteplici motivi, sia per la colloquialità e l’uso reale che viene fatto anche da istituzioni ufficiali, sia perché nessuna persona sa come arrivare ad un civico, ma sa come arrivare in nome calle. In altre parole, a parte la formalità che lega un numero al sestriere, la città e i suoi cittadini funzionano in base ai nomi delle strade.

Aggiungo che non è così unico come caso d’uso vista la risposta su Nominatim (in cui dicono che la modalità è parallela ai “conscription number” di altre zone del mondo, con la particolarità che i due numeri -civico e conscription- sono uguali). E anche se fosse un caso totalmente unico, perché non si dovrebbe supportare? Anche se i consumer non fossero pronti allo schema, intanto troviamo una modalità per contenere le informazioni, la documentiamo, e poi si parlerà con i consumer perché la supportino.

Inoltre OsmAnd pare supportare già questo schema, infatti cercando nome strada + numero torna il risultato corretto etichettandolo “contact:street (addr:place) addr:housenumber”.

Riepilogo quindi diverse opzioni:

  • rimuovere completamente “addr:street” dagli indirizzi, lasciando solo i tag corretti “addr:place” + “addr:housenumber”
    • :white_check_mark: si rispetta l’ufficialità delle informazioni
    • :white_check_mark: si rispetta lo schema addr:street O addr:place
    • :cross_mark: si perdono informazioni
    • :check_box_with_check: i data consumer supportano lo schema, ma non hanno modo di cercare per strada
  • spostare le informazioni presenti da “addr:street” a un altro tag, ad esempio “contact:street
    • :white_check_mark: si rispetta l’ufficialità delle informazioni
    • :white_check_mark: si rispetta lo schema addr:street O addr:place
    • :white_check_mark: si mantiene l’informazione della strada
    • :cross_mark: non tutti i consumer interpretano l’informazione correttamente (OsmAnd sì, Nominatim no, altri da verificare)
  • mantenere solo addr:street + addr:housenumber, e il place verrebbe da sè (i boundary sono già definiti)
    • :cross_mark: non si rispetta l’ufficialità delle informazioni (nel singolo nodo)
    • :white_check_mark: si rispetta lo schema addr:street O addr:place
    • :white_check_mark: si mantiene l’informazione della strada
    • :white_check_mark: dovrebbe essere già supportato dai motori di geocoding
  • non si decide nulla
    • :check_box_with_check: non si fa una scelta sbagliata
    • :cross_mark: non si risolve un problema
    • :cross_mark: i dati saranno sempre più vari e non gestibili massivamente in maniera coerente

Parere personale: la soluzione di @Max1234-ITA mi sembra più pulita, ma mi preoccupa che in possibili gestioni automatizzate dei dati manchi l’informazione della strada, generando punti solo con housenumber. Forse andrebbe bene così e bisogna solo fare dei mapping party veneziani per inserire i nomi delle strade (con bacaro tour :wine_glass: annesso, moderato per non inserire dati insensati :rofl: ). Usare contact:street inoltre potrebbe sovrapporsi con altri tentativi di utilizzare quel tag, ma inventarsi nuovi tag sembra esagerato.

1 Like

Secondo me usare solo addr:place renderebbe il tutto caotico e impossibile da navigare, alla fine OSM è una mappa non un database.
Non sono esperto di amministrazione Veneziana ma, se venissero mappati i sestieri con relazioni e boundary con admin_level=10 in luogo al poligono di oggi e poi si tenessero gli addr:street+addr:housenumber sugli indirizzi. Facendo così verrebbe anche meno la necessità di indicare is_in.

Questo se i sestieri hanno effettivamente una minima valenza amministrativa. Se il livello amministrativo fosse sotto gli standard del livello 10 si potrebbe pensare di codificare il livello 11. Questo magari da utilizzare come livello per i quartieri (o sestieri) che hanno comitati di quartiere riconosciuti dal comune e con elezioni regolari.

Lasciare solo “addr:street” + “addr:housenumber” per le Isole Veneziane non dovrebbe essere preso in considerazione, poiché non si tratta dello schema ufficiale del Comune di Venezia né è così segnalato sul territorio. Inoltre, all’interno dello stesso sestiere possono esistere due strade con lo stesso nome.

Anche l’ultima opzione è svantaggiosa, perché gli indirizzi rimarranno non ricercabili.
Raccomando di prendere in considerazione la prima opzione (senza contact:street) oppure, eventualmente, la seconda (con contact:street per la segnalazione facoltativa della strada).

1 Like

OSM non ha problemi nell’utilizzare solo addr:place. Questo schema è ampiamente utilizzato senza difficoltà, ad esempio in Polonia, nella Repubblica Ceca o in Italia a Burano, sia da solo sia in combinazione con addr:place + addr:city.
Non funziona solo con addr:street, poiché una tale combinazione è esplicitamente vietata dal Wiki (“No object should have addr:place=* and addr:street=* at the same time.”).

la strada su quale si trova un indirizzo solitamente si può ottenere in automatico con un algoritmo di prossimità (salvo casi eccezzionali)

Vorrei evidenziare che su OSM mappiamo la realtà. Se lo schema che hanno scelto di usare i veneziani è particolare, quello dobbiamo comunque usare. Ciò implica l’uso di addr:place + addr:housenumber dove la numerazione civica viene assegnata per sestriere.

Sottolineo inoltre che la ricerca di un indirizzo con un navigatore e con una mappa cartacea è totalmente differente. Il navigatore dato sestriere e numero civico è in grado di portarmi a destinazione perché questo dato è geolocalizzato. Se invece devo usare una mappa cartacea, siccome i genere NON sono presenti i numeri civici (e anche fossero presenti trovare un numero a 4 cifre è abbastanza complicato), devo basarmi sulla calle su cui afferisce il numero (ed è per questo che molte amenities usano questo schema).

1 Like