[postgis-devel] PostGIS Development Roadmap

[Kevin Neufeld]

These all sound good to me.  Can we add to this list a documentation 
overhaul? 

Personally, I would love to see the documentation become much more 
exhaustive in it's method descriptions (a more professional look 
wouldn't hurt either).  I'm envisioning something where we have a good 
description and a comprehensive example (complete with pictures) for 
*every* method.  When I say "good description", I mean something that 
includes all the nuances and subtleties associated with a particular 
method.  IE. ST_BuildArea(Geometry) should at least mention that it 
quietly discards all unused linework (dangles and cutlines) that aren't 
used in the resultset :)  As for a professional look ... honestly, 
DocBook doesn't do it for me.  I'm not sure what to suggest here, but 
maybe in the interim we could use something like MediaWiki to gather our 
thoughts together (aka PostGISpedia).  I realize we already have a wiki, 
but I personally think it has a clumsy and awkward feel to it.  It's 
also next to impossible to quickly attach pictures to enhance method 
descriptions. 

Additionally, to expand the Regression Tests bullet item, can we add 
Unit Tests for every method?  This would save us the embarrassment of 
breaking something simple we really should have caught in the first 
place (i.e. reference ST_EndPoint() that broke in 1.3.0 or 1.3.1). 

Comments, thoughts?
-- Kevin


Mark Cave-Ayland wrote:
> Hi everyone,
>
> Having got 1.3.3 out of the door and into the wild, I'd like to share
> some thoughts about the current state of the PostGIS codebase and how we
> can improve it. One of my primary aims is to get things to the point
> where MSVC can be used to compile PostGIS; while MingW/MSYS works
> perfectly well for building PostGIS, it can take a while to set up a
> suitable environment, and building can be particularly slow.
>
> With this in mind, I'd like to suggest the following:
>
>
> - Build system overhaul
>
> In order to extract certain MSVC build vars into separate header files 
> (so they can be generated by an MSVC script as appropriate),
> it is necessary to spend some time on the autoconf system. In
> particular, I'd like to work on external library detection to make it
> more robust and display more useful information on the screen.
>
> Whilst we're doing this, it also makes sense to try and re-work PostGIS
> so that it uses the PGXS build infrastructure. This would enable us to
> remove our own copies of Makefile.shlib but would mean we would require
> PostgreSQL >= 8.0. I would distinctly prefer PostgreSQL >= 8.1 since 
> 8.0 is missing some of the pg_config options required for a PostGIS 
> build.
>
>
> - Build dependencies
>
> When developing the code, errors can slip by in cases where developers 
> haven't tried re-compiling without various libraries. My suggestion 
> would be to make GEOS and PROJ.4 *compulsory* for PostGIS, and to see 
> if we can devise some C wrapper macros like 
> PGIS_REQUIRES_GEOS_VERSION(major, minor) which can be used both within 
> code and the regression tests for code that requires newer functionality.
>
>
> - Regression tests
>
> Regression tests under Win32 are mind-numbingly slow and only run 
> under a bash shell. To better support MSVC, the test harness needs to 
> be re-written in another language. My thoughts are that Perl would be 
> the best language to use, since this is used by the main PostgreSQL 
> MSVC build scripts.
>
>
> - Stripping out dead code
>
> If we are happy to require PostgreSQL >= 8.1 for future versions then 
> there is a lot of dead code that can be removed, specifically with 
> regard to statistics / GiST indexes. It would help tidy up the code 
> base  a lot :)
>
>
> So... there is a lot of work on this list which we really need to 
> think about doing. Since the changes are quite involved, I am leaning 
> towards working in a separate branch and then switching it to HEAD 
> when something actually works for some more testing.
>
>
> Thoughts & comments welcome.
>
>
> ATB,
>
> Mark.
>