Thread: contrib/postgis spatial extensions
(My last try at this vanished into the aether, so I am repeating...) Patchers, I hope using an attachment is not breaking list protocol... PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at http://postgis.refractions.net The source is set up to compile cleanly from under 'contrib'. The only Makefile quirk is a switch to allow the environment variable PGSQL_SRC to override the usual contrib defaults about where the pgsql source tree is and where installation should happen. Thanks, Paul -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
Attachment
> (My last try at this vanished into the aether, so I am repeating...) > Patchers, > I hope using an attachment is not breaking list protocol... > PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at > http://postgis.refractions.net > The source is set up to compile cleanly from under 'contrib'. The only > Makefile quirk is a switch to allow the environment variable PGSQL_SRC > to override the usual contrib defaults about where the pgsql source tree > is and where installation should happen. > Thanks, > Paul > Yes, I have kept your original email. Can I have a vote on whether this should be in contrib? Our logic of putting plugin stuff and conversion stuff in contrib clearly matches this patch. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote: > > > (My last try at this vanished into the aether, so I am repeating...) > > Patchers, > > I hope using an attachment is not breaking list protocol... > > PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at > > http://postgis.refractions.net > > The source is set up to compile cleanly from under 'contrib'. The only > > Makefile quirk is a switch to allow the environment variable PGSQL_SRC > > to override the usual contrib defaults about where the pgsql source tree > > is and where installation should happen. > > Thanks, > > Paul > > > > Yes, I have kept your original email. Can I have a vote on whether this > should be in contrib? Our logic of putting plugin stuff and conversion > stuff in contrib clearly matches this patch. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
I'm for adding this to contrib, but is there any chance of getting it
released under our BSD-style license, not GPL? If it's GPL then it
will never be a candidate to move out of contrib and into the main tree,
which seems like something we'd like to do with it eventually. The GPL
license forbids us from merging GPL'd code into BSD-licensed code,
so the best we can do with GPL'd code is keep it at arm's length in
the contrib area.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The package is 760k. I know GIS is a major feature, but that size had
> me concerned.
Well, 18k of that is the GPL COPYING file ;-)
Seriously, the size doesn't bother me too much. Possibly some space could
be shaved by decreasing the size of the regression test data. And maybe
we don't need to include both XML and HTML versions of the docs. And we
definitely don't need an executable file for examples/wkb_reader/readwkb;
perhaps there are some other files that don't belong in a source
distribution?
But it's under 200K compressed as-is, and given the amount of
functionality added that seems like a worthwhile tradeoff. The existing
geometric datatypes in PG are really only proof-of-concept, academic-toy
quality. This looks like the beginning of a considerably superior
replacement.
regards, tom lane
> I'm for adding this to contrib, but is there any chance of getting it
> released under our BSD-style license, not GPL? If it's GPL then it
> will never be a candidate to move out of contrib and into the main tree,
> which seems like something we'd like to do with it eventually. The GPL
> license forbids us from merging GPL'd code into BSD-licensed code,
> so the best we can do with GPL'd code is keep it at arm's length in
> the contrib area.
One thing that made me hesistate is this. These numbers are in 1k:
93 ./doc/html
147 ./doc
58 ./examples/wkb_reader
59 ./examples
21 ./jdbc/org/postgis
22 ./jdbc/org
5 ./jdbc/examples
30 ./jdbc
136 ./loader
164 ./regress
760 .
The package is 760k. I know GIS is a major feature, but that size had
me concerned.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
This is something which has been discussed on our list in the past. The
main argument for BSD to date has been as you noted: to get eventual
mainline pgsql inclusion. The main argument against, in my view, is that
we want to be a place where open geomatics code can aggregate. At the
moment, most geospatial algorithms are only available under commercial
licencing regimes: until we get a critical mass of open projects and
workable code, inertia will continue to point us towards closed source
and development.
We'll talk about this a bit on the list and see what the PostGIS users
think.
Tom Lane wrote:
>
> I'm for adding this to contrib, but is there any chance of getting it
> released under our BSD-style license, not GPL? If it's GPL then it
> will never be a candidate to move out of contrib and into the main tree,
> which seems like something we'd like to do with it eventually. The GPL
> license forbids us from merging GPL'd code into BSD-licensed code,
> so the best we can do with GPL'd code is keep it at arm's length in
> the contrib area.
>
> regards, tom lane
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_
Paul Ramsey <pramsey@refractions.net> writes:
> This is something which has been discussed on our list in the past. The
> main argument for BSD to date has been as you noted: to get eventual
> mainline pgsql inclusion. The main argument against, in my view, is that
> we want to be a place where open geomatics code can aggregate.
A fair point. The BSD theory about this is that open source process
is enough better than closed source that you can achieve critical mass
anyway, but if you haven't seen that happen for yourself it's hard to
take on faith.
A possible compromise is to accept postgis as a contrib item under GPL
now, with the thought that someday (after you feel you've achieved
critical mass) you might relicense it as BSD so we can put it in the
mainline postgres code. However that bothers me somewhat: your current
and near-future contributors might say that they contributed on the
understanding that the license is GPL, and they don't want their
contributions relicensed. In practice it's awfully tough to change
the license of an established project without making people unhappy.
You're probably better off making your decision and sticking to it.
> We'll talk about this a bit on the list and see what the PostGIS users
> think.
Fair enough. Thanks for listening.
regards, tom lane
I just did a little scruft hunt, and the only thing which is expendable
is 'regress', which is not really any good right now. (just doesn't
work, we need to redo it). Everything else has some kind of reasonable
purpose...
Generally, it as you said: this is a major feature and has a
concommitant quantity of code.
Bruce Momjian wrote:
> The package is 760k. I know GIS is a major feature, but that size had
> me concerned.
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_
OK, on the licencing issue, we have decided to keep the PostGIS
extension as GPL. We think it is important that at least one part of the
open source GIS community be GPL. And it doesn't hurt that Dave and I
are both Communists. <wink> :) We don't mind living in contrib, and
since we are going to have different release cycles would probably find
it easier to move our development along as an extension than as an
integral part of the distribution.
On the size side, I'll go through and blow away all the redundancies
which Tom listed and any more I can find for the package to go under
contrib. Then I'll post a new tarball for consideration.
Thanks guys,
Paul
Tom Lane wrote:
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The package is 760k. I know GIS is a major feature, but that size had
> > me concerned.
>
> Well, 18k of that is the GPL COPYING file ;-)
>
> Seriously, the size doesn't bother me too much. Possibly some space could
> be shaved by decreasing the size of the regression test data. And maybe
> we don't need to include both XML and HTML versions of the docs. And we
> definitely don't need an executable file for examples/wkb_reader/readwkb;
> perhaps there are some other files that don't belong in a source
> distribution?
>
> But it's under 200K compressed as-is, and given the amount of
> functionality added that seems like a worthwhile tradeoff. The existing
> geometric datatypes in PG are really only proof-of-concept, academic-toy
> quality. This looks like the beginning of a considerably superior
> replacement.
>
> regards, tom lane
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_
Oops, hold until I receive new, smaller one. > (My last try at this vanished into the aether, so I am repeating...) > Patchers, > I hope using an attachment is not breaking list protocol... > PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at > http://postgis.refractions.net > The source is set up to compile cleanly from under 'contrib'. The only > Makefile quirk is a switch to allow the environment variable PGSQL_SRC > to override the usual contrib defaults about where the pgsql source tree > is and where installation should happen. > Thanks, > Paul > > -- > __ > / > | Paul Ramsey > | Refractions Research > | Email: pramsey@refractions.net > | Phone: (250) 885-0632 > \_ [ application/x-gzip is not supported, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Paul Ramsey <pramsey@refractions.net> writes:
> ... We don't mind living in contrib, and
> since we are going to have different release cycles would probably find
> it easier to move our development along as an extension than as an
> integral part of the distribution.
Okay, we'll plan on playing it that way indefinitely. Thanks for
thinking about the issues, though.
regards, tom lane
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> (My last try at this vanished into the aether, so I am repeating...)
> Patchers,
> I hope using an attachment is not breaking list protocol...
> PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at
> http://postgis.refractions.net
> The source is set up to compile cleanly from under 'contrib'. The only
> Makefile quirk is a switch to allow the environment variable PGSQL_SRC
> to override the usual contrib defaults about where the pgsql source tree
> is and where installation should happen.
> Thanks,
> Paul
>
> --
> __
> /
> | Paul Ramsey
> | Refractions Research
> | Email: pramsey@refractions.net
> | Phone: (250) 885-0632
> \_
[ application/x-gzip is not supported, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> OK, silly binaries removed, HTML docs only, broken regress removed and
> (added bonus) accurate uninstall SQL added.
> 105K compressed, 640K uncompressed.
>
> Bruce Momjian wrote:
> >
> > Oops, hold until I receive new, smaller one.
> >
> > > (My last try at this vanished into the aether, so I am repeating...)
> > > Patchers,
> > > I hope using an attachment is not breaking list protocol...
> > > PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at
> > > http://postgis.refractions.net
> > > The source is set up to compile cleanly from under 'contrib'. The only
> > > Makefile quirk is a switch to allow the environment variable PGSQL_SRC
> > > to override the usual contrib defaults about where the pgsql source tree
> > > is and where installation should happen.
> > > Thanks,
> > > Paul
>
> --
> __
> /
> | Paul Ramsey
> | Refractions Research
> | Email: pramsey@refractions.net
> | Phone: (250) 885-0632
> \_
[ application/x-gzip is not supported, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> Tom Lane writes: > > > I'm for adding this to contrib, but is there any chance of getting it > > released under our BSD-style license, not GPL? If it's GPL then it > > will never be a candidate to move out of contrib and into the main tree, > > which seems like something we'd like to do with it eventually. The GPL > > license forbids us from merging GPL'd code into BSD-licensed code, > > so the best we can do with GPL'd code is keep it at arm's length in > > the contrib area. > > I think I have a problem with this approach. If you think these types are > the way to go for PostgreSQL then they should be available under a > BSD-style license or we should not support them by shipping them in the > distribution. You are thereby effectively declaring the development on > the existing geometry types obsolete in favour of something not as free as > we like. > > In particular, what kind of situation, legal and otherwise, are you > creating for someone who may in the future want to implement a free > version of these types? > > This PostGIS project seems big enough that they can handle their own > releases. I have a general problem with everything that comes our way > being stuffed in contrib (imagine Perl shipping the whole CPAN in its > tarball), but half a meg seems to be too much. OK, patch on hold. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane writes: > I'm for adding this to contrib, but is there any chance of getting it > released under our BSD-style license, not GPL? If it's GPL then it > will never be a candidate to move out of contrib and into the main tree, > which seems like something we'd like to do with it eventually. The GPL > license forbids us from merging GPL'd code into BSD-licensed code, > so the best we can do with GPL'd code is keep it at arm's length in > the contrib area. I think I have a problem with this approach. If you think these types are the way to go for PostgreSQL then they should be available under a BSD-style license or we should not support them by shipping them in the distribution. You are thereby effectively declaring the development on the existing geometry types obsolete in favour of something not as free as we like. In particular, what kind of situation, legal and otherwise, are you creating for someone who may in the future want to implement a free version of these types? This PostGIS project seems big enough that they can handle their own releases. I have a general problem with everything that comes our way being stuffed in contrib (imagine Perl shipping the whole CPAN in its tarball), but half a meg seems to be too much. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> In particular, what kind of situation, legal and otherwise, are you
> creating for someone who may in the future want to implement a free
> version of these types?
Well, legal problems none at all: to paraphrase a bad rap tune,
people can "do what they like, be how they like". Our existance does
not create a legal constraint on people to do whatever they want with
their own code.
Otherwise problems, just the problem of our being there first: most
people won't be sufficiently loyal to the BSD licence to want to
reimplement the whole OpenGIS spec when there's already an open source
version around.
> This PostGIS project seems big enough that they can handle their own
> releases. I have a general problem with everything that comes our way
> being stuffed in contrib (imagine Perl shipping the whole CPAN in its
> tarball), but half a meg seems to be too much.
This is a valid point, but the line around where things get added or
not seems fuzzy. GIS support is as useful as soundex and probabilistic
matching functions, it is just inconveniently more involved and
therefor bigger. Is size the determinant? Licencing? Both? This is
something which probably should be hashed out in general. What
constitues the core product and (just as important) what are the
packaging standards for non-core modules which will allow them to
be added to the core with a minimum of effort (CPAN is an excellent
example).
--
__
/
| Paul Ramsey
| Refractions Research
| Email: pramsey@refractions.net
| Phone: (250) 885-0632
\_
Paul Ramsey writes: > Otherwise problems, just the problem of our being there first: most > people won't be sufficiently loyal to the BSD licence to want to > reimplement the whole OpenGIS spec when there's already an open source > version around. That's exactly my point. We at PostgreSQL have confirmed many times that the BSD license is not just a historical accident but a desired feature of our product. I think we should not compromise that by effectively endorsing and supporting a partial replacement for our product that does not meet these standards. > This is > something which probably should be hashed out in general. What > constitues the core product and (just as important) what are the > packaging standards for non-core modules which will allow them to > be added to the core with a minimum of effort (CPAN is an excellent > example). Good points. I think before long we need some sort of extension repository as well. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Paul Ramsey writes:
>
> > Otherwise problems, just the problem of our being there first: most
> > people won't be sufficiently loyal to the BSD licence to want to
> > reimplement the whole OpenGIS spec when there's already an open source
> > version around.
>
> That's exactly my point. We at PostgreSQL have confirmed many times that
> the BSD license is not just a historical accident but a desired feature of
> our product. I think we should not compromise that by effectively
> endorsing and supporting a partial replacement for our product that does
> not meet these standards.
OK, I have thought about this for a day, and I have some ideas. First,
let me say that GIS capability would be a major PostgreSQL feature, and
would showcase our extensibility.
Second, let me mention that our license is designed to allow a company
to take PostgreSQL, spend lots of time adding some neat data type, and
then sell a closed version to recoup their expenses. We also want to be
considerate of others who don't want their work used in this way and
want their code GPL'ed.
With that said, I think there are three issues with the GIS patch:
size
license (GPL)
duplication of existing types
Let me suggest a solution. What if we took the part of the GIS code
that duplicated our existing code (geometric types) and replaced what we
had in the core distribution with the GIS version. The geometric types
are one of the few areas that have been untended over the years. Seems
a new implementation, based on the GIS specification, would be a great
idea. We would have to add some backward compatibility stuff to help
people load their old data and port their applications, but it may be a
big win for PostgreSQL.
Second, we could give the GIS folks CVS permission so they could
maintain the new geometric types.
Third, we could take the remaining GIS-specific part of PostGIS and move
it into /contrib with a GPL.
This would tie the PostGIS project closer to PostgreSQL, giving them
greater visibility and increase the use of PostGIS. This makes a
non-GPL GIS on top of PostgreSQL even less likely because PostGIS will
be much more visible and GIS people will be directly involved with core
PostgreSQL features.
It also reduces the size of the patch, because we are removing existing
code that was never really maintained.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
[ why is this thread hiding in -patches? It should be on -hackers or
-general, methinks. ]
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Let me suggest a solution. What if we took the part of the GIS code
> that duplicated our existing code (geometric types) and replaced what we
> had in the core distribution with the GIS version.
This is a complete nonstarter unless the GIS guys are willing to accept
BSD licensing of that part of their code; which I doubt given Paul's
prior comments.
regards, tom lane
> [ why is this thread hiding in -patches? It should be on -hackers or > -general, methinks. ] > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Let me suggest a solution. What if we took the part of the GIS code > > that duplicated our existing code (geometric types) and replaced what we > > had in the core distribution with the GIS version. > > This is a complete nonstarter unless the GIS guys are willing to accept > BSD licensing of that part of their code; which I doubt given Paul's > prior comments. I talked to him on the phone today, and he was interested. My basic reasoning was that if they don't want a commerical GIS developed on PostgreSQL, their best defense is to get involved with the core code, and make their GPL implementation in /contrib so popular that it doesn't make any sense for a company to make one. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> It also reduces the size of the patch, because we are removing existing
> code that was never really maintained.
You are forgetting the work I and others have put into it (mostly three
or four years ago iirc). But I'm sure that the GIS code is an
improvement ;)
- Thomas
> > It also reduces the size of the patch, because we are removing existing > > code that was never really maintained. > > You are forgetting the work I and others have put into it (mostly three > or four years ago iirc). But I'm sure that the GIS code is an > improvement ;) Let me add that PostGIS has worked closely with Oleg and all their indexing is based on GIST. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
OK, silly binaries removed, HTML docs only, broken regress removed and (added bonus) accurate uninstall SQL added. 105K compressed, 640K uncompressed. Bruce Momjian wrote: > > Oops, hold until I receive new, smaller one. > > > (My last try at this vanished into the aether, so I am repeating...) > > Patchers, > > I hope using an attachment is not breaking list protocol... > > PostGIS is a GIS extension to PostgreSQL 7.1.x. Lots of info is at > > http://postgis.refractions.net > > The source is set up to compile cleanly from under 'contrib'. The only > > Makefile quirk is a switch to allow the environment variable PGSQL_SRC > > to override the usual contrib defaults about where the pgsql source tree > > is and where installation should happen. > > Thanks, > > Paul -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
Attachment
Tom Lane wrote: > > [ why is this thread hiding in -patches? It should be on -hackers or > -general, methinks. ] > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Let me suggest a solution. What if we took the part of the GIS code > > that duplicated our existing code (geometric types) and replaced what we > > had in the core distribution with the GIS version. > > This is a complete nonstarter unless the GIS guys are willing to accept > BSD licensing of that part of their code; which I doubt given Paul's > prior comments. > > regards, tom lane Hi Tom, I have discussed this with Dave Blasby, who has done all of the programming to date (and will no doubt pop up here soon to put his oar in). There are a few issues germain to us in this: 1) Protection of important intellectual property under the GPL so that a core of geospatial algorithms can begin to coallesce. 2) Promotion of PostGIS as a central OpenGIS component (the University of Minnesota Mapserver is another) which will hopefully bring our business some consulting work over time. 3) Promition of PostgreSQL/PostGIS as an open-source alternative to things like OracleSpatial or SDE/Oracle. Our feeling is that the basic database objects and their hooks into GiST are not the core of IP we are interested in protecting. The most important code for PostGIS and open source GIS is not yet incorporated: it is the overlay, union, binary predicate algorithms specificed by the OpenGIS spec. Those are the bits we want to have GPL'ed. We are not averse to having the objects and spatial indexing under BSD and in the core pgsql distribution, but would like the rest of the OpenGIS Simple Feature Spec to be part of a GPL package (the functions, the supporting triggers and consistency maintainance devices, blah blah blah). So, 1) we can do by maintaining the important OpenGIS algorithms in an external package while the objects and indexes are brought into the pgsql main tree 2) and 3) are better served by being part of the main tree, where everyone can use the main objects, and the savants can learn about OpenGIS and move on to the complete package. Now, why would you want these objects? - they are toastable, so one of the big GIS usability bugaboos with the old geometries - they are indexable, using GiST, and do lossy indexing so "large polygon" bugaboo is not a problem - they follow an existing spec for GIS-in-a-database - they support polygons-with-holes - 3d coordinates supported Why don't you want these objects? - some of the existing funcionatily is missing, because it is not in the OpenGIS spec - no circles, or arcs - different canonical representations (EG, a point is 'POINT(1 2)' not '(1,2)' - superannuation of alot of the operator notation in short... - not backward compatible I'm sure there's other reasons as well. Something I would like Dave to comment on is how cleanly we can split the object/indexing from the OpenGIS spec'ed support tables and reference systems. I am thinking about the canonical representation in particular, which could be pretty ugly with the SRS id's hanging in there for no purpose. The OpenGIS spec is at http://www.opengis.org/techno/specs/99-049.pdf
> Something I would like Dave to comment on is how cleanly we can split > the object/indexing from the OpenGIS spec'ed support tables and > reference systems. I am thinking about the canonical representation in > particular, which could be pretty ugly with the SRS id's hanging in > there for no purpose. The OpenGIS spec is at > http://www.opengis.org/techno/specs/99-049.pdf I am thinking we can turn off the prefix tags with some postgresql.conf option. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Dave Blasby <dblasby@refractions.net> writes: > [snip] Vivid Solutions (cf. > http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it > under the LGPL. > [snip] > This leaves the option for creating a semi-compliant OpenGIS core inside > PostgreSQL and having a LGPL add-on for the complex spatial operations > (making a fully compliant implementation). Um, the tarfile that Paul sent us contained the GPL license, not LGPL. There's a pretty substantial difference. Please clarify exactly which license you intend to use. regards, tom lane
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).
I think it would be great for PostgreSQL to be an 'OpenGIS Simple Feature Specification for SQL' compliant database with robust spatial operators right-out-of-the-box. Currently, PostGIS implements most of the OpenGIS specification. The unimplemented portions are the important; spatial operators (the DE-9IM spatial relationship matrix) and boolean functions (union, intersection, XOR, etc ). Since these are extremely difficult algorithms, the PostGIS team will probably translate the JTS (Java Topology Suite) to C++. The JTS is a soon-to-be-released robust Java implementation of the OpenGIS simple feature type. Vivid Solutions (cf. http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it under the LGPL. JTS is the only open-source robust spatial library I've ever heard of. The PostGIS developers and Vivid Solutions want this to remain Free Software and not be co-opted and closed. Since PostgreSQL cannot have LGPL code in its core, this would make it impossible to ever have a fully-compliant PostGIS in its core. In fact, its unlikely that anyone will spend the huge effort required creating a BSD equivalent spatial library when there is already a LGPL one available. This leaves the option for creating a semi-compliant OpenGIS core inside PostgreSQL and having a LGPL add-on for the complex spatial operations (making a fully compliant implementation). 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. 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. dave For those reading the OpenGIS spec, PostGIS is most accurately described as "SQL92 with Geometry Types Implementation of FeatureTables".
Tom Lane wrote: > > Dave Blasby <dblasby@refractions.net> writes: > > [snip] Vivid Solutions (cf. > > http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it > > under the LGPL. > > [snip] > > This leaves the option for creating a semi-compliant OpenGIS core inside > > PostgreSQL and having a LGPL add-on for the complex spatial operations > > (making a fully compliant implementation). > > Um, the tarfile that Paul sent us contained the GPL license, not LGPL. > There's a pretty substantial difference. Please clarify exactly which > license you intend to use. PostGIS is currently released under the GPL, and is developed by Refractions Research. JTS (Java Topology Suite) will be released under the LGPL, and is developed by Vivid Solutions. JTS hasnt been released yet, and it will need to be converted to C++ before it could be incorporated into PostGIS. Even if PostGIS is converted to BSD at some point in the future, it will always have a LGPL component if we decide to use the JTS to do the complex spatial relations and operations. Sorry for the confusion, dave