IT:Import/Guidelines

Questo articolo è una traduzione dall'articolo originale, ma il contenuto sembra essere disallineato con l'articolo di riferimento (solitamente la versione inglese, francese o tedesca). Se possibile aggiorna questa traduzione.

Occorre sempre ricordare che l’attuale database OSM rappresenta una quantità estremamente alta di lavoro svolto dai volontari della community OSM. Dato che gli import fanno solitamente da riferimento all’inserimento di una quantità considerevole di dati, se condotto attraverso un processo automatizzato da una persona o da un team di persone, sussiste quindi un considerevole rischio di provocare un danno di vasta entità al database. In aggiunta, deve considerarsi fondante l’idea che tutti gli import debbano essere approcciati con cautela e la dovuta quantità di pianificazione.

Le “linee guida” che seguono vogliono fornire supporto alle persone che sono determinate a precedere all’importazione (en) di dataset all’interno del database OpenStreetMap, e al tempo stesso proteggere i dati già presenti nel database OSM. Moltissime attività OSM richiedono grande discrezione da parte degli utenti, ma gli import sono tra le attività più sensibili e richiedono un pianificazione attenta.

Gli import possono potenzialmente introdurre problemi non trascurabili nel database OS e devono essere giudicati a fondo. Inoltre, attrarre una grande community di mapper viene considerato da molti la necessità chiave per costruire una grande mappa. Mentre i data import possono servire a migliorare rapidamente la copertura, le simulazioni (en) sembrano suggerire che i dati importati possono causare problemi alla crescita di una community. Uscire allo scoperto e organizzare tanti mapping party, fare tanta pubblicità, raggruppare molta gente del luogo può rivelarsi una strategia di lungo termine assai migliore rispetto alla semplice importazione dei dataset.

Le linee guida che seguono non garantiscono l’accettabilità di un import, ma questo implica anche che potreste non avere problemi anche non seguendole. Tuttavia, le linee guida incarnano parecchie lezioni imparate durante la vita del progetto OpenStreetMap e dovrebbero essere quantomeno lette da tutti coloro fossero interessati a un processo di importazione di dati orientato alla conservazione di quelli già esistenti nel database OSM.

Il Data working group ha ricevuto l’incarico dalla Fondazione OSM di identificare e fermare gli import che non aderiscono alle linee guida. Quindi, qualora non fossero seguite, l’account utilizzato corre il rischio di venire bloccato (en).

Ogni punto presentato in questa guida è aperto alla discussione, chiaramente, sia sulla mailing list import@ (en) così come anche sulla pagina di discussione.

Il processo

Se siete dell’opinione che la vostra città/provincia/regione/nazione, un ente non-profit, o qualsiasi altra organizzazione o persona abbia degli ottimi dati che potrebbero essere utilizzati per migliorare la qualità del progetto OpenStreetMap, ecco tutto quello che c’è da sapere. Cominceremo con uno schema riassuntivo del processo per partire sulla buona strada. La maggior parte di queste sezioni verranno espanse nelle prossime sezioni della pagina oppure nelle pagine relative.

Step 1 - Prerequisiti

1. Acquisire familiarità con i principi di OpenStreetMap, incluso l’editing e cose come l’aggiunta di dettagli dei dintorni del luogo in cui si vive. E’ consigliato seguire i passi della guida per principianti
2. Imparare la storia pregressa degli import e tutti i possibili impatti negativi. Consultate la pagina dello storico problematiche (en)
3. Identificare gli oggetti che si desidera importare, siano essi linee di demarcazione, contorni di edifici, vie d’acqua, indirizzi, ecc…

Step 2 - Il consenso della community

1. È raccomandabile che, prima di disporre l’effettiva importazione, venga preso contatto con la community per ottenere del riscontro di interesse sull’importazione dei dati. Aree geografiche differenti hanno livelli diversi di accettazione degli import. Lo stesso tipo di dataset potrebbe essere il benvenuto in una certa area e respinto in un’altra.
2. Discutere del piano di importazione. Potrete farlo scrivendo una mail (mandatoria) a imports@openstreetmap.org, talk-it@openstreetmap.org e, se esistente, il gruppo OSM specifico dell’area impattata dall’importazione. La pratica ci permette di trarre beneficio dalle esperienze passate, oppure di scoprire che l’esame del dataset per l’area in questione è già stato fatto in tempi passati. A tal proposito occorre non dimenticare di consultare gli user groups (en), il local chapter working group, e le mailing list specifiche per nazione
3. Le importazioni più complesse e di larga scale dovrebbero essere esaminate con la supervision dei volontari più tecnici di OSM.
4. Rendersi disponibili a rispondere alle domande della community, e discutere con la community dell’appropriatezza dei diversi layer dell’importazione. Ci sono dati che possono essere importati senza difficoltà, mentre altri sono decisamente più difficili (es. le linee di demarcazione stradale). Alcuni inoltre sono generalmente sempre accettati, mentre certi altri non godono del medesimo consenso (es. le divisioni di lotto).

Step 3 - Documentazione

1. È “richiesto” di ottenere gli opportuni permessi e licenze all’impiego dei dati in OSM dal detentore dei diritti. Se le licenze sui dati non sono compatibili con la Licenza Open Database non sarà possibile utilizzare i dati. Molti enti territoriali hanno policy open data avanzate, altri hanno policy “quasi” open, ma i conflitti con le policy che vietano gli usi commerciali o che richiedono l’attribuzione esplicita sussistono su base concreta. Altre volte ancora, recuperati i permessi di utilizzo dei dati, anche se le licenze di utilizzo possano sembrare proibitive, è sufficiente chiedere all’autorità competente se desiderano aderire ai termini di contratto OSM Open Database License. Visionare ottenere i permessi (en) per alcuni esempi di email in grado di toccare i punti più importanti
2. È “richiesto” di registrare i vostri permessi e il progetto aggiungendo una linea sulla tabella di catalogo
3. Citare il contributo dei proprietari dei dati. Se necessario citarli nella pagina dei collaboratori
4. È “richiesto” di scrivere il piano di importazione nella wiki OSM. Creare una pagina che descriva i dettagli del vostro piano, il piano dovrà includere informazioni quali su come convertire i dati nel formato XML OSM, la divisione del lavoro, la gestione della conflazione (en), la corrispondenza degli attributi GIS con i tag OSM, le potenziali possibilità di semplificare i dati, i piani di rollback, le policy sulle dimensioni del changeset e i piani per la quality assurance. Si possono trovare degli esempi pratici nella sottosezione dedicata ai canovacci

Step 4 - Presentazione dell'importazione

1. È “richiesta” la presentazione della vostra importazione alla mailing list imports@openstreetmap.org. Non caricare nessun dataset finché il progetto non sarà prima esaminato
2. Se possibile, preparate i dati per poterli rendere disponibili durante la revisione

Step 5 - Upload

1. Seguire il piano
2. Tracciare i progressi
3. Fornire aggiornamenti delle vostre fatiche alla community
4. Rendere noto quando il lavoro è finito
5. È “richiesto” di utilizzare un account dedicato

Assicurarsi che la licenza sui dati sia OK

Abbiamo interesse nei soli dati che siano “liberi.” “Dobbiamo poter rilasciare i dati attraverso la nostra Licenza OpenStreetMap.” Ovviamente ci è permesso utilizzare le sorgenti di dominio pubblico, presenti in numero piuttosto corposo. Oltre quei confini però tutto si complica.

OpenStreetMap si è spostato alla Licenza OpenStreetMap nel Settembre del 2012. I dati da importare dovranno di conseguenza esserne compatibili. In aggiunta, l’account di importazione dovrà aderire ai termini di collaborazione, che include clausole in grado di permetterci di licenziare nuovamente i dati forniti attraverso nuove licenze libere e aperte qualora la community ne esprimesse la volontà.

L’importatore non dovrà reclamare nessun diritto d’autore aggiuntivo. Per esempio, se venissero importati dei dati di dominio pubblico, non si dovrà cercare di restringere l’utilizzo dei dati importati. L’account di importazione non dovrà negare alcun permesso garantito dagli originali creatori dei dati che saranno importati.

Si ponga particolare attenzione ai dettagli dei requisiti di attribuzione. Possiamo offrire “alcune” attribuzioni: possiamo farne menzione sul nostro sito web (“non” sull’homepage, ma nella pagina wiki dedicata ai collaboratori, e sulla pagina della licenza per contribuzioni di scala estremamente grande). Possiamo linkare e offrire informazioni che li riguardano sull’account che eseguirà l’importazione, con lo scopo di tracciare la fonte della donazione di dati. Possiamo anche impostare il loro nome nei tag source=* relativi al dato puntuale. E’ probabilmente l’offerta più evidente, ma ha lo svantaggio di poter essere modificata o rimossa da altri mapper nelle progressive lavorazioni. I crediti “all’autore” si fermano dunque qui. Ciò che non possiamo di certo fare è obbligare ai fruitori finali dei dati o dei rendering il credito un preciso donatore. Tenendolo bene a mente, diventa chiaro che le attribuzioni che forniamo potrebbero non essere ritenute sufficienti da un punto di vista strettamente legali, e potrebbero essere considerate insoddisfacenti dagli originali “autori” dei dati.

Possiamo anche scoprire talvolta alcuni dati spacciati per disponibili tramite una licenza compatibile vengano derivati in ultima da sorgenti non libere. Per esempio, nonostante alcuni geodati siano messi a disposizione da Wikipedia con una licenza Creative Commons si diffonde la voce che la provenienza iniziale sia Google Maps, in violazione dei canoni della nostra licenza. In tali casi è prassi della community non procedere all’importazione di dati dalla provenienza dubbia, nonostante la licenza sotto cui vengono diffusi. Meglio un rimpianto che mille rimorsi.

Discutere l’import con la community

È molto importante discutere con la community le proposte di importazione in qualsiasi punto del progetto. Prima di tutto aggiungere una referenza alle potenziali fonti di dati. Potrete inserire una breve descrizione di quello che avete trovato a proposito delle licenze sui dati, e l’accuratezza dei dati rispetto ai dati già in nostro possesso. Qualora servisse più spazio, create un link a una nuova pagina wiki dedicata alla fonte di dati.

Aprire una discussione sul proprio import alla mailing list (en) imports@openstreetmap.org “e” con le corrette community locali. Parecchie community hanno delle pagine di progetto (en) dedicate (en), oppure delle mailing list. Coordinarsi con persone che condividono gli stessi obiettivi davvero è molto importante.

Anche se la stessa o un’importazione simile è già stata discussa, si dovrebbe comunque discuterla con la community locale. L’obiettivo è di renderli partecipi dei vostri piani, e di raccogliere ogni possibile dubbio o rischio di collisione prima che il danno effettivo si verifichi. La pratica è necessaria in special modo dal momento in cui i dati sono a disposizione da molto tempo, e nessuno si è ancora occupato di importarli; NON è considerato accettabile procedere senza la giusta discussione con la community locale.

Cominciare sempre dalla discussione sull’indagine compiuta in merito alle licenze e alla precisione. Se durante il dibattito si sviluppasse l’opinione che i dati non rispettino i nostri standard, non dispiacersi. In questo caso è importante contrassegnare la referenza come ‘’respinta’’ nella pagina relativa alle potenziali fonti di dati, fornendo le ragioni del respingimento. Documentare le ragioni del respingimento è di per sé un’utile contribuzione. Se invece tutti sono soddisfatti della fonte, spostare la discussione sull’implementazione degli script di importazione, ecc…

Le importazioni dedicate alle emergenze umanitarie, risposta alle catastrofi, oppure allo sviluppo dovrebbero invece consultare il Team Umanitario OSM (en) (il mezzo ideale è la mailing list HOT dedicata).

Documentare l’importazione sulla wiki

Se l’importazione procede fino a questo punto, si potrà creare una pagina dedicata sulla wiki, con tutti i dettagli del caso. Creare quindi una referenza al progetto nella pagina del catalogo delle importazioni (en) con un link alla pagina dedicata al progetto. Aggiungere anche un link sulle pagine di progetto. La pagina dovrà contenere i dettagli che seguono:

• Descrizione della precisione dei dati e delle licenze acquisite (erano già state riassunte nella pagina delle potenziali fonti di dati)
• Il software di importazione (en) che si intende utilizzare. Condividere il codice utilizzato
• Spiegare esattamente come i dati verranno tradotti dal formato di origine nel formato OSM
• Come appariranno i dati finali. Elencare i tag che verranno impiegati
• Un link a dei dati campione importati sul database di test
• Username dell’account che eseguirà l’importazione e altri dettagli di come verranno taggati i changeset

E al progredire dell’importazione:

• Link a dei dati di esempio sul database di produzione

Utilizzare un account utente dedicato

Creare una nuova utenza per l’importazione. È indispensabile non utilizzare il proprio account standard OSM. La pagina dell’utenza potrà essere utilizzata per raccogliere le informazioni relative alla sorgente e ai dettagli dell’importazione. In aggiunta, questo implica che l’attribuzione potrà anche essere condotta attraverso il nome dell’utenza, o attraverso la pagina dell’utenza. La pratica è più salubre rispetto all’inserimento in un tag, dal momento che la cronologia delle modifiche di un utente è un’informazione permanente relativa alla sorgente, non interferisce con i tag e non incrementa troppo la dimensione del database. Per tutte queste motivazioni, creare un account dedicato è assai preferibile all’inserimento del tag source=*. Per delle importazioni distribuite oppure gestite dalla community, si faccia in modo che ogni persona crei il proprio account di import, per esempio sullo schema “OSM-username_import”. Non è richiesto che ogni import avvenga tramite il medesimo account.

“Il Data Working Group potrebbe decidere di bloccare le utenze che non rispettassero questa o altre regole.”

Attenzione ai tag

L’importazione dovrebbe utilizzare dei tag che sono familiari alla community OSM, piuttosto che inventarne un gruppo personalizzato.

Per esempio si potrebbe venire in possesso degli ID utilizzati per i dati originali. Se i metadati tornassero utili su OSM allora si definisca il proprio prefisso e lo si utilizzi per tutti i metadati relativi all’insieme. L’importazione TIGER (en), per fare un esempio, ha utilizzato e utilizza il prefisso “tiger:”. L’identificativo originale di un oggetto TIGER (en) è stato targato come “tiger:tlid.”

Non si esageri con con i metadati, però. OSM è interessato unicamente a ciò che può considerarsi verificabile. Non sono incluse nel concetto di verificabilità le chiavi esportate di un altro database, per esempio, a meno che non sia assolutamente indispensabile mantenere quel tipo di dato per il futuro. La sorgente di dati utilizzata potrebbe avere tantissimi campi diversi, ma gli elementi OSM con tantissimi tag possono essere molto difficili da manipolare. È necessario trovare il giusto equilibrio. Si può scoprire (discutendo!) quali siano i campi davvero interessanti per la community OSM.

Tenere a mente le risorse lato server

Assicurarsi di non sovraccaricare il server durante l'importazione di grandi moli di dati. L'importazione TIGER (en) dovette estendersi per diversi mesi per evitare di intasare il server principale. Sarà sufficiente importare i dati in piccole quote, oppure rallentare gli script di importazione. Per qualsiasi dubbio, rivolgersi agli amministratori di Sistema.  

Non guastare i dati!

Non dovrebbe neanche esserci bisogno di dirlo: non rovinare i dati già presenti su OpenStreetMap! Bisogna mettersi sempre nei panni di un collaboratore occasionale di OpenStreetMap che lavora con iD e Potlatch, senza dare per scontato che questi utenti abbiano voglia di fare pulizia. Se non si ha esperienza con iD e Potlatch, sarebbe bene evitare di eseguire importazioni. JOSM tende a comportarsi leggermente meglio nel districare dati compromessi, ma è comunque estremamente scomodo. In ogni caso, la maggior parte degli utenti (specialmente quelli nuovi) usa iD e Potlatch.

I vostri dati rischiano di rovinare l'esperienza di editing su OpenStreetMaps? Bene, a noi questo non ci va.

Si tenga sempre conto dei dati già presenti, evitando di importare nuovi dati sopra quelli che già ci sono. In generale la sovrapposizione di dati è sempre una brutta idea (vedi le note sui dati che seguono). Bisogna anche tenere presente che i dati esistenti possono essere oggetto di cura e manutenzione da parte di utenti reali. È possibile determinarlo attraverso metodi automatici o semi-automatici, e decidere di conseguenza. Per esempio, in aree di lavoro gestite da persone in carne e ossa, si potrebbe decidere di non fare nulla.

“Se un import non va a buon fine,” o si presenta la necessità di interrompere un upload a metà, questo dovrebbe essere annullato. Qualora ci fosse bisogno di aiuto, contattare la casella imports e/o talk. Ma l'import non andrà male, perché è già stato testato con cura nel database di test… giusto?   Se non si conosce la procedura per annullare un’importazione, sarebbe meglio non farla in primo luogo.

Linee guida specifiche per i dati

Non sovrapporre i dati ad altri dati

A differenza dei tradizionali sistemi GIS, su OpenStreetMaps non esiste il concetto di layer. I dati sovrapposti ad altri dati sono semplice disordine. Quel genere di disordine che rende davvero complicato per gli utenti reali lavorare con i normali editor di OpenStreetMap. La mappa dei nodi duplicati (en) mostra le importazioni che non hanno seguito queste direttive (gli importatori fraudolenti dal sistema TIGER (en) hanno causato diversi problemi, ma purtroppo ci sono molte altre importazioni recenti dall’esito disastroso).

I dati nel tradizionale formato GIS a layer necessitano di un approccio diverso. Una prima idea potrebbe essere unire i layer, e computare i migliori tag di aggregazione. È anche possibile evitare l'importazione diretta, e approntare una sorgente da cui gli utenti possano selezionare e importare manualmente i dati, o un web map service da ricalcare (ad esempio Natural Resources Canada -Toporama)

Semplificazione innanzitutto

Un file shape include spesso troppi dettagli, per esempio moltissimi nodi allo scopo a di rappresentare una curva, oppure più di due nodi che formano una linea perfettamente dritta. È una condizione che si incontra in particolare sulle aree a utilizzo civile non abitativo più estese in cui i nodi distano qualche metro l’uno dall’altro, oppure appaiono seghettati a causa della risoluzione troppo bassa oppure troppo alta. Strumenti come Map Shaper possono essere impiegati per semplificare i file shape che hanno troppi dettagli. Occorre sempre tenere a mente l’idea di come i dati appaiono, e di come potranno essere lavorati su Potlatch.

Consultare anche

• catalogo delle importazioni (en)