OpenStreetMap merkið OpenStreetMap

Blogg frá StephaneP

Nýlegar bloggfærslur

RTKBase v2 is available for your GNSS Base Station

Sett inn af StephaneP 16. júní 2020 á English. Síðast uppfært 2. júní 2024.

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)

Raspberry Pi Gnss Base Station

GUI Tour:

Video

Sjá alla færsluna

You thought OpenStreetMap data uses the WGS84 datum? No it doesn't!

Sett inn af StephaneP 17. júlí 2019 á English. Síðast uppfært 2. júní 2024.

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!

Sjá alla færsluna

How to highlight high-precision GPX traces?

Sett inn af StephaneP 23. maí 2019 á English. Síðast uppfært 2. júní 2024.

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

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.

Sjá alla færsluna

RTK test, Aerial pictures accuracy, and OSM Database Accuracy

Sett inn af StephaneP 11. september 2017 á English. Síðast uppfært 2. júní 2024.

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

Sjá alla færsluna

Construire son V4MPod pour prendre des photos à 360°

Sett inn af StephaneP 21. september 2016 á French (Français). Síðast uppfært 2. júní 2024.

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

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

Sjá alla færsluna

Limites communales terminées

Sett inn af StephaneP 5. desember 2013 á French (Français). Síðast uppfært 2. desember 2021.

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

santé

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

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.

Staðsetning: Le Patis, La Bruffière, La Roche-sur-Yon, Vendée, Pays de la Loire, France métropolitaine, 85530, France