[Gfoss] Grass double precision field

Ciao,
in una tabella collegata ad un layer di grass aggiungo una colonna "Area" double precision, che valorizzo con v.to.db map=miobuffer type=centroid option=area col=Area

Il valore dell'area calcolata di è di 0.999021.
Questo valore lo posso leggere sia da QGis, sia dalla gui di grass, sia da shell, ovviamente.
Domanda: essendo il campo un double precision (lungo 20), mi sarei aspettato di leggere più decimali (perché mi occorrono più decimali per discriminare i poligoni in base alla loro superficie).
Mi sono messo a cercare nella documentazione ma non ho trovato niente che mi aiuti a capire né come sono fatti i calcoli, né se c'è un modo per mostrare tutti i decimali.
Qualche dritta?
grazie
marco

On Wed, 28 Nov 2012 11:44:37 +0000 (GMT), Marco Guiducci wrote:

Il valore dell'area calcolata di è di 0.999021.
Questo valore lo posso leggere sia da QGis, sia dalla gui di grass,
sia da shell, ovviamente.
Domanda: essendo il campo un double precision (lungo 20), mi sarei
aspettato di leggere più decimali (perché mi occorrono più decimali
per discriminare i poligoni in base alla loro superficie).

Marco,

le variabili "double precision" sono numeri binari a virgola mobile
conformi allo standard IEEE 754:
http://it.wikipedia.org/wiki/IEEE_754

come puoi vedere, proprio in quanto "a virgola mobile", non hanno
un numero predeterminato di cifre intere e decimali, dipende tutto
dal valore che viene effettivamente memorizzato.
approssimativamente, la somma delle cifre decimali e di quelle
intere e' 17 o 18 (non aspettarti un valore esatto, perche' essendo
un formato binario non ha un'esatta corrispondenza in base10)

dato che per qualsiasi sw e' del tutto impossibile sapere a priori
quante cifre decimali (precisione) sono effettivamente disponibili,
si usa sempre visualizzare una rappresentazione approssimativa ed
arrotondata che utilizza un numero limitato di cifre decimali:
tipicamente 4 oppure 6, molto piu' raramente 8.

questo non significa affatto che il valore memorizzato internamente
abbia subito un troncamento: e' semplicemente la visualizzazione che
avviene in modo arrotondato, sia per consentire un piu' agevole
allineamento delle cifre in colonna, sia per evitare di esporre un
numero esagerato di decimali poco significativi.

insomma, non e' affatto un problema di GRASS; e' semplicemente una
specie di "convenzione standard" adottata universalmente da qualsiasi
sw che si trovi a dovere visualizzare/stampare valori floating point.

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

----- Messaggio originale -----

Da: "a.furieri@lqt.it" <a.furieri@lqt.it>
A: gfoss@lists.gfoss.it
Cc:
Inviato: Mercoledì 28 Novembre 2012 13:14
Oggetto: Re: [Gfoss] Grass double precision field

On Wed, 28 Nov 2012 11:44:37 +0000 (GMT), Marco Guiducci wrote:

Il valore dell'area calcolata di è di 0.999021.
Questo valore lo posso leggere sia da QGis, sia dalla gui di grass,
sia da shell, ovviamente.
Domanda: essendo il campo un double precision (lungo 20), mi sarei
aspettato di leggere più decimali (perché mi occorrono più decimali
per discriminare i poligoni in base alla loro superficie).

Marco,

le variabili "double precision" sono numeri binari a virgola mobile
conformi allo standard IEEE 754:
http://it.wikipedia.org/wiki/IEEE_754

come puoi vedere, proprio in quanto "a virgola mobile", non hanno
un numero predeterminato di cifre intere e decimali, dipende tutto
dal valore che viene effettivamente memorizzato.
approssimativamente, la somma delle cifre decimali e di quelle
intere e' 17 o 18 (non aspettarti un valore esatto, perche' essendo
un formato binario non ha un'esatta corrispondenza in base10)

dato che per qualsiasi sw e' del tutto impossibile sapere a priori
quante cifre decimali (precisione) sono effettivamente disponibili,
si usa sempre visualizzare una rappresentazione approssimativa ed
arrotondata che utilizza un numero limitato di cifre decimali:
tipicamente 4 oppure 6, molto piu' raramente 8.

questo non significa affatto che il valore memorizzato internamente
abbia subito un troncamento: e' semplicemente la visualizzazione che
avviene in modo arrotondato, sia per consentire un piu' agevole
allineamento delle cifre in colonna, sia per evitare di esporre un
numero esagerato di decimali poco significativi.

insomma, non e' affatto un problema di GRASS; e' semplicemente una
specie di "convenzione standard" adottata universalmente da qualsiasi
sw che si trovi a dovere visualizzare/stampare valori floating point.

ok, quel che dici non mi è nuovo.
Sto solo cercando un sistema per vederli quei decimali, visto che ci sono :slight_smile:

per ora mi accontento di questo
v.out.ascii input=miobuffer dp=16 columns=Area

così vedo i valori dell'area di tutti i buffer, trovo la soglia che serve per poi fare una select.

(serebbe più carino nelle gui, compreso QGis, un'opzione per vedere qualcosina di più :wink:
Purtroppo si lavora con buffer di 40 cm su punti distanti pochi centimetri, ma con coordinate a 7 cifre sulla parte intera :frowning:

grazie
marco

On Wed, Nov 28, 2012 at 12:50:24PM +0000, Marco Guiducci wrote:

Purtroppo si lavora con buffer di 40 cm su punti distanti pochi centimetri, ma con coordinate a 7 cifre sulla parte intera :frowning:

Purtroppo i floating point non possono proprio arrivare a quella precisione,
quindi e' anche possibile che tu ottenga dei numeri completamente arbitrari.
Servono tutte quelle cifre intere ?
Le proiezioni non le hanno inventate per nulla :slight_smile:

--strk;

Un escamotage per aumentare la precisione può essere quello di diminuire
il range della parte intera limitandosi al boundary effettivo.

Puoi sottrarre alle coordinate di tutti i punti le coordinate del punto
LowerLeft del boundary, andando a lavorare in un sistema cartesiano non
inquadrato in un SRS. Non so dirti come farlo in GRASS, in PostGIS
sarebbe una cosa tipo:

insert into non_geom_table(id, geom)
  select id, ST_SetSrid(ST_Translate(geom, -originx, -originy), 0)
  from geom_table

Se l'area di lavoro è di pochi Km di lato, puoi arrivare ad un aumento
della precisione di 2/3 cifre.

Sig

Il giorno mer, 28/11/2012 alle 14.02 +0100, Sandro Santilli ha scritto:

On Wed, Nov 28, 2012 at 12:50:24PM +0000, Marco Guiducci wrote:

> Purtroppo si lavora con buffer di 40 cm su punti distanti pochi centimetri, ma con coordinate a 7 cifre sulla parte intera :frowning:

Purtroppo i floating point non possono proprio arrivare a quella precisione,
quindi e' anche possibile che tu ottenga dei numeri completamente arbitrari.
Servono tutte quelle cifre intere ?
Le proiezioni non le hanno inventate per nulla :slight_smile:

--strk;
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

_____________
PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

PRIVACY
Le informazioni contenute in questo messaggio sono riservate e confidenziali. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora Lei non fosse la persona a cui il presente messaggio è destinato, La invitiamo ad eliminarlo dal Suo Sistema e a distruggere le varie copie o stampe, dandone gentilmente comunicazione all’indirizzo mail del mittente. Ogni utilizzo improprio e' contrario ai principi del D.lgs 196/03 e alla legislazione europea (Direttiva 2002/58/CE).

Buonasera,

scusandomi per l'OT, alla Geographike (www.geographike.it) stiamo ricercando un collega junior da inserire nel gruppo di sviluppo web e mobile di carattere prevalentemente geografico. Si richiede un po' di esperienza su Android e web geografico OS. La sede di lavoro è Siena.

Per ricevere maggiori informazioni o inviare una candidatura rispondere a questa mail o scrivere a info@geographike.it.

Saluti.

S.G

----- Messaggio originale -----

Da: Luca Sigfrido Percich <sigfrido@tiscali.it>

Puoi sottrarre alle coordinate di tutti i punti le coordinate del punto
LowerLeft del boundary, andando a lavorare in un sistema cartesiano non
inquadrato in un SRS. Non so dirti come farlo in GRASS, in PostGIS
sarebbe una cosa tipo:

insert into non_geom_table(id, geom)
select id, ST_SetSrid(ST_Translate(geom, -originx, -originy), 0)
from geom_table

v.edit map=mappa tool=move move=x,y

ciao
marco