Scegliere il SR di un progetto a scala globale

[Massimiliano Moraca]

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: [hidden email]
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/
_______________________________________________
[hidden email]
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

[Massimiliano Moraca]

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 <
[hidden email]> 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: [hidden email]
> 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/
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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

[enricofer]

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 <
[hidden email]> 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 <
> [hidden email]> 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: [hidden email]
> > 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/
> > _______________________________________________
> > [hidden email]
> > 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
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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

[Massimiliano Moraca]

Grazie mille Enrico, approfondirò a breve

Il sab 30 nov 2019, 10:39 Enrico Ferreguti <[hidden email]> 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 <
> [hidden email]> 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 <
>> [hidden email]> 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: [hidden email]
>> > 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/
>> > _______________________________________________
>> > [hidden email]
>> > 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
>> _______________________________________________
>> [hidden email]
>> 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
>
>

_______________________________________________
[hidden email]
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