Come sto procedendo (senza essere sicuro di andare nella direzione giusta).
Ho messo su un documento di Qgis i lug, le associazioni nazionali e i negozi amici di linux (questi ultimi ampiamente da rivedere IMHO).
Il formato in cui salvo i dati dei singoli layer è GeoJSON.
Da Qgis esporto il lavoro tramite il plugin qgis2web in open layer o volendo leaflet. Per ora mi pare meglio il primo.
Qui i dati diventano in file JS in cui si dichiara una var che non è altro che il file GeoJSON.
Per ora ipotizzo di mantenere questo unico file come DATO di riferimento e da questo estrarre la lista, che con la libreria list.js può essere facilmente filtrata ed ordinata.
Occorrerà aggiungere un campo REGIONE visto che questo dovrebbe essere il criterio di selezione.
Il problema che ho incontrato, ma che ormai mi sono convinto non abbia soluzione, almeno non facilmente, era dato dal voler usare direttamente la var dichiarata nel file senza farne il parsing.
A parte il fatto che in questi giorni le esigenze di potatura mi limitano e quindi è tutto un po’ fermo, conterei di arrivare ad avere una cosa che possa girare e presentare i dati sia in forma di mappa che di tabella tra non molto.
Non mi ero posto il problema di condividere i dati con altri sistemi, ed in particolare con Openstreetmap. Condividere con OSM potrebbe essere non così immediato, proprio per la necessità di riferimenti univoci, quindi almeno dei tags specifici che poi tutti usano.
Detto questo l’obbiettivo originale mi pareva che fosse uniformare ed eventualmente accomunare. Quindi l’obbiettivo che mi ero posto era avere tre file js che potessero essere unici con tutti i dati, ma volendo si potrebbe anche passare ad uno solo, con qualche lavoro in più da fare sul lato mappa. Alla fine resterebbe, per ora assolutamente non preso in considerazione, da scrivere un po’ di PHP per l’aggiornamento facilitato della/e lista/e invece di usare un editor generico.
Sull’eventuale inserimento in OSM: ci sono dati con coordinate geo delle associazioni, con licenza compatibile [1]?
Il nodo OSM citato da Valerio ha come tag sia office=association che club=linux. Al momento in Italia OSM ne conta solo tre, mentre se filtriamo solo per club=linux [2], i punti di interesse sono 56
@cascafico Grazie per la domanda sulla licenza dei dati. La riporto nel repository della LUGMap:
Non avrei mai detto che così tante persone avessero già mappato il loro user group in quel modo su OpenStreetMap. Veramente ottimo. Ora manca solo una chiave che permetta a tutti di confrontare i dati ogni volta.
Appunto eviterei che Italian Linux Society dichiari un suo “identificativo LUG”. Magari appunto facciamo affidamento agli identificativi Wikidata così è facile fare intersezioni.
Premetto solo a @mauromago che il “nostro” dataset al momento è questo quindi poi in qualche modo sarebbe ottimale ricondurre le tue modifiche a quel formato (in questa prima fase - per fare in fretta):
Il nodo OSM citato da Valerio ha come tag sia office=association che club=linux. Al momento in Italia OSM ne conta solo tre, mentre se filtriamo solo per club=linux [2], i punti di interesse sono 56
Mi pare che rispetto a questa questione si dovrebbero definire un paio di obbiettivi. Se lo scopo è avere su OSM i LUG in modo che un utente generico possa trovarli, definire solo un tag è poco. La ricerca sulla pagina di OSM non permette ricerche avanzate. Se invece si ritiene che il dato debba essere su OSM perchè l’utente avanzato ne possa fare uso, allora direi che basterebbe trasferire i dati su OSM quando il lavoro sarà finito e poi quando si aggiorna, con il non piccolo problema di possibili dupilicati. Rispetto alla licenza delle coordinate mi pare un problema poco rilevante se non si fa copia incolla. Io mappo su OSM e traccio ciò che c’è, se so che in un dato posto si trova qualche cosa la metto su OSM. Le attuali (mie) indicazioni geografiche sono tutte ridefinite da me, quindi certamente libere. Per altro sono “quasi” giuste solo per i LUG di località dove si trovano più associazioni vicine, altrimenti la posizione è solo il comune (e anche così non è certo che il dato sia significativo)
Premetto solo a @mauromago che il “nostro” dataset al momento è questo quindi poi in qualche modo sarebbe ottimale ricondurre le tue modifiche a quel formato (in questa prima fase - per fare in fretta)
A dire il vero mi sono messo a lavorare su questa cosa proprio perchè si ipotizzava di modificare/rifare la bese dati. Se così non fosse… perchè tutto questo lavoro?
La mia idea infatti è di cambiare il sistema dati, sostituire i file txt da parsare in un file JSON e fare un cron lato CI che fa un push delle modifiche in produzione come facciamo per gli altri siti.
Quindi l’ideale è di rifare una UI mobile friendly delle mappe e una volta definito quello rifare tutto il sistema per entrambi.
Dal punto di vista del progetto LUGMap, vorrei però aiutare ad essere il più gentile possibile con i mantainer storici del progetto LUGMap: idealmente, prima aggiorniamo i dati (nel formato che hanno usato da sempre negli ultimi 10 anni), poi il mattino dopo proponiamo il nuovo formato inventato da noi (JSON con chiavi a caso).
Dal punto di vista di @cascafico questo non comporta lavoro in più. Se @cascafico condivide i dati dal suo QGIS in un GeoJSON, senza problemi aiutiamo a ricondurli al formato originario CSV.
Credo nell’automazione (15 righe di PHP probabilmente faranno la cosa) ma il caso peggiore è che aiuto a farlo a mano e davvero non ho problemi. Però prima vorrei vedere i dati che son curioso
In secondo luogo, sulla issue GitHub e su StackOverflow menzionati, ho cercato di dare una risposta utile ma probabilmente daranno altre risposte utili altre persone
Premessa doverosa. Tutto quel che segue è fuor di polemica
Il tread nasce dal fork di un’altra discussione in cui si chiedeva collaborazione. Tra le varie voci c’era quella relativa a LUG e linuxSI, unificati per evidenti comunanze.
Io rispondevo ipotizzando l’uso di un server GIS se questo fosse poi stato utile anche in altre situazioni, quest’ipotesi veniva esclusa e quindi mi proponevo di lavorare su una soluzione intermedia.
Prendevo i dati presenti e li portavo su un lavoro in Qgis (visto che già lo uso per altri lavori mi è facile), riposizionavo i LUG e facevo una revisione di massima dei negozi linuxSI. I dati sono stati resi disponibili sulle mappe proposte, ma possono essere convertiti in altro modo se servisse.
A questo punto mi è stato detto che prima di rivedere i dati si doveva lavorare sull’interfaccia e dopo si sarebbero rivisti i contenuti.
Procedo cercando di arrivare ad una soluzione che sia proponibile e che possa soddisfare sia la presentazione dei dati in mappa che in forma tabellare.
Poi viene fuori che i dati devo essere interscambiabili con altre piattaforme e che il formato non deve essere modificato (che non era però chiaro all’inizio).
Ora il dubbio di non aver capito bene cosa venisse richiesto diventa quasi una certezza.
La mia intenzione è/era quella di lavorare su una proposta di variazione che andasse verso un’ipotesi iniziale.
Sono fatti in modo diverso ma l’ideale sarebbe uniformare sia la UI che il sistema di dati, quindi anche rifarli potrebbe essere interessante.
Poi alla fine se piace bene se non piace ho imparato cose nuove.
A questo punto andrò avanti nel generare le liste dai dati esportati da Qgis perchè al di là di tutto interessa a me anche per altri lavori.
Fatto questo cercherò di capire se avrà senso lavorare sull’UI o meno in base a quello che verrà fuori.
La premessa doverosa è che è chiaro che chi ha inventato la LUGMap NON avesse idea di come funzionassero software come QGIS
Allo stesso modo, sono quasi sicuro che chi usa software come QGIS non sia solitamente avvezzo a fare siti web.
Ma una quadra la troviamo.
Fra l’altro, che fai di bello lunedì ore 21:00? magari possiamo dare un’occhiatina dal vivo al tuo lavoro su QGIS. Ogni lunedì a quell’ora ci incontriamo online. Se ti farebbe piacere io curioserei volentieri QGIS
In pratica si chiede all’interno della relazione “Italia” di restituire in formato CSV l’id OSM, il tipo OSM (nodo, poligono o relazione), il nome, latitudine, longitudine di tutti gli elementi di tipo nodo (n), poligono(w) o relazione (r) che hanno il tag club=linux.
Per elementi non puntuali (w e r), le coordinate rappresentano il centroide dell’elemento. Al “name” si può aggiungere p.es. “email”, “website” eccetera.
C’è poi la possibilità di ottenere i dati della query con un wget via API al https://overpass-api.de/api/interpreter?data=
Per fare questo basta seguire il menu per “esporta query compatta” e si può ottenere un URL con il testo della query già encoded.
I lug non hanno tutti una sede fissa, quindi in quei casi ha senso mettere il centro città
I negozi hanno delle problematiche, del tipo se ci sono ancora ecc
Non tutti i lug e i negozi sono su osm per i motivi sopra citati
Entrambi linuxsi e lugmap sono fatti nello stesso modo lato tecnologico
Unificare il software che li genera e semplificarli era l’idea di fondo
Se abbandoniamo il sistema attuale in txt per un json sicuramente semplifica per poter fare una mappa
QGIS sicuramente non ci aiuta ma se noi trattiamo il json generato dopo tutta la pulizia e integrazione e poi non lo usiamo più (qgis) sicuramente ci semplifichiamo la vita
valerio.bozzolan
Fra l’altro, che fai di bello lunedì ore 21:00? magari possiamo dare un’occhiatina dal vivo al tuo lavoro su QGIS. Ogni lunedì a quell’ora ci incontriamo online. Se ti farebbe piacere io curioserei volentieri QGIS
Ho controllato in agenda… per i prossimi 7 lunedì… assolutamente nulla
mte90
Allora tante cose tutte insieme:
I lug non hanno tutti una sede fissa, quindi in quei casi ha senso mettere il centro città
Perchè in una mappa almeno una localizzazione approssimativa mi pare dovuta. Se io suppongo che la pagina venga vista da chi cerca aiuto o riferimento, più o meno dov’è l’associazione si dovrebbe mettere.
I negozi hanno delle problematiche, del tipo se ci sono ancora ecc
Molti ci sono ma, a vedere da come si propongono sono “poco” amici. Poi altri riferimento sono a ditte che non vendono a privati. Utile indicarle se operano “adeguatamente” con software libero, ma andrebbero divisi per non creare confusione.
Non tutti i lug e i negozi sono su osm per i motivi sopra citati
A parte alcuni, evidenziati nel riassunto, quasi tutti indicano almeno un sito web, da lì dare la collocazione geografica è stato solo un po’ di lavoro.
Entrambi linuxsi e lugmap sono fatti nello stesso modo lato tecnologico
Unificare il software che li genera e semplificarli era l’idea di fondo
OK
Se abbandoniamo il sistema attuale in txt per un json sicuramente semplifica per poter fare una mappa
E’ quello che provo a fare, appena sta in piedi (almeno un po’) lo propongo.
QGIS sicuramente non ci aiuta ma se noi trattiamo il json generato dopo tutta la pulizia e integrazione e poi non lo usiamo più (qgis) sicuramente ci semplifichiamo la vita
Infatti questo mi era diventato chiaro nei messaggi precedenti. Qgis è solo un tool per fare del lavoro, non viene affatto coinvolto successivamente nel funzionamento del sito.
Aggiunta.
Ho notato che la mappa presente sulla pagina https://www.ils.org/info/ è “in fondo” equivalente a quella presente su https://lugmap.linux.it/mappa/.
Sulla prima non ci sono tutti i lug, credo che questo dipenda dallo stato di adesione a ILS, inoltre si distingue tra associazioni e sezioni locali (che in mappa LUG sono presentati come gli altri LUG).
Ma a questo punto non sarebbe meglio unificare tutto, aumentare dove necessario i campi in modo da poter selezionare e poi fare sempre solo riferimento ad un unico DB? Fare un solo codice che genera la mappa partendo da questi dati, filtrandoli in base ai dati della chiamata?
Ho partecipato alla riunione sul linux day, ma siccome sono senza mic al PC ed i tentativi di usare il tablet provocavano un fastidiosissimo effetto larsen mi sono zittito.
Sono poco social e poco smart, Quindi dimmi cosa conteresti di usare che vedo come posso adattarmi al meglio.
Ogni lunedì ore 21:00 c’è almeno una persona online qui per mandare avanti sviluppi interni
Se non funziona il microfono del computer nessun problema. Workaround: entrare anche da un telefono, collegando normali cuffie al telefono. Poi comunque ci si può unire, mutati, da altri desktop in casa, per condividere schermi ecc.
Ho messo tutto più o meno assieme, dire che cammina forse è troppo… però sta in piedi
Ho messo il codice su Github ed il tutto sul mio solito sito da prove varie.
I dati sono tutti in file js, come già detto, e sono sostanzialmente dei GeoJSON.
Sono divisi in 3 file e sono nella cartella layers (lfs_1, lug_2 e naz_1) I file sono generati dal plugin di Qgis.
Ci sono 4 file html nella cartella principale.
index.html che non fa altro che mettere assieme altri due file html (poco utile, ma per avere un punto di partenza con le due cose map e list)
index-lug.html che è la mappa dei LUG oltre che delle due associazioni nazionali
index-lfs.html è invece la mappa dei negozi LinuxSI
index-l.html che genera la lista a partire dei file GeoJSON Per ora c’è solo la versione per i LUG, per i LinuxSI… si vedrà poi, ma è la stessa cosa.
Il codice è qui
Per velocità ho copiato direttamente la direttrice principale.
Per vedere come viene si può andare qui
la pagina index.html mostra index-lug e index-l. Per le altre pagine correggere il nome del file.
Il tutto è brutto (ci verrebbe un po’ di css… anzi anche un po’ di più), però rende l’idea.
La mappa è quella già vista, ma nella pagina in cui è inclusa (index) se il popup è lungo viene tagliato. Nella sua pagina diretta il problema è minore. Il funzionamento però resta quello. La ricerca sul campo nome non funziona, ma per ora non mi ci sono dedicato, in una versione precedente andava bene.
La lista parte completa, tutti 103 i LUG (per ora non include le ass nazionali).
sulla lista si può fare la ricerca, il sort ed il filtro sulla regione. Per ora solo due per capire.
Per fare questo è stato aggiunto il campo regione e visto che c’ero ho messo anche il campo “sezione ILS”, per ora inutile.
La lista la semplificherei eliminando l’URL e mettendo direttamente il link al nome o su tutta la riga.
Tante altre cose sono da rivedere, ma siccome a questo punto ho raggiunto un risultato che mi è sufficiente per il lavoro che sto facendo sulle vigne in zona, per me lo sviluppo potrebbe anche finire. Quindo per procedere oltre devo sapere se la direzione va bene e l’impostazione piace oppure no.
Nel primo caso rifinisco un po’ di cose e gli do un aspetto migliore e poi metterei tutto su un repo che vada bene a tutti e dove anche altri (magari più bravi e pratici di me con HTML, DOM e JS possano dire, fare, correggere, ecc…
La pagina della lista dovrebbe essere richiamata passando il parametro regione per avere la visualizzazione per regione come nella versione attuale, tuttavia lascerei sempre (magari con una dropdown list) la possibilità di cambiare il filtro nella pagina per non dovere fare avanti ed indietro.
Grazie Mauromago per non rischiare di dimenticarmi questa tua implementazione la segno anche qui, dove avviene lo sviluppo software della LUGMap:
Probabilmente ti rispondo in settimana. Principalmente se ho capito correttamente ti farebbe piacere se fosse la LUGMap in primis ad esporre delle API che generino dei GeoJSON, invece che darti dei file “TXT” scomodi. Ho capito bene?
Rispondo per segnalare che il mio sito andrà probabilmente a riposo e ne farò uno nuovo, magari metto un redirect ma non sono sicuro.
Ora sono in prevendemmia e poi sarò in vendemmia (il che vuol dire Linux day?) ma dopo per riprendere il discorso ci sono, magari di persona una volta perchè così mi pare anche un po’ complicato.
M
per non rischiare di dimenticarmi questa tua implementazione la segno anche qui, dove avviene lo sviluppo software della LUGMap: