Occhio che esistono sia ele:source che source:ele ma solo quest’ultimo è documentato sulla wiki e indica effettivamente " the source of the elevation altitude"; è anche molto più utilizzato secondo Taginfo (~100k vs ~3k).
Hai ragione, ho invertito le cose! @Gjanosh61 ho sbagliato, i tag sono “invertiti”.
Mi fa piacere che, poco a poco, si stia facendo chiarezza su questo argomento. Ho notato che nella pagina wiki di source:ele non è presente la voce source:ele=DEM Sentinel-1. Posso aggiungerla per maggiore completezza?
Inoltre, qualche ora fa ho effettuato un changeset in blocco relativo alle elevazioni, ma ho utilizzato il tag sbagliato. Vorrei sapere: è possibile annullare quell’invio? Se sì, quale sarebbe la procedura corretta per farlo e inviare nuovamente i dati con il tag corretto, ossia source:ele=DEM Sentinel-1?
Non penso ci siano problemi.
Immagino il changeset sia Changeset: 163991399 | OpenStreetMap. Non c’è bisogno di annullarlo, basta correggere i tag dei vari elementi
io in questi casi non metterei nessun tag ele, e se volessi avere informazioni interpolate prenderei un modello altimetrico e farei quello che stai facendo tu, ma senza caricarlo su OpenStreetMap
Concordo pienamente con Martin non ha nessun senso aggiungere questa tipologia di dati, possono essere altamente imprecisi. Ti chiederei di revertare tutte le ele che hai aggiunto in questo modo.
Grazie mille
Luca
Grazie per i vostri feedback, Martin e Luca. Apprezzo davvero l’importanza che date alla precisione e verificabilità dei dati in OSM. Vorrei condividere che i miei dati provengono dal satellite Sentinel 1 (SAR), con una risoluzione orizzontale di circa 10 metri. Questa accuratezza è, secondo me, superiore rispetto ai dati SRTM 1 arc sec già presenti in OSM, che hanno una risoluzione di 30 metri.
Comprendo, tuttavia, le vostre preoccupazioni sull’inserire valori che non derivano da misurazioni dirette sul campo. Mi chiedo però se sia realisticamente possibile disporre di dati di elevazione sempre assolutamente precisi, considerando che molte informazioni altimetriche in OSM potrebbero già derivare da modelli e non da misurazioni puntuali.
Sono comunque aperto a trovare una soluzione condivisa: se ritenete che il mio approccio possa essere migliorato o corretto, sarei felice di collaborare. Purtroppo non ho le competenze tecniche per effettuare un revert, né so cosa revertare esattamente dato che i dati di elevazione non esistevano precedentemente e sono disponibile a ricevere supporto o indicazioni al riguardo.
Grazie ancora per la vostra attenzione e disponibilità a discutere!
Giovanni
ciao Giovanni,
non abbiamo dati SRTM 1 in OSM, ci sono delle mappe che utilizzano OpenStreetMap insieme ai dati SRTM, ma in OpenStreetMap non ci sono.
Ciao Martin,
Grazie per la risposta. Ho letto nel wiki di OSM che il tag ele=
è raccomandato per indicare l’elevazione di una vetta (natural=peak
), ma ho notato che i dati di elevazione, come SRTM, non sono inclusi direttamente nel database OSM. Al tempo stesso, alcune mappe basate su OSM mostrano linee di contorno generate da SRTM 1 arcsec.
Mi chiedo:
- È accettabile utilizzare valori di elevazione da fonti esterne come SRTM per compilare manualmente il tag
ele=
? - Come si concilia questa raccomandazione con il fatto che i dati SRTM non sono direttamente inclusi in OSM?
Vorrei aggiungere una riflessione. Ho notato che il tag ele=*
è molto comune in OSM e sembra improbabile che tutte queste quote siano state determinate manualmente senza fare uso di dati DEM, come SRTM o ASTER.
Anche se i dati DEM non sono direttamente integrati nel database OSM, mi sembra che sia una prassi consolidata tra i mappatori utilizzare questi dati come riferimento esterno per arricchire il tagging manuale. Questo spiegherebbe perché vediamo così tanti tag ele=*
associati a vette, colline e altri punti di interesse.
Credo che un approfondimento su questo tema potrebbe aiutare a evitare ambiguità future e migliorare la coerenza delle informazioni nel database OSM. Suggerisco di avviare una discussione più ampia, magari attraverso il forum, la mailing list o un RFC, per raccogliere pareri e definire linee guida più precise.
Mi scuso per la lunghezza di questo post e nel contempo Ringrazio tutti per l’attenzione e resto in attesa delle vostre opinioni e suggerimenti!
Cordiali saluti
Giovanni
È accettabile utilizzare SRTM, Lidar, ecc., ma secondo me bisogna seguire alcune regole d’uso, per così dire. Utilizzo dati dem ad arco da 1" a condizione che i picchi non abbiano elevazioni associate, ovvero nodi natural=peak senza key ele. Correggo anche quei nodi che hanno nel commento CS che sono state utilizzate linee di contorno di un certo stile topografico o che sono stati utilizzati dati srtm di arco da 3" o risoluzione inferiore. Sebbene siano poche, nella mia zona ci sono vette con dati di altitudine abbastanza precisi, rilevati in loco o con dati ricavati dall’ente cartografico ufficiale del mio Paese.
Questa domanda necessita di un po’ di contesto perché non è chiara.
Riguardo=
Devo dire che è necessario rivederlo a fondo, alcuni nodi sono troppo vicini tra loro e segnano piccoli picchi che non dovrebbero essere in OSM, cioè hai un picco principale con piccoli altitudini diverse dalla cima principale. Secondo me dovrebbe esserci solo il picco principale, mappare quelle piccole elevazioni vicine non fa che ingombrare la mappa.
Inoltre, hai 2 nodi mappati all’interno dell’area della palude.
Vorrei anche sottolineare che i nodi sono duplicati: hai 2 CS con 66 nodi ciascuno nella stessa posizione.
È importante anche mappare i nomi delle vette: nel mio caso mappa solo le altitudini delle vette con nome, Il nome è un chiaro indicatore dell’importanza di un natural=peak, Se una cima, una montagna, ecc. ha un nome, ciò indica che si tratta di un elemento importante e adatto a far parte di OSM. La mia regione è montuosa, ovunque guardi ci sono montagne e montagne e dietro queste ancora più montagne, ma non mi è mai venuto in mente di includere tutte quelle vette e montagne in OSM, mappongo semplicemente quelli più importanti, quelli che hanno un nome o sono storici per qualche motivo o sono un elemento importante del luogo.
Forse questa immagine spiega meglio quello che sto cercando di indicare, secondo me ci sono 4 nodi rimasti e forse sarebbe meglio gestirlo come una natural=ridge se soddisfa le condizioni, cioè un natural=peak e la linea natural=ridge.
Ciao a @afgb1977 e a tutti,
Condivido alcune considerazioni e proposte per ottimizzare la mappatura dei picchi e dei nodi in OpenStreetMap:
- Picchi principali e altitudini minori: Concordo sul fatto che sia necessario focalizzarsi solo sui picchi principali. Piccole elevazioni vicine al picco principale non solo sovraccaricano la mappa, ma possono anche creare confusione. I lavori svolti finora devono essere considerati una bozza, e procederò di conseguenza per perfezionarli.
- Nodi all’interno di aree paludose: Ho notato che ci sono nodi mappati erroneamente all’interno dell’area della palude. Mi impegnerò a correggere questi errori e a migliorare la precisione della mappatura.
- Duplicazione di nodi: È stato un mio errore grossolano avere 2 CS con 66 nodi ciascuno nella stessa posizione. Mi scuso per l’inconveniente e prometto di prestare maggiore attenzione per evitare che accada nuovamente.
- Natural=ridge e natural=peak: Sto riscontrando difficoltà nel capire questa parte specifica, soprattutto in relazione alla gestione di 4 nodi rimanenti. Accetto volentieri ulteriori spiegazioni o consigli per implementare correttamente le modifiche proposte.
- Supporto alla mappatura: Se qualcuno volesse seguire queste linee guida, sono disponibile a fornire gratuitamente il DEM appropriato (nel caso fosse disponibile) e a offrire assistenza per mappare utilizzando QGis e JOSM.
Grazie mille per la vostra collaborazione e pazienza. Non esitate a condividere ulteriori suggerimenti o richieste.