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

… 查看完整日記項目

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!

… 查看完整日記項目

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.

… 查看完整日記項目

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”:

… 查看完整日記項目

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 :

… 查看完整日記項目

Ç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 !!