Update to EPSG3035 and then verify that buffering invalid shapes doesn't destroy data

[brynpickering]

As discussed in #9, we buffer shapes that are 'invalid' to stop them breaking the workflow elsewhere. Invalid shapes are those with edges that self-intersect, e.g. think of a 'bow tie'. Many shape operations cannot be undertaken on invalid shapes (aggregating, overlaying, joining, etc.). Validity can be checked by calling is_valid() on a shape object. Buffering cleans this up, but can cause bits of shapes to completely disappear (see cautionary comment here).

At the moment, in #9, a check has been added to ensure the final area of a buffered shape is the same as the pre-buffered shape area, within a tolerance. Ideally we would set this tolerance in absolute units of e.g. m2. This can only be done, however, if the coordinate reference system is in metres (e.g. EPSG3035), which isn't always the case.

This can be resolved by moving the entire workflow to operate in a single coordinate reference system from very early on. Depending on the reference system, the absolute buffer tolerance could be set. EPSG3035 would possibly be the best for this, but if it is configurable, then we need to ensure that the buffer tolerance changes accordingly.

[timtroendle]

Actually, there are many more reasons to move to EPSG:3035 (and pitfalls coming with it most probably). The main reason to use WGS84 was that land use data is given in it and is difficult to resample. If we were to switch to Copernicus land use data (corine) we could more easily go with EPSG:3035.