[gdal-dev] Open source vector geoprocessing libraries?

[Ragi Y. Burhum]

>
> Date: Wed, 13 Jan 2010 10:27:43 -0500
> From: "Jason Roberts" <jason.roberts at duke.edu>
> Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
> To: "'Peter J Halls'" <P.Halls at york.ac.uk>
> Cc: 'gdal-dev' <gdal-dev at lists.osgeo.org>
> Message-ID: <008001ca9464$f4059f10$dc10dd30$@roberts at duke.edu>
> Content-Type: text/plain;       charset="US-ASCII"
>
> Peter,
>
> > are you constrained to retaining your data in an ArcGIS compatible
> format?
>
>
> We are attempting to build tools that can work with data stored in a
> variety
> of formats. Our current user community uses mostly shapefiles, ArcGIS
> personal geodatabases, and ArcGIS file geodatabases. Many of them are
> ecologists who do not have the interest or skills to deploy a real DBMS
> system. Thus we are hoping to provide tools that can work without one. This
> is one reason I was exploring how embeddable PostGIS and SpatiaLite might
> be
> in the other fork of this thread.
>
> > Until the File
> > Geodatabase format is published (later this year?) and someone has the
> effort to
> > build an OGR interface, the DBMS route is probably the best route to
> > compatibility.
>
> It would be really great for that to happen, but I'm not holding my breath.
> If it does get published, I would seriously contemplate building an OGR
> driver.
>
> I have contemplated building an ArcObjects- or arcgisscripting-based
> driver.
> This would at least allow people who have ArcGIS to use OGR to access any
> ArcGIS layer, including those created by ArcGIS's tools for joining
> arbitrary layers, etc. That would handle file geodatabases, as well as ALL
> formats accessible from ArcGIS. If such a driver existed, then we could use
> OGR as the base interface inside our application. But creating such a
> driver
> would be a lot of work and have funky dependencies because it either needs
> to use Windows COM (for ArcObjects) or Python (for arcgisscripting) to call
> the ArcGIS APIs. I am certainly capable of implementing it but because most
> of our code is in Python, it is probably easier for me to wrap OGR and
> arcgisscripting behind a common abstraction, and then have our tools work
> against that abstraction rather than OGR directly.
>
>
I find it very amusing you mention this right now.

Why?

I asked Frank if there was an ArcObjects based OGR driver this very past
Thursday and he said "not that I know of". What I wanted was, among other
things, to get data out of FileGDB to PostGIS with one shot and add some
custom behavior for a client of mine. So I spent the past three days looking
at OGR drivers and wrote an ArcObjects based one. I got it working
yesterday.

- Right now I only instantiate 3 factories (Enterprise GDB aka ArcSDE,
AccessDB and FileGDB). This means it reads FileGDB just fine. If you want
more factories, the driver only has to be modified with one line to add any
other factories and everything else would just work.

- I only implemented the parts that I needed, so it is readonly (should be
straight forward to expand if need be).

- Although, it can read other GeoDatabase abstractions (Topology, Geometric
Networks, Annotations, Cadastral Fabrics, etc), currently I am explicitly
filtering for FeatureClasses and FeatureDatasets.

- It is a ATL / COM / C++ based one, so it will only compile on Windows. It
can be modified to use the cross platform ArcEngine SDK since all the COM
Objects that I use are called the same and behave the same way... I just did
not have an ArcEngine SDK installer, so I could not test this.

Anyway, if you are interested in the source code, let me know. Perhaps we
can add it as an ogr driver contribution (what is the process for that
anyway?). I may not respond fast enough to e-mail, since the next 4 weeks
are pretty crazy for me.

- Ragi Burhum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100113/bd5bfa6b/attachment-0001.html