Die digitale Transformation wird oft abstrakt diskutiert. Mich hat jedoch eine praktische Frage beschäftigt: Wie kann ich in meiner Lehre zeigen, dass (Geo)Daten, Algorithmen und künstliche Intelligenz tatsächlich zur Lösung urbaner Herausforderungen genutzt werden können? Mir ging es dabei nicht nur um theoretische Konzepte, sondern um anwendungsnahe Lehrforschung: realen Daten, greifbare Fragestellungen und idealerweise einen konkreten Mehrwert für die Stadt Mainz.

Wieso bin ich ein Fan von Lehrforschungsprojekten? Die Studierenden haben sich in meinen Mastermodulen immer wieder klar positioniert: Sie wollen mehr Forschung, mehr Praxisbezug, „Hands-on“ und eigenständiges Arbeiten mit fachlicher Begleitung. Daraus ist folgendes Format entstanden: projekt- beziehungsweise problembasiertes Lernen anhand konkreter Projektausschreibungen. Im Modul „Geo-Government und Digitale Transformation“ arbeiten die Studierenden so in Zweierteams an Fragestellungen und entwickeln eigenständige Lösungsansätze.

Die Projektausschreibungen als Ausgangssituation

1. 1. Verkehrsfluss, Stauursachen und KI-gestützte Prognosen
      Mainz steht regelmäßig vor Herausforderungen durch Staus und stockenden Verkehr, insbesondere während der morgendlichen und abendlichen Rush Hour. Die hohe Verkehrsbelastung beeinträchtigt nicht nur die individuelle Mobilität, sondern wirkt sich auch auf Umwelt, Luftqualität und Stadtklima aus. Im Mittelpunkt steht daher die Analyse, wann und wo die größten Engpässe im Mainzer Stadtverkehr auftreten und welche räumlichen sowie zeitlichen Muster sich erkennen lassen. Ebenso ist zu untersuchen, welche Faktoren Stausituationen verstärken. Aufbauend darauf soll geprüft werden, wie KI-gestützte Verfahren dazu beitragen können, Verkehrsflüsse präziser vorherzusagen und gegebenenfalls aktiv zu steuern.
   2. Bikesharing in Mainz: Nutzung, Nachfrage und Verfügbarkeit
      Bikesharing gilt als flexible und nachhaltige Alternative zum privaten Pkw und ist ein wichtiger Baustein moderner urbaner Mobilitätskonzepte. In der Praxis zeigt sich jedoch häufig ein Ungleichgewicht: An stark frequentierten Standorten fehlen zu Stoßzeiten verfügbare Räder, während sie an anderen Stationen ungenutzt bleiben. Ziel ist es, räumliche und zeitliche Nutzungsmuster zu analysieren, Engpässe und Überangebote zu identifizieren und Einflüsse wie Tageszeit, Wochentag oder Wetterbedingungen zu berücksichtigen. Darauf aufbauend stellt sich die Frage, wie KI-gestützte Modelle dazu beitragen können, Verfügbarkeit und Nachfrage besser aufeinander abzustimmen.
   3. Parkhausnutzung und intelligente Lenkung des Innenstadtverkehrs
      Viele Autofahrende kennen die Situation: Statt direkt einen freien Stellplatz zu finden, kreisen sie durch die Innenstadt. Dieser Parksuchverkehr erzeugt zusätzlichen Verkehr, erhöht Emissionen und belastet die urbane Infrastruktur. Zu analysieren ist, wie sich die Auslastung der Parkhäuser über Tages- und Wochenverläufe verteilt und welche wiederkehrenden Muster, etwa bei Veranstaltungen oder Ferienzeiten, erkennbar sind. Darauf aufbauend soll untersucht werden, wie KI-gestützte Prognosen helfen können, Belegungsentwicklungen vorherzusagen und Parksuchverkehr gezielt zu reduzieren.

Forschung statt Reproduktion: Mein didaktischer Ansatz
Das Lehrformat verfolgt bewusst einen forschungsorientierten Ansatz. Im Mittelpunkt stehen weder reine Literaturarbeiten noch bloße Demonstrationen bestehender Tools. Stattdessen sollen die Studierenden eigenständig Hypothesen entwickeln, ein geeignetes Forschungsdesign konzipieren und reale Datenbestände analysieren. Entscheidend ist dabei für mich nicht die Präsentation einer vermeintlich „perfekten Lösung“, sondern der Aufbau einer gewissen Methodenkompetenz, die Förderung kritischen Denkens und die reflektierte Anwendung von KI. Gerade in einem Masterstudium geht es meines Erachtens nicht allein um die Fragen „Was ist technisch möglich?“, sondern vielmehr um: Was ist fachlich sinnvoll, ethisch vertretbar und (administrativ) umsetzbar?

Und wer weiß, vielleicht münden die Ergebnisse am Ende sogar in eine Publikation …

 

Part of the rationale for getting a folding bike was that I could avoid climbs by putting it in the boot of the car and heading out for flat rides in areas that are less hilly than our immediate surroundings. The plan has worked, but after a few months I felt ready for something a bit more demanding. At the weekend I tried routes around Wooler, but the weather wasn't great and that turned into a short, cold ride with showers of rain and hail. 

Three days later the weather today was a big improvement. So I headed back to Wooler to attempt something more ambitious. I began by revisiting Weetwood and Fowberry. Instead of turning back I then headed for Chatton. Then on to Chillingham, where I had a break outside St Peter's Church. I continued south, almost as far as Old Bewick. Then back via Lilburn Tower. I wanted to avoid riding along the busy A697 so I had intended to head north through Haugh Head. However, I missed the turning. A short stretch along the A697 wasn't as bad as I feared, then I was back on quiet country lanes and the Pennine Cycleway through North Middleton, and Coldgate Mill.

Highlights of the ride were the quiet roads, a variety of fords and old bridges, and great views across lovely countryside. The hedges haven't started to blossom yet, but spring is definitely in the air. I couldn't have asked for better weather. I was looking for something a bit more demanding than usual, and this certainly wasn't as flat as I've been used to. But for a ride of just over twenty miles, it felt more demanding than I intended. I'm not ashamed of getting off and pushing. But really, a bit more practice across similar terrain  is called for. 

Прогулка с StreetComplete — добавил 300+ объектов в Минске. Приятно видеть, как карта наполняется деталями!😊

3 March 2026: Writing this at a Missing Maps “London” remote meeting, realizing that I’d never written a OSM diary about the research I did within the ecosystem. I’m so late! But I’d love to still write this down.

I started a new wiki talk page discussion on the conflicting/controversial usage of the wetland=tidalflat tag regarding implied and explicit surface types:

• Change of definition to mainly encompass mud and discourage use on sand flats

Also posted a comment on positive related changes being worked on by the carto team:

• openstreetmap-carto PR: #5067 Use dedicated style for landcover polygons over water

Hoy comienzo la plenitud de mi sinceridad

This FAQ is continuously being improved and expanded and may change at any time.

Q: Why does SOSM oppose the MODI bill, isn’t improving the efficiency of our mobility infrastructure a good thing?

A: We have always supported making more mobility data available and suggested that it is one of the missing pieces to creating viable competing services to google and Apple. We are simply opposed to regulation that couples access to that data to use of the navigation data of a single market player.

Q: What is Verkehrsnetz Schweiz and why is it a problem?

A: Update March 2026

For transparency sake the full previous version of this FAQ item can be found below.

swisstopo currently positions Verkehrsnetz Schweiz as a set of tools that allows building more complete datasets from their routable base transport data swissTNE Base in an automated fashion and allowing third parties to incorporate their ids in a so generated dataset.

This is technically an interesting approach, particularly compared to the monolithic design used in Austria and that is now emphasised in swisstopos marketing. However this does not really address our concerns that use of MODI is legally closely tied to the use of swissTNE Base as the reference dataset and the proposed law does not mandate any other way of access.

It should be clear that while swisstopo has not announced that it will publish an enriched version of swissTNE including the additional data (POIs, buildings etc) required for a full navigation product, it is building the tools to do exactly that. In the swisstopo app navigation support is already available and swisstopo is clearly already competing in this space.

The situation is similar to if google claimed that google maps is just the internal tools they use to build the google maps service, in a certain fashion true, but at the same time very misleading.

Previous version:

Verkehrsnetz Schweiz is swisstopos new product entry in to the navigation data market.

Verkehrsnetz CH is a completely conventional set of geodata suitable for navigation and similar purposes just like the products Tomtom, Here, apple, google, OpenStreetMap and others have been creating since decades. As any of these players will attest to, aggregating data from multiple sources, applying quality checks, arranging for updates and so on is the name of the game, and not something that is unique to swisstopos product.

The navigation data market is healthy with many competitors to choose from even though most consumers use products from google, a further player with a “me too” product is likely not a concern for any of the other players or us.

Matter of fact we are a bit tickled by the fact that OSM it important enough that one of the key competitive features of Verkehrsnetz CH is that it will be available in an OSM compatible format so that swisstopo it can easily use it to push out OpenStreetMap of existing applications.

Realistically the market for such a product in isolation is small, however legally and technically coupling the access to the mobility data infrastructure to use of Verkehrsnetz Schweiz changes this equation and will tilt the playing field substantially to the advantage of swisstopo.

Q: Do you have an example why the coupling of MODI access to Verkehrsnetz Schweiz would be anti-competitive?

A: Update March 2026

swisstopo has removed mentions of producing an OSM compatible dataset as a core requirement of Verkehrsnetz CH.

Consider the following scenario:

You are running a, hypothetical, e-bike rental service, and the bikes have OSM-based navigation devices. You want to use the federal government’s mobility data (MODI) to improve navigation, e.g., to avoid closures or traffic jams. As required, you must use the Verkehrsnetz CH to retrieve the relevant data. In other words, you either have to make additional efforts to continue using original OSM in your navigation systems, or you can simply get data from swisstopo in an OSM-compatible format and frictionlessly access MODI.

And if you want to (automatically) make the usage status of your bike docks available to everyone, since multimodal navigation systems can then, for example, direct users to a dock that still has bikes, you will of course also have to use Verkehrsnetz CH data to upload the data to MODI, even if you otherwise use OSM to manage your locations.

If the access to the MODI data were designed to be both technically and legally provider-neutral, no one would be favoured. As planned, regardless of if we provide workarounds for access in the future or not, there will always be additional friction and uncertainty as to whether it will work correctly and users will gyrate to using Verkehrsnetz CH because it is “guaranteed” to work.

Q: This is Switzerland, shouldn’t have any disagreements on the bill been worked out before it got to this stage?

A: Yes you would have expected as one of the few organisations that are directly impacted by the regulation we would have been addressed early. However not only were we not invited to the consultation phase and had to, after we had found out, submit our statement within a day, our concerns have not been taken seriously by any of the bodies we have contacted.

It has to be said that we are arguing a fine techno-legal point here and the importance may be lost on many. Not to mention that we are small voice compared to the many swisstopo receptions, handouts to consultants and not to forget the cantons expecting free money from the federation.

Q: Won’t this rein google in and provide more opportunity for small businesses to provide services?

A: swisstopo has naturally played the bad big tech card in promoting Verkehrsnetz Schweiz a quote from their “Faktenblatt Verkehrsnetz CH” promotional material:

Kartendienste wie OpenStreetMap oder Google verfügen über umfassende Verkehrsdaten. Diese sind jedoch nicht in jeder Hinsicht frei zugänglich oder sind mit kommerziellen Interessen verbunden, z.B. werden beworbene Informationen bevorzugt angezeigt. Zudem ist nicht immer transparent, woher die Daten kommen.

The reference to OpenStreetMap was removed after intervention by us, it however nicely illustrates the mind frame of the authors.

But naturally companies like google and apple are unlikely to be affected at all as they do not provide direct navigation data access and can, if they even want to use the MODI data over what they already have access to, hide this behind their APIs and likely will save money in the process.

A look over the border to Austria where more than a decade ago a similar project was passed in to law, doesn’t show any less use of google, it does show a distinct lack of products that use OpenStreetMap or other sources and instead a de-facto monopoly for certain sectors that is based around the GIP (Verkehrsnetz CH equivalent) and the VAO (semi-private MODI equivalent). It should be noted that the VAO services are not free, which is the likely longer term MODI scenario too.

Q: Where can I find the text of the bill and related material?

A: Documentation of the MODIG bill from the federal council

Q: Isn’t this all open data and therefore not a problem?

A: Most parts of Verkehrsnetz CH and MODI are expected to be available as open data. However besides that not guaranteeing that the terms will be compatible with OSMs distribution licence, there are carve outs that might actually require update commitments and similar that would not be possible to fulfil in an OSM context, see fossgis.de Stellungnahme zum Mobilitätsdatengesetz for a similar issue with German regulation.

More importantly, while the promise of open data is that it will fuel innovation and create more economic activity, that would require the publishing entity to not itself corner the market with its own products. There is no legal requirement in Switzerland for this, and as swisstopo shows, the main effect of allowing it to publish data on open terms now is that it is under substantially less pressure to justify its offerings on economic terms. “it’s open data” has literally become the universal excuse for all its activities.

As mentioned above there is some hope that we will be able to use the published data to shoehorn MODI compatibility onto an OSM data distribution if the legislator decides not to require a vendor neutral access. But by its very nature this will be a 2nd class, high friction solution.

It really shouldn’t matter if you are building your app or service on Tomtom, Here, google, apple, OSM or swisstopo data and services, the technology is there to make MODI vendor agnostic, what is missing is the political will to require it.

Q: What are SOSMs concrete demands?

A: SOSM demands that the MODI components Verkehrsnetz CH and NADIM are decoupled and that the bill requires geodata-provider agnostic access to NADIM.

We further suggest that the establishment of Verkehrsnetz CH is moved to a separate bill to allow an independent evaluation and decision on the merits of the undertaking.

Q: Doesn’t the bill require that the MODI is independent of market players?

A: Art. 6 a. of the MODI bill stipulates “Die MODI ist von den Marktakteuren unabhängig” (MODI is independent of market participants). However it then completely ignores that by any definition, including its own, swisstopo is such a market participant, and that Verkehrsnetz CH is a product that swisstopo is actively promoting on the market.

Not only has swisstopo positioned itself as a competitor to other mapping service providers in its promotional material for Verkehrsnetz CH, it provides map services to web developers in competition to other players, and even offers products to end users in competition to other market participants. See for example https://www.swisstopo.admin.ch/de/swisstopo-app

Every map tells a story. Some stories are drawn with roads and buildings. Others are written through people, voices, and lived experiences. This is the story of how mapping became a bridge between climate vulnerability and community resilience in the heart of Dhaka. Under the Climate Resilience Fellowship, proudly supported by OpenMappingHub Asia Pacific, our Team 8 embarked on a journey called “Healthy Homes, Safer Futures.” Our goal was simple yet powerful: to strengthen climate awareness and resilience among vulnerable communities living in Dhaka’s urban informal settlements.

Where It All Began

In early May, all ten fellowship teams gathered in Dhaka, sharing ideas and aspirations for climate action. We were two coordinators: Mohammad Azharul Islam — Oceanographer and GIS Analyst at the Center for Geoservice and Research Ahsan Habib Saimon — Capacity Building Officer at Christian Commission for Development in Bangladesh Together, they envisioned a project that would connect data, digital tools, and grassroots knowledge to create safer living environments.

Walking Through Vulnerability

On 22nd August, our team stepped into the narrow alleys of Mirpur’s slum settlements. Climate change here is not an abstract concept it is visible in waterlogged pathways, overheated tin roofs, poor sanitation, and fragile housing structures. After consultations and careful observation, we selected Duaripara Slum as our core study area. Over the following days, we collected data from more than 400 households, representing over 8,200 people. But beyond the numbers were conversations, stories of survival, adaptation, and hope. Community leaders shared their concerns about flooding, health risks, and extreme heat. Residents spoke about their struggles but also about their determination. Mapping was no longer just about coordinates. It became about understanding lived realities.

Building Knowledge, Building Confidence

On 24th August, we conducted our first capacity-building training with 20 community participants from Duaripara. We discussed: - Climate risks in urban slums - Health impacts of poor WASH practices - Climate-smart hygiene behaviors - The power of community-led solutions Through practical demonstrations and interactive discussions, participants began to see themselves not as victims of climate change but as agents of change. The energy in the room was transformative.

1st Training

The first training focused on climate resilience and community preparedness, and it was facilitated by M. Rezaul Karim from Dushtha Shasthya Kendra (DSK). With his extensive experience in community health and development, he guided participants through the realities of climate vulnerability in urban informal settlements like Duaripara. The session explored how flooding, extreme heat, poor drainage, and inadequate sanitation directly impact household health and safety. Through participatory discussions and practical examples, he emphasized locally adaptable solutions, safe water management, improved hygiene behavior, and collective preparedness strategies. His facilitation style encouraged open dialogue, allowing participants to connect climate concepts with their daily experiences and recognize their own role in strengthening resilience.

2nd Training

The second training centered on community mapping and digital data collection, led by Mohammad Azharul Islam from the Center for Geoservices and Research and an OpenMappingHub GURU under OpenMappingHub Asia Pacific. He introduced participants to open-source mapping tools, particularly KoboToolbox, and provided step-by-step hands-on guidance on using smartphones for survey design and data submission. Participants learned how to collect GPS points, structure questionnaires, ensure data accuracy, and maintain ethical standards such as informed consent. The training transformed digital tools from unfamiliar technology into accessible instruments for community empowerment, helping residents understand how mapping can make their challenges visible and actionable.

Digital Skills for Local Change

On 5th September, we introduced participants to KoboToolbox, an open-source digital platform for field data collection. For many trainees, this was their first time using digital survey tools on smartphones. Curiosity quickly turned into excitement as they: - Learned to design simple surveys - Practiced submitting digital forms - Understood how community data can influence planning Technology, once distant and unfamiliar, became accessible and empowering. The following day, they took these skills into the field, collecting household data, speaking with neighbors, and documenting vulnerabilities. It was a powerful moment: community members mapping their own community.

Reflection and Impact

On 24th September, we gathered once more to reflect. Participants shared how they had: - Improved hygiene practices at home - Discussed preparedness measures with neighbors - Increased awareness about climate risks - Built confidence in using digital tools - Small behavioral shifts were already visible in cleaner surroundings, better conversations around sanitation, and stronger collective engagement.

“Healthy Homes, Safer Futures” was no longer just a fellowship project. It had become a shared movement.

You can learn more about our project through our website: Healthy Homes, Safer Future Also watch this video: Healthy Homes, Safer Future (YouTube)

Nimman Road, Chiang Mai(Thailand) is a well-mapped, high-traffic corridor. It scores a B on network density: good intersection frequency, reasonable block lengths. But it scores near zero on crossing coverage because there are no highway=crossing nodes tagged within the 800m analysis radius. The street has physical crossings. They’re just invisible to any tool that relies on OSM, which is most tools.

That’s what SafeStreets shows: not just a score, but which data gap is causing it.

What SafeStreets is?

A free tool that scores the walkability and pedestrian safety of any street address globally(graded out of 10). No account required, 190+ countries. OSM is the backbone, and the only data source that works everywhere.

How OSM powers it, three functions?

1. Address geocoding via Nominatim Every analysis starts here, with a ~50km geolocation bias for local lookups while preserving global search. No proprietary geocoding.
2. Street infrastructure scoring via Overpass API (800m radius) We query within an 800m circle for:

highway=crossing nodes → crossing safety footway=sidewalk and highway=footway ways → sidewalk coverage highway=primary/secondary/tertiary/residential/living_street → network topology Way attributes: lanes, width, surface, maxspeed, lit, sidewalk, cycleway

Four sub-metrics from this graph:

Intersection density (nodes with degree >= 3 per km2) Average block length (total street length / intersection count) Network density (total street km per km2) Dead-end ratio (degree-1 nodes penalize walkability)

These combine into the Network Design component (35% of the total score). 3. 15-minute city scoring via Overpass API (1,200m radius) Service reachability on foot, scored by nearest distance (<=400m = 100pts, <=800m = 75pts, <=1,200m = 50pts):

Grocery: shop=supermarket/convenience/greengrocer Healthcare: amenity=pharmacy/clinic/hospital Education: amenity=school/kindergarten/library Recreation: leisure=park/playground/sports_centre Transit: public_transport=stop_position/platform, highway=bus_stop, railway=station/tram_stop/subway_entrance Dining: amenity=restaurant/cafe/fast_food

This feeds the Accessibility component (25% of total score) and a separate 15-Minute City Score.

1. Map rendering via Leaflet + OSM tiles Scored infrastructure overlaid on OSM base tiles. What’s missing, and what would help We’re explicit in the UI about what we can and can’t measure:

✓ Crossings exist and where ✓ Lit / not lit (where tagged) ✓ Service accessibility via POIs ✗ Pavement condition ✗ Sidewalk obstructions (vendors, parked bikes) ✗ Crossing quality (marked, signalled, raised), sparse outside Europe/North America

The most useful contributions for Southeast Asian cities: sidewalk=, crossing=marked/uncontrolled/traffic_signals, and lit= on way segments. These tags directly change scores for real addresses. Nimman Road would improve immediately with accurate crossing nodes added.

The project

SafeStreets is live at safestreets.streetsandcommons.com. Built by Streets & Commons, a civic tech initiative based out SEA If you’re mapping in SE Asia and want to see a specific street analysed, or if you work on pedestrian tagging schema, I’d love to hear from you in the comments

Portal North Bridge construction and study documents

https://archive.org/details/@isstatenisland/lists/7/portal-bridge-documents?sort=date

I gathered and uploaded documents relating to the Portal Bridge capacity enhancement project and its replacement, Portal North Bridge. The documents (except the Amtrak bulletins) come from NJDEP’s DocMiner. The Amtrak bulletins were retrieved by FOIA request. It appears the FEIS disappeared off the web many years ago.

The original plans intended to build a 3-track fixed span to the north. The documents from 2019 and later depict the currently chosen plan, the two-track fixed structure to the north. The south structure is not funded.

https://archive.org/details/portal-bridge-project-feis-final-4f-october-2008 Portal Bridge Capacity Enhancement Project - Final Environmental Impact Statement and Final Section 4(f) Evaluation, October 2008

https://archive.org/details/portal-bridge-project-feis-final-4f-appendix-vol1-october-2008 Portal Bridge Capacity Enhancement Project - Final Environmental Impact Statement and Final Section 4(f) Evaluation, October 2008: Appendix Volume 1

https://archive.org/details/portal-bridge-project-feis-final-4f-appendix-vol2-october-2008 Portal Bridge Capacity Enhancement Project - Final Environmental Impact Statement and Final Section 4(f) Evaluation, October 2008: Appendix Volume 2

https://archive.org/details/portal-bridge-project-relocation-study-january-2010 Portal Bridge Capacity Enhancement Project - Relocation Feasibility Study, January 2010

https://archive.org/details/portal-bridge-project-gc02-construction-plan-sheets-2019 Portal Bridge Capacity Enhancement GC.02 Contract - Construction Plan Sheets, August 15th 2019

https://archive.org/details/portal-bridge-project-environmental-impact-sheets-2020-2025 Portal Bridge Capacity Enhancement Project - Environmental Impact Sheets, January 2020 with November 2025 modifications

https://archive.org/details/AMTK-NEC-employee-timetable-supplemental-bulletin-20260214-NYW1-25-b/mode/2up Amtrak - Northeast Corridor Employee Timetable Supplemental Bulletin 2026-02-14, NYW1-25-b

https://archive.org/details/AMTK-NEC-employee-timetable-supplemental-bulletin-20251213-NYW1-23-b Amtrak - Northeast Corridor Employee Timetable Supplemental Bulletin 2025-12-13, NYW1-23-b

Всем привет! Я GISTracer из Минска.

По базовому образованию — технолог-машиностроение. Работа с чертежами, допусками и технической документацией выработала главные качества: внимательность, усидчивость и привычку к точности. Именно они привели меня в OpenStreetMap.

Сейчас вхожу в тему профессиональной картографии и ГИС. Интересуюсь качественной векторизацией по спутниковым снимкам, работой в JOSM и постепенно наполняю карту полезными деталями.

Понимаю, что хорошая карта — это тысячи мелких правок, сделанных с вниманием. Этим и планирую заниматься.

Буду рад обратной связи и советам от опытных участников. Всем качественных тегов и чистых подложек!

1. 你驾车，Android Auto上使用OSM导航软件
2. 副驾不能晕车，放个笔记本在大腿上，在iD上连接两点，用编辑器把缺失的路现画上
3. 你在导航上规划路线，看哪里特别绕
4. 副驾对着卫星图画缺少的路
5. 你开车，副驾补全车道和路线信息

Until recently, I used generative AI (GenAI) for programming almost exclusively through the browser in the form of ChatGPT, Gemini, or via my own Ollama backend. My typical use cases ranged from “I need a function or a script that does …” to “There’s a bug in the following lines, how could I fix it?” A direct integration of GenAI into my development environments was not really on my radar. However, through my recent activities around OpenClaw, I kept running into coding assistants more often and I started wondering whether those assistants could be combined with (my) local large language models (LLM).

The Candidates
VS Code as an editor is nothing new, and neither the Copilot extension. I had simply never tried it before. Claude Code is Anthropic’s CLI-based development environment and so far (for me) it has a strong focus on Git workflows, project understanding, and structured refactoring. On the other hand, OpenAI offers Codex as a CLI variant for AI-assisted coding.

Installation and First Tests
VS Code worked as a regular editor right away. Claude Code and Codex could both be installed on my macOS system with just a few terminal commands. Setting up a local Ollama server in those tools was a bit more challenging. With Claude Code, in the simplest case, three environment variables with the connection parameters were enough. Codex was somewhat trickier. The profile configuration and model naming did not quite match up at first. Due to a current bug in VS Code, I initially couldn’t connect my own Ollama server there. My attempts with a proxy failed. So things escalated a bit: I switched to VS Code Insiders, checked out the Copilot extension locally from GitHub, built it myself, and integrated the extension directly. Looking back, this took by far the most time, especially compared to the other tools. However, classic YouTube examples such as Flappy Birds or Tetris could be tested surprisingly quickly. For me, it was once again a mix of “whoa,” “aha,” and a bit of “oh dear.”

Overall Claude Code works transparently and shows which files are being modified, including a GitHub-like diff view showing additions and deletions. Codex feels functional, but compared directly, the overall look and feel seemed slightly less polished to me than Claude Code. On the positive side, I really liked its suggestions about what meaningful next steps could be implemented. VS Code with the Copilot extension, despite the fiddly installation, delivered the best integration and usability for me, especially in combination with my own Ollama server.

Which Model Performed Best? Context Is King.
I prefer to use Ollama as my backend. Given my hardware setup, I am also able to test larger models locally. My first choice was qwen3-coder-next, a model recommended on the Ollama website. At first, the assistants behaved somewhat strangely with more complex requirements. After several tests, it became clear that my (default) chosen context window was too small. Normally, I work with a context window of around 4,096 or 8,192 tokens. However, when programming with Ollama, I achieved significantly better results with 64,000 or even 128,000 and more tokens of context. This obviously has consequences: higher VRAM usage, more load on the GPU or unified memory, and longer response times. Interestingly, VS Code with the Copilot extension felt more robust in this regard. I had to do less manual parameter tuning.

First Flappy Birds, Then WebGIS
I conducted my tests using German prompts. Why German? In my experience, if it works well in German, it will definitely work in English. After starting the classic way with “Create Flappy Birds as a browser game.”, I moved on to a more realistic use case from geoinformatics: a simple WebGIS. My prompts, unchanged, were:

1. “Please create a webpage with a map centered on Mainz.”
   (German: “Bitte erstelle ein Webseite mit einer Karte, die auf Mainz zentriert ist.”)
2. “Please add additional layers, for example using GeoJSON.”
   (German: “Bitte baue weitere Layer z.B. mit geojson ein”)
3. “Could you move the GeoJSON into a separate file that is then loaded?”
   (“German: Könntest du die Geosjon in eine separate Datei auslagern die dann geladen wird?”)
4. “Using Python, create a server for the GeoJSON files.”
   (German: “Erstelle mir mittels python einen server für die geojson files”)
5. “Do you know what an OGC Feature API is?”
   (German: “Weisst du was eine OGC FeatureAPI ist?”)
6. “Yes, please implement it as an additional API.”
   (German: “Ja, bitte als weitere API umsetzen.”)
7. “Could you also add another baselayer in the form of a WMS?”
   (German: “Könntest du noch ein weiteres Baselayer in form eines WMS hinzufügen?”)

What used to feel like an entire semester of teaching to build a Leaflet map with a server, layers, and OGC interfaces was now possible in a basic version with just a handful of prompts. That is somehow impressive and at the same time thought-provoking.

What Does This Mean for Me?
I am seriously considering trying this kind of setup with students in the next semester. But one central question remains in the back of my mind: how much foundational knowledge is necessary to use such powerful tools in a meaningful, reflective, and sustainable way? If you do not understand HTTP, APIs, projections, or data formats, if you cannot debug, if you cannot read code, then you become heavily dependent on these tools instead of being able to use them in a controlled way.
For me, one thing is clear: “vibe coding” has arrived. And it is not going away. The question is no longer whether I use it. The question is how wisely I integrate it into my teaching.

19/02/2026-25/02/2026

Mapping

• Simgaymer has asked for comments on a tagging proposal to extend the existing building:flats=* tag, allowing mappers to record the number of flats with 0 bedrooms (studio), 1 bedroom, 2 bedrooms, and so on. For example building:flats:0_bedrooms=* to record the number of studio flats.
• The proposal flashing_lights=* is still open for voting. The proposal intends to indicate the precise design of flashing lights.
• Voting on the indication:*=*, a tag prefix to designate any feature with the help of existing tagging (useful for utility markers, like hydrants), refinement proposal has closed successfully at 100% approval rate (20 votes for, 0 votes against, and 0 abstentions).

Mapping campaigns

• ^[1] Matt Whilden has launched a MapRoulette project focused on improving the mapping of VORTAC (VHF Omnidirectional Range / Tactical Air Navigation) beacons (beacon:type=VORTAC), a type of radio station used in aviation to help pilots determine both their direction from a station and their distance to it. According to Matt many of these installations in OpenStreetMap have been incorrectly mapped as buildings, storage tanks, towers, or other structures, rather than being tagged as aviation navigation aids. The circular shelters and antenna arrays that characterise VORTAC sites are frequently misidentified when viewed from aerial imagery.

Community

• Following a recent outage affecting the Overpass API service used by many OpenStreetMap tools, Daniel Schep and Jacob Hall announced the launch of the MapRVA Overpass server (https://overpass.maprva.org/api/), a dedicated Overpass instance focused on the state of Virginia in the United States. Alongside the server, they also introduced a customised deployment of Ultra. The customised version is configured to use the MapRVA Overpass server and the MapRVA styling server as its default infrastructure, providing an alternative resource for users working with Virginia-focused data during broader service disruptions.
• Michal Migurski has written about the representation of boundaries in dispute using open data and mapping with OpenStreetMap.
• Derlamaer highlighted the current OSM proposal traffic_signals:detector=pedestrian_presence_sensor, suggesting a tag for indicating pedestrian presence detectors at traffic signals. This tag aims to improve the precision of signal controller datasets and support more detailed traffic engineering analyses.
• FeetAndInches has written a diary entry on how they process dashcam video and GNSS data into a sequence of images for Panoramax.
• Kevin Ratzel has written an Ultra query to visualise the 1.0 Pedestrian Working Group Schema, a tagging schema for pedestrian infrastructure mapping in OpenStreetMap.
• Anne-Karoline Distel has published a video explaining how to map bonfire sites associated with the Eleventh Night.
• Valentin Bachem has identified and explained ► several potential safety risks in the current cycling path network of Heidelberg, calling on local authorities and the media to give greater attention to these issues and to pursue improvements aimed at reducing harm.
• SirfHaru wrote in their OSM user diary about some of the peculiarities of mapping addresses in India.

Events

• The call for participants at SotM 2026 is open. This year’s SotM will take place in Paris, France, 28 to 30 August. The Programme Committee is ready and waiting, eager to unwrap your submissions for talks, workshops, and panels. These sessions aren’t just part of the conference; they’re its beating heart, driving conversations and sparking ideas that resonate worldwide. Presenting your work, projects and ideas at SotM is also a great way to get in touch with the wider OSM community.

Maps

• Jochen Topf outlined several recent feature updates to OSM Spyglass, a debugging interface for OpenStreetMap that displays all tagged nodes, ways, and relations.

Open Data

• An update of the Portuguese coastline dataset, at a scale of 1:150,000, is now available ►, on the dados.gov portal, published by the Hydrographic Institute.
• The 2025 version of the Official Administrative Map of Portugal has been published ► on the website of the Directorate-General for Territory. There is also a viewer for online data, which uses OSM as its base map.
• Pinhead map symbols is a repository of public domain SVG icons designed to be displayed at 15×15 pixels (minimum). You can find the project on GitHub.

Software

• ni5arga has made Sightline, an OSINT search engine for physical infrastructure, built on OpenStreetMap data. The tool uses the Overpass API and Nominatim, supports both free-text and structured queries, such as type:data_center operator:google, and relies on deterministic rule-based parsing instead of AI inference.
• nickrsan has built Browsm, a browser extension that allows users to edit OpenStreetMap points of interest directly while viewing a business or attraction’s official website.

Releases

• Organic Maps has released its February 2026 update. Users can now contribute by adding real-time public transport schedule data through sending GTFS feed sources and ensuring that a city’s OSM data includes all the necessary tags, which can be verified using the gtfs-osm-matcher.

Other “geo” things

• FOSSGIS e.V. has launched a mailing list aimed at the wider community. The list is intended as a place to ask questions about QGIS, discuss software or plugin choices, and exchange practical experiences with other users. Subscribers will also receive updates from the association, including event notices, job postings, and other announcements. Registration is available here , and joining does not require association membership.
• The German tech outlet Golem.de reported that Google is further restricting the full functionality of Google Maps for users who are not signed in with a Google account. According to the report, the limitation has been confirmed to apply at least in the United States and Germany.
• The Atelier Parisien d’Urbanisme (Parisian Urbanism lab APUR) has published ► the first Atlas de la Métropole du Grand Paris. As part of this publication, APUR has chosen to present an analysis of the departure patterns of Parisians and residents of the Île-de-France region to metropolitan seaside areas, based on data from CitiProfile ►, a French startup specialising in the production of decision-making tools based on the flow of people and vehicles.
• The Zürich-based Mapillary team hosted an event on 26 February to celebrate reaching 3 billion uploaded images. The meetup offered insights into the engineering behind hosting this volume of imagery, the future roadmap, and how mapping communities are using Mapillary.
• You can read the incredible history of Inō Tadataka, who was 55 years old when he set out to methodically survey the entire coastline of Japan in 1800, a task he would spend the last 17 years of his life working on.
• QGIS 4.0 Release candidate has been launched, with some important improvements and, according to the developers, this major release will represent the successful culmination of a long period of technical migration, transitioning the core of QGIS to Qt6. According to the Road Map, the release date for version 4.0 is 6 March 2026.

Upcoming Events

Country	Where	Venue	What	When
	Seattle	Seattle, WA, US	OpenThePaths 2026: Connecting People and Places Through Sustainable Access	2026-02-26 – 2026-02-27
	Santa Clara	Santa Clara University	Friends of MSF Mapathon	2026-02-26
			UN Maps Validation Friday Chat & Map	2026-02-27
	Greater Noida	Online	Missing water Bodies of Delhi	2026-02-27
	Essen	Fahrrad-Messe Essen, Halle 5, Show-Truck	Vortrag: Mitmachen bei OpenStreetMap, der Basis vieler Outdoor-Apps	2026-02-27
	Potsdam	Hafthorn	Potsdamer Mappertreffen	2026-02-27
	Ferrara	Cimitero monumentale della Certosa di Ferrara	Ferrara mapping party	2026-02-28
	Messina	Messina	Mapping Day @ Messina	2026-02-28
		Dijital Bilgi Derneği Genel Merkezi	OpenStreetMap Community Meet-Up & Mapathon	2026-02-28
	नई दिल्ली	Jitsi Meet (online)	OSM India – Monthly Online Mapathon	2026-03-01
	Madurai	Naveen Coffee Bar, Anna Nagar (tentative)	OSM Mapping Party @ Madurai	2026-03-01
	Milano	Building 4A, Room Fassò – Politecnico di Milano	PoliMappers Maptedì	2026-03-03
	Salzburg	Bewohnerservice Elisabeth-Vorstadt	OSM-Treffpunkt	2026-03-03
	Lille	Salle Yser, MRES, 5 rue Jules de Vicq, Lille	Rencontre OpenStreetMap à Lille	2026-03-03
			Missing Maps London: (Online) Mapathon [eng]	2026-03-03
			iD Community Chat	2026-03-04
			OSM Indoor Meetup	2026-03-04
	Brno		Kvartální OSM pivo	2026-03-04
			Harzer OSM-Stammtisch	2026-03-04
	Stuttgart	Stuttgart	Stuttgarter OpenStreetMap-Treffen	2026-03-04
		Online	OpenHistoricalMap in North America	2026-03-04
			OSM US Mappy Hour: OpenHistoricalMap in North America	2026-03-04
	Flensburg	Offener Kanal Flensburg	3. Open Data Day Flensburg	2026-03-05
	Žilina	Fakulta riadenia a informatiky UNIZA	Missing Maps mapathon Žilina #21	2026-03-05
		Le Schmilblick, Montrouge	Réunion des contributeurs de Montrouge et du Sud de Paris	2026-03-05
	София	Rectorate of Sofia University St. Kliment of Ohrid	FOSS4G:BG Open GIS Conference 2026	2026-03-06 – 2026-03-07
			OSMF Engineering Working Group meeting	2026-03-06
	Gent	Wijgaard	OpenStreetMap meetup in Gent – Pre-VLA-congres editie	2026-03-06
		Hogeschool Odissee Hospitaalstraat 23 Sint-Niklaas	Vereniging Leraars Aardrijkskunde (VLA) conference 2026	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-08
	Delhi		OSM Delhi Mapping Party No.27 (East Zone)	2026-03-08
	København	Cafe Bevar’s	OSMmapperCPH	2026-03-08
	London	Social Sciences Centre – Western University	Friends of MSF UWO Mapathon	2026-03-09
	Brno	Geografický ústav, PřF MUNI, Brno	Březnový brněnský Missing Maps Mapathon na Geografickém ústavu	2026-03-09
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-03-09
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #86	2026-03-09
	Hamburg	Voraussichtlich: “Variable”, Karolinenstraße 23	Hamburger Mappertreffen	2026-03-10
	Cork	Logitech, Cork, Ireland	Logitech Missing Maps – Office Mapathon	2026-03-11
	Reston	George Mason University, HUB VIP 3	The GAIN Mapathon	2026-03-11
	Zürich	Bitwäscherei Zürich	185. OSM-Stammtisch Zürich	2026-03-11
	München	WikiMUC	Münchner OSM-Treffen	2026-03-12
	Leuven	Romaanse Poort	Camera’s in kaart brengen	2026-03-14

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 MarcoR, MatthiasMatthias, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, izen57, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

 

It's been a bit of a gap since my last ride because I've been busy decorating. In the process of clearing the room I discovered a leaflet of cycle routes around Wooler. That sent a pretty clear signal of where I should head for my next ride. So today I headed for Wooler.

The point of a folding bike was that I could stick it in the boot of the car, or take it on public transport to places that weren't hilly. So I'm getting used to easy flat rides. Wooler isn't like that. Some of the routes suggested in this leaflet are described as "strenuous". But I picked one that was described as "moderate". I expected something a bit more demanding than what I'm used to. What I didn't anticipate were the hailstorms.

I was mostly riding on quiet country lanes. There were more dog-walkers than traffic. Most of them said "hello" or "good afternoon". Which was nice. One said "What a lovely afternoon". She wasn't being ironic. I wonder what weather they've been experiencing recently around Wooler.

In summary: Several nice bridges, including Weetwood (thought to have been built in the 16th century, with alterations in 1775) and Fowberry (pictured). More gradients than I'm used to. Interesting weather. In the end I cut it short and only covered 10 miles of a longer route. Still, it was a good ride.

Manchmal sind es die kleinen Details. Dank 360° Mapillary Bildern konnte ich an der Stelle die Gegend etwas “aufhübschen”. Auch wenn man natürlich nicht für den Renderer mappen soll. Aber ein paar Dinge sind doch nützlicherweise hinzugekommen.

Leider wollte imgur meine animierte webp-Datei nicht annehmen. :shrug:

谁有中国地区电网数据

In this next edition of our OpenStreetMap interview series we speak with DW Innovation about SPOT, their tool for searching geospatial patterns in OpenStreetMap. They share how the project began, the challenges behind building it, and what they have learned since its launch.

1. Who are you and what do you do? What got you into OpenStreetMap?

We are DW Research & Cooperation projects. We research and experiment with new technologies in national and international innovation projects to get a clear picture of how journalism can benefit from those technologies.

In our research domain ‘verification’ we acknowledged that a very time-consuming process is the location verification of digital media. OpenStreetMap is a very interesting source of geolocation data as it contains non-commercial data that is relevant for geolocating digital media.

2. What is SPOT? What prompted you to create it? Why do we need a tool like this?

Imagine that you have to verify the location of a picture on which you can see a fountain and a church and a tower block within 60 metres of each other in the City of London. Google Maps won’t be able to help you searching for multiple entities at once, but in OSM you can actually search for geospatial information patterns.

The tool that we previously used for that is Overpass Turbo, however, it was rather complex to use for a lot of journalists. We decided to make searching in OSM easier and build a tool that can translate natural language prompts to search queries for geospatial patterns. The user won’t need to understand OSM tags and descriptors and can just prompt the system in their natural language, for example: ‘find a fountain and a church and a tower block within 60 metres of each other in the City of London’. The result will look like this:

3. What are the unique challenges involved in creating SPOT?

As we started in a world that was just being introduced to LLMs and training them for specific purposes it was quite complex to find the right open source model that would provide us with robust translation of natural language prompts to OSM search queries. We have developed a fine-grained automated benchmarking system that allows us to compare LLM models and measure the impact of fine-tuning.

Another challenge is the tagging system of OSM. We have developed our own descriptor-tag bundle index to try and make sure that we cover any way of searching for e.g. a public bin. We have also clustered visually similar entities, for example all kinds of train rails, due to our geolocation verification use case.

4. SPOT was launched at the end of 2024 launch announcement - what has the response been and what have you learned since then?

SPOT was received very well. The response from the journalistic and OSINT communities is very positive. We started with a Beta version that was not yet very stable. The early users saw the potential, looked through some bugs and provided us with very valuable feedback that allowed us to improve the application. Some, at first sight, minor issues led to insight that created structural changes in the system. Today, we have a well working, stable version that we can build on.

We are still learning that it is not easy to run well engaged open source projects. Building something, making it available for free and asking for input from like-minded is not necessarily the recipe for success. Also free products need to be marketed, also open source projects need to be well-managed and need Product Managers and Product Owners to thrive. We would be very happy to get more engagement from the OSM community, so if you can share the secret for that with us, we’d be much obliged!

5. Recently OpenStreetMap celebrated 20 years. Where do you think the project will be in another 20 years?

Phew, I was never so good at looking into the future. I guess we’ll see the urge and necessity to work on digital sovereignty in the near future. Implementation of that will take a bit. OSM can serve as a great example of how a society can build and own data and applications. OSM could possibly also use this momentum to make a leap and lead the way as a platform independent from state or big tech.

And of course, we would love OSM to be easily searchable for geospatial information patterns by everyone ;)

---

A big thank you to the team at DW Innovation for sharing their insights on SPOT and their work at the intersection of journalism, verification, and open geodata. We’re excited to see how SPOT and the wider OSM community continue to grow and collaborate in the years ahead.

Forward!

Ed and the OpenCage team

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

Como corrigir o nome de uma rua na aplicação CNEFE

Corrigir um nome de rua usando a aplicação CNEFE – Logradouro é um processo simples e direto, integrando os dados oficiais do Instituto Brasileiro de Geografia e Estatística com o mapa colaborativo do OpenStreetMap.

Veja o passo a passo:

1️⃣ Escolha a área no mapa Acesse a aplicação e navegue pelo mapa até a cidade ou bairro desejado. Você pode usar o zoom e arrastar o mapa para localizar a região onde deseja verificar os nomes das ruas.

2️⃣ Use o filtro “Rua” No painel de filtros, selecione a opção Rua. Isso fará com que a aplicação mostre apenas os logradouros classificados como ruas, facilitando a identificação de divergências entre o CNEFE e o OSM.

3️⃣ Escolha o editor A aplicação permite abrir a edição diretamente em um editor do OSM. Você pode escolher, por exemplo:

Editor iD (no navegador) JOSM (editor avançado para desktop)

Selecione o editor com o qual você já trabalha.

4️⃣ Selecione a rua a ser corrigida No mapa, clique sobre a rua que apresenta nome incorreto ou divergente. Compare o nome exibido no OSM com o nome oficial disponível na base do CNEFE.

5️⃣ Faça a correção No editor escolhido:

Selecione o trecho da rua No campo name, apague o nome incorreto Cole o nome oficial correto conforme indicado no CNEFE Verifique se não há abreviações indevidas ou erros de grafia

Exemplo: Se no OSM estiver “R. C. J. Silva” e no CNEFE constar “Rua Coronel João Silva”, atualize para o nome completo correto (seguindo as boas práticas da comunidade).

6️⃣ Envie a atualização Após revisar a edição: Salve as alterações

Escreva um comentário claro no conjunto de alterações (ex: “Correção de nome de rua conforme CNEFE 2022”)

Envie para o OpenStreetMap Pronto. O nome será atualizado no mapa colaborativo.

✅ Boas práticas Sempre confira se a rua selecionada corresponde exatamente ao logradouro do CNEFE.

Evite alterar nomes se houver sinalização local divergente — nesses casos, vale validar em campo. Mantenha o padrão adotado pela comunidade do OpenStreetMap no Brasil.

Assim, cada correção contribui para um mapa mais preciso, padronizado e útil para todos.

Correção de Nomes de Ruas no Openstreetmap. Aplicação CNEFE/CENSO2022.

https://cnefe.mapaslivre.com.br/logradouro/#map=5/-8.75479/-48.66943

‘De Wasvrouwen’ is een beeld van Carla Rump in Groet, Noord-Holland.
Link naar de locatie met tags op OSM.
Het beeld is een creatie van Carla Rump.

多言語表記のタグ付けを考える(パート2: 編集合戦編)

2026-02-01に’さくらインターネット Blooming Camp’で行われた「マッパーズサミット2026」での発表内容の「編集合戦編」です

パート１: OSMの基礎知識編

この記事は「基礎知識編」の続編です

必ず「基礎知識編」を見てから「編集合戦編」へ進んでください

• パート１: OSMの基礎知識編

パート2: 編集合戦編

ここからは、OSM編集で実際に起きた「編集合戦」について説明します。

パート１を見ていない方は、パート１: OSMの基礎知識編 を先に見ください

事件は「渋谷スクランブル交差点」で起きました
- ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #6” 2025-07-30

この交差点は英語圏では “Shibuya scramble crossing”として世界的に認知されており、インバウンド観光客の目的地ともなっています
- 渋谷スクランブル交差点

訪日客が”Shibuya scramble crossing”を目的地にした場合、数多ある渋谷周辺の’交差点’の中からどうやって”Shibuya scramble crossing” だと確信することができるでしょうか？
交差点にある「案内標識」の「国際表記名=Sybuya Sta.」がOSMに入力されていれば,日本語を解さない人でも「Sybuya Sta.」と表記された場所が「Shibuya scramble crossing」だと確信することができます

• ここでは、OSMwikiの「一般的な名称以外は、派生名に入れてください」に従い、国際表記部分を int_name=Sybuya Sta. と入力します
  • 「一般的な名称以外は、派生名に入れてください」@osmwiki:名称キー

引き続き「ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #6“」のマッピングを見てみます

「name = 渋谷駅前交差点」となっています

• 実際の表記は「渋谷駅前」なので、現物のとおり name=渋谷駅前 とし、交差点を削除します
  • 「存在しないものには名称をタグ付けしないでください」@osmwiki:多国語の名称
  • 「名前に説明を組み合わせて名称を作らないでください」@wiki/JA:名称#名称で説明しない
• OSMwikiに「現地語名称は言語明示サブキーと重複させてください 」とありますが、
  name=渋谷駅前としたことにより、name:ja と一致しなくなりましたが、下記の理由により、name:jaは変更せずにこのままとしました
  • すでにwikidataタグが付けられており、name:XXがロック状態になっているため
  • name:XXのソースが不明。ひょっとすると現地のどこかに表記があるかもしれないため

int_nameをマッピングしたところ、２～３日後に int_name が消されました。
- 「ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #7“」

• int_name= を消すことは OSMwikiの記述に違反することになります
  • 「他の名前はすべて、派生名に入れてください」@osmwiki:名称#名称キー

また、name:enが name:en=Shibuya Sta.に変更されてしまいました

• name:en=Shibuya Sta. に変更することは、OSMwikiに違反することになります
  • 「現地語名称は言語明示サブキーと重複させてください 」@wiki/JA:多国語の名称#言語明示タグによる複数回の名前付け
  • 「略称は使用しないでください」@wiki/JA:名称#略称
  • 「省略しない」@wiki/JA:名称#略称
  • 「一般的な名称以外は、派生名に入れてください」@osmwiki:名称キー

ちなみに、すでにwikidataタグが付けられており、name:enはロック状態になっていいます。

wikidataタグがあるにもかかわらず’name:en’を改変しても意味はありませんし、OSMデータベースに不要なごみデータを蓄積されるだけです。（データベースの保守は無料ではありません）

無意味な編集合戦はやめましょう。

OK. Last year I wrote a short guide on mapping Indian addresses but I lost it in my tiny pursuit to delete myself. Today I suddenly came across the fact that the guide was actually used by mappers and, hence, as a result I am now writing this post to become a replacement for that old guide. Since this is a new one, I don’t want to just rehash the old stuff and instead this time I am going to take a simple problem and show how I would solve it from scratch.

A1, Tower 2, Sector 11, RK Puram, South West District, Delhi, India

A problem very similar to this one came up in OSM India’s XMPP channel today. So, how does one go about mapping this address?

As it’s usually the case we can ignore the district, state, and country part as they are all very well mapped in India. This leaves us with everything upto RK Puram.

If you are thinking that something as big as RK Puram should surely be already on the map then you are wrong; In my “career” I have actually seen larger areas without any nodes for them. So we will in fact check if it’s already on the map and, guess what, it actually is already mapped as a suburb, so that’s one less step for us! I should mention that in OSM there are three “neighbourhood” levels below the district: quarter, suburb, and neighbourhood in decreasing order of size. In most cases suburb and neighbourhood should be enough for you, but it is important to be aware of quarter for special situations.

Now let’s check for Sector 11. As of writing this, Sector 11 isn’t on the map. So I will put a neighbourhood node at the approximate centre of Sector 11. (Remember that neighbourhood is smaller than suburb.) We are making good progress.

Now let’s take care of Tower 2. It’s actually specifying a particular building, unlike the previous steps which were about specifying the area in which the building lies. In this case it should be “Tower 2” for housename and “Sector 11” for place. It’s important to specify the place because it could be the case that “Sector 45” node is actually closer to the building.

A small interjection: when mapping a building try to choose between housename and housenumber or place and street logically. If your address is “36, Shivaji Marg” then please please use 36 for housenumber and Shivaji Marg for street. If you do it incorrectly then there’s a 90% of divine punishment from OSM gods.

OK. The building is done. Now all you have to do is to add A1 to the unit tag as a separate node inside the building. Note that the A in this case does not refer to a block and so it should not be separated from the 1. Another important point is that even though A1 is referred to as housenumber in common language, in OSM it isn’t actually a housenumber since housenumber/housename are reserved for building. A1 is just a unit number which means that it is a part of the building. (In case you haven’t realized it yet, the given address was for an apartment.)

I forgot to mention but blocks are somewhat of a controversial topic. My method is usually to retain the blocks in housenumber if they are simple (such as the 1 in “1/265”) or move them into “place” if they are more complicated (like the Pocket E in “36, Pocket E”).

OK. Let’s see if you were reading carefully. Tell me how you would map

1/26/65EB, Gali Shanti, Near Phoole Wala Mandir, Chandni Chowk, Old Delhi

Were you able to do it? Here’s my answer:

Old Delhi is probably already mapped, Chandni Chowk would be a neighbourhood, I would ignore Phoole Wala Mandir, I would add Gali Shanti to the name of highway, then finally for the building I would add 1/26/65E as housenumber and Gali Shanti as street. Did you notice that I never actually told you that letters like E are allowed in housenumber? By that I wanted to show that this guide probably does not contain comments for each and every case, but it should work for the majority of cases. If you come across a difficult problem, then your best bet is always OSM Wiki. Just look it up!

This post was first released on my website with 💜 under CC BY-NC-SA 4.0.

本系列编辑主要修复了部分住宅楼的过大幅度偏移，以及一些误标记的绿化。问题区域主要在星塘街以东，为方便起见，以东西向道路作阶段性的分割。

记录

2026/2/24已完成修复兆佳巷以北

2026/2/25已完成修复中新大道东以北

2026/2/26已完成修复港田路以北

Introduction: What is the Model Context Protocol (MCP)?

To make it easier for AI assistants to communicate with databases and various external systems, the Model Context Protocol (MCP) was created – a kind of API for AI that describes how to use a given service.

MCP works a bit like Swagger / OpenAPI for developers: it precisely specifies which “tools” are available, what parameters they accept, and what responses they return, so that an AI assistant knows how to query a given server correctly. The difference is that MCP is designed exclusively for AI, not for humans – it does not provide a traditional user interface, only a contract that a language model can use.

This post is therefore mainly aimed at developers of AI applications and assistants: it describes a new tool they can integrate into their projects to work more effectively with OpenStreetMap tagging data.

---

A few months ago, I worked on a new project: the OSM Tagging Schema MCP — a Model Context Protocol (MCP) server built for AI assistants and LLM applications that interact with OpenStreetMap tagging data.

It serves as a bridge between AI systems and the official OpenStreetMap tagging schema, allowing agents to validate tags, query values, search presets, and suggest improvements using the structured knowledge from the @openstreetmap/id-tagging-schema library.

The current 3.x release is technically stable — all tools and endpoints work reliably without errors — but it should still be considered experimental. Active development on version 3 has ended; for now, I only maintain it through dependency updates.

The next major step will be version 4, a complete rewrite developed with AI-assisted coding, focusing on a cleaner architecture, long-term maintainability, and deeper MCP integration.

You can try the service live here: mcp.gander.tools/osm-tagging

I invite you to experiment, test, and share feedback — your ideas and suggestions are always appreciated: gander-tools/osm-tagging-schema-mcp discussions