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
