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.

The Beginning – Discovering JOSM..

I never imagined my mapping journey would reach this point in time. I would like to share with you my experience, which carried both doubts and excitement for my team and me—the thrill of learning Java OpenStreetMap (JOSM) and climbing the staircases that led to building victories in the Africa Map Cup 2026 Tournament. My name is Alvin Andrew Barugahara, also known as AlvinB (OSM name), a student from a mapping community in Uganda called Spatial Mappers at Ndejje University. I had always heard of JOSM and its simplicity in mapping OSM tasks. Back then, I was just a beginner mapper using iD editor, which was the default platform. It wasn’t bad, but it required constant internet access and had a small working window with few shortcuts, making mapping slow. My captain, Aikiriza Justus (OSM name), had a vision of teaching us how to use JOSM and become “advanced mappers.” He guided and pushed us beyond our limits through various Google meetings, preparing us for the Africa Map Cup 2026, which began on 7th February 2026. “Stay tuned for the next part of my Africa Map Cup journey…”

Solar Farms

Looking into getting a gist for where there are solar farm setups both on land and in water (lakes , ponds ) etc

So the John Muir Way has been open since the 21st of April. This long distance route is a Coast to Coast route between Helensburgh in the West—from where John Muir set off to the United States where he inspired the conservation movement and the creation of its national parks—to Dunbar on the East Coast where he was born and grew up.

We’ve covered most of the route in OpenStreetMap for a while. But until recently we’ve had a tiny gap missing. I was trying to figure out getting over to do it when I saw Martin McMahon had filled it in with a 9-mile walk between train stations—great effort!

twitter: to map that gap took 2 trains 1 to Helensburgh a 9 miles walk then train from Balloch. Great day

So with some not insignificant effort, we now have the complete route mapped. These can easily be seen by looking at a raw view of either the walking route or the cycling route on OpenStreetMap.

But where OSM comes into its own is the ability to actually do things with the data, so to kick things off I’ve created a set of GPX files of the route. These contain the full walking or cycling route and are suitable to be loaded into your GPS or phone app as aids to navigating the route.

• john_muir_way_cycling.gpx
• john_muir_way_walking.gpx

Map wise, as always I’m disappointed to see the otherwise very nice John Muir Way website using Google Maps rather than an OpenStreetMap based map:

There are also tools such as Relation Analyser. Interestingly this shows cycling distance as 206km and the walking distance as 213km while the route is officially 215 km (I guess they rounded up).

So almost as often as I post, I rewrite the site. This time I have switched it to Octopress. This is the 3rd blogging engine, I’ve used

I don’t get enough hits to justify the performance need of a static site, but it has the advantage of being one less wordpress site to maintain, and for me writting posts using markdown in vim is a definite win.

I have also taken the oportunity to switch to a small cluster I’ve setup using ByteMark’s BigV

Also a change, the code for this site is all on github. The commit history provides a nice history of the work and changes I’ve made to the standard Octopress site. This is largely in area’s of the category handling, and removing the banner. I may base some future posts on this.

Below I will outline improvements for data interoperability regarding Wilderness Study Areas in the United States: https://en.wikipedia.org/wiki/Wilderness_study_area

OpenStreetMap tagging:

• Main article: osm.wiki/United_States/Public_lands#Guidelines_for_tagging_conservation_areas)

Wikidata identifiers:

• Instance of: Wilderness study area
• Authority: BLM/USFS/etc.
• Inception
• Coordinates
• Described by source
• Area
• Official website
• Recreation.gov Gateway
• OSM Relation

Wikimedia Commons

• Wikidata Infobox template: {{Wikidata Infobox

  qid=}}

• Images
• Locator Maps
• PDFs of wilderness plan/study documents

A few days ago, I asked the community about converting general GIS polygons into OSM multipolygon relations. I’ve searched online but haven’t found a workflow that fits my needs. Specifically, I am looking for a way to handle three different levels of administrative boundaries where adjacent areas share a single boundary line connected via a relation.

My question on the OSM forum is still awaiting a solution: Link

However, someone from my local community mentioned that what I’m looking for is “topology.” While that is a broad GIS term, they clarified that TopoJSON is a specific format designed for this. There are many converters available to turn GeoJSON into TopoJSON.

Interestingly, I found that someone opened a ticket for a TopoJSON converter in JOSM back in 2020, but it hasn’t received a response yet: Link

I’m planning to update and expand the administrative boundaries for Bali in OSM. I’ve already prepared the multipolygons for admin_level 5, 6, and 7 using single shared ways for efficiency. By leveraging Google Sheets, I’ve also compiled a comprehensive list of Wikidata, Wikipedia links, and multilingual names to better serve Bali’s international profile.

However, the conflation process is proving to be a challenge. The existing data is quite a “nightmare” to clean up; many roads and waterways are currently shared with administrative relations, and landuse or natural features are glued to the boundaries. Time to start untangling!

O víkendu jsem se vydal na malý výlet vlakem. Nastoupil jsem do vozu GW Train, který mne vezl až do Horní Plané u Lipna. Jedu s tímto dopravcem poprvé a je to všechno v pohodě. Těším se na vycházku a výstup na rozhlednu Dobrá voda.

Posadím se a hned si všimnu, že na stěně vozu je uchycena široká obrazovka infopanelu. Ukazuje aktuální stanici a v druhé části obrazovky je vyobrazena mapa s pohybujícím se bodem na trati.

Vlak projíždějící Českým Krumlovem, foto Aktron, CC BY-SA 4.0

Ani nemusím jít blíž, abych rozeznal, že ta mapa je OpenStreetMap a že mě toto malé objevení udělalo radost. Je to jedna z mnoha praktických použití mapy, která nemusí být jen na počítači, nebo v mobilu.

Při výletu po Horní Plané si všímám dalších nových detailů a zajímavostí ve městě. Horní Planou jsem před časem mapoval. Teď si ji konečně prohlížím naživo.

Večer když dojedu domů se vracím k mapě a doplňuji několik drobností, které ještě na mapě nejsou. Těším se že toto léto uvidím spoustu takových míst.

Memetakan batas administrasi di Indonesia bisa jadi cukup rumit, terutama saat menghadapi nama wilayah yang serupa. Berikut adalah alur kerja (workflow) sederhana saya dalam menyiapkan data tersebut:

1. Sumber Data

Pertama, unduh data spasial resmi dari Peta Rupa Bumi oleh Badan Informasi Geospasial (BIG). Data ini berfungsi sebagai sumber geometri utama.

2. Ekstraksi Titik Lokasi (Place Nodes)

Karena data sumber berbentuk poligon, saya menggunakan QGIS untuk mengekstrak titik tengah (centroid). Titik-titik ini penting untuk membuat tag place=* yang mewakili pusat dari tiap wilayah administrasi.

3. Pentingnya Kode Kemendagri

Poligon tersebut mencakup kode referensi Kemendagri. Kode ini sangat vital untuk:

• Konflasi: Memastikan data cocok dengan set data lainnya.

• Identifikasi: Banyak desa (admin_level 7 atau 8) memiliki nama yang sama. Kode ini membantu membedakannya dalam satu Kabupaten atau Provinsi.

4. Pengayaan Metadata

Menggunakan alat spreadsheet dan teknik konflasi, saya mencocokkan data untuk menambahkan:

• Tag wikidata dan wikipedia.

• Nama dalam berbagai bahasa (name:en, dsb).

5. Pengolahan Geometri

Sesuai dengan praktik terbaik (best practices) di OSM, saya mengubah poligon menjadi garis terpisah (polylines).

• Hal ini memungkinkan wilayah yang bertetangga untuk berbagi satu garis batas yang sama melalui relasi multipolygon.

• Setelah dikonversi, saya mengekspor hasilnya dalam format .geojson.

6. Pengetagan Akhir (Final Tagging)

Terakhir, saya menggunakan titik lokasi (place nodes) yang telah diekstrak sebelumnya untuk menyalin dan menempelkan tag yang relevan ke dalam relasi multipolygon baru di editor OSM.

Mapping administrative boundaries in Indonesia can tricky especially when dealing with overlapping names. Here is my simplified workflow for preparing this data:

1. Data Sourcing

First, download the official spatial data from Peta Rupa Bumi by Badan Informasi Geospasial. This serves as the primary geometry source.

2. Extracting Place Nodes

Since the source data is in polygon format, I use QGIS to extract the centroids (points). These points are essential for creating the place=* tags that represent the center of each administrative area.

3. The Importance of Kemendagri Codes

The polygons include Kemendagri reference codes. These are vital for:

• Conflation: Ensuring data matches across different sets.

• Identification: Many villages (admin_level 7 or 8) share the same name. The code helps distinguish them within a Regency or Province.

4. Enriching Metadata

Using spreadsheet tools and conflation techniques, I cross-reference the data to add:

• wikidata and wikipedia tags.

• Multilingual names (name:en, etc.).

5. Geometry Processing

To follow OSM best practices, I convert the polygons into independent ways (polylines).

• This allows adjacent areas to share a single boundary line via a multipolygon relation.

• Once converted, I export the result as a .geojson file.

6. Final Tagging

Finally, I use the previously extracted place nodes to quickly copy and paste the relevant tags into the new multipolygon relations in my OSM editor.

Comme ailleurs dans le monde, les installations photovoltaïques se multiplient en Belgique. En 2022, 68 ans après les débuts du photovoltaïque, la capacité mondiale en panneaux photovoltaïques atteignait son premier TW. Il n’aura fallu que 2 ans pour que 1 TW supplémentaire soit ajouté en termes de capacité mondiale en 2024. Et le rythme s’accélère encore.

En Belgique, d’après electricitymaps, il y aurait une capacité installée de 11.5 GW, soit environ 1 kW par habitant, une puissance à peu près équivalente à la charge électrique moyenne du pays. Toutefois, difficile de trouver des chiffres précis, à jour et encore moins la répartition spatiale de ces installations.

Récemment, je vois passer l’info que l’équipe du géoportail wallon travaille justement sur un inventaires des installations photovoltaïques au sol. Du coup, j’en ai profité cette semaine de faire un tour des centrales solaires de Wallonie (la moitié sud de la Belgique) enregistrées dans OSM, en vérifiant les données et les complétant. J’ai même découvert et ajouté quelques centrales photovoltaïques.

Mais comment les ajouter dans OSM ?

Il y a une très grande diversité d’installation photovoltaïques: depuis le panneau isolé sur un balcon ou la toiture d’une maison, jusqu’à la centrale solaire photovoltaïque de plusieurs MW, composé de milliers de panneaux. Dans OSM, on distingue d’une part les centrales solaires et d’autre part les panneaux solaires. Les centrales solaires photovoltaïques sont constituées d’un ensemble de panneaux, tandis que les petites installations sont composés uniquement de panneaux.

Dans OSM, on ajoute une centrale solaire avec les tags “power=plant” + “plant:source=solar” + “plant:method=photovoltaic” + “plant:output:electricity=*” (voir le wiki osm.wiki/Tag%3Aplant%3Asource%3Dsolar). On dessine généralement une surface qui englobe les panneaux, qui sont plus ou moins espacés selon les cas, et uniquement pour les “grosses” installations.

Pour les panneaux solaires (ou ensemble de panneaux), on utilise les tags “power=generator” + “generator:source”=”solar” + “generator:method”=”photovoltaic” + “generator:output:electricity=*” (voir osm.wiki/Tag%3Agenerator%3Asource%3Dsolar). On peut y ajouter le tag (redondant mais bon)”generator:type=solar_photovoltaic_panel” ou encore le nombre de panneaux (“generator:solar:modules=*”) et le type de montage/localisation (location=*). L’éditeur JOSM facilite énormément l’ajout des panneaux, surtout dans les centrales solaires, en copiant-collant les panneaux d’un bloc à l’autre.

À partir de quand considérer qu’un ensemble de panneaux est une centrale solaire? D’après le wiki, à partir d’une installation de 1 MW (à peu près 1600 panneaux de 600W!), mais dans les faits, des installations de moindre puissance sont caractérisées comme des centrales solaires en Belgique (“power=plant”).

Combien de centrales et panneaux en Wallonie?

En attendant l’inventaire du géoportail wallon, voilà un aperçu de la situation dans OpenStreetMap en Wallonie.

• Centrales solaires: On en compte 41 avec cette requête. Après analyse dans QGIS, leur surface cumulée est de 203 ha, la plus grande faisant 37 ha. La plupart sont complétées par une cartographie détaillée des ensembles de panneaux.

• Panneaux solaires (ou plutôt ensemble de panneaux): à la fois représentés par une surface ou par un point, on en compte à peu près 7200 en Wallonie, couvrant une surface totale de 196 ha (requête). Attention, ce nombre est en-dessous de la réalité, puisqu’une petite partie seulement du territoire est cartographié en ce qui concerne les panneaux des installations résidentielles, en fonction de l’activité des contributeurs locaux.

• Panneaux solaires au sol (en excluant ceux présent sur les batiments): 1992, sur une surface de 133 ha. Ce sont les grandes installations et des installations moyennes, mais très variables, entre les 2-3 panneaux mis dans un jardin résidentiel, et les centaines de panneaux d’une installation industrielle (qui pourrait être caractérisé comme une centrale).

• Panneaux solaires dans les centrales: 1115 objets couvrant 95 ha (à peu près la moitié de la surface des centrales, principalement parce qu’il manque la cartographie détaillée des panneaux dans certaines grandes centrales très récentes)

• Deux ensembles de panneaux seulement sont indiqués comme flottant sur l’eau (tags “location”=’overwater’ ou “floating”=’yes’).

• Enfin, un truc amusant, il existe aussi un tag pour les tracker solaires, des installations capables de suivre la course du soleil en suivant sa direction et son inclinaison. Un très bon moyen de maximiser le rendement des panneaux. On en compte une quarantaine seulement, un nombre probablement sous-évalué.

Pour information, un des meilleurs rendus cartographique de ces installations est l’application openinframap, avec notamment une carte de chaleur (heatmap) des installations photovoltaïques.

N’hésitez pas à compléter les installations photovoltaïques près de chez vous.

Happy mapping,

Люди, кто пишет в дневниках: вот, я стал картографом,..мне это всё понравилось,…ура ура ура… Большая просьба: не превращайте только карты в игру для развлечений! Не вносите правки и не присваивайте имён, если вы Лично не проводили исследования в данном районе! Надеюсь что большинство прочитавших всё-таки поймут меня.

Es macht besonders Spaß, draußen an der frischen Luft zu kartieren. Gerade jetzt, wo es wieder wärmer wird, ist das durchaus eine angenehme Art zu mappen. Doch das wäre ohne bestimmte Tools gar nicht möglich. Da dein Smartphone selbstverständlich um einiges kleiner als ein PC-Bildschirm ist, ist es wichtig, die richtigen Tools auf dem Handy zu haben, um den Überblick zu behalten und effizient arbeiten zu können. Doch welche Apps eignen sich für dich? Und überhaupt: Welche Apps gibt es da eigentlich?

1. Einsteigerfreundlich, schön und einfach: StreetComplete

Um StreetComplete kommst du nicht drumrum. Es ist einfach zu bedienen, schön gestaltet und vor allem gamifiziert. Und genau dieser zugrunde liegende spielerische Ansatz macht die App so gut. Statt die Tags manuell für Objekte einzutragen, sucht die App nach fehlenden Tags, die du dann durch die Beantwortung einer Frage hinzufügen kannst. Zudem gibt es Abzeichen, Statistiken und Rankings, die dich motivieren weiterzumachen. Meiner Meinung nach macht die App aber auch ohne diese schon süchtig genug …

2. Da geht noch mehr: SCEE (StreetComplete Expert Edition)

SCEE ist prinzipiell eine abgewandelte Version von StreetComplete. Ihr Ziel ist es, die App auch für dich als etwas fortgeschritteneren Mapper zugänglich zu machen. So lassen sich Tags anzeigen und bearbeiten, mehr Fragen zu spezielleren Tags aktivieren und diese sogar leicht modifizieren. Ich persönlich nutze dieses Tool hauptsächlich, da es für mich den besten Kompromiss zwischen Übersichtlichkeit bzw. schönem Design und tieferem Mapping bietet. Wichtig zu wissen: Du findest diese Version meist nicht im Play Store, sondern musst sie über F-Droid oder GitHub beziehen.

3. Anwender und Beitragender zugleich: OsmAnd

OsmAnd ist eine der größten OSM-basierten Kartenapps überhaupt und bietet Unmengen an Features und eine unheimliche Anpassbarkeit. So hast du auch die Möglichkeit, OpenStreetMap-Bearbeitungen direkt in der App vorzunehmen. Meiner Ansicht nach eignen sich diese Bearbeitungsmöglichkeiten aber primär für kurze, kleine Fehler in der Karte, die dir während der normalen Nutzung der App auffallen. Es ist eher ein nettes Feature, aber nennenswert, gerade deswegen, weil du einen Editor direkt in der App hast, die du eventuell sowieso schon nutzt. Denk nur daran, dein OSM-Konto in den Einstellungen zu verknüpfen, damit der Upload klappt.

4. Das absolute Monster: Vespucci

Vespucci ist wohl die umfangreichste Option überhaupt. Die App ist nun schon 17 Jahre alt und hat so ziemlich alles, was du brauchst, um OSM-Bearbeitungen jeglicher Art vorzunehmen – quasi der JOSM für die Hosentasche. Ich nutze es vor allem, weil es anders als SCEE und andere Tools die Möglichkeit bietet, Linien und Polygone zu erstellen. Dies ist praktisch, wenn du mal eine lange Sitzbank als Linie oder einen größeren Fahrradparkplatz als Fläche eintragen möchtest. Es sei jedoch gesagt, dass es eine gewisse Einarbeitungszeit erfordert und für dich eventuell nicht ganz so intuitiv ist, da man hier auch leichter mal versehentlich bestehende Daten verschieben kann.

5. Ein angenehmer Mittelweg: Every Door

Every Door ist wieder etwas übersichtlicher. Hier arbeitest du in vier Kategorien: Dinge, Orte, Häuser und Notizen. In der oberen Bildschirmhälfte befindet sich dann die Karte mit – je nach aktiver Kategorie – farblichen Markierungen oder Zahlen, die in der unteren Bildschirmhälfte definiert werden. Besonders stark ist die App beim Erfassen von Ladenöffnungszeiten oder Mikromapping wie Mülleimern und Bänken. Durch das Tippen auf ein bestimmtes Objekt gelangst du dann in einen grafisch ansprechend und verständlich gestalteten Tag-Editor, der aber auch zu einer Listenansicht umgeschaltet werden kann. Ich persönlich nutze die App nicht sehr oft, da mir der Workflow in SCEE besser gefällt. Es stellt aber eine gute Alternative dar, wenn du mit SCEE nicht zufrieden bist.

6. Mappe, was dich interessiert: MapComplete

Es handelt sich erneut um eine App, die grafisch ansprechend und einsteigerfreundlich gestaltet ist. Beim Start der Anwendung wählst du zunächst eine Themenkarte aus, bei der du je nach Thema nur bestimmte Objekte bearbeitest und hinzufügst. Beim Anklicken eines POIs werden dir ähnlich wie in StreetComplete bzw. SCEE Fragen zu fehlenden Tags angezeigt. Ich persönlich finde das Konzept und die Idee sehr schön, gerade auch deswegen, weil du eigene Themenkarten erstellen kannst. Leider basiert die Android-App aber auf WebView, was die App ganz schön verlangsamt. Ein kleiner Tipp: Falls sie bei dir auch hakt, nutze sie einfach direkt im Webbrowser deines Handys und erstelle dir eine Verknüpfung auf dem Homescreen – das läuft oft flüssiger.

7. Eine simple Ergänzung: OSMfocus Reborn

Wenn du einen schnellen Blick auf alle Tags eines Objektes werfen willst, kannst du einfach schnell OSMfocus Reborn öffnen, damit siehst du direkt alle Tags von den Objekten in deiner Nähe ohne einen einzigen Klick. Wenn dir die Ansicht nicht reicht, hast du aber auch die Möglichkeit, auf ein bestimmtes Objekt zu tippen, um alle Tags in voller Länge zu sehen.

Mit diesen Tools steht deinem mobilen Mapping mit einem Android-Smartphone nichts mehr im Weg. Probiere gerne alle Tools mal durch, ich bin mir sicher, dass du bei mindestens einer hängen bleibst. Bei Fragen, Ergänzungen oder Korrekturen schreibe bitte gerne einen Kommentar.

Viel Spaß beim Kartieren!

We’ve recently added GeoPackage (gpkg) files to the download server, in addition to the shape files we’re already offering. This seems to be a popular addition; over half of the previous shape file download traffic has already migrated to the newer GeoPackage format – combining all layers in a single file, GeoPackage is more convenient than the old shape format.

But there’s more: We have updated the layer structure in the shape and GeoPackage files to include more data. You can review the details in our format specification PDF; the most important news is that the free data sets now contain an administrative area layer which was previously only available in the paid data sets*.

We’ve also added a protected areas layer and many POIs, but taken great care not to upset things too much so that people shouldn’t have to re-tool their processing chains built for previous versions of our shape files. Enjoy!

(*) Note that OSM doesn’t have a hierarchy of admin levels (i.e. city X is in county Y is in state Z) by default, and neither are boundaries clipped along the coastline. Administrative area shape files that have these extra features are available from us commercially.

🗺️ Entry 1 — Setting up JOSM & Plugins

Mapping Banjë, Albania

I started mapping the Banjë region in Albania by setting up my editing environment in JOSM.

⚙️ Setup

I configured JOSM with a set of plugins to support structured mapping and validation:

• utilsplugin2 – general productivity tools
• reltoolbox – relation and multipolygon editing
• waydownloader – working with connected geometries
• merge-overlap – cleaning overlapping features
• Relation Validation Plugin – checking data consistency
• FastDraw – faster geometry digitizing

I also explored additional plugins like contour-related tools for terrain-based mapping.

🗺️ Mapping Context

The focus area is Banjë (central Albania) — a landscape with: - Complex terrain (valleys, rivers, slopes)
- Mixed land use (forests, agriculture, settlements)
- Incomplete or inconsistent OSM coverage

🌱 Initial Observations

• Landuse classification is often fragmented or overlapping
• Boundaries between forest, farmland, and settlements are not always clear
• Many features require clean multipolygon structures
• Validation tools already highlight conflicts in relations

🎯 Next Steps

• Clean and structure landuse polygons (forest, farmland, residential)
• Resolve relation conflicts and validation errors
• Improve consistency of tagging using presets
• Start refining settlement structures and road connectivity

เลขที่ 93/324 ถนนสุขุมวิท แขวงบางจาก เขตพระโขนง กรุงเทพมหานคร 10260

So, I’ve been using Altilunium LocationPad for several of my personal projects until now. But recently, I encountered several problems.

I dabble with multiple projects at once, but this app saves everything in a single database. I want this app to be able to create several separate “canvases”, so I can manage several of my projects at once, without mixing them with other projects.

For each canvas, the data is also exportable to JSON (and can be imported back too).

And, for a better “presentation view”, I made a shortcut (Ctrl + .) to temporarily hide/show all the UI elements, focusing on maps and markers.

And sometimes, I also want to directly copy a certain marker’s coordinates. From now on, when we click a marker, the raw coordinates are also shown.

v26.4.6 : This update introduces a more flexible workspace system by allowing users to create, edit, delete, and switch between multiple “canvas” environments. Each canvas now operates with its own independent database, making it easier to separate and manage different datasets or projects. The canvas manager behavior has also been refined. When the Ctrl + . shortcut is triggered, the canvas manager will now be properly hidden to ensure a cleaner interface and avoid visual clutter during use. Interaction with markers has been improved as well. Clicking on a marker will now display its precise coordinates, providing clearer spatial information directly within the interface. Finally, data portability has been expanded. Each canvas now includes an “Export to JSON” option, allowing users to easily back up or share their data. In addition, a new “Import from JSON” feature enables users to load a JSON file into a newly created canvas, simplifying data transfer and reuse across environments.