I've added the provided service to the GI-cat broker. Please find attached some screenshots:
1) Query "temperature AND maximum"
2) maps provided by GI-axe via its WMS interface. GI-axe accesses in turn the OPeNDAP service. (in the next days we will fix the tiling problem that you can observe)
3) eHabitat layer added
Let us know in case of problems.
On 11/08/2012 06:30 PM, Ben Domenico wrote:
The search for "ehabitat" now returns 46 hits as it did before. Unfortunately I'm not sure what caused it to fail and what fixed it, but it is working now.
Is it possible to put in a configuration for resources on a TDS server now? Perhaps one of the Global Forecast System Model Best Time Series, e.g.
PS Also note the GI-cat service is still failing with an error message "Name must not be null."
On Wed, Nov 7, 2012 at 7:01 PM, Ben Domenico <address@hidden> wrote:
I may have some issues with my Java installation(s?). I notice some difficulties with IDV but inconsistent. I will reconfigure from scratch and see what happens tomorrow. It worked fine for a while.
On Wed, Nov 7, 2012 at 9:26 AM, Enrico Boldrini <address@hidden> wrote:
great result! That will be nice for the poster. I've tried to recreate the GI-go issue, but without success. Here is my configuration:
You can find attached two screenshots: the ehabitat query selection and its results.
Also, please find attached the screenshot of the GI-portal client, ehabitat query (available at: http://asclepio.pin.unifi.it:8080/gi-cat-9.4-SNAPSHOT/gi-portal/)
Let me know if the problem should persist and good luck with the experiments!
On 11/06/2012 05:47 PM, Ben Domenico wrote:
The good news is that the IDV displays the Ehabitat ADDCM3_A2a just fine as shown in the attached image.
Not so good is the fact that GI-go no longer finds anything when I search for ehabitat. The message I get from the CSW-ISO interface entry that Mattia sent me is
CSW exception report: CSW exception report:Exception Code: InvalidParameterValue- Unparsable date/datetime literal: 2012-10-29T05:59:59Supported date formats: yyyy-MM-dd,yyyy-MM-ddZ,yyyy-MM-dd+hh:mm,yyyy-MM-dd-hh:mmSupported dateTime formats: yyyy-MM-ddThh:mm:ss,yyyy-MM-ddThh:mm:ssZ,yyyy-MM-ddThh:mm:ss+hh:mm,yyyy-MM-ddThh:mm:ss-hh:mm
====================================================I believe this is the same search I did a few days ago when I got back 46 valid hits. Has something changed for that discovery service?
On Tue, Nov 6, 2012 at 6:52 AM, Ben Domenico <address@hidden> wrote:
Many thanks, Enrico.
That URL seems to display an image fine now within the Chrome browser.
I will try it in the IDV when I get to the office this morning. In the meantime, I've put some entries into the Google site wiki at
so I will have some memory assistance for our work and perhaps a place to start on the poster for AGU.
On Tue, Nov 6, 2012 at 3:02 AM, Enrico Boldrini <address@hidden> wrote:
Dear Ben, all,
sorry, the GI-axe restart procedure went wrong: now the problem should be fixed. We also took the opportunity to remove the service=WMS parameter, as per your suggestion!
Let us know in case of additional issues.
On 11/05/2012 07:23 PM, Ben Domenico wrote:
Hello again, Mattia and Enrico,
It seems that asclepio.pin.unifi.it is up and running again, but things are not working as they were over the weekend. For example, I cannot get the search to return any valid hits for "ehabitat". Also, when I use the browse interface, it only results in partial URLs for the transfer options linkage URLs.
Maybe the best simple and specific problem I can point out is the URL that was working to display an image over the weekend
http://asclepio.pin.unifi.it:8080/gi-axe-3110-SNAPSHOT/services/wms?protocol=urn:ogc:serviceType:WebCoverageService:1.0:HTTP&linkage=http://ehabitat-wps.jrc.ec.europa.eu/mapserver/index.php?&name=wc_10m_HADCM3_A2a_now_bio&&version=1.1.1&request=GetMap&Styles=&format=image%2Fpng&SRS=EPSG:4326&CRS=EPSG:4326&Layers=wc_2_5m_HADCM3_A2a_now_bio&BBOX=-179.0,-22.0,180.0,80.0&width=592&height=600&reaspect=false&transparent=TRUE&a mp;servic e=WMS
now fails with the following message:
<ns1:XMLFault xmlns:ns1="http://cxf.apache.org/bindings/xformat"><ns1:faultstring xmlns:ns1="http://cxf.apache.org/bindings/xformat">java.lang.NoClassDefFoundError: Could not initialize class eu.floraresearch.sdi.axe.stadd.matlab.MatlabMCRFactory</ns1:faultstring></ns1:XMLFault>For what it is worth, that is the situation I see at the moment. Thanks for any guidance you can provide.
On Mon, Nov 5, 2012 at 10:20 AM, Enrico Boldrini <address@hidden> wrote:
Hi Ben, all,
asclepio.pin.unifi.it is now up again, thanks for having pointed this out! Regarding the other problem, it seems indeed that service is not a required parameter (e.g. for wms GetMap). We are investigating deeper tomorrow and will fix the problem! Thank you again,
On 11/05/2012 05:24 PM, Ben Domenico wrote:
On a closer look, it seems the broker server asclepio.pin.unifi.it is not running today, so we'll have to wait for the ESSI Lab people to get it back online to continue our experiments.
On Mon, Nov 5, 2012 at 9:19 AM, Ben Domenico <address@hidden> wrote:
I downloaded the most recent nightly build of the IDV on my computer at work and I cannot get it to work with that brokering WCS to WMS URL. Has something changed in today's build of the IDV?
On Fri, Nov 2, 2012 at 1:55 PM, Yuan Ho <address@hidden> wrote:
On 11/2/2012 12:28 PM, Unidata IDV Support wrote:I added this SERVICE parameter in the IDV, the initial tests are pretty clean, didn't break those original WMS service. I will keep my eye opened for a while.
I just checked the WMS specifications (1.1.1 and 1.3.0) and neither requires or even lists the SERVICE parameter for the GetMap or the GetFeatureInfo requests. It is only listed (and mandatory) for the GetCapabilities request.
So, I think (as you first guessed) this is an issue for GI-Axe. Enrico and Mattia, does that sound right to you?
OK. I see. The unifi.it server is brokering a WCS service from the europa.eu
server into a WMS service. Here is the "bare" WMS GetCapabilities URL:
And Ben's original GetMap URL slightly cleaned up:
Ticket ID: RCF-221222
Department: Support IDV
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.