Buongiorno a tutti, vi scrivo per avere un consiglio.
Sono stato coinvolto in un progetto mirato allo sviluppo di una piattaforma
WebGIS per l'analisi di dati satellitari in cui devono essere presenti anche
tool di misurazione di distanze e buffer in metri/km; il "motore" di
rendering sarà MapBox che accetta.
MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli sviluppatori
di questa libreria non sembrano intenzionati a cambiare lo status quo perchè
è una libreria pensata per la renderizzazione del dato cartografico e non
per le analisi.
Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui per
forza di cose si usa il sistema di riferimento locale e sicuramente non il
3857.
La mia strategia per aggirare il problema del SR è quella di lavorare in
4326 convertendo tramite uno script in python le distanze di buffer,
inserite dall'utente in metri, in gradi in modo che quando MapBox fa la sua
riproiezione in 3857 non ho deformazioni e tra l'altro non avrei problemi di
luoghi di provenienza dei dati essendo il 4326 globale.
Voi che strategia usereste?
Il progetto in questione usa GeoDjango e PostGIS.
-----
[1] https://docs.mapbox.com/help/glossary/projection/
[2] https://github.com/mapbox/mapbox-gl-js/issues/3184
-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
Scusare il refuso su copia ed incolla errato
....di
rendering sarà MapBox che accetta.....
*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
Il giorno sab 30 nov 2019 alle ore 09:56 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:
Buongiorno a tutti, vi scrivo per avere un consiglio.
Sono stato coinvolto in un progetto mirato allo sviluppo di una piattaforma
WebGIS per l'analisi di dati satellitari in cui devono essere presenti
anche
tool di misurazione di distanze e buffer in metri/km; il "motore" di
rendering sarà MapBox che accetta.
MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli sviluppatori
di questa libreria non sembrano intenzionati a cambiare lo status quo
perchè
è una libreria pensata per la renderizzazione del dato cartografico e non
per le analisi.
Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui
per
forza di cose si usa il sistema di riferimento locale e sicuramente non il
3857.
La mia strategia per aggirare il problema del SR è quella di lavorare in
4326 convertendo tramite uno script in python le distanze di buffer,
inserite dall'utente in metri, in gradi in modo che quando MapBox fa la sua
riproiezione in 3857 non ho deformazioni e tra l'altro non avrei problemi
di
luoghi di provenienza dei dati essendo il 4326 globale.
Voi che strategia usereste?
Il progetto in questione usa GeoDjango e PostGIS.
-----
[1] https://docs.mapbox.com/help/glossary/projection/
[2] https://github.com/mapbox/mapbox-gl-js/issues/3184
-----
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019
Quando definisci il campo geometria in geodjango con srid="EPSG:4326"
dovresti settare il flag geography a True:
https://docs.djangoproject.com/en/2.2/ref/contrib/gis/model-api/#geography
in questo modo il calcolo delle distanze terrà conto della curvatura
terrestre e sarà espresso in metri, al contrario del campo geometria
semplice che esprimerà le distanze in gradi.
Se ho capito bene il tuo problema questo accorgimento dovrebbe essere
risolutivo.
Il giorno sab 30 nov 2019 alle ore 10:11 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:
Scusare il refuso su copia ed incolla errato
> ....di
> rendering sarà MapBox che accetta.....
*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
Il giorno sab 30 nov 2019 alle ore 09:56 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:
> Buongiorno a tutti, vi scrivo per avere un consiglio.
> Sono stato coinvolto in un progetto mirato allo sviluppo di una
piattaforma
> WebGIS per l'analisi di dati satellitari in cui devono essere presenti
> anche
> tool di misurazione di distanze e buffer in metri/km; il "motore" di
> rendering sarà MapBox che accetta.
>
> MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli
sviluppatori
> di questa libreria non sembrano intenzionati a cambiare lo status quo
> perchè
> è una libreria pensata per la renderizzazione del dato cartografico e non
> per le analisi.
>
> Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui
> per
> forza di cose si usa il sistema di riferimento locale e sicuramente non
il
> 3857.
>
> La mia strategia per aggirare il problema del SR è quella di lavorare in
> 4326 convertendo tramite uno script in python le distanze di buffer,
> inserite dall'utente in metri, in gradi in modo che quando MapBox fa la
sua
> riproiezione in 3857 non ho deformazioni e tra l'altro non avrei problemi
> di
> luoghi di provenienza dei dati essendo il 4326 globale.
>
> Voi che strategia usereste?
>
> Il progetto in questione usa GeoDjango e PostGIS.
>
>
> -----
> [1] https://docs.mapbox.com/help/glossary/projection/
> [2] https://github.com/mapbox/mapbox-gl-js/issues/3184
>
> -----
> Consulente GIS, Formatore, Blogger e Ciclista Urbano
> email: info@massimilianomoraca.it
> cell: 333 5949583 (lun-ven, 9.00-18.00)
> website: massimilianomoraca.it
> --
> Sent from:
>
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> _______________________________________________
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019
Grazie mille Enrico, approfondirò a breve
Il sab 30 nov 2019, 10:39 Enrico Ferreguti <enricofer@gmail.com> ha scritto:
Quando definisci il campo geometria in geodjango con srid="EPSG:4326"
dovresti settare il flag geography a True:
https://docs.djangoproject.com/en/2.2/ref/contrib/gis/model-api/#geography
in questo modo il calcolo delle distanze terrà conto della curvatura
terrestre e sarà espresso in metri, al contrario del campo geometria
semplice che esprimerà le distanze in gradi.
Se ho capito bene il tuo problema questo accorgimento dovrebbe essere
risolutivo.
Il giorno sab 30 nov 2019 alle ore 10:11 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:
Scusare il refuso su copia ed incolla errato
> ....di
> rendering sarà MapBox che accetta.....
*ing.Massimiliano Moraca*
*Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
*P.IVA*: 08700081212
*CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
*WEB*: www.massimilianomoraca.it
* Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
Il giorno sab 30 nov 2019 alle ore 09:56 Massimiliano Moraca <
info@massimilianomoraca.it> ha scritto:
> Buongiorno a tutti, vi scrivo per avere un consiglio.
> Sono stato coinvolto in un progetto mirato allo sviluppo di una
piattaforma
> WebGIS per l'analisi di dati satellitari in cui devono essere presenti
> anche
> tool di misurazione di distanze e buffer in metri/km; il "motore" di
> rendering sarà MapBox che accetta.
>
> MapBox lavora solo con EPSG 3857[1] e dal 2016 ad oggi[2] gli
sviluppatori
> di questa libreria non sembrano intenzionati a cambiare lo status quo
> perchè
> è una libreria pensata per la renderizzazione del dato cartografico e
non
> per le analisi.
>
> Io sono abituato ad usare OpenLayers su progetti a scala "locale" in cui
> per
> forza di cose si usa il sistema di riferimento locale e sicuramente non
il
> 3857.
>
> La mia strategia per aggirare il problema del SR è quella di lavorare in
> 4326 convertendo tramite uno script in python le distanze di buffer,
> inserite dall'utente in metri, in gradi in modo che quando MapBox fa la
sua
> riproiezione in 3857 non ho deformazioni e tra l'altro non avrei
problemi
> di
> luoghi di provenienza dei dati essendo il 4326 globale.
>
> Voi che strategia usereste?
>
> Il progetto in questione usa GeoDjango e PostGIS.
>
>
> -----
> [1] https://docs.mapbox.com/help/glossary/projection/
> [2] https://github.com/mapbox/mapbox-gl-js/issues/3184
>
> -----
> Consulente GIS, Formatore, Blogger e Ciclista Urbano
> email: info@massimilianomoraca.it
> cell: 333 5949583 (lun-ven, 9.00-18.00)
> website: massimilianomoraca.it
> --
> Sent from:
>
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
> _______________________________________________
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 764 iscritti al 23/08/2019
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
764 iscritti al 23/08/2019