Hi all!
I am new to geotools and consider using it for the next project. Sorry for
the long post and lots of questions, but I wonder if, and if yes, how I can
make use of geotools (especially the new catalog api) to cover my use case.
The use case shouldn't be that uncommon, so udig/geoserver might had, have
or will have similar problems. Maybe someone can point my in the right
direction?
Well, what we want is some sort of "server-side, enterprise ingestion
service for spatial data". Here is the use case: Our enterprise
infrastructure consists of several web services that provides access to
features, coverages, metadata and observations through ogc interfaces. The
service implementations are heterogenous, just for fun lets say we have a
Geoserver WCS, MapServer WFS, Geonetwork CSW and a 52n SOS. The "ingestion
service" should read spatial datasets from different sources (files, db,
w*s), (process some of them), store them in different datastores
(filesystem, db), register them in specific service implementations to make
them available through w*s and finally set the permission on a service
proxy. All this must be logged and each ingested datasets must be registered
persistantly in the "ingestion service catalog", which holds of course not
the prim data or collection metadata but rather internal metadata ( e.g.
what kind of data is registered, where is it stored, which service provides
access to it, when was it added, etc.). That's required in order to
remove/update the datasets gracefully... ;-)
This use case overlaps significantly with udig and geoserver functionality (
e.g. import/export to/from datastores, cataloguing and registering of
datastores). Unfortunately, our service should run in a headless environment
so the uDig plugins will not work (or does they?). We cannot use geoserver
as its scope is different (gs is not an enterprise infrastructure, but a
part of it) and we have too special requirements for a generic w*s
implementation. On the other hand there is at some point a need for an admin
interface to change configuration (trigger, cache size, etc.), lists catalog
entry, manually ingest data, etc. So uDig as a platform would already
provide interesting features...
Now, the question is how far can we abstract the ingestion from the concrete
service implementation and is the new catalog api of any use in that regard?
And how does DataStore/GeoResource/Service relate to each other?
Well, I probably didn't understand it completly right, but one solution I
see is to use the catalog api to represent/model the enterprise
infrastructure with its services, datastores and georesources:
Catalog_1..n_CoverageService (extends interface Service) //similar:
FeatureService, MetadataService, ...
CoverageService_1..n_CoverageStores (extends interface DataStore) //e.g.
dirA: /var/rep1, dirB: /var/cache/rep2
CoverageStore_1..n_CoverageResource (extends interface GeoResource) //
n90e90.tif, ...
I think all this can be done quite abstract. If I understand it right, we
can add CoverageResources (eg a few geotiff tiles) to a CoverageStore (eg a
directory), an event (ResolveChangeEvent) is fired and the specific
CoverageService is responsible for registering the geotiff files. Now we
need to have an specific implementation that handles the real registration,
e.g.
GeoserverImpl /*MapserverImpl, etc.*/ implements CoverageService,
FeatureService {
registerCoverage(CoverageResource cr);
...
registerFeature(FeatureResource fr);
}
With that, the service implementation declares what kind of data it is able
to provide and the "last mile" can be implemented in regard to the specific
instance and can use a specific java api, ant, scripts or whatever to do the
registration. This is where osgi could come in handy. A GeoserverBundle
could implement and provide a CoverageService, FeatureService, etc. Once
loaded in an osgi runtime, it would be available to the Catalog. It would
even allow you to have two versioned ( e.g. 1.4, 1.5) and configured (e.g.
hostA:path and hostB:path b) geoserver bundles loaded into an osgi runtime
providing access to different geoserver instances (ok, thats kind of silly,
but hey why not;-). Of course the application or user has now to choose one
of them, but that's cool!
So, do you think this is feasible or just plain stupid? Is there a better
solution to this use case? Am I missing something? Or is geotools even
heading in this or a similar direction? Regarding the persistance, what
about using JPOX on the catalog/service objects? Will gt provide modules as
osgi-bundles ( e.g. a gt-catalog-bundle) in the future? Of course there are
other issues (e.g. security/permissions and versioning) but this is for
another thread...
Thanks for feedback and comments,
Torsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
