TR : [Gdal-dev] ADO driver based on OpenGIS SQL specification in OGR ?

[Jean]

Jean wrote:
> The document « OpenGIS Simple features specification for SQL rev1.1 »
> describes the SQL92 implementation of features tables
(www.opengis.org).
> 
> As the Microsoft jet database engine is free on the Windows' system,
> this could be a good way to have a Read/Write driver with a
"performant"
> SQL engine.
> 
> Indeed, I believe that these specifications are enough to create an
> Read/Write OGR driver with Geometries stored in wkb format. Am i wrong
?
> and is it interessting in OGR ?

Franck wrote
>Jean,
>
>Sorry for not replying sooner.  I have been working hard on a couple
>projects
>trying to get them out of the way before I take a week off next week.
>
>Implementing OGC Simple Features for SQL (including the functions and
>datatypes)
>is a pretty big job even with an existing full function SQL
>implementation
>to build on.  The Refractions guys did it for Postgres, but they had
>access
>to the full source so they could update the database core.  That >would
really
>be practical (as far as I know) with the jet engine.
>
>We could implement support storing geometry in WKB in using Jet, and
>have
>OGR understand this, but with the database just treating the geometry
>as
>a generic binary field.  This would be somewhat useful, but not
>something
>I am all the keen on spending alot of time on.  Doing this in a way
>that it
>would work with any ODBC supported database might be worthwhile, and >a
bit
>more general.  I would like to see this happen, but I don't know what
>all
>the gotchas are.  It is also not something I have funded or large
>amounts of
>free time to work on.   If it were to happen, it might well be done >in
such
>a way as to be compatible with ESRI (or MapInfos?) use of access
>databasees
>as lightweight spatial databases.
>
>What we do have now is a solid PostGIS driver in OGR, and PostGIS
>implements
>good and improving OGC compliance on a full featured database engine
>*with*
>good spatial search performance.  PostGIS/Postgres works quite well on
>Windows (as well as unix of course), and is free.  So I don't see a
>compelling
>reason to search for another solution.
>
>Now, I may have missed part of your point.  Is there some advantage >to
using
>ADO?  Is the intent to implement on a database that is easily
>accessable from
>VB?  Do you think the Jet database is more performant than Postgres? 
>It is,
>no doubt, faster than the builtin OGR SQL implementation.
>
>Best regards,

About ADO : Althought less general than ODBC, ADO is much more
efficient. 

About Jet : The good point of such format is that it is
free(distribution). However, it is only a relational database that
implies that no query is available on binaries field (geometry). The
only query availables are based on simple attributes of features (long,
double .)
In my opinion jet was good to store wkb geometry to do queries on simple
attributes and to create relation beetwen feature (Foreign key/Primary
key).
It's indeed not enough to justify such a development.

About PostGIS : It looks perfect ! But the GNU GPL license of PostGis
raises a problem. Our software that would use PostGIS through OGR, will
must be distribued under GPL licence too. Or, we can not published our
source code(however no problem about PostGres's source code) neither
allowed our users to redistribute our software for free.
Is that the real application of the GNU GPL license ? I may be wrong.

Thanks for all,

Best regards,

Jean.


_____________________________________________________________________
MSN Messenger, nouvelle version ! Personnalisez vos messages, jouez en
ligne et communiquez en temps réel par vidéo! http://ifrance.com/_reloc/m