Hi all, Im for alternative 1, efficient and simple.
Geotoolkit is another project. Thanks Martin. 2016-04-06 10:11 GMT+02:00 johann sorel <[email protected]>: > I'm for alternative 2. > > > In GeotoolKit we have something like the alternative 3 , here is what the > result looks like : > geotk-client-wcs.jar > geotk-client-wfs.jar > geotk-client-wms.jar > geotk-client-wmts.jar > geotk-coverage-geotiff.jar > geotk-coverage-netcdf.jar > geotk-coverage-postgresql.jar > geotk-feature-csv.jar > geotk-feature-dbf.jar > geotk-feature-geojson.jar > geotk-feature-gml.jar > geotk-feature-kml.jar > geotk-feature-mapinfo.jar > ... > It's not bad but technically coverages are features, and like martin said, > some format are both, > and he first solution do not allow the user to clearly see which > dependency is a data connector. > > Something like this in the end in SIS would be nice and clear : > sis-store-xxxxx.jar > sis-store-client-xxxxx.jar > > > Johann > > > On 05/04/2016 19:53, Mattmann, Chris A (3980) wrote: > >> I’m for alternative 1 thanks Martin >> >> >> >> On 4/5/16, 12:34 PM, "Martin Desruisseaux" < >> [email protected]> wrote: >> >> Hello all >>> >>> With Johann working on the GPX format, a question is which (if any) >>> naming convention to use for storage modules (i.e. modules that read and >>> write some file formats). Currently there is none; the only stores are: >>> >>> Names alternative 1: >>> * sis-netcdf >>> * sis-shapefile >>> >>> We could prefix with "sis-store-" like below: >>> >>> Names alternative 2: >>> * sis-store-netcdf >>> * sis-store-shapefile >>> >>> We could also be more specific by separating the store in 3 categories: >>> those reading features ("sis-feature-"), those reading coverages >>> ("sis-coverage-"), and those that get the data from a distant machine >>> through web services ("sis-client-"): >>> >>> Names alternative 3: >>> * sis-coverage-netcdf >>> * sis-feature-shapefile >>> >>> However one issue with alternative 3 is that some formats does not fit >>> entirely in any category. For example NetCDF can be used for both >>> coverages and features. >>> >>> Alternatives 2 and 3 would impacts users of those modules since they >>> would need to change their dependency in the pom.xml file. >>> >>> Does anyone has a preference for the module naming convention? (for now >>> my own personal preference would be alternative 2, but I'm not sure) >>> >>> Martin >>> >>> > --
