Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Risoluzione spaziale dataset

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

Giuseppe Patti

Risoluzione spaziale dataset

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

Andrea Peri

Re: Risoluzione spaziale dataset

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Giuseppe Patti

Re: Risoluzione spaziale dataset

Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

pcav

Re: Risoluzione spaziale dataset

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 15/01/2014 18:29, Giuseppe Patti ha scritto:
> Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io
> devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza
> delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni
> analoghe con soluzioni "esoteriche" anche qui:
>
> http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients
>
> http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Confermo, il problema e' serio; una discussione qui:
http://lists.osgeo.org/pipermail/qgis-developer/2014-January/030119.html
Credo ci sia un po' di lavoro da fare per rendere le analisi immuni dalle conseguenze
di questo problema.
Saluti.

- --
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlLWzMEACgkQ/NedwLUzIr6V4gCgplsQ7rAduWihJRIIuwVixjty
YskAn3os7nT8X9DpjseVE8QTTjti66XV
=pcOU
-----END PGP SIGNATURE-----
_______________________________________________
[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.
666 iscritti al 22.7.2013

Andrea Peri

Re: Risoluzione spaziale dataset

In reply to this post by Giuseppe Patti

Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:

Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013

giohappy

Re: Risoluzione spaziale dataset

Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni

Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:

Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013
_______________________________________________
[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.
666 iscritti al 22.7.2013

Giuseppe Patti

Re: Risoluzione spaziale dataset

In reply to this post by Giuseppe Patti

Mettiamola così allora: un cliente vi commissiona un dataset vettoriale in cui i vertici delle geometrie devono essere precisamente posizionati su una griglia a spaziatura omogenea XY pari a 1e^-7, eventuali cifre dopo la settima decimale devono essere al limite pari a zero, eventuali geometrie che in seguito ad operazioni di processing dovessero risultare con coordinate differenti devono essere ricondotte al caso precedente.

Come risolveremmo il problema con strumenti GFoss?

---------- Messaggio inoltrato ----------
From: "G. Allegri" <[hidden email]>
To: Andrea Peri <[hidden email]>
Cc: gfoss <[hidden email]>
Date: Wed, 15 Jan 2014 20:06:25 +0100
Subject: Re: [Gfoss] Risoluzione spaziale dataset
Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni
Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:
Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013

giohappy

Re: Risoluzione spaziale dataset

Con PostGIS e Spatialite è possibile snappare i vertici ad una griglia del genere tramite ST_SnapToGrid.

http://postgis.net/docs/ST_SnapToGrid.html

https://www.gaia-gis.it/fossil/libspatialite/wiki?name=liblwgeom-4.0

giovanni

Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <[hidden email]> ha scritto:

Mettiamola così allora: un cliente vi commissiona un dataset vettoriale in cui i vertici delle geometrie devono essere precisamente posizionati su una griglia a spaziatura omogenea XY pari a 1e^-7, eventuali cifre dopo la settima decimale devono essere al limite pari a zero, eventuali geometrie che in seguito ad operazioni di processing dovessero risultare con coordinate differenti devono essere ricondotte al caso precedente.

Come risolveremmo il problema con strumenti GFoss?
---------- Messaggio inoltrato ----------
From: "G. Allegri" <[hidden email]>
To: Andrea Peri <[hidden email]>
Cc: gfoss <[hidden email]>
Date: Wed, 15 Jan 2014 20:06:25 +0100
Subject: Re: [Gfoss] Risoluzione spaziale dataset
Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni
Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:
Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013
_______________________________________________
[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.
666 iscritti al 22.7.2013

--
Giovanni Allegri
http://about.me/giovanniallegri
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

Andrea Peri

Re: Risoluzione spaziale dataset

In reply to this post by Giuseppe Patti

Se la griglia è regolare.
Prendi spatialite, con esso ti fai generare un dataset che è una griglia rettangolare che parte da una coordinata che gli dici te e che ha un delta pari all'incremento.
Poi carichi tale dataset su qgis e forzi lo snap di tutti gli altri dataset su di esso.

Oppure altra opzione:
sempre in spatialite:

carici hi il dtaaset che devi portare su tale griglie e poi lanci:

update tabella set geometry = ST_SnapToGrid(.....)

dove li' dentro ci scrivi punto di partenza e delta.

Dovrebbe funzionare.

Io ho usato una strategia simile per troncare (brutta parola, ma è per tagliare corto) i dati del nostro DBT ristrutturato su due cifre decimali.

Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <[hidden email]> ha scritto:

Mettiamola così allora: un cliente vi commissiona un dataset vettoriale in cui i vertici delle geometrie devono essere precisamente posizionati su una griglia a spaziatura omogenea XY pari a 1e^-7, eventuali cifre dopo la settima decimale devono essere al limite pari a zero, eventuali geometrie che in seguito ad operazioni di processing dovessero risultare con coordinate differenti devono essere ricondotte al caso precedente.

Come risolveremmo il problema con strumenti GFoss?
---------- Messaggio inoltrato ----------
From: "G. Allegri" <[hidden email]>
To: Andrea Peri <[hidden email]>
Cc: gfoss <[hidden email]>
Date: Wed, 15 Jan 2014 20:06:25 +0100
Subject: Re: [Gfoss] Risoluzione spaziale dataset
Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni
Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:
Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013
_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Andrea Peri

Re: Risoluzione spaziale dataset

Aggiungo un dettaglio che forse non è trascurabile.

A parte la specifica utente:

snappare su griglia prefissata.

Se l'obiettivo vero è riprodurre la griglia del noto software commerciale.

Occorre stare molto attenti. Perche' la griglia cambia in base al box di imiego definito per il dataset.
E il processo è irreversibile.
Ovvero lo snap che egli effettua non è dinamico ma statico al momento del caricamento.
Dopodiche' resta quello.
Se poi si sposta l'archivio su altra piattaforma lo snap puo' ulteriormente cambiare.
Se poi si passa su uno shapefile, lo snap cambia ulteriormente perche' a quel punto interviene la griglia dell' FP64

E cosi' via.
Per cui non è facile stabilire la griglia esatta da usare.

Occorrerebbe tracciare tutti i passaggi pregressi.

Evito di partire con il solito pistolotto alla luna che sarebbe utile che queste cose venissero riportate nel lineage di una eventuale scheda di metadato , perche' serve proprio a profilare questo genere di situazioni. La specifica nazionale prevede altre metodiche che non incoraggiano questo tipo di informazione e quindi lascio perdere pure io.

Il giorno 16 gennaio 2014 09:03, Andrea Peri <[hidden email]> ha scritto:

Se la griglia è regolare.
Prendi spatialite, con esso ti fai generare un dataset che è una griglia rettangolare che parte da una coordinata che gli dici te e che ha un delta pari all'incremento.
Poi carichi tale dataset su qgis e forzi lo snap di tutti gli altri dataset su di esso.

Oppure altra opzione:
sempre in spatialite:

carici hi il dtaaset che devi portare su tale griglie e poi lanci:

update tabella set geometry = ST_SnapToGrid(.....)

dove li' dentro ci scrivi punto di partenza e delta.

Dovrebbe funzionare.

Io ho usato una strategia simile per troncare (brutta parola, ma è per tagliare corto) i dati del nostro DBT ristrutturato su due cifre decimali.

A.
Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <[hidden email]> ha scritto:
Mettiamola così allora: un cliente vi commissiona un dataset vettoriale in cui i vertici delle geometrie devono essere precisamente posizionati su una griglia a spaziatura omogenea XY pari a 1e^-7, eventuali cifre dopo la settima decimale devono essere al limite pari a zero, eventuali geometrie che in seguito ad operazioni di processing dovessero risultare con coordinate differenti devono essere ricondotte al caso precedente.

Come risolveremmo il problema con strumenti GFoss?
---------- Messaggio inoltrato ----------
From: "G. Allegri" <[hidden email]>
To: Andrea Peri <[hidden email]>
Cc: gfoss <[hidden email]>
Date: Wed, 15 Jan 2014 20:06:25 +0100
Subject: Re: [Gfoss] Risoluzione spaziale dataset
Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni
Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:
Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013
_______________________________________________
[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.
666 iscritti al 22.7.2013
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Giuseppe Patti

Re: Risoluzione spaziale dataset

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

On 16/01/2014 09:22, Andrea Peri wrote:

Aggiungo un dettaglio che forse non è trascurabile.

A parte la specifica utente:

snappare su griglia prefissata.

Se l'obiettivo vero è riprodurre la griglia del noto software commerciale.

Occorre stare molto attenti. Perche' la griglia cambia in base al box di imiego definito per il dataset.
E il processo è irreversibile.
Ovvero lo snap che egli effettua non è dinamico ma statico al momento del caricamento.
Dopodiche' resta quello.
Se poi si sposta l'archivio su altra piattaforma lo snap puo' ulteriormente cambiare.
Se poi si passa su uno shapefile, lo snap cambia ulteriormente perche' a quel punto interviene la griglia dell' FP64

E cosi' via.
Per cui non è facile stabilire la griglia esatta da usare.

Occorrerebbe tracciare tutti i passaggi pregressi.

Evito di partire con il solito pistolotto alla luna che sarebbe utile che queste cose venissero riportate nel lineage di una eventuale scheda di metadato , perche' serve proprio a profilare questo genere di situazioni. La specifica nazionale prevede altre metodiche che non incoraggiano questo tipo di informazione e quindi lascio perdere pure io.

A.
Il giorno 16 gennaio 2014 09:03, Andrea Peri <[hidden email]> ha scritto:
Se la griglia è regolare.
Prendi spatialite, con esso ti fai generare un dataset che è una griglia rettangolare che parte da una coordinata che gli dici te e che ha un delta pari all'incremento.
Poi carichi tale dataset su qgis e forzi lo snap di tutti gli altri dataset su di esso.

Oppure altra opzione:
sempre in spatialite:

carici hi il dtaaset che devi portare su tale griglie e poi lanci:

update tabella set geometry = ST_SnapToGrid(.....)

dove li' dentro ci scrivi punto di partenza e delta.

Dovrebbe funzionare.

Io ho usato una strategia simile per troncare (brutta parola, ma è per tagliare corto) i dati del nostro DBT ristrutturato su due cifre decimali.

A.
Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <[hidden email]> ha scritto:
Mettiamola così allora: un cliente vi commissiona un dataset vettoriale in cui i vertici delle geometrie devono essere precisamente posizionati su una griglia a spaziatura omogenea XY pari a 1e^-7, eventuali cifre dopo la settima decimale devono essere al limite pari a zero, eventuali geometrie che in seguito ad operazioni di processing dovessero risultare con coordinate differenti devono essere ricondotte al caso precedente.

Come risolveremmo il problema con strumenti GFoss?
---------- Messaggio inoltrato ----------
From: "G. Allegri" <[hidden email]>
To: Andrea Peri <[hidden email]>
Cc: gfoss <[hidden email]>
Date: Wed, 15 Jan 2014 20:06:25 +0100
Subject: Re: [Gfoss] Risoluzione spaziale dataset
Il problema degli arrotondamenti investe qualsiasi problema geometrico computazionale. Ci sono librerie come le CGAL in grado di lavorare con precisione arbitraria, ma la maggior parte dei software implementa le proprie strategie per gestire i problemi del floating point. Non so se la "portabilità della precisione" sia un problema risolvibile, certamente i software che sfruttano librerie geometriche comuni (vedi GEOS) possono sfruttarne la trasparenza per gestire la cosa, ad es. tramite il Precision Model (usato ad es. dallo SnapToGrid di PostGIS).

Mi sembra comunque che le questioni sono due:

1) come viene rappresentata una coordinata nel formato dati scelto

2) come viene gestita dal software

Il primo credo non sia un problema, visti i tanti mezzi che ci sono (dallo shapefile a PostGIS, ecc.) . Il secondo... bhè, finché un sw è chiuso c'è poco da discutere.

giovanni
Il 15/gen/2014 19:34 "aperi2007" <[hidden email]> ha scritto:
Diciamo che tra parecch softwares si spostano in maniera trasparente.

Un discorso a parte è il noto software commerciale , il quale

UNICO AL MONDO adotta una riclassificazione in "quanti" della coordinata.

Poiche' lui adotta un meccanismo che non trova riscontro in nessun altro software.
Difficile che con altri software si riesca a riprodurre la sua coordinata.
Oltre tutto , se prendi due PC con il medesimo software commerciale, non è assolutamente detto che quando sposti da uno all'altro la coordinata ti rimane invariata.
Dipende da quali altri dataset sono caricati nel medesimo DB di partenza o di destinazione.

A.

On 15/01/2014 18:29, Giuseppe Patti wrote:
Sono d'accordo, ma questo è un altro aspetto del problema. Rimane il nocciolo: se io devo spostare degli shape da un sw ad un altro, è possibile garantire la consistenza delle coordinate? Non penso sia un problema peregrino, ho trovato discussioni analoghe con soluzioni "esoteriche" anche qui:

http://gis.stackexchange.com/questions/68636/spatial-precision-for-editing-in-multiple-gis-clients

http://gis.stackexchange.com/questions/76939/qgis-polygon-precision

Il giorno 15 gennaio 2014 18:01, Andrea Peri <[hidden email]> ha scritto:

Il noto software commerciale permette di impostare la XY resolution , ma all'aumentare della resolution diminuisce la BBOX ammessa.

E viceversa.

Per cui ti crea un bel problema anche lui. Perche' ovviamente o ammetti una resolution veramente bassa (leggi scarsa) oppure non riesci a spostare il dataset su basi dati di lvello nazionale anziche' locale.

Il giorno 15 gennaio 2014 17:44, Giuseppe Patti <[hidden email]> ha scritto:

Ciao. Vorrei approfondire con voi la questione della risoluzione spaziale di dati vettoriali nella quale sono incappato.

In particolare mi riferisco alla precisione delle coordinate ad es. di uno shape, che continuano a variare passando da un software all'altro. In quale modo, anche appoggiandosi ad un DB, sarebbe possibile essere sicuri di avere coordinate di precisione nota e costante settando il numero di cifre decimali alle quali arrotondare? Ad esempio un noto sw commerciale fa impostare i valori di XY_resolution e XY_tolerance creando un file geodatabase, sarebbe interessante capire se esiste la possibilità di raggiungere lo stesso risultato anche con GFOSS.

Saluti

_______________________________________________
[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.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[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.
666 iscritti al 22.7.2013
_______________________________________________
[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.
666 iscritti al 22.7.2013
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

pcav

Re: Risoluzione spaziale dataset

Il 16/01/2014 10:18, Giuseppe Patti ha scritto:
> E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la
> geometria del poligono dopo lo snap mi tornano fuori le 17 cifre.
> Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

Forse sarebbe piu' semplice scrivere un comando che consenta
l'arrotondamento a piacere (l'utente sceglie il N di cifre decimali da
mantenere).
Che ne dite?
Saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[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.
666 iscritti al 22.7.2013

Giuliano Curti

Re: Risoluzione spaziale dataset

Il giorno Thu, 16 Jan 2014 10:32:00 +0100
Paolo Cavallini <[hidden email]> ha scritto:

> Il 16/01/2014 10:18, Giuseppe Patti ha scritto:
> > E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere
> > la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre.
> > Sbaglio io qualcosa o capisco male il funzionamento di
> > ST_SnapToGrid?
>
> Forse sarebbe piu' semplice scrivere un comando che consenta
> l'arrotondamento a piacere (l'utente sceglie il N di cifre decimali da
> mantenere).
> Che ne dite?

che probabilmente è la soluzione più semplice; c'è forse il problema
di vedere se si snappa in orizzontale, in verticale o secondo la
direzione, ma magari è un falso problema: dovrei analizzarlo meglio;

#Giuseppe (che mi conosce): dispongo (dovrei) di una porzione di codice
per fare il parsing dei vertici di linestring e polygon: dovrebbe essere
abbastanza banale (aggiornarla,) introdurre la funzione di troncamento
indicata da Paolo (e testarla); se ti interessa te la passo o ne
parliamo;

> Saluti.

ciao,
giuliano
_______________________________________________
[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.
666 iscritti al 22.7.2013

giohappy

Re: Risoluzione spaziale dataset

In reply to this post by Giuseppe Patti

Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il Precision Model delle coordinate della geometria. Anzi, questo concetto non viene proprio gestito dentro PostGIS, perché non è esposto dalle API C delle GEOS [1].

ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non tiene conto di questa griglia di precisione nelle eventuali successive manipolazioni della geometria, cosa che invece avviene quando si imposta il Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).

Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.

giovanni

[1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion

[2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <[hidden email]> ha scritto:

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

snap to grid

pcav

Re: Risoluzione spaziale dataset

In reply to this post by Giuliano Curti

Il 16/01/2014 10:58, giulianc51 ha scritto:

> che probabilmente è la soluzione più semplice; c'è forse il problema
> di vedere se si snappa in orizzontale, in verticale o secondo la
> direzione, ma magari è un falso problema: dovrei analizzarlo meglio;
>
> #Giuseppe (che mi conosce): dispongo (dovrei) di una porzione di codice
> per fare il parsing dei vertici di linestring e polygon: dovrebbe essere
> abbastanza banale (aggiornarla,) introdurre la funzione di troncamento
> indicata da Paolo (e testarla); se ti interessa te la passo o ne
> parliamo;

Potete aggiungere considerazioni qui:
https://hub.qgis.org/issues/9326
Grazie.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[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.
666 iscritti al 22.7.2013

Giuseppe Patti

Re: Risoluzione spaziale dataset

In reply to this post by giohappy

Ecco, così mi torna il discorso (purtroppo). Scartato quindi ST_SnapToGrid in PostGis e in Spatialite, non posso nemmeno da QGis gestire direttamente il precision model di GEOS, o sbaglio? Esiste qualche modo (dalla linea di comando di QGis?) per farlo?
Penso che partendo da questa discussione sarebbe interessante costruire una interfaccia per settare il precision model in modo da avere dati congruenti tra vari gis

On 16/01/2014 11:52, G. Allegri wrote:

Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il Precision Model delle coordinate della geometria. Anzi, questo concetto non viene proprio gestito dentro PostGIS, perché non è esposto dalle API C delle GEOS [1].
ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non tiene conto di questa griglia di precisione nelle eventuali successive manipolazioni della geometria, cosa che invece avviene quando si imposta il Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).

Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.

giovanni

[1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion

[2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <[hidden email]> ha scritto:

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

snap to grid

giohappy

Re: Risoluzione spaziale dataset

Il problema è che il PrecisionModel non è esposto tramite le API C [1] e non è consigliabile bypassare tale API, anzitutto per una questione di compatibilità ABI tra versioni diverse delle GEOS.

Comunque è un argomento da approfondire....

giovanni

[1] http://trac.osgeo.org/geos/browser/trunk/capi/geos_c.cpp

Il giorno 16 gennaio 2014 13:32, Giuseppe Patti <[hidden email]> ha scritto:

Ecco, così mi torna il discorso (purtroppo). Scartato quindi ST_SnapToGrid in PostGis e in Spatialite, non posso nemmeno da QGis gestire direttamente il precision model di GEOS, o sbaglio? Esiste qualche modo (dalla linea di comando di QGis?) per farlo?
Penso che partendo da questa discussione sarebbe interessante costruire una interfaccia per settare il precision model in modo da avere dati congruenti tra vari gis

On 16/01/2014 11:52, G. Allegri wrote:

Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il Precision Model delle coordinate della geometria. Anzi, questo concetto non viene proprio gestito dentro PostGIS, perché non è esposto dalle API C delle GEOS [1].
ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non tiene conto di questa griglia di precisione nelle eventuali successive manipolazioni della geometria, cosa che invece avviene quando si imposta il Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).

Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.

giovanni

[1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion

[2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <[hidden email]> ha scritto:

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

snap to grid

--
Giovanni Allegri
http://about.me/giovanniallegri
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

giohappy

Re: Risoluzione spaziale dataset

PS: sarebbe interessante e utile avere un'opinione da Sandro Santilli (aka strk), visto che è colui che meglio conosce le GEOS, visto che le mantiene lui! ;)

giovanni

Il giorno 16 gennaio 2014 14:19, G. Allegri <[hidden email]> ha scritto:

Il problema è che il PrecisionModel non è esposto tramite le API C [1] e non è consigliabile bypassare tale API, anzitutto per una questione di compatibilità ABI tra versioni diverse delle GEOS.
Comunque è un argomento da approfondire....

giovanni

[1] http://trac.osgeo.org/geos/browser/trunk/capi/geos_c.cpp

Il giorno 16 gennaio 2014 13:32, Giuseppe Patti <[hidden email]> ha scritto:

Ecco, così mi torna il discorso (purtroppo). Scartato quindi ST_SnapToGrid in PostGis e in Spatialite, non posso nemmeno da QGis gestire direttamente il precision model di GEOS, o sbaglio? Esiste qualche modo (dalla linea di comando di QGis?) per farlo?
Penso che partendo da questa discussione sarebbe interessante costruire una interfaccia per settare il precision model in modo da avere dati congruenti tra vari gis

On 16/01/2014 11:52, G. Allegri wrote:

Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il Precision Model delle coordinate della geometria. Anzi, questo concetto non viene proprio gestito dentro PostGIS, perché non è esposto dalle API C delle GEOS [1].
ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non tiene conto di questa griglia di precisione nelle eventuali successive manipolazioni della geometria, cosa che invece avviene quando si imposta il Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).

Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.

giovanni

[1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion

[2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <[hidden email]> ha scritto:

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

snap to grid

--
Giovanni Allegri
http://about.me/giovanniallegri
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

--
Giovanni Allegri
http://about.me/giovanniallegri
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

Giuseppe Patti

Re: Risoluzione spaziale dataset

In reply to this post by giohappy

Mi permetto di fare un po' di sintesi.

Giuliano (in Cc) si offre come donatore di codice e sviluppatore.

Io non sono in grado di metterci mano, ma se serve posso mettere due eurini e dare il mio apporto come tester.

Richiamo anche il suggerimento di Paolo Cavallini ad esporre le considerazioni su https://hub.qgis.org/issues/9326

PS: Ben ritrovato Giuliano!

Se hai codice giralo, sicuramente c'è qualcuno più in grado di me nel ficcarci il naso!

Rilevo che una discussione del genere nel famoso software proprietario non avrebbe nemmeno avuto inizio.

Grazie

On 16/01/2014 11:52, G. Allegri wrote:

Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il Precision Model delle coordinate della geometria. Anzi, questo concetto non viene proprio gestito dentro PostGIS, perché non è esposto dalle API C delle GEOS [1].
ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non tiene conto di questa griglia di precisione nelle eventuali successive manipolazioni della geometria, cosa che invece avviene quando si imposta il Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).

Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.

giovanni

[1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion

[2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <[hidden email]> ha scritto:

E infatti io avrei usato ST_SnapToGrid, però se poi vado a chiedere la geometria del poligono dopo lo snap mi tornano fuori le 17 cifre. Sbaglio io qualcosa o capisco male il funzionamento di ST_SnapToGrid?

snap to grid

Sandro Santilli

Re: Risoluzione spaziale dataset

In reply to this post by giohappy

On Thu, Jan 16, 2014 at 11:52:26AM +0100, G. Allegri wrote:

> Ho verificato che, contro quanto credevo, ST_SnapToGrid non setta il
> Precision Model delle coordinate della geometria. Anzi, questo concetto non
> viene proprio gestito dentro PostGIS, perché non è esposto dalle API C
> delle GEOS [1].
> ST_SnapToGrid non fa altro che "arrotondare" i valori delle coordinate alla
> griglia [2], e sputa fuori una nuova geometria "arrotondanta". Però poi non
> tiene conto di questa griglia di precisione nelle eventuali successive
> manipolazioni della geometria, cosa che invece avviene quando si imposta il
> Precision Model dentro le GEOS (o le JTS, da cui viene ereditato).
>
> Come suggerito nel wiki di PostGIS sarebbe importante poter gestire il
> Precision Model... Non so se nel frattempo la cosa ha avuto altri sviluppi.
>
> [1] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion
> [2]
> https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_functions_analytic.c

Nessun nuovo sviluppo. E' un'idea considerata valida in attesa di un
"piano di attacco" su cui nessuno ha dichiarato di star gia lavorando.

Sicuramente si dovrebbe partire dalla C-API di GEOS, e poi capire come
modellare la faccenda in PostGIS (se ad esempio codificare la precisione
in ogni singola geometria, come avviene per lo SRID).

Volontari/e ? Nuova carne ? Gloria e vita !

--strk;
_______________________________________________
[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.
666 iscritti al 22.7.2013