Re: [HACKERS] PostGIS spatial extensions - Mailing list pgsql-patches

Dave Blasby wrote:
>

> The next question is, of course, what does 'semi-compliant' mean? Or,
> more interesting, why would you want a semi-compliant database?  For
> most people's simple tasks, the built in geometry types are adequate.
> Those interested in doing more complex tasks will probably want the full
> OpenGIS implementation.

I would argue that for most people's simple tasks the built-in geometry
types are in fact not adequate. The fact that they choke on large
objects and are mostly not indexable (polgyons and boxes excepted)
should be enough to discourage most people with GIS intentions.

I would tend to say that a semi-compliant database would be good enough
to hack with, but not good enough to plug-n-play with an existing
OpenGIS client. It would include the objects, indexing and accessors.
Dump data in, search real fast, dump data out.

A more philosophical question would be whether a semi-compliant database
is desirable from a public good point of view: semi-compliant
infrastructure will encourage non-standard applications, which will in
turn weaken the raison d'etre of the standard in the first place.

> A few people have suggested that we simplify PostGIS, release it as BSD,
> and use that in the core of PostgreSQL.  The simplified PostGIS would
> have the basic types, indexing, and a few operations (those following
> PostGIS development, this is very much like version 0.5 and earlier).
> The 'full' PostGIS (with JTS) would have the entire OpenGIS spec.
>
> Unfortunately, this is easier said than done.  The full implementation
> requires a properly maintained metadata table (with information about
> every geometry column in the DB), a spatial referencing system table
> (info about each map projection used), and each geometry must have
> spatial referencing information.  The JTS may also require precision
> grid (offset/scale) information in each geometry.  This would make it
> really difficult (and confusing) to upgrade to the fully compliant
> version from the partially compliant version - friction I don't want.
>
> Secondly, as paul has already pointed out, there wouldn't be very many
> operations you could do on these objects.

You forgot to finish your thought :) "Therefore, I do not think we
should cleave the distribution into a BSD core and GPL support package."
I am not opposed to that philisophically, but I really do think that
Bruce's suggestion regarding becoming more integrated has merits around
acceptance by the larger PgSQL community. Being a good neighbor means
both receiving and giving.

Perhaps we could back up at this point and revisit 'contrib' ... at what
point in the size/licence/redundace spectrum do we become reasonable
candidates for 'contrib', if ever? The current tenor seems to be that at
600K/GPL/point-line-polygon we are "too big"/"too restrictive and/or too
free"/"overlapping". Would moving on any of those axes be sufficient, or
do we have to address all three (practically speaking, I not think there
is anything to be done about size).