Found two issues at the demo instance: - the layers links point to localhost:8000, as in <http://localhost:8000/data/hazard:NICARAGUA_VIENTO_TR100_INT1> instead of <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1> - Once you get to <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1>, the metadata link returns the metadata document but enclosed on a GetRecodsByIdResponse (like in <http://geonode.capra.opengeo.org/geonetwork/srv/en/csw?service=CSW&OutputSchema=http://www.isotc211.org/2005/gmd&request=GetRecordById&version=2.0.2&ElementSetName=full&id=524bcf81-7d39-4879-a8a6-5ff346388dc9>. I think we should return the plain MD_Metadata element as the document's root instead. Otherwise whomever wants to use the metadata document will have to strip out the enclosing element by hand, which is odd. Now, how do we do that? well, geonetwork does it from the UI by using one of its legacy "xml services": <http://geonode.capra.opengeo.org/geonetwork/srv/en/iso19139.xml?id=14> but that implies knowledge of the internal record identifier it used for storage... which we do/should not not know. suggestions? Gabriel -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers.
On 05/18/2010 08:47 PM, Gabriel Roldan wrote: > Found two issues at the demo instance: > > - the layers links point to localhost:8000, as in > <http://localhost:8000/data/hazard:NICARAGUA_VIENTO_TR100_INT1> instead > of > <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1> > > Which links are these? What page are they showing up on? > - Once you get to > <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1>, > the metadata link returns the metadata document but enclosed on a > GetRecodsByIdResponse (like in > <http://geonode.capra.opengeo.org/geonetwork/srv/en/csw?service=CSW&OutputSchema=http://www.isotc211.org/2005/gmd&request=GetRecordById&version=2.0.2&ElementSetName=full&id=524bcf81-7d39-4879-a8a6-5ff346388dc9>. > I think we should return the plain MD_Metadata element as the document's > root instead. Otherwise whomever wants to use the metadata document will > have to strip out the enclosing element by hand, which is odd. > > Now, how do we do that? well, geonetwork does it from the UI by using > one of its legacy "xml services": > <http://geonode.capra.opengeo.org/geonetwork/srv/en/iso19139.xml?id=14> > but that implies knowledge of the internal record identifier it used for > storage... which we do/should not not know. > > suggestions? > > Gabriel I guess it wouldn't be too hard to put together a little Django endpoint that grabs a metadata record by uuid (or arbitrary CQL? maybe a bit too ambitious) and unwraps it. It would be nice to have this sort of thing in GeoNetwork though to save some RAM/CPU cycles on the server. Any idea how much work something like that would be? -- David Winslow OpenGeo - http://opengeo.org/
On 5/19/10 11:49 AM, David Winslow wrote: > On 05/18/2010 08:47 PM, Gabriel Roldan wrote: >> Found two issues at the demo instance: >> >> - the layers links point to localhost:8000, as in >> <http://localhost:8000/data/hazard:NICARAGUA_VIENTO_TR100_INT1> instead >> of >> <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1> >> >> > Which links are these? What page are they showing up on? sorry, terrible bug report, I know. The links in the map page, like in <http://geonode.capra.opengeo.org/maps/1>, under "This map uses the following layers" >> - Once you get to >> <http://geonode.capra.opengeo.org/data/hazard:NICARAGUA_VIENTO_TR100_INT1>, >> the metadata link returns the metadata document but enclosed on a >> GetRecodsByIdResponse (like in >> <http://geonode.capra.opengeo.org/geonetwork/srv/en/csw?service=CSW&OutputSchema=http://www.isotc211.org/2005/gmd&request=GetRecordById&version=2.0.2&ElementSetName=full&id=524bcf81-7d39-4879-a8a6-5ff346388dc9>. >> I think we should return the plain MD_Metadata element as the document's >> root instead. Otherwise whomever wants to use the metadata document will >> have to strip out the enclosing element by hand, which is odd. >> >> Now, how do we do that? well, geonetwork does it from the UI by using >> one of its legacy "xml services": >> <http://geonode.capra.opengeo.org/geonetwork/srv/en/iso19139.xml?id=14> >> but that implies knowledge of the internal record identifier it used for >> storage... which we do/should not not know. >> >> suggestions? >> >> Gabriel > > I guess it wouldn't be too hard to put together a little Django endpoint > that grabs a metadata record by uuid (or arbitrary CQL? maybe a bit too > ambitious) and unwraps it. It would be nice to have this sort of thing > in GeoNetwork though to save some RAM/CPU cycles on the server. Any > idea how much work something like that would be? We could create a GeoNetwork endpoint that does a lookup by UUID, but then again we would be diverging from the CSW interface, which so far was not _needed_ and I see as a good thing. On my flight back from Peru in a couple hours I'll investigate if something similar does not exist already though... :) > > -- > David Winslow > OpenGeo - http://opengeo.org/ -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers.