Monthly Archives: October 2009

from #osgeo channel

Posted on by
7

A tiny discussion about climate change triggered by FOSS4G 2009 talks logged by seven on #osgeo IRC channel: 

[seven] The Earth's climate is changing.
[seven] Finally it seems like it is not a discussion any more.
[seven] We messed the world up and now?
[seven] We go fly to down under. Huh.
[mloskot] The Earth climate is a self-modifying code performing multi processing tasks, quite hard to debug
[seven] Debug earth's climate is easy: Remove humanity
[seven] says a dedicated Borg...
[mloskot] seven:  right, that sounds like a reasonable patch

Paul Ramsey keynote at FOSS4G 2009

Posted on by
Reply

This is video with Paul Ramsey keynote at the Free and Open Source Software For Geospatial (FOSS4G) conference in Sydney. It’s not a high quality video, but the content delivered by Paul is high-end, as always.

Thanks go to OpenGeo for delivering the videos.

Always use proper C++ integer types

Posted on by
2

When programming in C++, it’s a good idea to use proper integer types relevant to particular context. A little bit of strictness always pays back. It’s not uncommon to see a tendency to ignore the integral types defined as specific to standard containers, namely size_type. It’s available for number of standard container like std::string or std::vector. Such ignorance may get its revenge easily.

Below is a simple example of incorrectly used type to catch result of std::string::find function. I’m quite sure that many would expect there is nothing wrong with the unsigned int here. But, actually this is just a bug. I run Linux on 64-bit architecture and when I compile this program as is, it works as expected. However, when I replace the string in line [1] with abc, it still works but not as expected :-)

#include <iostream>
#include <string>
using namespace std;
int main()
{
  string s = "a:b:c"; // "abc" [1]
  char delim = ':';
  unsigned int pos = s.find(delim);
  if(string::npos != pos)
  {
    cout << delim << " found in " << s << endl;
  }
}

Fix is very simply. Just replace unsigned int with std::string::size_type. The problem could be avoided if somebody who wrote this program took care of use of correct type. Not to mention that the program would be portable straight away.

I’ve seen this kind of issues quite many times, especially in code written by former C programmers who do not like to wear the muzzle of strictness the C++ types system enforces and requires. The example above is a trivial one, but I believe it presents the root of the problem well.

It’s not acceptable to cut corners in the biscuits business, so why it should be acceptable in programming :-)

OSGeo Propaganda

Posted on by
4

The recent discussion on LinkedIn OGC forum about Advantages and disadvantages of Open Source GIS has reached at times hot temperatures. Good, as long as a discussion is factual. Unfortunately, the current one sometimes lacks of facts. Shawn Owston has started throwing heavy stones without, again, giving any facts or real examples:

One of the major “issues” with OSGeo in particular is the open and slanderous at times propoganda that is communicated regarding “commercial” companies regarding software quality, maintenance schedule and delivery of bug fixes to their constituent markets.

I agree with propaganda but I do not agree with slanderous propaganda. I have never seen anybody talking or writing on behalf of OSGeo who would be spreading defamation about anyone or anything in the industry or outside.

Shawn, it’s just not right. Please, drop the heavy stones away and pick the facts.

Boost will review Generic Geometry Library

Posted on by
2

Generic Geometry Library (GGL)Today afternoon, Barend Gehrels oficially submitted formal request of the Generic Geometry Library (GGL) to Boost C++ Libraries.

After a long journey through four previews and number of discussions, here and there on Boost mailing list and on GGL mailing list, and through the library presentation at BoostCon’08 and hard work on application of improvements to design and implementation contributed by previews reviewers and also by growing community of users, the Generic Geometry Library project finally has got his D-Day. Today official request has been posted to the Boost Community.

The design of the GGL library is stable. The library provides a variety of coherent functionality. Given that, the library has matured enough for formal review. Fair enough.

The Generic Geometry Library is considered as a general purpose library which is not bound to any specific domain. I believe this goal has been achieved very well. However, every use of a software library is a domain-specific use. Thus, next to built-in features, agnosticism (computing) and extensibility, an idea of GGL extensions has been defined. We* agreed that extensions should be supported in a very similar way to how the Generic Image Library (GIL) does it. So we are going to help to organize development of GGL extensions, where an extension is something more specific to domains, for example domain of GIS applications.

The review is put on the official Boost formal review schedule with Hartmut Kaiser as the review manager. Let’s get this party started:

Formal Review Request: Generic Geometry Library (GGL).

The Boost review itself is quite long, very detailed and fairly exhausting, for a library submitters, process. It feels like a kid standing still in front of a wall and other kids are bombarding him with snow balls. Having in memories process of Boost.Polygon library review I was witnessing a few weeks ago, GGL is going to take zillions of “snow balls” on the chin :-) Fingers crossed!

* I’ve joined the Generic Geometry Library project in April 2008 2009 and since then has tried contribute by evaluating, testing, fixing, porting, improving and extending to some small, hopefully useful, extent.