Hi Torsten,
Thanks for the email, please feel free to ask all the question you would
like.
First off I should say that the catalog api is in state of flux. The
implementation in geotools is just a port of the one from udig. There
are issues with the api that require it to be partially redesigned,
however at the moment noone really has the mandate to do so.
However I think the catalog api might be part of what you are looking
for. However it seems your requirements go above and beyond, with the
need to be able to "push" data into the catalog from a central
"ingestion site". To this date the api has mostly been used on the
client side to "pull" data into it.
One thing in GeoServer we are currently looking at doing is coming up
with an api for "remote management". That fits right into your use case
as the ingestion service would have a GeoServer api to call, and let it
know that it should serve up some new kind of data.
As for OSGi, a while back i as prototyping the geotools catalog, and
indeed created OSGi bundles for the different modules. It worked quite well.
-Justin
thegis wrote:
> 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 !DSPAM:1004,45dc458640129771116852!
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
> !DSPAM:1004,45dc458640129771116852!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Geotools-gt2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
> !DSPAM:1004,45dc458640129771116852!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
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
