Farm Maps Online: An Open Source Success In Norway.

The 2012 GPI project produced a new "Farm Maps Online" client, as a replacement for an existing HTML client that had been used for 10 years. The GPI application is an important tool for Norwegian farmers and governmental staff, but it's open everybody all properties in Norway can be viewed in the application. The GPI application provides users with a variety of area statistics and maps relating to farms and farmland. In particular, the system can be used to track (land/farm?) ownership, which is an important factor for Norwegian farm subsidy calculation. Norwegian municipal authorities also use GPI to control applications from farmers. The discussion here focusses on the server side aspects of this project: data sources, server-side design and the provided client interfaces. The client interacts with OpenLayers and Java on the server side. Data sources: The application uses both remote and local data sources. Data is collected via WFS, Soap WS, WMS, and JDBC (for local PostgreSQL databases). The system is integrated with the Norwegian national MinID system, which allows Norwegian residents to log in to many national data services with a single personal identification number. Server-side design: The application is based on Spring/Java together with Hibernate, some code from Geotools/Geoserver and JTS. The application stack is 100% Open Source, and is hosted on multiple Linux virtual servers. The applications and servers are fully integrated with open source system monitoring software like Nagios and Munin. This has provided a high performance solution for our purposes - the average time to collect and process information for a farm is less than 2 seconds. The application is heavily multithreaded to improve response time. The only limit on current performance is the speed of the external data sources. Server client interfaces: The client interfaces used are JSON WS, SOAP WS and Geoserver. SOAP WS was used because it defines communication between the server and client in a very precise way. We are now also using JSON. The mapping from a JSON string to Java DAO objects is handled by the Jackson package from Fasterxml, and converting to JSON is simply a extra endpoint in Spring. We also store temporary data in PostgreSQL, which is used by the client via a JSON client interface or through Geoserver as WMS or WFS. How do we use Open Source? We use Open Source technology in every step of the value chain that we control. In particular, we rely upon access to source code as an aid for debugging, and we re-use code samples from existing projects, and make adjustments to fit our local needs. One of the main advantages of Open Source for this project was the ability to separate application design issues from software pricing / software interface issues. For example: Pricing: We wanted to run small, independent Geoserver instances to simplify design, and this was simple because Geoserver is free and open source. If there had been a license fee per instance, or a more complex installation (e.g. license server), it would have caused problems for our project. Code Re-use: We looked at existing JUnit & integration tests, and existing WFS code, to find solutions we could use ourselves in our own code. This flexibility (at the package, module and source code levels) is a strong motivation to use open source throughout our value chain. The only constraint upon design is the functionality provided by existing open source modules; but even this is something that can be addressed directly (by adding code) rather than indirectly (by asking a manufacturer to add a feature). We try to give back by producing new test cases for existing projects; hiring open source developers to contribute to projects we rely upon and share code back to the community; by reporting bugs; and by promoting Open Source to others. Our session presentation will provide a comparison of Open Source against commerical software alternatives in terms of ease of development, installation and upfront/ongoing costs.N/A2