staylor@anonymised.com wrote:
Yeah I only support what was in the documentation, and this class (SDO)
was picked up by JTS recently, and
thus I can probably retire it. Can you try making use of JTS 1.7 and
see if it does any better?
By "the documentation", do you mean 'OpenGIS Simple Features Specification
for SQL, Revision 1.1'? Or is JTS a replacement for these specifications?
JTS is an implementation of the SFSQL specification, however the Oracle SDO stuff predates the SFSQL specification and has
a slightly different outlook on life (it allows curves for example). JTS 1.7 has recently updated its code for taking geometry into and out of oracle.
It still won't do curves, but they may have fixed a bug or two.
(I'm very confused!) Another example of the kind of Oracle data I'm trying
to deal with isSDO_GEOMETRY(2002, 82474, NULL, SDO_ELEM_INFO_ARRAY(1, 4, 1, 1, 2, 2),
SDO_ORDINATE_ARRAY(212617.232, 599480.464, 212690.034, 599577.342,
212809.778, 599595.966))
The first triplet (1, 4, 1) of the element info array denotes a compound
line string, while the second triplet (1, 2, 2) denotes a line string of
circular arcs.
Yep that is the kind of thing that should not work. We could bring it across as a linestring (and print a warning) but right now we may just throw you
an exception.
I know that 'Simple Features Specification for SQL'
specifies no subclass of Curve other than LineString, but I don't mind
approximating circular arcs with chords: this approximation can apparently
be done within GeoTools using the function GT_PLARC2PL, so has a similar
Oracle data-transformation problem already been implemented in GeoTools?
(And how can I search for the GeoTools classes that make use of
GT_PLARC2PL?)
We have not implemented anything yet, however if you had a patch we could make use of it. However we are likely to drop our support and
rely on JTS 1.7 as indicated above.
And how would I make GeoServer use JTS 1.7 rather than SDO? (If that is
what you meant - sorry!)
I would start with a Jira request, and talking to the geoserver list to see who can help.
For something like this, I would subclass oracle datastore and ask it to
use a new SDO class. For you new SDO class
you can teach it how to recognize your ETYPE 0 (and its intended
meaning).
Any help or hints as to how to get started would be greatly appreciated.
Or can anyone point to the appropriate section(s) of the GeoTools
design?The javadocs for SDO are very complete, SDO is used by an
GeometryConverter which is where you would need to subclass, and perform
any STRUCT manipulation. If there are any additional ETYPES which you
can smoothly adapt to JTS please feel free to
add them. Although the warning about moving over to JTS1.7 should be
noted.
Sorry for the crudeness of my understanding, but exactly would class would
I sublass? OracleDatastore? Or GeometryConverter? Does the change to
JTS1.7 mean that I have to be careful which classes I use in my code?
I think you would need to subclass *everything*. You can try out JTS 1.7 first, but I have not heard of them
adding even approximate curve support.
These classes are called by SDOAttributeIO (which is only engaged for
geometry columns).Would my transformation code be most similar to that in SDOAttributeIO?
Yes, you would simply detect the cruve type and produce chords instead of an error.
You chose a really hard problem to introduce yourself to the community, please keep us informed 
Jody