Hi all, Thanks for the very interesting inputs about FGDB.
I've not been working with ESRI products for a while and it's difficult for me to evaluate the future of the format and the need to have it in OpenJUMP. What I can more easily say is : - undertaking to develop a driver (I/O) on our own does not seem reasonnable (at least for me ;-)). - trying to work with GeoTools project seems to be the best choice (100% java, maybe more than drivers to be shared with GT). Ede has already a good experience in integrating GeoTools drivers to OJ. I'm still concern by adding dependencies we don't need. - trying to integrate ogr2ogr : second choice. I think we should avoid non java api if there is an alternative in java. On the other hand, I like the user-friendly tool that Larry did to use ogr2ogr from java, and I would be very pleased if this tool could access last version of ogr2ogr, proj4 ;-) My 2 cents, Michaël Le 11/08/2011 13:26, Matthias Scholz a écrit : > Hi! >> +1 vote to support file geodatabase as a geotools dataset (if ede can >> provide a geotools dataset adapter). >> >> I volunteer to add or improve write capability. I have a little time >> to contribute in the next couple of weeks. I have ArcMap available to >> test compatibility. >> >> I don't have experience with JNI or JNA, but I need to learn. JNA >> sounds like the way to go if it really works. > If we have the needs to use some native code, we should take a look at > http://www.swig.org. Here you need nearly no knowledge about JNI. With > that I've implemented the use of a C++ library for DXF reading. JNI or > JNA was me to complex and too much boilerplate code. > > Matthias >> Larry >> >> On Tue, Aug 9, 2011 at 11:06 PM, Martin Davis<mtncl...@telus.net >> <mailto:mtncl...@telus.net>> wrote: >> >> Translation has various problems, such as: >> - a cumbersome step before being able to access data >> - limitations of the shapefile format (which I presume you would >> have to target for output): e.g. 2 GB limit, dumb column names, >> limited types, etc >> - more storage requirements >> >> Don't get me wrong - I'm not saying that Read-Write to FGDB is not >> needed. I'm just saying that having Read capability would still >> provide value. >> >> M >> >> On 8/9/2011 7:27 AM, Larry Becker wrote: >>> Hi Martin, >>> >>> >>> Disagreed. ... >>> >>> >>> >>> Another way to think of this - what better way to to suck the >>> life out of a proprietary format than to make a one-way >>> gateway into an open solution? (This is a tried-and-true >>> ploy of proprietary platforms...) >>> >>> >>> I see your point, but if I needed a one way translator, I would >>> just use OGR2OGR,<shameless self-promotion> preferably with the >>> iGOR interface (after I update it to support FGDB).</shameless >>> self-promotion> >>> >>> I'm also in the position of needing to do advanced editing on >>> data that is maintained in ESRI format. So far it is just >>> shapefiles, but the popularity of file geodatabases is >>> increasing. I can't give the customer data back in a different >>> format, especially one that can't handle the data size or field >>> names. I need to be able to edit /along side of /the ESRI >>> solution, especially in an ArcGIS Engine runtime environment that >>> doesn't have all of the regular tools. >>> >>> regards, >>> >>> Larry >>> >>> On Mon, Aug 8, 2011 at 8:08 PM, Martin Davis<mtncl...@telus.net >>> <mailto:mtncl...@telus.net>> wrote: >>> >>> >>> >>> On 8/8/2011 10:33 AM, Larry Becker wrote: >>>> It looks like there could be cooperation between the two >>>> groups on the development of the Java interface at least. >>> Cooperation with GeoTools seems like a reasonable way to go. >>> >>>> The ogr support approach would not seem to provide any >>>> advantage beyond translating FGDB to shapefiles as SkyJUMP >>>> uses that library for mdb translation now. There may be >>>> Java bindings for the low level API in OGR that I'm not >>>> aware of, but this would be a level removed from the actual >>>> API we want to use. >>> Agreed. It's bad enough having to include the C libs needed >>> for access to non-Java APIs, but including a bunch of OGR >>> libs as well just compounds the problem. >>> >>> Also, from a development point-of-view if there are issues >>> that makes two places which need to be looked at and updated >>> - and if the problem is in OGR then OJ is hostage to OGR's >>> schedule. >>> >>>> The only way this would be any use in JUMP (IMHO) is if we >>>> could open and edit FGDBs like ArcMap does. We discussed >>>> the idea of supporting the Access personal geodatabase years >>>> ago, but abandoned the idea because it was too risky because >>>> it was proprietary and had no published API. >>> Disagreed. Providing Read-Only access to FGDB is still very >>> useful, since it provides a gateway into OJ for ESRI users. >>> And there is lots of functionality which is difficult to >>> accomplish in ESRI tools which is easy in OJ (and other Java >>> solutions like JEQL). I'm now in the unenviable position of >>> working with ESRI tools on a daily basis, and by the biggest >>> stumbling block to trying to introduce OJ into my environment >>> is the inability to read the (sometimes huge) FGDBs that we use. >>> >>> Another way to think of this - what better way to to suck the >>> life out of a proprietary format than to make a one-way >>> gateway into an open solution? (This is a tried-and-true >>> ploy of proprietary platforms...) >>> >>> I'm not even sure that the ESRI FGDB API supports writing.. >>> or at least, not without a lot of caveats. >>> >>>> As far as the ESRI license, it would put us in the same >>>> position as having the end user download the MRSID >>>> executable. Not good, but doable. >>>> >>>> On the minus side, by supporting the proprietary FGDB >>>> format, we might be using effort that could be better >>>> applied to open source solutions. >>> See comment above about providing a gateway... >>>> What are the viable open source alternatives? Spatial Lite >>>> seems to have a C API as well. >>> SpatialLite support would be useful too, but I don't think >>> it's going to replace FGDB in the wider world anytime soon >>> (unfortunately). >>>> just a few thoughts, >>>> >>>> Larry >>>> >>>> >>>> >>>> >>>> On Mon, Aug 8, 2011 at 10:22 AM,<edgar.sol...@web.de >>>> <mailto:edgar.sol...@web.de>> wrote: >>>> >>>> Obviously there is interest in geotools to add a gt2 >>>> datastore for it. Also cite: >>>> >>>> >Justin Deoliveira: Just a note that fgdb support was >>>> recently added to ogr as a format... so using the >>>> existing ogr datastore (and its java bindings for ogr) >>>> could be an easier route to go. However it requires ogr >>>> >= 1.9.0. >>>> >>>> In any way we should (re)implement a geotools >>>> reader/writer extension or pimp my old GT2 reader/writer >>>> to work with the latest oj. >>>> >>>> ede >>>> >>>> >>>> On 08.08.2011 17:07, Sunburned Surveyor wrote: >>>> > It looks like there is some interest and opportunity >>>> for collaboration >>>> > with the GeoTools team on FGDB support. You can see >>>> the thread I >>>> > started on their development mailing list here: >>>> > >>>> > >>>> >>>> http://osgeo-org.1803224.n2.nabble.com/FGDB-Support-in-GeoTools-td6662165.html >>>> > >>>> > I'm already way over committed, so I can't take the >>>> lead on this >>>> > effort, but I hope we can work together with the >>>> GeoTools people if >>>> > there is a desire and resources for work on a FGDB >>>> library. >>>> > >>>> > Landon >>>> > >>>> > On Sun, Aug 7, 2011 at 10:44 AM, Sunburned Surveyor >>>> > <sunburned.surve...@gmail.com >>>> <mailto:sunburned.surve...@gmail.com>> wrote: >>>> >> If we did decide to explore FGDB support for >>>> OpenJUMP, I'd recommend >>>> >> we collaborate with GeoTools on the lower-level code. >>>> I can post there >>>> >> to see if there is anything going on in this area and >>>> will get back to >>>> >> the list. >>>> >> >>>> >> Landon >>>> >> >>>> >> On Thu, Aug 4, 2011 at 2:25 AM,<edgar.sol...@web.de >>>> <mailto:edgar.sol...@web.de>> wrote: >>>> >>> Thanks for the overview on this.. ede >>>> >>> >>>> >>> On 04.08.2011 01:28, Martin Davis wrote: >>>> >>>> Yes, they are definitely positioning FGDBs as the >>>> replacement for shapefiles - at least in their world. >>>> FGDB has a lot of advantages for them - no limit on >>>> file size, able to contain all of the weird and >>>> wonderful ESRI data structures, and >>>> platform-independent. Oh, and no 11-char limit on field >>>> names!!! >>>> >>>> >>>> >>>> <philosophy> >>>> >>>> Personally I can't see it replacing the role that >>>> Shapefiles play in the wider geospatial world - that is, >>>> a (fairly( open, easily-accessible, documented spatial >>>> data format. The FGDB format is closed and proprietary >>>> - only the API is somewhat open. And it's written in C, >>>> which limits its use in some situations. Also, the FGDB >>>> format is very complex, and completely tailored to >>>> support ESRI's needs, rather than a more general set of >>>> needs. >>>> >>>> >>>> >>>> It would be GREAT to have a truly open geospatial >>>> format, which was essentially a shapefile for the 21st >>>> century. GML is NOT that format... so the field lies open >>>> >>>> </philosophy> >>>> >>>> >>>> >>>> It would be great to have a solution for accessing >>>> FGDBs from Java (OpenJUMP of course, but I'd also like >>>> to be able to read them from JEQL). If OJ could read >>>> them that should make it quite appealing for working >>>> with newer ESRI data. >>>> >>>> >>>> >>>> One possiblity is this work on a Java interface to >>>> the FGDB API. If this project has taken care of all the >>>> JNI nastiness, then it could be worth using. >>>> >>>> >>>> >>>> http://sourceforge.net/projects/jfilegdbexplore/ >>>> <http://sourceforge.net/projects/jfilegdbexplore/> >>>> >>>> >>>> >>>> I know that the GDAL project is working on adding a >>>> driver for the FGDB API. This is in C, of course, so >>>> not directly usable by OJ. >>>> >>>> >>>> >>>> Martin >>>> >>>> >>>> >>>> On 8/3/2011 8:27 AM, Larry Becker wrote: >>>> >>>>> It would seem that ESRI is positioning the "file >>>> geodatabase" as the heir to the shapefile. They now >>>> have a cross-platform API that provides access without >>>> ArcObjects. >>>> >>>>> >>>> >>>>> >>>> >>>> http://forums.arcgis.com/threads/31841-Welcome-to-the-discussion-forum-for-the-File-Geodatabase-API! >>>> >>>>> >>>> >>>>> Is this something the JUMP community should look >>>> into supporting? >>>> >>>>> >>>> >>>>> Larry >>>> >>>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>> BlackBerry® DevCon Americas, Oct. 18-20, San >>>> Francisco, CA >>>> >>> The must-attend event for mobile developers. Connect >>>> with experts. >>>> >>> Get tools for creating Super Apps. See the latest >>>> technologies. >>>> >>> Sessions, hands-on labs, demos& much more. Register >>>> early& save! >>>> >>> http://p.sf.net/sfu/rim-blackberry-1 >>>> >>> _______________________________________________ >>>> >>> Jump-pilot-devel mailing list >>>> >>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>> >>>> >> >>>> > >>>> > >>>> >>>> ------------------------------------------------------------------------------ >>>> > BlackBerry® DevCon Americas, Oct. 18-20, San >>>> Francisco, CA >>>> > The must-attend event for mobile developers. Connect >>>> with experts. >>>> > Get tools for creating Super Apps. See the latest >>>> technologies. >>>> > Sessions, hands-on labs, demos& much more. Register >>>> early& save! >>>> > http://p.sf.net/sfu/rim-blackberry-1 >>>> > _______________________________________________ >>>> > Jump-pilot-devel mailing list >>>> > Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> > >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> BlackBerry® DevCon Americas, Oct. 18-20, San >>>> Francisco, CA >>>> The must-attend event for mobile developers. Connect >>>> with experts. >>>> Get tools for creating Super Apps. See the latest >>>> technologies. >>>> Sessions, hands-on labs, demos& much more. Register >>>> early& save! >>>> http://p.sf.net/sfu/rim-blackberry-1 >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >>>> The must-attend event for mobile developers. Connect with experts. >>>> Get tools for creating Super Apps. See the latest technologies. >>>> Sessions, hands-on labs, demos& much more. Register early& save! >>>> http://p.sf.net/sfu/rim-blackberry-1 >>>> >>>> >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> >>>> Jump-pilot-devel@lists.sourceforge.net<mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>>> >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com<http://www.avg.com> >>>> Version: 10.0.1391 / Virus Database: 1520/3821 - Release >>>> Date: 08/08/11 >>> >>> ------------------------------------------------------------------------------ >>> uberSVN's rich system and user administration capabilities >>> and model >>> configuration take the hassle out of deploying and managing >>> Subversion and >>> the tools developers use with it. Learn more about uberSVN >>> and get a free >>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>> >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> uberSVN's rich system and user administration capabilities and model >>> configuration take the hassle out of deploying and managing Subversion >>> and >>> the tools developers use with it. Learn more about uberSVN and get a >>> free >>> download at: http://p.sf.net/sfu/wandisco-dev2dev >>> >>> >>> >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> >>> Jump-pilot-devel@lists.sourceforge.net<mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> No virus found in this message. >>> Checked by AVG - www.avg.com<http://www.avg.com> >>> Version: 10.0.1391 / Virus Database: 1520/3822 - Release Date: >>> 08/08/11 >> >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing >> Subversion and >> the tools developers use with it. Learn more about uberSVN and get >> a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> <mailto:Jump-pilot-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> uberSVN's rich system and user administration capabilities and model >> configuration take the hassle out of deploying and managing Subversion and >> the tools developers use with it. Learn more about uberSVN and get a free >> download at: http://p.sf.net/sfu/wandisco-dev2dev >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
