[gdal-dev] Table Names (FGDB)

Chaitanya kumar CH chaitanya.ch at gmail.com
Tue May 31 13:37:04 EDT 2011


Paul,

PgSql is not the only driver that use the schema.table notation. I see that
OGR's MSSQLSpatial driver too uses it too. So there won't be anything new.
On the other hand, the '\' separator could lead to some confusion with
escaping in some situations.

On Tue, May 31, 2011 at 10:13 PM, Paul Ramsey <pramsey at cleverelephant.ca>wrote:

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



-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110531/fb29d952/attachment.html


More information about the gdal-dev mailing list