Allora mi focalizzerei nel fare una PR verso linuxsi così vediamo che modifiche bisogna fare per integrare la mappa per regione ecc
Poi passiamo alla lugmap che è più complessa.
Non sono del tutto sicuro di cosa tu intenda per PR, ipotizzo “public relation”.
Tuttavia credo che, visto quello che ho visto navigando nei vari siti, sarebbe bene definire aprioristicamente un setaccio per capire chi sono le attività commerciali “amiche del Software libero”. Anche per non lasciare ai singoli l’onore, ma sopratutto, l’onere di decidere senza riferimenti.
Per come la vedo io essere individuati in tale modo è contemporaneamente un servizio all’utente per ricercare assistenza e promozione di un’attività economica. In entrambi i casi occorrerebbe che uno standard minimo sia definito.
cosa intendi integrare la mappa per regione?
Non credo che la parte dei LUG sia più complessa, o mi perdo qualche passaggio!
PS al LFS di Bra passo io tra qualche giorno. A quello di Torino potrei andare domani, ma ipotizzo che sia noto a chi è del posto, quindi eviterei.
Intende pull request.
Ah! Segno per la prossima volta 
Allora ho bisogno di una pull request sul repo su gitlab con la modifica.
Poi come definire i negozi presenti sul sito lo farei successivamente ma mi preoccuperei di avere questa mappa in ogni regione perché il sito di linuxsi ha pagine per regione LinuxSi: Lazio
Non pensavo di mettere io le mani sul sito, preparavo i pezzi e poi li lasciavo assemblare a chi solitamente ci lavora sopra. Comunque vediamo, ci darò un’occhiata.
Forse ho frainteso all’inizio, ed uniformare non deve intendersi come unire, ma rifarli usando la stessa base è quello che io pensavo come obbiettivo minimo. Altrimenti non capisco il senso di tutto il lavoro.
Per la mappa divisa per regione mi pare più complicato, specialmente se si pensava di unificare. Solo la lista invece non dovrebbe essere difficile anche mantenendo un solo DB.
Se si mettono i negozi su layer distinti per regione si può accendere e spegnere le varie regioni, ma la lista dei layer diventa lunga ed il vantaggio mi pare limitato. Qual è il problema a tenere una mappa completa?
Fare una mappa completa significa ristrutturare entrambi i siti che ad oggi sono divisi per regione.
Però va bene possiamo anche partire dal tuo progetto e vedere come unificare il tutto noi direttamente.
Allora direi di aspettare che riesca a tirare fuori la tabella dai dati così strutturati, poi rifacciamo il punto.
Però a quanto vedo oggi i siti, tutti e due, estraggono la tabella per regione, mentre la mappa e completa.
Appena ho fatto per le tabelle lo scrivo qui.
Non sono morto Ho dovuto toglire un po’ di ruggine dal mio html/js. In particolare sono un po’ nei problemi con la libreria JS che intenderei usare; list.js
Ho studiato e sto studiando il problema, vediamo se riesco ad arrivare ad una soluzione.
Ho aperto in proposito un issue su github ed una question su stack overflow. Vediamo se qualcuno mi riesce ad aiutare. Se tra chi legge qui c’è chi conosce bene questa librerie, faccia un fischio e provo a spiegare meglio il problema.
Tutto questo per usare i dati nel formato originale senza farne prima il parsing. Se entro qualche giorno non sarò riuscito a venirne a capo, adotterò la soluzione alternativa.
Non puoi semplicemente fare qualcosa tipo
json_2.map(x => x.properties}).map(x => x.zona + " - " + x.nome)
O non ho capito quale sia il tuo problema.
Non è un problema, solo che se riesco ad usare direttamente il dato provo a tenere il tutto al livello di massima semplicità e compattezza possibile.
Poi come detto, se la cosa non si può fare o non ci riesco, andrò su altre soluzioni.
So che con list.js non si possono gestire le liste nidificate, ma non ho trovato nulla sulla possibilità di utilizzare i dati di oggetti nidificati.
Comunque mi copio negli appunti la riga di codice 
QGis quali formati apprezza?
Se gli piace anche solo un enorme GeoJSON, glielo esportiamo in fretta da PHP.
Premettendo che per unificare i dati comunque servirà un identificativo univoco fra Italian Linux Society ed OpenStreetMap, e di questo potrebbe occuparsene Wikidata.
Per esempio questo è il Free Circle di Palermo con il tag di Wikidata:
Quindi se Italian Linux Society ha un suo elenco dei LUG associati a Wikidata, e OpenStreetMap anche, è facile fare una unione e vedere cosa manca e cosa aggiungere / cosa aggiornare ecc.
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.
PS se sono contromano… ditemelo
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
[1] Import/ODbL Compatibility - OpenStreetMap Wiki
[2] overpass turbo
@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):
A margine quest’ultimo repository Linuxsì su GitHub sarà da migrare su GitLab - segnato qui: (Import "LinuxSI" from GitHub, update README, mention the new repository on the homepage (#45) · Issues · Italian Linux Society / Brainstorm · GitLab)
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.
Io ero partito più o meno con quest’idea.
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