Re: [Talk-it] Uniformità dei dati e strumento keepright
Quello di cui si parlava (beta) [1] http://www.gpstracks.it/index.php/openstreetmap/134-osm-form-peaks.html ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Stefano Salvador stefano.salva...@gmail.com: Ed allora com'è che spesso sulle carte topografiche trovo l'altezza arrotondata al decimetro? le carte topografiche vengono realizzate con strumenti di misura estremamente precisi (ad esempio GPS topografici lasciati in misura per giorni) e appoggiandosi a geoidi ufficiali prodotti dall'IGM. E anche con tutte queste accortezze il massimo che si ottiene è una precisione attorno al decimetro o poco meno. io non avevo pensato di misurare l'altezza col GPS, ma invece credo che spesso si prendono altezze indicate sul luogo (ci sono delle targhe per esempio). Comunque stiamo discutendo di lana caprina, gli esempi che ha fatto gpstracks riportano una precisione assurda che vuol dire solo che il mappatore ha copiato acriticamente il dato del GPS. In quel caso eliminare di decimali è solo una cosa buona. credo invece che questi numeri lunghi derivano da conversioni algoritmici (conversione da un sistema a l'altro). Cmq., millimetri e inferiore non hanno nessun senso, concordo, mentre a partire del centimetro potrebbe avere un senso, anche se col GPS un metro di precisione è illusorio. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Uniformità dei dati e strumento keepright
Buongiorno e scusate il lungo post. Sto preparando uno script che permetta la ricerca e la modifica dei dati riguardanti la feature natural=peak L’idea è quella di definire dei canoni qualitativi minimi entro i quali tenere i valori assegnati alle diverse chiavi. Questo è un’abbozzo di strumento per il controllo di alcuni valori per una determinata feature. La procedura è volutamente semiautomatica, presuppone la validazione delle modifiche da parte dell'utente. Il funzionamento è il seguente: Data un’area (selezionabile tramite bounding box) e/o un nome utente, viene eseguita la richiesta al database OSM. Ottenuti ed analizzati i dati secondo i criteri spiegati di seguito, vengono proposte le modifiche alle key name=* ed ele=* che presentano anomalie. Ogni modifica, come già detto, sarà solamente proposta. Manualmente sarà possibile accettarla così com’è, modificarla o scartarla (oppure verificare lo stato di fatto sulla mappa o tramite controllo remoto) Alla fine de processo viene restituito un file .osm pronto per essere caricato tramite l’editor preferito (per il momento è stato testato solo JOSM) Anomalie delle quali propone la modifica sul tag “name”: Maiuscole – minuscole [1] (con euristica: cerca di lasciare alcune parole in minuscolo fra cui articoli, preposizioni semplici ed articolate, aggettivi – es: superiore, inferiore, meridionale, settentrionale..) Spazi doppi Trim (spazi iniziale e finali) Abbreviazioni Caratteri speciali – accenti Spaziatura fra indicazione bilingue ( nome1/nome2 → nome1 / nome2) Spazi non digitati ( Nome1Nome2 ) Anomalie delle quali propone la modifica sul tag “ele”: Indicazione dell'unità di misura (elimina – come da prescrizione ufficiale tagging) [2] Caratteri non numerici Numeri troppo piccoli o troppo grandi Arrotonda all'intero più vicino Per vari motivi non sono riuscito a proporre una ‘selezionabilità’ delle anomalie di cui sopra. Sarà quindi lasciato all’utilizzatore l’onere di accettare o meno le modifiche proposte. Il dubbio sul quale volevo conoscere il vostro parere è il seguente: Sul tag “ele=*” ho predisposto la funzione per arrotondare i valori all’intero più vicino poiché ritengo che in un dato di altitudine terrestre non sia necessaria la precisione decimale, né a livello di rendering (una cosa così [3] e [4] non si può guardare), né a livello di database. Gli strumenti con i quali solitamente vengono rilevati i valori per OSM (cartografia commerciale, GPS o DEM ) non permettono una approssimazione così fine, ed anche ammettendo che sia possibile eseguire un rilievo con tale precisione, per conto mio la sua utilità è nulla. L’uso di questo strumento non presenta particolari problemi per quanto riguarda la possibilità di interventi errati o dannosi (non più di un qualsiasi editor). Purtroppo la procedura risulta leggermente “macchinosa”. Da parte di un singolo utente sarebbe comunque possibile controllare e correggere (o vandalizzare) i valori anomali di elevazione in tutta Italia in poco tempo. [1] http://wiki.openstreetmap.org/wiki/IT:Key:name [2] http://wiki.openstreetmap.org/wiki/Key:ele [3] http://www.openstreetmap.org/browse/node/519825195 [4] http://www.openstreetmap.org/?lat=45.2627lon=7.0513zoom=14layers=M ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Hai informato anche la ML internazionale e quella degli sviluppatori di questo tuo strumento? 2011/12/11 gpstracks.it m...@gpstracks.it: Buongiorno e scusate il lungo post. Sto preparando uno script che permetta la ricerca e la modifica dei dati riguardanti la feature natural=peak L’idea è quella di definire dei canoni qualitativi minimi entro i quali tenere i valori assegnati alle diverse chiavi. Questo è un’abbozzo di strumento per il controllo di alcuni valori per una determinata feature. La procedura è volutamente semiautomatica, presuppone la validazione delle modifiche da parte dell'utente. Il funzionamento è il seguente: Data un’area (selezionabile tramite bounding box) e/o un nome utente, viene eseguita la richiesta al database OSM. Ottenuti ed analizzati i dati secondo i criteri spiegati di seguito, vengono proposte le modifiche alle key name=* ed ele=* che presentano anomalie. Ogni modifica, come già detto, sarà solamente proposta. Manualmente sarà possibile accettarla così com’è, modificarla o scartarla (oppure verificare lo stato di fatto sulla mappa o tramite controllo remoto) Alla fine de processo viene restituito un file .osm pronto per essere caricato tramite l’editor preferito (per il momento è stato testato solo JOSM) Anomalie delle quali propone la modifica sul tag “name”: Maiuscole – minuscole [1] (con euristica: cerca di lasciare alcune parole in minuscolo fra cui articoli, preposizioni semplici ed articolate, aggettivi – es: superiore, inferiore, meridionale, settentrionale..) Spazi doppi Trim (spazi iniziale e finali) Abbreviazioni Caratteri speciali – accenti Spaziatura fra indicazione bilingue ( nome1/nome2 → nome1 / nome2) Spazi non digitati ( Nome1Nome2 ) Anomalie delle quali propone la modifica sul tag “ele”: Indicazione dell'unità di misura (elimina – come da prescrizione ufficiale tagging) [2] Caratteri non numerici Numeri troppo piccoli o troppo grandi Arrotonda all'intero più vicino Per vari motivi non sono riuscito a proporre una ‘selezionabilità’ delle anomalie di cui sopra. Sarà quindi lasciato all’utilizzatore l’onere di accettare o meno le modifiche proposte. Il dubbio sul quale volevo conoscere il vostro parere è il seguente: Sul tag “ele=*” ho predisposto la funzione per arrotondare i valori all’intero più vicino poiché ritengo che in un dato di altitudine terrestre non sia necessaria la precisione decimale, né a livello di rendering (una cosa così [3] e [4] non si può guardare), né a livello di database. Gli strumenti con i quali solitamente vengono rilevati i valori per OSM (cartografia commerciale, GPS o DEM ) non permettono una approssimazione così fine, ed anche ammettendo che sia possibile eseguire un rilievo con tale precisione, per conto mio la sua utilità è nulla. L’uso di questo strumento non presenta particolari problemi per quanto riguarda la possibilità di interventi errati o dannosi (non più di un qualsiasi editor). Purtroppo la procedura risulta leggermente “macchinosa”. Da parte di un singolo utente sarebbe comunque possibile controllare e correggere (o vandalizzare) i valori anomali di elevazione in tutta Italia in poco tempo. [1] http://wiki.openstreetmap.org/wiki/IT:Key:name [2] http://wiki.openstreetmap.org/wiki/Key:ele [3] http://www.openstreetmap.org/browse/node/519825195 [4] http://www.openstreetmap.org/?lat=45.2627lon=7.0513zoom=14layers=M ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Il 11/12/2011 12.04, Maurizio Napolitano ha scritto: Hai informato anche la ML internazionale e quella degli sviluppatori di questo tuo strumento? No, perchè come detto non si tratta di un bot, e poi, l'euristica che ho preparato per i nomi riguarda solo l'Italia. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 gpstracks.it m...@gpstracks.it: Spaziatura fra indicazione bilingue ( nome1/nome2 → nome1 / nome2) di solito è meglio avere (anche in più) 2 tags (name:it, name:fr) anzichè un name con 2 valori. La sintassi generale per 2 valori è la separazione col semicolon. Anomalie delle quali propone la modifica sul tag “ele”: Indicazione dell'unità di misura (elimina – come da prescrizione ufficiale tagging) [2] Caratteri non numerici cosa significa elimina? Fai una conversione da altri unità al metro? Numeri troppo piccoli o troppo grandi quali separatori decimali intendi di interpretare e come (. vs ,) Arrotonda all'intero più vicino -1, se il mapper ha ritenuto di mappare ciffre decimali non vedo un grande senso di fare questa operazione dentro al database, e 214.6 non è 215. Se ti disturbino questi valori li puoi trasformare prima di utilizzare i dati nella tua applicazione, non nel database. Sul tag “ele=*” ho predisposto la funzione per arrotondare i valori all’intero più vicino poiché ritengo che in un dato di altitudine terrestre non sia necessaria la precisione decimale, né a livello di rendering (una cosa così [3] e [4] non si può guardare), né a livello di database. sono d'accordo al livello di rendering, ma non credo che debba essere modificato il livello database (o meglio credo che la precisione di un metro suggerita da te è inferiore della precisione di alcuni punti misurati). Gli strumenti con i quali solitamente vengono rilevati i valori per OSM (cartografia commerciale, GPS o DEM ) non permettono una approssimazione così fine, ed anche ammettendo che sia possibile eseguire un rilievo con tale precisione, per conto mio la sua utilità è nulla. dato che per conto tuo la utilità è nulla lo vuoi eliminare dal database? [3] http://www.openstreetmap.org/browse/node/519825195 concordo che la precisione indicata è assurda, ma non vedo problemi per esempio nel rendering se fatto bene. Tra altro è ambiguo questo nodo (sia in OSM che anche quello che si trova con Google rapporta valori da 2842 a 3006 m). Probabilmente i diversi valori sono dovuti a sistemi di riferimento diverso (riccordo che usiamo sempre WGS84 in OSM). Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
No, perchè come detto non si tratta di un bot, e poi, l'euristica che ho preparato per i nomi riguarda solo l'Italia. Certo! ma puo' essere usato da altri. Ancora di piu' se poi distribuisci il codice sorgente. Giusto una curiosita'. Ho visto il tuo sito e mi e' caduto l'occhio sulla licenza dei dati http://www.gpstracks.it/index.php/licenza.html In pratica cc-by-sa-nc ... quindi non compatibile con OSM. Peccato :( Come mai? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Martin Koppenhoefer dieterdre...@gmail.com: Arrotonda all'intero più vicino -1, se il mapper ha ritenuto di mappare ciffre decimali non vedo un grande senso di fare questa operazione dentro al database, e 214.6 non è 215. Se ti disturbino questi valori li puoi trasformare prima di utilizzare i dati nella tua applicazione, non nel database. un esempio megli sarebbe: 1999.6 non sono 2000 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Il 11 dicembre 2011 12:21, Martin Koppenhoefer ha scritto: se il mapper ha ritenuto di mappare ciffre decimali non vedo un grande senso di fare questa operazione dentro al database, e 214.6 non è 215. Se ti disturbino questi valori li puoi trasformare prima di utilizzare i dati nella tua applicazione, non nel database. +1 anche le anomalie sugli spazi vanno eliminate nell'applicazione (se si ha un algoritmo che evidenzia gli errori sugli spazi probabilmente sei in grado di correggerli automaticamente per la propria applicazione) perché se vuoi dai dati omogenei non ti puoi affidare al database che è in continua evoluzione sono comunque d'accordo che un utente sistemi anche gli spazi quando corregge manualmente errori che il programma non può correggere, quindi ben venga questo strumento di controllo -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Daniele Forsi dfo...@gmail.com: sono comunque d'accordo che un utente sistemi anche gli spazi quando corregge manualmente errori che il programma non può correggere, quindi ben venga questo strumento di controllo +1, anch'io credo che questo strumento può essere utile, e volevo solamente indicare qualche potenziale problema. Nel dubbio credo sia meglio non applicare modifiche probabilmente migliori ma lasciare i dati, e per la precisione suggerisco una precisione di 1 cm anzichè un metro (anche se nella maggiorparte dei casi reali già un metro è più preciso che il dato rilevato da noi). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 gpstracks.it m...@gpstracks.it: Sul tag “ele=*” ho predisposto la funzione per arrotondare i valori all’intero più vicino poiché ritengo che in un dato di altitudine terrestre non sia necessaria la precisione decimale, Propongo un compromesso: arrotondare al centimetro Per arrotondamenti superiori si potrebbe lasciare al rendering Viceversa numeri con precisione maggiore sono senza senso (basta spostare un sasso e cambia l'altitudine) Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Martin Koppenhoefer dieterdre...@gmail.com: di solito è meglio avere (anche in più) 2 tags (name:it, name:fr) anzichè un name con 2 valori. La sintassi generale per 2 valori è la separazione col semicolon. Nel caso di valori multipli (es cuisine=italian;pizza) hai ragione. Qui invece si sta parlando di un valore solo, il tag name, che viene mostrato così com'è dal rendering Mi spiego meglio: se i due nomi sono in due lingue diverse, oppure sono uno il nome ufficiale e l'altro il nome locale, allora il sistema di tagging di OSM permette di mappare bene questa diversità Se invece è ad esempio un nome bilingue e non c'è modo di scegliere una lingua preferenziale (mi vengono in mente le aree bilingui) allora mi sembra meglio separare in maniera estetica proprio perché è funzionale al rendering. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Federico Cozzi f.co...@gmail.com: 2011/12/11 Martin Koppenhoefer dieterdre...@gmail.com: di solito è meglio avere (anche in più) 2 tags (name:it, name:fr) anzichè un name con 2 valori. La sintassi generale per 2 valori è la separazione col semicolon. Qui invece si sta parlando di un valore solo, il tag name, che viene mostrato così com'è dal rendering come un tag viene mostrato dipende sempre dalle regole, anche name non deve per forza essere mostrato com'è. Nei miei rendering avevo per esempio una regola che mi faceva omettere i name=fixme. Mi spiego meglio: se i due nomi sono in due lingue diverse, oppure sono uno il nome ufficiale e l'altro il nome locale, allora il sistema di tagging di OSM permette di mappare bene questa diversità Se invece è ad esempio un nome bilingue e non c'è modo di scegliere una lingua preferenziale (mi vengono in mente le aree bilingui) allora mi sembra meglio separare in maniera estetica proprio perché è funzionale al rendering. secondome mettere i singoli nomi in tags name:it, name:de ecc. ha sempre senso, e volendo si potrebbe anche omettere un name per facilizzare il lavoro dei renderer (così non devono capire che si tratta di un valore multilingue in name). Oppure si potrebbe mettere (in più) un tag name con valore artificiale (composto), e se guardo la mappa esistente vedo che qualcuno usa - (al meno in Belgio e a Bruxxels). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Il 11/12/2011 12.19, Martin Koppenhoefer ha scritto: di solito è meglio avere (anche in più) 2 tags (name:it, name:fr) anzichè un name con 2 valori. La sintassi generale per 2 valori è la separazione col semicolon. La correzione si riferisce a tags già esistenti Anche io, se lo conosco, metto un name per ogni lingua, era solo per uniformare quelli che esistono già in questo modo. A parte che Nome1;Nome2 non ne ho trovati, ed ammettendo che sia la forma accettata: Nome1 - spazio - semicolon - spazio - Nome2 oppure Nome1 - semicolon - Nome2 ? Comunque a me pare che nelle zone di confine con l'Italia, la forma più diffusa sia Nome1 / Nome2 con qualche presenza di Nome1 - Nome2 cosa significa elimina? Fai una conversione da altri unità al metro? Il valore di ele va indicato solo in *metri* e *senza* unità di misura (dovrebbe esserci solo il numero). Se un dato è sbagliato sarebbe meglio correggerlo. Arrotonda all'intero più vicino -1, se il mapper ha ritenuto di mappare ciffre decimali non vedo un grande senso di fare questa operazione dentro al database, e 214.6 non è 215. Se ti disturbino questi valori li puoi trasformare prima di utilizzare i dati nella tua applicazione, non nel database. sono d'accordo al livello di rendering, ma non credo che debba essere modificato il livello database (o meglio credo che la precisione di un metro suggerita da te è inferiore della precisione di alcuni punti misurati). dato che per conto tuo la utilità è nulla lo vuoi eliminare dal database? Non lo farò, ma mi piacerebbe sapere la fonte di dati di altitudine precisi al centimetro, millimetro o millesimo di millimetro (le Alpi in alcuni punti guadagnano un centimetro ogni decina di anni) per pura curiosità personale. concordo che la precisione indicata è assurda, ma non vedo problemi per esempio nel rendering se fatto bene. Tra altro è ambiguo questo nodo (sia in OSM che anche quello che si trova con Google rapporta valori da 2842 a 3006 m). Probabilmente i diversi valori sono dovuti a sistemi di riferimento diverso (riccordo che usiamo sempre WGS84 in OSM). Era il mio dubbio. Ora risolto. Predispongo la proposta di arrotondamento alle due cifre decimali quali separatori decimali intendi di interpretare e come (. vs ,) A questo punto almeno uniformerei il tutto usando il . Il 11/12/2011 12.20, Maurizio Napolitano ha scritto: Giusto una curiosita'. Ho visto il tuo sito e mi e' caduto l'occhio sulla licenza dei dati ... In pratica cc-by-sa-nc ... quindi non compatibile con OSM. Peccato :( Come mai? Il sito è stato creato prima del mio interessamento ad OSM. Come avrai notato, le mappe sono quelle della concorrenza. La migrazione dei dati è già cominciata, anche se procede a rilento. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
-1, se il mapper ha ritenuto di mappare ciffre decimali non vedo un grande senso di fare questa operazione dentro al database, e 214.6 non è 215. Se ti disturbino questi valori li puoi trasformare prima di utilizzare i dati nella tua applicazione, non nel database. un esempio megli sarebbe: 1999.6 non sono 2000 in qualsiasi scienza sperimentale riportare troppe cifre significative è sempre un errore, se misuro una quota con un gps (precisione in quota di 10 metri) la misura giusta da riportare non è 1999.6 ma 2000 con un errore di 10. Se all'università avessi fatto altrimenti mi avrebbero bocciato senza indugi. Quindi indicare misure in quota con i decimali è sbagliato perché nessuno possiede uno strumento con questa precisione. Senza considerare il fatto che lo zero di queste misure (il cosidetto geoide) è anch'esso frutto di misure con precisione molto maggiori del metro. In definitiva per indicare la quota di un picco basterebbe fermarsi alle decine di metri, già scendere al metro è un'esagerazione. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Il 11/12/2011 16:24, Stefano Salvador ha scritto: Quindi indicare misure in quota con i decimali è sbagliato perché nessuno possiede uno strumento con questa precisione. Senza considerare il fatto che lo zero di queste misure (il cosidetto geoide) è anch'esso frutto di misure con precisione molto maggiori del metro. Ed allora com'è che spesso sulle carte topografiche trovo l'altezza arrotondata al decimetro? Io a volte ho inserito l'altezza di alcune cime con un decimale, perché tale era la cifra indicata sulla carta (libera) usata come fonte. -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Ed allora com'è che spesso sulle carte topografiche trovo l'altezza arrotondata al decimetro? le carte topografiche vengono realizzate con strumenti di misura estremamente precisi (ad esempio GPS topografici lasciati in misura per giorni) e appoggiandosi a geoidi ufficiali prodotti dall'IGM. E anche con tutte queste accortezze il massimo che si ottiene è una precisione attorno al decimetro o poco meno. Con i GPS di classe escursionistica non è pensabile di andare oltre a qualche metro di precisione (che di solito hanno caricato un geiode approssimato). Comunque stiamo discutendo di lana caprina, gli esempi che ha fatto gpstracks riportano una precisione assurda che vuol dire solo che il mappatore ha copiato acriticamente il dato del GPS. In quel caso eliminare di decimali è solo una cosa buona. Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
In data domenica 11 dicembre 2011 16:59:33, Giacomo Boschi ha scritto: Io a volte ho inserito l'altezza di alcune cime con un decimale, perché tale era la cifra indicata sulla carta (libera) usata come fonte. Per curiosità a che carta libera ti riferisci? Io uso le carte dell'impero austroungarico. Vedo che le quote metro su metro sono giù corrispondenti a quelle riportate su carte topografiche moderne. http://commons.wikimedia.org/w/index.php?title=Category:3rd_Military_Mapping_Survey_of_Austria- Hungary Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
Il 11/12/2011 18:04, Alessio Zanol ha scritto: Per curiosità a che carta libera ti riferisci? Quelle del wms toscano: http://web.rete.toscana.it/sgr/webgis/consulta/viewer.jsp Le ctr hanno le quote con i decimetri. Addirittura ora mi sono accorto che ci sono i punti quotati con le quote al centimetro. -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Giacomo Boschi gwil...@gmail.com: Le ctr hanno le quote con i decimetri. Addirittura ora mi sono accorto che ci sono i punti quotati con le quote al centimetro. Occhio che le CTR sono spesso fatte rispetto al geoide Roma 1940, che è diverso da quello WGS84. Pertanto se non trasformi l'altitudine (esattamente come si fa per le altre coordinate lat e lon) ti ritrovi delle altitudini errate, cioè i cui decimali (e magari anche i metri) non sono corretti dal punto di vista di OSM. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
2011/12/11 Alessio Zanol nar...@infinito.it: Io uso le carte dell'impero austroungarico. Vedo che le quote metro su metro sono giù corrispondenti a quelle riportate su carte topografiche moderne. Di una quota di una mappa austro-ungarica mi fiderei al massimo della decina di metri, tra errori di misura e cambi di geoide! Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Uniformità dei dati e strumento keepright
In data domenica 11 dicembre 2011 22:35:45, Federico Cozzi ha scritto: Di una quota di una mappa austro-ungarica mi fiderei al massimo della decina di metri, tra errori di misura e cambi di geoide! Ma certamente! Come del resto ci si accontenta della decina di metri di molti altri dati osm. Se più avanti ci saranno dati più precisi, ben vengano. :) Alessio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
