Thank you all for your comments --
Even:
* I think the build system is easy to do. The library does not have any
significant external dependencies so wrapping it into a circle of auto* was
not my top priority.
* I would of course be available to maintain the synchronization. If the
library/driver
Thank you Even,
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.
My main question is in how far the included co
Update:
The source code to FYBA is available at
http://bitbucket.org/relet/fyba
Some binaries for FYBA and ogr+sosi are also available in the releases
directory.
I would still strongly vouch for integrating with ogr, as third applications
like QuantumGIS or mapserver would depend on libraries
Dear all,
Re: http://trac.osgeo.org/gdal/ticket/3638
The current version of the SOSI driver depends on a library called FYBA.
This library is about to be made open source under a MIT/X licence. That
means, we could legally include it fully in the SOSI driver, and I would
like to start a discussio
Thanks Frank.
I have attached the current driver code to the ticket and added a short
explanation
http://trac.osgeo.org/gdal/ticket/3638#comment:1
I hope that works for you. In case there are any questions I'll be glad to
be of assistance to whomever wishes to review the driver, also by chat or
Dear all,
During the last month, we have developed an OGR driver for the Norwegian
SOSI standard[1]. It has reached a state[2] where it can be used to read and
use the basic features from SOSI files in OGR-enabled application like
mapserver. The standard itself is the national standard for repres
