Thank you all for your answers!!! Now I understand the reasons.
Downloading the jar from the Oracle site is not difficult,
but you have to register, so GeoTools can not redistribute it.
And you decided to write your own SDO library because the Oracle' one
was slow, that's a very good reason.
In the end Chris idea seems good, having a separate DataStore that
checks for the jar presence.
The problem I'm facing now is that of a MULTIPOLYGON instance
(GTYPE=2007) having a SDO_ELEM_INFO like this:
[1, 2003, 1, 9, 2003, 1, 19, 1003, 1, 35, 2003, 1]
so the exterior polygon is not in the first triplet.
I don't know if this geometry is valid or not, I asked Oracle
and I'm waiting for an answer.
If it's not valid, then we have no problem, but if it's indeed
valid there's an error inside SDO.createMultiPolygon(), because
it always expects the first triplet to describe the exterior ring.
We can fix that bug, but how many other bugs am I to encounter???
Maybe the Oracle library is slow, but it should work more relialably
than the GeoTools' one, or not???
Bye Paolo
> -----Messaggio originale-----
> Da: Chris Holmes [mailto:[EMAIL PROTECTED]
> Inviato: venerdì 28 ottobre 2005 9.22
> A: Jody Garnett
> Cc: P.Rizzi Ag.Mobilità Ambiente; [EMAIL PROTECTED];
> GeoTools-devel
> (E-mail)
> Oggetto: Re: [Geotools-devel] Why arent' we using the "Oracle Spatial
> Java Class Library " from Oracle???
>
>
> Quoting Jody Garnett <[EMAIL PROTECTED]>:
>
> > P.Rizzi Ag.Mobilità Ambiente wrote:
> > > Yes, why???
> > > I'm sure there should be a reason, but why are we
> fiddling directly
> > with
> > > SDOs, GTYPEs
> > > and all the other Oracle geometry madness, instead of using the
> > Oracle
> > > provided Java library???
> > > It should be contribute to render the OracleDataStore much more
> > reliable.
> > > Please let me know!!!
> > >
> > Um do you mean sdoapi.zip - they were making that hard to download
> > (and
> > talking about removing it). The version we did have that
> used it made
> > the Oracle object, turned it into WKT and then parsed the WKT into
> > JTS
> > Geometry objects. If you need to make the SDO utility class faster
> > there is plenty of room for optimization (it is designed to be
> > correct
> > first, and testable), unwinding the recursion and eveything is all
> > possible for speed.
>
> I think they've actually made it easier to download now. I think the
> thing to do, which I discussed a bit with Marc, is to make it a config
> option for the datastore, to use the sdo api, or not. I believe it
> should just be one or two classes that would be the different readers
> and writers for sdo and non-sdo. Each has advantages and
> disadvanteges, and the oracle jar based one should be pretty easy to
> write. If you were to take a crack at it Paolo then I think we could
> include it as an option, though probably better to default to the one
> that does not need the additional jar, the config option could just be
> there if the jar is on the path... Marc and I talked about it a bit,
> and the easiest way to do that would probably be to make a new
> datastore, in the style of the thick client option for oracle, that
> only has isAvailable() to true if the jar is on the path.
>
> Chris
>
> >
> > We use all the other mock stuff because we cannot expect everyone
> > that
> > compiles geotools to go through the oracle I am not a criminal
> > madness to
> > download the jar.
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.
> > Get Certified Today * Register for a JBoss Training Course
> > Free Certification Exam for All Training Attendees Through End of
> > 2005
> > Visit http://www.jboss.com/services/certification for more
> > information
> > _______________________________________________
> > Geotools-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
AVVERTENZE AI SENSI DEL D. LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i, sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceveste questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario ai
principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse.
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
