Wow - thanks for this Andrea. Lots of good and interesting stuff here. The Bridj and JNAerator tools look extremely useful. I've got some C / C++ code from long ago, and also native libraries that come with R packages, that I'd love to try hooking up to Java. It always seemed too complicated to bother with before.
I hope to try using the OGR data store soon to attack a large archive of arc/info binary coverages (more relics from long, long ago). Michael On 31 October 2011 01:57, Andrea Aime <[email protected]> wrote: > Hi all, > those who follow the commits mailing list have probably noticed me hacking > around the OGR data store in unsupported land in the last few weekends. > > This time I dropped the OGR own JNI library, which has the pretty obnoxious > requirement to have to be built for each an every platform, but also pretty > much always missing in pre-made binary builds. > > Instead the store this time is based on Bridj > (http://code.google.com/p/bridj/), > a library that allows to perform calls into native code without having > to compile > anything on the native side, just requires a class with methods with > the "native" > annotation and a few extra directives, most of which can be generated once > and for all from the .h files using JNAerator > (http://code.google.com/p/jnaerator/), > a tool that parses the .h file and generates the corresponding java class. > > The resulting code feels a little odd, in that the native parts are pretty > much > evident by the usage of Bridj Pointer class, but the result is > fantastic, I developed > the code against GDAL/OGR 1.8 on Linux 64 bit, then tested it against 1.7, > worked, tested against FWTools/OGR 1.7b2 on Windows 32 bit and again it > worked > (after I amended some usage of recent 1.8 API that was not availale in > older builds). > > So, if you plan to bind to some native lib and want to avoid JNI and > SWIG headaches > I encourage you to try out Bridj/JNAerator, they both worked fine for me and > the few hiccups were promptly dealt with by the dev of both tools > (Olivier Chafik). > > Also tested it briefly with GeoServer, WMS performance is pretty much on par > with the shapefile data store, whilst WFS shows a tangible difference > (30% slower) > but still pretty good for a library that never had ultimate > performance as its goal > (both mapserver and qgis use their own custom sources for the most common > data types, falling back on OGR when some oddball data source is required). > > Code wise the store has been rewritten using the ContentDataStore framework, > the > code is clean enough and decently tested, code coverage is floating > well above 70%. > For stores that support random writes the OGR wrapper will also provide write > support. > > Looking to the future I hope to have it tested quite a bit more before pushing > it into supported land, since a single hiccup in the native lib interfaces > will > make the JVM segfault. > > It would be interesting to hear from OSX folks, whether it works for > them or not. > The code will search for the native lib automatically, if it's not > found there are > two system variables you can set: > -Djava.library.path="C:\Program Files\FWTools2.4.7\bin" > -DGDAL_LIBRARY_NAME=gdalOddVersion > The first sets the native library search path, the second is necessary if GDAL > library name is not "gdal", "gdal_fw" or "gdalx.y.z" > (if you are wondering why GDAL and not OGR, it's because OGR is always > built into the GDAL library, it's not available stand alone). > > The library also has some tricks that we could learn from. > > The first one is this sort of limited write mode, that allows write only if > you > are writing out the file for the first time. Basically no random write, but > just one shot output. > This is a mode that can be used to write out GML/KML files, but once > created it is not possible to reopen them in write mode. > To support this mode I added a > createSchema(FeatureCollection) > method. > Actually this method strikes me like a good idea also for other reasons, > in particular for mass data copies. Such method allows the datastore to: > a) handle attribute transformations > b) optimize bulk transfers > Attribute transformations are often unavoidable: shapefiles will handle > just one geometry, as the first attribute and call it "the_geom", Oracle > datastore will uppercase all attributes, and so on. > With the above method the store can do the bulk copy handling its > own oddities. > Bulk transfer wise, stores could use the above to use some more efficient > method of copying overt the data, writing directly to the destination > file, or using database "COPY" statements to copy the data over without > having to deal with transactions and concurrency. > > Another thing that's interesting in OGR is the support for per feature styling > information: this adds support for data sources that natively mix features > and styling, such as KML, Mapinfo, DWG/DXF. > I did not go there, but one day we could indeed support one ore more > Symbolizer objects attached as user data to features and have the > renderer paint them when a NativeSymbolizer is used, which prompts > the renderer to look into these feature attached styles and use them > to paint stuff. > > All right, all right, enough ranting, congrats if you made it to the end > of the mail and I hope the OGR store will be of use for you as well :-) > > Cheers > Andrea > > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
