Hi Martin, On Jul 30, 2012, at 4:14 PM, Martin Desruisseaux wrote:
> Hello Chris > > Le 30/07/12 19:50, Mattmann, Chris A (388J) a écrit : >> OK to clarify, OSGeo will discuss this issue at their board meeting on 8/9? > Yes, I will keep this list informed. > > >> Sure feel free to start threads here on sis-dev@ to discuss your thoughts. > I saw the 5 modules in the root directory of the SIS project. The first thing > that come to my though was that if the project growth to 1 million lines of > code (which could happen relatively fast), we are going to have a lot of > modules. What about a directory tree a little bit deeper, which regroup > modules by category? We could have the following categories among others: The below look pretty good in terms of organization. I like the idea of having top-level modules too. A few comments: > > * utilities Before we create a utils package, I like to find classes that don't fit in any of the other categories. Do you have some ideas as to what would fit into here now? > * metadata I would imagine metadata here would refer to arbitrary metadata support and/or specific Geo metadata models? If so, then I think we should leverage Apache Tika (http://tika.apache.org/) as much as possible for doing that. There are already a few issues filed to help tie together Tika and SIS here: https://issues.apache.org/jira/browse/SIS-32 https://issues.apache.org/jira/browse/TIKA-605 > * referencing Is this like geo-location and geo-referencing for coordinate system support? If so, I filed an issue already for this: https://issues.apache.org/jira/browse/SIS-9 > * geometry Seems similar to: https://issues.apache.org/jira/browse/SIS-51 (distance being just one of the many possible geometric functions) > * feature We don't have support for this yet, if this is like WFS, etc. > * coverage WCS? We did discuss a WMS-like service here: https://issues.apache.org/jira/browse/SIS-28 > * processing What type of processing would this be? Like raster processing? Tiling? > * index I think I called this "storage" -- this would be the persistence layer for the spatial data structures, e.g., https://issues.apache.org/jira/browse/SIS-8 https://issues.apache.org/jira/browse/SIS-33 > * display For us, this would be: https://issues.apache.org/jira/browse/SIS-43 > * client I think for us this would be: https://issues.apache.org/jira/browse/SIS-11 https://issues.apache.org/jira/browse/SIS-46 > > Each category is a directory, which contains one or many modules. For example > the "coverage" category could contains the following modules: > > * sis-coverage > * sis-coverageio > * sis-coverageio-netcdf Sure that makes sense. Think about the above in the context of the JIRA issues I sent you and I would be happy to discuss smallish, intermediate next steps to get there. > > I noticed that the current SIS code contains a "sis-core" module. What about > trying to put the content of "sis-core" in some more specific modules? > Otherwise I think that core may become very big if "referencing", "geometry", > "feature" etc. are considered as core... Sure, that makes a lot of sense. Right now, core is a catch-all for functionality that sis-webapp and sis-app depend on. But, I'd be happy to discuss a better refactoring based on the above. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
