-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bryce L Nordgren
Sent: 06 March 2006 19:59
To: Martin Desruisseaux
Cc: geotools-devel
Subject: Re: [Geotools-devel] Looking for 19107 implementation
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
