Re: [JPP-Devel] ESRI file geodatabases

[Larry Becker]

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,  preferably with the iGOR interface
(after I update it to support FGDB).


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

Re: [JPP-Devel] ESRI file geodatabases

[Martin Davis]

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,  preferably with the iGOR 
interface (after I update it to support FGDB).


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