@Alexey

Nothing new since this diary, but there are some tickets in Josm to recognize single/float/fix inside nmea and gpx files. That’s a good start. https://josm.openstreetmap.de/ticket/20600 https://josm.openstreetmap.de/ticket/20601

Hi Adrian,

Just to let you know that most base station on the centipede network use RTKBase, which is developped by …. an Osm Contributor… me :-)

@ndrw6 The rover was about 4km from the base station. With dual frequency receivers (base + rover) you can get a very good accuracy, up to 60km. The rover was a Zed-F9P with an arduino-like (Adafruit Feather M0 Adalogger). You can’t post-process a gpx, because all the useful informations are already gone. You can post process a base/rover setup or use them in real-time. I usually post-process, because I can test everything I want with RTKLib, and I don’t have to worry if my phone doesn’t receive the base data.

@Glassman Sorry, but I don’t know any low cost dual-frequency gnss receiver ready to use (with battery, case, bluetooth….). You have to build one yourself. When you have such a receiver, you can use it in realtime or only log the raw data and postprocess later. In realtime, you can use the receiver internal engine if you feed it with the base data, or the android app Rtkgps+ (it’s not 100% compatible with the F9P). This is a Rtkgps+ that “should” work with the F9P : https://github.com/jancelin/RtkGps/releases

Je ne sais pas. En tout cas, elle est visible ici : https://cycling.waymarkedtrails.org/#?map=8!46.9647!-1.3455

La relation master est celle-ci : https://www.openstreetmap.org/relation/4774799

Depuis celle-ci, on retrouve les différents morceaux comme celui-là par exemple : https://www.openstreetmap.org/relation/4840316

Bonjour Clément,

Interessant tout ça !! Je pense que ce que fait jungle bus devrait t’interesser aussi :

https://junglebus.io/

@Cameron Shorter Your draft is very interesting. I will follow it and the proj mailing list too.

@SimonPoole

we are using sources that are not actually using WGS84 and are offset to it

Exactly! I think that the first thing to do is a “state of the aerial imagery”. We have to know where the data are not using WGS84 coordinates, and the first step is to add some reference marks in every country with high res imagery: https://wiki.openstreetmap.org/wiki/Survey_points_on_aerial_imagery

@Warin61 What do you mean with “plate tectonic references”? There are 2 Coordinate Reference System type: Earth fixed (WGS84), and plate fixed (local datum like GDA94, NAD83, ETRS89 ….) The problem is that Osm is mixing the 2 types: Plate fixed coordinates in a earth fixed database.

If the GNSS receiver you use today is not accurate, some recent smartphones include a dual frequency receiver. Sub-meter accuracy in our pocket is just a matter of a few years.

@Harry Wood I had completely forgotten this April fool :-)

If we do nothing with the Australian data, we will see Osm contributors going to waste thousands of hours fixing everything with GDA2020 aerial imagery whereas they could use this time to add new data. I think it’s a big concern.

Here is a 1.8m offset:

Très intéressant ! N’hésite pas à faire d’autres retours lors des prochaines sessions.

As this gnss station is in the IGS network, we can download the observation data, and then use an online service to compute a PPP solution. The AUSPOS service gives back the coordinate with several datums. Here are the results from 2018-03-31 with GDA94, IRTF14(2018) and GDA2020 datums.

I’m more and more confident that this aerial imagery isn’t using an actual WGS84 datum…like the french aerial imagery, and potentialy many others.

I finally found a “mark” in Autralia, a gnss station. Go to http://www.ga.gov.au/ngrs/ Then search for a NGDB station, select GDA94 datum and type stromlo glonass in the “name” field. Then you can copy/paste these GDA94 coordinates in Josm (S35°18’ 58.19897” E149°0’ 36.54767”) to add this node. Just add one of the available imagery layer and look at the result:

We should check other survey_points to confirm, but It seems that the imagery use the GDA94 datum, not the WGS84, or we would see a 1.7m offset.

We know when the node was added in the database, but it doesn’t say what is the original datum epoch. And If the contributor add a node from an aerial imagery, we have to know what is the wms/tms datum….and it’s not an easy task (I spent a lot of hours trying to find the real datum of various Australian imagery).

I know that some of you are thinking that I’m splitting the hair, and it is likely right for today. But in the future we will have to manage these problems.

about gpx: I’d like to be able to add an attribute, as easily as in OpenStreetMap, but the gpx would be invalid and the attribute would be simply ignored. I’ve sent a message on the gpx dev mailing list.

Yes, that’s fast, and they are moving to a new plate-fixed datum: GDA2020 https://www.researchgate.net/publication/319454295_GDA2020_AUSGeoid2020_and_ATRF_An_Introduction

@smaprs It’s not 7mm/year, but about 70mm.

I tried to find which datum is usually used on australian aerial imagery, but I didn’t find a real answer. It’s GDA94, GDA2020, or WGS84. On the talk-au mailing list, I found this old message (2009) from an aerial imagery provider, Nearmap: https://lists.openstreetmap.org/pipermail/talk-au/2009-December/004656.html The today Nearmap website says this about accuracy: https://docs.nearmap.com/display/ND/Accuracy

I think it’s easier to create data on a plate-fixed datum, and move these data if you want to display them with another datum.

If you want to do the opposite, you have to store the original date and compute the delta for every single node in the database.

@SimonPoole Which attribute seems ok for you to store the point accuray?

@SimonPoole Do you know how the australian contributors manage this? Is their aerial imagery locked to a local datum or if it moves with the tectonic plate?

We should think twice.

Let’s jump in 2030 or 2040.

-2cm/pixel Aerial imagery is a standard value and new capture campaign occurs every 1 or 2 years

Do you think that we will see the small offset between campaign epoch? I don’t. Each layers will be aligned to the local reference system as it is today.

Do you think that in the Osm world we should add this small offset ? And we should correct this offset every year ?

The answer isn’t so easy.

-Every smartphone integrated gnss receiver offers at least a half meter accuracy I don’t know it these receivers will display the coordinate in WGS84 or in the local datum. I just know that today, professionnal in GIS don’t use WGS84.

@SimonPoole I’m not responsible for these aerial tms/wms, I can’t do it.

My original post was more about finding a way to store the accuracy in gpx files, but all the comments are on the datum problem. I think I will create another diary to split the subjects.

@Andy The aerial imagery we’re using in France use the RGF93 datum. When I use an official gnss base to compute RTK position, this base transmits its coordinate within the RGF93 datum.

If accuray isn’t better than 1 meter, it doesn’t matter, but we use the RGF93 datum without knowing it.

I’m not sure, but I think it’s the same thing in many other countries because using a “moving” datum would be a nightmare.

I took a random aerial imagery in U.S. and the system is … NAD83, the local datum: https://njgin.state.nj.us/NJ_NJGINExplorer/ShowMetadata.jsp?docId=%7B188471FF-2803-4145-A5AD-605DE86D3B4D%7D

@nrdw6 Yes It was a surprise for me too, but now I think it’s normal: On the earth, nothing is really static. We are all living on a plate which is slowly moving. So the national geographic agency usually set a local reference system that move with the plate. If they didn’t do that, every point’s coordinates would change continuously. It’s not practicable.

It was not a big deal with standard gnss receivers and low to mid res aerial imagery, as we could not see this offset. But with better imagery, more accurate gnss receiver, we’re starting to detect it.

Usually, country reference system is based on ITRS, just like the WGS84, but locked to a specific epoch. RGF93 in France, is locked to ITRS from 1989. Since then, the eurasian plate is moving to nord-east at about 2 to 2.5 cm per year.

In the united states, the local datum is NAD83, but I don’t know if the osm data are in WGS84 or NAD83.

I think that at some point in the future, local datum will be updated, and we will have to move entire plate in the osm database. :-)

Wow !!! It could be very useful!!

So..don’t stop to write editor :-)

Beau boulot !

Il ne reste plus qu’à récupérer une caméra pour faire les 50% restants ☺️