Hi Andrea On Sun, Apr 7, 2013 at 5:53 PM, Andrea Aime <[email protected]> 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 ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
