Digital Earth Weblog

Thanks to a pointer from James Fee to the Text Control plug-in I now have a ZoomIn map embedded in a Wordpress weblog post.

Note: If you are reading this in an RSS aggregator chances are the scripting has been stripped or ignored. Please try this page.

To get this to work I had to:

1. Use Text Control to turn off all of Wordpress’ default text formatting, and
2. Fix a minor bug in the sample code. There was an extra parenthesis on the end of GPoint(151.215,-33.857), 4);

[code]
[/code]

Update: Added a marker for the Sydney Opera House that displays an information window.

In my last post I said it was going to see how easy it was to embed a ZoomIn map in a blog post. Tried. Failed.

When I enter the the <script> … </script> element in the Wordpress editor it escapes some of the characters to HTML entities and Unicode characters and inserts <br /> elements (not good inside a JavaScript block). The <script> elements also get wrapped in <p> elements.

Several attempts at workarounds also failed, including putting all the JavaScript on one line, and wrapping it with <![CDATA[ … ]]> or HTML comment tags.

ZoomIn is a Google Maps-like system using Australian data. In addition to being an online street directory you can add places of interest, write comments, join a group and share photos about a place. It also has a developer API for mapping and geocoding.

ZoomIn originated in New Zealand. It looks like ProjectX and SDX have teamed up to bring it to Australia.

The website has been developed to encourage exploration. If you go to the home page and type the first few letters of a place name into the search box you get a list of possible matching options. This feature only seems to return streets and suburbs. It would be nice to have it return places of interest.

ZoomIn also uses a hierarchical URI scheme to represent locations that I haven’t seen before. For instance, you’ll find the suburb of Mangerton in the city of Wollongong at:

http://zoomin.com.au/australia/nsw/wollongong/mangerton/

Append <street+name>/<no>/ to identify an address. Simple, effective.

I have requested a developer API key. I’m curious to see how much effort is required to embed a map in a blog post. More to come…

This feels very familiar:

Dave Podnar’s 5 Stages of Dealing with Web Services

Followed by the realisation that the vast majority of web services can be created using XML over HTTP (or even better, REST).

[tags]web services, rest, soap[/tags]

Rhonda left a comment on my Improving WMS GetFeatureInfo – Part 2 post. In my effort to clarify my thoughts my responding comment got lengthy, so here’s a new post.

“GetFeatureInfo is not different than using the info tool in your favorite GIS client.”

Exactly! That’s what I’m trying to encourage with WMS. A WMS client should be able to display the GetFeatureInfo response using the same presentation style regardless of WMS implementation that provides the layer that was queried. All the GIS applications that I’ve used display a table of name/value pairs.

ID	1234
Depth	30.0 m

The INFO_FORMAT parameter is mandatory, but by specifying INFO_FORMAT=text/xml& in your GetFeatureInfo request you still do not know what the content model of the XML response will be. In the current WMS specifications it is left to the WMS implementor. Therefore, a WMS client cannot provide a consistent and useful user experience.

I’m using the term “generic features” to describe the use of the element name Feature which contains Properties in the form of a set of Property title/value pairs. e.g.

[xml]
1234 30.0

[/xml]

In contrast, the non-generic “feature typed” version would use meaningful element names. One possible example is:

[xml]
1234 30.0

[/xml]

The generic feature approach can be used to describe details about any feature using one content model. This enables interoperability, and interoperability leads to a consistent experience for the user regardless of the WMS implementation.

In contrast, a GetFeatureInfo response that contains non-generic features requires prior knowledge of that specific content model. Unless a WMS client understands the semantics of my water bore schema it cannot render a visually consistent response for the user just by asking my WMS for INFO_FORMAT=text/xml&.

I understand that the format I am proposing is not good XML markup, from a semantic viewpoint, and that it results in tighter coupling. However, my position is that without an agreed GetFeatureInfo response format interoperability cannot occur without a lot of up front complexity.

Details on the NetKernel website. If you are doing any web application or web services development you should do yourself a favour and have a look at NetKernel.

A client has been developing a SOAP web service. I got involved with specifying the web service interface and testing compliance with the specification. I ended up using JMeter and XPath assertions. It doesn’t have the addictive unit test “green bar”, but it worked.

The requirement was to perform the tests on the SOAP messages that passed across the wire. At least one client application will be POSTing raw XML SOAP requests to, and pulling apart SOAP responses from, this service rather than using using a SOAP toolkit. We needed to ensure that the web service interface behaved as expected, and that business logic changes behind the interface had no impact on the client applications.

Prior to setting up the tests in JMeter a quick Google didn’t reveal anything suitable for a quick and dirty test. The tests could have been written unit and executed using JUnit, but a declarative solution that could be emailed to the client was preferred. JMeter did the job, but it did have a few issues.

The Recipe

1. Download and install JMeter. (Activation.jar and mail.jar are required for SOAP testing. See installation notes.)
2. Create a new Test Plan.
3. Add a Thread Group to the Test Plan. Check that the number of threads is set to 1 and the number of loops is 1.
4. For each test, add a Web Service (SOAP) Request samplers as a child of the Thread Group. Name them with a numeric identitifier for ease of reference. e.g. “1. Invalid Foo, Valid Bar”. You will need to supply the URL to the WSDL file and a fully formed SOAP request XML document.
5. For each sampler, add as many XPath Assertions as you need to validate the result. XPath expressions can be used to check pretty much everything about the content and structure of XML documents.
6. Add a View Results Tree listener to capture and display the requests and responses. Any tests that fail will be shown in red.
7. Save your Test Plan.
8. Run it.
9. View results by clicking on the View Results Tree.
10. Clear results before running the test again. Results are stored cumulatively, not replaced by each test.

Here is an example test plan:

The Results

In this example, the fifth test “Invalid Values” did not return the expected results.

The View Results Tree listener also lets you view the HTTP headers, the XML request, and the XML response (not shown here). This is helpful for debugging, and you can also ask JMeter to write that data to file.

Minor Issues

1. No green bar, but then JMeter is not intended to be a unit test framework.
2. Duplication. XPath assertions are repeated in multiple tests. If you need to modify a repeated assertion you need to do it manually. That said, the JMeter project file (.jmx) is an XML document so you can (carefully) do a global search and replace. JMeter also makes it easy to copy and paste any element of the test plan so is not a major drama.

The JMeter project that was created became useful tool. The web service developer can now run the tests at any time, particularly before deploying a new version of the web service. Simple declarative regression testing.

[tags]JMeter, JUnit, unit testing, SOAP, web services[/tags]

After getting some good feedback from the members of the WMS Developer mailing list I have revised my suggested WMS GetFeatureInfo response format.

Background on this topic is described in Part 1 and Part 2 of my original suggested WMS GetFeatureInfo response format.

Keith Pomakis of CubeWerx also suggested using their BXFS format (XML Schema). Personally, I was looking for something a little simpler than BXFS, but if links to related resources were added to BXFS it would be able to perform the same function (and a lot more).

However, several of the people on the WMS Developer thought simplicity was the key so here is a revised, and slightly simplified, proposed WMS GetFeatureInfo response format (dubbed version 0.2).

<?xml version="1.0" encoding="UTF-8"?>

<!— This is an example of a WMS GetFeatureInfo response 
  instance document in the format being described by the 
  accompanying schema.


  – Rights: Public domain.
  – Version: 0.2
  – Author: Andrew Hallam, Digital Earth Pty Ltd. See also the 
    threads titled  "Suggestion for Common GetFeatureInfo 
    Response Format" at 
    http://lists.eogeo.org/pipermail/wms-dev/2006-January/thread.html
  – Date: 2006-01-27

  NB: See associated schema for documentation. Changes are 
  noted below in comments.
  —>
<FeatureInfoResponse 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="wms-gfi-response-v0.2.xsd">
  <Layer>
    <name>bores</name>
    <title>Water Bores</title>
    <!— In version 0.1 Features were identified by an attribute 
      named "id". This is a bad idea because feature 
      identifiers are not XML identifiers (which must be unique 
      within an XML document), and there is the possibility of  
      getting identical features within one GetFeatureInfo  
      response document. The identifier attribute has been  
      renamed "fid" (stolen from GML, with thanks).
    —>
    <Feature fid="1234">
      <Properties>
        <Property>
          <title>ID</title>
          <value>1234</value>
        </Property>
        <Property>
          <title>Depth</title>
          <!— 
          Units of measure have been given their own attribute.
          —>
          <value uom="m">30.0</value>
        </Property>
      </Properties>
      <!— Links only represent related web resources so the "rel"
        attribute has been dropped, and all link element must 
        have an attribute named "title".
      —>
      <link type="text/html" 
        href="http://somedomain/bore/report?id=1234" 
        title="Salinity Report for Bore 1234"/>
    </Feature>
    <Feature fid="4321">
      <Properties>
        <Property>
          <title>ID</title>
          <value>4321</value>
        </Property>
        <Property>
          <title>Depth</title>
          <value uom="m">55.5</value>
        </Property>
      </Properties>
      <link type="text/html" 
        href="http://somedomain/bore/report?id=4321" 
        title="Salinity Report for Bore 4321"/>
    </Feature>
  </Layer>
  <Layer>
    <name>salin_stat</name>
    <title>Watercourse Salinity Measuring Stations</title>
    <Feature fid="5678">
      <Properties>
        <Property>
          <title>Station ID</title>
          <value>5678</value>
        </Property>
        <Property>
          <title>Station Name</title>
          <value>Beyond the Black Stump</value>
        </Property>
        <Property>
          <title>Salinity Reading</title>
          <value uom="ppm">6290</value>
        </Property>
        <Property>
          <title>Last Reading</title>
          <value>2006-01-21 14:00</value>
        </Property>
      </Properties>
      <link type="text/html" 
        href="http://somedomain/salinity/report/5678" 
        title="Salinity Report for Measuring Station 5678"/>
    </Feature>
  </Layer>
</FeatureInfoResponse>

Downloads:

• Example instance document (v0.2, as shown above), and
• it’s XML Schema (v0.2).

Changes since version 0.1:

• Features were identified by an attribute named “id”. This is a bad idea because feature identifiers are not XML identifiers (which must be unique within an XML document), and there is the possibility of getting identical features within one GetFeatureInfo response document. The identifier attribute has been renamed “fid” (stolen from GML, with thanks).
• Units of measure have been given their own attribute.
• Links now only represent related web resources so the “rel” attribute has been dropped, and all link element must have an attribute named “title”. The current WMS specification already handles alternate representations via the Format element in the capabilities document.

As usual, comments are most welcome.

[tags]WMS, interoperability, web services[/tags]

CarbonArc Lite is now available for download from The Carbon Portal.

“CarbonArc

For anyone interested in improving WMS GetFeatureInfo there is a good discussion happening on the WMS Developer mailing list.