<br><br><div class="gmail_quote">On Sat, May 30, 2009 at 12:00 PM,  <span dir="ltr"><<a href="mailto:postgis-users-request@postgis.refractions.net">postgis-users-request@postgis.refractions.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Date: Sat, 30 May 2009 09:46:46 +0700<br>
From: Bruce Foster <<a href="mailto:gis.foster@gmail.com">gis.foster@gmail.com</a>><br>
Subject: Re: [postgis-users] ESRI GDB format into PostGIS<br>
To: PostGIS Users Discussion <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br>
Message-ID:<br>
        <<a href="mailto:c97454c50905291946m76c5e023n74842b3fabcc5dec@mail.gmail.com">c97454c50905291946m76c5e023n74842b3fabcc5dec@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
HI<br>
<br>
this could help;</blockquote><div><br>I think it could, except that it is not entirely accurate :)<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
ESRI Geodatabases</blockquote><div> <br>...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Nomenclature<br>
<br>
Many users are baffled by ESRI nomenclature when it comes to parsing<br>
the bewildering variety of marketing phrases ESRI has used to describe<br>
ESRI "geodatabase" formats. If you feel baffled, you are not alone. </blockquote><div><br>Amen to that!<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In<br>
a nutshell, ESRI at one point introduced the idea of storing geometry<br>
in DBMS using a format that more or less boiled down to storing<br>
shapefiles within blobs. This was done in a complex way using<br>
middleware called ArcSDE that worked with serious databases like<br>
Oracle, and it was also done in a somewhat simplified way in Personal<br>
Geodatabase products that used Access .MDB files and were later<br>
apparently updated to work with MSDE (a free version of Microsoft SQL<br>
Server) or with SQL Server Express. In recent years, the ArcSDE<br>
product name seems to have been dropped by ESRI: more recent versions<br>
of this technology have been packaged as part of the ArcGIS product<br>
family and have been referred to as geodatabases.<br>
</blockquote><div><br>Yep<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
All such storage methods are technically similar and are generally<br>
referred to as SDE geodatabase formats or as Personal geodatabase<br>
formats when in the somewhat simplified form that uses Access .MDB for<br>
file-based storage. Since all such formats are similar or derived from<br>
ArcSDE, they are referred to by Manifold documentation as ESRI SDE or<br>
as ESRI Geodatabase or as Personal Geodatabase data sources, the<br>
various terms being used interchangeably, regardless of which file<br>
format or DBMS system is used to store the data.</blockquote><div><br>Here, there is no mention of FileGDB, which is what the discussion was about.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
The terms are used interchangeably because some ESRI users come from a<br>
long ArcSDE tradition and don't realize that "geodatabase" is the new<br>
term for the same old thing, while some newer ESRI users might not<br>
realize that their "geodatabase" is really SDE technology with a new<br>
name. Because of the confusion caused by ESRI names for their SDE and<br>
their Personal technology being so similar, Manifold documentation<br>
will often refer to SDE and Personal geodatabases to underline that a<br>
particular capability is available whether one is working with either<br>
SDE geodatabases or the somewhat simpler Personal geodatabases.</blockquote><div><br>This is incorrect. ArcSDE is, in a nutshell, the middleware that acts as a data access layer that is used by the GeoDatabase. The GeoDatabase is the term used to encapsulate the collections of technologies that include Topology, Geometric Networks, Network Datasets, Annotation, Representation Layers, Versioning, editing behavior, Disconnected Editing, Replication, Raster Catalogs, etc etc. So Personal GeoDatabase (mdb files), FileGDB (.gdb files), an Enterprise GeoDatabase (databases accessed through ArcSDE) are just implementations of the ESRI idea of what "GeoDatabase" entails.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Manifold can also connect to ESRI SDE and Personal geodatabase data<br>
sources for full read / write / edit capability. </blockquote><div><br>This is the scary part as well as a bold statement. If you don't use any of the complex dataset types (i.e. you just use Simple Features within the ESRI environment), then "read/write/edit" is very simple to implement. Just write SQL directly (insome cases), stored procedures, use the ArcSDE client libraries, whatever. <br>
<br>However, "Full read / write / edit capability" would mean that you understand 100% all the different components inside the GeoDatabase and have implemented routines that cause edits to dirty, percolate, update, etc the different tables/rows involved in all GeoDatabase abstractions. In fact, within ESRI, nobody is able to claim that they understand the entire GeoDatabase (OK well, maybe only one person - and no, it is not Scott Morehouse). The reason is not technical difficulty, it is just a moving target: the behavior changes and since the format is not "published" it is easy to tweak and change within ArcGIS versions as long as the ArcObjects API is tweaked accordingly. No open spec, easy to change within versions, no need to explain it to anybody.<br>
<br>Hence, why there is no public FileGDB specification. <br><br>To do this, it would mean to open the box and let everyone know all the "precious ESRI secrets about the other complex types" and there hasn't been any "strong business argument" to cause enough presure inside ESRI to make that happen. Now I and (hopefully) you understand why open formats are a "good thing", but the philosophy behind it has not struck ESRI management strong enough. **My*** interpretation of the idea of "open architecture" inside ESRI (and I may be wrong since it has been a few years since I left my Redlands job) is that open interoperability is reached from the webservice tier and that there is no need for openess at any other level of the architecture stack.<br>
<br>...<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<a href="http://www.manifold.net/doc/manifold.htm" target="_blank">http://www.manifold.net/doc/manifold.htm</a><br>
<br>
Bruce<br>
<br>
<br>
On Fri, May 29, 2009 at 6:38 AM, Simon Greener<br>
<<a href="mailto:simon@spatialdbadvisor.com">simon@spatialdbadvisor.com</a>> wrote:<br>
> Frank and Piotr,<br>
><br>
> Yes, Manifold has reverse-engineered Personal and Enterprise GeoDatabases. DOn't know how well.<br>
><br>
> Type "GeoDatabase" into Search in the Manifold Help.<br>
><br>
> But, the way it is done is that one uses Tools>Database Console tto go to the database (eg Access .mdb) file that holds the<br>
> geodata. When Manifold opens it it will recognise the ESRI crap and allow you to import/link to it.<br>
><br>
> regards<br>
> Simon<br>
>> Frank Warmerdam wrote:<br>
>>><br>
>>> Are you suggesting that Manifold GIS has reverse engineered the file<br>
>>> geodatabase format?  Can you provide any pointers supporting that?<br>
>>> If those guys can reverse engineer it, then so could we given enough<br>
>>> desire.</blockquote><div><br>Frank W.:  years ago when the first talks about the Open FileGDB API started, I
personally suggested a GDAL/OGR driver as the primary venue for this
open API. I know that the primary engineer dedicated to FileGDB contacted you directly with an inquiry about this topic. I know this, because he stopped by my office and we talked about it. If there is some momentum/need to reverse-engineer FileGDB (for Simple Features), I would recommend to start by contacting him directly. He is an extremely friendly fellow and will no doubt get you pointers that would help creating the open source driver a much easier task.<br>
<br><br>
</div>My two cents,<br><br>- Ragi Burhum<br></div>