also Brandenburg offers the data but just as text and has to be requested:
1 Like
I arranged several licence agreements for the Netherlands community.
There are several entity that give the order to shoot aerials, not only Het Waterschapshuis (beeldmateriaal.nl) and there paspunten GCP.
Others also give orders to fly, these fly-companies need a flightplan. Need paspunten GCP, that are measured in, often outsourced to a measure RTK GNSS company.
You could see more points on the ground, which are not open data.
On the download page you could download a single geotiff.
geotiff screenshot.
The service from PDOK makes .jpg for performance reasons, WMTS layer.
It is a project (short)name BM5 BeeldMateriaal5
In the meantime, the image project has entered its fifth cycle, hereafter referred to as the BM5 project.
hi,
the discussion turns now a bit from “let’s make ground control points” to “let’s import any other source”.
It would make to structure our activities so we end up with starting to do something and not just have talked about a lot of good ideas :).
so, how do you find it to learn from the mentioned sources what parameters they offer, so that we can import them to OSM. And also to be able to use different formats of parameters from the many sources and have one interoperable system. What I saw from Bavaria and Brandenburg, that it starts with the license under which their data can be used. And it ends with how they name the parameters.
Let’s find matching parameters in the different sources that they all have in common.
Andreas
As I wrote before I do not want to import, all.
The above link Geodätischer Referenzpunkt Bad Tölz has a tag.
note Do not move this point!
The essence of the node
We can not rely on, that the point is not moved on OSM, therefore there must be a tag with the source long lat and coordinate reference system (CRS) or/and a tag with a coordinate reference system (CRS) of choice, EPSG ?
So that we always can check if the node is not moved. Margin, a small deviation. (conversion calculation and number roundings)
Therefore the official data is needed.
If we want the node data to be useful.
This node have more in it than others to be on the right place.
Then we need tags to do so.
ele:wgs84 693.191 m
The elevation is set in a tag ele:
The long lat is set in the description tag, which is not the right place, other key(s) should be used, a new one? format.
description 47°45.62141’ 11°33.44861’ ETRS89 47.76035679° 11.55747689° ETRS89
Because of this we need the official long lat data.
On site survey or from a site (open data).
Not a import is the goal but correct, useful data.
If there is any data, a licence check must be done to use it in Openstreetmap.
source Bayerische Vermessungsverwaltung, CC BY 3.0 DE
Is there a licence agreement with Bayerische Vermessungsverwaltung?
Or are all these points collected with on site survey.
We need to know how the data has been acquired in order to have a proper control, this must be clear from the key selection.
BTW: It is now one year later, when we had the OSM.to project at NASA’s SpaceApps Challenge.
Starting this weekend, the 2022 edition will start and maybe some people here would like to code for it tomorrow.
We will meet in the chat linked here https://twitter.com/SpaceAppsStgt/status/1574655052479881216
And as every open-source project, you can also just code for it and add a pullrequest or do your own version of it. Anything is cool that would bring OSM.to like QR-Codes forward.
See you tomorrow,
Andreas