PostGIS spatial extensions
От | Paul Ramsey |
---|---|
Тема | PostGIS spatial extensions |
Дата | |
Msg-id | 3B782B13.A8867E7A@refractions.net обсуждение исходный текст |
Ответы |
Re: [PATCHES] PostGIS spatial extensions
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: