WALIS wrapup

So the WALIS forum is finished for another 18 months … was fun. While i didn’t get to as many sessions as i would have liked, the turnout was fantastic with more than 630 delegates coming through the doors.

There was lots of interest generated by the demonstrations on our Shared Land Information Platform SDI for WA. The resounding theme was of surprise i’d have to say with what has been achieved. There has been quite a few people dismissing the project along the way but i think everyone is finally starting to see the light at the end of the tunnel
In other news,

  • the ESRI 9.2 rc looks good from what i could see looking at some of the demos. Just put James Fee on ignore and be patient :)
  • The work on ESRI’s portal toolkit is certainly continuing. From what i saw of the workshop there was a fair bit of interest
  • Intergraph were showing off some of their sexy imagery analysis applications. I dont think anyone can get sick of high res fly-throughs can they?
  • Cadcorp guys made the trip down to set up a booth as new kids on the block. Seemed to be well recieved locally … top blokes too!
  • The last thing i can remember is the 3d globes. Customised worldwind apps …. Skyline TerraExplorer …. DappleosgPlanetGoogle Earth … when will it end!?
  • Doesnt seem like the Autodesk Mapguide products have gotten much of a foot hold down here. Unfortunately the local resellers didnt seem to have much info on hand about it. I was interested to hear their thoughts on going opensource and its impact on the local market.

WALIS will hopefully be releasing the presentation slides shortly to anyone interested. Unfortunately i wasnt smart enough to take some piccies, but no doubt some writeups will appear in the aust. GIS media soon.

Overall i’m glad i stayed. I was bit too’ing and fro’ing whether to go to the FOSS4G conf instead. By the looks of things there didn’t seem to be much interest from what i saw in the photos? (Please tell me otherwise!) I’m sure local boy, Tim Bowden held the torch well

Google half bakes WMS support

As has been reported all over the place, the latest Google Earth v4 beta now has “WMS” support.

In the 5 minutes i had a look, the following needs to be fixed

  1. The mandatory Service=WMS parameter is not attached to the online resource which causes some services to fail
  2. The is no support for layer subgroups as per WMS spec
  3. You cannot select the preferred image format when requesting (defaults to image/gif .. wheres my png!). Some services seem to pick png … ?
  4. The overlay never seems to be requested at the current, full extents .. for some reason?
  5. The [t] i’m assuming stands for transparency ?
  6. The client, out of courtesy, should always request any exceptions in image if the service supports it
  7. Generic HTTPS support is still broken for everything, including image overlays
  8. The client should really be able to interpret the bounding box and set the image overlays to start using the region KML functionality. If the average joe blogs adds a service, it would be for good measure to zoom to the envelope extents of that layer/service.

I know its beta, but truth be told i’m a bit dissapointed with the support. It really seems like the whole WMS feature was just something thrown in quickly, hidden in the depths of the image overlay -> refresh dialog. A lot of the points are very minor changes so i am hopeful the spatial guys at Google recognise the importance of good WMS support.

The problem with OGC support ..

is that the focus is too largely geared towards server certification. While i understand the importance of server compliance using tools such as CITE, if the subsequent clients consuming these services are poorly implemented, the end user surely has to question the point of it all.

I would really like to see a set of “best practices” written up for OGC clients to at least, try to follow.

Here’s my list (which is by no means complete)


  • Use layer Title’s and not Name’s
  • Support layer grouping’s
  • Be able to pull out individual layers from a service
  • Be able to split layers into separate requests if desired. Layers will be returned based on their draw time and not have to wait for the slowest layer
  • Select desired output format
  • Select desired coordinate system
  • Interpret the ScaleHint element so user’s are aware of any view scale restrictions
  • A console to debug requests sent without referring to server logs
  • Support for GetFeatureInfo and GetLegendGraphic requests
  • Support for BASIC HTTP authentication
  • Tiled requests. If i already have the image for that area, just download the difference when i pan.


  • Use layer Title’s and not Name’s
  • Support of the maxfeatures parameter
  • Support of the BBOX/Intersects Filter at the very least
  • Caching of features. If i zoom out or pan from the current view, why should i have to wait for another WFS request when i already have the features?
  • Status indicator
  • Ability to send manual POST requests to the server.
  • Support for the GZIP / Deflate HTTP compression schemes if the server supports it. Everyone knows GML compresses smaller than shapefiles in most cases … lets speed things up a bit
  • Whether the WFS GML is converted or read natively, ultimately that WFS layer should be treated no differently than a local dataset in your client.

Let me know if you disagree or think something should be added … i’d certainly like to hear other people’s thoughts on the issue or if you’ve run into similar issues.