+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.
Larry
On Tue, Aug 9, 2011 at 11:06 PM, Martin Davis 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 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 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
