In the past, desktop GIS were necessary to handle complex spatial business decisions. This lead to problems with data management, model updates and an increased cost to the organisation in hardware and (often) software maintenance. As organisations move to more cloud based solutions and provide staff with thinner client machines (chrome books etc.) it becomes harder for staff to manage more complex geospatial problems.

The Open Geospatial Consortium (OGC) developed the web processing service (WPS) standard in 2005. It provides rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services are made. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes.

This talk will present case studies of how Astun Technology has used the OGC WPS standard, as implemented by GeoServer, to allow users of web based mapping applications to carry out advanced spatial operations and allowed them to implement complex business logic without the need for specialised hardware or software.

A common question seen on many open source mailing lists is “When will you guys fix my bug? It is critical to my company!” This is often followed by one of the developers replying to say “When you write a fix or pay someone to do it”. This leads to the user complaining to everyone that this “snarkiness” is not a “welcoming” response or how unreasonable it is to expect them to learn to program, or to pay. The discussion often descends into a rambling maze of twisty insults and justifications. When the fuss dies down, all the developers go back to doing what they the were doing (something useful) and the user becomes either a dissatisfied user or an ex-user.

This talk by two veteran open source developers will help users see that play out from our the developer point of view. We’ll look at the reasons that drive developers to share their code, the licencing conditions covering it, the real life of developers and associated constraints, and what is actually reasonable to expect from both sides.