Hi Martin, That sounds good. I will create a new branch for the shapefile functionality.
Could the sis-storage be a "module" as well as have the ability to be compiled to a sis-shapefile.jar that has less dependencies for people that only want to use shape file functionality? Maybe it can have two outputs and generate a standalone artifact as well as be including in the larger package. I want to write a shapefile input format for hadoop for doing bulk ingests of shapefiles. Where would be the best place to add this functionality? Maybe a class called ShapefileInputFormat in org.apache.sis.storage.shapefile.mapred I have about 20,000 shapefiles of various types to test with. Thanks, Travis On Thu, Jun 20, 2013 at 4:21 AM, Martin Desruisseaux < [email protected]> wrote: > Hello Travis > > Le 20/06/13 02:33, Travis L Pinney a écrit : > > I have some tests for the shapefile functionality I am working with and I >> would like to get it integrated into Apache's CI system. Would it be ok to >> create a shapefile branch then use reviewboard before merging it into >> trunk? >> > > If it is okay for you, I think that would be nice. One thing we may do > would be to merge and continue the work in trunk right after the 0.3 > release if you like. I'm right now in a "tests and bug fixes only" phase in > the hope to release the much delayed 0.3 as soon as possible. After that > release, I could help you with the shapefile store is you wish :-) > > One open question is whether we want a separated module for shapefile > store, or if we implement it right in the existing "sis-storage" module. > Since the shapefile format is a very common one, I wonder if we should > consider it as a fundamental services that most SIS users will want. The > issue is to find the right balance between modularization, without ending > with hundreds of modules (Geotk has about 120 modules!). > > Martin > >
