Scusa, ma devo contraddirti decisamente.
Il file .shx non ci entra niente con l'abbinamento tra geometria e attributi.
Esso contiene solo l'indicizzazione spaziale, e qui non centra,
perche' l'indicizzazione spaziale non rappresenta il legame tra
attributi nel dbf e geometria nel .shp.
Prova ne e' che in assenza del file .shx e' sempre possibile
recuperare il corretto abbinamento tra dbf e shp. Al riguardo qualche
mese fa' vi fu' un thread su questo argomento e su un programmino che
si chiamava "shapecheck".
Tornando a noi: leggiti le specifiche esri dello shapefile.
In essa sono contenute esattamente le descrizioni su come si deve procedere.
http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
An ESRI shapefile consists of a main file, an index file, and a dBASE
table. The main
file is a direct access, variable-record-length file in which each
record describes a shape
with a list of its vertices. In the index file, each record contains
the offset of the
corresponding main file record from the beginning of the main file.
The dBASE table
contains feature attributes with one record per feature. The
one-to-one relationship
between geometry and attributes is based on record number. Attribute
records in the
dBASE file must be in the same order as records in the main file.
Come e' riportato dalle suddette specifiche la relazione tra geometria
e attribute e' basata ssul record number (numero del record)
E nei dbf il record number e' il numero di posizione nel file DBF.
Ergo, il primo record del dbf si associa alla prima geometria e cosi' via.
Anche il concetto del posizionamento a piacere, non centra niente.
Ogni record del file .dbf ha lunghezza fissa, contenuta nell'header
del file dbf.
per cui se vuoi posizionarti nel record numero 27 e nell'header e'
riportato che un record e' lungo 150 byte, basta fare una
moltiplicazione e sai quanti bytes saltare.
Questo pero' , ribadisco, non vuol dire niente.
Quindi il "modo giusto" per interpretare gli shapefiles è il seguente:
- si legge la riga N dello DBF e si recuperano gli attributi informativi
- se legge la riga N dello SHX
- quindi si "salta" [fseek() o anologhi] nello SHP all'offset indicato
sullo SHX e si recupera l'entità geometrica corrispondente
Ergo non esiste nessun vincolo tale da imporre una corrispondenza
1:1 tra le righe del DBF e quelle dello SHP, almeno "da specifica ESRI".
Invece e' proprio l'opposto.
Deve esserci una corrispondenza 1:1 se si vuole restare sullo
standard, altrimenti si
crea un qualcosa che poi non viene letto correttamente da altri programmi.
e maggior riprova riporto quest'altra frasettina sempre presente nel
doc. di specifiche esri.
The table must contain one record per shape feature.
The record order must be the same as the order of shape features in
the main (*.shp)
Mi pare chiaro.
Andrea.
2008/3/3, Alessandro Furieri <a.furieri@lqt.it>:
giusto amor di precisione, non è proprio esattamente così ...
a) il DBF ha una struttura con record a lunghezza fissa, e dichiara
nell'header
sia quanti record contiene che quale è la lunghezza record in bytes;
quindi è molto facile sia leggerlo sequenzialmente oppure posizionarsi
su di un record arbitrario a piacere
b) lo SHP ha una struttura con entità a lunghezza variabile [una polilinea
con 2 vertici occupa ovviamente molto meno spazio di una con 1.000
vertici]
c) poi però la "terna" shapefile prevede anche lo SHX, che ha una
lunghezza record fissa, e che contiene l'OFFSET associato all'entità
geometrica contenuta nello SHP
Quindi il "modo giusto" per interpretare gli shapefiles è il seguente:
- si legge la riga N dello DBF e si recuperano gli attributi informativi
- se legge la riga N dello SHX
- quindi si "salta" [fseek() o anologhi] nello SHP all'offset indicato
sullo SHX e si recupera l'entità geometrica corrispondente
Ergo non esiste nessun vincolo tale da imporre una corrispondenza
1:1 tra le righe del DBF e quelle dello SHP, almeno "da specifica ESRI".
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
