Chris Holmes wrote:
Jody Garnett wrote:
anna zanetti wrote:
Good evening,
I am starting to use GeoServer 1.3.2 that works over an Oracle 10g database, with a 1.5.0_02 JVM. I am able to connect GeoServer to db, create Features Type, and use the sample request on them. My problem is that the Map Preview does not work with my features. I have my feature in the list for the preview but when I go to the map page anything does not appear. The system continues loading data from localhost but nothing appears, even if I wait for a long time.
One extreme thing you can try is to see if it works in uDig? Oracle support is available as a community plug-in, and the developers there are responsive to bugs...
The reason I recommend this is that is likely that you are victim of:
- an SLD style not configured to work against "Geometry", a problem uDig has solved
- geotools data store not being set up to query the SDO_GEOM_METADATA correctly, uDig makes use of a subclass that is more capable (we were unable to smoothly offer these fixes back to the community due to communication)
When did this communication mishap happen? If I can help get back it back in let me know.
The subclasses of the datastores used in uDig are due to two requirements...
- need to use the database connection (so the requests can be made for the for the GeoResourceInfo objects)
- need to support a
As for timing it after the uDig 1.0 release, we could not figure out a way to allow Database DataStores to specificly optimize bounds requests smoothly.
Justin did a bunch of optimizations for PostGIS (ranging from version specific hacks, to a full table scan), and I got some for Oracle.
I did eventually create a method in JDBCDataStore that the PostGIS datastore has now used to "rescue" the code from uDig, the implementation for OracleDataStore is incomplete currently ... there were more ways to say "horizontal" and "verticle" with oracle metadata then I knew at the time.
Now that Justin has back ported the various info classes we have a chance to handle things a bit better...
Finally I *know* that code in geotools is not handling all the GEOM_METADATA correctly, but I now have access to a book and could do a better job, it is just mucking with setting up Oracle that I do not enjoy.
We've got an oracle instance on geo that I could give you access to Jody. It looks like you already have an account on the box?
Really, I will have to ask Justin about that sometime - thanks a lot I dread setting up Oracle. Unless this issue starts killing someone (and Marc tags me for help), I got my hands full with IP checks right now...
Looking at the status of the Oracle module is helpful:
- http://docs.codehaus.org/display/GEOTOOLS/Module+Matrix (two stars, not very mature)
- http://docs.codehaus.org/display/GEOTOOLS/Oracle (have a look through the known issues, the very first one is a blocker about table scan prevention, blocker implys the code is so broken it should not be released!)
Should that really be a blocker? GeoServer users have been using it fine for awhile. I understand that full table scans are more of an issue for uDig, but that to me would imply that it should be a blocker in uDig jira, linked to a critical in GeoTools jira.
As keeper of the DataStore API, I really want these things to work as advertised. If you check the "gold start" for quality chart on geotools there is one star for working with GeoServer (where metadata can be overridden), and an additional start for working "out of the box" as required by uDig. The more DataStores that work out of the box the easier the library will be to use ...
Given that a request for extent is needed for any use of the GeoTools rendering system I figure it is a reasonable blocker. But perhaps the issue should be moved to the rendering system? It does seem like a reasonable thing for a source of data to know....
Jody