Why did we select postgis?
[1] We were already using open source tools elsewhere in the system, and were keen to stick to that if possible.
[2] Postgis offered a number of advantages.
It was quick and easy to add as an extension to a database system with which we were already familiar
[*] We envisaged analytical work that may combine both spatial data and the primary attribute data – the census interaction data - that we use; having both sets of data in the same database was therefore considered very useful, compared to a separate mapping system that need not necessarily have anything to do with postgres.
[3] The availability of mapserver – which will be discussed shortly – was another advantage of postgis. In particular, the fact that we could use PHP, which the rest of the application is written in, to generate maps.
[4] Finally, we took the vierw from the outset that we wanted to make very low demands of the capabilities that a user’s web browser had. We had our own experience of using a variety of mapping tools, including tools written as client-side Java applets, and also tools that required browser plugins. From our perspectives of teaching students in Leeds, both Java and browser plugins were very problematic, and we could not reply on PCs used by students in general access clusters having a suitable configuration. We knew directly that the same problem arose in an number of other universities, and assumed that it would in fact be repeated in many other institutions. We therefore wanted a relatively low tech solution, in which maps were presented as clickable images; Mapserver was able to meet those needs.