Quickbook is a textual format, it feels quite similar to AsciiDoc or some sort of Wiki dialect but dedicated for documenting C++ programming. It is extremely easy to grasp while drinking a single short coffee.

Anyway, it seems it is going to be a quite a book after all elements of Boost.Geometry are documented. One of the challenge I’ve found is to collect all bits necessary to document C++ concepts defined by Boost.Geometry. Unfortunately, Doxygen is not an ideal tool for this purpose, so current version of the documentation lacks of some sections of concepts description. So, I have to dig the source code to find out formal definitions and details of valid expressions and semantics.

Another challenge related to concepts is to find best way to structure their documentation. I started to browse documentation of existing Boost libraries looking for examples and what I found is that there is no best example. Various libraries document concepts in very different way.

A concept is a set of requirements consisting of valid expressions, associated types, invariants, and complexity guarantees

– David Abrahams, Generic Programming Techniques

For example, neatly Boost.Fusion documents concepts with Quickbook, though some elements seem to be omitted. Boost.Graph doesn’t document with Quickbook, looks good, but some details are missing to me, for instance, titles in headers of tables saying what is what is return type and pre-/post-condition for valid expressions, etc. Documentation of Boost.IOStreams concepts sound well. On the other hand, Boost.GIL is an example of why Doxygen should not be used to document concepts of a C++ library.

It looks to me the old good Standard Template Library Programmer’s Guide at SGI is still a best and most complete example of how C++ concepts should be documented.

Given these experiences, I started to think of a way to improve the way concepts are documented within Boost. I believe it would be a good idea to have predefined block for concept in Quickbook. Something along these lines:

[concepttype [Point Concept]
  [this is a concept for 0-dimensional geometry]
  [notation
    [term 1] [description 1]
  ]
  [refinement [concept 1] [concept 2]]
  [associated
    [type 1] [description 1]
  ]
  [expressions
    [name 1 [expr 1]
      [type requirement 1] [return type 1]
  ]
  [semantics
    [name 1 [expr 1]
      [precondition 1] [semantic 1] [postcondition 1]
  ]
  [complexity [...]]
  [invariants
    [invariant 1] [description 1]
  ]
  [models [model 1] [model 2]]
  [notes
    [ note 1] [ note 1]
  ]
  [seealso ...]
]

I posted my proposal to boost-docs list explaining the motivation in details. It’s an interesting experience of a C++ documentation craftsman, anyway. (BTW, Daniel James just announced Quickbook port to Spirit 2.)

Boost.Geometry is accepted but with a sticky note attached with a list of issues that need to be solved before the library can be included in official Boost release. It means there is still plenty of work necessary to be done and as soon as they are done and confirmed, we’re in.

Hartmut Kaiser, the review manager, included compete and detailed list of all the issues that need to be addressed in the GGL review results report. Shortly, the contingencies are:

• Robustness: complete review of all elements of the library to assure it allows to instantiate all algorithms with arbitrary number types. By design, it is possible to specialise types and algorithms of Boost.Geometry with GMP or CLN, so it computes with arbitrary-precision arithmetic. This feature is possible thanks to numeric_adaptor developed by Bruno and Barend. Also, details of computational complexity per algorithms shall be updated.
• Concepts: during the review, a few problems have been revealed with adapting custom geometries for Boost.Geometry. The concepts are a moral backbone of the library, so they need to be sound making the adaptation process simpler as that’s what the whole idea of concepts in C++ is for.
• Boolean operations: robustness and coping with different coordinate orders of polygons should be improved.
• Documentation: currently only Doxygen-based documentation is available. This system does not work well for Boost, so migration to Quickbook system is to be done.
• Testing: simply, a collection of basic unit tests is not enough and verification of the correctness of the algorithms in a wide range of use cases is necessary along with high volume and random tests.

There are also a few minor issues specified as non-contingencies, however.

It is quite a list and plenty of work that needs to be done and Barend replied on the list:

We’re working on the library, I don’t hope it will take us that long, but 1.42 was not feasable at all. I hope 1.43 but even that is already coming soon.

Tasks dispatched. Fingers crossed.

Apparently, there are situations in which PostGIS could be an affordable anti-GML vaccine jab. It seems there is a potential market for PostGIS to conquer. Perhaps it wouldn’t be estimated as profitable as the H1N1 but who knows what will happen if no one takes a brave stand and stop GML designers! Here I’d eagerly conclude with one of the famous Scottish sentences :-)

Back to the subject matter. Today, I spotted an interesting question on the StackOverflow archives: Is it possible to export spatial data from Sql Server 2008 in gml2 format?. Natively? No, there is no such solution. Presumably, Microsoft thinks forward and thinks GML 2 is a legacy standard. Fair enough, someone has to draw a line between prehistoric and modern, somewhere. Why Microsoft? Again?

Facing such a tremendous suffer Microsoft exposed SQL Server users to, I suggested to visit the “underworld” for a while and hire PostGIS to do the dirty job.

Paraphrasing Andrei Alexan­dres­cu’s, hysterically famous recently, sentence: SQL Server should go!.

Tamas has been a contributor to GDAL and MapServer projects for years. He develops and maintains .NET/C# interfaces for both of the projects. He also is a member of the Project Steering Committee for GDAL project.

Welcome Tamas!

This is the first major new release since the 1.6.0 release approximately one year ago

This new version brings quite a nice collection of new drivers for raster and vector data formats:

• New Raster Drivers: BAG, EPSILON, Northwood/VerticalMapper, R, Rasterlite, SAGA GIS Binary, SRP (USRP/ASRP), EarthWatch .TIL, WKT Raster
• GDAL PCIDSK driver using the new PCIDSK SDK by default
• New Vector drivers : DXF, GeoRSS, GTM, PCIDSK and VFK
• New utilities: gdaldem, gdalbuildvrt now compiled by default
• Add support for Python 3.X. Compatibility with Python 2.X preserved
• Remove old-generation Python bindings
• Significantly improved raster drivers: GeoRaster, GeoTIFF, HFA, JPEG2000 JasPer, JPEG2000 Kakadu, NITF
• Significantly improved vector drivers: CSV, KML, SQLite/SpataiLite, VRT

After lurking and kicking my own axons, it’s time to nudge stackoverflowers with my first question. Here we go:

Which macro to wrap Mac OS X specific code in C/C++

hackers are exploiting a weakness in the Mozilla Firefox browser to wreak havoc on Freenode and other networks that cater to users of internet relay chat.

Here is the whole story Firefox-based attack wreaks havoc on IRC users posted to The Register

Mr Dan Goodin, I would wish you don’t cultivate the mainstream media alignment regarding the use of word hacker. Don’t call a hacker someone who has unlawful intentions, please.

Kitware launched its first developer blog today with contributions from Company technical and business leaders.

The CMake build system is one of the main category of topics on the Kitware blog, so I presume it may be of interest of OSGeo Community as the CMake build system is slowly winning over more and more folks here :-)

First CMake-related post is about Deploying on Windows with DLL Manifest Issue

Another interesting post on the blog is Will Schroeder’s answer to the question Why Open Source Will Rule Scientific Computing? It’s really worth reading.