Martin Desruisseaux <[EMAIL PROTECTED]> wrote on 03/05/2006
12:29:40 AM:
> I already though about it (and missed time, like usual). I would be
> very glad if someone else could
> begin to create this geometry module!
If I end up specifying Geometry for use within the Coverage module, it's
going to consist of "points-and-as-little-else-as-I-can-get-away-with". :)
But it'll be a start.
> As Dave point out, the geooxygen project may worth a look. But I
> don't know much about them.
> My proposal (what I would have liked to do if I had time to start
> coding this geometry module) is to
> adapt JTS. More specifically, create the following package:
>
> org.geotools.geometry.jts
Agreed.
> Wrapping degree code would not have much interest for Geotools,
> since we don't use Degree geometry
> objects (by the way, I believe that Degree's API on the geometry
> part come from the early GeoAPI
> days, before the packages settle down). Wrapping JTS code (instead
> of adapting it) would provides a
> transition path between JTS-dependent code and GeoAPI-dependent
> code. This transition path is likely
> to be needed.
This would seem to apply to all non-JTS code. I've looked at some of the
suggestions so far. None of them implement GeoAPI. One of them bears only
a superficial resemblance to 19107 (e.g., the classes have the right names,
but most of the method names are "custom") Worse, none of the suggestions
so far seems like a very active project. That alone scares me off. ;)
> A limitation of JTS wrappers is that they would work only for
> geometries in a 2D cartesian space. We
> should make that clear in the documentation. However, it would be a
> valuable start. It would give us
> more time for looking alternative implementation in the future
> (geooxygene?), if we wish.
Out of curiousity, does JTS work in a lat/lon space? Mentally, I can't
picture it working with axes that aren't length units.
BTW- This should make our lives easier. ISO 19107 / OGC Abstract Spec
Topic 1:
"There are 39 comformance classes for application schemas that instantiate
geometric or topological objects. They are differentiated on the basis of
three criteria. The first two criteria determine the types defined in this
schema that shall be implemented by an application schema that conforms to
a given conformance option. The third criterion determines the elements of
those types that shall be implemented.
The first criterion is level of data complexity. Four levels are
identified: Geometric primitives, GeometricComplexes, Topological
complexes, Topological complexes with geometric realization.
The second criterion is dimensionality. There are four levels for simple
geometry: (0), (0 & 1), (0, 1, & 2), and (0, 1, 2, & 3) dimensional
objects. However, [0 dimensional is useless, so is omitted].
The third criterion is level of functional complexity. There are three
levels: data types only, simple operations, complete operations."
JTS probably covers ("2D, Complete Operations, geometric primitives" and at
least "2D, simple operations, geometric complexes.") I have to look closer
to see exactly what each one entails. The point is that we can express our
"conformance level" in the terms laid out by the standard. With 39 levels
to pick from, one of them should probably do the trick.
> So my vote would be: Adapters around "official" JTS objects (not a
> rewrite of JTS).
I don't mean to sound flattering, but I'm not nearly smart enough to do
that. I'm only smart enough to swipe the code.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
