Irritation level is getting pretty huge

Question

Wow, spatial is starting to be a really huge PITA!  Below, "sources" is a cursor...
vnode sdo_geometry ;
DBMS_OUTPUT.PUT_LINE(' Source Geom = ' || SDO_UTIL.TO_WKTGEOMETRY(sources.geom)) ;
output =  Source Geom = POINT (-118.18981 34.13884)
v_node := SDO_UTIL.POINT_AT_BEARING(sources.geom,0,500) ;
DBMS_OUTPUT.PUT_LINE(' Return from PAB call = '|| SDO_UTIL.TO_WKTGEOMETRY(V_NODE)) ;
Return from PAB call = POINT (-118.18981 34.1433475527035)
DBMS_OUTPUT.PUT_LINE('getting x1  '||sources.geom.sdo_point.x) ;
output = getting x1  -118.18981
DBMS_OUTPUT.PUT_LINE('getting y1  '||SOURCES.GEOM.SDO_POINT.Y) ;
output = getting y1  34.13884
DBMS_OUTPUT.PUT_LINE('getting x2  '||v_node.sdo_point.y) ;
output = getting x2 
DBMS_OUTPUT.PUT_LINE('getting y2  '||v_node.sdo_point.y) ;
output = getting y2
This is really starting to make me a little crazy.  I have tried surrounding v_node in a with n as () statement to give them an alias, I have tried making v_node a simple sdo_point_type and still CAN't extract the vertice so I can take two points and make a line string,  The are 500 meters apart so I can have a nice straight line geometry but I am frustrated at every turn! The only thing I have found that works is to extract them to a wkt and then to all sorts of subtr and instr functions to drag them out and that is a major PITA.  Anyone have a better idea or am I just totally missing the boat on something?
Cheers!

Answer 1

FlyingGuy wrote:
While one can argue where to put the business logic I prefer it on the DB server, just my preference since there really is no right or wrong in that regard.
Not wanting to spawn one of "those" discussions again, I do agree with you completely here. What a waste of resources not to use the DB for that....
FlyingGuy wrote:
The documentation seems like a lot of documentation that was written by engineers, for engineers and not by technical writers who know how to logically lay out things so that anyone can work through it,  The whole "cola" thing assumes WAY to much spatial knowledge and does not start with the basic building blocks and then work from there.  It mostly looks like it was derived from javadocs which are NOT documentation by any stretch of the imagination.
As I've said before, the whole Orale Spatial thing was never meant to be used as a front end, but as a back end with applications talking to it and those applications would be used by the users (with less knowledge). The back end was meant to be maintained and developed by administrators, dba's, developers with more knowledge than the average Joe. That is how it was explained to me by Oracle, and I think it still holds true. The problem is with the mainstreaming of geo-information you start to see people with no geodetic knowledge starting to fiddle with geo-data, and then you have a problem. I still see users zooming in on data until they can see the last 10th of a millimeter on screen, while the data has been gathered by vectorizing aerial photograps. Which implies an accuracy, precision and reliability that runs in 10s of centimeters if you're lucky, so zooming in that far is useless.
I do agree that some of the documentation could be a bit better, but that is also up to us: If you look at the docs online , you'll notice that all the way at the bottom there's an option to leave comments (@Paul: that might enable you to leave a comment as well). So we should probably use that option a little bit more.
FlyingGuy wrote:
hibernate or spring
IMHO those two should be placed in the deepest pits of hell to burn forever....
FlyingGuy wrote:
Anyway.. Like many things in Oracle there is a steep learning curve and the docs don't make it easy for the spatialy uninitiated.  I thnk all of you for your help, suggestions and pointers to where I can get more in depth with this stuff.
Cheers to all!
I've learned a lot on these forums myself, and am happy to be able to repay some of that   Besides, it's a nice diversion when you are waiting for another 25-minute process to finish (or crash ).
Cheers,
Stefan