[Gfoss] Risoluzione spaziale dataset

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” <giohappy@gmail.com>
To: Andrea Peri <aperi2007@gmail.com>
Cc: gfoss <gfoss@lists.gfoss.it>
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” <aperi2007@gmail.com> 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

_______________________________________________
[Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it)
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](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

Il giorno 15 gennaio 2014 18:01, Andrea Peri <aperi2007@gmail.com> 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 <gpatt@tiscali.it> 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


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

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

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 <gpatt@tiscali.it> 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?


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.
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

---------- Messaggio inoltrato ----------
From: “G. Allegri” <giohappy@gmail.com>
To: Andrea Peri <aperi2007@gmail.com>
Cc: gfoss <gfoss@lists.gfoss.it>
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” <aperi2007@gmail.com> 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

_______________________________________________
[Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it)
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](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

Il giorno 15 gennaio 2014 18:01, Andrea Peri <aperi2007@gmail.com> 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 <gpatt@tiscali.it> 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


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

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

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 <gpatt@tiscali.it> 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?


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

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

---------- Messaggio inoltrato ----------
From: “G. Allegri” <giohappy@gmail.com>
To: Andrea Peri <aperi2007@gmail.com>
Cc: gfoss <gfoss@lists.gfoss.it>
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” <aperi2007@gmail.com> 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

_______________________________________________
[Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it)
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](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

Il giorno 15 gennaio 2014 18:01, Andrea Peri <aperi2007@gmail.com> 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 <gpatt@tiscali.it> 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


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

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

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 <aperi2007@gmail.com> 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.

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

Il giorno 16 gennaio 2014 08:52, Giuseppe Patti <gpatt@tiscali.it> 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?


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

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

---------- Messaggio inoltrato ----------
From: “G. Allegri” <giohappy@gmail.com>
To: Andrea Peri <aperi2007@gmail.com>
Cc: gfoss <gfoss@lists.gfoss.it>
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” <aperi2007@gmail.com> 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

_______________________________________________
[Gfoss@lists.gfoss.it](mailto:Gfoss@lists.gfoss.it)
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](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

Il giorno 15 gennaio 2014 18:01, Andrea Peri <aperi2007@gmail.com> 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 <gpatt@tiscali.it> 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


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

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

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 <aperi2007@gmail.com <mailto:aperi2007@gmail.com>> 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 <gpatt@tiscali.it
    <mailto:gpatt@tiscali.it>> 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" <giohappy@gmail.com
            <mailto:giohappy@gmail.com>>
            To: Andrea Peri <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>>
            Cc: gfoss <gfoss@lists.gfoss.it <mailto:gfoss@lists.gfoss.it>>
            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" <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>> 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
                <aperi2007@gmail.com <mailto:aperi2007@gmail.com>> 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
                    <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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

                        _______________________________________________
                        Gfoss@lists.gfoss.it
                        <mailto: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.
                        666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

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

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

Il giorno Thu, 16 Jan 2014 10:32:00 +0100
Paolo Cavallini <cavallini@faunalia.it> 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

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 <gpatt@tiscali.it> 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

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

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 <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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

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 <gpatt@tiscali.it> 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


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

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <gpatt@tiscali.it> 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

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! :wink:

giovanni

···

Il giorno 16 gennaio 2014 14:19, G. Allegri <giohappy@gmail.com> 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


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

Il giorno 16 gennaio 2014 13:32, Giuseppe Patti <gpatt@tiscali.it> 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


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

Il giorno 16 gennaio 2014 10:18, Giuseppe Patti <gpatt@tiscali.it> 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

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 <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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

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;

Tieni presente che ci sono dei numeri che in FP64 non sono esprimibili con un numero FINITO di cifre.

Ad esempio il valore 0.1
e quindi anche 0.01 0.001 0.00001 etc...
puo' sembrare strano , ma non è espirmiile con un numero finito di cifre e quindi se lo memorizzi in una variabile Double e poi lo vai a rileggere ti ritorna con tutte e 17 le cifre decimali.
E non è l'unico.
Lo snaptogrid
non puo' bypassare il formato binario e quindi se deve esprimire un numero che in binario non si esprime deve per forza approssimarlo.

A.

On 16/01/2014 10:18, Giuseppe Patti wrote:

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 <aperi2007@gmail.com <mailto:aperi2007@gmail.com>> 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 <gpatt@tiscali.it
    <mailto:gpatt@tiscali.it>> 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" <giohappy@gmail.com
            <mailto:giohappy@gmail.com>>
            To: Andrea Peri <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>>
            Cc: gfoss <gfoss@lists.gfoss.it
            <mailto:gfoss@lists.gfoss.it>>
            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" <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>> 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
                <aperi2007@gmail.com <mailto:aperi2007@gmail.com>>
                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
                    <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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

                        _______________________________________________
                        Gfoss@lists.gfoss.it
                        <mailto: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.
                        666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

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

Cosi' risolvi solo il problema della rappresentazione a video.
Nel momento in cui lo memorizzi in una variabile double ritorna ad avere 17 cifre decimali.
La memorizzazione con il numero di cifre voluto come ipotizzato è realizzabile solo con se si implementano variabili che memorizzano in BCD oppure in forma testuale il valore.

A.

On 16/01/2014 10:32, Paolo Cavallini wrote:

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.

Il giorno Thu, 16 Jan 2014 14:58:18 +0100
Giuseppe Patti <gpatt@tiscali.it> ha scritto:

ciao Giuseppe,

Mi permetto di fare un po' di sintesi.

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

sì, certo :slight_smile: con la (solita) precisazione che sono uno "sviluppatore
domenicale";

se ho capito bene il thread (e mi viene qualche dubbio perchè ho sentito
parlare di Precision Model che, ahimè :frowning: non so dove stia di casa,
forse ho qualche riga di codice che opportunamente adattato può
consentire il troncamento desiderato;

Io non sono in grado di metterci mano, ma se serve posso mettere due
eurini ....

il mio obiettivo attuale è conoscere ed imparare ... ed ogni occasione
è buona;

.... e dare il mio apporto come tester.

questo lo davo per scontato :slight_smile: :slight_smile: :slight_smile:

sarebbe oltremodo gradita l'attività di tutoring di chiunque abbia
voglia di farla :slight_smile: anche se quello che ha appena detto Andrea P. circa
la precisione in virgola mobile vanifica il mio progetto :frowning:

Grazie

a te, ciao,
giuliano

Il giorno Thu, 16 Jan 2014 18:08:08 +0100
giulianc51 <giulianc51@gmail.com> ha scritto:

Il giorno Thu, 16 Jan 2014 14:58:18 +0100
Giuseppe Patti <gpatt@tiscali.it> ha scritto:

........

ciao a tutti,

così, per divertimento, ho messo insieme quelle routine di cui parlavo
per affrontare l'arrotondamento delle coordinate (snapToGrid);

alle prime, sommarie prove riscontro però il problema segnalato da
Andrea: arrotondando ad es. a 3 cifre decimali (*) sembra andare tutto
bene, ma poi trovo qualche coordinata con la ennesima cifra decimale
occupata o con tutti 9 (**);

sembra, dico sembra, che il troncamento all'intero funzioni meglio;
fosse così si potrebbe scalare all'unità decimale desiderata troncando
all'intero, ma non so la reazione di QGIS a trattare con coordinate
dell'ordine di 7+7 = 14 cifre !

per cavare un ragno dal buco credo serva la consulenza di un esperto
conoscitore della rappresentazione numerica decimale;

my 2 cents :slight_smile:

ciao,
giuliano

(*) non sono affari miei ma confesso di essere curioso di capire cosa
serve, magari in un sistema GaussBoaga, con coordinate dell'ordine dei
milioni di km, snappare a 10 microns (1/10**7), ma non sono affari
miei :slight_smile:

(**) credo che il campo numerico rappresentato digitalmente non sia
continuo !

Ciao a tutti,

Vorrei rianimare la discussione su questo thread (reperibile per intero qui: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Risoluzione-spaziale-dataset-tt7585941.html) finito poi su un binario morto ma che credo di grande importanza.

L'occasione mi è data dal rilascio di due nuovi software, Shapefile Fixer e GeoUML Report Filler da parte dell'amico Jody Marca (http://www.jodymarca.com/it/)

Che potete trovare alla pagina:

http://www.jodymarca.com/tools/

Ai fini di questo thread è in particolare interessante lo Shapefile Fixer, che si occupa di arrotondamento di coordinate e di aggiustamento delle geometrie.

Anche in questo caso però si ripresenta l'inghippo che ha originato questa discussione: arrotondate le cifre decimali dei vertici che rappresentano una geometria ad un numero fissato, mi aspetto che se imposto la precisione a 3 cifre decimali il vertice 543523.1237 diventi 543523.124 ed in effetti questo è quello che succede. Però se provo ad interrogare quella geometria arrotondata chiedendone il wkt (ad es. in QGis) mi ritorna una rappresentazione che è "molto prossima" a quella arrotondata ma non esattamente arrotondata, del tipo 543523.123999900000000034252. Credo che questo problema sia legato alla "virgola mobile", infatti lo stesso problema mi si ripresenta se uso ST_SnapToGrid in Postgis o Spatialite, oppure lo strumento "Semplifica geometrie" di OpenJump. Ovviamente il problema non si presenta in ST_SnapToGrid se imposto uno "snap" molto alto (superiore a 1) che a quel punto taglia tutta la parte decimale.

Allo scopo ho aperto un ticket su PostGis che trovate qui:

http://trac.osgeo.org/postgis/ticket/2611

Sarebbe utile, credo, pervenire ad una gestione ragionata e trasparente (ovvero meno "randomica") di queste situazioni.

Saluti a tutti!

On 16/01/2014 16:50, aperi2007 wrote:

Tieni presente che ci sono dei numeri che in FP64 non sono esprimibili con un numero FINITO di cifre.

Ad esempio il valore 0.1
e quindi anche 0.01 0.001 0.00001 etc...
puo' sembrare strano , ma non è espirmiile con un numero finito di cifre e quindi se lo memorizzi in una variabile Double e poi lo vai a rileggere ti ritorna con tutte e 17 le cifre decimali.
E non è l'unico.
Lo snaptogrid
non puo' bypassare il formato binario e quindi se deve esprimire un numero che in binario non si esprime deve per forza approssimarlo.

A.

On 16/01/2014 10:18, Giuseppe Patti wrote:

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 <aperi2007@gmail.com <mailto:aperi2007@gmail.com>> 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
    <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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" <giohappy@gmail.com
            <mailto:giohappy@gmail.com>>
            To: Andrea Peri <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>>
            Cc: gfoss <gfoss@lists.gfoss.it
            <mailto:gfoss@lists.gfoss.it>>
            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" <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>> 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
                <aperi2007@gmail.com <mailto:aperi2007@gmail.com>>
                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
                    <gpatt@tiscali.it <mailto:gpatt@tiscali.it>> 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

                        _______________________________________________
                        Gfoss@lists.gfoss.it
                        <mailto: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.
                        666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

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