Import/Latvia Microreserves

From OpenStreetMap Wiki
Jump to navigation Jump to search

DRAFT

This is a one-time import of microreserves ("mikroliegums" in Latvian) in Latvia.

Description

Microreserve or micro-reserve is an official term used by Nature Conservation Agency under Ministry of Environment of Latvia to describe a small nature protection area for a specific habitat and/or species. The Latvian law defines "microreserve territory" ("mikrolieguma teritorija" in Latvian) as a category for specially protected nature zones [1]. The Latvian law defines how microreserves are created, notably they have to be officially approved to be added to the list [2]. Listed as LV08 along other types of reserves in CDDA Nationally Designated Areas. Microreserves are established for a specific biotope, species or both; and in case of species, a specific group (see below). There are 3060 microreserves of which a bit less than 40 are currently mapped in OSM. A microreserve is not to be confused with a nature reserve ("dabas liegums" in Latvian) or nature park ("dabas parks" in Latvian). In fact, a large number of microreserves are part of a larger reserve. A few microreserves have names, but the vast majority do not.

Schedule

??

Import

This is a one-time manual import of almost the full dataset of microreserves published under CC0 1.0 at https://data.gov.lv/dati/lv/dataset/mikroliegumi by Latvia's Nature Conservation Agency ("Dabas aizsardzības pārvalde" in Latvian) [3], accessibly hosted on their OZOLS content system [4].

Data preparation

Original data comes in an ESRI Shapefile in LKS-92/Latvia CRS. QGIS is used to reproject it to WGS 84. Data has several ring-intersection errors fixed in QGIS. Geometries are simplified with a fairly high tolerance to remove redundant geometry points. Geometries are then visually inspected to fix some obvious polygon errors (of which there weren't many). (Any automated verification tools were of little help as human input errors far exceed the precision of the data otherwise.)

To check conflation, 420 OSM elements for reserves and protected boundaries were exported from Overpass Turbo and imported to QGIS. OSM elements that didn't overlap any data geometry were ignored. The vast majority of overlapping elements were larger nature parks and areas that contained the microreserves, so they were also ignored. Smaller nature reserves with areas comparable to overlapping microreserves were manually checked as being their own entities and ignored. This left about 40 already-mapped microreserves and a few ambiguous/unclear cases. Some of these were previously manually imported, so they match either exactly or near so. Most remaining would need to have their geometry updated. Only a few examples were significantly incorrect. Due to there only being some 20 or so such conflating cases, these are left for a manual update after the import, while the import would proceed with all geometry for now.

Some features are polygons, some are multipolygons (completely separate areas or self-touching - both vertex-to-vertex and vertex-to-edge). A bit over 3000 importable features are made of a bit over 110 K nodes; 95% or so are below 100 vertices and 50% or so are below 30. There are shared nodes.

Tagging

The following tags will be applied to each microreserve:

  • boundary=protected_area - The primary tag to identify this as a protected territory.
  • protect_class=4 - This falls neatly into "Habitat/Species Management Area".
  • protection_title=mikroliegums - The specific type within the above class, i.e. "microreserve".
  • protection_object=* - What is the principal protection target based on two codes in the data: what is protected - biotope, species, both or undefined; and if species, then which one of 9 pre-defined classes. (See #protection_object below.)
  • ref:OZOLS=#### - A new ref tag namespace. The permanent ID of the reserve in the Nature Data Management System OZOLS [5]. This allows identifying each reserve back to the data source/maintainers. The data comes with this ID. Opting to not use plain "ref" in case these ever get official IDs in some government system, like Place names database.
  • start_date=####-##-## - The starting date of the microreserve, specified as "date of formation" in the data. Ranges from 7 Dec 2001 to 17 Apr 2023.
  • buffer_zone=yes/no - A new tag. Whether this microreserves also has a buffer-zone around it. (See #Buffer zones below.)

Notably, these tags are not added

  • leisure=nature_reserve - Microreserves are not by default locations that are designated for human activity or have any infrastructure at all. Many are within larger "parent" nature reserves, which then have this tag (and would "include" the microreserve too). They are basically just "nature", but of particular interest to conservation and not the general public.
  • name=* - Microreserves do not have names by default, although some may be named by the relevant authority, like a municipality (but this needs to be verified manually for each one).

protection_object

The exact values parsed from the data are: amphibians (3), biotope (827), biotope; vascular plants (1), birds (1979), fish (1), invertebrates (24), lichens (18), mammals (1), moss (35), mushrooms (5), vascular plants (162). The term "biotope" here is used by its more-specific scientific meaning rather than "habitat", which is often used synonymously, but would actually imply specific species.

Changeset(s)

The account used for importing is .... TODO make account

The proposed changeset comment is "Importing microreserve territories in Latvia. See https://wiki.openstreetmap.org/wiki/Import/Latvia_Microreserves".

The changeset tags would be those of JOSM

plus source=https://data.gov.lv/dati/lv/dataset/mikroliegumi

The changeset hashtags would be #import ... TODO and what?

The changeset will cover basically the area of Latvia.

The number of changeset will probably be around 12 (based on 10k element limit). TODO: do I want smaller?

TODO: Link to your source data files that you have prepared for the import - e.g. the .osm files you have derived from the data sources.

TODO: Identify what method will be used for entering the imported data into the OSM database - e.g. API, JOSM, upload.py, etc.

Describe how you'll use changeset tags in the import.

Detail the steps you'll take during the actual import.

Conflation

Thankfully, very few of microreserves are already mapped, so it's mostly adding new geometry.

Identify your approach to conflation here.

Buffer zones

It's relevant to mention that microreserves may have "buffer zones" decided and approved together with the microreserve. About half of the microreserves have a buffer zone around them. This is also represented in the data - each microreserve entry has a flag whether it has a buffer zone and a separate shapefile describes their geometries. Most of these are around bird species microreserves. These have mainly forestry restrictions, but less strict than the main territory. Given the already-minor status of the microreserves (compared to nature reserves/parks), there is no plan to import these at this time.

TODO: example image

QA

Before import, by large, the data has been visually reviewed in QGIS to note any discrepancies and compare to existing data. (See #Data preparation.)

After import, individual reserves will be checked manually and adjusted as necessary. There are two tasks.

The existing microreserves will be replaced or modified, depending on how "correct" they were and simply what's easier to do manually. So adding tags to the old reserve and fixing its geometry. Or just deleting it and leaving the imported one.

The bulk of the post-import work would be connecting the reserves to existing features, i.e. nature park boundaries, admin boundaries and such. Visual inspection suggests that the imported data is more precise than the vast majority of already-mapped data, which is mostly from many years ago. It is most likely that existing areas need to match the microreserve shapes rather than vice versa. But the data also appears to be manually entered so it may not match what it is supposed to represent. So this needs manual review for each case and it's hard to say ahead of time how much adjusting would be needed. It's unlikely any automated tool can help with this, because there is no way to tell something like "this microreserve edge should match this nature park edge" versus "microreserve starts several meters into the nature reserve territory, because it doesn't include the ditch".

Discussion

The email to the Imports mailing list was sent on YYYY-MM-DD and can be found in the archives of the mailing list at [6].

Proposal and discussion at the Latvian Zulip community Live chat; Archive.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Import/Latvia_Microreserves&oldid=2556386"