[Gdal-dev] PGeo and ODBC support in OGR

[Tamas Szekeres]

Folks,


If the data source could provide the bounding box of the shape adding a
spatial filter support is not a difficult challenge.

The only problem is how to inform the driver about the columns of the
bounding box. Is applies to the reporting of the fid column as well.

Due to the significant benefits of these issues it would be considerable to
maintain default column names (eg. ogc_fid, minx, miny, maxx, maxy) since
one can apply the proper aliases to support them without any problem.


Tamas Szekeres 



-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Frank Warmerdam
Sent: Thursday, December 01, 2005 10:56 PM
To: Eugene Polishchuk
Cc: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] PGeo and ODBC support in OGR

On 12/1/05, Eugene Polishchuk <ugeni79 at gmail.com> wrote:
> Hi all,
>
>  I am currently trying to use OGR for reading and writing spatial data in
> different formats.  I have a couple of questions about OGR support for the
> following formats:
>
>  ODBC:
>  I've noticed that a new way to create an ODBC datasource:
> tablename(geometrycolname) has been added recently which is great since it
> resolves some of the performance issues that we have been experiencing,
but
> when creating a datasource in this way and then subsequently calling
> ExecuteSQL on it, the layer that ExecuteSQL() returns does not appear to
> retain the geometrycolname and therefore its features do not have any
> geometry info.  Since I am new to OGR I wasn't sure whether this behavior
is
> by design or is it still in development or a bug?

Eugene,

This is the expected behavior, though not really the desired
behavior.  The problem is that OGR doesn't "understand" the SQL
passed through it to ODBC and it has to examine the resultset
produced blindly which means it is very hard to work out what
is a geometry column (or what should be used as the FID).

>  PGeo:
>  With OCI and Shapefile datasources the FID's of the layer returned from
> ExecuteSQL() are from 0 to GetFeatureCount()-1, but with PGeo they appear
to
> correspond to the OBJECTID of the feature.  Is this the intended behavior?

The OCI driver now includes a backdoor mechanism to pick a column
to use as the FID (via the OCI_FID config variable).  Otherwise fids
are assigned sequentially which means the fids aren't really persistant.
If the query changes (new spatial extents for instance) then the fids
change.

Shapefile uses the index in the file as the fid which is persistant.

Overall, it is better for RDBMS based drivers to be able to select
a column to use as FID but when that can't be done, dummy fids
are auto-assigned.  In general you should not depend on any
particular order or continuity in fids for apps that should work on
different drivers.

>  Also do you have any plans on adding spatial reference support to OCI and
> ODBC?

I thought spatial reference support was already there (mostly) for OCI.
I have no plans to add it for ODBC.

>  And if we decide to make any changes to OGR what would be the appropriate
> process to roll our changes into the main source?

For modest changes submit the changes as patches through bugzilla
with an explanation.  If you plan to do alot of work, we can discuss
providing CVS commit access.

Best regards,
--
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 2005.11.30.
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.11/191 - Release Date: 2005.12.02.