<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr"><br><br><div><div id="SkyDrivePlaceholder"></div>> From: rhodges@ecotrust.org<br>> To: pycsw-devel@lists.osgeo.org<br>> Date: Sun, 16 Dec 2012 12:03:56 -0800<br>> Subject: [pycsw-devel] PyCSW Harvesting<br>> <br>> I’ve been testing out harvesting with PyCSW and I’m pretty impressed, right off the bat harvesting from CSW sources (including GeoNetwork and GeoPortal, ISO19139 and FGDC) was fairly smooth. However, I didn’t have any success harvesting a CKAN 1.8 instance or between PyCSW instances, and I also failed to harvest from PyCSW using CKAN 1.8, GeoPortal, or GeoNetwork (all of the failed tests were with ISO 19139 documents).<br>> <br>> Does this sound about right?<br>> <br>> I can understand failing on harvesting CKAN 1.8, as it was (as I understand) only set up to serve CSW to be >harvested from by GeoNetwork instances, though CKAN 2.0 should be better thanks to PyCSW. <br><br>Yes, for the record, some of the CKAN issues were discussed on the ckan-dev mailing list last month:<br><br><a href="http://lists.okfn.org/pipermail/ckan-dev/2012-November/003406.html" target="_blank">http://lists.okfn.org/pipermail/ckan-dev/2012-November/003406.html</a><br><br>Having
said this, CKAN is moving ahead with pycsw integration (Adrià: any
update?), so I imagine some of these issues may go away in terms of CSW
interoperability.<br><br>>However I'm not sure if the problems I'm having harvesting between PyCSW instances is due to me improperly >configuring one/both of my PyCSW instances, or if it's indicative of something bigger. Has anyone successfully >performed CSW harvesting between to PyCSW instances, and if so, do you have a server somewhere I could >attempt to harvest from (preferably with only a few records in it)?<br>> <br><br>You can always test out the endpoints at <a href="http://demo.pycsw.org/." target="_blank"></a><a href="http://demo.pycsw.org/," target="_blank"></a><a href="http://demo.pycsw.org/." target="_blank"></a><a href="http://demo.pycsw.org." target="_blank">http://demo.pycsw.org</a>, which serve Dublin Core, FGDC, and ISO documents as examples. <br><br><a href="http://demo.pycsw.org/." target="_blank"></a><br>> If there is something specific that you'd like to see in my logs from these tests, let me know. I'll be better able to get those on Monday.<br>> <br><br>Ryan and I discussed these issues on IRC today, and found the following issues:<br><br>- sbin/pycsw-admin.py's post_xml operation has a default HTTP timeout of 10 seconds, which was giving timeout errors. Since fixed (see https://github.com/geopython/pycsw/issues/96)<br><br>- pycsw does CSW harvesting with the following logic:<br> - client sends CSW Harvest request asking server A to harvest server B<br> - server A sends 1..n GetRecords server B asking for all typenames supported by server A<br> - if server B does not support all server A's typenames, an exception is thrown by server B, and subsequently server A back to the client. Initial tests of a fix indeed fixed the issue, but this needs more thought before a fix is committed. I have since filed an issue at https://github.com/geopython/pycsw/issues/99<br><br>Thanks for the testing and reporting.<br><br>..Tom<br><br>> Thanks,<br>> Ryan Hodges<br>> Applications Developer at Ecotrust <br>> rhodges@ecotrust.org | +1-503-467-0800 | www.ecotrust.org<br>> _______________________________________________<br>> pycsw-devel mailing list<br>> pycsw-devel@lists.osgeo.org<br>> http://lists.osgeo.org/mailman/listinfo/pycsw-devel<br></div></div>
</div></body>
</html>