The agricultural policy in the European Union involves one of the biggest financial transactions in the annual budget. This calls for a careful and precise registration of those farmers eligible to receive subsidies, plus the amount they are entitled to. In order to make this registration work smoothly, a Land Parcel Identification System (LPIS) has been designed.
Each country in the European Union manages and operates their own LPIS. For the Netherlands, this is done by the Ministry of Economic Affairs, which includes the former Ministry of Agriculture. Each of the current 70,000 farmers in the Netherlands must log into the system each year to declare which parcels they have used, what they’ve grown and, if needed, modify their parcel boundaries. The declaration period is constrained to six weeks, and many farmers wait until the last weekend to submit their data. This results in peak usage in the final days of the declaration period. In order to properly respond to this surge, the application must be fast and reliable at all times.
The system supporting LPIS in the Netherlands was initially conceived in 2008, and involved a complex architecture of federated databases and geospatial servers. Keeping up performance and reliability was a challenge, especially at peak times, with a large part of the load coming from the underlying imagery data. This is why the Ministry approached Imagem, as Benelux distributor for Hexagon Geospatial.
ERDAS APOLLO Imagery Service Operational in 1.5 Hours
Putting in place a powerful imagery service based on ERDAS APOLLO was something Hexagon Geospatial has done on many occasions. In this case, the additional challenge was to implement it in an existing architecture, based on Esri technology. There was no room to modify front end or back end architecture; the solution needed to slide neatly in place, and it needed to be done fast. When the order came in, there was a mere four weeks until the start of the submission period.
Upon arriving onsite, the base system became operational within 1.5 hours. We used the native Esri Geoservices protocol, which meant the front end could directly take in the new service, without recoding. Therefore, testing could begin almost immediately after installation. When doing this, the imagery appeared on screen faster than the vectors, which had never been the case before.
An Imagery Service that Performs Under Pressure
When the system went into production and farmers began submitting, the system proved not only to be very fast, but also much more stable than the previous architecture. Even at peak times, with over a 8 million page views and 100 Gb of data being requested each hour, CPU’s would not exceed 25% of their maximum load.
Furthermore, the data was now coming from a few large ECW mosaics, without a predefined tile cache (which had been used before). This meant that on top of the gain in speed and stability, data management was significantly reduced, as well as the amount of storage space required.
In conclusion, the Ministry is very happy with the solution and the ease with which it was implemented. It paves the way to make use of this architecture for other systems as well. It also proves that adopting a ‘best of breed’ approach to your system architecture sometimes yields a better return on investment than standardizing on a single platform.