JTS1.7 only provides translations from JTS to an oracle STRUT and back ... that is to say, you only need to cast the value from ResultSet.getObject(int) to STRUT, pass it into the library, and get a JTS geometry out. You will still have to deal with figuring out which col's result to cast, and pass through (which the ResultSet metadata should provide).
DZ
On 2/7/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
David Zwiers wrote:
> Jody,
>
> Did you get this sorted out? Do you need some info? Did you want some
> help (If you point me at your sql generation routines I can take a
> look for you)?
I think I need time, and to punt the oracle datastore down to
"unsupported" ;-) I have a big fat oracle spatial book next to me - all
that is needed is careful attention to detail.
> I also forgot to mention one thing, there is a very good reason to
> clump all the Clob, Blob and mdsys.sdo_geometry cols at the end of the
> geom list ... chaining. If you are going to chain on disk, you want to
> ensure all of your search criteria (or atleast most) is in the first
> block. For most installs, if chaining is going to happen it's from a
> blob, clob, geometry, (complex object) col ... so pushing these to the
> right tells the db to store them last in the block on disk. Just
> though I'd mention it because it sounded like you wanted to create ora
> tables on the fly.
Okay I will keep that in mind as well, although I am likely to do what
the user tells me to (aka they provide a schema). How ever it has been
pointed out that a Schema is not the nicest way to specifiy things like
creation - they are immutable for example. P. Rizzi had a better system
(unfortauntly he called it "metadata") that was not persued as far as I
know.
Bleah - need to fix what is in front of me. The code is in svn, the
current code updates the wrong table - aka the table, not the view like
it is supposed to. Aside: how much of the SDO code can I retire as we
move over to JTS 1.7? It would be nice to take those test cases out of
the build.
Cheers,
Jody
