I went ahead and checked in code that uses order() instead of extending MappedByteBuffer. After going back over the code, I noticed there was not too many places that needed to be switched.
I am working on the patch now. I am assuming this needs to go in sis/trunk/storage/sis-shapefile. Thanks, Travis On Mon, Jun 3, 2013 at 7:12 PM, Travis L Pinney <[email protected]>wrote: > Hello all, > > Just an update of the progress I made. > > 1. Switched to org.apache.sis.storage.shapefile for java/tests > 2. Truncated the test shapefiles and checked them in and deleted the > original larger shapefiles. > 3. Switched to using NIO > > The code is here > > https://github.com/tlpinney/shapefile-api > > Currently I have it set up to MMAP the files. I am still using Apache > EndianUtils for reading Little Endian values. I am not sure of the > advantage of calling foo.order(ByteOrder.LITTLE_ENDIAN) instead of using > the EndianUtils, but I will extend the MappedByteBuffer so the api is > easier to use when switching between Little Endian and Big Endian. Either > method of reading Little Endian values can be swapped out without changing > the api in the future. > > Maybe something like? > > foo.getLEInt() > foo.getLELong() > > for dealing with Little Endian values? > > > Thanks, > Travis > > > > > On Mon, Jun 3, 2013 at 2:17 PM, Adam Estrada <[email protected]>wrote: > >> Thanks Travis! >> >> >> On Mon, Jun 3, 2013 at 10:04 AM, Travis L Pinney <[email protected] >> >wrote: >> >> > Thanks for the suggestions. >> > >> > I will update the packaging to be consistent with apache-sis and use >> > ReviewBoard for the patch. >> > >> > For the tests, I will regenerate the shapefiles with a subset of the >> data >> > to keep them at a reasonable size. This will allow testing for all >> types of >> > data (Polyline, Shapefile, and Point for now). I agree it is not optimal >> > for basic tests to depend on large files. >> > >> > Using java.nio will be better than using RandomAccessFile. I will look >> into >> > getting that switched over. >> > >> > >> > Thanks! >> > Travis >> > >> > >> > On Mon, Jun 3, 2013 at 4:37 AM, Martin Desruisseaux < >> > [email protected]> wrote: >> > >> > > Hello Travis >> > > >> > > Thanks for this work! I had a quick look at the code on GitHub, and I >> > > would like to do the following suggestions: >> > > >> > > * >> > > >> > > About the test data, the ANC90Ply_4326.dbf files could easily be >> > > committed on SVN since it is only 19 kb. However the other test >> > > files (SignedBikeRoute_4326 and ABRALicenseePt_4326) are 2.4 and >> 3.1 >> > > Mb big. We have not yet established a mechanism for such large test >> > > files. We may need to setup some FTP server for large test files, >> > > and design the tests in such a way that those tests are optional. >> > > Maybe for now it would be better to commit only >> ANC90Ply_4326.dbf... >> > > >> > > * >> > > >> > > The ShapeFile class uses java.io.RandomAccessFile for reading data, >> > > followed by calls to org.apache.commons.io.**EndianUtils for >> > > converting bytes to double (or other primitive types) while taking >> > > endianness in account. Would it be possible to use >> > > java.nio.channels.**ReadableChannel with java.nio.ByteBuffer >> instead? >> > > It would take care of the above for you, potentially much more >> > > efficiently. >> > > >> > > >> > > Thanks again! >> > > >> > > Martin >> > > >> > > >> > > >> > > Le 03/06/13 01:47, Travis L Pinney a écrit : >> > > >> > > Hello everyone, >> > >> >> > >> I started working on a very rough prototype that can read in >> Shapefiles. >> > >> >> > >> https://github.com/tlpinney/**shapefile-api< >> > https://github.com/tlpinney/shapefile-api> >> > >> >> > >> In order to write a patch to submit, where would this component >> reside >> > in >> > >> the Apache SIS project? >> > >> >> > >> >> > >> Thanks, >> > >> Travis >> > >> >> > > >> > > >> > >> > >
