Thanks, Travis, great! Cheers, Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Travis L Pinney <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, June 3, 2013 5:22 PM To: dev <[email protected]> Subject: Re: Material for potential volunteer >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 >>> > >> >>> > > >>> > > >>> > >>> >> >>
