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
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
