Yeah, I agree it would be very weird, just wanted to cover all bases.
I
investigated and that definitely wasn't the problem. So it looks like
the
coordinate parsing works. I can't help you with oracle specific
problems,
as I don't have an oracle install or access to any. So Sean is your
best
bet, hopefully his jar will help?
His jar actually worked, but the problem was not the sdoapi.jar. It was
the jdbc driver (he sent me that too)! I then started to investigate a
bit, downloaded several jdbc driver version (there are driver versions
for different jdk and for different oracle versions...) and all I tried
did not work. I decided then to try the jdbc drivers that are part of
the oracle installation and guess what, they worked! The bottom line of
all this: use the jdbc driver that is part of the oracle installation.
I've just recently applied a patch to my installation (oracle 9.2.0.4).
So my best guess is, that the jdbc driver was also somehow patched (the
latest downloadable version of the driver is for oracle 9.2.0.3).
Hope this helps anybody that gets into the same situation.
This would be something that should be mentioned in the readme of the
oraclespatial module.
Simon
On Thu, 11 Dec 2003, Simon Räss wrote:
> >
> > What are the error's you're getting? Another thing to try is to
> declare
> > all the namespaces with prefixes and use those, as that's how
we've
> tested
> > everything. I agree that we should also support this way, but am
> curious
> > about figure out exactly what's going wrong here.
> >
>
> I changed the request xml so that it uses prefixes everywhere. But
of
> course it did not work either (if it did work, it would be a VERY
> strange).
>
> The error I get is:
> org.vfny.geoserver.responses.WfsTransactionException:
> org.vfny.geoserver.responses.WfsTransactionException: Problem
updating
> features:
> org.geotools.data.DataSourceException: Geometry Conversion error
when
> adding features:
> java.sql.SQLException: Logisches Handle nicht mehr gültig cause:
> oracle.sdoapi.geom.InvalidGeometryException: java.sql.SQLException:
> Logisches Handle nicht mehr gültig
> at
>
org.vfny.geoserver.responses.TransactionResponse.getSub(TransactionRespo
> nse.java:212)
> at
>
org.vfny.geoserver.responses.TransactionResponse.getXmlResponse(Transact
> ionResponse.java:105)
> at
> org.vfny.geoserver.servlets.Transaction.doPost(Transaction.java:65)
> at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>
> >
> > On Wed, 10 Dec 2003, Simon Räss wrote:
> >
> > > I cannot get inserts working. The features I receive on the
server
> side
> > > do not have any attributes. The attributes are somehow dropped
along
> the
> > > xml filter chain. It is (most likely) not a data source related
> problem.
> > > I believe the source of problems lies in
TransactionFeatureHandler.
> > >
> > > Any ideas what might cause this problem? Otherwise I will start
to
> debug
> > > the filter chain step by step and see where the attributes are
> dropped
> > > (the received xml seems to be ok).
> > >
> > > An example of what I receive on server side:
> > > <?xml version="1.0" encoding="utf-16"?>
> > > <wfs:Transaction version="1.0.0" service="WFS"
> > > xmlns:wfs="http://www.opengis.net/wfs">
> > > <wfs:Insert handle="insert gps point">
> > > <RQS_POINT xmlns="http://www.someserver.com/myns">
> > > <GEOM>
> > > <Point xmlns="http://www.opengis.net/gml">
> > > <coord>
> > > <X>202238.869</X>
> > > <Y>604600.558</Y>
> > > <Z>578.672</Z>
> > > </coord>
> > > </Point>
> > > </GEOM>
> > > </RQS_POINT>
> > > </wfs:Insert>
> > > </wfs:Transaction>
> > >
> > > Another question: are optional attributes supported by the
> > > TransactionFeatureHandler? The above feature type could have
some
> more
> > > attributes but they are all optional (in short: the FeatureType
has
> a
> > > corresponding attribute for them, but the created feature does
not).
> > > Does this cause any problems? I think I've glimpsed some
potential
> > > problem areas, that's why I ask.
> > >
>
> Optional attributes do not seem to work in oracle spatial
datasource.
> Oracle data source fails if there are less attributes in a feature
than
> attribute types in a feature type (don't know about other
datasources).
> Actually, this may be partly (is?) the fault of
> TransactionFeatureHandler that does not create a proper attribute
array
> that is passed to the create method of FeatureType. I am lucky
enough to
> write the client software myself so I can make sure these attributes
are
> added to each request. So for the moment, I can work around this
> particular problem.
>
> I'm seriously thinking about rewriting this whole transaction
request
> xml handling stuff. I'm running constantly into things that do not
work
> as expected. What would be the requirements for this? I've seen the
> thread on geotools-dev list from Ian Schneider about gml parsing.
>
> Simon
>--