"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Testbed 2 - Geologic Map Of Canada

WMS Service

The WMS service address is here: http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/wms? The GetCapability for the Geologic Map : http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/wms?REQUEST=GetCapabilities

For those interested, the step-by-step of setting the wms wrapper is here : CocoonWmsSteps

The service is received by Cocoon that relay the call to ArcIMS that hosts the GDR dataset

The dataset is not complete because GDR does not have any faults nor boreholes.

-- EricBoisvert - 15 Sep 2005

-- EricBoisvert - 18 Nov 2005

Viewer

The testbed map can now be viewed using Phoenix. Please contact Boyan if you want to use Phoenix, in order to grant you the required priviledges to access the testbed workspace. A simple viewer is also available to demonstrate the wms/wfs service at http://ngwd-bdnes.cits.rncan.gc.ca/services/iugs/viewer.html

-- EricBoisvert - 03 Nov 2005

WFS

Made some minor changes (mostly to URLs) and internally on the server. But this page will be completely rewritten in a step by step fashion.. This was up to now a work in progress. stay tuned.

-- EricBoisvert - 07 Dec 2005

I've tested the performance of the testbed (or how the wrappers actually interfers with the real server hidden behind it).. The results are on CanadaTestBed2Perf.

Case 1

This is the first steps of the Case 1. It displays a geological map of Canada and when a GetFeatureInfo is issued, it returns GeoSciML.

http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/viewer.html

Again, Cocoon catches the GetFeatureInfo request, convert the pixel based x,y coordinates into a ArcXML query, which is sent to ArcIMS, then processed by Cocoon to translate GDR based result into GeoSciML. The sitemap for the whole WMS process is here

<map:pipeline>
      <map:match pattern="wms">
         <map:select type="parameter">
            <map:parameter name="parameter-selector-test" value="{request-param:REQUEST}"/>
            <map:when test="GetCapabilities">
               <map:generate src="capabilities/bedrock_wms.cap"/>
               <map:serialize type="xml"/>
            </map:when>
            <map:when test="GetMap">
               <map:read src="http://gdr.ess.nrcan.gc.ca/wmsconnector/com.esri.wms.Esrimap/GDR_E?{request:queryString}"/>
            </map:when>
            <map:when test="GetFeatureInfo">
               <map:generate type="serverpages" src="xsp/FeatureInfoArcXml.xsp">
                  <map:parameter name="WIDTH" value="{request-param:WIDTH}"/>
                  <map:parameter name="HEIGHT" value="{request-param:HEIGHT}"/>
                  <map:parameter name="BBOX" value="{request-param:BBOX}"/>
                  <map:parameter name="X" value="{request-param:X}"/>
                  <map:parameter name="Y" value="{request-param:Y}"/>
               </map:generate>
               <map:transform type="ArcIms">
                  <map:parameter name="server" value="http://gdr.ess.nrcan.gc.ca/servlet/com.esri.esrimap.Esrimap?ServiceName=GDR_E&amp;CustomService=Query"/>
               </map:transform>
               <map:transform src="style/arcimsResponse.xslt"/>
               <map:transform src="style/gsmlunit.xslt"/>
               <map:serialize type="xml"/>
            </map:when>
            <map:otherwise>
            <map:generate src="error.xml"/>
            <map:serialize type="xml"/>
            </map:otherwise>
         </map:select>
      </map:match>
   </map:pipeline>

The interesting bit is the way that GetFeatureInfo is processed.

<map:when test="GetFeatureInfo">
   <map:generate type="serverpages" src="xsp/FeatureInfoArcXml.xsp">
...

serverpages generator are java classes that generates XML as an output. The syntax is a mixture of java code and xml tags, pretty similar to a JSP, ASP or Cold Fusion page. Except that the xsp file is actually compiled into a java class (and not interpreted like JSP, ASP or Cold Fusion). What this xsp generator actually do is get the width, height, BoundingBox and x,y of the click location and convert it to a long lat coordinate and then embed the result in a ArcXML request.

FeatureInfoArcXml.xsp source code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsp:page xmlns:xsp="http://apache.org/xsp"
          xmlns:xsp-request="http://apache.org/xsp/request/2.0"
     xmlns:esql="http://apache.org/cocoon/SQL/v2" xmlns:cinclude="http://apache.org/cocoon/include/1.0">
<!-- turn a GetFeatureInfo into a ARCXML GET_FEATURE -->
<ARCXML version="1.1">
   <xsp:logic>
   // get information from parameters
   int width = parameters.getParameterAsInteger("WIDTH",0);
   int height = parameters.getParameterAsInteger("HEIGHT",0);
   String bbox = parameters.getParameter("BBOX",null);
   int x = parameters.getParameterAsInteger("X",0);
   int y = parameters.getParameterAsInteger("Y",0);
   String[] coord = bbox.split(",");
   Double xmin = new Double(coord[0]);
   Double ymin = new Double(coord[1]);
   Double xmax = new Double(coord[2]);
   Double ymax = new Double(coord[3]);
   // calculate the coordinate
   double px = (xmax.doubleValue() - xmin.doubleValue()) * x / width + xmin.doubleValue();
   double py = (ymax.doubleValue() - ymin.doubleValue()) * (height-y) / height + ymin.doubleValue();
   </xsp:logic>
   <REQUEST>
   <GET_FEATURES featurelimit="5" outputmode="newxml" geometry="true">
   <LAYER id="BedrockGeology"/>
   <SPATIALQUERY subfields="UNIT PERIOD RXTP SUBRXTP AGERXTP OBJECTID #SHAPE#">
      <SPATIALFILTER relation="area_intersection">
         <POLYGON>
            <RING>
            <POINT><xsp:attribute name="x"><xsp:expr>px-0.0001</xsp:expr></xsp:attribute><xsp:attribute name="y"><xsp:expr>py-0.0001</xsp:expr></xsp:attribute></POINT>
            <POINT><xsp:attribute name="x"><xsp:expr>px+0.0001</xsp:expr></xsp:attribute><xsp:attribute name="y"><xsp:expr>py-0.0001</xsp:expr></xsp:attribute></POINT>
            <POINT><xsp:attribute name="x"><xsp:expr>px+0.0001</xsp:expr></xsp:attribute><xsp:attribute name="y"><xsp:expr>py+0.0001</xsp:expr></xsp:attribute></POINT>
            <POINT><xsp:attribute name="x"><xsp:expr>px-0.0001</xsp:expr></xsp:attribute><xsp:attribute name="y"><xsp:expr>py+0.0001</xsp:expr></xsp:attribute></POINT>
            <POINT><xsp:attribute name="x"><xsp:expr>px-0.0001</xsp:expr></xsp:attribute><xsp:attribute name="y"><xsp:expr>py-0.0001</xsp:expr></xsp:attribute></POINT>
            </RING>
         </POLYGON>
      </SPATIALFILTER>
   </SPATIALQUERY>
   </GET_FEATURES>
   </REQUEST>   
</ARCXML>
</xsp:page>

this is then process following the familliar chain of transformators:
  • ArcIms transformation, that direct this ArcXML to ArcIMS
  • a stylesheet to extract only the response
  • a stylesheet to convert the ArcIms response into GeoSciML.

Don't you love Cocoon ? smile

-- EricBoisvert - 16 Sep 2005

Case 2

For case 2, I had to implement the complete round-trip. This means that the wfs query had to be translated prior to be sent to ArcXML and the result translated back to GeoSciML. I implemented a cocoon wrapper for WFS, GetCapability, DescribeFeatureType and GetFeature are partially implemented.

As I did for WMS, here's the step by step implementation of WFS service over ArcIMS in Cocoon : CocoonWfsSteps

GetCapabilities

http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/wfs?REQUEST=GetCapabilities works but sends a static WFS Capability document

DescribeFeatureType

http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/wfs?REQUEST=DescribeFeatureType&TYPENAME=gsml:LithoStratographicUnit will return the full schemas. The spec says it should return only requested type and related datatype. This is probably doable in GML2, but in GML3.x , Classes are connected to Classes through association and each classes are potentially connected to all others. I don't know how to solve this one, and I'm not the only one, I've seen very serious implementation (province of Ontario, the implementation has been done by Galdos) that do just this, return the whole document where the class is described. So, of course, the TYPENAME parameter is ignored.

Can't this be resolved through the judicious use of <include> and <import> elements, on which the schemaLocation value is a URL, or even another DescribeFeatureType call? -- SimonCox - 26 Oct 2005

In other words, isolate this specific feature type in a single dynamically generated xsd document with the appropriate xs:include statement ?. I see 2 problems...well, 1 annoyance and 1 problem

  • If the DescribeFeatureType returns a partial document, it forces the client to call the rest of the schema anyway (to make anything useful out of it). Might as well have it all on the first trip.
  • If we create a dynamic subset (isolating the requested Feature(s) ) that points to the full schema, and I see here a pointer to the static GeoSciML series of xsd, we will get in the situation where we will point to the xsd where this specific feature is already defined, and the validator will complain that this feature is already declared (once in the dynamically generated from DescribeFeatureType, once in the static schema)

The only solution is to have a completely dynamic solution, but does it worth the trouble ?? Or am I missing something ?

-- EricBoisvert - 26 Oct 2005

GetFeature

The GetFeature can be tested to some extents here: http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/ogc_filter.html You can change the BBOX and the maxFeatures values so far.

Client implementation.

I'm working on this part right now -- but essentially, the server side is functionnal for a simple BBOX query on a gsml:LithoStratographicUnit

-- EricBoisvert - 16 Sep 2005

I've fixed a couple of bugs in the previous version of my component mainly to deal with CarbonTools. The new component can be downloaded from CocoonArcIms.

I tested the server with Carbontools's GML Analyser. It also works with Gaia (in the sense that it does not return an error), but it won't display anything because (I assume) it does not know where the find the geometry to display (most GML client expect a geometry to appear in the feature under featureMember). In our case, the shape is located under MappedFeature. Does this means that the only type our wfs service will return are MappedFeatures ? This brings us back to good old shape files, isn't it ?

-- EricBoisvert - 27 Oct 2005

I was wrong about Gaia.. this thing actually can figure out the geometries to display out of GML3 complex structure (kudo). I managed to fix a few problems with the GeoSciML and can read the service with Gaia. I improved the speed of the service by using Nico Verwer's MultiFragmentTraxTransformer. I still have problem with Gaia and I'm not sure the service is the cause. It raises StackOverflow errors (which is a sign that it ran out of memory) when I request 1700 features or more. I'm pretty sure this is not caused by the size of the document (it's a few Megs), it looks like some infinite loop. I report this to Tim Duffy - BGS plans to use this and have a service agreement with CarbonTool.

In the mean time, this is what it looks like for Case 2

Gaia screenshot

The coloured map is from the WMS service (Case 1), the Drainage is from the National Atlas of Canada and the yellowed out polygons are from the WFS Service (500 first Features)

-- EricBoisvert - 01 Nov 2005

I've replace wfs-frag with stx to convert ArcXml to GeoSciML. Stx is a tranformation language, similar to xslt, that applies on SAX source instead of a DOM source. The result is similar to wfs-frag, but faster

STX

For those who want to use stx on cocoon, you need to update the stx component since cocoon ships with a previous version for compatibility with JDK 3.x.

  • stop apache
  • go under webapps/cocoon/WEB-INF/lib and delete (or move somewhere else) joost-20040330.jar
  • download joost from https://sourceforge.net/project/showfiles.php?group_id=55258
  • in this archive, you will find a lot of file and a single jar file (joost.jar), save this file in webapps/cocoon/WEB-INF/lib
  • restart tomcat

that's it.

-- EricBoisvert - 07 Dec 2005

The source is here: http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/source/style/gsmlunit.xslt

-- EricBoisvert - 05 Nov 2005

Case 3 Using SLD to portray GeoSciML data

As I did got Case 1 and 2, I kept a log (CocoonSldImplementation) nf how I implemented the Case 3 in Cocoon (as at least 2 other organisation uses the same technology). See TestBed2 for the requirements of the test bed.

-- EricBoisvert - 08 Aug 2006

Cocoon Site Map

Instead of copying pieces of a ever changing sitemap in here, you can see the source dynamically from here

http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/source

ou can also look at the stylesheet refered from in the sitemap. For example, if you see this line in the sitemap
<map:transform src="style/gsmlunit.xslt"/>
you can see it by hitting this link:

http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/source/style/gsmlunit.xslt

(just change the append the src="" portion to http://ngwd-bdnes.cits.rncan.gc.ca/service/iugs/source/)

-- EricBoisvert - 27 Oct 2005

WMS client

Tried MoxieMedia client. I could bring the canadian testbed map and US testbed map in a single screen. Cool.

-- EricBoisvert - 19 Dec 2005

  • canada - usa:
    canada - usa
Topic attachments
I Attachment Action Size Date Who Comment
gaiatest.pngpng gaiatest.png manage 58.3 K 01 Nov 2005 - 22:19 EricBoisvert Gaia screenshot
northamerica.pngpng northamerica.png manage 103.2 K 19 Dec 2005 - 21:30 EricBoisvert canada - usa
Topic revision: r20 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).