[fdo-internals] FDO RFC 16 - FDO Provider for SQLite

[Traian Stanev]

Hi guys,

I prefer Frank's schema here. My reasoning is:

Neither Jason's nor Frank's schema complies with the OGC spec. Jason's is "close" to the spec, but that doesn't mean it actually complies with it (otherwise MSIE would be CSS compliant).

Repurposing either of the storage_type or geometry_type would confuse a hypothetical client which _is_ spec-compliant and doesn't know about our new values (granted, it would have to be a pretty paranoid client).

So unless we get the OGC to agree with our [re]definitions for geometry_type and storage_type, I'd rather go with a solution that can interoperate with at least one existing database.

Traian

P.S. I agree that "type" is not a good name for a column, but it is a column in the "geometry_columns" table, so it is not that ambiguous. Also, its value is a string that says something like "POLYGON" so it is not only unambiguous, but painfully obvious.




> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Jason Birch
> Sent: Monday, March 24, 2008 2:35 AM
> To: FDO Internals Mail List; FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite
>
> Frank,
>
> Obviously (?) we're not shooting for SFSQL certification for this
> format, and I'm definitely not a stickler for standards, but I would
> feel better matching the current OGC spec than older the PostGIS
> schema.  Especially given that we are potentially setting a template
> for future spatial storage in non-spatial formats.
>
> There are some problems that mean that we can't just adopt the spec
> wholesale though.
>
> First, the geometry_type field in SFSQL1.2 is very close to TYPE in
> PostGIS, but it uses integer-based lookup.  This looks awfully Oracle-
> ish; not surprising given the editor I guess.  It does support curve
> strings and more (pp 39-41), just as the new WKB spec does.
>
> Second, storage_type in SFSQL1.2 is very close to what we want to
> accomplish with geometry_format, but again is integer-based, and only
> flags whether the geometry is normalised (ick - does anyone actually do
> this?) or WKB (pp 28-29).  We would have to extend this to support WKT
> and FGF.
>
> As far as self-descriptive values go, I agree with you.  Being a
> database geek, I'd personally prefer to see the use of integer codes
> and an FK table of all of the values and their english equivalents
> (which your code would ignore), but since we'd have to mangle the
> specification anyway I guess that I'm not opposed to using varchar in
> these places...
>
> Of course, I'm not building it, so take this as specifications wankery
> if you want.  I should also admit to being almost as annoyed at seeing
> "type" as a field name as I am when I get an Access database with
> "date" as a field name, so the rest of my comments are probably a bit
> bent. ;)
>
> Jason
>
> ________________________________
>
> From: Frank Warmerdam
> Subject: Re: [fdo-internals] FDO RFC 16 - FDO Provider for SQLite
>
> The "type" field is based on what I saw in PostGIS.  I'm not sure if it
> is
> described in the SF spec or not.  But, without a fairly specific reason
> to
> be different, I'd prefer to match what PostGIS does so it is easy for
> folks
> who already work with it to understand what is being done in SQLite.
> So,
> based on that I'm not *keen* on changing the field name or the
> contents.
>
> There are various reasons I don't like using integer codes in the
> field.
> First, it is different than PostGIS.  Second, I don't know what sorts
> of
> values to use for odd things like FGF curves.  Third, I find the
> strings
> more self-descriptive than integer codes.
>
> I didn't really understand why you preferred storage_type to
> geometry_format.
> The geometry_format is unique to the sqlite proposal as far as I know,
> so
> if there is a reason for storage_type instead, I'd be quite open to a
> change.  Does this align better with some other format?
>
> BTW, the naming, etc proposed for stuff in sqlite could just as easily
> be applied to any other non-spatial RDBMS type environment.
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals