Trouble Parsing ISO19139 Services about owslib

[tomkralidis]

hi @dblodgett-usgs thanks for the info. I am able to reproduce the issue.

The problem is that owslib/iso.py populates md.distribution.online from gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:transferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource

In the "gmo" query response, the URLs are set in gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor/gmd:MD_Distributor/gmd:distributorTransferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource. This does not get populated in md.distribution.online.

I would suggest verifying that this is actually where you want your metadata to store URLs (as opposed to storing them as per the "nlcd" query response).

In any case, it shouldn't much to add support for this area in the codebase. Keep in mind you would then have to traverse along md.distribution.distributor.online (roughly, TBD), as opposed to md.distribution.online.

Let me know what your findings are.

[dblodgett-usgs]

Hi Tom, Thanks for the quick response! You are right that the urls at gmd:MD_Metadata/gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor/gmd:MD_Distributor/gmd:distributorTransferOptions/gmd:MD_DigitalTransferOptions/gmd:onLine/gmd:CI_OnlineResource are not being parsed right now, that is where the iso creation utility we use puts urls for "human consumption"

There are also urls at gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/srv:containsOperations/srv:SV_OperationMetadata/srv:connectPoint/gmd:CI_OnlineResource/gmd:linkage/gmd:URL
These are urls for "machine interpretation".

Additionally, there are a couple of srv:SV_ServiceIdentification sections in the record the 'gmo' record as well.

This iso pattern is generated bu the ncISO project... here: http://www.ngdc.noaa.gov/eds/tds/ A bit unconventional, but very useful.

Make sense? We are really trying to get at the multiple MD and SV identification sections in the same MD_Metadata document.

[tomkralidis]

@dblodgett-usgs thanks for the info. Currently, md.identification stores a single data identification element, and md.serviceidentification stores a single service identification element.

md.identification is better off as a list, but I'd like to preserve backwards compatibility.

How about md.identificationinfo as a list of service and data identification elements?

Current functionality of md.identification would be preserved.

Long term solution would be to move md.identificationinfo to md.identification.

For now we can put a FutureWarning and phase this out eventually.

Thoughts? Any feedback/suggestions would be valued.

[dblodgett-usgs]

This sounds perfect Tom. Definitely want to keep backward compatibility.

[tomkralidis]

@dblodgett-usgs I've added this functionality to my fork at https://github.com/tomkralidis/OWSLib. Changes per above:

With this branch, you can now do:

>>> # SV_ServiceIdentification links
>>> from lxml import etree
>>> from owslib.iso import MD_Metadata
>>> md = MD_Metadata(etree.parse('foo.xml'))
>>> len(md.identificationinfo)
>>> 3 # all members have .identtype ('dataset'|'service') set
>>> md.identificationinfo[1].operations[0]['connectpoint'][0].url
'dods://cida.usgs.gov/thredds/dodsC/gmo/GMO_w_meta.ncml'
>>> # distributor links
>>> m.distribution.distributor[0].online[0].url
'http://cida.usgs.gov/thredds/dodsC/gmo/GMO_w_meta.ncml.html'

So md.identificationinfo is a list, and will become md.identification over time. And the distributor links are supported now.

Can you test this out and let me know if this is okay? I'll push to master upon your verification.

[tomkralidis]

@dblodgett-usgs pushed to master in 0770546

[dblodgett-usgs]

Hi Tom, I'm finally getting back to working on this... Looks like things are working as expected. Thanks!