On Tue, Nov 1, 2011 at 11:07 AM, Michael Bedward <[email protected]> wrote: > 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).
Ah coverages. OGR store reads vector data. But you can read binary grids using gt-imageio-ext-gdal AIGReader class. The thing is, you'll need to install imageio-ext specific gdal version, which is a 1.7.x one. If things go well with the OGR store and the stability and performance overhead of Bridj provides to be acceptable we might push to migrate imageio-ext to use Bridj instead of SWIG/JNI, that would make dealing with the native part a lot easier (install wise I mean, just use whatever is available on the system instead of having to roll our own binaries. Cheers Andrea > 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 >> > > -- ------------------------------------------------------- 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 ------------------------------------------------------- ------------------------------------------------------------------------------ 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
