This isn't a complete answer by any means, but what we're building at the University of Virginia Library is:
Discovery through Geonetwork with additional services developed in-house, on top of OGC services for data access through Geoserver (proxied by Apache httpd for access control and some URL-mapping for convenience) with vector datasets stored in PostGIS and raster datasets stored in GeoTIFFs on high-speed file storage. We haven't yet dealt with caching issues. Services will be consumed by a host of different tools, including ESRI desktop software, other desktop software, and a cornucopia of webapps.
We are about to start using Geonetwork's LDAP connection to control who discovers what and who edits what metadata, and an independent connection to the same LDAP server from Apache httpd to control who gets access to what. This is a good ploy for us because the University maintains an LDAP server covering the entire University community, which we can use. As an educational/research institution, we have a mix of licensed resources and in-house resources (many the product of local researchers) and we have to provide a flexible access-control model. We think LDAP will do that for us for now. We'd like to move that Apache httpd - LDAP connection into Geoserver, but I haven't looked at what the Geoserver developers' plans are for using Acegi (the Spring access-control framework) on a per-feature-type or per-layer basis. It doesn't seem that OGC services lend themselves to that very obviously.
Additional wrinkles will be introduced as we scale beyond our first few TBs of GeoTIFFs served from files through Geoserver to where we'd like to be, which is JPEG2000/JPIP. We're not there yet because we haven't seen open-source JPIP software that's production-ready, and we're still trying to figure out what JPIP would mean for OGC services and the client-side (including access-control). We're fairly confident in the ability of PostGIS to scale well, especially with clustering engaged, and we've got some fairly big iron in place to run our production instance. However, we're ready to look at Oracle Spatial if we need to. We'd like to keep the OGC services in J2EE (using Geoserver) because we're comfortable with it and we know we can scale it.
I've done some experimental work building Fedora (not the Linux build, the digital object repo infrastructure) objects that encapsulate OGC services, and that worked fairly well, but we haven't had the impetus to pursue that very far. We're very much a Fedora shop (we were one of the institutions that built Fedora) so I can't speak to other digital object repo software. Since Fedora uses XACML for fine-grained access control within objects, that could be a very flexible solution. GeoXACML is another technology that might be put into play here, but I'm not clear on how well-developed it is or how soon we might see support and tools come into the market. I'm also not sure how easy it would be to roll our own GeoXACML extensions for Fedora.
Feel free to contact me off-list if you want to trade notes and experiences.
---
A. Soroka / Digital Research & Scholarship Dep't : Digital Scholarship R&D
the University of Virginia Library
On May 8, 2008, at 5:08 PM, Brian Bishop wrote:
This is not strictly a Geonetwork question, however this issue may
affect others on the list.
Our Geonetwork catalogue links to datasets stored in a separate
repository consisting of a file system directory hierarchy organised by
Nation > Location > Theme. A Geonetwork catalogue entry may link to a
dataset or a subdirectory within the repository. A separate directory
hierarchy stores datasets that have restricted access, however this
simple approach is not meeting our long term needs.
As our data search & rescue efforts continue, we need to provide a
multilevel access control method for restricting access to some
datasets. We could store the datasets within Geonetwork and take
advantage of the access control that is available, however we are
talking about 2TB of data and therefore I have assumed that separating
the repository from the catalogue is the best approach.
Possible solutions include an ftp server or a digital library like
greenstone.org, that can be integrated with Geonetwork.
Has anybody faced similar issues and how have they solved them?
Cheers
Brian
-------------------------------------------------------------------------------------
Brian Bishop
Coordinator Ocean Information Systems
Ocean and Islands Programme
SOPAC PACIFIC ISLANDS APPLIED GEOSCIENCE COMMISSION
Postal Address: Private Mail Bag, GPO, Suva, Fiji Islands
Street Address: 241 Mead Road, Suva, Fiji Islands
Tel: +679 338 1377
Fax: +679 337 0040
E-mail: brian@anonymised.com
Web site: http://geonetwork.sopac.org
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork