While I was prevented from attending the recent code sprint in Toronto due to a large rock, Jody and I decided to use the excuse to sprint along in our time zone.
I had spent some time working on issues with PostGIS' support for curved geometries and was able to commit the fixes prior to the sprint. I had focused on the well known text (wkt) representations and parsing, simply because it's easier to fake up some data in a text format. This meant that the SQL-MM defined well known binary (wkb) was still unsupported. I spent much of my time sorting this out. It is in need of further test cases, but most of the heavy lifting is now done.
Jody took on a much more satisfying challenge, which was to connect uDig to my development PostGIS instance and actually render out a curved geometry. With time short, we took the approach of parsing the wkt and converting it into a linear approximation of the geometry using the segmentisation code I wrote for PostGIS back in the day. We had a great time porting the C code into Java, with Jody taking every opportunity to expound on the virtues of garbage collection and slagging C. For my part, I was happy to have another set of eyes on my code and once again rediscovered the virtues of clear comments, if only they would be read.
The end result, after two evenings work, is the following image. On the left is the geometry I drew using OpenJump to provide sensible points from which to derive a curved geometry. On the right is the uDig representation. It's curvy!
While this is not the end of the work required, it's a good start and paints a pretty picture.
Subscribe to:
Post Comments (Atom)
1 comment:
To be fair I poke fun at Java as well; how many classes can you split functionality across? Usually so many that a debugger is the only way to understand the flow of control.
This work is now committed to GeoTools trunk.
Post a Comment