Ciao a tutti!
Sto sviluppando un bot con l’obiettivo di aggiornare periodicamente (a cadenza settimanale) i dati dei DAE (defibrillatori) in Italia, partendo dai registri ufficiali in formato Open Data pubblicati dai vari comuni e dalle regioni italiane
Prima di iniziare qualsiasi operazione ci tenevo a confrontarmi con la comunità italiana per impostare il lavoro nel modo più corretto e condiviso possibile, e ottenere l’approvazione della comunità, come scritto sulle regole.
Domande per voi
Come avrete intuito, il bot dovrà gestire i nuovi inserimenti, modifiche e rimozioni nella mappa, che possono creare conflitti con i dati già messi da persone e possono essere dati inesatti. Quindi, quale sarebbe il miglior modo per segnalare le modifiche nella mappa? (Esempio: fixme=* con fixme:source=*)
Va bene per voi usare l’integrazione di intelligenza artificiale? Le informazioni da modificare nella mappa verrano fornite all’intelligenza artificiale che restituirà le modifiche suggerite, per esempio se un DAE cambia orario, suggerirà di cambiare il tag dell’orario e con cosa cambiarlo, verranno allegate ovviamente anche le fonti; Poi una persona dovrà verificarle (in alcuni casi di persona)
- Ma il consumo dell'intelligenza artificiale per ogni singola chiamata?
A parte il primo import di ogni registro, sopratutto nei registri grandi come quelli regionali che contengono molte informazioni, le chiamate dell’ai settimanalmente non sono molto elevate (1 per ogni dae modificato/aggiunto/rimosso)
Tabella di marcia
Rilascio della repository github pubblica in modo che tutti possano contribuire
Creazione dell’account del bot su OSM, del post dedicato nel forum e la pagina su OpenStreetMap Wiki
Come potete aiutare..
Fai parte di una associazione di volontariato (Croce Rossa Italiana (CRI), l'ANPAS(Pubbliche Assistenze) o leMisericordie) che gestiscono DAE pubblici? Sei un manutentore DAE? O semplicemente un mappatore di OpenStreetMap? Potrete aiutare ad aggiornare le informazioni nei DAE segnalati dal bot, preferibilmente controllando di persona, o nei primi due casi avendo informazioni sui DAE che gestiscono
Chiedere alla vostra regione ( O anche non alla vostra, eccetto Emilia-Romagna di cui si ha già il registro), tramite e-mail, di rilasciare pubblicamente su 1. dati.gov.it la lista dei DAE, e di tenerla aggiornata, segnando “Settimanale” come Frequenza di aggiornamento.
Contribuire sulla repository github (verrà creata in seguito), lo script è scritto in python.
la compatibilità delle licenze (non basta che siano su dati.gov.it per poterli importare)
la qualità dei dati usabili (mi ricordo che qualche mese fa se ne era parlato, forse su telegram, e molti erano sballati, il che rende problematico l’import automatico)
l’utilizzo di AI per decidere cosa fare: non è un problema così complesso da essere non-enumerabile, penso quindi che non dipendere dall’ai per un semplice update di tag sia da preferire, se non altro per la prevedibilità del risultato
Il registro regionale pubblicato dal comune di Bologna è sotto la licenza CC BY 4.0, bisognerebbe ottenere un waiver… magari qualcuno ci può lavorare?
Non è proprio un import, non aggiunge né sovrascrive dati alla cieca, la mia idea è quella che il bot aggiungesse un tag fixme (o qualche altro modo) con le modifiche suggerite, facendo in modo che un umano lo revisiona (in alcuni casi di persona) e nel caso corregge i dati sbagliati. Inoltre un’AI potrebbe risolvere alcuni errori nei dati che un import non potrebbe
Non credo sia un semplice update di tag. Adesso magari sbaglio, correggimi, ma di solito un import non avviene da solo un registro? O anche se sono più registri comunque il meccanismo è “campo “X” del database diventa il tag “Y” su OSM”. Il problema è quando invece usiamo più registri (tipo uno per regione perché non esiste uno nazionale, magari anche delle associazioni che vogliono condividere i loro dati per migliorare osm) il formato e i campi dei file sono diversi. Per farti un esempio in un registro gli orari sono formati con un campo chiamato “orari_comunicati” che ha come valore una lista dei giorni in qui c’è un orario (in qui i giorni sono separati da una virgola) e poi un campo per ogni giorno in qui c’è un orario con il valore dell’orario in quel giorno, in un altro invece c’è (per fortuna direi solo un campo con l’orario scritto in json nei vari giorni, magari potremmo mappare per ogni registro il meccanismo diverso per aggiornare i tag, ovviamente sarei d’accordo ma sai quanto lavoro c’è? Pensavo a qualcosa di più versatile, l’ai potrebbe suggerire i tag in modo più idoneo e appropriato, tipo combinandoli in base al contesto: esempio, se nella nota nel database c’è scritto “Installato sulla parete esterna della scuola …” allora l’ai deduce questi tag location=outdoordescription=Sulla parete esterna ...
Comunque grazie per la risposta e degli utili accorgimenti
Andrea, non puoi sapere se è un account creato solo per il bot da un utente magari con esperienza (visto che nulla vieta gli account multipli su OSM). E poi su un progetto collaborativo magari vi si può proporre per aiutare, invece di cassare subito l’idea di qualcuno.
Ciao. Questo account sta facendo una normale attività di mapping. Inoltre, gli account per i bot devono essere dichiarati. Se poi ho preso un abbaglio, nulla impedisce di rispondere. Infine, l’esperienza è un prerequisito delle import guidelines perché gli import sono processi complessi che richiedono più attenzione delle normali attività di mapping.
capisco, per quanto riguarda il merge di più dataset ti consiglierei di farlo a codice, piuttosto che farlo inferire ogni volta dall’ai (obv se l’ai ti aiutasse a scrivere il codice non vedo problemi! ).
per i tag aggiuntivi: di solito l’inferenza in base a note e simili è lasciata al mappatore, poi se qualche ente ha raccolto i dati mi aspetterei una certa uniformità anche nello stile delle note, quindi interpretabili anch’esse lato codice (ma conosco dataset ufficiali, tipo le biblioteche dell’iccu, che sono molto… fantasiosi)
per iniziare a valutare tutte queste opzioni, se ti va di iniziare a smanettarci, potresti fare che il codice genera un geojson, in maniera da poter valutare tutte le eccezioni e anomalie dei dataset d’origine e capire quanta fantasia hanno.
se lo metti già su una repo pubblica, magari rilasciando il geojson da un’action, possiamo darti anche una mano a valutare e decidere!
Grazie, non ho altri account OSM quindi se consideriamo l’età dell’account come esperienza di una persona (significa che se sto assente 7 anni da OSM praticamente vengo considerato come uno che ha un sacco di esperienza? ) allora non ho abbastanza esperienza, però concordo con te, è un progetto collaborativo (avrei fatto anche una repo github in seguito) e visto che nessuno ha fatto ancora qualcosa di simile, se non tentativi di importare i DAE dell’emilia romagna non riusciti, io pensavo di fare qualcosa di buono
Non avrò letto tutto ma proprio all’inizio della pagina c’è scritto nei requisiti che serve avere le basi di OSM, io le ho e controllo frequentemente anche il wiki di OSM quando edito.
Certo, è proprio quello che stavo per fare, grazie per i suggerimenti! Essendo un progetto collaborativo, ascoltare gli altri è la mia priorità e non sarò l’unico a lavorarci
Scusa ma non è più semplice se apri una PR sul repo di Osmose osmose.openstreetmap.fr invece che mettere un fixme su ogni DAE? Gli mandi un parser che produce `latitudine, longitudine, tag suggeriti` e fa comparire un segnalino sopra ad ogni DAE.
Attenzione, Osmose vuole che il dataset sia comunque essere in licenza compatibile con OSM, anche se non viene importato.
L’esperienza è imprescindibile per mettere nella stessa frase “conflation”, “dati governativi” e “dati OSM vecchi”, secondo me.
Un progetto collaborativo ha bisogno di competenze diversificate, però non mi sembra che manchino gli esperti di import e i programmatori (anche nella comunità internazionale, come sa chi segue la ML italiana)
Sì, grazie per il suggerimento. In verità ci avevo già pensato di farlo, comunque sarebbe solo nei casi di conflation perché nel caso che il DAE non esistesse già su OSM pensavo di importarlo automaticamente o con revisione
L’import automatico è implicitamente vietato dalle guidelines (un import è su un certo dataset, nel senso, non un URL, e ha un inizio temporale e una fine temporale) perché un difetto nella raccolta dati da parte del governo o nella produzione del CSV crea un problema massivo in OSM (e quindi il CSV va esaminato a mano, almeno in buona parte, prima di essere importato). Nei casi pompe di benzina, farmacie, colonnine elettriche, risultano centinaia di record con coordinate sbagliate, o con le stesse coordinate, o risultano inesistenti a seguito di verifiche dei mappatori (dati vecchi o reporting sbagliato).
Quello che chiami import con revisione è appunto Osmose, che ha i suoi fan anche nella comunità italiana e quindi puoi star certo che non viene ignorato.
A riguardo dell’import, se viene fatto su Osmose e non su OSM quindi non è da considerare un import vero e proprio che deve seguire le linee guida degli import giusto?
@davide020382 rispondo qua perché altri ci hanno provato e ci proveranno.
La PR rimane in sospeso finché non arriva il waiver; in Osmose chiedono la compatibilità di licenza con OSM, mi ricordo che NON fanno eccezione le coordinate e i tag dedotti dal dataset.
Però mi ricordo che segnalare la sola mancanza di POI (senza consigliare i tag) non fu né ammessa e né rigettata come proposta, eventualmente randomizzando un minimo le coordinate, magari puoi fare un tentativo e chiedere se gli va bene.
Vederlo come un import “collettivo”, fatto da tanti mappatori e non da un bot, non aggira il sui generis database right e il copyright, secondo Osmose e OSM(F). Non si tratta di avere ragione in un’ipotetica causa, la loro posizione è sempre che non deve esserci dubbio e non deve esserci una causa, con o senza ragione e con o senza anonimato.
Se ci pensi, un bro che sa importare lo sappiamo trovare, ci sono i focus collettivi (“progetto del mese”), quindi non puoi trovare la “low-hanging fruit”, frutta che cresce in basso e facile da cogliere.
Se credi di vederla, considera che non siamo come Wikipedia. Le comunità Wikimedia hanno più margine per prendere posizione, perché se sbagliano, basta o cancellare un’immagine (facile, è un oggetto indipendente) o riformulare pure meglio di prima (non perdi niente e hai migliorato il wiki). Da noi a revertare ci si rimette soltanto, si cancella il lavoro degli altri che hanno toccato i POI, magari sperduti.
@ppku So del copyright e del requisito del waiver, stavo solo dicendo che oltre a quello nelle linee guida viene richiesta anche una pagina del wiki, ecc. che però se non è un import non servono. Comunque è una domanda stupida, quindi lasciamo stare.
Stai dicendo che c’è gente che sa importare (al contrario di me) e che io sto cercando la soluzione più semplice e quindi non ha senso la mia interferenza? Va bene, ha senso, anche per quello che hai detto nelle ultime 4 righe, comunque il mio proposito non era quello.
A parte il fatto che la repository da me creata avrebbe creato solo un GeoJSON di test (come accennato da @McCio, almeno all’inizio), giusto per permetterci di analizzare la reale qualità dei dati dei registri e di valutare insieme le discrepanze, le coordinate sballate ,la “fantasia” dei dataset governativi, senza rischiare alcun revert dannoso sulla mappa. Non ho mai pensato di fare il “tuttofare” alla cieca, è un progetto colleborativo, che chi sappia fare import collabori allora
Detto ciò, se mi dici che la comunità non difetta di esperti di import, allora lasci volentieri a loro il lavoro; comunque stavo riprendendo il lavoro di Danysan (questo invece è stato approvato) quindi non credo il margine di errore sia elevatissimo…
Ben venga, mi sembra diversa dalla proposta iniziale. A questo punto linko alcuni tool per te o chi vuole impratichirsi con la conflation (anche io stesso in futuro) e spero di non andare troppo off-topic (scusate le notifiche).
QGis per fare un confronto visivo sulla macchina locale, in generale è un ottimo tool ed è scriptabile in Python. Sembra che esista un plug-in che fornisce un algoritmo di conflation. Per cambiare il rendering grafico dei punti e fare un confronto visivo: clic destro sul layer - Proprietà - Simbologia ed Etichette.
uMap https://umap.openstreetmap.fr/ per fare un confronto visivo su mappa da condividere con la comunità (usato ad esempio anche nel caso DAE Emilia-Romagna).
visidata, ottimo viewer tabellare, in generale regge molto bene i dataset malformati, è nelle distro principali.
Chiedere alla vostra regione ( O anche non alla vostra, eccetto Emilia-Romagna di cui si ha già il registro), tramite e-mail, di rilasciare pubblicamente su 1. dati.gov.it la lista dei DAE, e di tenerla aggiornata, segnando “Settimanale” come Frequenza di aggiornamento.
).