Sep 062009
 

Yesterday I installed JBoss 4.2.3 and deployed Geoserver 1.7.6 to it and installed the OracleNG plugin. Unfortunately, after setting up the Oracle datastore and some features, inserting via WFS-T still resulted in an empty geometry in the database.

SVN access to the OpenLayers trunk gives an error at the moment, so I guess I’ll have to do some further testing with the 2.0RC of Geoserver.

Aug 222009
 

I tried Geoserver with Oracle 11g, and still I get empty geometries inserted into the database. With Firebug I can see that the GML sent is correct, it contains the correct geometry information (in this case: point coordinates), but the receiving end fucks it up. Not sure whether the OracleNG plugin for Geoserver or Openlayers does the fucking up, but I suspect it is the plugin.

Aug 042009
 

Dear all,

I’ve been struggling with Geoserver and Oracle as a datastore. In a webpage that uses OpenLayers, I’m trying to use the WFS-T features. Don’t get me wrong, WFS works great. That is, the read-only part. WFS-T works great with shape files. WFS-T works great with PostGIS. But the same page, same WFS-server (my local Geoserver) with Oracle as a datastore just inserts empty geometry columns (NULL). When making the geometry column “NOT NULL” Geoserver and/or OpenLayers just inserts a point with 0.0,0.0 as coordinates. Which is NOT where I clicked on the map (0.0,0.0 isn’t even close to being visible on screen).

So, anyone got WFS-T with an Oracle datastore working? I’m using Geoserver 1.7.5 on Tomcat 6.0.something (latest as of now), OracleNG plugin, OpenLayers 2.8 (local, not the hosted version). With Firebug I can see that the GML being sent in the POST command is CORRECT, i.e. it shows the correct coordinates. Somewhere along the line these are discarded and NULL or 0,0 (depending on the column definition) is inserted.

Change to PostGIS (with almost the same table definition, that’s the beauty of PostgreSQL) and everything works like a charm. PostGIS + Geoserver + OpenLayers is a killer combination!

Let the comments pour in……

Oct 132007
 

If you try to install Oracle on Solaris 10 (x86-x64 version) and you run into the following error when you start the installer:

ld.so.1: java: fatal relocation error...

then you probably have your locale defined as “en_US.UTF-8”, the default. This is a bug in Java on Solaris. Workaround is to set it (temporary) to something else (e.g. en_US.ISO8859-15). This will not affect how you install the software, but only how the installer itself runs.

I ran into this on Solaris 10 Developer Edition 09/07 on AMD64, with Oracle 10g 64-bits for Solaris.

Oct 062007
 

Well, not all of it, but I have your attention now, do I? I intalled Oracle database 10g 64-bits edition on my Ubuntu AMD64 (Feisty). Works like a charm. You need to install a ton of packages, but after that, it works without a glitch.
To get Oracles HTTP server to work (not to be mistaken by the real application server, which is a completely different beast) one needs to install the companion CD. There is a companion CD in a 64 bits version for Linux. Yeah. Don’t you think that it contains a recompiled version of Apache, since it does not.The Apache server on the companion CD is the normal 32-bits version.
Oracle likes spending its money buying all sorts of companies, instead of supporting their customers and developers. Mind you, I’m trying to install the thing on Ubuntu, which is not supported by Oracle at all. But judging by the number of forum messages and blog posts about Oracle on 64-bits OS-es, I can only conclude Oracle doesn’t care about 64-bits at all.

Their 11g database is available for Linux now. The specs demand a very recent PC or server, but it’s only available as … a 32-bits version.

Why is that? Hardware manufacturers are pushing 64-bits systems like crazy, but the software (and OS-es) is way behind. Why? AMD64 has been around quite some time. Intel has a lot of 64-bits processors. What are they all waiting for?