You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/05/03 19:52:32 UTC
Proposal to create sis-netcdf module Sunday
Hello all
If peoples agree, I could create a sis-netcdf module this Sunday and
port the CF 1.5 - ISO 19115 binding. It should be quick since I do not
envision major changes, and would give peoples an opportunity to start
experimenting ISO metadata on real data files. This binding is specified
by NOAA, so anyone working with NOAA data would be in good position for
improving that module after the initial commit if they wish.
The initial commit would be only the metadata part of NetCDF. The actual
data part would need to be done later (after we ported a "sis-coverage"
module...)
Does it sound okay?
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by Greg Reddin <gr...@gmail.com>.
Sounds good to me.
On Fri, May 3, 2013 at 12:52 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:
> Hello all
>
> If peoples agree, I could create a sis-netcdf module this Sunday and port
> the CF 1.5 - ISO 19115 binding. It should be quick since I do not envision
> major changes, and would give peoples an opportunity to start experimenting
> ISO metadata on real data files. This binding is specified by NOAA, so
> anyone working with NOAA data would be in good position for improving that
> module after the initial commit if they wish.
>
> The initial commit would be only the metadata part of NetCDF. The actual
> data part would need to be done later (after we ported a "sis-coverage"
> module...)
>
> Does it sound okay?
>
> Martin
>
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Adam Estrada <es...@gmail.com>.
+1 from me.
On Fri, May 3, 2013 at 2:35 PM, Mattmann, Chris A (398J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> +1 from me
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: Martin Desruisseaux <ma...@geomatys.fr>
> Organization: Geomatys
> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
> Date: Friday, May 3, 2013 10:52 AM
> To: Apache SIS <de...@sis.apache.org>
> Subject: Proposal to create sis-netcdf module Sunday
>
> >Hello all
> >
> >If peoples agree, I could create a sis-netcdf module this Sunday and
> >port the CF 1.5 - ISO 19115 binding. It should be quick since I do not
> >envision major changes, and would give peoples an opportunity to start
> >experimenting ISO metadata on real data files. This binding is specified
> >by NOAA, so anyone working with NOAA data would be in good position for
> >improving that module after the initial commit if they wish.
> >
> >The initial commit would be only the metadata part of NetCDF. The actual
> >data part would need to be done later (after we ported a "sis-coverage"
> >module...)
> >
> >Does it sound okay?
> >
> > Martin
> >
>
>
Re: Proposal to create sis-netcdf module Sunday
Posted by johann sorel <jo...@geomatys.com>.
ok for me.
Johann Sorel
Geomatys
On 07/05/2013 10:45, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 07/05/13 01:20, Mattmann, Chris A (398J) a écrit :
>> +1, but we should probably make all top level dirs consistent like this
>> then too, right?
>
> In this proposal, the presence or absence of "sis-" prefix in
> directory name would not be determined by whether the directory is
> top-level or not, but rather by whether the directory is for a module
> producing a JAR file or is just a container for such sub-modules. Or
> in other words, it would be determined by whether the directory is a
> leaf in the modules tree or not. Only leaves would have "sis-" prefix.
>
> In terms of Maven pom.xml, this would be determined by the <packaging>
> element. "pom" packaging would have no "sis-" prefix, because they
> produce nothing by themselves. "jar", "bundle" and "maven-plugin"
> packaging would have the "sis-" prefix.
>
> If nevertheless we want to have top-level directories that looks like
> consistent, one possible approach could be to group the current
> top-level modules (except the "app" ones) in a "core" group. So the
> hierarchy could be like below:
>
> core
> - sis-utility
> - sis-metadata
> - sis-referencing
> - sis-coverage
> - ...
> storage
> - sis-shapefile
> - sis-geotiff
> - sis-postgis
> - sis-netcdf
> - ...
> client
> - sis-wms
> - sis-wfs
> - sis-csw
> - ...
> application
> - sis-app
> - sis-webapp
> - ...
>
>
> So the "core" which existed in SIS 0.2 would be back, but as a group
> of modules rather than a single one.
>
> What do you think?
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Suresh Marru <sm...@apache.org>.
Sounds like a great idea folks.
Since I will not have cycles to contribute any work a +0.
Suresh
On May 7, 2013, at 9:28 AM, "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov> wrote:
> +1 makes sense to me. We've got time so lets update for 0.3...
>
> Sent from my iPhone
>
> On May 7, 2013, at 1:46 AM, "Martin Desruisseaux" <ma...@geomatys.fr> wrote:
>
>> Hello Chris
>>
>> Le 07/05/13 01:20, Mattmann, Chris A (398J) a écrit :
>>> +1, but we should probably make all top level dirs consistent like this
>>> then too, right?
>>
>> In this proposal, the presence or absence of "sis-" prefix in directory name would not be determined by whether the directory is top-level or not, but rather by whether the directory is for a module producing a JAR file or is just a container for such sub-modules. Or in other words, it would be determined by whether the directory is a leaf in the modules tree or not. Only leaves would have "sis-" prefix.
>>
>> In terms of Maven pom.xml, this would be determined by the <packaging> element. "pom" packaging would have no "sis-" prefix, because they produce nothing by themselves. "jar", "bundle" and "maven-plugin" packaging would have the "sis-" prefix.
>>
>> If nevertheless we want to have top-level directories that looks like consistent, one possible approach could be to group the current top-level modules (except the "app" ones) in a "core" group. So the hierarchy could be like below:
>>
>> core
>> - sis-utility
>> - sis-metadata
>> - sis-referencing
>> - sis-coverage
>> - ...
>> storage
>> - sis-shapefile
>> - sis-geotiff
>> - sis-postgis
>> - sis-netcdf
>> - ...
>> client
>> - sis-wms
>> - sis-wfs
>> - sis-csw
>> - ...
>> application
>> - sis-app
>> - sis-webapp
>> - ...
>>
>>
>> So the "core" which existed in SIS 0.2 would be back, but as a group of modules rather than a single one.
>>
>> What do you think?
>>
>> Martin
>>
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
I have re-organized the SIS modules in "core", "storage" and
"application" groups as suggested by emails. I would recommend anyone
having a svn checkout to perform "mvn clean" *before* "svn update", in
order to avoid orphan "target" directories in the workspace.
I also took the initiative to rename "sis-parent" as "parent" for
consistency with all other groups, which have no "sis-" prefix. This
change should be invisible to users since I don't think there is any
reason why a user would reference this pom directly. However I can
revert if peoples think we should.
I did not changed the "groupId" of modules. Consequently the
<dependency> declaration in Maven projects using SIS is unchanged. We
currently have:
* org.apache.sis.storage groupId for sis-netcdf
* org.apache.sis for all other modules.
Whether the groupId should reflect the directory structure for all
modules is an open question. I'm neutral on that. I'm not sure it is
worth for "core" module. It may be considered for "application" modules,
but their names ("sis-app" or "sis-webapp") is already explicit...
Martin
Le 07/05/13 15:28, Mattmann, Chris A (398J) a écrit :
> +1 makes sense to me. We've got time so lets update for 0.3...
>
> On May 7, 2013, at 1:46 AM, "Martin Desruisseaux" <ma...@geomatys.fr> wrote:
>> (...snip...)
>>
>> core
>> - sis-utility
>> - sis-metadata
>> - sis-referencing
>> - sis-coverage
>> - ...
>> storage
>> - sis-shapefile
>> - sis-geotiff
>> - sis-postgis
>> - sis-netcdf
>> - ...
>> client
>> - sis-wms
>> - sis-wfs
>> - sis-csw
>> - ...
>> application
>> - sis-app
>> - sis-webapp
>> - ...
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1 makes sense to me. We've got time so lets update for 0.3...
Sent from my iPhone
On May 7, 2013, at 1:46 AM, "Martin Desruisseaux" <ma...@geomatys.fr> wrote:
> Hello Chris
>
> Le 07/05/13 01:20, Mattmann, Chris A (398J) a écrit :
>> +1, but we should probably make all top level dirs consistent like this
>> then too, right?
>
> In this proposal, the presence or absence of "sis-" prefix in directory name would not be determined by whether the directory is top-level or not, but rather by whether the directory is for a module producing a JAR file or is just a container for such sub-modules. Or in other words, it would be determined by whether the directory is a leaf in the modules tree or not. Only leaves would have "sis-" prefix.
>
> In terms of Maven pom.xml, this would be determined by the <packaging> element. "pom" packaging would have no "sis-" prefix, because they produce nothing by themselves. "jar", "bundle" and "maven-plugin" packaging would have the "sis-" prefix.
>
> If nevertheless we want to have top-level directories that looks like consistent, one possible approach could be to group the current top-level modules (except the "app" ones) in a "core" group. So the hierarchy could be like below:
>
> core
> - sis-utility
> - sis-metadata
> - sis-referencing
> - sis-coverage
> - ...
> storage
> - sis-shapefile
> - sis-geotiff
> - sis-postgis
> - sis-netcdf
> - ...
> client
> - sis-wms
> - sis-wfs
> - sis-csw
> - ...
> application
> - sis-app
> - sis-webapp
> - ...
>
>
> So the "core" which existed in SIS 0.2 would be back, but as a group of modules rather than a single one.
>
> What do you think?
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Adam Estrada <es...@gmail.com>.
Excellent! These items should probably be migrated to the wiki too once they are implemented. Also, I just noticed that our Jira page is still referencing the URL for the incubator site[1]. I don't have the permissions to fix it...Logged a Jira issue here[2].
Adam
[1] https://issues.apache.org/jira/browse/SIS
[2] https://issues.apache.org/jira/browse/SIS-99
On May 7, 2013, at 4:45 AM, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 07/05/13 01:20, Mattmann, Chris A (398J) a écrit :
>> +1, but we should probably make all top level dirs consistent like this
>> then too, right?
>
> In this proposal, the presence or absence of "sis-" prefix in directory name would not be determined by whether the directory is top-level or not, but rather by whether the directory is for a module producing a JAR file or is just a container for such sub-modules. Or in other words, it would be determined by whether the directory is a leaf in the modules tree or not. Only leaves would have "sis-" prefix.
>
> In terms of Maven pom.xml, this would be determined by the <packaging> element. "pom" packaging would have no "sis-" prefix, because they produce nothing by themselves. "jar", "bundle" and "maven-plugin" packaging would have the "sis-" prefix.
>
> If nevertheless we want to have top-level directories that looks like consistent, one possible approach could be to group the current top-level modules (except the "app" ones) in a "core" group. So the hierarchy could be like below:
>
> core
> - sis-utility
> - sis-metadata
> - sis-referencing
> - sis-coverage
> - ...
> storage
> - sis-shapefile
> - sis-geotiff
> - sis-postgis
> - sis-netcdf
> - ...
> client
> - sis-wms
> - sis-wfs
> - sis-csw
> - ...
> application
> - sis-app
> - sis-webapp
> - ...
>
>
> So the "core" which existed in SIS 0.2 would be back, but as a group of modules rather than a single one.
>
> What do you think?
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 07/05/13 01:20, Mattmann, Chris A (398J) a écrit :
> +1, but we should probably make all top level dirs consistent like this
> then too, right?
In this proposal, the presence or absence of "sis-" prefix in directory
name would not be determined by whether the directory is top-level or
not, but rather by whether the directory is for a module producing a JAR
file or is just a container for such sub-modules. Or in other words, it
would be determined by whether the directory is a leaf in the modules
tree or not. Only leaves would have "sis-" prefix.
In terms of Maven pom.xml, this would be determined by the <packaging>
element. "pom" packaging would have no "sis-" prefix, because they
produce nothing by themselves. "jar", "bundle" and "maven-plugin"
packaging would have the "sis-" prefix.
If nevertheless we want to have top-level directories that looks like
consistent, one possible approach could be to group the current
top-level modules (except the "app" ones) in a "core" group. So the
hierarchy could be like below:
core
- sis-utility
- sis-metadata
- sis-referencing
- sis-coverage
- ...
storage
- sis-shapefile
- sis-geotiff
- sis-postgis
- sis-netcdf
- ...
client
- sis-wms
- sis-wfs
- sis-csw
- ...
application
- sis-app
- sis-webapp
- ...
So the "core" which existed in SIS 0.2 would be back, but as a group of
modules rather than a single one.
What do you think?
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1, but we should probably make all top level dirs consistent like this
then too, right?
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Monday, May 6, 2013 2:52 AM
To: "dev@sis.apache.org" <de...@sis.apache.org>
Subject: Re: Proposal to create sis-netcdf module Sunday
>Le 05/05/13 23:31, Mattmann, Chris A (398J) a écrit :
>> Let's have:
>>
>> sis-storage
>> sis-kml
>> sis-netcdf
>> sis-shapefile
>
>What about the following?
>
>storage (without "sis-" prefix)
> sis-kml
> sis-netcdf
> sis-shapefile
>
>The reason is that "storage" is not a JAR module, but only a POM
>referencing sub-modules. If we keep the convention that only "real" JAR
>modules have the "sis-" prefix, then it makes clear which directories
>are JAR modules and which directories are groups for JAR sub-modules.
>Furthermore it would keep the "sis-storage" name available for a real
>JAR module if we want to put "storage core" code in it.
>
>In addition, "storage" sub-modules could also have the
>"org.apache.sis.storage" groupId instead of only "org.apache.sis". If we
>do that way, the Maven repository would contains a sub-directory named
>"storage" with both the pom.xml definitions, and the sub-modules as
>"sis-kml", "sis-netcdf", etc. sub-directories. So the groupId, the
>package name, the directory tree in source code and the directory tree
>on the Maven repository after deployment would all be consistent.
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 05/05/13 23:31, Mattmann, Chris A (398J) a écrit :
> Let's have:
>
> sis-storage
> sis-kml
> sis-netcdf
> sis-shapefile
What about the following?
storage (without "sis-" prefix)
sis-kml
sis-netcdf
sis-shapefile
The reason is that "storage" is not a JAR module, but only a POM
referencing sub-modules. If we keep the convention that only "real" JAR
modules have the "sis-" prefix, then it makes clear which directories
are JAR modules and which directories are groups for JAR sub-modules.
Furthermore it would keep the "sis-storage" name available for a real
JAR module if we want to put "storage core" code in it.
In addition, "storage" sub-modules could also have the
"org.apache.sis.storage" groupId instead of only "org.apache.sis". If we
do that way, the Maven repository would contains a sub-directory named
"storage" with both the pom.xml definitions, and the sub-modules as
"sis-kml", "sis-netcdf", etc. sub-directories. So the groupId, the
package name, the directory tree in source code and the directory tree
on the Maven repository after deployment would all be consistent.
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Johann
Le 06/05/13 09:12, johann sorel a écrit :
> Do we keep both coverage and feature stores in the same group ?
I was thinking to merge "coverage stores" and "feature stores" in the
same group, for the reason that you mentioned (according ISO, coverage
is a special kind of feature), and also because some storage like NetCDF
and PostGIS provides both coverages and features.
> What about web services clients ?
I'm fine about putting them in a separated group.
> Just with the Geotoolkit formats, that would make about 30 modules.
Well, one think I would like to do with SIS is to reduce the amount of
modules. It make senses to have a whole module for a very complicated
format, or for a format that introduce big dependencies. But if we have
many formats that are very small, it may make senses to provide some of
them in a common module. For example "GeoTIFF", "World File" and "ASCII
grid" sound small and basic enough for being in a common module.
> What about this :
>
> sis-storage
> - sis-shapefile
> - sis-geotiff
> - sis-postgis
> - ...
> sis-client
> - sis-wms
> - sis-wfs
> - sis-csw
> - ...
Sound fine to me.
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Hi Johan,
+1 I like your proposal.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: johann sorel <jo...@geomatys.com>
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Monday, May 6, 2013 12:12 AM
To: "dev@sis.apache.org" <de...@sis.apache.org>
Subject: Re: Proposal to create sis-netcdf module Sunday
>Hi,
>
>Do we keep both coverage and feature stores in the same group ?
>What about web services clients ?
>
>In geotoolkit we have 3 groups : coverage store, feature store and
>clients.
>Examples :
>- Geotiff is a coveragestore
>- Shapefile is a featurestore
>- Postgis is both a coveragestore and featurestore
>- WMS is client and a coverage store
>- WFS is a client and a feature store
>- CSW is a client (provide metadatas but is not a coverage store or a
>feature store)
>
>Just with the Geotoolkit formats, that would make about 30 modules.
>
>I think coverage and feature store should be together since in theory
>coverages are features
>and with time I believe the apis for them will get closer and closer.
>But clients even if they provide coverage or features should be in a
>separate group.
>What about this :
>
>sis-storage
>- sis-shapefile
>- sis-geotiff
>- sis-postgis
>- ...
>sis-client
>- sis-wms
>- sis-wfs
>- sis-csw
>- ...
>
>Johann Sorel
>Geomatys
>
>On 06/05/2013 01:54, Charith Madusanka wrote:
>> +1 from me.
>>
>>
>> On Mon, May 6, 2013 at 5:20 AM, Adam Estrada <es...@gmail.com>
>>wrote:
>>
>>> Hmm...It does make sense to do it that way. I look at the way GDAL
>>> references its drivers and writing out the entire name gets to be
>>>messy,
>>> IMO. "ESRI Shapefile" with the space in it is not cool.
>>>
>>> So, if in Maven you need to reference each module with the preceding
>>>sis-*
>>> I think that would definitely be a lot cleaner.
>>>
>>> Adam
>>>
>>> On May 5, 2013, at 7:41 PM, Greg Reddin wrote:
>>>
>>>> Something like that is what I'd suggest too.
>>>>
>>>> Sent from my mobile device.
>>>>
>>>> On May 5, 2013, at 4:31 PM, "Mattmann, Chris A (398J)" <
>>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>>> +1, sounds good Martin.
>>>>>
>>>>> Let's have:
>>>>>
>>>>> sis-storage
>>>>> sis-kml
>>>>> sis-netcdf
>>>>>
>>>>> sis-shapefile
>>>>>
>>>>> Then. Sounds like we agree on package naming, so +1!
>>>>>
>>>>> Cheers,
>>>>> Chris
>>>>>
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Chris Mattmann, Ph.D.
>>>>> Senior Computer Scientist
>>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>>> Office: 171-266B, Mailstop: 171-246
>>>>> Email: chris.a.mattmann@nasa.gov
>>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> Adjunct Assistant Professor, Computer Science Department
>>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Martin Desruisseaux <ma...@geomatys.fr>
>>>>> Organization: Geomatys
>>>>> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
>>>>> Date: Sunday, May 5, 2013 2:16 PM
>>>>> To: "dev@sis.apache.org" <de...@sis.apache.org>
>>>>> Subject: Re: Proposal to create sis-netcdf module Sunday
>>>>>
>>>>>> Hello Chris
>>>>>>
>>>>>> Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
>>>>>>> What about a single module:
>>>>>>>
>>>>>>> sis-storage
>>>>>>>
>>>>>>> That has underneath it:
>>>>>>> netcdf
>>>>>>> shapefile
>>>>>>> kxml
>>>>>>>
>>>>>>> Sub modules? That should reduce the top level bloat.
>>>>>> Maybe with a slight modification?
>>>>>>
>>>>>> storage
>>>>>>
>>>>>> as the parent module, then
>>>>>>
>>>>>> sis-netcdf
>>>>>> sis-shapefile
>>>>>> sis-kml
>>>>>>
>>>>>> as sub-modules. The reason is that "leaf" sub-modules are also JAR
>>>>>>file
>>>>>> names, at least in default Maven configuration.
>>>>>>
>>>>>>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
>>>>>>> together (and similarly for o.a.sis.storage.kml, and
>>>>>>> o.a.sis.storage.shapefile)
>>>>>> Cool, org.apache.sis.storage.netcdf sound fine.
>>>>>>
>>>>>> Martin
>>>
>>
>
Re: Proposal to create sis-netcdf module Sunday
Posted by johann sorel <jo...@geomatys.com>.
Hi,
Do we keep both coverage and feature stores in the same group ?
What about web services clients ?
In geotoolkit we have 3 groups : coverage store, feature store and clients.
Examples :
- Geotiff is a coveragestore
- Shapefile is a featurestore
- Postgis is both a coveragestore and featurestore
- WMS is client and a coverage store
- WFS is a client and a feature store
- CSW is a client (provide metadatas but is not a coverage store or a
feature store)
Just with the Geotoolkit formats, that would make about 30 modules.
I think coverage and feature store should be together since in theory
coverages are features
and with time I believe the apis for them will get closer and closer.
But clients even if they provide coverage or features should be in a
separate group.
What about this :
sis-storage
- sis-shapefile
- sis-geotiff
- sis-postgis
- ...
sis-client
- sis-wms
- sis-wfs
- sis-csw
- ...
Johann Sorel
Geomatys
On 06/05/2013 01:54, Charith Madusanka wrote:
> +1 from me.
>
>
> On Mon, May 6, 2013 at 5:20 AM, Adam Estrada <es...@gmail.com> wrote:
>
>> Hmm...It does make sense to do it that way. I look at the way GDAL
>> references its drivers and writing out the entire name gets to be messy,
>> IMO. "ESRI Shapefile" with the space in it is not cool.
>>
>> So, if in Maven you need to reference each module with the preceding sis-*
>> I think that would definitely be a lot cleaner.
>>
>> Adam
>>
>> On May 5, 2013, at 7:41 PM, Greg Reddin wrote:
>>
>>> Something like that is what I'd suggest too.
>>>
>>> Sent from my mobile device.
>>>
>>> On May 5, 2013, at 4:31 PM, "Mattmann, Chris A (398J)" <
>> chris.a.mattmann@jpl.nasa.gov> wrote:
>>>> +1, sounds good Martin.
>>>>
>>>> Let's have:
>>>>
>>>> sis-storage
>>>> sis-kml
>>>> sis-netcdf
>>>>
>>>> sis-shapefile
>>>>
>>>> Then. Sounds like we agree on package naming, so +1!
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Chris Mattmann, Ph.D.
>>>> Senior Computer Scientist
>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> Office: 171-266B, Mailstop: 171-246
>>>> Email: chris.a.mattmann@nasa.gov
>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Adjunct Assistant Professor, Computer Science Department
>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Martin Desruisseaux <ma...@geomatys.fr>
>>>> Organization: Geomatys
>>>> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
>>>> Date: Sunday, May 5, 2013 2:16 PM
>>>> To: "dev@sis.apache.org" <de...@sis.apache.org>
>>>> Subject: Re: Proposal to create sis-netcdf module Sunday
>>>>
>>>>> Hello Chris
>>>>>
>>>>> Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
>>>>>> What about a single module:
>>>>>>
>>>>>> sis-storage
>>>>>>
>>>>>> That has underneath it:
>>>>>> netcdf
>>>>>> shapefile
>>>>>> kxml
>>>>>>
>>>>>> Sub modules? That should reduce the top level bloat.
>>>>> Maybe with a slight modification?
>>>>>
>>>>> storage
>>>>>
>>>>> as the parent module, then
>>>>>
>>>>> sis-netcdf
>>>>> sis-shapefile
>>>>> sis-kml
>>>>>
>>>>> as sub-modules. The reason is that "leaf" sub-modules are also JAR file
>>>>> names, at least in default Maven configuration.
>>>>>
>>>>>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
>>>>>> together (and similarly for o.a.sis.storage.kml, and
>>>>>> o.a.sis.storage.shapefile)
>>>>> Cool, org.apache.sis.storage.netcdf sound fine.
>>>>>
>>>>> Martin
>>
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Charith Madusanka <ch...@gmail.com>.
+1 from me.
On Mon, May 6, 2013 at 5:20 AM, Adam Estrada <es...@gmail.com> wrote:
> Hmm...It does make sense to do it that way. I look at the way GDAL
> references its drivers and writing out the entire name gets to be messy,
> IMO. "ESRI Shapefile" with the space in it is not cool.
>
> So, if in Maven you need to reference each module with the preceding sis-*
> I think that would definitely be a lot cleaner.
>
> Adam
>
> On May 5, 2013, at 7:41 PM, Greg Reddin wrote:
>
> > Something like that is what I'd suggest too.
> >
> > Sent from my mobile device.
> >
> > On May 5, 2013, at 4:31 PM, "Mattmann, Chris A (398J)" <
> chris.a.mattmann@jpl.nasa.gov> wrote:
> >
> >> +1, sounds good Martin.
> >>
> >> Let's have:
> >>
> >> sis-storage
> >> sis-kml
> >> sis-netcdf
> >>
> >> sis-shapefile
> >>
> >> Then. Sounds like we agree on package naming, so +1!
> >>
> >> Cheers,
> >> Chris
> >>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Chris Mattmann, Ph.D.
> >> Senior Computer Scientist
> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >> Office: 171-266B, Mailstop: 171-246
> >> Email: chris.a.mattmann@nasa.gov
> >> WWW: http://sunset.usc.edu/~mattmann/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> Adjunct Assistant Professor, Computer Science Department
> >> University of Southern California, Los Angeles, CA 90089 USA
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Martin Desruisseaux <ma...@geomatys.fr>
> >> Organization: Geomatys
> >> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
> >> Date: Sunday, May 5, 2013 2:16 PM
> >> To: "dev@sis.apache.org" <de...@sis.apache.org>
> >> Subject: Re: Proposal to create sis-netcdf module Sunday
> >>
> >>> Hello Chris
> >>>
> >>> Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
> >>>> What about a single module:
> >>>>
> >>>> sis-storage
> >>>>
> >>>> That has underneath it:
> >>>> netcdf
> >>>> shapefile
> >>>> kxml
> >>>>
> >>>> Sub modules? That should reduce the top level bloat.
> >>>
> >>> Maybe with a slight modification?
> >>>
> >>> storage
> >>>
> >>> as the parent module, then
> >>>
> >>> sis-netcdf
> >>> sis-shapefile
> >>> sis-kml
> >>>
> >>> as sub-modules. The reason is that "leaf" sub-modules are also JAR file
> >>> names, at least in default Maven configuration.
> >>>
> >>>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
> >>>> together (and similarly for o.a.sis.storage.kml, and
> >>>> o.a.sis.storage.shapefile)
> >>>
> >>> Cool, org.apache.sis.storage.netcdf sound fine.
> >>>
> >>> Martin
> >>
>
>
--
Charitha Madusanka
Linkdin : http://www.linkedin.com/pub/charith-madusanka/1a/508/42a
Twitter : http://twitter.com/#!/charithccmc
Re: Proposal to create sis-netcdf module Sunday
Posted by Adam Estrada <es...@gmail.com>.
Hmm...It does make sense to do it that way. I look at the way GDAL references its drivers and writing out the entire name gets to be messy, IMO. "ESRI Shapefile" with the space in it is not cool.
So, if in Maven you need to reference each module with the preceding sis-* I think that would definitely be a lot cleaner.
Adam
On May 5, 2013, at 7:41 PM, Greg Reddin wrote:
> Something like that is what I'd suggest too.
>
> Sent from my mobile device.
>
> On May 5, 2013, at 4:31 PM, "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov> wrote:
>
>> +1, sounds good Martin.
>>
>> Let's have:
>>
>> sis-storage
>> sis-kml
>> sis-netcdf
>>
>> sis-shapefile
>>
>> Then. Sounds like we agree on package naming, so +1!
>>
>> Cheers,
>> Chris
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW: http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Martin Desruisseaux <ma...@geomatys.fr>
>> Organization: Geomatys
>> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
>> Date: Sunday, May 5, 2013 2:16 PM
>> To: "dev@sis.apache.org" <de...@sis.apache.org>
>> Subject: Re: Proposal to create sis-netcdf module Sunday
>>
>>> Hello Chris
>>>
>>> Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
>>>> What about a single module:
>>>>
>>>> sis-storage
>>>>
>>>> That has underneath it:
>>>> netcdf
>>>> shapefile
>>>> kxml
>>>>
>>>> Sub modules? That should reduce the top level bloat.
>>>
>>> Maybe with a slight modification?
>>>
>>> storage
>>>
>>> as the parent module, then
>>>
>>> sis-netcdf
>>> sis-shapefile
>>> sis-kml
>>>
>>> as sub-modules. The reason is that "leaf" sub-modules are also JAR file
>>> names, at least in default Maven configuration.
>>>
>>>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
>>>> together (and similarly for o.a.sis.storage.kml, and
>>>> o.a.sis.storage.shapefile)
>>>
>>> Cool, org.apache.sis.storage.netcdf sound fine.
>>>
>>> Martin
>>
Re: Proposal to create sis-netcdf module Sunday
Posted by Greg Reddin <gr...@gmail.com>.
Something like that is what I'd suggest too.
Sent from my mobile device.
On May 5, 2013, at 4:31 PM, "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov> wrote:
> +1, sounds good Martin.
>
> Let's have:
>
> sis-storage
> sis-kml
> sis-netcdf
>
> sis-shapefile
>
> Then. Sounds like we agree on package naming, so +1!
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
>
> -----Original Message-----
> From: Martin Desruisseaux <ma...@geomatys.fr>
> Organization: Geomatys
> Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
> Date: Sunday, May 5, 2013 2:16 PM
> To: "dev@sis.apache.org" <de...@sis.apache.org>
> Subject: Re: Proposal to create sis-netcdf module Sunday
>
>> Hello Chris
>>
>> Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
>>> What about a single module:
>>>
>>> sis-storage
>>>
>>> That has underneath it:
>>> netcdf
>>> shapefile
>>> kxml
>>>
>>> Sub modules? That should reduce the top level bloat.
>>
>> Maybe with a slight modification?
>>
>> storage
>>
>> as the parent module, then
>>
>> sis-netcdf
>> sis-shapefile
>> sis-kml
>>
>> as sub-modules. The reason is that "leaf" sub-modules are also JAR file
>> names, at least in default Maven configuration.
>>
>>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
>>> together (and similarly for o.a.sis.storage.kml, and
>>> o.a.sis.storage.shapefile)
>>
>> Cool, org.apache.sis.storage.netcdf sound fine.
>>
>> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1, sounds good Martin.
Let's have:
sis-storage
sis-kml
sis-netcdf
sis-shapefile
Then. Sounds like we agree on package naming, so +1!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Sunday, May 5, 2013 2:16 PM
To: "dev@sis.apache.org" <de...@sis.apache.org>
Subject: Re: Proposal to create sis-netcdf module Sunday
>Hello Chris
>
>Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
>> What about a single module:
>>
>> sis-storage
>>
>> That has underneath it:
>> netcdf
>> shapefile
>> kxml
>>
>> Sub modules? That should reduce the top level bloat.
>
>Maybe with a slight modification?
>
> storage
>
>as the parent module, then
>
> sis-netcdf
> sis-shapefile
> sis-kml
>
>as sub-modules. The reason is that "leaf" sub-modules are also JAR file
>names, at least in default Maven configuration.
>
>> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
>> together (and similarly for o.a.sis.storage.kml, and
>> o.a.sis.storage.shapefile)
>
>Cool, org.apache.sis.storage.netcdf sound fine.
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 05/05/13 23:05, Mattmann, Chris A (398J) a écrit :
> What about a single module:
>
> sis-storage
>
> That has underneath it:
> netcdf
> shapefile
> kxml
>
> Sub modules? That should reduce the top level bloat.
Maybe with a slight modification?
storage
as the parent module, then
sis-netcdf
sis-shapefile
sis-kml
as sub-modules. The reason is that "leaf" sub-modules are also JAR file
names, at least in default Maven configuration.
> In addition, +1 to keeping all o.a.sis.storage.netcdf.*
> together (and similarly for o.a.sis.storage.kml, and
> o.a.sis.storage.shapefile)
Cool, org.apache.sis.storage.netcdf sound fine.
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
Hey Martin,
What about a single module:
sis-storage
That has underneath it:
netcdf
shapefile
kxml
Sub modules? That should reduce the top level bloat.
In addition, +1 to keeping all o.a.sis.storage.netcdf.*
together (and similarly for o.a.sis.storage.kml, and
o.a.sis.storage.shapefile)
Cheers!
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Sunday, May 5, 2013 1:58 PM
To: "dev@sis.apache.org" <de...@sis.apache.org>
Subject: Re: Proposal to create sis-netcdf module Sunday
>Thanks for the vote, I started the creation of a NetCDF module on my
>local machine.
>
>Maybe we should find now a naming convention for those kind of modules?
>After NetCDF, we will probably have Shapefile, KML and many others. One
>possible schema could be "sis-store-something", e.g.:
>
> * sis-store-netcdf
> * sis-store-shapefile
> * sis-store-kml
>
>An alternative could be "sis-data-something".
>
>Similar question apply to the package name. In Geotk, the NetCDF
>metadata part was in "org.geotoolkit.metadata.netcdf" and the Coverage
>I/O part in an other package. But for SIS I would like regroup all
>NetCDF stuff in a single package, for reducing the amount of packages.
>What about the following?
>
> * org.apache.sis.store.netcdf
>
>Again an alternative could be "org.apache.sis.data.netcdf". However
>"data" suggests more to me a particular set of data rather than a
>storage mechanism...
>
> Martin
>
Re: Proposal to create sis-netcdf module Sunday
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Thanks for the vote, I started the creation of a NetCDF module on my
local machine.
Maybe we should find now a naming convention for those kind of modules?
After NetCDF, we will probably have Shapefile, KML and many others. One
possible schema could be "sis-store-something", e.g.:
* sis-store-netcdf
* sis-store-shapefile
* sis-store-kml
An alternative could be "sis-data-something".
Similar question apply to the package name. In Geotk, the NetCDF
metadata part was in "org.geotoolkit.metadata.netcdf" and the Coverage
I/O part in an other package. But for SIS I would like regroup all
NetCDF stuff in a single package, for reducing the amount of packages.
What about the following?
* org.apache.sis.store.netcdf
Again an alternative could be "org.apache.sis.data.netcdf". However
"data" suggests more to me a particular set of data rather than a
storage mechanism...
Martin
Re: Proposal to create sis-netcdf module Sunday
Posted by "Mattmann, Chris A (398J)" <ch...@jpl.nasa.gov>.
+1 from me
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.fr>
Organization: Geomatys
Reply-To: "dev@sis.apache.org" <de...@sis.apache.org>
Date: Friday, May 3, 2013 10:52 AM
To: Apache SIS <de...@sis.apache.org>
Subject: Proposal to create sis-netcdf module Sunday
>Hello all
>
>If peoples agree, I could create a sis-netcdf module this Sunday and
>port the CF 1.5 - ISO 19115 binding. It should be quick since I do not
>envision major changes, and would give peoples an opportunity to start
>experimenting ISO metadata on real data files. This binding is specified
>by NOAA, so anyone working with NOAA data would be in good position for
>improving that module after the initial commit if they wish.
>
>The initial commit would be only the metadata part of NetCDF. The actual
>data part would need to be done later (after we ported a "sis-coverage"
>module...)
>
>Does it sound okay?
>
> Martin
>