Jody Garnett's Blog: January 2006 Archive

Recently there has been a lot of press about MapServer, everything from MapServer Junior to the formation of a Foundation. Welcome to the other team, the Java team, and here is what GeoServer does so well - WFS-T.

For those new to the Open Geospatial Consortium standards scene there are a couple of levels of "compiliancy".

WFS Compliant - Supports GetCapabilities, GetFeatures, DescribeFeatureType
WFS-T Compliant - Supports Transaction (aka allows you to modify information)

There are a couple of leftover things, like LockFeature and GetFeatureWithLock - they don't get their abbrevation. Rest assured, GeoServer does those as well.

MapServer gets Ugly

One thing that both GeoServer and MapServer products share is a fair bit of "ugly". MapServer starts with an advantage in this regard, as it is hard for us to compete with pointers.

We have had occasion to look at the MapServer codebase, for label positioning code I think, at the time we were relieved. It was an intricate, ornate construction, where the slightest tweak would have far flung consequences. What MapServer Classic (I mean Cheeta) has going for it is the open source advantage, it has been deployed, and tweaked, so often that it shines. Shines in this case means speed.

The only way to really clean it up would be to start again from the same building blocks, something we did not think they would do unless a major sponsor came around. Enter AutoDesk ...

I suppose that means we will need to work for a living ...

GeoServer gets Ugly

Okay I will fess up, the following code is 98% my fault. At this point I will pass the keyboard over to Richard Gould as he intro's the 800 line function of Doom.

Richad Gould writes:
In January of 2004 Jody and I were working on the Validation Web Feature Service aspect of GeoServer. More specifically Jody was working on that, and I was working on GeoServer's web configuration interface. The day before the project was due, Jody asks me for help. After two weeks of failed debugging, Jody decided we should re-write the WFS transaction code. Let me first say that before starting this work on GeoServer, I had never even heard of GIS before. I didn't even really understand what a Feature was. So for the next 17.5 hours, reaching until 5:30 am, I ran around absolutely clueless of the big (or even small) picture. Somehow, under the guidance of Jody, we came up with the biggest method of Java I have ever seen, and it worked. These 800 lines of code almost made Chris Holmes give up on open source! I have not touched the code since, but I fear it is still running about like some titanic bull.

I can't ask for a better intro then that ... thanks Richard the truth is supposed to hurt right?

Transaction - The Method Behind the Madness

Yes there actually was a plan, it involved introducing test cases to the codebase so we could tell when we were done. Up until this time GeoServer sufficed on a diet of Cite tests which only Chris Holmes managed to reliably run. Fixes involved poking the code, and then pinging an external test suite (called Cite) and asking it to perform 400 odd tests. Wash, rinse, repeat.

Oh and the method name is TransactionResponse what does it do? Well it kinds of does everything, it is the only method in the WFS patagon that changes anything.

But lets start with what a WFS Transaction is supposed to process...here is an outline of a Transaction Request:

<?xmlversion="1.0"?>
<wfs:Transaction version="1.0.0" service="WFS" ....>
  <LockId>00A01</LockId>
  <wfs:Insert>
     ...GML...
  </wfs:Insert>
  <wfs:Update typeName="myns:OCEANSA_1M">
    <wfs:Property>
       <wfs:Name>myns:DEPTH</wfs:Name>
       <wfs:Value>2400</wfs:Value>
    </wfs:Property>
    <ogc:Filter>
      <ogc:PropertyIsGreaterThan>
        <ogc:PropertyName>OCEANSA_1M.DEPTH</ogc:PropertyName>
        <ogc:Literal>2400</ogc:Literal>
      </ogc:PropertyIsGreaterThan>
    </ogc:Filter>
  </wfs:Update>
  <wfs:DeletetypeName="INWATERA_1M">
    <ogc:Filter><ogc:FeatureIdfid="INWATERA_1M.1013"/></ogc:Filter>
  </wfs:Delete>
</wfs:Transaction>

From this we can see a number of interesting details:

Insert
Delete
Update
Locking/Unlocking

In response to this we need to return a TransactionResponse document, that the "Feature ID" of any features added ... and how successful we were. Yes that sounds messed up, we could be SUCCESS, FAILURE, or PARTIAL at the end of the day. I am sure PARTIAL is just a quick hack, not sure why the standards body thought this one up, we went to a lot of trouble not to support this feature.

As long as we are going to trouble, we had some more features to consider:

Writability of DataSources
Restrictions on each of the kinds of operations
Validation

You may note that the last entry, Validation, was the purpose of the Validating Web Feature Server Project we were working on - so we had a vested interest in getting this method to work. Validation is grouped into two areas of applicability:

Feature Validation - per feature tests, can be applied before an insert, or after an update
Integrity Validation - tests that take in the big picture, checked before commiting all the changes off to the data sources

That is it, what we need to do, now for how we did it.

Happy New Year

Posted by jive on January 01, 2006 at 12:43 PM | Permalink | Comments (1)

Happy New Year!

This has been an amazing time for the open source Java community, and I thank all of you for making the last year an amazing experience.

I have never traveled so much, or met so many amazing people.

I wish all of you the best in the new year!

Powered by
Movable Type 3.01D

java.net RSS Feeds