WebMapViewer Forum

Laszlo Zsidai

Dear WebMapViewer developers,

I have a problem with the WebMapViewer, namely that the search results are not dispalyed on the map but an error message is shown instead: "No features added to the map due to invalid GML".
I don't now what the problem is since previously it worked fine.
The service's stylesheet uses the following template for displaying the GML results on the WebMapViewer:

<xsl:template match="mass:viewEmbeddedResult">

<script LANGUAGE="JavaScript">
displaySingleEmbeddedResultFromPortal('<xsl:value-of select="mass:embeddedType"/>','<xsl:call-template name="ownEmbeddedResult"/>');
</script>
</xsl:template>

Where <xsl:call-template name="ownEmbeddedResult"/> generates the GML representation (see attached file)

As I mentioned it has been working until now.
I tested the attached GML representetion with the WebMapViewer Test Tool and I noticed that the Test Tool accepts our GML (see the attached image file).
The Test Tool can be found here: http://services-test.eoportal.org/portal/DownloadExternalUtil.jsp?pageName=mapTools

Is it possible that the implementation of displaySingleEmbeddedResultFromPortal() function changed somehow?
Or has the GML handling changed recently in SSE?

Laszlo Zsidai

Hello Paulo,

thanks for your comprehensive answer. Actually, pointing to the sources of the workflow did help a lot.
Unfortunately, we need to handle multi-polygons, which this workflow does not seem to support. On the other hand, we understand that utilizing undocumented features (as we did it) is not a goog practice, therefore we decided to create a custom worflow that fits our requirements.

Anyway your support was - as always - a good source of learning! Thanks a lot,
Laszlo

Hello Laszlo.

I think that the template is still invoked by the SSE, as it always was. There were quite a few SSE patches installed - one in particular addresses an issue with sse:viewEmbeddedResult but it should only affect RFQs; small patches to the WebMapViewer have also been delivered -, but I wouldn't expect any of them to cause the template not to be invoked.

I don't understand exactly why your strategy stopped working, but I think it was only working in the first place by coincidence (i.e. using a method which we don't recommend and that risks stop working at any time since it's not a "feature").

Anyway, the way to make this work, as you also suggested, is to have the workflow correctly generate the GML content of the sse:viewEmbeddedResult. If you look at the BPEL source of the search workflow, you see that the applied transformation (XSLT) is included in the suitcase under "xsl/cswApIso4Eo-v0-92-getRecordsToGml.xsl". This file is also online at http://services.eoportal.org/wsdl/icd/cswApIso4Eo-v0-92-hm/cswApIso4Eo-v0-92-getRecords-hm-1/templateSrc/xsl/cswApIso4Eo-v0-92-getRecordsToGml.xsl

Near the bottom of this file you find the statements to produce the GML coordinates in particular:

&lt;gml:coordinates&gt;
&lt;xsl:call-template name="write_polygon"&gt;
&lt;xsl:with-param name="polygon" select="concat(./gml:extentOf/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList,$space)"/&gt;
&lt;/xsl:call-template&gt;
&lt;/gml:coordinates&gt;

So, the XPath it uses is /gml:extentOf/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList, meaning it hopes to find:

&lt;gml:extentOf&gt;
&lt;gml:Polygon&gt;
&lt;gml:exterior&gt;
&lt;gml:LinearRing&gt;
&lt;gml:posList&gt;

while in your XML response, the corresponding structure at the moment is:

&lt;gml:extentOf&gt;
&lt;gml:MultiPolygon&gt;
&lt;gml:polygonMember&gt;
&lt;gml:Polygon&gt;
&lt;gml:outerBoundaryIs&gt;
&lt;gml:LinearRing&gt;
&lt;gml:coordinates&gt;

You need to either change the response (recommended) or change the XSLT inside the workflow (means that you need to edit the workflow, by hand or using a workflow editor).

Let us know if you need help,

Paulo

Laszlo Zsidai

Hello Paulo,

the problem is that the workflow does not copy the GML (from our service response SOAP message) into the sse:viewEmbeddedResult...
This is the reason why we decided to overwrite the <xsl:template match="mass:viewEmbeddedResult"> template in order to create the GML from the original response message.
Please note that it has been working until now, but currently the <xsl:template match="mass:viewEmbeddedResult"> template is NOT CALLED any more.

I see two solutions:
- either the <xsl:template match="mass:viewEmbeddedResult"> should be invoked again as before by SSE
- or the workflow should copy our original GML information into the appropriate element of the sse:viewEmbeddedResult

The second solution would be OK for me, but could you please help figure out why our GML is not accepted by the workflow.
Our response is based on the catalogue interface: http://services-test.eoportal.org/portal/documents/06-079r2_EO_Application_Profile_for_CSW_2.0.pdf where the GML information is included under the gml:extentOf element.
See the attached response sample:

<csw:GetRecordsResponse version="2.0.1" xmlns:csw="http://www.opengis.net/cat/csw" xmlns:gml="http://www.opengis.net/gml" xmlns:hma="http://earth.esa.int/hma" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:sosih="sosih" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<csw:SearchStatus status="complete"/>
<csw:SearchResults elementSet="summary" nextRecord="2" numberOfRecordsMatched="503" numberOfRecordsReturned="1" recordSchema="http://earth.esa.int/hma" resultSetId="resultSetId">
<hma:EarthObservationProduct>
<hma:identifier>SOSIH:SHNS_NPA:680</hma:identifier>
<hma:parentIdentifier>SOSIH:SHNS_NPA</hma:parentIdentifier>
<gml:extentOf>
<gml:MultiPolygon>
<gml:polygonMember>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates>18.1178017320794,46.1373218465818 18.1163211954191,46.1373095777901 18.1163036945857,46.1383293686975 18.1177871120148,46.1383416613403 18.1178017320794,46.1373218465818</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</gml:polygonMember>
</gml:MultiPolygon>
</gml:extentOf>
<hma:product>
<hma:ProductInformation>
<sosih:Properties>
...
</sosih:Properties>
</hma:ProductInformation>
</hma:product>
</hma:EarthObservationProduct>
</csw:SearchResults>
</csw:GetRecordsResponse>

Could you please tell me how the response message should contain the GML information in order to get a not empty sse:viewEmbeddedResult element?

Thank you in advance,
Laszlo

Hello again.

Actually the problem seems simpler than I was thinking. The search workflow was recompiled on the 16th of July so I cannot look before that, but all instances since then have the same problem.

All coordinates inside the gml which is inside the sse:viewEmbeddedResult element are empty. For each result, there is the XML element <gml:coordinates>,</gml:coordinates> (i.e. without any coordinates). The GML that you attached is not what is inside the sse:viewEmbeddedResult element. This is what will be passed to the WebMapViewer for display.

Paulo

Laszlo Zsidai

Hi Paulo,

I remember that it worked in July because we had an internal demonstration. But in August we did not try it in fact.

Ciao,
Laszlo

Hi Laszlo,

In fact it doesn't seem to be invoked, as the call to the displaySingleEmbeddedResultFromPortal() function is actually missing from the search result page. It appears the reason for that is an exception that's thrown when the SSE/WebMapViewer are trying to display the footprints on the map.

The date of last modification for the Search XSL is July 30, so it is plausible that one of the latest patches has something to do with it. When was the last time, more or less, when you know that this worked?

Paulo

Laszlo Zsidai

Dear Paulo,

we have checked our backend and nothing has changed. We still provide the GML in a single line.

We suspect that the template "mass:viewEmbeddedResult" is simply not invoked. Might this happed due to the new version of the SSE?

This is the service in question:
http://services-test.eoportal.org/portal/service/ShowServiceInfo.do?serviceId=1980F180

Can you have a look please,
Thanks,
Laszlo

Hi Laszlo.

Did you change anything on your service or backend, even if slightly or apparently not changing the functionality?

Often, the problem with this function are line breaks inside the GML string. So, the GML coming from <xsl:call-template name="ownEmbeddedResult"/> needs to be wrapped to be all on one single line.

There are also other ways to avoid this explained on the SSE ICD.

With the browser, you can also try to take a look at the source code of the generated page (search, rfq or order result) and/or error messages in the javascript console/debugger to see if there's something there.

If you didn't change anything, let us know for which service you are getting this.

Paulo