[gdal-dev] Table Names (FGDB)

[Paul Ramsey]

This is why I'm looking for guidance from the OGR experts... what
layer name styles work best for interoperation? If I emit schema.table
layers on read, will apps be happy or sad?

The driver is moving towards read/write. I will have no trouble
dealing with schema.table names as I can just map them to
\FeatureDataset\FeatureClass under the covers, and create new
FeatureDataset folders as necessary.

P.

On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira <DCarreira at edia.pt> wrote:
> Paul,
>
> The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like "yes, consider the dataset name"? Or "no, discard dataset name". I can see myself in both situations...
>
> Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb?
>
> Duarte
>
> -----Mensagem original-----
> De: Paul Ramsey [mailto:pramsey at cleverelephant.ca]
> Enviada: segunda-feira, 30 de Maio de 2011 22:47
> Para: gdal-dev at lists.osgeo.org
> Assunto: [gdal-dev] Table Names (FGDB)
>
> So, my goal is to map information from FGDB to PostGIS and as much
> fidelity as possible.
>
> FGDB includes a class called "Feature Dataset" which is basically a
> folder that holds "Feature Class" objects, which map directly to OGR
> layers. So the "Feature Dataset" then acts a good deal like a schema
> in PostGIS.
>
> I've noticed that the PgSQL driver supports a SCHEMA keyword to allow
> you to write to a schema without schema-qualified table names, and
> that it also notices when table names are schema qualified and puts
> them in the appropriate place. So the name of a layer read from a
> schema would show up in OGR as "schemaname.tablename".
>
> In FGDB, we have the "path" of a Feature Class or Table, which looks
> like this \FeatureDataset\FeatureClass. Similar to the schema
> qualification, yet different. As it stands right now, the
> FeatureDataset portion of the path is discarded in the public API, so
> that the OGR layer name is just the FeatureClass, with no reference to
> the FeatureDataset. That makes it hard to create a mapping from FGDB
> (\FeatureDataset\FeatureClass) to PostGIS
> (FeatureDataset.FeatureClass).
>
> The FGDB implementation currently returns "GeoDatabase.GetQueryName()"
> as the layer name, which "Gets the query name (the name to use in SQL
> statements) of a table based on its path". If it returned the path
> name, then the FeatureDataset qualification information could be
> preserved in other contexts. On the other hand, perhaps the QueryName
> is more useful to more users than the path? It looks like the
> QueryName is expected to be unique, so probably FeatureClass and Table
> names have to be unique regardless of what FeatureDataset they appear
> in (true?).
>
> So my options are:
>
> (a) - change the current OGR layer name to the path name
> (b) - change the current OGR layer name to a "schema.table" analogue
> and handle appropriately
> (c) - leave the current OGR layer name as is ("tablename" regardless
> of containing folders) and make a FGDB-only method for accessing the
> pathname for my particular purposes
>
> Preferences?
>
> P.
>
>