09/04/2026-15/04/2026

Mapping

• Comments are requested on this proposal:
  • terminal=yes to consistently map freight terminals and better describe connected transport modes and handled cargo.

Mapping campaigns

• A new MapRoulette challenge in Germany uses Mapillary-detected traffic signs to identify and add missing access restrictions in OpenStreetMap. The initial focus is on German regulatory signs such as DE:260.

Community

• Raquel Dezidério blogged about her participation in ‘Mapping Together’, a virtual meeting of the MapYourGrid project, representing the Virtual Institute for Sustainable Development – IVIDES.org (Brazil). The overall objective of the meeting was to demonstrate the structure of Wikidata and discuss improvements to the connection between the MapYourGrid web map, Wikidata, and Wikipedia, which have been adopted to document objects related to the power distribution network map using OpenStreetMap. The project is maintaining the osm-wikidata-toolset repository on GitHub and invites you to map what is missing for your country on OSM.
• A message from CasGroenigen on the OpenStreetMap Community forum warned of possible incorrect OSM edits related to a Pokémon GO event targeting specific landscape types. Mappers are encouraged to monitor their areas and check suspicious changes using tools such as OSMCha.
• On Mastodon users have discussed open-source Android apps for cycling, including OsmAnd, CoMaps, BikeRouter, and FitoTrack. The conversation also highlighted a request for a dedicated cycling layer in CoMaps.
• Pierre-Yves Beaudouin tooted that OpenStreetMap is now available as an official icon in FontAwesome. This makes it easier to integrate OSM into web applications and designs.
• rphyrin noticed that MapComplete’s recent new feature of adding pictures to reviews is very relevant to a September 2025 discussion thread by boramalper regarding a crowd-sourced review service for OpenStreetMap.
• Andy Townsend explained how vector tile processing performance can be improved by reducing data volume, for example by delaying the display of smaller features. The changes halved tile sizes and highlight the importance of cartographic generalisation for both performance and readability.
• Christoph Hormann examined the development and use of tags related to the key waterway in OpenStreetMap. Despite regional differences and ambiguities, the analysis shows that the classification, which has evolved over time, remains widely used and functional.
• Ruslan Fatih, an OpenStreetMap contributor from Kazakhstan, shared ► how he got into OpenStreetMap (and why ‘scary maps’ turned out to be the most useful hobby).

Imports

• Sweety_Kumar stated on the OpenStreetMap Community Forum that students from IIT Delhi propose importing hydrology data from the CoRE Stack project, such as watersheds and water bodies, into OpenStreetMap. The ultimate goal is to improve accessibility further to enable analysis and collaborative enhancement within the OSM ecosystem.
• The Kanach Yerevan initiative has proposed importing around 11,000 mapped urban trees into OpenStreetMap, based on volunteer field surveys. The dataset includes species and size information and is planned to be integrated gradually following import guidelines.

Events

• Bastian Greshake Tzovaras presented how CoMaps can be used for humanitarian use cases with the open technology and innovation working group of Humanitarian OpenStreetMap. The presentation slides are available online.
• The State of the Map Baltics 2026 conference will take place on Thursday 4 June in Riga, bringing together the OSM and GIS communities from Northern and Eastern Europe. Participation is free and talk submissions are encouraged.
• thapa prativa reported on Nepal’s Inclusive Mapping Week 2025; at the inaugural event there were over 400 participants who learned, mapped, and collaborated with OpenStreetMap. A key focus was humanitarian mapping and the encouragement of women’s participation in the geospatial space.

Education

• More than 20 students from a high school in Pesaro (Italy) have mapped their town in OpenStreetMap as part of a school project, making over 30,000 edits within two months. The initiative was proposed by their teacher Galessandroni to promote local mapping through hands-on contribution.

Maps

• The OpenStreetMap Ops Team reported that the standard map layer on openstreetmap.org is now running OSM Carto version 6.0.0 (we reported earlier).
• Daniel Dufour wrote, on his LinkedIn account, about the Chattanooga Area Regional Transportation Authority Route 4, a web map created with OpenStreetMap, MapTiler, JavaScript, and maplibre, which traces a route with its stops and buses. The source code is available on GitHub.
• Steven Feldman has published a map gallery on the KnowWhere portal, showcasing a series of experimental mapping projects. Each project includes reflections on what worked, what didn’t, and tips for others creating their own maps.

OSM in action

• Hans on the Bike showed that KLM uses OpenStreetMap data in its onboard displays for in flight map visualisations.
• mackerski described how he used ChatGPT to record GNSS track logs directly from a car browser to map the Dublin Port Tunnel. He worked in collaboration with Guillaume Rischard and the solution was tested on a Tesla model 3 and a Volvo XC90. The experiments show that even without GNSS signals, dead reckoning can produce useful data, and highlighted potential improvements to the OSM track logging workflow.

Open Data

• The New York MTA has released new open datasets on bus routes and stops, which they have combined with speed data to analyse and visualise bus traffic flow in detail.

Software

• The BRouter project, a configurable OSM offline router with elevation awareness, announced an upcoming server migration introducing the new lookups.dat version 11.1, additional pseudo-tags, a modernised library, and improved elevation data. The changes can already be tested on a preview server, with a new app version also planned.
• CoMaps has received a trust score of 9.6 from European & Open Source Alternatives, making it one of the top-rated map alternatives alongside OpenStreetMap.
• Oliver Wipfli reported on the progress of the open-source Mapterhorn project, which provides global terrain data as PMTiles and is now widely used (we reported earlier). The pipeline uses Copernicus GLO30, a global 30 m resolution dataset, as a baseline and refines it with local models. A new grant from the NLnet Foundation (which distributes funding from the EU Commission) will improve the pipeline to include open aerial imagery, as an extended project titled ‘Mapterhorn Imagery’ .
• OpenTrafficMap is a new project with a focus on visualising real-time data from traffic signals and C-ITS-enabled vehicles on top of OpenStreetMap. The current focus is on Graz (Austria), where a higher density of tracked signals and vehicles are already available.
• The OSRM API documentation has been refreshed with a cleaner design that provides easy navigation and covers all six OSRM services: Route, Table, Map Matching, Trip Planning, Nearest, and Tile. OSRM is a high performance routing engine for OpenStreetMap data and one of the most widely used in the world.
• The GNOME Maps project is working on displaying public transport delays using the Transitous and MOTIS APIs. In addition to scheduled times and real-time updates, status indicators will be taken into account. MOTIS is the acronym for the Modular Open Transportation Information System.
• Stadia Maps is offering a public preview of traffic-influenced routing based on OpenStreetMap, integrating real-time and historical traffic data. The feature targets use cases where accurate travel times, such as logistics and ride-hailing, are required.
• The ‘WillCycle GPS Art Generator’ allows users to turn drawings into real-world routes by matching them to roads and paths. It uses BRouter and OpenStreetMap data to generate GPX tracks for creative cycling routes.

Programming

• Cláudio Tereso demonstrated how OpenStreetMap data can be integrated via the Overpass API into Power BI to create interactive maps of wild swimming locations. Photos and additional information are also included.
• Thomas Derflinger has developed a Docker container to run your own local Overpass API instance. This stateless Docker container keeps OSM data on your host file system, while providing all the tools needed for data conversion and querying. It includes a simple shell script to download and ingest OSM data and it also runs on Raspberry Pi 5. The container does not implement updates from OSM. We reported on Roland Olbricht’s Docker container earlier and both Kai Johnson and Wiktor Niesiobędzki have their own versions.
• wielandb’s StreetComplete pull request proposed a new quest to capture the direction in which bicycles may travel on separate pavements and cycleways. The approach considers country-specific rules and visible signage to avoid incorrect data.

Releases

• [1] Ralph Straumann presented Terraink, a web application for creating stylised map posters based on OpenStreetMap data. It offers extensive customisation options for layout, colours, and content, targeting users who want to design unique maps for print or social media.
• Version 3.16 of OpenMapTiles brought improvements to the transportation layer, including better road connections, additional path information, and enhanced styling for roads and railways.
• Version 2026.04.07-8 of CoMaps updated OSM data and fixed several crashes, including issues with routing and edit uploads. It also introduced map style improvements, such as better road and tree visibility, and additional POI information.
• The April update of Organic Maps introduced elevation profiles for hiking and cycling routes, improved address search (especially in the US), and enabled seamless map rendering across the anti-meridian.
• MapComplete announced several new features, such as adding pictures to place reviews, a colour-coded maxspeed theme, and updates to the cycle-infra theme.
• Yohan Boniface has released version 3.7.3 of uMap. This update addressed an issue that occurred when cloning maps, where layer relationships were not copied correctly. In addition, a minor bug in the Docker configuration was fixed, so that nginx is now ready to use right away.
• OSRM version 26.4.0 brought multiple improvements, including enhancements to routing profiles (e.g., better handling of cycleway=* and sidewalk=* tags) plus various stability and build fixes. It also modernised the release process with automated monthly releases and a new versioning scheme.
• Marcus Jaschen reported that Bikerouter’s shortlink and QR code service has been migrated to a new server and that a new web service for generating route preview images has been developed. Both changes prepare for an upcoming feature: a built-in route manager that will allow you to store, organise, and restore planned routes on the server.
• Version 2.0 of Transportflow has been released ►, introducing a ‘radar’ feature that shows areas reachable by public transport within a given time. It is based in part on OpenStreetMap data alongside timetable and real-time information.
• Alexis Lecanu (aka ravenfeld) released version 1.21.0 of the Baba app, introducing automatic screen orientation based on camera sensors. This improves usability when capturing images, e.g., for Panoramax.
• Tiri, an independent developer based in Germany, reported on the OpenStreetMap Community forum that he is building Xopoz, an Android GNSS team tracking app for professional field teams, such as mountain guides, search and rescue volunteers, NGO field operations, and adventure tour operators. The app is built entirely on OpenStreetMap data with zero Google dependency and the geolocations are end-to-end encrypted.

OSM in the media

• The City of Seattle has temporarily removed its official bike map PDF in the wake of new accessibility requirements, according to an article on the Seattle Bike Blog. The article highlighted OpenStreetMap as an alternative, which offers more detailed and up-to-date cycling infrastructure and is continuously improved by the community.

Other “geo” things

• Attila Bátorfy wrote about Dutch ‘cartocubism’, a forgotten attempt to simplify maps from the interwar period.
• The website trainjazz.com uses subway train geolocation data to create a dynamic soundscape, where each train represents a musical note. The result is an ever-changing composition that even adapts to the user’s geolocation. Jake Z commented on kottke.org that there is a 10 year old application similar to this called Conductor, on mta.me, developed by Alexander Chen, where the New York subway system is turned into a string instrument.
• Brilliant Maps has published their ‘Map of Asia Made Up of its National Animals’. A similar map for European countries has also been published. Both maps were created by Ibis_Wolfieand and there is some discussion on Reddit about these maps.
• The article ‘Real Maps for Imaginary Places: a journey into the cartography of literature’, written by Neely Tucker and published on the Library of Congress’ website, highlighted how maps have long played a key role in literature, from Treasure Island to The Lord of the Rings. These maps help readers understand fictional worlds spatially and make the stories more tangible.

Upcoming Events

Country	Where	Venue	What	When
	Milano	Building 4A, Room Fassò – Politecnico di Milano	PoliMappers Maptedì	2026-04-16
	Freiburg im Breisgau	CCCFR, Adlerstr. 12a, Freiburg (Grethergelände)	OSM-Treffen Freiburg/Brsg.	2026-04-16
			OSMF Engineering Working Group meeting	2026-04-17
	Potsdam	Kellermann	Potsdamer Mappertreffen	2026-04-17
		Golem, Avane, Empoli	Mapping Day ad Empoli	2026-04-18
		Dijital Bilgi Derneği	OSM-TR Meet-Up – OSM League Pit-Stop	2026-04-18
			Mapping Resilience Across the Yamuna Basin (UN Mappers & The FOSS Club India)	2026-04-19
	Chennai Corporation		Mapping Party @ Chennai	2026-04-19
	Liège	ULiège-RISE	Understanding the OpenStreetMap ecosystem	2026-04-20
			Missing Maps London: (Online) Mid-Month Mapathon [eng]	2026-04-21
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-04-21
	Derby	The Brunswick, Railway Terrace, Derby	East Midlands pub meet-up	2026-04-21
	City of London	The Globe pub, Moorgate	London pub meet-up	2026-04-21
	Bonn	Dotty’s	199. OSM-Stammtisch Bonn	2026-04-21
	Chemnitz	Kaffeesatz, Chemnitz	OSM-Stammtisch Chemnitz	2026-04-21
		Online	Lüneburger Mappertreffen (online)	2026-04-21
	Richmond	Richmond, VA USA	Capital One TPM Summit Global Mapathon	2026-04-23
	Bratislava	Prírodovedecká fakulta UK Bratislava	Missing Maps mapathon Bratislava #13	2026-04-23
			Presentacion de initiative piloto: Capitulos de ONU Mapas	2026-04-23
	Richmond	Virtual	MapRVA Virtual Map & Yap with LaToya Gray-Sparks, VA DHR	2026-04-23
	Catania	Verso Coffice	Modifichiamo Wiki e OSM insieme!	2026-04-23
			UN Mappers Mappy Hour	2026-04-24
	Rapperswil-Jona	OST RJ See-Gebäude 6, Rapperswil (SG)	18. Mapathon & Mapping Party Rapperswil 2026	2026-04-24
		Pinneberg	Hamburger Mapping-Spaziergang (in Pinneberg)	2026-04-25
	Grad Zagreb	Sveučilište Algebra Bernays, Gradišćanska ulica 24	State of the Map Croatia (DORS/CLUC 2026)	2026-04-25
	Mumbai		OSM Mumbai Mapping Party No.9 (Central Line)	2026-04-25
			B of A – EC AM’s Mapathon -Global Service Month	2026-04-27
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-04-27
	Brno	Kamenice 753/5, Brno, Kamenice 753/5, Brno	Dubnový Missing Maps mapathon na Ústavu botaniky a zoologie	2026-04-27
	Stadtgebiet Bremen	Online und im Hackerspace Bremen	Bremer Mappertreffen	2026-04-27
	Kiel	Mango’s, Kiel	Kieler Mapper*innentreffen	2026-04-28
	Wien	Schlupfwinkel (Kleine Neugasse 10, 1040 Wien)	78. Wiener OSM-Stammtisch	2026-04-28
	Berlin	Online	OSM-Verkehrswende #74	2026-04-28
	Hannover	Kuriosum	OSM-Stammtisch Hannover	2026-04-29
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2026	Düsseldorfer OpenStreetMap-Treffen (online)	2026-04-29
	Essen	Linuxhotel Essen	FOSSGIS-OSM-Communitytreffen im Linuxhotel	2026-04-30 – 2026-05-03
	Stuttgart	Großraum Stuttgart	MA1PING	2026-05-01
	Augsburg	Augsburger Linux-Infotag 2026	Workshop: JOSM – Java OpenStreetMap Editor – Eine Einführung	2026-05-02
		Sovigliana-Vinci	Mappando si Vinci! – 2 Maggio 2026	2026-05-02 – 2026-06-02
	Braunschweig	Stratum 0	Braunschweiger Mappertreffen im Stratum 0 Hackerspace	2026-05-02
	नई दिल्ली	Jitsi Meet (online)	OSM India – Monthly Online Mapathon	2026-05-02

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by HeiGIT, Mateusz Konieczny, MatthiasMatthias, PierZen, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, jcr83, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

Regarding Lougheed Highway in Coquitlam, BC, Canada: Nothing along Lougheed between Sage Place and Schoolhouse is accessible to foot traffic, but much of it claims to be, despite the significant danger. Lougheed appears to be editable in many sections, and I don’t know how to change the entire strip easily. Can someone help? Thank you!

Translations into the following languages have been added:

• English
• German
• Italian
• Slovak
• Russian

There are a lot of German speaking people in OSM, so this should help :)

Not much strings though :) There are also several validation messages, but there are just 32 lines total.

Just in case you would like to translate the plugin in any other language, here is the pot file.

We do not have any web UI for translations, but you can use PoEdit instead.

Because sometimes you want to see less rather than more, I created this. It’s the railway information from the existing transportation layer of the SVE01 schema, together with railway stations, places and water as needed for context.

One thing that it does is to distinguish between regular transportation railway stations and tourist ones.

Freight lines are de-emphasised (see here and disused and abandoned railways are shown in a barely-discernable grey.

The source of the style is here but that is just a subset of the “show everything” style for this schema here.

RETEX: My Journey into RTK

(text translated from my original entry in french using Chatgpt)

to be continued, perhaps:

• journal entry (coming soon): Existential questions about my encounter with Panoramax
• journal entry (coming soon): Mapping my village

I would like to point out that these journal entries are neither WIKI pages nor expert advice… They are simply accounts of lived experiences shared here for anyone who may be interested.

Why did I become interested in this topic?

During my urban recycling trekking (see previous journal entries), I photographed all the voluntary drop-off containers I came across, uploaded these photos to Panoramax, and added the Panoramax photo reference in OSM. This caused me no issues, as my goal was that, from the standard OpenStreetMap rendering layer, it would be easy (in this case, a simple click) to find the images.

I positioned the containers in OSM not based on the photo, but using aerial imagery and relevant environmental features (street intersections, buildings, etc.). This worked perfectly well until I noticed three things:

• when aerial imagery or the already mapped environment did not allow me to geolocate a container without hesitation, I sometimes went back to the geolocation embedded in the photo—and realized… that it placed my camera in the middle of a pond next to the road!
• when I discovered the “explorer” feature of Panoramax, I immediately checked the places where I had taken and published images. I then realized that the points with photos were rarely at the exact location of the container as I remembered it (nor at the exact shooting position).
• when I developed a small piece of software to process positioning streams emitted by OsmAnd to allow my family to follow me while hiking (Github oldnab OnlineTracker), I realized that without smoothing, the track was a sometimes chaotic polyline which still allowed people to know roughly where I was—within a few meters—but distorted any distance calculation (without smoothing, the polyline could produce a distance estimate off by more than 30%).

This realization will probably make most contributors reading this smile, but keep in mind that I had barely 6 months of experience on OSM, and the issue of “GPS accuracy” had never really struck me. I then looked into the subject and learned:

• that the GNSS antennas built into smartphones or cameras are of limited quality (to fit inside the device), which generally reduces the number of satellites properly received at any given moment, and therefore the reliability of positioning
• that, of course, the immediate environment (signal obstructions, reflections, etc.) disrupts satellite signals
• that even with a better antenna and a favorable environment, distortions caused by atmospheric traversal (which vary by location and time) affect signal processing (especially timing comparisons) and ultimately do not allow accuracy better than “within 5 to 10 meters” (unless one remains stationary, collects data over several hours, and then detects and compensates for atmospheric distortions through computation)

RTK principles from a layperson’s perspective

There is plenty of literature far better than what I could produce on the subject (Wikipedia, Centipede, etc.), so I will limit myself to a simplified introduction for beginners to the three main components:

• RTK Base: a reference point

  • Set up a reasonably good antenna and a suitable receiver on a fixed location.
  • Let this system compute (once) its position with centimeter accuracy using long measurements that detect and cancel atmospheric distortions.
  • Then let it perform regular measurements (every few seconds) to compute its theoretical position without accounting for atmospheric distortions, and thus determine (every few seconds), since the base knows its true position, the offset between actual and theoretical positions at that moment and location.
  • Use this offset/distortion calculation assuming that the distortion is roughly the same within a reasonable radius (a very good approximation up to ~10 km, very poor beyond ~40 km).

• RTK Rover: equipment requiring centimeter-level positioning

  • Equip a mobile setup (backpack, bicycle, car, agricultural machine) with a reasonably good antenna and a suitable receiver (so it can continuously receive at least a dozen satellites).
  • Provide this equipment with correction data computed by a nearby RTK base so it can apply the same corrections and thus eliminate atmospheric distortions specific to the time and place.

• RTK Network: the key to proper operation is, of course, having a base within reasonable proximity to any rover. This can be achieved either by installing your own bases in your working areas or by accessing networks of bases covering large territories. These networks may be open or private (with authentication and often paid access). In such a network, each base continuously reports observed distortions to a central distribution point (a “caster”). Each rover can then retrieve correction data from the nearest bases and apply it to its own positioning.

My choices

I quickly discovered the existence of the Centipede-RTK network, a collaborative and open-source RTK base network, fully aligned with the spirit of the digital commons ecosystem I had just entered through OSM: free, collaborative, open-source, open data. As of early 2026, the network includes nearly 1,200 bases, about half of them in France, covering most of the country. An active base is located about 15 km from my main mapping area (Villennes-sur-Seine), so I could reasonably rely on a rover connected to the existing network.

However, I did not hesitate long before deciding to install my own RTK base on the gable of my house and connect it to the Centipede-RTK network:

• it provides excellent accuracy in Villennes-sur-Seine
• it improves coverage southwest of Villennes-sur-Seine (previously somewhat lacking)
• it allows me to give back to the community some of what I benefit from through this free service

So:

• deploy an RTK rover (goal achieved in November 2025)
• deploy and integrate an RTK base into the Centipede-RTK network (goal achieved late November 2025)
• deploy a GoPro Max with the RTK rover (goal achieved mid-January 2026; see a future journal entry on Panoramax)

RTK Rover: choices, discoveries, learnings…

I’m somewhat of a geek as long as things remain intangible (math, software, etc.), but quite challenged when it comes to hardware (DIY, assembly, etc.). So I quickly ruled out building my own rover and directly purchased a commercial “surveying kit.”

Upon receiving it, I realized it did not match my needs: the kit includes an antenna and receiver, but also a survey pole with mounting options and a clamp system for attaching the receiver and a smartphone. I assume the idea is to plant the pole at the point to be geolocated and keep hands free.

I immediately stored the pole and mounting accessories in my garage (which I should not have bought if I had thought more carefully) and kept only the antenna and receiver.

I bought a telescopic photo pole and a threading adapter to mount the antenna, and placed it in my backpack (in the map/water pocket), leaving the receiver and a small 10,000 mAh power bank (more than sufficient) inside the backpack in a small plastic bag.

“Physical” observations

• if the pole is too thin, walking vibrations cause it to collapse and the antenna drops against the bag
• in all cases, a simple pole in a backpack has no lateral guidance and ends up leaning significantly left or right
• when I later added a GoPro, I used a second pole placed next to the first; both poles started oscillating laterally (sometimes in sync, sometimes not 🙂)
• the freedom of movement inside the backpack also creates unpredictable rotations around the vertical axis, which is not an issue for the antenna (symmetrical) but is problematic for GoPro images

The solution after several iterations:

Poles:

• for the antenna: 110 cm carbon handheld monopod
• for the GoPro: 2.7 m carbon GoPro pole (admittedly overkill, but since its collapsed length is 40 cm, I use it at ~1 m, avoiding vibration-induced collapse, and occasionally allowing higher positioning)

Lateral stabilization frame:

• bottom: dual-mount tripod plate
• top: two double pipe clamps (Ø22), connected with wire and tape

Rotation stabilization:

• add metal washers with locking tabs to prevent loosening

This frame, inserted into the backpack pocket, is perfectly stable. I position the GoPro 60–80 cm above the antenna to avoid interference with 360° images. Carbon poles prevent GNSS signal interference.

“Software” observations

• The receiver communicates via Bluetooth with the smartphone (free Lefebure NTRIP client), which connects to the Centipede caster (via IP) and injects positioning into the Android location API so all apps benefit from centimeter accuracy. The NTRIP client is not available on my de-Googled LineageOS phone—so I must use my Samsung phone… unfortunate, since it should technically work.
• The Samsung camera app produces erratic Exif positioning when NTRIP is active. The solution is simple: OpenCamera works perfectly.

RTK Base

Like the rover, I purchased a pre-assembled solution (from StephaneP, an OSM and Panoramax contributor).

The hardest part was physical installation. Not only am I not skilled in DIY, but I also have balance issues, so climbing a ladder was not an option. I hired a professional to mount the antenna on my roof gable, above the chimney and trees, then install the base in the attic and run an Ethernet cable to my fiber box.

He did not fully grasp the purpose (he understood precise positioning, but not why it needed to be continuous, since my house is supposed to stay put 🙂), but followed instructions and everything worked quickly.

Today the base is operational (Centipede-RTK station VLNS) and clearly useful to others—which was the goal.

Final thoughts

Base operational, rover operational.

Walking around with a backpack topped by two poles—one with a flying-saucer-shaped antenna, the other with a GoPro—sometimes attracts questions. I ended up creating a small flyer (tri-fold A4) answering three questions: “What are you doing?”, “Who do you work for?”, and “Why are you taking images?” It has been quite successful.

I also learned that I am taller with my setup than without (indeed!)—and tree branches or porches do not grow to compensate… So:

• watch above your line of sight
• position the GoPro sideways (to avoid unexpected impacts on lenses)
• even sideways, do not place the power button forward (a branch once turned my GoPro off)

And returning to RTK: remember that centimeter accuracy still requires satellite reception and IP connectivity (to query the caster), so nothing works in tunnels (typically short when walking). Therefore, once out of a tunnel, pause briefly to allow the NTRIP client to resynchronize and reposition.

These RETEX (feedback) journal entries describe my beginner choices, hesitations, discoveries, and questions. They reflect only my experience and are not WIKI entries. Some of these choices were discussed on the France forum, but not all. I remain open to comments and do not claim to provide recommendations here.

RETEX : RTK et moi

à suivre peut-être :

• entrée de journal (à venir) : Questions existentielles sur ma rencontre avec panoramax
• entrée de journal (à venir) : Cartographier mon village

Je rappelle que ces entrées de journal ne sont ni des pages de WIKI, ni des conseils d’expert … . Ce sont juste des comptes-rendus d’expérience vécue mises ici pour servir à toute personne intéressée.

Pourquoi me suis-je intéressé au sujet ?

Au cours de mon trekking urbain recyclage (voir entrées de journal précédentes), j’ai photographié tous les conteneurs de point d’apport volontaire que j’ai rencontrés, versé ces photos sur Panoramax et mis dans OSM la référence de la photo Panoramax. Cela ne m’a posé aucun problème, mon but étant qu’à partir du calque standard de rendu d’Openstreetmap, il soit aisé (en l’occurence un simple clic) de trouver les images.

Je positionnais dans OSM les conteneurs non pas à partir de la photo mais à partir de l’imagerie aérienne et des éléments pertinents de l’environnement (croisements de rues, bâtiments, …). Cela m’a parfaitement convenu jusqu’à trois constats :

• lorque l’imagerie aérienne ou l’environnement déjà cartographié ne permettent pas de géolocaliser sans hésitations le conteneur, il m’est arrivé de revenir sur la géolocalisation portée par la photo et de me rendre compte … que cela mettait mon appareil photo au milieu de la mare à côté de la route !
• lorsque j’ai découvert la fonction “explorer” de Panoramax, je suis tout de suite allé voir les endroits où j’avais photographié et publié des images. Je me suis alors rendu compte que les points avec photos étaient rarement à l’endroit précis du conteneur dans mes souvenirs (et pas non plus à l’endroit de la prise de photo).
• lorque j’ai développé un petit logiciel de traitement des flux de positionnement émis par OsmAnd pour permettre à ma famille de me suivre en randonnée (Github oldnab OnlineTracker ). Je me suis rendu compte que sans lissage, le trajet était une ligne brisée parfois chaotique qui n’empêchait pas de savoir où j’étais - à quelques mètres près - mais faussait tout calcul de distance parcourue (sans lissage, la ligne brisée peut fournir une indication de distance parcourue fausse de plus de 30%)

Il est probable que cette découverte fait sourire la plupart des contributeurs lisant ces lignes mais il faut se souvenir que j’avais à peine 6 mois de présence sur OSM et que cette question de la “précision GPS” ne m’avait jamais vraiment frappé. Je me suis alors intéressé au sujet et ai appris :

• que les antennes GNSS internes aux smartphones ou appareils photos étaient de qualité faibles (pour tenir dans l’appareil), ce qui réduisait en général le nombre de satellites correctement reçus à un instant donné, et donc la pertinence des informations de croisement
• que bien sûr l’environnement immédiat (obstacles aux ondes, réverbérations, …) perturbait les signaux satellites
• que même si l’antenne était de meilleure qualité et l’environnement très correct, les déformations induites par la traversée de l’atmosphère (variables selon le lieu et l’instant) faussaient l’exploitation des signaux (notamment sur les comparaisons temporelles) et au final ne permettaient pas une précision meilleure que “à 5 ou 10 mètres près” (sauf à rester immobile, prendre les données sur quelques heures et détecter et compenser alors par calcul les déformations atmosphériques)

Les principes du RTK vus par un béotien

Il y a toute une littérature bien meilleure que moi sur le sujet (Wikipedia, Centipède, …) et je me contenterai d’une présentation de / pour néophyte) des trois composants concernés :

• Base RTK : un point de référence
  • Positionner une antenne un peu sérieuse et un récepteur ad hoc sur un point fixe du territoire.
  • Confier à ce dispositif le soin de calculer (une fois) sa position au centimètre près par une longue mesure permettant la détection et l’annulation des déformations induites par l’atmosphère.
  • Puis le laisser faire des mesures régulières (toutes les quelques secondes) permettant le calcul théorique de sa position sans tenir compte des déformations atmosphériques et en déduire (toutes les quelques secondes donc), puisque la base connaît sa position réelle, le décalage entre réel et théorique à l’instant de la mesure et à l’emplacement de la base.
  • Utiliser ce calcul de décalage / déformation en considérant que cette déformation est certainement la même dans un rayon raisonnable (approximation très correcte jusqu’à 10 km, très incorrecte au delà de 40 km)
• Rover RTK : un équipement ayant un besoin de positionnement centimétrique
  • doter un équipement mobile (sac à dos, vélo, voiture, engin agricole) d’une antenne un peu sérieuse et d’un récepteur ad hoc (pour lui permettre de capter en permanence au moins une douzaine de satellites)
  • donner à cet équipement les informations de décalage calculées par une base RTK pas trop éloignée afin qu’il applique les mêmes corrections, s’affranchissant ainsi des déformations atmosphériques propre à l’instant et au lieu.
• Réseau RTK : la clé du bon fonctionnement est bien sûr d’avoir toujours une base à proximité raisonnable de son ou ses rovers. Ce but peut être atteint en créant et positionnant ses propres bases sur les zones d’usage ou en accédant à des réseaux de bases couvrant le plus large territoire possible, réseaux pouvant être d’usage libre ou privé (avec authentification et souvent alors payants à l’usage ou par abonnement). Dans le cas d’un réseau, chaque base informe en permanence un point central de rediffusion (un “caster”) des déformtions constatées à sa position. Chaque rover peut alors récupérer les informations de déformation des bases les plus proches pour les appliquer à son propre positionnement.

Mes choix

J’ai très vite découvert l’existence du réseau Centipède-RTK, réseau collaboratif et open-source de bases RTK, complètement dans l’esprit de la galaxie des communs numériques dans laquelle je venais d’entrer par la porte OSM : libre, collaboratif, open-source, opendata. Le réseau comprend début 2026 près de 1200 bases dont la moitié en France, couverte en quasi totalité. Une base active est à 15 km de ma zone de cartographie principale (Villennes-sur-Seine) et je pouvais donc raisonnablement me contenter d’un rover RTK appuyé sur le réseau existant.

Je n’ai cependant pas hésité longtemps à décider de mettre en place sur mon pignon de résidence une base RTK à joindre au réseau Centipède-RTK :

• cela m’offre sur Villennes-sur-Seine une excellente précision,
• cela augmente la couverture au sud-ouest de Villennes-sur-Seine (un peu faible)
• cela me permet de rendre à la communauté un peu de ce dont elle me fait bénéficier via cette offre libre.

Donc :

• mettre en service un rover RTK (objectif atteint en novembre 2025)
• mettre en service et intégrer au réseau Centipede-RTK une base (objectif atteint fin novembre 2025)
• mettre en service une Gopro Max avec le rover RTK (objectif atteint mi janvier 2026, voir une future entrée de journal sur Panoramax)

Rover RTK ; choix, découvertes, apprentissages …

Je suis un peu geek tant que cela reste immatériel (maths, logiciels, …) et particulièrement handicapé dès que cela devient matériel (bricolage, montage, …). J’ai donc repoussé toute idée de montage de rover par moi-même et ai directement acheté dans le commerce un “kit d’arpenteur”.
Dès réception, je me suis rendu compte que ce n’‘était pas mon besoin : Le kit d’arpenteur contient bien sûr une antenne et un récepteur, mais aussi une pique d’arpentage avec possibilité de fixer l’antenne et un système de fixation du récepteur et d’un smartphone (par machoire). Je pense que l’idée est de pouvoir planter la pique d’arpentage dans le sol au point à géolocaliser et de disposer des mains libres pour le reste des manipulations.

J’ai tout de suite remisé dans mon garage la pique d’arpentage et les systèmes de fixation (que je n’aurais pas dû acheter si j’avais réfléchi un peu) pour ne garder que antenne et récepteur.

J’ai acheté une perche photo téléscopique et un adaptateur de filetage pour fixer l’antenne sur la perche et ai glissé cela dans mon sac à dos (dans la partie prévue pour les cartes et / ou la poche à eau) en laissant le récepteur et une petite batterie externe 10.000 mAh (très largement suffisante) tranquillement dans le sac à dos dans un petit sac plastique.

Constats “physiques”

• si la perche est trop fine, les secousses de la marche la font se replier et l’antenne descend se coller au sac.
• dans tous les cas, la simple perche glissée dans le sac n’a aucun guide latéral et finit par se pencher à droite ou à gauche de façon marquée.
• lorsque j’ai voulu ensuite mettre en place aussi une Gopro, j’ai utilisé une seconde perche glissée à côté de la première de la même façon. Et les deux perches se sont mises à osciller latéralement de concert (ou non :) ).
• la liberté de positionnement des perches dans le sac à dos génère aussi des rotations d’axe vertical imprévisibles qui ne sont pas gênantes pour l’antenne (symétrique) mais le sont grandement pour les images Gopro.

La solution apportée après plusieurs essais :

Perches :

• pour l’antenne : monopode de main 110cm en carbone
• pour la GoPro : perche Gopro carbone 2,7 m. Je reconnais que le 2 mètres 70 est très largement inutile (mais comme sa position non étirée fait 40 cm, je l’utilise autour de 1m, donc peu étirée et donc je n’ai aucun problème de repli progressif dû aux vibrations. Cela permet aussi occasionnellement de remonter assez haut la Gopro.

Cadre de stabilisation latérale des deux perches verticales :

• en bas : plaque de fixation des bases des perches : support de trépied à deux montures (fait pour appareil phote et flash, par exemple)
• en haut : deux colliers doubles de fixations pour tube plomberie Ø22. Les colliers enserrent les perches et sont reliés entre eux par fil de fer et chatterton

Solution de stabilisation de rotation :

• adjoindre aux rondelles de caoutchouc protégeant les deux fixations au cadre inférieur des rondelles métalliques avec petits ergots empêchant le desserrage.

Ce cadre glissé dans la poche à cartes du sac à dos est parfaitement stable. Je mets la Gopro 60-80 cm au dessus de l’antenne pour ne pas que celle-ci perturbe les images 360 degrés. L’usage de perches en carbone évite toute perturbation de réception des signaux GNSS par l’antenne (même située plus bas).

Constats “logiciels”

• Le récepteur discute en Bluetooth avec le smartphone (application gratuite Lefebure NTRIP client) qui assure l’intermédiaire avec le caster Centipede (via IP) et se glisse sous l’API de positionnement de Android afin que toutes les applications sur le smartphone ayant besoin de positionnement bénéficient sans effort de la position centimétrique. Le client NTRIP n’est pas disponible sur mon smartphone LineageOS dé-google-isé. Encore un cas où je dois utiliser mon Samsung Google-isé … . C’est dommage car il n’y a pas de raison qu’il ne fonctionne pas (en supprimant bien sûr le fait de se glisser sous l’API de positionnement).
• L’appareil photo Samsung détraque complètement ses positionnements (données Exif erratiques) quand le client NTRIP est en service. Pour le coup, la solution est simple : OpenCamera fonctionne parfaitement.

Base RTK

Comme pour le rover, j’ai acheté une solution pré-montée (auprès de StephaneP, contributeur OSM et Panoramax, contactable sur le forum OSM France). Aussitôt reçue, aussitôt testée et opérationnelle (mais non positionnée).

La partie la plus difficile a été son positionnement physique. Non seulement je suis incompétent en bricolage, mais en plus j’ai de gros problèmes d’équilibre et il est donc hors de question pour moi d’effectuer du bricolage en haut d’une échelle. J’ai donc dû faire appel à un professionnel pour monter l’antenne en haut du pignon de ma maison, au bout d’un mat la mettant au dessus de la cheminée et des arbres environnants (donc soudure de la fixation, peinture du mât - concession à mon épouse un peu circonspecte) puis positionner la base dans les combles et tirer un câble Ethernet jusqu’à ma box fibre. Il n’a pas très bien compris quel était le but (il s’est arrêté à l’idée que cela permettait de connaître de façon précise la position de l’antenne mais n’a pas compris l’intérêt de le faire en continu puisque ma maison est supposée être fixe :) ) mais il a suivi mes requêtes et tout a été OK rapidement.

Aujourd’hui la base est opérationnelle (station Centipede-RTK VLNS) et est visiblement utile à d’autres que moi (c’était le but).

Au final

Base opérationnelle, Rover opérationnel. Mes déplacements avec le sac à dos dont émergent les deux perches, l’une terminée par une antenne en forme de soucoupe volante, l’autre par une Gopro, attirent de temps en temps des interrogations de la part des personnes que je croise et j’ai fini par faire un petit flyer (A4 plié en trois) qui répond aux trois questions : “Que faites-vous ?”, “Pour qui travaillez-vous ?” et “Pourquoi prenez-vous des images ?”. Il rencontre pas mal de succès.

J’ai aussi appris que je suis plus haut avec mes deux antennes que sans (eh oui!) et que les frondaisons des arbres ou les porches ne grandissent pas pour compenser … . Et donc :

• surveiller au-dessus de ma ligne de vue
• positionner la Gopro de façon transverse (pour qu’une rencontre imprévue ne se fasse pas sur les objectifs photo)
• même en transverse, ne pas mettre la tranche avec le bouton de mise en marche / arrêt vers l’avant (une branche d’arbre a un jour tout simplement éteint ma Gopro)

Et, pour revenir au sujet RTK : ne pas oublier que la précision centimétrique nécessite quand même une réception satellite ainsi qu’un accès IP (pour interroger le caster) et donc rien dans les tunnels (en général assez courts à pied : tunnel sous une route ou sous une voie ferrée). Donc ne pas hésiter, une fois sorti du tunnel à s’arrêter quelques secondes pour permettre au NTRIP client de se resynchroniser et repositionner.

Ces entrées RETEX (retour d’expérience) dans mon journal font état de mes choix de débutant, mes hésitations, mes découvertes, mes questions. Ces textes n’engagent que moi et ne sont pas des entrées de WIKI. Plusieurs de ces choix ont été évoqués sur le forum France, mais pas tous. Je reste bien sûr ouvert à tout commentaire et n’ai aucunement la prétention de donner ici des recommandations.

Gemeinsam hacken, mappen und Ideen teilen

Beim Hackweekend Berlin 04/2026 kommt die OpenStreetMap Community zusammen, um in entspannter Atmosphäre gemeinsam an Ideen zu arbeiten. Ein Hackweekend ist kein reiner Programmier Marathon. Es ist ein offenes Treffen, bei dem neue und erfahrene Leute zusammenkommen, sich gegenseitig helfen und am Ende konkrete Verbesserungen mitnehmen.

Wir danken Wikimedia Deutschland herzlich für die erneute Gastfreundschaft: für die Räume, die gute Arbeitsatmosphäre und die tolle Verpflegung.

Die Beispiele aus diesem Wochenende zeigen die Bandbreite sehr gut. Es ging um kleine, nützliche Tools für Events wie Platzmonitor oder Abfahrtsmonitor, um Daten und Darstellung wie externe WMS Layer in BBBike oder einen Rust Renderer im Browser, und genauso um Austausch und Mapping Themen rund um Micromapping und Strassenraumdetails. Du kannst an deinem eigenen Projekt weiterarbeiten, dich an etwas dranhängen oder einfach erst mal zuschauen und Fragen stellen.

Wenn du neu dabei bist, reicht oft schon ein Laptop und Neugier. Du kannst aber auch ganz ohne Technik mitmachen, zum Beispiel beim Mapping, Testen, Dokumentieren oder einfach im Austausch. Hilfreich sind ein OSM Account und, je nach Themengebiet, Smartphone oder Kamera, aber notwendig ist das nicht. Vor Ort gibt es kein festes Programm, stattdessen entstehen spontan Aufgaben und Mini Sessions, und jemand findet sich fast immer, um dich beim Einstieg zu unterstützen.

Wenn du die naechsten Termine nicht verpassen willst, beobachte die verlinkte Wiki Seite oder osmcal.org.

Das nächste Hackweekend in Berlin wird am 24. und 25. Oktober 2026 stattfinden.

Im Folgenden sind einige der Themen gesammelt, an denen gearbeitet wurde.

Lars: Platzmonitor und Fahrplan Druck

• github.com/gislars/platzmonitor erstellt, um freie Plätze für Workshops und Exkursionen auf der FOSSGIS Konferenz anzuzeigen

• github.com/gislars/fossgis-fahrplan-druck kleinere Änderungen, unter anderem in config.js ausgelagert
• Mobile Version mit Favourite Funktion: gislars.github.io

Christopher: Abfahrtsmonitor für die FOSSGIS Konferenz

Abfahrtsmonitor für die FOSSGIS Konferenz:

• github.com/britiger/fossgis-abfahrtsmonitor

Christian (Jaller): Kassenbondrucker und MapSCII

Wir hatten einen Kassenbondrucker vor Ort und natürlich haben wir darauf Karten gedruckt:

MapSCII

MapSCII ist ein Braille und ASCII Renderer für das Terminal. Ein grosser Wunsch ist es, aktuelle Karten in MapSCII anzuzeigen. Der offizielle Server hat einen Kartenstand aus 2016 ohne Chance auf Updates von der ursprünglichen Quelle.

Dank Pull Request 155 von ionmeo gibt es nun die Option, auf einen topaktuellen Datensatz von OpenFreeMap umzusteigen. Der Pull Request wurde an dem Wochenende gelesen und freigegeben. Ein weiteres Ziel war es, den Quellcode nach TypeScript zu übersetzen.

Aktionsplan für ein neues Release:

• github.com/rastapasta/mapscii issue 159

Murphy (StrangeGirlMurph): Mapping und Diskussionen

• Kleistpark weiter gemappt
• Fahrradwege in der Kolonnenstrasse hinzugefügt
• Fotogrammetrie diskutiert

Wolfram: BBBike Map Compare mit externen WMS

BBBike Map Compare ist ein spezialisiertes Kartentool, mit dem man verschiedene Online Karten direkt miteinander vergleichen kann.

Neu ist auch die Einbindung externer WMS Services. In der Admin Console lassen sich zum Beispiel Karten aus Geoportalen einbinden und neben oder über eine OpenStreetMap Karte legen. Das funktioniert mit allen gängigen WMS Servern.

Oliver: Geldautomaten Layer in der Obstbaumkarte

Geldautomatenlayer in obstbaumkarte eingebaut, auch zur weiteren Verwendung als Vektortile Layer in geldautomaten-suche.org.

Dazu wurden mittels osm2pgsql zwei Postgis-Tabellen mit Geldautomaten und Geschäften, bei denen Bargeldauszahlungen vom Bankkonto möglich sind, angelegt. Für die Geldautomaten werden die OSM-Tags amenity=atm und atm ausgewertet. Für die Geschäfte wird der Key cash_withdrawal ausgewertet; außerdem wird über die Keys brand und operator festgestellt, ob das Geschäft zu einer Kette gehört, die Barabhebungen in ihren Filialen ermöglicht. Über eine Postgis-Abfrage werden Polygone herausgefiltert, die als Möglichkeit zum Bargeldabheben getaggt sind und zuzätzlich Geldautomaten oder entsprechende Geschäfte als Nodes enthalten. Das Ergebnis dieser Postgis-Abfragen wird als Mapbox-Vektotiles ausgeliefert und kann als Layer in andere Karten eingebunden werden. Auf diese Weise werden die Daten zu Bargeldabhebemöglichkeiten zusammen mit den Kacheln der Hingrundkarte in den Client geladen, so dass sich eine Abfrage über die Overpass-API erübrigt. Der Vorteil dieser Vorgehensweise ist, dass auch Informationen für große Gebiete angezeigt werden können. So lassen sich Geldautomaten und Geschäfte auch auf niedriegeren Zoomstufen darstellen (hier ein Beispiel für Zoomlevel 9 ). Ein nächster Schritt könnte z.B. sein, clientseitig durch Auswertung der Öffnungszeiten tageszeitabhängig zu filtern, so dass nur die Automaten und Geschäfte angezeigt werden, bei denen man zum Zeitpunkt des Aufrufs der Karte tatsächlich Geld abheben kann.

Sven: Rust Renderer für area:highway im Browser

Experimenteller Rust basierter Renderer für area:highway und barrier=kerb, der per WebAssembly direkt im Browser läuft:

• github.com/svenpilz/highway_area_map

Slaven: BBBike Optimierung, Converter und Bugfixes

• Fahrradstrassen Optimierung in BBBike, zunächst nur in der Desktop Anwendung, am Beispiel Bundesallee vs Handjerystraesse plus Prinzregentenstrasse
• Mapillary Vector Tiles nach BBBike Datenformat Converter
• Bugfixes
• Nominatim Issue zu problematischen neighbourhood und quarter Angaben in den Ergebnissen angestossen

Alex: Austausch, QGIS Rendering und Modernisierung der Prozessierung

• Viel Austausch zu Micromapping, Mapping von Strassenraumdetails und Diskussionen über Vibe Coding
• Experimente mit komplexen Rendering Reihenfolgen in QGIS, um Features auf oder unter Brücken abhängig ihres layer Taggings zu rendern. Die nächste Version der Strassenraumkarte soll übereinander liegende Features besser darstellen.
• Modernisierung der Prozessierung der Strassenraumkarte auf einen osm2pgsql plus SQL Stack. Arbeit an der Generierung von Strassenmarkierungen ging weiter voran.

My hood

Hello

You might have noticed that I have been maping this neighbourhood. Richmond. Why? Well Way: Richmond (1489761671) is small, historic and central with a mixed architectural heritage. You’ll find points of interest in the suburb of Q61359147. There are a number of offices and public (and private) education facilities. There’s no shortage of nearby recreation facilities either.

Mapping the hood with SPARQL.

In this post (which is in draft) I’m going to show how I go about creating a map of the hood

Take a specific place (Q61359147) as the center point Finds all nearby places within 10 km radius Filters them according to specific category (tourist attractions, bookshops ) Calculates how far each one is from the centre point and returns results from nearest to farthest.

Tourist Attractions (Q570116)

Let’s begin with a list. Are there tourist attractions (Q570116) near Richmond (Q61359147)? ~~~ SELECT DISTINCT ?place ?placeLabel ?location ?distance WHERE { hint:Query hint:optimizer “None” . wd:Q61359147 wdt:P625 ?arcLoc . #Change the location SERVICE wikibase:around { ?place wdt:P625 ?location . bd:serviceParam wikibase:center ?arcLoc . bd:serviceParam wikibase:radius “50” . } ?place wdt:P31/wdt:P279* wd:Q570116 . SERVICE wikibase:label { bd:serviceParam wikibase:language “en” . } BIND(geof:distance(?arcLoc, ?location) AS ?distance) } ORDER BY ASC(?distance) ~~~

Mapping the hood with Overpass Queries

You might want to explore [Overpass] (https://osm-queries.ldodds.com/) and see if you can finds a range of potentially interesting, historic or noteworthy locations. A lack of a wikidata link doesn’t mean that there is a wikidata entry to link to, or that the location should have one. This might be another useful starting point to find locally significant places. Credit to Leigh Dodds for all this information

@title Interesting places without wikidata links @see osm.wiki/Key:wikidata @see osm.wiki/Key:tourism */ [bbox:{{bbox}}]; ( //historic locations nwr[“historic”];

//tourist attractions nwr[“tourism”=”attraction”]; nwr[“tourism”=”artwork”]; nwr[“tourism”=”museum”];

//parks nwr[“leisure”=”park”];

//historic buildings nwr[“amenity”=”townhall”]; nwr[“amenity”=”university”];

)->.qi; nwr.qi[“wikidata”!~”.”]; out body; >; out skel qt;

Richmond Points of Interest

https://commons.wikimedia.org/wiki/Data:South_Africa/Gauteng/Richmond_POI.map

Melville Koppies

https://en.wikipedia.org/wiki/Wikipedia:Map_data/Melville_Koppies

Melville Koppies East

Credit to Stanislav Kralin for the SPARQL query.

Un petit tuto pour montrer comment importer du stationnement vélo issus d’une base de donnée en Opendata.

Ici la Communauté d’agglomération du Saint Quentinois vient de publier un jeux de données sur les aménagements cyclables.

https://www.data.gouv.fr/datasets/amenagements-cyclables-10

Avant de vérifier le linéaire avec OSM, on peut déjà importer les données ponctuels de stationnements vélo.

Avec QGIS, on importe les données, on vérifie leur homogénéités.

On peut suite traduire les champs et valeur en fonction de ce qui est attendu dans OSM.

exemple : champs “type” valeur ‘Appuis-vélos’ créer un champs “bicycle_parking” valeur ‘stands’ et on supprime ensuite le champs “type”

On supprime ensuite l’ensemble des champs inutiles dans OSM.

Dans QGIS, on importe également les stationnements existants déjà dans OSM, et on note bien les points en doublon, qu’il va falloir corriger après l’import.

Dans JOSM, on importe le fichier créer dans QGIS en .gpkg fichier - ouvrir

Puis on exporte après vérification.

Une fois importer dans OSM, on va retrouver les points en doublons et on effectue des fusions en prenant en compte les valeurs les plus à jours.

今日，到广州图书馆一游，记录一下

Accurate and precise updates

I’ve made excellent, accurate, and completely correct updates for o.s.m users in my area where I live, work, and spend most of my time. I’ve lived here for six years, I love my area completely, and I feel a true sense of belonging to it.

I’ve made the updates, but I don’t know when the new changes will appear in the map updates. There might be a delay in the update for some applications that use o.s.m.

Hello, i have an irrational fear of technology. Because i hate OSMwiki. i hate how things related to public transit is inconsistent. i hate how iD editor is inconsistent in giving necessary tags for PTv2. i don’t like stop positions. i don’t like iD editor not having an auto sort for relation members. i don’t like weird tagging schemes. i don’t like the OSM wiki having multiple different tags for very similar things without the wiki explaining them in terms of how the things that are being talked in OSMwiki is implemented in your country. i don’t like how convoluted it is for adding bus routes. harumph.

in another news, pt_assistant plugin for josm is a godsend. thank you kind stranger for this gift to humanity.

also, even if i added PTv2 compliant perfect bus routes, OSMand is still not able to properly show bus information on itself.

harumph.

please, someone save OSM and me.

The Virtual Institute for Sustainable Development - IVIDES.org® participated in “Mapping Together”, the virtual meeting of the MapYourGrid project

MapYourGrid logo © 2026 Open Energy Transition (OET).

The Virtual Institute for Sustainable Development - IVIDES.org® attended the virtual meeting of the MapYourGrid project, represented by its Chairwoman, Dra. Raquel Dezidério Souto, who participated in the meeting to learn about the project and understand its infrastructure and logical model.

The overall objective of the meeting was to demonstrate the structure of Wikidata and discuss improvements to the integration between the MapYourGrid web map, available at https://mapyourgrid.org/, and the Wikidata and Wikipedia structures, which are used to document objects related to the power distribution network mapped using OpenStreetMap.

You can see here the mental model of a workflow to this connection which was elaborated by Norman, Lacombe and other meeting attendees.

The connection with Wikidata is one of the MapYourGrid project’s strategies and aims to link objects mapped in OSM to their corresponding Wikipedia pages. You can follow the short guide to see what’s missing in your country and then map those on OSM.

The organizers are committed to empowering individuals, communities, and nations around the world to map their countries’ power grids. They invite interested individuals to participate in the next meeting, which will take place in two weeks; you can view the project agenda.

Important note: IVIDES.org® and IVIDES DATA® are registered trademarks. To keep contact: ivides [at] ivides.org | https://ivides.org  

Ajout du parcours de “La Chartreuse” à Dijon

Par ici : osm.org/node/13731747305

Des infos par ici : https://www.discjonctes.fr

Photos trouvées ici : https://udisc.com/courses/la-chartreuse-dijon-icgi/photos

Membantu orang hendaknya ikhlas, dan tidak mengharap pujian atau apresiasi dari orang lain. Bantulah dengan bantuan yang terbaik. Dan tidak perlu kita mengungkit-ungkit bantuan yang kita berikan, berharap balasan dari ALLAH subhanahu wata’ala semata. Caranya mudah, bantuan yang engkau berikan itu ibarat yang engkau keluarkan dipagi hari. Dengan begitu engkau akan lupa, tidak ingat bantuan apa yang telah engkau berikan kepada orang lain

Das Vernetzungstreffen des FOSSGIS e.V. hat am 15.04.2026 mit 28 Teilnehmenden in der dafür neu gestalteten Netzwerkwelt stattgefunden. Die Idee ist, das gegenseitige Kennenlernen und gemeinsamer Austausch zu Anliegen, Themen, Menschen im Umfeld des FOSSGIS-Vereins erhalten Gelegenheit Kontaktpunkte zu finden.

Ein weites Spektrum an Perspektiven war vertreten, von Einzelpersonen, die sich engagieren, über Anwendende, die spezielle Fragen haben und Firmen, die erfolgeich auf OSS umgestiegen sind.

Eindrücke vom Treffen

Zu Beginn trafen sich alle im Raum FOSSGIS e.V. für einen gemeinsamen Einstieg und um den Ablauf der Veranstaltung miteinander zu teilen. Vier Räume waren thematisch vorgeplant. Im FOSSGIS e.V. Raum war die Vorstellung des Vereins, inklusive Fragen geplant, da die Option keiner angewählt hatte, verschiebt Katja die Session auf das nächste Treffen. Dafür wurde Interesse bekundet. Im Bällebad haben Janine und GisLars Buddy findet Buddy gespielt, FOSSGIS-Wiki. Zu Karrierewegen und Karriereplanung im Geobereich tauschte sich eine Gruppe über Jobfindorte, Arbeitgeber aus, auch Erfahrungen und gefragte Skills wurden im Raum GDAL besprochen.

Eindrücke vom Treffen

Im Raum Wiese war Gelegenheit mit Jannik aus der AG Grundsatz des FOSSGIS e.V. über Ideen zur Weiterentwicklung zu sprechen. Die Perspektiven reichten von Ausweitung der Lobbyarbeit, um FOSS weiter zu verbreiten, über Digitale Souveränität bzw. den Umstieg dahin. Die FOSSGIS-Konferenz dient als Informationsquelle für zahlreiche Themen, doch wären Visualisierungsmöglichkeiten für Fachwissen über Gemeinwohllösungen, um der steigenden Konzentration von Macht über das Netz und das Geld entgegenzuwirken, eine wünschenswerte Sache. Links zu Infomaterialien der FSFE und OSBA wuden ausgetauscht sowie auch die Initiative des Digital Independence Day Erwähnung fand.

Für das spontan eingebrachte Thema “GEODATEN - managen?!” wurde der Raum OSGeo genutzt. Die Gruppe wird beim nächsten Vernetzungstreffen wieder einen Raum öffnen und verschiedene Varianten von Geodatenlösungen vorstellen.

Eindrücke vom Treffen

Das Treffen in der Netzwerkwelt hat auf Basis von Workadventure stattgefunden. In der Netzwerkwelt ist die Interaktion von Teilnehmenden möglich, man ist mit einem Avatar unterwegs, gibt sich beim Eintreten einen Namen. Trifft man eine andere Person, öffnet sich ein Videochat, eine Unterhaltung ist bis maximal 4 Teilnehmende möglich. Die Räume (Inselchen) sind Videokonferenzräume, man tritt einem Jitsi-Videochat bei, dort fanden die Austauschrunden statt. Vielen Dank an Stella fürs Bauen der Netzwerkwelt und danke den FOSSGIS e.V. für die Unterstützung des Treffens mit den Entgelt an die Betreiber der Plattform.

Abschluss und Feedback

Die Rückmeldungen waren durchweg positiv, die Teilnehmenden kommen wieder und wollen sich weiter über verschiedene Themen unterhalten.

Das nächste Vernetzungstreffen ist für den 17.06.2026 um 18 Uhr geplant und wird voraussichtlich wieder in der Netzwerkwelt stattfinden

Folgende Themen wurden gewünscht/ werden angeboten:

• Lösungen zu Geodatenmanagement werden vorgstellt (Anja Sigesmund)
• noch mehr über FOSSGIS e.V. (Katja)
• Fortsetzung Karriere/ Jobplanung
• Wird es im PostGIS-Raum ein Angebot geben?
  Wer Interesse hat einen Raum anzubieten, meldet sich bitte vorab bei Katja.

Infos aus dem Verein

Die Aktivitäten des Vereins sind im FOSSGIS-Vereins-Kalender zu finden: https://fossgis.de/aktivitäten/termine.

JETZT OSM-Förderer werden und die digitale Souveränität stärken!: https://openstreetmap.de/foerderer/

I had the opportunity to solely lead Nepal’s first Inclusive Mapping Week 2025 at Kathmandu University. What started as an idea became a week-long initiative bringing together over 400 participants to learn, map, and collaborate.

Throughout the program, we focused on both technical skills and real-world applications:

Humanitarian mapping using OpenStreetMap Remote sensing with Google Earth Engine Crisis mapping and spatial data use Field mapping with tools like Mapillary and OSM Tracker

One of the most meaningful aspects of this initiative was contributing mapping data to support earthquake-affected regions. It reinforced how open geospatial data can play a role in disaster preparedness and response.

As a young woman in the geospatial field, leading this initiative was both a challenge and a responsibility. Ensuring inclusivity and encouraging participation especially from women was at the core of this program.

Being recognized by The Annapurna Express for this work was a proud moment, but what matters most to me is the impact created through collective effort and open collaboration.

This experience taught me that:

Mapping is not just technical work—it creates real-world impact Leadership is about enabling others to contribute Inclusive communities build stronger, more meaningful maps

This is just the beginning of my journey with OpenStreetMap. Looking forward to contributing more, learning more, and building maps that represent people, communities, and realities. youthmappers blog; https://www.youthmappers.org/post/she-leads-we-map-nepal-s-first-inclusive-mapping-week-2025 The Annapurna Express: https://lnkd.in/g6ZSgBBq

ww

Introduction

Sometimes, we set out to solve one problem and arrive at a bunch of even greater discoveries along the way. This story starts with my curiosity about whether you can get a “GPS” track log underground - like in a tunnel or underground car park. GPS is our go-to tool for mapping most things that we can’t see on aerial imagery, but what can we do in places where GPS signals cannot be received? In the course of my investigation, I uncovered a few even more interesting insights:

• Even if you can code, it’s impressive what an off-the-cuff LLM prompt can build for you
• The openstreetmap.org site UI would work very differently had it been built in the smartphone era
• Capturing rich mapping data from stock vehicles with no extra hardware is feasible
• With relatively little effort, we can improve the effectiveness of GPS track log capture for OSM mapping

Oh, and I did manage to get that underground track log, but more on that anon…

Motivation: the desire to improve tunnel mapping

Mapping underground features in OSM can be challenging. Sometimes we are lucky - a tunnel or covered roadway may be a straight line between two known points on the surface. Perhaps the tunnel was built using cut-and-cover and we were able to establish the geometry during construction. But sometimes, we just have an underground linear feature with bends in it. We know where each end dives underground, but GPS signals cannot be received underground, so our traditional mapping approaches won’t help us.

Road tunnels, of course, are designed for vehicles, and many modern vehicles have moving map displays as part of a navigation system. When in a tunnel, many even show a plausible vehicle position that updates. Without GPS. How do they do that? They could simply infer movement along the mapped path of the road based on distance travelled. But they may also use more sophisticated dead-reckoning inferring direction from sensors. I have such a car. I wanted to find out.

The Equipment

My car is a Tesla Model 3. Even by modern standards, its cockpit is very high-tech, with many parts of the car’s controls managed in software via a large touch screen. But there is no way to run my own software to access and record vehicle position. Well… not directly.

What the car does have is a web browser. And web pages can request location information via JavaScript. If I crafted a suitable web page, would it be able to access full-precision position data equivalent to what the car’s own navigation system uses? Just as importantly, on a platform with no user-accessible storage system, could I somehow get that position data to a place where I could use it for mapping purposes? Before committing to any actual work, I considered various options, many of them as unhinged as a Cybertruck:

• Display co-ordinates on screen, video-record the output and use OCR to save it
• Try using copy and paste to grab the displayed co-ordinates and use web mail to send it to myself
• Deploy a lightweight server component to accept the uploaded data (spoiler: this was the key to success) The Proof of Concept

I had to convince myself that plausible location information would be delivered by the car, and not just low-precision generalised data. I knew that the browser could access some kind of location data, since I’d used web sites that had maps to locate charging stations. I also knew that the car’s own navigation tech seemed to be able to estimate underground position. To avoid pointless effort, I needed confidence that the same level of precision would reach the browser. As an OSMer, my test tool of choice was clear - www.openstreetmap.org. Our own slippy map has a moving map mode that I had already used many times on a smartphone. I could simply drive around with the map active in the car’s browser. If the location marker tracked my movements well, precision was probably high. If it continued to track them in, say, an underground car park, then we had a path to success.

There’s not much to say about that road test - it validated the premise. The map marker accurately tracked my location and continued to do so underground. I would later have to exclude the possibility that the underground position might be inferred with assistance from the car’s own onboard maps, but this was enough validation to invest effort to find a way to record a track log. But the role of the OSM slippy map in this test foreshadows some later events in this story.

How do I get a web page that can do what I need? Well, I’m a clever chap who made his career building stuff using web technology, so I did what any self-respecting industry veteran in 2025 would do: I took a chance on an LLM being able to build it for me. I fed the following prompt into ChatGPT:

Can you provide code to implement capture and storage of a GPS track log, in GPX format, from a web browser running on a GPS-equipped computing device, such as a mobile phone or modern motor car. Ideally, during capture, the user's location would be displayed on an interactive map based on OpenStreetMap data and the track log already collected should be displayed superimposed on that map.

(The more observant among you will spot that I missed a question mark in the main request. The shame…)

This generated a pretty short single HTML file. I loaded it into a browser on my laptop for initial validation. It displayed a mostly blank page and threw two console errors. So much for vibe coding? In fact, the truth was a lot more positive. The errors arose because of two referenced Leaflet files, one JavaScript, one CSS, for which incorrect checksums had been hallucinated. I removed the checks (I said I was a professional), and… It worked. Immediately.

I had a full page OSM map. I had a button to start logging. Pressing it centred the map on my home location and displayed a marker. Remember, this was on a laptop, so the marker couldn’t actually move anywhere - the constant position was whichever one the browser was able to infer from my IP address alone. But: the “Download GPX” button that the LLM had thoughtfully provided did push a GPX file into my Downloads folder and JOSM could display the single point it contained.

I hadn’t written a single line of code, other than to remove the checksum tests. On reflection, I could probably have just asked ChatGPT to remove those for me.

I was impressed. I needed to road-test it. I also needed to tell somebody how clever this all was. The person I told was Stereo, and he participated in a bunch of the (slight) refinement that was to follow, in particular, through hosting the prototype on his web space so that the car (remember, no access to local storage) could actually open the page and record stuff.

Road Test

Once the vibe-coded HTML file was web-accessible, I hopped in the car, entered the URL of the tool, pressed “Record” and drove. Not far, and I didn’t seek out any underground challenges at this point either. Remember, we hadn’t yet rigged up anything to get the recorded data out of the browser. This test was all about proving that the car would accumulate a track log and be able to obtain real, useful co-ordinates from real GPS satellites. But everything checked out:

• The marker moved
• A good clean track log was displayed (in blue, good choice!)
• Actually, a SUPERBLY clean track log. Driving up one side of the road and then back down, you could tell which side of the road you were on. Seems like cars have good GPS chipsets and antennae.
• The “Download” button worked, sort of: I got a raw display of the GPX content. I photographed some of it and we were able to verify its correctness.

We didn’t do a lot else to this - Stereo rigged up a server component to allow for upload of the data. He also added a very few ergonomic tweaks to the display. I road-tested it a bunch more in my area to make sure that the resulting GPX files were good (they were). It was time to go underground! I took one more quick trip to a local supermarket with underground parking to make sure that all of this still worked underground and everything looked good. We were ready for the big test.

Dublin Port Tunnel

The Dublin Port Tunnel connects the M50 and M1 motorways to Dublin Port. Because the port is right in the city centre, essentially all HGV traffic entering or leaving the port used to clog up key city centre roads. The building of the tunnel allowed for a comprehensive truck ban in the central area. There are two parallel bores, each 4.5km long and carrying two lanes of traffic. Each bore contains two gentle curves, describing a slight S-shape. On either end, a section was built cut-and-cover, and these sections were therefore mapped accurately from aerial imagery during construction. The precise nature of the curves in the bored sections was mapped as best we could, inferred mainly from crude knowledge of the surface locations of ventilation shafts.

So if you could get a track log underground, that would be better, wouldn’t it?

I took the car out one evening to find out. There is a toll on the tunnel, so repetitive tests could get pricey. Evening rates are lower. I fired up the browser and logged the entire journey along the M50 from Blanchardstown to make sure the GPS was warmed up. I drove through the southbound bore, surfaced, uploaded my work in case of a browser crash (put a pin in that…) and then logged the northbound bore.

I got a track log for the entire journey. While driving through the southbound bore, I could see my recorded position diverge noticeably from what was on the map, more or less as I reached the second curve. In theory, that might have been correct, but, as I entered the cut-and-cover section, it was clear that this was not the case. Once out of the tunnel, the position jumped back to reality. The northbound log was much more plausible, with only a minimal adjustment on emergence from the tunnel. What should we conclude?

• Underground mapping certainly works, especially over distances that are much shorter than 4.5km
• The positions reported by this particular car are not assisted (and therefore not contaminated) by on-board mapping data
• The dead-reckoning used by the car degrades with distance from the last known GPS position
• Single track logs are probably not trustworthy over this distance
• Multiple track logs may allow for the emergence of a plausible averaged path
• Because this instance involves twin bores believed to maintain constant distance from each other, logging in both directions may allow the earlier, more accurate logs from one direction to be used to correct the less accurate later parts of the logs from the other direction.

What this means for vehicle mapping

So far, this web-based tool has been tested in my Tesla and in a Volvo XC90. Testing in a variety of other vehicles would be necessary in order to draw comprehensive conclusions, but so far I can say:

• At least some vehicles obtain useful location information, even underground
• At least some vehicles expose that location information to their system browser
• At least some vehicles can use web-based logging tools to yield GPX track logs
• At least some vehicles (the Volvo) cannot use web-based logging tools as they block browser usage during driving (there are some indications that this may be an Android Automotive constraint)
• In-vehicle browsers may crash or context shifts in the car-UI may switch away from them, say, when shifting into reverse. On resuming the browser, logged data may not be retained. Experimentation is therefore needed around browser Local Storage or perhaps periodic pushing to a server.

The prototype is great, and, when I map a new road, or an underground car park, or do any other kind of vehicle-based mapping, I use it for real, usually as my only logger. I’d love to share it with other mappers, but the data upload mechanism is crude and won’t scale to that. The tool would need to be refined to keep things manageable, especially in terms of keeping track (heh!) of which track logs belong to which user and maintaining privacy when desired. But that brings me neatly to some important reflections on the right way to implement a tool like this. Because it turns out that most of what we need is already present in a very familiar place.

Reflections on OpenStreetMap.org

I noted above that my use of the OSM slippy map as a first validation was a foreshadowing event. In my validation run, I drove around with my live position displayed on the OSM map but wasn’t able to record a track log because openstreetmap.org doesn’t do that. Then I had an LLM build me a standalone tool centred on an OSM map that just happens to look almost exactly the same and used that to record the track log I wanted. Finally, if I wanted to add my track log to my repository of OSM track logs, I could go back to openstreetmap.org and upload that file.

If that comes across to you as a cumbersome workflow, then you’ve reached the same conclusion I did. Almost all of what I needed to solve my problem is functionality already present on OpenStreetMap.org. Much of it represents core mapper workflows present since the earliest days of the project. The only real difference is context – the context that, nowadays, lots of end-user devices have both web browsers and GPS – and a few missing links that result accidentally from that context.

Feature comparison

Seen through this lens, my prototype ceases to seem like a novel proposition and looks more like a missing link in the toolset mappers have been using for as long as we can remember. We have the tools to upload a GPS track log, but only from a file. And we have the ability to display our live position on the slippy map. What we lack is the means to record where we have been while we display that live position. Even though it is increasingly likely that any track log captured by a mapper was recorded on a smartphone on which the mapper had probably also been using the slippy map with live position displayed.

A stunning functionality gap? Yes, but only if viewed with fresh eyes in 2026. I’ve been an OSM mapper for about 20 years, so I’m used to the idea that these apparently complementary features do not connect. The tools we use to manage track logs were built in a pre-smartphone era, when the devices that had proper web browsers at first didn’t have GPS at all and then gradually started to have really crappy GPS that you wouldn’t want to use for mapping. Add to that the fact that most stuff I need to map these days can readily be traced from aerial imagery, so whenever I do need to use GPS data, I mostly don’t bother to upload the track log to OSM anyway. In some ways, the track log repository isn’t the core feature it used to be 20 years ago. But if it’s no longer so relevant, this is in part because its upload UI still expects to be processing data as a file that came from a standalone device rather than as a sequence of points that were captured on the exact same device being used for the upload.

We should fix that. Partly for my own selfish reasons - I’d love a tidier way to do my vehicle mapping and I’d like to let others do the same - but mostly because it would give us a much saner workflow story to explain to new mappers. Let me caricature how you might explain a GPX-based mapping scenario to a new OSMer who grew up in a smartphone-centric world:

• You are out and about and you wonder whether the map is up-to-date at your location
• You open up openstreetmap.org in your phone’s browser and have it display your live location
• As you walk around, you realise that the footpath you’ve been on isn’t mapped. You should fix that.
• Switch away from your browser and launch a third-party tool that can record track logs. Start recording.
• Walk back along that bit of footpath - we weren’t paying attention the first time you walked along it.
• Depending on the software you’re using, it may or may not show you an OSM base map or any map at all. If it shows an OSM map, it may be badly out of date.
• Walked all the way along? Stop recording and work out how to get a GPX file out of the tool you just used. Hopefully your app can output one. If you’re unlucky, you might need to export it to your PC later. Maybe you even need to fish it out of the cloud somewhere.
• Go back to openstreetmap.org and use the GPX upload feature - you’ll need to point it at that file, wherever the app put it on your phone’s file system.

It’s not very nice, is it? Wouldn’t this be better?

• You are out and about and you wonder whether the map is up-to-date at your location
• You open up openstreetmap.org in your phone’s browser and have it display your live location
• As you walk around, you realise that the footpath you’ve been on isn’t mapped. It’s easy to spot, because the track log overlaid on the map doesn’t coincide with any existing map feature. You should fix that.
• Keep walking until you have covered all of what you wanted to capture. Hit the “Save” button.
• You will be able to name the trace (a suggested default will be offered based on your location). Choose what visibility settings should apply to the trace and press “Upload”.

I like this! What do we need to build?

If you made it this far, you’ve probably understood that I’m advocating that we extend the openstreetmap.org feature set to accommodate direct device-to-OSM capture of GPS track logs. Although the use case that brought me to this conclusion was vehicle-based mapping, we should expect that smartphones would be the main devices capturing data in this way.

As for the changes themselves, they are pleasingly contained to the point of likely being invisible to anybody not setting out to use them:

The key additions to current functionality are:

• Addition of an overlaid display of track log in moving-map mode
  • Recorded points must be buffered at least in the browser (see below) prior to upload
  • Decision: should this display be contingent on entering a “record” mode? If so, a button to activate this would be required, but this button would likely not appear until actually in moving-map mode.
• Addition of a “Save” or “Upload” option available whenever the track log is active
  • Actual uploading can reuse the existing GPX upload system
  • Decision: should it be possible for the user to name the track and configure visibility before track completion? This could be practical in cases where we provide a server component to progressively upload in order to work around browser brittleness (see below).

Technical challenges

• Recording of track log: no system impact to openstreetmap.org, if data kept by browser until time for upload
• Upload of track log: same process as exists already
• Risk of data loss during recording: brittleness due to browsers crashing or forgetting captured points due to context-switch
  • A real issue for cars
  • Modern smartphones are probably more robust, but background logging is still unlikely to occur
  • Possible solutions:
    • Do nothing: position this as an experimental feature, caveat mappor. It would still be useful for many purposes
    • Periodically flush recorded data to browser local storage (subject to the whims of individual browser implementations)
    • Periodically flush recorded data to server-based buffer (system load impact, so probably only reasonable after user has entered an actual “recording” mode)

In the second week (14th–19th February), we faced OSMMalawi. With no strategy to balance academics and mapping, I grew lazy. To overcome this, I wrote a sticky-note reminder on my laptop to push myself to map at least five tasks daily during breaks. By the end of the week, my contributions increased, and on 20th February, we celebrated another win, rising to 3rd place overall.

The third week (21st–26th February), the mapping match was against KabUyouth Mappers from Uganda. Bing imagery was unclear, but I adapted by using Google Earth references & comparing different imageries. My changesets piled up, promoting me from beginner to intermediate mapper. . We maintained the 3rd position but our captain organized a google meeting with Kingsley (one of the tournament organizers), who taught us valuable skills in both iD editor and JOSM.

By the fourth and fifth weeks (28th February–12th March), mapping had become part of my routine—even appearing in my dreams! Funny!!, am I right?

Despite some abrupt technical issues with OpenStreetMap login, we pushed through, won the game against YouthMappers Mukuba, and advanced to the next stage. By the end, we’re proudly ranked 4th among the top 10 contributing teams out of approx. 80 countries.

Thank you for reading my diary—I hope my journey inspires someone out there. Let’s map the world together! #SpatialMappers #AfricaMapCup2026. Cheers to all participants in this tournament, and please wish my team & I good for it’s still on going.

Every day at around 4 pm (unless there’s IRL business that I have to attend to), I log in to https://osmbc.openstreetmap.de/ to edit this week’s edition of WeeklyOSM.

My task is to review all the links submitted by both WeeklyOSM editors and guest users. I study each link, then write a short sentence describing it.

Some link submitters already accompany their links with proper sentences when submitting, so I mostly skip those. I only focus on links that don’t have English text yet.

This afternoon, while doing my daily WeeklyOSM editing, I stumbled upon this MapComplete post announcing that it is now possible to add pictures to reviews on MapComplete. This feature is powered by Mangrove Reviews.

Then, I suddenly remembered a certain discussion thread on c.osm.org regarding the possibility of building “a crowd-sourced review service for OpenStreetMap.”

Back then, I informed people that yet-another-crowdsourcing-mapping-platform had already built this kind of feature by simply allowing “comments” on each map object over there. My intention was to give a “clue” on how to make this wish a reality.

OSM objects (nodes/ways/relations) already have IDs. If we could simply add reviews to those OSM IDs as database keys, that would be simple and great.

Also, to gauge how well this idea is actually executed in the wild, you can see how that-yet-another-crowdsourcing-mapping-platform’s community reacted to the introduction of such a feature. Did it work? Did they actually add useful reviews there? How about moderation? What about the spam situation? How can we distinguish between good-faith posts and literal libel aimed at destroying someone’s business?

But apparently, a lot of people didn’t like my post. I got downvoted heavily. They accused me of “promoting” an OpenStreetMap “competitor” right behind “enemy lines.” Welp.

Alright, let’s get back to the MapComplete situation.

I’ve heard of Mangrove Reviews for a long time. The first time I used that platform was also while I was editing WeeklyOSM.

One day, there was this OSM-based web app launching, something about leaving a review of a camping ground. I used that app to review a camping ground near my area. It turns out the reviewing feature is powered by Mangrove Reviews. Cool.

Back then I thought, “If I could review other things than camping grounds, that would be cool. Also, it would be even cooler if I were able to post images.”

Now, fast forward to today.

Adding pictures to reviews? Is that our collective dream from long ago, just realized now?

Now I’m interested in pursuing this idea further.

First, I studied the Mangrove Reviews.

Then I found a problem.

I couldn’t find an interactive web map that shows all the submitted reviews.

So I built one.

Alright, done. It’s working.

Now we can see the reviews.

But how can we add reviews?

But I’m too lazy to implement it myself.

So I simply gave up.

Then I realized that MapComplete already implemented this feature, complete with an “add picture review” feature.

Nice.

Let’s try it.

Alright, done.

A new review of a certain cafeteria that I used to frequent during my college days, complete with a picture.

Good, it’s working.

Then I realized you can only add reviews to certain specific themes on MapComplete.

In the food theme, it turns out we can add reviews with pictures. But what if we want to review things other than food-related places?

So I studied MapComplete and learned how to make my own theme, so I can add more reviews to a wider variety of places.

And it’s done.

Great.

Now I can add reviews and browse reviews, even with images.

Dream come true.

I remember when my captain and I searched for willing mappers in our community to register for the tournament, which required at least 20 participants per team. One colleague discouraged me, saying it was highly impossible for us to be among the winners. However, that didn’t stop me from learning JOSM and joining the tournament.

In the first match week (7th–12th February), my team faced Carto Afrique of Kenya. The transition from iD editor to JOSM was amazing—tasks that once took over an hour now took only 30–40 minutes, giving me time to complete more. JOSM’s validation tool saved us from penalties by detecting errors before uploading.

On 13th February, the results were announced: my team won against Carto Afrique! That victory gave us our first point, lifted our spirits, and placed us 5th among the top 10 contributing teams. Yet, as my semester began, I feared balancing mapping with academics, sports, and assignments which would be tough, making the experience even more intense. ……..thank you to those that are reading my dairy. comment your review and lets share our experiences.

02/04/2026-08/04/2026

Mapping

• Comments on the following proposal have been requested:
  • Deprecate railway=narrow_gauge
• The following proposals are up for a vote:
  • man_made=cable_landing_station, to standardise the mapping of submarine cable landing station locations in OpenStreetMap. The tag is intended to more accurately help map this important infrastructure for international data connections (voting until 14 April 2026).
  • aerodrome:classification=*, to classify aerodromes more precisely according to their use and significance (e.g. international, regional, or local) (voting until 16 April 2026).

Community

• SeverinGeo, one of the French editors on weeklyOSM, has started a subjective review of weeklyOSM on Mastodon threads in French, English, and Portuguese, highlighting relevant information or extending articles with commentary.
• Pieter Vander Vennet provided an overview of the reviews made using MapComplete (2026 edition). Most reviews are located in Europe and focus on categories such as food, shops, and leisure activities.
• Engelbert Modo published , on LinkedIn, about a new initiative titled ‘CityMAPPER Externship 2026’, which aims to develop local capacity on mapping with OpenStreetMap and using open data, with initial focus on urban mapping in Cameroon. This initiative is a pilot project of the UN Mappers, a programme of the United Nations Global Service Centre, and has the sponsorship of the companies IVIDES DATA and TomTom, and the NGOs Humanitarian OpenStreetMap Team, GeOsm Family, and Geospatial Girls and Kids. You can read a prospectus of the UN Mappers Chapters Programme, the umbrella of the local initiatives.
• JDL09Organic, in a diary entry, presented a collection of Android apps for mobile mapping, including StreetComplete, Every Door, and MapComplete. The post provides a practical overview of their use cases and differences for efficient mapping on the go.
• juminet provided an overview of mapping photovoltaic installations in Wallonia and explains the correct usage of tags such as power=plant and power=generator. The analysis identifies several thousand mapped installations while highlighting gaps, especially in smaller setups.
• mbuege shared his experience capturing 360° imagery for Panoramax and has created a wiki page with tips on equipment and workflows. The guide is intended to be expanded and improved collaboratively by the community.
• watson reported ► on the discovery of a previously unmapped island in the Weddell Sea, which is now being discussed and mapped in OpenStreetMap. The community is debating the correct representation and positioning, as the feature is gradually added to maps and datasets.

Events

• Around 100 students at Brigham Young University took part in a mapathon to contribute OpenStreetMap data for humanitarian purposes. During the event, more than 13,000 features were mapped, mainly in regions such as South Africa and Myanmar.
• The organisers of State of the Map 2026 in Paris have opened their call for presentations, workshops, and panels, with a submission deadline of 27 April 2026. Contributions are invited across topics such as mapping, software development, community, and data analysis.
• Manuel is offering ► a workshop on the JOSM editor at the Graz Linux Days 2026 on Saturday 2 May, which will teach beginner and advanced users how to edit OpenStreetMap data. While using practical examples and exercises, the participants will learn how to work efficiently and error-free with the editor.

OSM research

• HeiGIT and the Federal Agency for Cartography and Geodesy have investigated how OSM data quality affects routing outcomes. Thirty city-to-city routes were computed across several countries and benchmarked against Google Maps, Bing, Apple Maps, and Graphhopper using two criteria: distance and travel time.

Maps

• ^[1] L_J_R presented, via their OSM user diary, Strado, a web map that scores neighbourhoods across 50 European cities using OpenStreetMap data. Based on around 78 million POIs, it uses an H3 grid to analyse liveability and activity. There is also a city dashboard where you can browse all cities with their neighbourhood rankings.
• Frederik Ramm reported that Geofabrik now provides GeoPackage files alongside shapefiles, combining multiple layers into a single file. The datasets have also been expanded with new content such as administrative boundaries, protected areas, and additional POIs previously only available in paid datasets.
• Users can explore the application built using python-maps-vis that visualises river basins and watersheds across North and South America on an interactive map.

OSM in action

• Carlos Carrasco, the developer behind NIMBY Rails, a game with a railway design simulator that allows users to plan and build railway networks on real-world geography, has announced a shift away from the proprietary file format in favour of open standards, specifically Protomaps PMTiles and MapLibre MLT. The change is intended to make it easier for players to generate their own in-game map files.
• The OSRM project noticed that both OSRM and the OpenStreetMap project are properly credited in the Tesla Model Y owner’s manual.

Open Data

• HeiGIT introduced OpenAccessLens, a platform analysing global accessibility to healthcare and education based on OpenStreetMap and openrouteservice. The open dataset is intended to support research, humanitarian work, and policy-making.

Software

• Craig announced that Wandrer, an OpenStreetMap-data-based exploration game, now has ‘100% routing’ tools which lets you create in one go a route covering every road in an area.
• Tobias Knerr introduced, on the OSM Community forum, the OSM2World Object Viewer, a viewer that allows inspection of individual OSM objects in 3D, such as buildings, highways, waterslides, German traffic signs, and more than 200 other types of OSM objects. It fully supports Simple 3D Buildings, fetches up-to-date data on demand, and even enables local tag edits with instant visual feedback.
• The project OpenCourseMaps has introduced a web-based editor designed specifically for mapping golf courses in OpenStreetMap, thus reducing the complexity of doing this in a general purpose editor. It aims to engage golfers in detailed mapping of features such as fairways, greens, and bunkers while ensuring correct OSM tagging and geometry. The YouTube video explains how to map with the editor.
• Michael Reichert presented Wamy (an acronym for ‘Where are my ways’), a prototype of a web map which reconstructs and maps the ways deleted from OpenStreetMap in Germany, Austria, and Switzerland. It displays geometries of ways removed since 12 September 2012 (when OpenStreetMap changed its licence to the Open Data Commons Open Database Licence). It is helping to reveal changes in the dataset and potential conflicts around path usage. You can read more in the ‘About’ section.

Programming

• Sander de Snaijer presented ‘Map Gesture Controls’, browser-native hand gesture controls for OpenLayers, powered by MediaPipe and without a backend. A JavaScript library enables gesture-based interactions for web maps and the project enhances map usability with more intuitive controls, especially for touch and trackpad input. The source is available from the GitHub project map-gesture-controls, under a MIT licence.
• Marcos Dione described, in his OSM user diary, a small Python 3 script that scans a local osm2pgsql database for rare and likely wrong tag values and opens the affected objects in the editor for manual review. The approach deliberately targets the long tail of uncommon errors, so corrections can be made directly and in a controlled way. The errors include typos, street names instead of type, and some others.
• Ralph Straumann described on Spatialists – geospatial news, a demo workflow by Riccardo Klinger, which converts OpenStreetMap street network data into vector tiles using GDAL/OGR and integrates them into ArcGIS Enterprise. The pipeline runs on Kubernetes in the ArcGIS Notebook Server. You can read the tutorial on LinkedIn.
• The new iD tagging schema release v6.16.0 includes 34 new icons, 4 new presets (shop=piercing, amenity=kitchen, natural=arete, advertising=sign), new matching fields in various presets, fixes of bad text, avoidance of iD issues, and more.
• Tom Hodson outlined his experience of compiling and running a local copy of the Overpass API on a Mac.

Releases

• Kevin Ratzel introduced Map2Go, a new OpenStreetMap editor for iOS, designed to simplify on-site data collection through suggestions and favourites. The app is currently in early beta and available for testing via TestFlight.
• The OSM-based web map Cartes.app is now available in English (in addition to the original French version), as announced by maelito2000 in the OSM Community forum. Further translations are planned, while current performance issues are caused by the overloaded Overpass instances.
• The DBeaver Community Release 26.0.2 has fixed the ‘access blocked’ error in Spatial Viewer when loading OpenStreetMap tiles and provided other improvements. It is now using a local web server and your firewall might ask you to accept the connection to this server. DBeaver is a free, open-source database management tool which connects to PostgreSQL/PostGIS and other geospatial (and non-geospatial) databases, including MariaDB, DuckDB, MySQL, and SQL Server.
• Zeke Farwell announced that the josm-strava-heatmap version 6 updates the extension to work with Strava’s current heatmap site and cookie requirements for imagery access. Unfortunately this means support for iD editor had to be removed, but you can use the julcnx/strava-heatmap-extension instead, which was designed to be used with iD.
• Rphyrin announced the release of Altilunium LocationPad v26.4.6, introducing several features aimed at addressing personal pain points encountered in the past. This lightweight web app has its focus on mapping, labelling, and revisiting meaningful places on an OpenStreetMap-based map. Designed for quick place logging, personal mapping, and spatial note-taking without accounts. The source is available on GitHub.
• Tracestrack has introduced Tracesmap, a new iOS app for recording and uploading GNSS traces to OpenStreetMap. The app supports multiple map styles and aims to contribute to improving OSM data quality.
• Pablo Brasero reported on the OSM Community forum (in posts [1] and [2]) about the multiple updates to the OpenStreetMap.org website made in March 2026, including UI refinements, better small-screen layouts, and upgrade of iD to version 2.39.5. They have also introduced anti-abuse measures such as Cloudflare Turnstile on sign up and laid groundwork for a future notification system.
• Zkir released version 2.0 of their UrbanEye3D, a JOSM plugin, which significantly improves 3D rendering of OSM data directly within the editor. New features include a 2D ground layer, tree visualisation, and improved background processing for large datasets.

Did you know that …

• … there is a special offer for AI companies: in exchange for a modest donation to the OpenStreetMap project, the donor company will receive a direct download link to OSM data in a machine-friendly format. For a larger donation, the OpenStreetMap Ops Team will provide the full history data via a fresh weekly torrent download, under the ODbL licence.

OSM in the media

• Arshak Ahamed wrote about how the delivery company they work for in Oman has replaced Google Maps with OSM-based services, in order to stop paying $8,000 a month.
• In a blog post, PeopleForBikes described how mapathons help update bicycle infrastructure in OpenStreetMap and improve the accuracy of their City Ratings. Around 60 participants from North America have learned how to use iD and JOSM to map bike lanes, speed limits, and key destinations.

Other “geo” things

• Jet Lag: The Game is a travel competition video series by Wendover Productions channel. Every season is built around a game format that is tailored to its filming location, while taking into account regional geography and available modes of transportation. The challenges vary widely, including tasks such as claiming territories across countries or continents, circumnavigating the globe by air, playing large-scale tag, racing between a country’s northernmost and southernmost points, and staging cross-country games of hide-and-seek, among others.
• Jake Godin reported that the access to open source visuals of the current Iran conflict, which has spread to many parts of the Middle East, continues to be sporadic. In past conflicts satellite imagery has provided a vital overview of potential damage to infrastructure, but nowadays imagery from commercial providers is becoming increasingly restricted and expensive. After the war in Gaza (began in 2023), Bellingcat introduced a free tool authored by University College London lecturer and Bellingcat contributor, Ollie Ballinger, that was able to estimate the number of damaged buildings in a given area. Bellingcat is now introducing an updated version of the open source tool, the Iran Conflict Damage Proxy Map, focused on destruction in Iran and the wider Gulf region, which can be freely accessed.

Upcoming Events

Country	Where	Venue	What	When
	Berlin	Wikimedia e.V. Tempelhofer Ufer 23-24,10963 Berlin	OSM Hackweekend Berlin-Brandenburg 04/2026	2026-04-11 – 2026-04-12
		Armadale Park Cafe	Social Mapping Sunday: Armadale Train Station	2026-04-12
	Milano		Editathon e mapathon alla Milano Marathon 2026	2026-04-12
	Antwerpen		Camera’s in kaart brengen	2026-04-12
	København	Cafe Bevar’s	OSMmapperCPH	2026-04-12
	Meerut	Haldiram’s, Garh Road, Meerut	OSM Delhi Mapping Party No.28 (Meerut)	2026-04-12
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-04-13
	Grenoble	La Turbine	Atelier d’avril 2026 du groupe local de Grenoble	2026-04-13
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #87	2026-04-13
	Salt Lake City	Woodbine Food Hall	OSM Utah Monthly Map Night	2026-04-14
		Online	Mappy Hour OSM España	2026-04-14
	München	Echardinger Einkehr	Münchner OSM-Treffen	2026-04-14
	Hamburg	Online (Link s. Wiki)	Hamburger Mappertreffen	2026-04-14
		Oloron Sainte Marie	Une cartopartie dédiée à la mobilité durable dans les Montagnes Béarnaises	2026-04-15
		Oloron-Sainte-Marie – La Friche	Cartopartie à Oloron-Sainte-Marie – Projet SYSTOUR	2026-04-15
		MJC de Vienne	Rencontre des contributeurs de Vienne (38)	2026-04-15
			Online Mapathon von ÄRZTE OHNE GRENZEN	2026-04-15
	Karlsruhe	Chiang Mai	Stammtisch Karlsruhe	2026-04-15
	Freiburg im Breisgau	CCCFR, Adlerstr. 12a, Freiburg (Grethergelände)	OSM-Treffen Freiburg/Brsg.	2026-04-16
			OSMF Engineering Working Group meeting	2026-04-17
	Potsdam	Kellermann	Potsdamer Mappertreffen	2026-04-17
		Golem, Avane, Empoli	Mapping Day ad Empoli	2026-04-18
		Dijital Bilgi Derneği	OSM-TR Meet-Up – OSM League Pit-Stop	2026-04-18
	Chennai Corporation		Mapping Party @ Chennai	2026-04-19
	Liège	ULiège-RISE	Understanding the OpenStreetMap ecosystem	2026-04-20
			Missing Maps London: (Online) Mid-Month Mapathon [eng]	2026-04-21
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-04-21
	Chemnitz	Kaffeesatz, Chemnitz	OSM-Stammtisch Chemnitz	2026-04-21
	Derby	The Brunswick, Railway Terrace, Derby	East Midlands pub meet-up	2026-04-21
	Bonn	Dotty’s	199. OSM-Stammtisch Bonn	2026-04-21
	City of London	The Globe pub, Moorgate	London pub meet-up	2026-04-21
		Online	Lüneburger Mappertreffen (online)	2026-04-21
	Richmond	Richmond, VA USA	Capital One TPM Summit Global Mapathon	2026-04-23
	Bratislava	Prírodovedecká fakulta UK Bratislava	Missing Maps mapathon Bratislava #13	2026-04-23
	Richmond	Virtual	MapRVA Virtual Map & Yap with LaToya Gray-Sparks, VA DHR	2026-04-23
	Tours	Étape 84	Rencontre locale Touraine	2026-04-23
	Catania	Verso Coffice	Modifichiamo Wiki e OSM insieme!	2026-04-23
	Rapperswil-Jona	OST RJ See-Gebäude 6, Rapperswil (SG)	18. Mapathon & Mapping Party Rapperswil 2026	2026-04-24
		Pinneberg	Hamburger Mapping-Spaziergang (in Pinneberg)	2026-04-25
	Mumbai		OSM Mumbai Mapping Party No.9 (Central Line)	2026-04-25
			B of A – EC AM’s Mapathon -Global Service Month	2026-04-27
	Brno	Kamenice 753/5, Brno, Kamenice 753/5, Brno	Dubnový Missing Maps mapathon na Ústavu botaniky a zoologie	2026-04-27
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-04-27

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by MatthiasMatthias, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, izen57, mcliquid, s8321414.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

The problem

I’ve been creating and serving web-based maps such as this one for some time. That’s based on raster tiles, and an osm2pgsql database is used to store the data that the tiles are created from, on demand as a request to view a tile is made.

For various reasons I wanted to also create a similar map using vector tiles. With vector tiles what is sent to the client (such as a web browser) is not lots of small pictures that the client stitches together, but instead larger chunks of data, still geographically separated. The client then creates the map itself based on the style that it has been told to show the data in, combined with the data itself.

I’d noticed that the vector maps that I was displaying were sometimes slow to load, especially at some lower zoom levels such as vector zoom 8. Note that vector zoom levels are one less than raster zoom levels, so vector 8 is raster 9.

This diary entry describes what I did to mitigate the problem (mostly over a year ago now - it’s taken me a while to get around to writing this!).

For info, also see similar work elsewhere, such as in OpenHistoricalMap.

The schema and the style

Often with OSM raster tile styles, what is in the osm2pgsql database is a selection of raw OSM keys, and the map style then chooses which of those to show. My raster style wasn’t really like that; it made significant use of lua scripts (called both on initial database load and on all subsequent updates) to convert OSM data into a state in the database in which it was easy to display.

This approach transferred really well to vector tiles. I documented the schema, and much of the code is actually shared between raster and vector. Once an OSM item has been transformed the raster code adds it to a database and the vector code creates vector tiles.

Vector tiles

The individual vector tiles can be seen in debug here. As you zoom in you’ll see that the squares get smaller, as far as vector zoom 14. Those are the highest zoom vector tiles created and things displayed at zoom levels > 14 are actually stored in zoom 14 tiles but only displayed later.

I’m creating vector tiles with tilemaker. That creates a big “.mbtiles” file which I copy to a directory under a web server.

/var/www/html/vector/sve01: (29 GiB available)
drwxr-xr-x 2 root root       4096 Mar 14 17:31 .
drwxr-xr-x 4 root root       4096 Mar 28 01:04 ..
-rw-r--r-- 1 root root 6203834368 Apr 10 01:58 tilemaker_sve01.mbtiles

I’m using Apache as a web server and I’m using a module mod_mbtiles to allow individual vector tiles to be extracted from that and sent to a client. It would make no sense to send (in this case) 6GB of Britain and Ireland data to a client that only wants to show a map of a small part of Lincolnshire.

Why are things sometimes slow?

A large vector tile has to be extracted from the large .mbtiles file, and sent to the client. The larger this is, the longer it will take, due to network speed issues among others.

There’s also an impact on the client - it potentially has to chew through a large amount of data to get to the data that it wants to display.

I tested various scenarios - fast vs slow clients, small vs large MapLibre .json styles (based on the same Schema) and omitting data from tiles to make them just smaller. Of all of those, the most important factor was the size of the vector tiles themselves, so the challenge became “how can I minimise vector tile size at certin low zoom levels”.

I initially looked at vector zoom 8, because it was quite slow, and was also used as a landing page zoom

Looking at Apache logs

An example entry in Apache’s access.log file looks like this:

anipaddress - - [11/Apr/2026:00:36:36 +0100] "GET /sve01/7/63/41.pbf HTTP/1.1" 200 1016621 "https://map.atownsend.org.uk/vector/index.html" "Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0"

Here the path to the vector tile can be clearly seen. The “200” is the code for “yes that request was served successfully”, and the “1016621” is the size of the data returned. The browser had requested https://map.atownsend.org.uk/vector/index_svwd01.html#7/51.407/0.178 , and that zoom 7 tile contains most of southern England.

In terms of tile size, what I saw before any optimization in March 2025 was this:

zoom  a big example tile
0     19490
1     19076
2     8468
3     5442
4     69416
5     108941
6     735912
7     810916
8     1455666
9     2065707
10    1060757
11    562848
12    532770
13    343290
14    190211

The various parts of the problem

Clearly I needed to reduce the amount of data contained in a zoom 8 tile, but how? Why was it so big in the first place?

The vector style contains X because someone might want to show it.

I had originally thought of the schema as being one that could support multiple styles. There were a couple of places where I was writing things into tiles because I thought that I (or some other consumer) might want to create something to show it later. This was the same approach as I’d used for the raster tiles database - there information is stored in the database to track changes to certain objects but isn’t used for display.

In order to reduce vector tile size I removed places where I’d done this on vector.

All X is displayed at zoom Y

This was the standard approach I’d used for raster tiles (inherited from early OSM Carto versions). The cost on raster wasn’t especially noticeable, because on raster it only affected render time, and if an old tile existed that was always sent to the user first (or, if zooming in, an overzoomed lower-zoom tile). Where previous tiles existed users weren’t faced with blank space, and the CPU effort to generate a new tile was on the server, not on their device.

On vector, the architecture means that this is no longer true. A large and complicated vector tile has a direct impact on the client, and the user waiting for a map has to wait while their client creates a map from it.

A challenge is that some features may be either very large or very small. If you look here you can see that some natural parks / nature reserves are large enough to be worth showing at the zoom level (but many aren’t), and similarly some lakes are large enough the show (mainly in Ireland) but that the smaller English and Welsh lakes aren’t.

In the code, the water logic can be seen here. That then calls set_way_area_name_and_fill_minzoom_sea to decide which vector tiles to actually write details to. That in turn honours sqkm values for point features representing “large woolly areas” by using set_sqkm_name_minzoom.

If you zoom in here you’ll see initially just Irish lakes, then the largest Welsh and English ones, and eventually the smallest.

This approach allows some previously unshown large features to appear. Fir example, the large military area off Essex has been added to vector at relatively low cost (there are few of that size) but did not appear on raster.

Finding out how many of X of size Y there are

I have a rendering database for use for raster tiles for the same map style, and it can be useful for queries like this:

gis=> select osm_id,name,way_area from planet_osm_polygon where "natural" = 'water' order by way_area desc;

The top values are as expected:

   osm_id   |                              name                              |   way_area    
------------+----------------------------------------------------------------+---------------
   -1121118 | Lough Neagh                                                    |   1.13296e+09
    -189915 | Lough Corrib - Loch Coirib                                     | 4.6095802e+08
     -12889 | Lough Derg                                                     |   3.21772e+08

and if we look at it the other way around:

gis=> select osm_id,name,way_area from planet_osm_polygon where "natural" = 'water' and name!='' order by way_area asc;

   osm_id   |                              name                              |   way_area    
------------+----------------------------------------------------------------+---------------
 1303491300 | Porthmadog Harbour                                             |      0.010894
  304781034 | Rainwater Collection Butt                                      |       1.12869
  304780098 | Rainwater Collection Butt                                      |       1.12869
  304781037 | Rainwater Collection Butt                                      |       1.12869
  304781038 | Rainwater Collection Butt                                      |       1.12869
  304781033 | Rainwater Collection Butt                                      |       1.12869
  304781035 | Rainwater Collection Butt                                      |       1.12869
  304781036 | Rainwater Collection Butt                                      |       1.12869
  969325744 | Well                                                           |       1.62326
 1449480418 | Ditch of Bert                                                  |       1.67907
  728196775 | 130                                                            |       1.98514

For info, the first of those seems to be a bit of extreme “tagging for the renderer”. The “Rainwater Collection Butts” are “reservoirs”(!) on some allotments and “Ditch of Bert” is a school pond.

The raster database “way_area” is not the same value as Tilemaker’s vector one, but it is still useful.

Results of this optimisation

Before, the largest vector zoom 8 tile was 1455666. Afterwards, it was reduced to 729085, around 50% of the previous size. Success!

A worked example (in 2026)

In order to come up with more data for this diary entry, I wrote a simple script to analyse Apache logs and report on the largest tile at each zoom level. I then loaded only “Greater London” locally, in order to create a baseline to test against. Tile sizes were:

129951    6
281487    7
389658    8
2115753   9
1881853  10
3541994  11
1686270  12
802204   13
492326   14

Note that some low zoom tiles show much more than just the loaded area and so are artificially smaller; but the same date will be used for subsequent tests meaning that differences are relevant,

One obvious difference is the jump in size at vector zoom 11. That corresponds to where buildings are first drawn. To see if that is coincidence, let’s move buildings to vector zoom 12 as a test:

129719   6
282138   7
390274   8
2117479  9
1884428  10
880557   11
1686348  12
802561   13
492375   14

So that’s a big difference, and not a coincidence.

Next, how to look at building sizes? Let’s load Greater London into a raster database and have a look at way_area there. Here are some examples:

   osm_id   |                                         name                                         | way_area
------------+--------------------------------------------------------------------------------------+----------
   18926167 | Dagenham Engine Plant                                                                |   463567
   -1895281 | The O2                                                                               |   218893
  200652378 | Brent Cross Shopping Centre                                                          |   110867
  357278392 | Sainsbury's                                                                          |  49090.2
  227053396 | Wanis Cash and Carry                                                                 |  25921.4
   30327519 | Barking Bus Garage                                                                   |  12756.5

Using MapLibre debug it’s easy to see the vector way_area corresponding to these places - zoom in until the label is shown, and way_area is an attribute of the label in the style.

I want to include the largest buildings only in zoom 11 vector tiles, more at z12 and z13, and everything at z14. I experimented with values until I was happy with both the reduction in tile size and the visual results. The logic I ended up with was this:

if ( passedt.way_area > 5000 ) then
    MinZoom( 11 )
else
    if ( passedt.way_area > 2500 ) then
        MinZoom( 12 )
    else
        if ( passedt.way_area > 1250 ) then
            MinZoom( 13 )
        else
            MinZoom( 14 )
        end
    end
end

and the results?

129588    6
281145    7
389723    8
2115639   9
1882556  10  100%
898182   11   25%
726818   12   43%
552760   13   69%
492121   14  100%

That’s a significant reduction in tile size. Arguably zooms 11 and 12 are more usable because they’re not cluttered with lots of very small buildings

What next?

Clearly there’s more work to do, both regards to “tile size” and legibility. Zooms 9 and 10 are pretty crowded in London and the tertiary colour (which first appears there) really doesn’t work, especially over some types of landuse.