<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Verdana","sans-serif";
        color:#003399;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>Ragi,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>Nicely done. That is pretty funny. I'm sure there's a few others
lurking on the list who have thought of such a thing as well. Could you please
send me the code? Thanks!<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>Do you know if it would work if invoked from Python-based
geoprocessing tools? We expose a lot of our work to ArcGIS as those. An
interesting feature of these is that they can access layers created at run time
by the user in the ArcGIS applications. They can also run both in and out of
the ArcGIS process. The arcgisscripting Python API (and
esriGeoprocessing.GPDispatch COM object) use named pipes to communicate with
the application, or something like that. I am wondering if your driver would
have to initialize ArcObjects in a special way to somehow integrate with that. I
have never seen documentation from ESRI on how to use ArcObjects from a &quot;script-based&quot;
geoprocessing tool (only from a &quot;function-based&quot; geoprocessing tool,
which always runs in process and always uses ArcObjects).<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>What is the startup cost like? I have written a lot of standalone
Python geoprocessing scripts that you run from the command line. These always
take a long time to initialize the geoprocessor (several 5 to 20 seconds,
depending on ArcGIS version) before I can call any APIs. I don't know if it is
because the geoprocessor is internally allocating an ArcObjects &quot;application&quot;
object, or if it is due to the license system (doesn't matter if you use a
local or remote license server). In any case, it would be great if your driver
did not suffer from this. I have not written any ArcObjects programs that run
outside of ArcGIS applications, so I don't know if it would suffer this.
(Sadly, I am betting yes&#8230;)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>I do not know the process for submitting an OGR driver but the team
seems very receptive to user contributions. I would be happy to review the code
and offer comments (I'm also busy this month, so this might take some time).
Based on some thinking I've done in the past 24 hours, I'm not sure that I will
end up using it in my final application, but it would certainly be valuable. There
are periodic inquiries to gdal-dev about reading file geodatabases, and your
driver would solve that one.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>There are precedents for other drivers that depend on other software
(e.g. Oracle, I think), so I don't think anyone will strenuously object to your
driver being dependent on COM and ArcObjects. Obviously it would have to be an
optional driver. It would be good to write some tests for it; that may be a
requirement from the GDAL team, although I doubt they are in a position to run
them as part of a normal GDAL release, as I don't think any of them have
ArcGIS.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>A possible issue is that you'd probably need to recompile it
every time a different version of ArcGIS came out. Ideally, you would maintain
versions of it for each release of ArcGIS. The driver documentation should point
out to the user that they must obtain the right version. Alternatively you
might be able to craft one driver that dynamically determines the ArcGIS
version and does the right thing.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>Best,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'>Jason<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";
color:#003399'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
gdal-dev-bounces@lists.osgeo.org [mailto:gdal-dev-bounces@lists.osgeo.org] <b>On
Behalf Of </b>Ragi Y. Burhum<br>
<b>Sent:</b> Wednesday, January 13, 2010 12:53 PM<br>
<b>To:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> RE: [gdal-dev] Open source vector geoprocessing libraries?<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

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

</blockquote>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>I find it very amusing you mention this right now.&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>Why?<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>I asked Frank if there was an ArcObjects based OGR driver
this very past Thursday and he said &quot;not that I know of&quot;. 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.&nbsp;So I spent the
past three days looking at OGR drivers and wrote an ArcObjects based one. I got
it working yesterday.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>- 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.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>- I only implemented the parts that I needed, so it is
readonly (should be straight forward to expand if need be).&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>- Although, it can read other GeoDatabase abstractions
(Topology, Geometric Networks, Annotations, Cadastral Fabrics, etc), currently
I am explicitly filtering for FeatureClasses and FeatureDatasets.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>- 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.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>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.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=MsoNormal>- Ragi Burhum<o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>