SDO_UTIL.SIMPLIFY - 101 Uses (almost)

Question

SDO_UTIL.SIMPLIFY
“Simplifies the input geometry, based on a threshold value, using the Douglas-Peucker algorithm.”
This is an understated description if there is one. This function can do much more for you than just simplify the geometry, it will also convert arcs to line stings, eliminate duplicate verticies, and correct many overlapping edge polygon problems.
I “discovered” this additional functionality while trying to get a process down to import reference ESRI shapefile data (GeoBase CIP's) stored in state-plane format into OS (Oracle Spatial) using Lat/Long. Most of the problems I encountered were due to overlapping polygon edges, duplicate verticies, and arcs in line strings. At first, I discreetly defused these issues by finding the errors (with code) and then fixing them based on the returned error codes. This was painfully slow and a real pain to code.
Then I took a look at the incoming data, and determined that many times, the drafters (possibly from a CAD to GIS conversion) really went overboard and included many times more points than necessary for the accuracy I was interested in for the reference data. I looked at several of the simplify options and since I wanted to simplify the data in-place using an update statement, I choose this one. Then once, I ran the simplify command out of order by accident (before the arc/duplicate/overlap routine). Not only did it simply the data, it also “fixed” all the other problems as well!
So – note to Oracle staff – great job! You might want to update the documentation to mention all the things it does while simplifying the data, as this is VERY useful for migrating troublesome data. However, I noticed that it can overtake all the memory (and take forever to run) on your database box if you make the mistake of specifying the same values for threshold and tolerance. The docs do state that the tolerance “Must not be greater than threshold.”, but I'd add that they also should not be the same.
As always, YMMV...
Bryan

Answer 1

tdsacilowski wrote:
All together there are about 20 machines that display a page that has one of the above 5 second refreshes. The application is also public; there is no authentication. From my understanding about how APEX handles sessions there is a max session length (8 hours in my case) even for public sessions. As a page is rendered, a hidden form variable is created called p_instance and the AJAX calls send this to the server to process the request within the active session. In theory, the application shouldn't be generating a lot of new sessions since once a page is loaded it is used simple to display an updating value. In other words, there's no user interaction. No page reloads, no new items being set in session state.
no interaction, 24/7 uptime, refreshing every 5s, and it is all public.....
I'd almost look at a slightly different architecture.
option one:
have a basic, static web page that calls an APEX REST service.
This html file and any neccessary css, js files will reside on the same webserver as the APEX listener, but in a different WAR file.
option two:
make a simple java swing app using JDBC to connect directly to the database.
use Oracle Wallet technology so you don't have to hardcode the name/password in plain text.
have the DBA create an account with very limited access and a profile to guarantee it will never suck-up DB resources.
*** IIRC -- the OCI version includes the capability of triggering an event (in Java) when a table gets update. ****
APEX is a very good tool.
But, for your case, it sounds like it is overkill for your requirements.
MK