{"id":3795,"date":"2024-05-23T15:21:57","date_gmt":"2024-05-23T13:21:57","guid":{"rendered":"https:\/\/usemaps.net\/nature-inventories-in-usemaps\/"},"modified":"2024-05-23T15:21:57","modified_gmt":"2024-05-23T13:21:57","slug":"nature-inventories-in-usemaps","status":"publish","type":"post","link":"https:\/\/usemaps.com\/en\/nature-inventories-in-usemaps\/","title":{"rendered":"Nature inventories in Usemaps"},"content":{"rendered":"

Nature inventories are a nightmare for GIS specialists.<\/p>\n

Why? The task seems simple: collect data from naturalists, reduce it to a \u2018common denominator\u2019, do some quick post-processing, bring it to the state required by the customer, and send it off. Done. <\/p>\n

Unfortunately, it’s not that simple:<\/p>\n

    \n
  1. The ornithologist can only use KML, the herpetologist only GPX, and \u2018the reptile guy\u2019 brings printouts with notes written in pen.<\/li>\n
  2. Once you’ve processed the data, someone will send you the \u2018missing data\u2019 in the middle of the night, and of course there will be duplicates.<\/li>\n
  3. Once you have calculated the mileage and distances, the investment plan will change, and you will have to recalculate everything again.<\/li>\n
  4. There will always be a problem with Latin names. And you never know whether the Polish name is correct or the Latin one… <\/li>\n
  5. Once again, you receive new data that partially duplicates the previous data, and you don’t know what to do with it…<\/li>\n<\/ol>\n

    I have already seen projects that ended up with huge penalties because someone carelessly used Ctrl+C and Ctrl+V and duplicated observations. There were 20 points on the map and 40 in the attribute table. And so the document stated that there were 40 nesting sites… <\/p>\n

     <\/p>\n

    Is it possible to help at least a little? Yes, of course, by using Usemaps. <\/p>\n

    What can we see in the film?<\/p>\n

    This project is configured for nature inventory in accordance with PKP standards. Everything that can be automated is counted automatically. After adding a point, the user selects a species from a dictionary containing Polish and Latin names. The following are added to the appropriate fields \u2018automatically\u2019: <\/p>\n

      \n
    1. railway line number<\/li>\n
    2. railway mileage<\/li>\n
    3. distance from the railway line<\/li>\n
    4. the side of the railway line on which the observation is located<\/li>\n
    5. Latin name of the species<\/li>\n
    6. Polish name of the species<\/li>\n
    7. species acronym<\/li>\n
    8. Species code<\/li>\n
    9. No. GUID<\/li>\n
    10. X coordinate<\/li>\n
    11. Y coordinate<\/li>\n<\/ol>\n

      The naturalist must enter the rest of the data himself (date of observation, method, etc.).<\/p>\n

      Most importantly:<\/p>\n

        \n
      1. editing the location of a point causes the coordinates, mileage, distances, etc. to be recalculated.<\/li>\n
      2. editing the species dictionary results in editing the Polish name, Latin name, acronym and code<\/li>\n
      3. and best of all: editing the railway line also recalculates the mileage and distance from the tracks.<\/li>\n<\/ol>\n

        Of course, everything can be done in a browser, QGIS, and via a mobile application, and finally exported to an SHP file and sent… wherever it needs to go.<\/p>\n

        Why is that?<\/p>\n

          \n
        1. To minimise the risk of errors,<\/li>\n
        2. Minimise the amount of work<\/li>\n<\/ol>\n

           <\/p>\n

          All this without a single line of additional code, in the standard version of Usemaps. I encourage you to contact us and present Usemaps. <\/p>\n

           <\/p>\n