[gdal-dev] Table Names (FGDB)

[Even Rouault]

Le mardi 31 mai 2011 18:43:15, Paul Ramsey a écrit :
> 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?

Not having followed the whole discussion and not sure to really understand the 
FGDB concepts, I don't think it would be very hard to propose a configuration 
option/environement variable to get the layer names reported as fully qualified 
or just the table names.

> 
> 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.
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev