Well, I'm no expert!! As far as applications go, the few I use *had* problems with schemas other than public, but I think this has been worked out for some time now. So I think schemas are well supported - but it may be worthwhile asking qgis and gvsig how they are faring with these today...
I can hook up some people from qgis to this thread (if they're not following already...). Duarte -----Mensagem original----- De: Paul Ramsey [mailto:pram...@cleverelephant.ca] Enviada: terça-feira, 31 de Maio de 2011 17:43 Para: Duarte Carreira Cc: gdal-dev@lists.osgeo.org Assunto: Re: [gdal-dev] Table Names (FGDB) 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 <dcarre...@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:pram...@cleverelephant.ca] > Enviada: segunda-feira, 30 de Maio de 2011 22:47 > Para: gdal-dev@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
