Monumentale bomen in Leeuwarden

Communities Nederland (Netherlands)
1

Bij het mappen van parken en gemeentegroen stuitte ik op een open dataset (CC0, bevestigd door de gemeente) van de gemeente Leeuwarden waarin alle monumentale en gedenkbomen van de gemeente staan. Omdat deze dataset soortnamen, plantjaar, en monumentale status markeert naast de locatie, ben ik aan de gang gegaan met de data om ze om te zetten naar een dataset die in JOSM ingelezen kan worden.

Dat is inmiddels gelukt: https://github.com/jdhoek/bomen-leeuwarden-osm

Het doel van deze data is om mappers in Leeuwarden toegang te geven tot een dataset met alle monumentale en beeldbepalende bomen, zodat we bij het mappen van een stukje stad ze er zo bij kunnen pakken met de juiste tags (vooral voor soort is dat erg handig). In eerste instantie gaat het om twee mappers, maar wie de set gebruiken wil kan natuurlijk meedoen.

Voor de duidelijkheid: het gaat hier dus niet om een geautomatiseerde/handmatige import waarbij in een klap 2000 bomen geüpload worden.

Van alle bomen die we uit de set over willen nemen bevestigen we het bestaan eerst zelf. Ze gaan dus altijd mee met een normale changeset waarin een stuk stad verbeterd wordt. Waarschijnlijk pikken we steeds de bomen op prominente locaties eruit.

Wat moet ik verder nog aan documentatie doen om deze set te mogen gebruiken?

Bij een geautomatiseerde import moet er (terecht) veel meer gedocumenteerd worden, plus overleg op de Imports ML. Hoe ver moeten we voor deze dataset gaan? Volstaat een pagina op de wiki?

Zijn er nog dingen die beter kunnen?

Naar aanleiding van feedback op het Q&A forumdeel heb ik de soortnamen aardig nauwkeurig getagged. Mis ik nog iets?

2

Transformatiemethode

Is de brondataset in EPSG:4326 (WGS84) of EPSG;28992 (Rijksdriehoekscoördinaten, kortweg “RD”, het officiële Nederlandse coördinatensysteem)

Er zijn verscheidene transformaties beschikbaar om RD om te rekenen naar WGS84, mij lijkt het belangrijk dat de juiste wordt gebruikt om later niet te lopen prutsen met kleine afwijkingen en dingen die niet op elkaar aansluiten.
De BAG import plugin en JOSM gebruiken EPSG:4833, de meest recente transformatie afkomstig van de Nederlandse Commissie voor Geodesie.
Echter gebruiken beiden wel een specifiek afgeronde versie van EPSG:4833, want de originele transformatie parameters moeten omgerekend worden naar een +towgs84 string voor Proj.4.
Het lijkt mij verstandig dat we hier consistent in zijn en exact dezelfde transformatie als de BAG-import plugin gebruiken, namelijk;

+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725

JOSM gebruikt zelf overigens een anders afgeronde +towgs84 string, wat misschien enigsinds problematisch is, maar dat punt is voor een andere keer, laten we maar vasthouden aan de BAG import plugin.

3

Ik weet dat er in Utrecht ook zo’n dataset is en ongetwijfeld in meer gemeenten. Ook heeft bomenstichting.nl en landelijke registratie. Misschien is het mogelijk om een standaard af te spreken voor de source en source:ref tags, wat het eenvoudiger zou maken om in de toekomst wijzigingen bij te houden. Op https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree wordt nog voorgesteld om monument=yes toe te voegen.

4

De source en source:ref zijn nu lokaal voor deze dataset. Ik heb geen controle over de ref-waarde; die is door de gemeente toegekend. Ik hanteer ze zodat ik bij een update van de brondata makkelijk een controle kan doen.

Ik twijfel nog tussen monument=yes en denotation=natural_monument. Vooral omdat monument=* geen documentatie heeft.

JOSM heeft de coördinatenconversie nu gedaan. Is dat problematisch?

5

Dit is de projectie die de brondata gebruikt:

PROJCS["RD_New",
    GEOGCS["GCS_Amersfoort",
        DATUM["D_Amersfoort",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]
        ],
        PRIMEM["Greenwich",
            0.0
        ],
        UNIT["Degree",
            0.0174532925199433
        ]
    ],
    PROJECTION["Double_Stereographic"],
    PARAMETER["False_Easting",155000.0],
    PARAMETER["False_Northing",463000.0],
    PARAMETER["Central_Meridian",5.38763888888889],
    PARAMETER["Scale_Factor",0.9999079],
    PARAMETER["Latitude_Of_Origin",52.15616055555555],
    UNIT["Meter",1.0]
]

Ik wil best wel doen wat de BAG import plugin doet, in plaats van JOSM. Waar staat de broncode?

6

.
Die is naar mijn weten - net zoals de plugin zelf - niet vrij beschikbaar.

Gezien die WKT CRS definitie wordt er inderdaad RD gebruikt door de brondataset.
De BAG import plugin gebruikt de transformatie die ik voorheen noemde, en rond daarna de resulterende WGS84 lat/lon coördinaten op 7 decimalen na de komma af. De OSM database kan meer decimalen na de komma ook niet aan. Dit betekend dat je op ±11,11mm afrond in de N-Z richting en in de O-W richting maximaal ±5.56mm

7

Hoe krijg ik die transformatie voor elkaar als ik JOSM niet gebruik voor de conversie? Als ik de WKT string gebruik in Proj (via pyproj) zonder extra transformatie dan zit ik er tientallen meters naast:


Invoer: 579564.12 182275.913 

Geeft:     53.20313657853  5.79588350592  
Moet zijn: 53.2020250823   5.79539061988

Als ik van de WKT string de Proj-parameters maak (gdalsrsinfo) krijg ik hetzelfde, dus dit klopt:

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs

Maar als ik daar die transformatie-instructie achter plak krijg ik onzin:

+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725

Wat is dan wel de juiste Proj-aanroep?

Raar. Past niet bij een opensoftwareproject. Dan maar weer even het wiel opnieuw uitvinden. :frowning:

8

Ja helaas. Het komt vooral omdat men niet wilt dat iedereen zomaar BAG imports kan uitvoeren. Het is ook wel enigsinds logisch, je hebt eigenlijk nogal wat kennis van de BAG, GIS, geodesie en landmeetkunde nodig om echt goed BAG imports uit te voeren. Maar dat terzijde, de correcte Proj4 string is:

+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs

Misschien dat je https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py nuttig vind.
Als het goed is kan je die als volgt aanroepen om bijv. “example.gml” (dat in RD is) om te zetten naar “example.osm”.

ogr2osm.py example.gml --never-download --no-upload-false --significant-digits=7 -p "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs" -o example.osm

De significant digits zijn belangrijk voor de juiste afronding. Zonder de --significant-digits wordt het vanzelf afgerond in het upload proces naar de server, als je het vervolgens weer download ligt het op zijn afgeronde plek, maar voor analyses en vergelijkingen in JOSM zelf lijkt me het het handigst om de afronding van te voren te doen, om verwarring te voorkomen.
Als je niet van te voren af rond zul je verschil zien tussen de lokale dataset en alles wat je net hebt geupload naar de OSM server, zodra je dat weer download.

Zie overigens ook mijn recente discussie in https://forum.openstreetmap.org/viewtopic.php?id=65347

9

Ah, ik zie wat ik fout deed. Nu werkt hij.

Ik krijg niet echt andere data dan met de JOSM-route, maar de het is wel fijn om zonder JOSM de OSM XML te kunnen bouwen vanuit de brondata. Dat maakt de broncode een stuk betrouwbaarder.

Dus zeven cijfers achter de komma voor X en Y?

10

Naar mijn praktische ervaring kan de JOSM transformatie grofweg een centimeter afwijken van de BAG import plugin transformatie, wat naar mijn mening toch wel problematisch is.

11

Correct, de WGS84 lat/lon coördinaten worden beiden afgerond op 7 cijfers na de komma.

Dit volgende staat dan ook op de wiki:
"Do not use IEEE 32-bit floating point data type since it is limited to about 5 decimal places for the highest longitude.
A 32-bit method used by the Rails port is to use an integer (by multiplying each coordinate in degrees by 1E7 and rounding it: this allows to cover all absolute signed coordinates in ±214.7483647 degrees, or a maximum difference of 429.4967295 degrees, a bit more than what is needed).
For computing projections, IEEE 64 bit floating points are needed for intermediate results.
The 7 rounded decimal places for coordinates in degrees define the worst error of longitude to a maximum of ±5.56595 millimeters on the Earth equator, i.e. it allows building maps with centimetric precision. With only 5 decimal places, the precision of map data would be only metric, causing severe changes of shapes for important objects like buildings, or many zigzags or angular artefacts on roads. "
https://wiki.openstreetmap.org/wiki/Node

12

Mwah, voor een boom zal het niet veel uitmaken. :slight_smile:

Bedankt voor de hulp.

13

Nee dat klopt, maar voor de homogeniteit van de transformatie van OSM naar RD en andersom is het wel heel belangrijk :stuck_out_tongue:

14

Misschien aardig om hier te noemen: bomenkaart voor park in Leiden op basis van OSM: http://infodisiac.com/bomen/groenesteeg.html

15

Dat is best enthousiast ingetekend. Leuke OSM toepassing.

16

Mooie kaart, alleen “Wijs boom aan voor naam” doet het bij mij niet?
En een geweldige standerdmolen op de foto! Met onzichtbare wieken door de lange belichting :slight_smile: