Grass double precision field

[Marco Guiducci-2]

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

[a.furieri]

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.

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

[Marco Guiducci-2]

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

> Da: "[hidden email]" <[hidden email]>
> A: [hidden email]
> 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 :-)

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ù ;-)
Purtroppo si lavora con buffer di 40 cm su punti distanti pochi centimetri, ma con coordinate a 7 cifre sulla parte intera :-(

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

[Sandro Santilli]

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 :-(

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 :)

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

[Luca Sigfrido Percich]

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 :-(
>
> 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 :)
>
> --strk;
> _______________________________________________
> [hidden email]
> 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).
_______________________________________________
[hidden email]
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

[Simone Gadenz-2-3]

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

Saluti.

S.G


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

[Marco Guiducci-2]

----- Messaggio originale -----
> Da: Luca Sigfrido Percich <[hidden email]>

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

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