One of the basic challenges in this project was to find an efficient way to split hundreds of thousands of polygons (census blocks) using a separate, and rather large layer of line geometry – in this case, statewide commercial street data.  Although I had the option to do this work with custom code in Oracle Spatial, I wanted to use Geomedia in order to avoid the Oracle customization time sink.  How to do it in Geomedia?  The solution is easy, but not at all obvious (at least to me).  Here is the recipe I came up with:

1. Load the feature class that you want to split (in my case, census blocks), and the features that you want to split by (in my case, streets). Also, and this is important, make sure that the “Display Properties Dialog for New Features” button is unpressed.

2. Select the census blocks and initiate the split tool in Geomedia.  Notice that a new toolbar appears with four buttons on it… split by point, split by line, split by polygon, and split by selected features.  Click on “split by selected features”.

3. Turn OFF locatability on the census blocks layer (the layer to be split).  Be sure to do this without unselecting those features.

4. Turn on locatability for the streets layer, and select the features that you want to use as a basis for splitting census blocks.

5. Double-click somewhere – anywhere – on the map window and let Geomedia do its thing.  Depending on the complexity of the features that it is analyzing and the sheer number of records, it may take a little time to complete.  If you didnt take my advice from step one and ignored the “Display Properties Dialog for New Features” button, then it might force you to click OK for every newly split feature.

The result in my case is census blocks seemlessly split based on a seperate layer of line work.  Perfect geometry, perfect topology between features, with no slivers or gaps… a thing of beauty.

I must say that Oracle has done some impressive things with Oracle 11g and their support for LiDAR data, TIN exports, and overall 3D data storage. Additionally Safe Software has done some really cool things embracing Oracle 11g. At the Oracle Spatial User Conference, Safe demonstrated extracting 3D data from 11g, and transforming the data into a 3D PDF. Once in the PDF environment, you could pan, tilt, zoom, and fly around. It was really cool to be able to do a virtual flyover both around and into a building. You can see the demo on the Safe web site. Just look for the .wmv titled “FME and Oracle Spatial”.

Anyhow…I did have some time to sit down at the Intergraph booth and talk to a few people. I’ll cover some of the things I discussed in upcoming posts.

And finally, on a complete side note. I was really surprised at the size of the booth at the GITA conference. It was really great to see such a large presence at a conference. I’m used to seeing the one small table in the corner. Not this time…. Very cool.

On the software side, I purchased the following:

1. GeoMedia WebMap (finally)
2. Oracle Spatial upgrade
3. MapText Label-Web
4. MapText Label-EZ
5. MapText Label-Edit

I’ve spent time on #1 and #2 before on my blog, but don’t think I’ve ever touched on the MapText products. So, over the next couple of days I’m going to spend some time on both products. Needless to say, if you haven’t heard of the company or its products, I HIGHLY encourage you to take a look at their web site and a few of their samples. To put it simply, MapText produces the best software on the market (without a doubt) for the labeling of maps – both on the web (via Label-Web and GeoMedia WebMap) or on paper (via Label-EZ and Label-Edit).

Tomorrow I’ll go over Label-Web and then I’ll touch on Label-EZ and Label-Edit next week.

Until then…

11g released too late to be certified but I have been testing with the 6.1 beta for a few months. Oracle broke the ANYINTERACT spatial operator in the released version of 11g but they did fix some spatial filter problems.

So, although 6.1 will NOT be certified against 11g, it has, and will continue to be tested against 11g. I would have to guess that an upcoming 6.1 hotfix will actually be certified against 11g.

For those that are unaware, one of the biggest additions to 11g was the native support for text in the Oracle database. What does this mean? Basically, if you store your text as an Oracle text object (not sure of the proper terminology), you should be able to see that text in ANY client that will read the standard Oracle text object. GREAT for those multi-GIS/CADD client agencies that need to look at GIS data in multiple applications like Bentley Microstation and Intergraph GeoMedia.

Unfortunately, 6.1 is not taking advantage of this new functionality. However, I’m hoping that we’ll see the support for Oracle native text before the release of 6.2.

On a side note, Intergraph did recently release an expansion pack to support Oracle’s GeoRaster datatype. For those that aren’t aware, with the release of Oracle 10g, you can now store imagery (think orthophotos) in the database. Very cool if you have the storage space and Oracle Spatial. The expansion pack can be downloaded from the Intergraph web site (requires a login).

For those that aren’t aware, SQL tuning is basically the idea of writing your SQL queries in ways that will run most efficienty in the database. So in other words, look at the following two SQL queries – both will return the same results but are written in different ways:

SELECT cust_city, avg(cust_credit_limit)
FROM customers
WHERE cust_city = ‘Paris’
GROUP BY cust_city

vs

SELECT cust_city, avg(cust_credit_limit)
FROM customers
GROUP BY cust_city
having cust_city = ‘Paris’

In the two queries the WHERE clause will be evaluated before the HAVING clause. Therefore, by using WHERE as opposed to HAVING, you’re able to reduce the number of records returned faster in Query A as opposed to Query B. As a whole, this can be VERY important – especially when dealing with hundreds of thousands of records.

Anyhow, as a whole, the class covered A LOT of information and really went back into the core of Oracle and how it operates for many things. Very interesting (I think)…but also very detailed. However, if I had to outline what I learned in a single thought, it would be the following:

"Oracle 10g wants to use the cost-based optimizer. So, it’s going to do it; and most often the cost-based optimizer is correct. So, the idea of including 8i and 9i SQL hints for the most part has been elimianted. In fact, unless the complete query is written using hints, Oracle will simply IGNORE the hints you put into an SQL query."

This was very good for me to understand as I was constantly playing with SQL hints trying (for the most part unsuccessfuly) to get my SQL queries to run faster.

All in all, I did find the class to be very useful and really helped me answer a number of questions I’ve had over the years. I’m looking to test some of the Oracle SQL tuning tools against a spatial query in the near future…. Should be interesting to see how much faster I can make it.

This comes up whenever you open/close a connection or open a geoworkspace. Personally, even though the MGE connection to an Oracle database is read-only, I think this is a valuable option. On a side note, on some machines you can save the user name and password into the ODBC DNS setup and this will eliminate the need for entering a password at this dialog. This can be done my just embedding the password with the user name like this:

user/password

Anyhow, I’ve always been surprised that Intergraph doesn’t force something similar for an Oracle Object Model connection…ESPECIALLY since this connection can be read/write! For those that don’t use Oracle with GeoMedia, by default GeoMedia will save the password (hidden) in the .gws. As a result, whenever you load the .gws, GeoMedia will connect to the Oracle database with the user name and password saved in the .gws. Yes, this is convenient. However, it’s not ideal from a security standpoint. Especially if you actually use unique logins in Oracle where User A may only have read/write to TABLE A while User B may have read-only to TABLE A. To be honest, even from a non-security standpoint, it’s still a bad idea. It’s fairly easy to make a mistake when you’re not paying attention or not expecting to be able to do something to the data.

So, there is a workaround to force a similar type of login restriction. This can be found in the "Working with GeoMedia Professional" PDF in Appendix B, page B-2. However I’ll post it here as well:

By default, GeoMedia stores the Oracle connection password in the GeoWorkspace. This is meant as a convenience and allows users to open existing GeoWorkspaces containing Oracle connections without having to re-enter connection passwords. However, this is a drawback to those users wanting higher levels of security. The option to turn off password persistence is in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\GDO\Oracle Object Read-Only\1.0\Store Password
HKEY_LOCAL_MACHINE\SOFTWARE\GDO\Oracle Object Read-Write\1.0\Store Password
The default setting is 1, which means that connection passwords will be stored. To force the user to enter a password for each Oracle connection, change the (default) setting to 0.
Password persistence is not an issue if you are using Windows Domain authentication for your connections.

When you set these registry entries, you get the following dialog when you open a .gws, or close/open the connection:

You notice that it just sets the password to a single asterisk. Usability-wise, it’s not as easy as the MGE dialog, but it’s not bad.

It’s interesting to note that you have the option to not save the password for the Oracle Object Model Read-Only data server, the Oracle Object Model Read-Write data server, or both. I would heavily recommend setting it for read-write. If you’re not concerned with other people having read-only access to your data, you can keep GeoMedia saving the user’s password for read-only connections. Incidentally, this is what I prefer.

Now, since I’m not a big fan of editing the registry manually, I wrote a small executable using AutoIt – a FANTASTIC piece of freeware that allows you to script many different mundane Windows tasks and save the scripts off as standalone executables. I’ve uploaded my registry modification script (both source and executable). You can download it from the left hand side of the screen or from here. The script will force the login screen for read-write connections but will store read-only connections. You can modify the source quite easily (just reference my comments in the script) if you’d like to force the login screen both both read-write and also read-only.

To get GeoMedia to log everything it does with the Oracle database, do the following:

1. Close your connection to the Oracle database (or quit GeoMedia)
2. Create a file named “GOracle.log” in c:\temp (minus the quotes)
   NOTE – The file MUST be in c:\temp and MUST have the correct file name
3. Open the Oracle connection (or restart GeoMedia and connect to your Oracle database)
4. Start interacting with the Oracle database

You’ll notice that from that point forward EVERYTHING you do to the Oracle database is very verbosely logged. You can then go into the log file and review it for errors. Most of the time the error is easy to find and you can pull the information from the log to feed to Google or Intergraph support.

A couple of notes:

1. The log file can get very big, very fast. In fact, after only a few minutes of logging, I’ve seen the file grow to well over 10mb in size! So, make sure to move the file from the c:\temp folder or delete it altogether. If you don’t, any interaction you have in GeoMedia with the Oracle database WILL be logged. This could obviously cause a space issue on your hard drive after a while.
2. If you’re looking to write your own Oracle Locator/Spatial spatial query, this logging functionality can be an excellent first step. You can create the log file and then run a native query (Analysis > Native Query) inside of GeoMedia. For those that haven’t used the Native Query command, it’s basically a GUI for the Oracle Locator operators.
   So, I created a native query asking Oracle (as opposed to the spatial query operators inside of GeoMedia) to identify all of the stations that fall within a pressure zone named “Cox Zone”. Since this was an Oracle query, GeoMedia created the query, but logged all of the interaction between GeoMedia and the database. Copying directly from the log:

   select a.ROWID,a.GDO_GEOMETRY from SJWC_MIG.PRESSURE_ZONE b,SJWC_MIG.STATION a where PRESSURE_ZONE_NAME = ‘Cox Zone’ and mdsys.sdo_relate(a.GDO_GEOMETRY,b.GDO_GEOMETRY,’mask=ANYINTERACT querytype=window’) = ‘TRUE’

   All in all, I find this logging tool to be extremely useful. Especially when you’re working with a data model as opposed to a bunch of independent tables in a schema. It helps you understand just what GeoMedia is doing and why Oracle doesn’t like it. You can download my log from this session using this link or the link to the left. Although it’s boring, it might help add some context to this entry. You will also see the spatial query embedded in the log on a few different occasions.

He goes over licensing, what’s covered in both products, and even some great workarounds if you only have Oracle Locator but need Oracle Spatial functionality. He’s even got a number of code examples to help you implement these Oracle Spatial types of functions with ONLY Oracle Locator.

Finally, much like the free Oracle Object Model scripts and packages available on the Intergraph web site, Simon has his own free packages and code available for download on his site. I haven’t had a need for any of them yet, but definitely nice to know they’re available.