On bicycle accidents and furry pornography

A few days ago, the Belgian newspaper de standaard published this map depicting the number of bicyle accidents per community in Flanders.



 When I saw the map I quickly had to think of this XKCD comic:

Yes, logically most accidents happen in communes with a large population. Normalizing by population seems a sensible thing to do.

Saga GIS 2.1.0 rc2 - What's new?

Last week Olaf released the second release candidate for SAGA GIS 2.1.0. I thought this was a good opportunity to take some time to document what's new.




The major (from a technical point of view) change was the switch of wxwidgets 2.8 to wxwidgets 2.9. One of the major reasons that switch was made was to have better support for MacOSX, and it was also an opportunity to solve some unicode issues.

But unless you are using MacOSX this will not really help you. So you may be more interested in some other new features. One of the most relevant is support for parallel processing and some other performance enhancements. If you have a multicore processor you may find out that performance in some grid procedures like reclassification, resampling and calculation of convergence and wetness index is much better in this new build.

Should the "Geoservices REST API" become an OGC standard?

ESRI recently submitted their ESRI server REST standards to the OGC. Currently, the voting members have to decide whether they accept the proposal or not. As one of the contributors to the OSGEO-Live dvd, Cameron Shorter invited me to the discussion at Osgeo discuss list.
This discussion comes at an interesting time. Just a few weeks ago I did a session on geospatial web services in my company. The actual reason that we covered this topic is that there are two interesting (and diverting) trends happening at the same time:

1. The current OGC standards are finally taking off. Ever since our governement started serving their large-scale reference maps as publicly available WMS services, I see them being used  by many of our customers
   At the same time, I managed finding interesting data sets using CSW services for the first time, and the fact that view and metaservices have to be provided for INSPIRE III themes by the end of the year will probably mean that the shift to using services is finally taking off. 
2. On the other hand RESTful GIS services  have started popping up everywhere. ESRI's proposed Geoservices REST API is one, GeoREST is another one which I've enjoyed using. 

Actually my first thoughts when using ESRI's api was a sense of relief: I really enjoyed using these services. The fact that I can just tinker using an URL rather than having to use a special SOAP client was nice. My productivity as a programmer increased enormously. I couldn't figure out why anybody would want  to use SOAP-like services (without going in a semantic discussion).

So you would expect that I'd support the Geoservices REST API as an OGC standard? Well, no. Quite a large number of valid points have been raised: the name is bad, the existing reference implementation is commercial without available sources, ...

But I'd like to raise a different point: there are too many different services involved: the proposed standard comes in 8 different parts, all covering services which in my opinion unrelated. 

  12-054r2    GeoServices REST API - Part 1: Core
  12-055r2    GeoServices REST API - Part 2: Catalog
  12-056r2    GeoServices REST API - Part 3: Map Service
  12-057r2    GeoServices REST API - Part 4: Feature Service
  12-058r2    GeoServices REST API - Part 5: Geometry Service
  12-059r2    GeoServices REST API - Part 6: Image Service
  12-060r2    GeoServices REST API - Part 7: Geoprocessing Service
  12-061r2    GeoServices REST API - Part 8: Geocoding Service

This is the opposite of the unix philosophy: have one tool for the job. This is what in my opinion services should be about: have one service for every job, so one standard for every service. 

One tool for every job? Image source

I don't understand why a good feature service should also provide geocoding, maps or any other service. Yet these small tools will not be able to comply to the standard because they can provide only one service. 

So my proposal would be: break up the proposal. Check where new standards may be useful or where RESTFul implementations of existing services (and we already have a long list) are more appropriate. The services provided by ESRI prove that such an implementation really boosts productivity.

And actually while doing this, perhaps we should immediately consider using binary data where appropriate. I started off by saying that web services are finally being used. I did not mention WFS. This is logical. Nobody likes WFS. It is too slow. If WMS would contain an xml record for every pixels with an attribute for every color nobody would use it either. No, WMS sends a binary image. Why isn't  WFS doing the same and sending vector data in a binary form? 

Using Mapguide selection with OpenLayers

Using Mapguide selection with OpenLayers

Mapguide is a great solution for building web applications:  it has the best administrative interface of all open-source (and some commercial) web servers, it is very fast with vector data, it integrates nicely with AutoCAD Map 3D, ...

Even though I am very satisfied with the basic viewer, it does not play well on mobile devices. Creating a viewer using OpenLayers seems the way to go, and it is in fact the library used by the fusion viewer and AutoDesk's own mobile viewer.

Since I wanted my mobile viewer integrated with an existing application, I prefered rolling my own viewer based on OpenLayers: for integration with the rest of an existing webapplication I prefer a simple viewer rather than having all the bells and whistles of the fusion viewer.