What is RTKBase?

It’s a software to manage a Gnss base station. It’s a fully Open Source Software and it’s available here: https://github.com/Stefal/rtkbase

What is a Gnss base Station?

It’s a permanent and fixed Gnss receiver with known accurate coordinates. A base station is needed when you want to get centimeter accuracy with RTK.

New Features:

• Web Gui
• Automated installation
• Automated setup for usb connected Ublox F9P
• Satellite levels
• Map
• Settings
• Update from the Gui.
• Manage Raw data
• Multiple simultaneous streams (Raw/Rtcm/Ntrip)

GUI Tour:

Video

Example:

Here are 15 “gpx” traces made with a RTK rover on my car, and my Base station.

More precisely, the WGS84 Datum is not used everywhere.

Here is some background:

• The WGS84 Coordinate Reference System uses an ITRF datum, locked with the Earth’s rotation.

• The tectonic plates we’re living on, are moving, up to 70 to 80 mm/year for the Australian plate, 20 to 25 mm/year for the Eurasian one.

• The tectonic plates have internal distortions (we do ignore them here)

If you have a very accurate GNSS receiver which shows you WGS84 coordinates, and place it on a survey mark, because this mark moves, you won’t get the same coordinates year after year. If you surveyed a mark in Australia 13 years ago, today’s coordinates are 1 meter off. So, accurate WGS84 coordinates are not accurate at all if you don’t know the epoch, just as a time value is unuseful if you don’t know the time zone. Working with dynamic coordinates would be a nightmare for the surveyors. To make their life easier they use a datum associated with their continental plate, locked at a point in time. And for a few decades now, many countries have chosen an ITRF datum and “locked” it at a specific date. With such a datum, the coordinates of survey marks remain the same over the years.

• USA is using NAD83

• Australian is using GDA94 (ITRS epoch 1994.0)

• Europe is using ETRS89 (ITRS epoch 1993.0)

• France (in europe) is using RGF93, a more accurate ETRS89 realization. We consider that RGF93 = ETRS89.

You could object this is not an OSM problem : we use gpx trace, aerial imagery, opendata sets, all with WGS84 coordinates!

• At first, don’t forget that a WGS84 datum without epoch can’t be accurate at a submeter level.

• Secondly, if you use a standard GNSS receiver, it doesn’t matter, as your accuracy is too low (3 to 5 meters). If you use RTK, like I do, your datum is the one used by the base station, and it’s usually plated-fixed.

• Thirdly, if your aerial imagery has a low resolution like 50cm/pixel, it will be very difficult to see small details.

However, we have more and more high-res imagery. In some places, you can see some survey marks and check the coordinates. Let’s go to Australia, next to the Mount Stromlo Observatory. This node is a GNSS antenna, part of the IGS network. You can go to the Geoscience Australia website to find the GDA94 coordinates of this antenna and enter them in JOSM with the “Lat Lon Tool”. Then, if you switch between the 3 good imagery (ACTmapi Imagery 2017, ACTmapi Imagery 2018, LPI Nsw Imagery), you will see that the antenna, the node with the GDA94 coordinates, and the 3 imagery layers, are aligned:

Ok, but what are the WGS84/IRTF coordinates for this antenna? Luckily, you can download the data from this GNSS station and process them with a PPP software. The Australian online AUSPOS service gives you the PPP results with GDA94, GDA2020 and IRTF (@epoch data) coordinates. Here are the locations, more than 1.5m to north-east: !!

The conclusion is that these imageries are not using an IRTF datum, but the local one: GDA94. Therefore any OSM data created using these layers are not in WGS84.

Now let’s go to France, to this node : https://www.openstreetmap.org/node/670517301

This is a survey mark with coordinates using RGF93 datum and the accuracy is better than 10cm. The alignment is good. We can say that this imagery layer use RGF93, not WGS84, or we would have seen a 70 to 80 cm offset. I’ve checked check some other survey marks in the country…all aerial imagery are RGF93/ETRS89.

This is our first problem: Some OSM data are not using WGS84 coordinates ; the offset could be as high as 2 meters.

Our second issue is: How do we guarantee a good accuracy over the years?

Here are a couple of options.

1. We keep using local datums.

   • This is simple, but we don’t want too many datums: perhaps we should select a single datum for each tectonic plate.

   • Aerial imageries with the same local datum remain aligned.

   • We should inform data consumers, so that they can decide to convert the coordinates to WGS84 if they want to.

   • We will need to move a lot of data when a new datum replaces an old one (more on that later)

2. We convert all data to an ITRF datum.

   • We must convert data with local datum (Australia, France, …) to WGS84. This is not an easy task, but this is feasible with a plate motion model.

   • The date a node is created in OSM doesn’t inform about the original epoch.

   • Should we keep the old aerial imageries to their original location, or transform them to today’s location? It could be difficult for the editors (Josm, ID, …) to do this if there is a translation and a rotation.

   • When you load data in an editor, it should check all nodes coordinates, find the epochs, and dynamicaly move them to the actual localization with an Helmert transformation. It would be the same problem if you want to reuse the data. Another way is to create a bot which moves all the nodes in the database regularly (twice a year?).

   • Prone to errors

Whatever the decision is, we should check what is the real datum of all high-res imagery. To do so we need more reference points that are visible on one or more imagery. These could be a survey mark on the ground with public and accurate coordinates, or a GNSS antenna on or near the ground (we can’t use an object on a roof) with observation data freely available. I’ve already started a list on the wiki, feel free to add more reference points. A new tag on these nodes would be useful.

Let’s go back to Australia: The Auspos service provides GNSS coordinates with 3 datums : GDA94, WGS84 and GDA2020. What is the last one? As you know, the Australian plate is moving pretty fast. In 2020 the offset between GDA94 and the real location will be more than 1.8 meters. They decided they will use a new datum from 2020: GDA2020 It means that new high-res aerial imagery in this country will have a big offset relative to the old imagery. They will use a dynamic reference frame too, but I’m not sure it will be used by the GIS world: ATRF

Another country will change its datum : the U.S.A., with the plate-fixed NATRF2022, in replacement of NAD83.

Summary:

• On Earth, everything is moving, up to 80mm/year.

• A fix point on a tectonic plate will see its WGS84 coordinates changing over the years, but the same point have static coordinates with a plate-fixed local datum.

• WGS84 coordinates without epoch can’t be accurate.

• Contrary to what is stated, not all OSM data are using a WGS84 datum. In some country, the offset could be as high as 1.8 meters.

• Some aerial imagery are not using a WGS84 coordinate reference system, but a local datum.

• What should OSM do? Keep the dynamic WGS84 coordinates, or use some local datums as the surveyor’s world do?

Thank you to naomap for his help with the translation.

I have been testing precision localization for a few years now using RTK, PPP calculations, and RTKLIB. Since a few weeks, I have my own GNSS base, which allows me to generate gpx traces with an accuracy of a few centimeters, or a few tens of centimeters. Here is an example of about 15 overlapped gpx traces:

I think I’m not the only one interested in high-precision localization, and the arrival of smartphones with dual-frequency gnss receivers will probably accelerate the movement, which is a great thing for OpenStreetMap. Of course, I send these traces to the Osm servers, and they are available for everyone.

The problem is that theses gpx are mixed with the others, look at this: At this time, I don’t know how contributors can know that they are of better quality, I don’t know how to “enhance” them.

How could we do that?

• The GPX format does not store information on point accuracy, but allows you to add private namespaces. However, everyone must use the same one. I don’t think it’s a good idea.

• On the developers’ discussion list, there was mention of a version 2 of the gpx format, but the last message was almost a year ago.

• The files generated with Rtklib are .pos files that include all the necessary information. Could the database handle this format?

One last point: - by default, the coordinates of the gpx files must be in the WGS84 system. The problem is that Osm data is not necessarily in this system, but rather in the datum used locally. In France, it is the RGF93, which is derived from the European ETRS89 datum. I think that all European data are in ETRS89 and not in WGS84. There is currently a gap of about 70cm between ETRS89 and WGS84, and this is gradually increasing. So, the GPX traces I send to the Osm servers are not in WGS84, but in ETRS89. I do not respect the GPX standard. I think it should be possible to specify in the gpx files the used datum.

What do you think about this?

RTK accuracy

Since 1 or 2 years, I’m testing some low-cost GNSS receivers with RAW output. The goal is to get a cm accuracy. One way is to store the raw data, then post-process it with the open-source software RTKLIB. I had various fails and success and I finally find a point to place my own reference station, my “base”:

One test was to put the “rover” on my car go back to my home. RTKLIB gave me a solution with “FIX” for a big part of the record : orange is “float” and green is “fix” (best accuracy)

An interesting part is a new roundabout, too new to see it on any aerial picture :

Ok, but what about the accuracy ? So, zoom in, zoom in, ….. zoom more !! Each square is 1 cm. Yes, the accuracy is about 1.5 centimeters !!

RTKLIB gave me a very good accuracy, but is this real ? I can’t answer for this individual point, but with the results I got on surveys points from the French national geographic institute (IGN), I think I can say that the accuracy should be at about 5 or 10 cm, as my base coordinates are not perfect.

RTK vs Aerial Imagery accuracy

We are in September 2017, and the IGN just published new aerial imagery, and they usually do a very very good job. Finally I can see the roundabout I draw on OpenStreetMap 1 year earlier.

Let’s compare my recording and the pictures:

Hey ! Not bad !! Now I must train to drive with a centimeter accuracy :-)

OpenStreetMap database accuracy

I speak about gnss trace accuracy, aerial imagery accuracy, but what about OpenStreetMap accuracy ? I heard that with 7 decimals, the coordinates stored in the OpenStreetMap database get only a 10 cm accuracy. Don’t you think that It’ll be a problem sooner or later ?

Perhaps we should consider adding a 8th decimal ?

Cartographier l’intérieur d’un bâtiment peut être une tâche très complexe, surtout s’il s’agit d’un environnement chargé de nombreux éléments comme…une gare… et c’est exactement ce qu’on m’a demandé il y a quelques mois, puisque Carto’Cité m’a sollicité pour le projet de la SNCF-Transilien consistant à cartographier dans OpenStreetMap l’intérieur des six grandes gares de Paris

Pour faciliter le repérage des différents éléments (services, commerces, guichets, etc…), il était évident qu’il fallait pouvoir prendre des photos à 360°. Les quelques produits disponibles sur le marché étaient soit de qualité assez moyenne, soit bien trop cher.

J’avais déjà 2 petites caméra, alors j’ai décidé d’en ajouter 2 autres et de fabriquer ce qui est devenu le V4MPOD :

Je viens de publier le guide complet permettant de le fabriquer toi-même, il comprend :

• La fabrication de la tête
• La configuration des caméras
• Le logiciel nécessaire au contrôle des caméras depuis un smartphone Android
• La méthode que j’ai utilisé pour géolocaliser les photos en indoor.

Construire son V4MPod pour prendre des photos à 360° - Partie 1

Construire son V4MPod pour prendre des photos à 360° - Partie 2

I hope to have an english guide soon. If you want to help to translate, contact me.

Ça y est !

Le chantier, commencé en 2008, s’est terminé hier, après 7 mois de travail intensif sur les planches rasters des communes non vectorisées. Tout cela à l’aide de l’outil de collaboration Mapcraft.

Vincent_95 en a profité pour nous faire une magnifique vidéo de l’évolution de ces tracés depuis 2008 : OpenStreetMap - Les limites administratives françaises (French administrative boundaries)

Un grand bravo à nous tous !

Tchin !!!

Je n’avais pas regardé mon “compteur” d’erreurs relevées par Osmose depuis longtemps lorsque je me suis rendu compte qu’il dépassait les 500.

Aïe !!

Hop ! Au travail !

Seulement voilà, en corriger une en crée souvent plusieurs autres. Il suffit de toucher à un cours d’eau pour se rendre compte du résultat quelques jours plus tard, les intersections de highway et waterway, augmentent en flèche. Et c’est sans parler des “riverbank sans waterway”. Corriger tout cela prend du temps, mais j’ai réussi à descendre aux environs des 200 erreurs.

Mon objectif : descendre aux environs des 100 erreurs, et vérifier régulièrement ce compteur pour ne pas laisser filer le “score”.

Et voilà, après plusieurs semaines de dur labeur, il n’y a plus d’erreur de batiments superposés dans les pays de la loire. Maintenant, si quelqu’un réalise un import du cadastre sans contrôle, ce sera visible très rapidement.

http://osmose.openstreetmap.fr/utils/info.py?source=208

Je corrige petit à petit les bâtiments superposés aux alentours de ma zone habituelle de mapping. Je constate que sur la commune de La Bruffière (85), le bâti importé est souvent décalé par rapport à ce qu’affiche le plugin cadastre.

Comment est-ce que cela a pu avoir lieu ?

J’ai commencé à recaler certains bâtiments, mais j’ai l’impression qu’il sera plus rapide pour moi de tous les supprimer, et de refaire un nouvel import.

Mai 2011 : Je découvre OSM par l'intermédiaire de X-Plane qui va utiliser cette base. Je me rends compte qu'il manque pas mal de routes et d'informations par chez moi (près de Clisson).
Aller ! On regarde comment ça fonctionne, et on ajoute un truc par ci, un truc par là.

Mince, c'est addictif !!