[gdal-dev] Re: OGR Driver for Norwegian SOSI standard

Even Rouault even.rouault at mines-paris.org
Thu Nov 17 09:28:19 EST 2011


> I would want to try and go for the second option.
> My motivation is mainly that a majority of users will be using packaged
> software like osgeo4w or qgis - if SOSI support is enabled by default, it
> would be available in these packages.

Yes that's understandable. That goal could be achieved with option 1) though,
but that would require proper packaging of FYBA as a standalone library. From
what I've seen, its build system is currently a bit simplistic ;-)

> My main question is in how far the included code has to follow RFC 8. It
> would be quite a task to make it follow the gdal-Hungarian prefix dialect,
> or even to translate variables and method names to plain English.

Those requirements apply certainly for the core of GDAL, but they can be relaxed
for drivers. I also don't believe that it would be reasonable to ask for
rewriting all variable names and translating them.

> I think the sandbox is a good approach. I understand the terms of RFC 3 and
> RFC 8, but I'm not too familiar with the sum of community guidelines around
> gdal. I hope not to remain the only maintainer, but in order to achieve
> that, the driver has to become more available and create a user/developer
> base.
> (The users exist, but they are currently used to convert SOSI to Shape files
> using commercial tools before further processing, losing most of the
> metadata that is available in the original format.)

Well, that's the key point. I'm not that worried by integrating the code : it
should not be too hard to integrate it into GDAL build system, if it already
compiles under Linux and Windows.

I think we might be open to host the FYBA code but being not easily maintanable
by most GDAL core developers, we would need to be sure of some commitment of you
or other people to help maintening it in the future, and managing its
synchronisation with the upstream git FYBA code. It's not good to have a huge
code dump without the associated maintenance for it...


More information about the gdal-dev mailing list