Salve,
ho a che fare con delle tabelle postgis e mi chiedevo quale fosse il formato delle geometrie.
Per esempio in una tabella di feature class areale nel campo the_geom ho il seguente valore:
0101000000D441C64A39023A41A112F8E2729C5241
che credo non sia in formato WKT
Qualcuno saprebbe dirmi di che formato si tratta?..esiste un convertitore di formato?
Per esempio in una tabella di feature class areale nel campo the_geom ho
il seguente valore:
0101000000D441C64A39023A41A112F8E2729C5241
che credo non sia in formato WKT
On Tue, 12 Oct 2010 16:13:37 +0200, Paolo Cavallini wrote
Il 12/10/2010 16:10, marco zanieri ha scritto:
> Per esempio in una tabella di feature class areale nel campo the_geom ho
> il seguente valore:
> 0101000000D441C64A39023A41A112F8E2729C5241
> che credo non sia in formato WKT
Mi permetto di corregere:
"quasi" WKB, ma non esattamente ...
Non è una idiosincrasia di PostGIS: è una
regola costante per praticamente tutti gli
Spatial DBMS (SpatiaLite compreso, ovvio)
a) i formati standard WKB e WKT si usano
"esternamente" al DB
b) ma poi ciascun DBMS utilizza un proprio specifico
formato binario specifico per la rappresentazione
"interna" delle geometrie.
basti solo pensare al fatto che WKB *non*
prevede la memorizzazione dello SRID ....
c) di regola questi "formati binari interni"
assomigliano molto al WKB, ma hanno sempre
qualche header/footer "esoterico".
btw le rappresentazioni "interne" utilizzate
da MySQL Spatial / PostgreSQL PostGIS / SpatiaLite
sono sostanzialmente diverse ed incompatibili.
Ma grazie alla "traduzione" standard WKB/WKT sono
anche reciprocamente pienamente interoperabili.
Insomma, mettersi a "sciacquettare a manina" i
dati binari memorizzati dentro ad uno Spatial DBMS
non è per nulla cosa saggia e prudente ...
e presumibilmente può anche generare spiacevoli
sorprese quando cambia la versione (perchè gli
sviluppatori possono anche legittimamente
decidere di modificare/ottimizzare il formato
interno).
Soluzione: usare sempre le apposite funzioni
di accesso ai dati: AsText(), AsBinary(),
GeomFromText(), GeomFromWKB() etc.
queste sono state inserite nello standard OGC-SFS
proprio per disaccoppiare le rappresentazioni
interne da quelle esterne, rendendo tutti i
meccanismi di implementazione totalmente
trasparenti per gli utilizzatori.
e servono ottimamente per evitare di dovere
mai "mettere le mani" sui formati interni.
On Tue, Oct 12, 2010 at 04:10:01PM +0200, marco zanieri wrote:
0101000000D441C64A39023A41A112F8E2729C5241
che credo non sia in formato WKT
Qualcuno saprebbe dirmi di che formato si tratta?
Lo chiamiamo HEXEWKB, che sta per HEXadecimal Extended WKB.
Extended perche' e' un superset del WKB (include lo SRID e
il supporto per le coordinate misurate e 4d).
HEX perche'.. beh, e' esadecimale.
....esiste un convertitore di formato?
Esistono chiamate per ottenere formati diversi:
ST_AsWKB -- standard WKB binary
ST_AsText -- standard WKT ascii
...
Ciao Giuseppe,
io ho il pdf dell’ebook su postgis “PostGis in Action”, dovrebbe essere molto valido (ancora non ho avuto il tempo di leggerlo)…ti interessa?..se si te lo invio volentieri…fammi sapere!!
Ciao,
marco
Il giorno 12 ottobre 2010 17:26, strk <strk@keybit.net> ha scritto:
On Tue, Oct 12, 2010 at 04:10:01PM +0200, marco zanieri wrote:
0101000000D441C64A39023A41A112F8E2729C5241
che credo non sia in formato WKT
Qualcuno saprebbe dirmi di che formato si tratta?
Lo chiamiamo HEXEWKB, che sta per HEXadecimal Extended WKB.
Extended perche’ e’ un superset del WKB (include lo SRID e
il supporto per le coordinate misurate e 4d).
HEX perche’… beh, e’ esadecimale.
…esiste un convertitore di formato?
Esistono chiamate per ottenere formati diversi:
ST_AsWKB – standard WKB binary
ST_AsText – standard WKT ascii
…