Tag Archives: open source

Update on SqlGeometry and POINT EMPTY in WKB

Posted on by
Reply

Long time ago I discussed about how SqlGeometry handles POINT EMPTY in WKB format. The SqlGeometry states the definition of OGC GEOMETRY type for Microsoft SQL Server. Shortly, the message was that SqlGeometry implicitly casts POINT EMPTY to MULTIPOINT EMPTY geometry when generating WKB output. PostGIS casts as well, but does it in a consistent way, in my opinion, outputting GEOMETRYCOLLECTION.

Following those findings, I assumed it is not quite correct, or I didn’t like the inconsistency, and I had reported it to Microsoft Connect as a bug: SqlGeometry reports invalid type of WKB of POINT EMPTY.

Recently, I have received a couple of comments from Microsoft to my report. The comments are attached to the report linked above, but I paste them below for completeness and archive:

Our development team for the spatial data types tells me that it is not possible to use a single value for the WKB format of any spatial data type. For the POINT EMPTY, the WKB format does not allow empty points, so we are outputting a MULTIPOINT with zero elements.
In a MULTIPOINT EMPTY, we are stripping out empty points.

The reasoning is technically correct. It’s just Microsoft does it differently. However, as second comment suggests, the current behaviour may change in future:

But we might consider changing it to get consistent behavior.

Preparing for Subversion to Git migration

Posted on by
5

GEOS is slowly moving to Git, so I decided to clear the Subversion specific settings, namely the svn:keywords. The procedure is quick and based on the commands I used to perform bulk svn:keywords property update.

First, svn:keywords property is removed:

find . -path '*/.svn' -prune -o -type f -print  | xargs svn propdel -q svn:keywords

Next, line consisting of $Id$ keyword is stripped from every plain text file using a tiny script coded in Python:


#! /usr/bin/env python
import fileinput
import re
import sys

def strip_line(filename, rx):
    sys.stderr.write(filename + '\n')
    for line in fileinput.input(filename, inplace=1):
        m = re.match(rx, line)
        if m is None:
            sys.stdout.write(line)
        else:
            sys.stderr.write(line)

if len(sys.argv) < 2:
    sys.exit("Missing filename")

pattern = '^.*\$Id.*$'
rx = re.compile(pattern, re.DOTALL)
strip_line(sys.argv[1], rx)

The script is executed for every file, excluding the working copy admin area in .svn:

for f in `find . -path '*/.svn' -prune -o -type f -print`; do ~/bin/strip_line_regex.py $f; done;

Voila!

Update: Torvalds answers Does GIT has vc keywords like CVS/Subversion?

AX_LIB_LIBKML macro

Posted on by
1

Recently, I was playing for a while with Brian‘s new OGR LIBKML driver and I integrated it with GDAL/OGR build system, so it’s more convenient to build, test and use it. The complete tree is available in GDAL sandbox in mloskot/winkey-libkml. (It is just a give it a try-like prototype and I don’t actively maintain this branch myself. Hopefully, Brian will take it over.)

By the way, I crafted AX_LIB_LIBKML macro for Autoconf. This macros checks for headers and libraries of specified version (or newer) of Google libkml library and defines compilation and linking flags.

I submitted the macro to GNU Autoconf Archive. It is the new incarnation of well-known autoconf-archive.cryp.to. Peter Simons announced not long time ago that

The archive has moved to Savannah: http://www.nongnu.org/autoconf-archive/. Version 2009-04-26 was the last to be released at autoconf-archive.cryp.to.

Happy detecting libkml!

Const-correctness schizophrenia in GDAL

Posted on by
1

Const-correctness rants are quite common topic of chats on #gdal IRC channel. Some of the pearls I’ve got printed in to my mind:

A: The lesson is I ought to get things right the first time.
B: The issue with const method is that if you want to add lazy loading later, it can cause problems
C: GDAL is rather painful to use with const correct code, unfortunately :(
B: The solution is obvious: don’t write const correct code

Who’s right then, A or B?

I recall another motto from #gdal channel that sounds like “when unsure, do nothing” which has the following rationale:

especially when I realize afterwards that I’ve f**cked things because I neglected to follow the motto

Remembering these recommendations, it’s pretty clear why the const-mess in GDAL has happened. I’d conclude paraphrasing the motto this way:

I’ve f**cked things because I neglected to make a decision.

Now, poor GDAL beginner deadpickle, trying to find out (it’s me the evil) why compiler complains about his not-that-bad-written code, wandered to find and ask C gurus @ comp.lang.c and got the problem explained by Malcolm who wrote:

The problem is that, when C was first developed, there was no const keyword. So strings literal, which are constant, had to be non-const for backwards compatibility. This means that lots of programmers get lazy and omit the const, even from functions which don’t modify their string arguments. (There are also some subtle problems with const which means that this isn’t always a case of pure laziness). So a sort of solution is to discard the const qualifiers. However this is perpetuating the problem in your own code.

The motto stays in contradiction to a well-known best practice of const correct sooner than later. It’s way easier and cheaper to remove const-correctness once it turns out it does not express properly the actual design and contract than to apply it to existing codebase. Sometimes, the latter is even not possible making things f**cked up twice, in existing code base and in client’s code.

Using Git with GDAL repository

Posted on by
2

I have mirrored Subversion trunk of GDAL repository on Gitorious – a free hosting for collaborating on distributed open source projects. It is available as svn-trunk repository of gdal project.

The main motivation is that it simplifies development of experiments in case one needs version control or complete disconnection from SVN trunk for some period. Thanks to git-svn, it is possible to push changes back to the trunk.

I outlined the process of maintaining GDAL trunk using Git in the Wiki article Using Git To Maintain GDAL Workflow.

The synchronization is not a time consuming process at all but even that I hope to make it automatic process in near future. First, I have to ship my little personal server to a remote data centre and I’m hoping to do it next week. Lucky bastard going to bask in the warm sun of Portugal :-)

GDAL/OGR 1.7.0 Released

Posted on by
Reply

GDAL logoFrank has just posted announcement about freshly released GDAL/OGR 1.7.0:

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