Hello,
Here are more informations on shapefile structure and link between files :
http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
Page 24 and 25.
p.24 SHX : The I’th record in the index file (shx) stores the offset and
content length for the I’th record in the main file (shp).
p.25 DBF : The record order must be the same as the order of shape
features in the main (*.shp) file.
So the order must be consistant between all files : shx, shp and dbf
Hope this helps
Johann Sorel
Geomatys
On 05/01/2015 10:11, Martin Desruisseaux wrote:
Hello Mark
Thanks for the reply.
Le 05/01/15 09:50, Marc LE BIHAN a écrit :
InputFeatureStream :
I guessed you wished a stream, but a Reader could be better.
Or anything else. What would you prefer ?
I was thinking about java.util.stream (new in JDK8 - but I have some
idea for JDK6/7 compatibilities):
http://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html
While the Javadoc shows lot of methods, many of them are static or have
default implementation. So the number of methods to implement may not be
so high.
Control the values :
How can I check if a shapefile content is correct ? Do you have some basic
controls to suggest ?
I'm not sure to understand what we mean by correct. Do we mean checking
if a value read from a Shapefile entry/record is of the expected type?
Shapefile - Dabase
Currently one MappedByteBuffer reads a shapefile,
while another one reads the Database.
The first record of the shapefile matches the first record of the database,
the second record of the shapefile matches the second record of the
database.
is it always true ?
I just asked to our Shapefile specialist. He said that not necessarily,
there is a third file with ".shx" extension which make the link between
the database entries and the shapefile entries.
SQLException and DataStoreException :
(...snip...)
But if you convert an SQLException to a DataStoreException :
throw new DataStoreException(sqlException.getMessage(), sqlException);
I fear the caller will have no way to react programmatically to the real
cause of a trouble. To allow programmer continuing to react to that, we
should set vendor codes in SQLException subclasses and DataStoreException.
SQLException indeed have room for SQL state or vendor code. We could
also define DataStoreException subclasses - we have not done that yet
only because we were waiting for more use case experience.
I agree with the goal to allow caller to react to the cause of trouble.
The question is: are SQLException subclasses the best way to achieve
this goal if there is no code outside sis-shapefile module would catch
those exceptions? Are the alternatives (SQL state, vendor code,
DataStoreException subclasses) worth to explore?
Martin
