On 7/15/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Hello all
>
> I noticed that two new experimental modules, "arcgrid" and "ArcGrid_ImageIO"
> have been commited to
> trunk. Thanks for commiting them on trunk; it make easier for me to take a
> look at them soon (I tend
> to look at branches much least frequently than trunk). I would like to share
> the following though:
>
> * Would it be better to put those modules in "plugins" rather than "ext",
> since they looks like Image I/O and GridCoverageExchange plugins to me?
Actually, this was an error caused by the lack of time. I wanted to
put them under spike not trunk since, as Andrea pointed out, this is
experimental work that me and another guy are doing in order to
replace arcgrid plugin and to provide an example of how to write
coverage plugins based on imageio plugin concept.
Conclusion is that I am going to move them under spike for the moment.
>
> * Since I do not expect "ArcGrid_ImageIO" to be a huge module, and since I
> do not expect
> most of the other pure-Java Image I/O modules to be huge neither, would
> it make sense
> to create a plain "plugin/imageio" module instead and put ArcGrid as well
> as any other
> "reasonably sized" image I/O plugins there? I would prefer a ~500 kb
> module instead than
> dozen of ~50 kb modules. Of course if a particular plugin produces a big
> JAR file alone,
> or if a set of plugins are mutually exclusive (for example users
> typically use only one
> of "epsg-access", "epsg-postgresql" or "epsg-hsql" - choosing one usually
> exclude the
> others), or if a plugin has a large amont of dependencies that are unique
> to this plugin,
> then this particular plugin may live in his own module. But otherwise I
> would like to
> avoid a multiplication of small JAR files.
>
> * Same for "ext/arcGrid". Would it make sense to create a plain
> "plugin/coverageio"
> module instead?
>
Situation here is still fluid. I want to put these things under spike
since for the moment thery are experimental work. In the end the
geotools part of the plugin will reside for sure under its own plugin
dir
but I am still unsure about where to place the imageio core. I am not
sure that geotools is the right place for it, it should belong to the
imageio project as a child project I guess, hence once again, spike
for the moment is the best place for these packages.
> * Minor note: "ext/ArcGrid_ImageIO" contains "project.xml" and
> "run-maven.xml" files,
> which are remanescence of the old Maven 1 build system and should be
> deleted. Only
> "pom.xml" and "LICENSE.txt" should be left in this directory.
Sorry about that.
>
> * The current package names are:
>
> - org.geotools.gce.imageio.asciigrid
> - org.geotools.gce.arcgrid
>
> Can I suggest the following package names instead?
>
> - org.geotools.image.io.<something>
> - org.geotools.coverage.io.<something>
>
> Rational:
>
> - "gce" stands for "GridCoverageExchange", which is a name from the
> legacy OGC 01-004
> specification. The new ISO 19123 specification has nothing similar. I
> don't know if
> ISO will come with some equivalent classes. But we can said that the
> future of the
> "GridCoverageExchange" name is not assured.
>
> - "org.geotools.image.io" and "org.geotools.coverage.io" already exist
> in current
> packages naming. We may have some advantages in leveraging the
> existing packages.
>
> - "org.geotools.coverage.io" make clear that this is about I/O of
> Coverage objects,
> and the relationship with the "org.geotools.coverage" package is
> obvious. This is
> not true for "org.geotools.gce".
>
> - "org.geotools.image.io" make clear that this is about I/O of
> RenderedImage objects,
> and the relationship with "org.geotools.image" is obvious. It also
> make clear that
> Image I/O do not (or should not) depend on coverage ("Coverage"
> depends on "Image",
> but we should avoid dependency the other way). The
> "org.geotools.gce.imageio" name
> suggests a relationship with "GridCoverageExchange" that I would like
> to avoid. I
> think that Image I/O should be independent of coverages as much as we
> can.
>
>
> Martin.
>
I agree with the package renaming for the geotools counterpart, but I
think that we should do the same on all the coverage plugins first. We
can discuss this after the merge is done, I thnk this is the kind of
work to be done at that point.
Simone.
--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant
http://simboss.wordpress.com/
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
