Paul,<br><br>PgSql is not the only driver that use the schema.table notation. I see that OGR&#39;s MSSQLSpatial driver too uses it too. So there won&#39;t be anything new. On the other hand, the &#39;\&#39; separator could lead to some confusion with escaping in some situations.<br>
<br><div class="gmail_quote">On Tue, May 31, 2011 at 10:13 PM, Paul Ramsey <span dir="ltr">&lt;<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This is why I&#39;m looking for guidance from the OGR experts... what<br>
layer name styles work best for interoperation? If I emit schema.table<br>
layers on read, will apps be happy or sad?<br>
<br>
The driver is moving towards read/write. I will have no trouble<br>
dealing with schema.table names as I can just map them to<br>
\FeatureDataset\FeatureClass under the covers, and create new<br>
FeatureDataset folders as necessary.<br>
<font color="#888888"><br>
P.<br>
</font><div><div></div><div class="h5"><br>
On Tue, May 31, 2011 at 5:05 AM, Duarte Carreira &lt;<a href="mailto:DCarreira@edia.pt">DCarreira@edia.pt</a>&gt; wrote:<br>
&gt; Paul,<br>
&gt;<br>
&gt; The schema.table is the most similar to the structure of the fgdb, but may be unwanted complexity. Can this be an option? Like &quot;yes, consider the dataset name&quot;? Or &quot;no, discard dataset name&quot;. I can see myself in both situations...<br>

&gt;<br>
&gt; Is the driver read only? If not, what will happen when you try the reverse? From PgSql to fgdb?<br>
&gt;<br>
&gt; Duarte<br>
&gt;<br>
&gt; -----Mensagem original-----<br>
&gt; De: Paul Ramsey [mailto:<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>]<br>
&gt; Enviada: segunda-feira, 30 de Maio de 2011 22:47<br>
&gt; Para: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
&gt; Assunto: [gdal-dev] Table Names (FGDB)<br>
&gt;<br>
&gt; So, my goal is to map information from FGDB to PostGIS and as much<br>
&gt; fidelity as possible.<br>
&gt;<br>
&gt; FGDB includes a class called &quot;Feature Dataset&quot; which is basically a<br>
&gt; folder that holds &quot;Feature Class&quot; objects, which map directly to OGR<br>
&gt; layers. So the &quot;Feature Dataset&quot; then acts a good deal like a schema<br>
&gt; in PostGIS.<br>
&gt;<br>
&gt; I&#39;ve noticed that the PgSQL driver supports a SCHEMA keyword to allow<br>
&gt; you to write to a schema without schema-qualified table names, and<br>
&gt; that it also notices when table names are schema qualified and puts<br>
&gt; them in the appropriate place. So the name of a layer read from a<br>
&gt; schema would show up in OGR as &quot;schemaname.tablename&quot;.<br>
&gt;<br>
&gt; In FGDB, we have the &quot;path&quot; of a Feature Class or Table, which looks<br>
&gt; like this \FeatureDataset\FeatureClass. Similar to the schema<br>
&gt; qualification, yet different. As it stands right now, the<br>
&gt; FeatureDataset portion of the path is discarded in the public API, so<br>
&gt; that the OGR layer name is just the FeatureClass, with no reference to<br>
&gt; the FeatureDataset. That makes it hard to create a mapping from FGDB<br>
&gt; (\FeatureDataset\FeatureClass) to PostGIS<br>
&gt; (FeatureDataset.FeatureClass).<br>
&gt;<br>
&gt; The FGDB implementation currently returns &quot;GeoDatabase.GetQueryName()&quot;<br>
&gt; as the layer name, which &quot;Gets the query name (the name to use in SQL<br>
&gt; statements) of a table based on its path&quot;. If it returned the path<br>
&gt; name, then the FeatureDataset qualification information could be<br>
&gt; preserved in other contexts. On the other hand, perhaps the QueryName<br>
&gt; is more useful to more users than the path? It looks like the<br>
&gt; QueryName is expected to be unique, so probably FeatureClass and Table<br>
&gt; names have to be unique regardless of what FeatureDataset they appear<br>
&gt; in (true?).<br>
&gt;<br>
&gt; So my options are:<br>
&gt;<br>
&gt; (a) - change the current OGR layer name to the path name<br>
&gt; (b) - change the current OGR layer name to a &quot;schema.table&quot; analogue<br>
&gt; and handle appropriately<br>
&gt; (c) - leave the current OGR layer name as is (&quot;tablename&quot; regardless<br>
&gt; of containing folders) and make a FGDB-only method for accessing the<br>
&gt; pathname for my particular purposes<br>
&gt;<br>
&gt; Preferences?<br>
&gt;<br>
&gt; P.<br>
&gt;<br>
&gt;<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Chaitanya kumar CH.<br>/tʃaɪθənjə/ /kʊmɑr/ <br>+91-9494447584<br>17.2416N 80.1426E<br>