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
