[udig-devel] Datastores, Features, and IGeoresources, oh my....

[Jody Garnett]

Dave S-B wrote:
> I'm afraid I've got lost in the maze of IGeoResources, Datastores, 
> Feature collections, IServices etc. etc. and I could do with some 
> pointers on the way out!
Let me try for a cheat sheet:

Representing the Database we have:
- IService is a "pointer" to a database, From this pointer you can ask 
for *anything you want*, a raw jdbc Connection, a DataStore for asking 
questions about the database etc.... you can ask for the members() which 
is a List<IGeoResource> representing the tables
- DataStore is the GeoTools data access api for interacting with the 
"entire" Database

Representing a Table we have:
- IGeoResource is a "pointer" to a table. From this pointer you can ask 
for *anything you want*, a raw jdbc Connection, a FeatureSource for 
reading features, A FeatureStore for writing features etc....
- FeatureSource is an geotools data access api for reading from a table 
containing Features
- FeatureStore is an geotools data access api for writing to a table 
containing Features
- FeatureCollection represents a Collection<Feature>, it is what you get 
back when you ask for a Features (think of it like a jdbc ResultSet)

> Here's my predicament - I have a database which contains all manner of 
> data relating to oil wells. I already have an analysis facility 
> whereby the user can choose from a selection of many analyses, pick 
> parameters (such as well operators, oil fields, drilling dates, etc.) 
> and then get results based on their options. All the querying is done 
> through JPA using Hibernate and the very useful HibernateSpatial, so 
> what I'm getting from each analysis is a List<Object[]> where one of 
> the items in the Object array is a JTS Geometry.
Sweet; I have had some contact with Hibernae / JPox etc... OR mapping 
plus Geometry :-)

Best practice: teach uDig about your use of Hibernate (using a and allow 
your IService to resolve to your DAO) - this is what 
IResolveAdapterFactory is for. Actually *exactly* what is for, we added 
this code when I was making a uDig / Hibernate client.
> I need to add a new layer to a map containing this data. I'd accept 
> just being able to do it temporarily for now, but I'd like it to be 
> persisted somehow (so the layer can recreate itself after closing down 
> and restarting) - my Analysis object stores the user's options as a 
> Map. I looked at the CreateTemporaryLayer example, but then got lost 
> in creating a FeatureCollection!
I see. Thinking....

Option 1: Make a renderer that knows about your objects (if you are just 
using uDig as a front end for your POJO application this is a good / 
quick way to go).
Option 2: Use MemoryFeatureCollection, add you features into that and 
allow it to take care of the rest ...

I don't think I know the CreateTemporaryLayer example ... do you have a 
link?
> I just need a way of thinking this through. At the moment, it seems to 
> me as if I have to create;
> - an Analysis DataStore, which wraps the existing Analysis object
> - an Analysis FeatureReader (used by the DataStore), which reads the 
> existing data and adapts it to Features
> - an IService which stores the user-defined parameters (including some 
> identifier to say which Analysis to run) and can create the DataStore 
> on the fly
> - an associated IGeoResource
> - a ServiceExtension so uDig can recreate the service
I see:
- Yes - you can make all of that. By making a DataStore by hand you can 
make use of the existing renderer (and all the nice style support it 
has). If you do this please consider making use of AbstractDataStore as 
your super class (you will then only need to make a FeatureReader, the 
FeatureCollection part will be done for you). An old tutorial is here: 
http://docs.codehaus.org/display/GEOTDOC/DataStore+Developers+Guide
- Alternative: depending on your database you may be able to let uDig 
talk to the database directly (and render what it finds), the downside 
is it would not make use of the hibernate cache. Note the use of 
hibernate is a bit troublesome for rendering as it takes all the 
attributes over (even if the renderer only uses the Geometry). You can 
then use IResolveAdapterFactory to make you DAO available to Views and 
Operations that care ...
> Then, after the user picks their parameters I create a new 
> AnalysisService (passing in the parameters as a Map). The 
> AnalysisService is in charge of creating and running the Analysis. 
> Then I can get the IGeoResource and use ApplicationGIS.addLayersToMap. 
> Are the IService/IGeoResource details are persisted with the Layer? 
> i.e. will the user-defined parameters get persisted somewhere if I 
> include them in the IService.getConnectionParams()?
The IService / IGeoResoruce details are stored in two places:
- in the catalog (for use with other maps)
- in the Map/Layer so you can load up the Map in another project or 
other machine
> So that brings me on to URLs. Given that the user can create any 
> number of analyses, do I need to make the URLs for the IService and 
> IGeoResource unique in some way? Or is it enough that the connection 
> parameters are different? If only the parameters need to be different 
> then the URL could be something like "myApp:/analysis#results" - but I 
> suspect the different analyses would interfere with each other 
> somewhere. So would I need to have URLs like 
> "myApp:/analysis/PoolSizeDistribution/1#results","myApp:/analysis/PoolSizeDistribution/2#results" 
> etc.?
They need to be unique.

It should be pointed out that these IGeoResources are representing 
"saved" queries or a view. You may consider making use of that fact:
- storing those "query" parameters on the Style Blackboard (it is persisted)
- making a single IGeoResource that represents all of your oil wells 
(using your own API no need for DataStore)
- Look at LayerResource.Wrapper and use your query parameters to make a 
FeatureSource right then and there.
- The renderer will be able to ask the Layer for a FeatureSource, the 
wrapper will engage and produce one based on the query parameters, and 
eveything will work as normal....
> Sorry to be asking so many questions, but I've been playing with this 
> for a couple of days now without success and I need a bit of a sanity 
> check before I dive into creating all the above stuff! If anyone knows 
> of a method which involves less code, I'd be glad to hear it!! ;)
Cheers,
Jody