This content has been marked as final. Show 8 replies
You're using the third dimension. Apparently Oracle does not support 3D WKT geometry, look at [url http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks/273/3d-4d-and-srid-aware-conversion-functions-for-sdo_geometry-wkt-and-ewkt]this post from Simon for some alternatives.
Depending on what Autodesk means by EnvelopeIntersects, any of Oracle's [url http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_operat.htm#i76448]spatial operators can be used.
Judging from the name I would say it's most likely SDO_OVERLAPBDYINTERSECT, but I'm not sure how Autodesk defines it's operators and their functionality.
You are using FDO right?
Is that Autocad or AutoCAd Map or something else?
Where did you got that expression from? From a config file?
Envelope intersect relates to SDO_FILTER
(quick link from MapGuide which uses the same FDO Framework)
Edited by: Luc Van Linden on May 31, 2013 1:27 PM
In addition, read this thread with contributions from Simon Greener and Paul Dziemiela on this topic:
Java Exception with SDO_UTIL.FROM_WKTGEOMETRY
Note also that the last vertex should be the same as the first, closing the ring. In your example this is not the case either.
So I am a bit curious where you got that notation from? Are you developing something yourself using the AutoCAD (MAP) API's?
We talked in the past that a lot of this confusion could be mitigated if the Oracle documentation just stated clearly what version of the OGC specification the WKT functions support. Been a bit of talk on the forum recently on various OGC support issues and it strikes me as being kind of unproductive since nothing has changed in terms of OGC support since... I guess since the GML 3.1.1 functions were released with 11gR1. Is that correct? And before that? So the situation could be termed as being "very stable". :)
Oracle Spatial WKT functionality (as of 188.8.131.52) pretty simply only supports the Simple Features 1.1 specification. End of story. Be nice if it said so here:
I'll try this weekend to submit an enhancement request for that as I don't think anyone else has.
Meanwhile most of us either use Simon's JTS solution or long ago coded our own readers/writers in PLSQL.
I've been trying to think of ways we could somehow inspire more forum users to submit SRs on the issues they bring up here. I am as lazy as the next person on the matter. Maybe some kind of point rewards for putting in SRs? I am not looking for folks to just knee-jerk submit SRs to every posting, but clearly there are some communities of interest (GML users for example) that could document their collective concerns through metalink.
I agree that people should add themselves to the appropriate SR's if those are being a bother to them (I used to work "on the other side", not Oracle but other software vendors - I know the drill ...).
But I don't have access to oracle support, so unfortunately can't add myself to anything, otherwise I would have.
Maybe some kind of point rewards for putting in SRs?I don't think that would be helpful, that is the wrong kind of incentive. The only thing that would really help is Oracle being responsive to SR's, but that is a difficult thing (it has no immediately visible ROI).
Maybe if we keep nagging them on the forums ... :-)
I share your idea that whatever we can do to contribute to solutions or fixes or requirements, we should help.
To some extent by getting (necessary) workarounds in (quick) place, the pressure gets off, and equally so the ROI or business case for Oracle. So also Stefan has a point, as this mainly how these fixes are being evaluated in priority.
Also, in this case, I believe (I can be wrong) the real cause here is as such an incorrect usage of the development framework (FDO) being used (either by the software) either by its developer using it. I think if Ananda fixes the polygon notation being a valid geometry (being it a WKT POLYGON Z), the problem should go away, as the FDO framework should take care of the effective correct SQL being passed to Oracle.
Having that said, by testing again the usage of the 3D WKT in SQL+ or developer, brings the issue back to the surface, which as such is again a good point.
Are you using some functionality that is custom made/developed? In that case the FDO framework should take care of WKT 3D conversion as long that you pass in the correct parameters (valid geometry for example).
If you are using some standard function provided by Map 3D, causing you with this error or issues, you might be better off posting it to the MAp3D forum on Autodesk's website.