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

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

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

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
\_

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

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

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

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
\_

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

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

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

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
\_

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