{"id":477,"date":"2010-05-07T21:34:28","date_gmt":"2010-05-08T01:34:28","guid":{"rendered":"http:\/\/www.kralidis.ca\/blog\/?p=477"},"modified":"2010-05-07T22:00:49","modified_gmt":"2010-05-08T02:00:49","slug":"owslib-csw-updates-and-implementation-thoughts","status":"publish","type":"post","link":"https:\/\/www.kralidis.ca\/blog\/2010\/05\/07\/owslib-csw-updates-and-implementation-thoughts\/","title":{"rendered":"OWSLib CSW Updates and Implementation Thoughts"},"content":{"rendered":"

I’ve had some time to work on CSW support in OWSLib<\/a> in the last few days.\u00a0 Some thoughts and updates:<\/p>\n

FGDC Support Added<\/h3>\n

Some CSW endpoints out there serve up GetRecords responses in FGDC CSDGM<\/a> format.\u00a0 This has now been added<\/a> to trunk<\/a> (mandatory elements + eainfo).\u00a0 Note that csw:Record (DMCI + ows:BoundingBox) and ISO 19139 are already supported.\u00a0 One tricky bit here is that FGDC was\/is mostly implemented without a namespace, which CSW requires as an outputSchema parameter value.\u00a0 I’ve used http:\/\/www.fgdc.gov for now.<\/p>\n

Both FGDC and ISO (moreso ISO) have deep and complex content models, so if there are elements that you don’t see supported in OWSLib, please file an feature request ticket in trac, and I’ll make sure to implement (and add to the doctests).<\/p>\n

Metadata Identifiers are Important!<\/h3>\n

When parsing GetRecords requests, we store records in a Python dict, using \/gmd:MD_Metadata\/gmd:fileIdentifier (for ISO), \/csw:Record\/dc:identifier (for CSW’s baseline) or \/metadata\/idinfo\/datasetid (for FGDC).\u00a0 Some responses return metadata without these ids for whatever reason.\u00a0 This sets the dict key to Python’s None type, which ends up overwriting the dict key’s entry.\u00a0 Not good.\u00a0 I implemented<\/a> a fix<\/a> to set a random, non-persistent identifier so as not to lose data.<\/p>\n

Of course, the best solution here would be for providers to set identifiers accordingly from the start.\u00a0 Then again, what happens when CSW endpoints harvest other CSWs and identifiers are the same?\u00a0 Perhaps a namespace of some sort for the CSW would help.\u00a0 This would be an interesting interoperability experiment.<\/p>\n

Harvest Support Added<\/h3>\n

I implemented<\/a> a first pass<\/a> of supporting Harvest operations.\u00a0 CSW endpoints usually require authentication here, which may vary by the implementation.\u00a0 Therefore, I’ve left this logic out of OWSLib as it’s not part of the standard per se.<\/p>\n

Transaction Support Coming<\/h3>\n

Sebastian Benthall<\/a> of OpenGeo<\/a> has indicated that they are using OWSLib’s CSW support for some of their projects (awesome!), and has kindly submitted a patch<\/a> for an optional element issue (thanks Sebastian!).\u00a0 He also indicated that Transaction support would be of interest, so I’ve started<\/a> to think about this one.\u00a0 As with the Harvest operation, Transaction support also requires some sort of authentication, which we’ll leave to the client implementation.\u00a0 Most of the work will be with marshalling the request, as response handling is very similar to Harvest responses.<\/p>\n

Give it a go, submit bugs and enhancements to the OWSLib trac<\/a>.\u00a0 Enjoy!<\/p>\n\n\n