Hi Andrea
On Sun, Apr 7, 2013 at 5:53 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:
A couple of years ago I wrote a working OGR data store in GeoTools:
https://github.com/geotools/geotools/tree/master/modules/unsupported/ogr
nice, didn't realize this
Unfortunately the module failed to gain any traction, there are a number of
difficulties:
* It's completely impossible to predict whether the module will compile and
pass unit
tests against a random system, since we don't know what version of OGR is
around
(too new? too old?), this prevented it so far from entering the official
build
Maybe it would be useful to stick to the latest GDAL stable release.
Or maybe, should it be possible that each user would compile it using
its GDAL version as it is done for other software using GDAL
(MapServer, QGIS etc)?
(not sure about Java downsides about this)
* Since I wrote it, I had exactly zero use of it. As much as people rave for
OGR capabilities,
large production sites don't use the formats that OGR supports, and stick
to spatial databases
instead, meaning there is no commercial interest in it. In turns, this
means the module
maintainership cannot be done during working hours.
True, but this would open to GeoServer to a plethora of formats such
as csv, CouchDB, GFT, OSM and others, plus the ability to query RDBMS
not having direct geometric information through virtual formats.
* Native libraries in generally are not welcomed in Java production sites,
because a small
glitch in them under sustained use that makes them segfault brings down
the entire
java process. It does not help that heavy users of OGR are short lived
programs
(cgi or fastcgi restarted every 1000 requests), desktop applications, and
in general,
programs that have no multithreading (now GDAL has a setup that allows to
keep
certain formats running in separate processes, which would address this,
I'd be happy
to add support for it if there is anybody interested in sponsoring the
work).
I see the point, and that it is in fact what I thought it is the major
concern against using GDAL straight in Java.
That said, I guess I could make an extra effort to make the module available
for nightly
downloads in the community section:
http://gridlock.opengeo.org/geoserver/2.3.x/community-latest/
Is there anyone that would be interested in having it? No promises it will
be maintained,
no promises it works at all (haven't used it in 2 years).
But the source code is there, if there is someone that wants to move from
chit-chat
to action (as in, try to maintain it), I'm ready to help get them started.
I would be interested 
thanks a lot
p
--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti