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
