So the proposal would be to keep "sis-netcdf" and "sis-shapefile" module
names unchanged.
For the new module to be created by Johann, while the primary format
right now is GPX, actually I think that it could be the base for various
(but not all) formats based on XML. For example the OGC Moving Feature
XML format would share a lot of code with GPX, as it could be seen as a
simplified version of GPX (except for handling of time) with different
XML element names. The module created by Johann could provide the tools
for supporting Moving Features and similar formats, so we propose to
name that module "sis-xml-store". Note: even if we provide more
extensive GML support in a future version, I think it would use many of
the tools defined in "sis-xml-store".
Any though?
Martin
Le 05/04/16 19:53, Mattmann, Chris A (3980) a écrit :
> I’m for alternative 1 thanks Martin
>
> On 4/5/16, 12:34 PM, "Martin Desruisseaux" <[email protected]>
> wrote:
>> 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
