We currently use GeoNetwork as a component in our project, GeoNode. We are at a stage of planning out next phases of development, and we anticipate putting more demands on our catalog implementation.
At the same time, we’ve heard a rumor that a new “GeoNetwork 3.0” implementation is being planned, and that much of the community will move to support it. Is this rumor true?
This is a list of features which we will need for our catalog implementation in the near future. Are any of them on the current GeoNetwork roadmap? On the GeoNetwork 3.0 roadmap?
Sub-element metadata updates (like in add/remove specific elements
from a given metadata record without the client having to get the full record, reconstruct it and send it back as a full record update)
XPath queries
(Ideally, we’d be interested in a BerkeleyDB XML backend, or the like, for these two features)
Insert a record in FGDC format and retrieve it in 19139 or a 19139 based profile. Or rather send an insert record in FGDC and get it inserted as 19139/profile. But through the standard service interface, maybe with some legacy parameter, not through a legacy geonetwork service.
Support for Basic Auth
An HTTP API for configuring the security of metadata records.
OpenGeo will likely be able to contribute to the implementation of these features, either in code or financially, if they have community support.
This is a list of features which we will need for our catalog implementation in the near future. Are any of them on the current GeoNetwork roadmap? On the GeoNetwork 3.0 roadmap?
...
- Insert a record in FGDC format and retrieve it in 19139 or a 19139 based profile. Or rather send an insert record in FGDC and get it inserted as 19139/profile. But through the standard service interface, maybe with some legacy parameter, not through a legacy geonetwork service.
We have implemented this capability in the GEOSS "Clearinghouse" catalog - conversion of FGDC to ISO on ingest from remote harvest - via stylesheet. This capability can be shared with the group.
I'd be interested in this capability as well!
steve
On 11/8/2010 1:18 PM, Douglas Nebert wrote:
.....
We have implemented this capability in the GEOSS "Clearinghouse" catalog
- conversion of FGDC to ISO on ingest from remote harvest - via
stylesheet. This capability can be shared with the group.
Doug
--
Stephen M. Richard
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701
USA
phone: 520 209-4127
AZGS Main: (520) 770-3500. FAX: (520) 770-3505
email: steve.richard@anonymised.com
Actually the ability to accept an xslt for transforming harvested metadata is already present for all harvesters (it was added to trunk during 2.5 - see this proposal HarvestingEnhancements – GeoNetwork opensource Developer website) - some harvesters can already use it (eg. Z3950, Local file system), for others the xslt harvester parameter is hidden and some coding will be req'd, usually because it wasn't immediately clear how/whether it would fit into their work flow.
Cheers,
Simon
________________________________________
From: Douglas Nebert [ddnebert@anonymised.com]
Sent: Tuesday, 9 November 2010 7:18 AM
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] GeoNetwork 3.0? Roadmap items? GeoNode?
On 11/8/10 2:22 PM, Sebastian Benthall wrote:
This is a list of features which we will need for our catalog
implementation in the near future. Are any of them on the current
GeoNetwork roadmap? On the GeoNetwork 3.0 roadmap?
...
- Insert a record in FGDC format and retrieve it in 19139 or a
19139 based profile. Or rather send an insert record in FGDC and get
it inserted as 19139/profile. But through the standard service
interface, maybe with some legacy parameter, not through a legacy
geonetwork service.
We have implemented this capability in the GEOSS "Clearinghouse" catalog
- conversion of FGDC to ISO on ingest from remote harvest - via
stylesheet. This capability can be shared with the group.
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
2010/11/8 Sebastian Benthall <seb@anonymised.com>:
Hi,
We currently use GeoNetwork as a component in our project, GeoNode. We are
at a stage of planning out next phases of development, and we anticipate
putting more demands on our catalog implementation.
At the same time, we've heard a rumor that a new "GeoNetwork 3.0"
implementation is being planned, and that much of the community will move to
support it. Is this rumor true?
This is a list of features which we will need for our catalog implementation
in the near future. Are any of them on the current GeoNetwork roadmap? On
the GeoNetwork 3.0 roadmap?
I think best information about future releases is on the proposal page [1].
- Sub-element metadata updates (like in add/remove specific elements
from a given metadata record without the client having to get the full
record, reconstruct it and send it back as a full record update)
Discussion about metadata updates which may be of interest [2].
- XPath queries
(Ideally, we'd be interested in a BerkeleyDB XML backend, or the like, for
these two features)
Maybe eXist is a good option too http://exist-db.org/ (having Lucene and some spatial features in).
Another option could be to use XML data type in relational DB like
Postgres, It's probably less work but also basic XQuery support ?
- Insert a record in FGDC format and retrieve it in 19139 or a 19139 based
profile. Or rather send an insert record in FGDC and get it inserted as
19139/profile. But through the standard service interface, maybe with some
legacy parameter, not through a legacy geonetwork service.
- Support for Basic Auth
- An HTTP API for configuring the security of metadata records.
There is a simple metadata.admin service [3].
OpenGeo will likely be able to contribute to the implementation of these
features, either in code or financially, if they have community support.
Cheers,
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi,
We currently use GeoNetwork as a component in our project, GeoNode. We are
at a stage of planning out next phases of development, and we anticipate
putting more demands on our catalog implementation.
At the same time, we’ve heard a rumor that a new “GeoNetwork 3.0”
implementation is being planned, and that much of the community will move to
support it. Is this rumor true?
This is a list of features which we will need for our catalog implementation
in the near future. Are any of them on the current GeoNetwork roadmap? On
the GeoNetwork 3.0 roadmap?
I think best information about future releases is on the proposal page [1].
Sub-element metadata updates (like in add/remove specific elements
from a given metadata record without the client having to get the full
record, reconstruct it and send it back as a full record update)
Discussion about metadata updates which may be of interest [2].
XPath queries
(Ideally, we’d be interested in a BerkeleyDB XML backend, or the like, for
these two features)
Maybe eXist is a good option too http://exist-db.org/ (having Lucene and some spatial features in).
Another option could be to use XML data type in relational DB like
Postgres, It’s probably less work but also basic XQuery support ?
Insert a record in FGDC format and retrieve it in 19139 or a 19139 based
profile. Or rather send an insert record in FGDC and get it inserted as
19139/profile. But through the standard service interface, maybe with some
legacy parameter, not through a legacy geonetwork service.
Support for Basic Auth
An HTTP API for configuring the security of metadata records.
There is a simple metadata.admin service [3].
OpenGeo will likely be able to contribute to the implementation of these
features, either in code or financially, if they have community support.
Cheers,
The Next 800 Companies to Lead America’s Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book “Blueprint to a
Billion” shares his insights and actions to help propel your
business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev