OpenStreetMap Blogs Last Update:

Drohnen sind aktuell in aller Munde. Leider allerdings eher im Kontext weltweiter Konflikte und geopolitischer Spannungen. Auch wenn ihr Ursprung in der militärischen Entwicklung liegt, werden sie heute vielseitig eingesetzt: zur Freizeitgestaltung, in der Vermessung sowie bei Hilfsaktionen. Genau hier möchte ich anknüpfen. Durch die Hochschule Mainz habe ich Zugriff auf unterschiedliche Drohnensysteme. Von Fluggeräten für YouTube-Influencer über Selbstbaudrohnen bis hin zu Enterprise-Modellen mit einer Wärmebildkamera. Gerade bei Letzterem stellt sich schnell die Frage: Wie kann diese Technologie greifbar gemacht werden? Die Idee war schnell geboren: Warum nicht genau das mit der Kinderfeuerwehr einmal ausprobieren? Eine kleine Übung, die Technik, Teamarbeit und das Ganze kombiniert in einem Abenteuer!

Meine Planung
Gesagt, getan: Die Begeisterung konnte ich bei den Betreuern der Kinderfeuerwehr schnell wecken. Ein Termin war gefunden und ich begann mir Gedanken zu machen, wie ich das Ganze umsetzen könnte. Der Plan: eine fiktive Vermisstensuche unter Einsatz einer Thermaldrohne. Was ist eine Thermaldrohne? Eine Thermaldrohne ist mit einer speziellen Kamera ausgestattet, die Wärme sichtbar machen kann. So können Menschen oder Tiere gefunden werden, die sich in Not befinden oder Hilfe benötigen, insbesondere wenn es dunkel ist oder sie sich verstecken. Daneben war ich neugierig: Wie gehen Kinder im Alter von 5 bis 9 Jahren eigentlich mit einer Karte, einer Drohne und deren Steuerung um?

♦Eine Karte für die Planung und Suche der vermissten Personen (© OpenStreetMap Contributors)

Vorstellung und Fragerunde
An einem sonnigen Samstag im März war es dann soweit: 18 Kinder, drei Betreuer und ein paar Zuschauer. Eines war für mich schon im Vorfeld klar: Sobald die Kinder die Drohne sehen, kommt die Frage: „Dürfen wir auch fliegen?“ Meine Antwort: „Lasst uns das gerne auf später verschieben.“ Für mich war es das erste Mal mit Zuhörerinnen und Zuhörern in diesem Alter eine Übung durchzuführen und ich muss sagen: Es war richtig gut. Die Begeisterung war von Anfang an spürbar, und es wurden Fragen gestellt und Dinge von den Kindern gesagt, mit denen ich so nicht gerechnet hätte: „Darf ich dort mit der Drohne fliegen, wenn der Eigentümer es nicht will?“, „Mein Papa hat auch eine Drohne von Temu für 21 Euro.“ „… und deine Drohne kostet ja so viel wie 20 Nintendo Switch 2!“

Vermisstensuche
Dann wurde es ernst, zumindest im Rahmen unserer Übung: Die Vermisstensuche konnte beginnen. Dafür hatten wir im Vorfeld ein Wald- und Wiesengebiet ausgewählt, in dem sich fünf Personen versteckt hatten. Die Aufgabe für die Kinder: Gemeinsam mit der Drohne das Gebiet absuchen und alle „Vermissten“ finden. Und so viel vorweg: Am Ende wurden alle gefunden ♦

♦Linkes Bild: Normales Bild der Drohne aus der Luft. Die zu suchende Person ist durch den Wald größtenteils verdeckt. Rechtes Bild: Thermalbild der Drohne aus der Luft. Die Person ist aufgrund der Körperwärme durchaus gut erkennbar.

Für mich waren beim Einsatz der Thermaldrohne besonders folgende Punkte interessant: Personen mit Rettungsdecken zu finden, ist durchaus herausfordernd. Die Größe und Topografie des Geländes stellen Geduld und Überblick auf die Probe. Nicht nur beim Pilot sondern auch bei den Kindern. Fünf Kinder gleichzeitig an oder eher über der Fernbedienung erfordern gute Koordination … bei allen Beteiligten. Was ich etwas unterschätzt habe: Wir hatten einen herrlichen Frühlingstag mit etwa 10 Grad und Sonnenschein. Für die Suche nach vermissten Personen ist das allerdings nicht optimal, da sich die Umgebung stärker aufheizt und die Temperaturunterschiede im sichtbaren geringer werden.

Fazit
Für mich bleibt vor allem die Erkenntnis, Kinder können schnell ein Gefühl für Technik entwickeln – und es entsteht viel Begeisterung, wenn man ihnen die Möglichkeit gibt, Dinge selbst auszuprobieren. Lieber Torben, lieber Christoph von der Freiwilligen Feuerwehr Hünstetten-Wallbach, vielen Dank für die Möglichkeit, den Nachwuchsfeuerwehrdamen und -herren den Einsatz einer Drohne bei der Vermisstensuche praktisch zu demonstrieren. Und zu guter Letzt: Vielen Dank an all die interessierten Kinder. Es war mir eine große Freude! Dass am Ende jedes Kind noch selbst (natürlich unter Aufsicht) eine kleine Drohne fliegen durfte, hat diesen Tag wohl sehr gut abgerundet.

18 hours ago

此文本同時提供 台灣華語版本 This article is also available in Taiwanese Mandarin

OpenStreetMap’s collaborative nature is both its biggest strength and a source of persistent data-quality issues. With thousands of contributors independently adding phone tags to shops, restaurants, clinics, and government offices, each person tends to follow their own formatting style. For Taiwan, that means a database where the same country code can show up as +886, +886+, or +886(2), and a single city’s worth of phone numbers might span a dozen different conventions.

This post catalogues what we found when we scanned OSM elements across all six special municipalities and five additional counties — we are working on a normalizer to fix the issue.

The Scale of the Problem

Across eleven cached regions — all six special municipalities (臺北市, 新北市, 桃園市, 臺中市, 臺南市, 高雄市) plus 苗栗縣, 新竹市, 臺東縣, 連江縣, 金門縣 — we found 49,260 tags (phone or contact:phone) on 49,229 elements. After splitting multi-value fields on semicolons, that yields 50,643 individual phone number strings to classify.

Format class Count Share E.123 space (+886 2 1234 5678) 41,842 82.6% RFC 3966 dash (+886-2-1234-5678) 6,655 13.1% No separator (+886212345678) 1,158 2.3% Local format, no country code (02-1234-5678) 854 1.7% Corrupt/typo country code (+866 …, +886(2)…) 92 0.2% Other (wrong country, junk) 42 0.1%

Roughly 1 in 5 individual values deviates from the most common contributor convention, creating inconsistency that complicates deduplication, display, and machine parsing.

♦ Things went from bad to downright ridiculous.

The format split varies noticeably by region:

Region Region (ZH) Tags Values E.123 RFC 3966 Other TPE 臺北市 ★ 9,804 10,146 85% 11% 4% NWT 新北市 ★ 13,963 14,395 85% 11% 4% TAO 桃園市 ★ 4,177 4,277 83% 12% 5% TXG 臺中市 ★ 8,065 8,282 73% 24% 4% TNN 臺南市 ★ 4,246 4,322 84% 11% 6% KNN 高雄市 ★ 5,168 5,262 84% 10% 5% MIA 苗栗縣 1,318 1,338 77% 18% 5% HSZ 新竹市 1,088 1,094 82% 12% 6% TTT 臺東縣 1,101 1,178 96% 3% 1% LIE 連江縣 95 103 98% 0% 2% KMN 金門縣 235 246 90% 8% 2%

★ Special municipality. Taichung stands out with 24% RFC 3966 usage — roughly double the rate of any other major city — suggesting a dominant local editing pattern or tool default in that contributor community. The outlier island counties (連江縣, 臺東縣) have the highest E.123 consistency, possibly because their smaller contributor pools converge on informal norms more easily.

What “Correct” Means: Format Standards in OSM

Before diving into the issues, it’s worth clarifying what “correct” actually means in an OSM context.

The OSM wiki’s Key:phone page does not mandate a single format. It documents E.123 international notation, RFC 3966 (tel: URI dash notation), and NANP-style formatting without expressing a clear preference between them. In practice, E.123 space notation is the most commonly used by Taiwan contributors — which is why we use it as the normalisation target — but RFC 3966 dash notation is a legitimate alternative that the wiki explicitly acknowledges.

So the goal of normalization isn’t strict compliance with any one standard — it’s internal consistency: a dataset where everything follows the same convention is just much easier to work with than one that mixes three formats at random.

What Consistent Looks Like

For Taiwan, the most common contributor convention is E.123, followed by RFC 3966 / NANP (North American +1-style, RFC 3966-like):

ITU E.123
----------------------------------------
+886 2 1234 5678    ← Taipei landline
+886 4 1234 5678    ← Taichung landline
+886 37 123 456     ← Miaoli landline (3-digit area code)
+886 89 123 456     ← Taitung landline (3-digit area code)
+886 9X XXXX XXXX   ← Mobile
+886 800 XXX XXX    ← Toll-free (0800)

NANP
----------------------------------------
+886-2-1234-5678    ← Taipei landline
+886-4-1234-5678    ← Taichung landline
+886-37-123-456     ← Miaoli landline (3-digit area code)
+886-89-123-456     ← Taitung landline (3-digit area code)
+886-9X-XXXX-XXXX   ← Mobile
+886-800-XXX-XXX    ← Toll-free (0800)

Multiple numbers separated by semicolons, no trailing semicolon:

ITU E.123
----------------------------------------
+886 2 8787 8787;+886 2 8787 8765

(or)

NANP
----------------------------------------
+886-2-8787-8787;+886-2-8787-8765

Both are acceptable normalised formats. The open question for the community is agreeing on one and applying it consistently to resolve the current mixing.

♦

Not your average daily struggle

Our findings Issue 1: Inconsistent Separators

The most common deviation is mixing hyphens and spaces. Both of these encode the same number:

+886 2 2181 2345     ← E.123 (space, most common in TW OSM data)
+886-2-2181-2345     ← RFC 3966 dash (legitimate, less common)

The real problem is mixing both within a single value, which belongs to neither convention:

+886 2 2873-6548     ← space after country code, dashes within
+886-2-28358739      ← dashes, then no grouping in subscriber number

We found 1,554 values that contain both spaces and hyphens in a single phone string — the worst of both worlds, unambiguously wrong under either standard.

Issue 2: Missing Country Code

Some contributors enter phone numbers the way they would dial them locally — without the +886 prefix:

02-2581-7780
02 8751 3227
0222346763
0921067050

OSM’s phone tag is meant to hold an internationally dialable number. A value like 02-2581-7780 is ambiguous outside Taiwan: consumers have no way to know which country’s area-code conventions apply. We found 854 such values, including mobile numbers entered as bare 09XXXXXXXX strings.

Issue 3: No Separator After Country Code

A related variant omits any separator between the country code and the rest of the number:

+886288613257
+886228839850

These are syntactically valid in E.164 (the all-digits form used by telephony APIs) but fail most display validators and are unreadable as stored OSM data. We found 1,158 such values.

Issue 4: Corrupt or Malformed Country Codes

A small but non-trivial number of entries contain clear input errors:

+866 2 29126883      ← digits transposed (866 instead of 886)
+886+2 2311 2940     ← extra plus sign
+886(2)28232410      ← parenthesised area code (North American style)
+886.2 2322 3477     ← dot as separator
+8886 2 8780 6278    ← extra digit in country code
+00886-2-23825234    ← international dialling prefix 00 prepended

We found 92 such values. These will silently fail in any phone-number parsing library that enforces ITU-T E.164 syntax.

Issue 5: Duplicate Entries in Multi-Value Fields

OSM supports multiple phone numbers for one element using semicolons. We found 1,320 multi-value tags across the dataset. Of those, 24 contain duplicate entries — the same number appearing more than once:

+886 2 2916 0300;+886 2 2916 0300
+886 89 862 326;+886 89 862 326;+886 89 862 326

This suggests copy-paste mistakes during editing. While harmless individually, they can inflate the number of contact options and potentially confusing to machines.

Issue 6: Extension Numbers — a Format Wild West

♦ You are the one accountable, Raiden!! (via @M4HCHE3ZY on X (formerly Twitter))

Beyond the main number itself, 635+ values encode an extension, using at least five different conventions found in the data:

Convention Example Count Hash # +886 2 2536 3001#8653 572 Tilde ~ +886 2 2368 0031~2 26 ext. / ext +886 2 2741 5991 ext.21 30 Chinese 分機 +886 4 2528 5394分機6000 7 Comma , (iOS) +886 2 2938 2300,630 ~1+ Detecting extensions is tractable

As community members pointed out, a simple rule works: any character that is not a digit, space, or hyphen ([^\s\d-]) can be treated as the start of the extension suffix. This is essentially what our normalizer does — split at the first such character, normalize the base number, then reattach the suffix verbatim.

Encoding extensions is where it breaks down

The OSM wiki’s Key:phone#Extensions page currently documents three different conventions without picking one, which is itself a signal of how unresolved this is.

E.123 specifies ext as the separator. It was standardised in the printed-directory era — ext 8653 is readable on a business card, but apps do not reliably parse it. There is no DTMF interpretation; the extension string is purely informational.

Apple iOS (and macOS Contacts) stores extensions using a comma , as a pause-and-dial separator: +886-2-2938-2300,630. The comma signals the dialler to wait for the call to connect, then send the remaining digits as DTMF tones — so 630 is dialled automatically after the main number picks up. This is practical on-device behaviour, but it creates two distinct problems in OSM data:

1. Ambiguity with multi-value separators. OSM uses ; to separate multiple phone numbers in a single tag. Comma has no such defined role in OSM, so an iOS-style value like +886 2 2938 2300,630 is likely to be misread as a single malformed number rather than a number-plus-extension. We found 16 values with commas in the dataset; most are multi-value numbers incorrectly separated by , instead of ;, but at least one appears to be a genuine iOS-exported extension.
2. Non-portability. A comma-encoded extension is only meaningful to a DTMF-capable dialler. It conveys no human-readable information and is invisible to any parser that does not understand the pause-dial convention.

libphonenumber detects extensions across many separators (#, ext, x, ,, etc.) but emits no canonical output format for the extension part, leaving it to the caller.

RFC 3966 (tel: URI) is the most formally specified option — it uses ;ext=NNN. But RFC 3966 extensions create a structural conflict with OSM’s data model that is worth spelling out in full.

The RFC 3966 semicolon conflict

OSM uses the semicolon ; as the multi-value separator for phone tags:

+886 2 1234 5678;+886 2 8765 4321    ← two phone numbers, standard OSM

RFC 3966’s extension syntax also uses a semicolon as a parameter delimiter:

tel:+886-2-1234-5678;ext=8653        ← RFC 3966 with extension

If a contributor stores this in an OSM tag, any OSM editor or data consumer that naively splits on ; will interpret it as two values: tel:+886-2-1234-5678 and ext=8653. The extension becomes a phantom second phone number — one that is not a phone number at all.

The obvious workaround is to escape the semicolon as \;, a convention some OSM tags use for literal semicolons inside values. But this creates its own problems:

• OSM editors do not consistently honour \; escaping; many will still split on it or display it literally.
• RFC 3966 parsers expect a raw ; as the parameter delimiter — a backslash-escaped \;ext=8653 is not valid RFC 3966 and will not be parsed correctly by any compliant tel: URI parser.
• Machine readability is not improved: a consumer now needs to know both OSM’s backslash-escaping convention and RFC 3966’s parameter syntax, and reconcile the two. It adds encoding complexity without giving any parser a clean path to the extension digits.

The backslash escape is a leaky workaround that satisfies neither standard fully. It is, in effect, a third encoding layered on top of two already-conflicting ones.

The result is that RFC 3966 extension notation is structurally incompatible with OSM’s semicolon-as-multi-value convention, with no clean resolution available today. For this reason, our normalizer preserves extension suffixes as-is rather than attempting to rewrite them into any standard form.

A Note on E.123 and Machine Readability

Here’s something worth keeping in mind: even a perfectly normalised E.123 phone tag isn’t as machine-friendly as it looks.

E.123 was standardised by the ITU-T in 1988 — when the primary medium for a phone number was a business card, letterhead, or printed directory. The spaces in +886 2 1234 5678 are visual grouping aids for human readers, not semantic tokens. A parser encountering that string has to strip the spaces, infer the country code, and figure out the area code boundary — all heuristically.

RFC 3966’s tel:+886-2-1234-5678 is marginally more structured (hyphens as explicit separators, a URI scheme that signals “this is a phone number”), but still requires a real parser to interpret the digit groups. The truly machine-readable form is E.164 — +886212345678, all digits, no punctuation — which is what telephony APIs and databases actually want. None of these is what OSM stores by default.

This tension is fundamental: OSM’s phone tag is human-oriented. Normalization to E.123 is about making data consistent and editable by contributors, not about producing a format that apps can blindly ingest without parsing. The downstream app still needs a library like libphonenumber to do the real work — which is exactly why that library’s correctness for Taiwan’s edge-case area codes matters as much as it does.

A Note on Unexpected Area Code Grouping by google/libphonenumber

This one is subtle. Google’s libphonenumber — the standard library used by virtually every phone-number parser — groups some Taiwanese area codes differently than how they appear in local usage.

Taiwan’s NCC assigns 3-digit and 4-digit area codes to several regions. libphonenumber’s metadata appears to represent these as extensions of their 2-digit neighbours, producing a different grouping than what locals would recognise:

Dialled libphonenumber output Expected output (E.123) 037-123-456 +886 3 7123 456 +886 37 123 456 049-123-4567 +886 4 9123 4567 +886 49 123 4567 082-123-456 +886 8 2123 456 +886 82 123 456 0826-12345 +886 8 26123 45 +886 826 12345 0836-12345 +886 8 36123 45 +886 836 12345 089-123-456 +886 8 9123 456 +886 89 123 456

Affected regions: Miaoli (037), Nantou (049), Kinmen (082), Wuqiu (0826), Matsu/Lienchiang (0836), and Taitung (089).

This means that even phone numbers already stored in +886 X XXXX XXXX form may carry a different digit grouping if they were entered via a tool backed by libphonenumber. The grouping we use here follows the National Numbering Plan and official government contact listings — though it’s worth noting this may be an intentional design choice in libphonenumber’s metadata.

See also:

• Issue Tracker: Unexpected formatting of the TW numbers with 3/4-digit area codes
• 公眾電信網路號碼計畫 (Public Telecommunication Network Numbering Plan, Chinese only) [PDF]
• TG Group Chat

NNNN

21 hours ago

19/03/2026-25/03/2026

♦

[1] OSM on an eInk display | © Héctor Satrústegui | map data © by OpenStreetMap Contributors.

Mapping

• Two proposals are waiting for your comments:
  • The cable_landing_station=* proposal to map landing points of submarine cables.
  • The highway=safari_service_road proposal to describe specific service roads in safari parks.
• The proposal flashing_lights=* is still open for voting. The proposal intends to indicate the precise design of flashing lights.

Mapping campaigns

• Following the Morshansk online map party ♦►♦ in 2025, the Russian community is organising another online map party ♦►♦ from 29 March to 11 April. The community will be working to eliminate one of the last major blank spots on the map: the Kunyinsky District of the Pskov Region. This year’s innovation is a new tool ♦ for coordinating zones during collaborative mapping, written specifically for this event. We invite everyone to participate, both beginners and experienced participants!

Community

• In the sharply worded, normatively charged, and at times speculative opinion essay ‘The City in the Data Lab’, mobileGEO offered ♦ an activist analysis of OpenStreetMap as an increasingly central digital infrastructure used for routing, research, and humanitarian missions, among other things. At the same time, they addressed the dependence on a small number of volunteers in core areas, such as server operations and software, as well as issues of governance and data equity.
• A forum post discussed introducing new tools for discussions on the OSM Wiki, including the MediaWiki DiscussionTools extension already used on Wikimedia projects. The aim is to provide more structured commenting and improve participation, with implementation currently being discussed as an Operations Working Group issue.
• Christian Quest announced the creation of the Panoramax Foundation to establish an open source platform for georeferenced street level imagery. The foundation is to be launched as a non-profit organisation and will be supported by partners such as the INRIA Foundation and IGN France. Its aim is to promote decentralised server structures, establish a global meta-catalogue, and strengthen cooperation between authorities, companies and NGOs. Members can actively shape technical development and governance (via the GeoCommuns Forum).
• In a blog post by the ‘OSM Verkehrswende’ initiative, Tobias Jordans explained ♦►♦ that Panoramax requires additional infrastructure and coordination. The goal is to further expand this open-source alternative to commercial services and promote its use for mapping, traffic planning, and data analysis.
• Marina Petkova wrote ♦►♦ about the release of the guide OpenStreetMap et territoires (OpenStreetMap and territories), produced by the Fédération des pros d’OSM. The video record of the session can be watched ♦ online. There is also a publication ♦ about the ODbL titled Tout savoir sur la license ODbL.

OpenStreetMap Foundation

• The OpenStreetMap Foundation Board has approved a new contractor to revamp the GNSS traces feature on the OpenStreetMap website, aimed at renewing the infrastructure for GNSS traces and complying with privacy regulations. The payment comes from the Sovereign Tech Fund, and the rate has been discussed with the Personnel Committee and Core Software Development Facilitator.

Local chapter news

• OpenStreetMap US announced the release of the Pedestrian Working Group Schema 1.0, defining a tiered tagging system for mapping pedestrian infrastructure. The schema provides detailed guidelines for features such as pavements, crossings, and kerbs, aiming to support use cases from basic navigation to accessibility-focused routing applications.

Events

• The FOSSGIS 2026 presentations are available ♦ online.

Maps

• Mlvln described his workflow for a Berlin streetscape map using area=highway data. He combined QGIS with the Overpass API, but switched to Geofabrik’s OSM extracts after his computer could no longer process the raw data. Using Osmose and Python scripts, he filtered tags such as surface=asphalt or amenity=waste_basket and converted HStore fields for visualisation. His goal: a zoom level-dependent tile map – but hosting and regular updates remain open problems.
• Henri97 introduced the portal-streuobst.de ♦►♦, a new map designed to support the mapping and analysis of orchard meadows based on OpenStreetMap data. The project aims to help validate NABU’s estimate of around 250,000 hectares and encourages community feedback and contributions.

OSM in action

• The Geo3D Library is a central hub for publicly available online 3D geological models. It is maintained by the Polish Geological Institute and the National Fund for Environmental Protection and Water Management. It includes OpenStreetMap, Carto Light and OpenTopoMap as basemaps.

Open Data

• Qi Zhou and others have published an open dataset of inland docks along the Yangtze River based on OpenStreetMap data and high-resolution satellite imagery. Using YOLO models they detected 3,562 docks with high accuracy and provided the results as bounding boxes and polygon geometries for further analysis.

Software

• A new security report highlighted CVE‑2026‑2580, affecting the WP Maps – Store Locator WordPress plugin by Flipper Code, which is used with OpenStreetMap, Google Maps, and Mapbox. The issue allows outsiders to access sensitive website data on sites running plugin versions up to 4.9.1, so site owners and developers are encouraged to update and review their map setups promptly.
• [1] Héctor Satrústegui explained how to optimise OpenStreetMap tiles for eInk devices such as Meshtastic or Meshcore. The approach uses Maperitive to generate tiles and a Python script to convert them into greyscale or black-and-white formats, improving performance and usability on low-resource hardware.
• The new iD tagging schema release v6.15.0 includes sidewalk= as a road property, multiple new icons (building under construction, covered reservoir, honey shop and more), animal=horse_walker was added, shop=butcher and other recovered their fields, making it easier to find many objects, and the deprecation of landuse=basin was stopped.

Programming

• d0min0 introduced Drakkar.one, an embeddable map widget that works without API keys, cookies, or Google services. It uses OpenStreetMap data and serves vector tiles as PMTiles via Cloudflare infrastructure, offering a low-cost and privacy-focused alternative to Google Maps embeds.
• Pascal Neis outlined a custom processing pipeline to analyse the full OpenStreetMap planet and generate vector tiles. The approach considers historical object versions and prepares the data for efficient visualisation and analysis workflows.
• The Infra Plan team released on GitHub bim-tile-overlay, a JavaScript library that renders map tiles such as aerial imagery or OpenStreetMap beneath 3D BIM models in Autodesk Viewer. It handles coordinate transformations from local model space to WGS84, computes visible tiles in real time, and projects them in sync with the camera view.
• tristanmk introduced Simple Routing, a low-cost routing API service built on OSRM and VROOM, targeting small projects and developers. The platform aims to bridge the gap between limited free APIs and expensive commercial services by providing shared infrastructure with transparent pricing.
• zorun presented a project implementing an OsmAnd plugin that calculates pedestrian routes based on shade coverage to improve comfort in sunny conditions. The plugin relies on custom-generated shade data, and currently works only for Nantes. The diary entry highlighted usability and integration challenges identified during testing.

Releases

• In a blog post the GraphHopper team introduced improvements made to elevation data handling, enabling more accurate slope and distance calculations. These enhancements particularly benefit use cases such as cycling and hiking routing, where precise elevation profiles are essential.
• The developers of Vespucci released version 22 beta, introducing numerous bug fixes and stability improvements, including handling of Overpass queries, uploads, and UI behaviour. The update also added features such as enhanced tag filtering, image upload support, and improvements to changeset tagging.
• The iD team released version 2.39.0, introducing improvements such as expanded recently used presets, clearer validation messages, and enhanced geometry editing. This release also included multiple bug fixes, updates for street-level imagery, and technical modernisations in the codebase.

Other “geo” things

• Apple has announced plans to introduce advertising in Apple Maps, allowing businesses to pay for promoted placements in search results and recommendations. Advertisements will be clearly labelled and, according to Apple, not linked to personal user data, as part of a broader expansion of its advertising business.
• In their paper ‘Bench marks of change’, Catherine Porter, Margaret O’Sullivan and Elizabeth Gabbett analysed the survival and loss of Ordnance Survey benchmarks in County Limerick, Ireland. Using GIS, historical cartography, and participatory methods, the study finds that over 90% of these historic survey marks are no longer visible and interprets their disappearance as an indicator of broader landscape and environmental change.
• Chronotrains is a Web map which shows how far you can travel by train, from a specific city, for example Berlin. You can select a European city and specify the travel time.
• The EO Glossary of Terms and Definitions serves as a reference for everyone involved in Earth Observation. It covers a wide range of terms, concepts, and definitions relevant to EO disciplines including remote sensing, satellite imagery, geospatial analysis, calibration and validation, climate adaptation, and more. It includes more than 30 recognised databases and you can see a graph with the hierarchy involving the terms.
• The Guardian published a video about how Google Maps search algorithms shape the types of restaurants people find and frequent.

Upcoming Events Country Where Venue What When ♦ Chemnitz Neues Hörsaalgebäude, TU Chemnitz Chemnitzer Linux-Tage 2026 ♦ 2026-03-28 – 2026-03-29 ♦ Online Псковская картопати 2026 ♦ 2026-03-29 – 2026-04-11 ♦ Hannover Kuriosum OSM-Stammtisch Hannover ♦ 2026-03-30 ♦ Saint-Étienne Zoomacom Rencontre Saint-Étienne et sud Loire ♦ 2026-03-30 ♦ San Jose Online South Bay Map Night ♦ 2026-03-31 ♦ Stuttgart Stuttgart Stuttgarter OpenStreetMap-Treffen ♦ 2026-04-01 ♦ Le Schmilblick, Montrouge Réunion des contributeurs de Montrouge et du Sud de Paris ♦ 2026-04-02 ♦ नई दिल्ली Jitsi Meet (online) OSM India – Monthly Online Mapathon ♦ 2026-04-04 ♦ Lucknow Café Coffee Day, Hazratganj OSM Lucknow Mapping Party No.3 ♦ 2026-04-05 ♦ Zaragoza Facultad de Filosofía y Letras (Unizar) & online Mapatón humanitario ♦ 2026-04-07 ♦ Salzburg Bewohnerservice Elisabeth-Vorstadt OSM-Treffpunkt ♦ 2026-04-07 Missing Maps London: (Online) Mapathon [eng] ♦ 2026-04-07 iD Community Chat ♦ 2026-04-08 ♦ Essen Verkehrs- und Umweltzentrum Essen OSM-Treffen ♦ 2026-04-08 ♦ Zürich Bitwäscherei Zürich 186. OSM-Stammtisch Zürich ♦ 2026-04-10 ♦ Paris MSF France (Paris 19e), France MSF-CARTONG: Nuit de la Géographie ♦ 2026-04-10 ♦ Berlin Wikimedia e.V. Tempelhofer Ufer 23-24,10963 Berlin OSM Hackweekend Berlin-Brandenburg 04/2026 ♦ 2026-04-11 – 2026-04-12 ♦ Braunschweig Stratum 0 Braunschweiger Mappertreffen im Stratum 0 Hackerspace ♦ 2026-04-11 ♦ 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 ♦ 臺北市 MozSpace Taipei OpenStreetMap x Wikidata Taipei #87 ♦ 2026-04-13

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, PierZen, 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.

a day ago

♦

Yesterday, I attended the OpenStreetMap Local Chapters and Communities Congress 2026 online.

There were at least 15 participants who signed the attendance list on the event’s HackMD document, representing a range of countries including the Philippines, Italy, the United States, Canada, Greece, Indonesia, Belgium, Kenya, and Brazil. The document is available publicly here.

After introductions and updates from the OpenStreetMap Foundation Board, the session moved into a group discussion titled “Challenges in OpenStreetMap and overcoming those challenges.” This discussion was conducted through Mentimeter, allowing participants to submit anonymous responses to guided questions.

Here is a (selected) summary of the discussion results:

Question 1 : If a new mapper asked you “what’s the hardest part about being in the OSM community?” what would you say.

“So many smart people. All with their strong opinions about how things should be done.”

“Dealing with abusive community members.”

“Not being demotivated by expert mappers that might yell at them for doing mistakes while mapping.”

“Encountering negative / unproductive discourse in OSM fora, which can discourage participation from new new users.”

“Documentation mostly in English.”

“If you are not already technologically literate, it’s a lot to learn and unclear where to start.”

“No clear entry point. Unclear governance”

“Not easy to know what tools/editors to use.”

“The idea of tagging might be confusing and tools/editors often hide these.”

“Data privacy issues in some structures”

“Security protocols with OSM APIs”

“Hard to explain why OSM is needed when Google Maps, Waze and Apple Maps already exist”

Question 2 : What makes it hard to grow or sustain your local community?

“Lack of time.”

“There’s not enough experienced mappers to help newbies and grow the community.”

“Most members from the community prefer money-yielding activities and the idea of volunteer driven initiatives are not so welcomed.”

“The distributed nature of the work can make it hard to reach out to people in the region. I feel we could have better integrated tool to talk to local mappers directly.”

“Lack of funds to organise events and projects”

“Even in English, it’s difficult to find good resources like tutorials for getting people started with mapping.”

“Even small disagreements could lead to long-term bad blood and resentment.”

Question 3 : Is there a gap between the global OSM and your local reality? Where do you feel it?

“Yes. In tagging practices. How to adapt it to the local reality.”

“People are drawn to local and immediate concerns by default and it’s hard to make people excited about global concerns.”

“Core infra needs work and innovation. We need more transparency and openness to community input. Local communities need to shape our shared website.”

“The people who are affected by the gap might not be present at this meeting.”

Question 4 : What support do you wish the OSMF or the wider community provided but doesn’t?

“Money!”

“Appreciation”

“Clear leadership”

“Technological support and timely communication. All effort and local chapters should be accredited.”

“A mix of more formal and informal meetups. From “let’s hear a presentation about this person’s mapping project” to “let’s meet at a bar and hang out as friends”

Question 5 : What are ways you get your community together?

“Daily communication via chat makes us feel close between bigger events.”

“Our annual event. But not all mappers attend.”

“Annual SOTMUS”

“This really requires a core group of active people to get the ball rolling.”

“Telegram groups. Contacting key people one by one through personal chats or email”

Question 6 : What ideas do you have to help grow and sustain OSM?”

“OSMF should hire an executive director / CEO.”

“Clear point of contact for each working group.”

“Local panoramax instances”

“OSM US working on a learning sandbox for new mappers.”

“Introduce the concept of a ‘local fork’, where people can map and document their work in a private space, outside the OSM main database. Build an entirely new geodata crowdsourcing platform on top of the OSM main database, focusing on personalized activities, viewpoints and perspective. The downside of a wiki is that everyone is forced to adhere to a single set of rules. This alternative would instead celebrate diversity”

“Be that positive person on the interwebs! Just a simple ‘Thank you for that question’ / ‘Thank you for editing the map!’ goes a long long way towards the sustainability of the volunteer community”

“An online documentary of successful works used for greater global good. e.g. flood mapping data used by rescue organizations in critical situation.”

“Opportunities to realize paid partnership”

“Communication with local residents for communal mapping of basic infrastructure and services, led through attending town halls meeting.”

2 days ago

Vuoden 2025 lämpimällä kaudella tuli tehtyä 3 tarkoituksellista kartoitusprojektia eri vaiheissa, joista osa liittyi uusien pyöräpysäköintialueiden etsintään ja osa oli ihan puhdasta StreetCompleten ja Wandrerin pisteidenkeruuta.

Keväällä ennen vappua tuli käytyä seuraavat paikat läpi pyöräpysäköintipaikkojen toivossa:

• Sairaalat ja terveyskeskukset.
• Urheiluhallit.
• Päivittäistavarakaupat (marketit ja supermarketit).

Näissä ideana oli käydä läpi paikkoja, joissa ihmiset säännönmukaisesti käy ja joissa pyöräpysäköinnille on kysyntää. Urheilukentät urheiluhallien sijaan olisi vielä kiinnostavampi aihe pyöräpysäköintien sijaan, mutta en saanut tehtyä järkevää hakua Overpass QL:llä, joka ei olisi samalla tuottanut isoa määrää pieniä puistoja tulokseksi.

Tämä kun tuli valmiiksi ennen kuin kesä varsinaisesti ehti alkaa, niin kävin pienen henkilökohtaisen kriisin läpi, että kesäksi suunniteltu projekti tuli valmiiksi aivan liikaa etuajassa. Joten sitten piti keksiä jotain muuta tehtävää, jotta motivaatio säilyy ja StreetComplete onneksi tarjosi sellaista.

StreetCompletesta tehtäviä viihdyttämään

StreetCompletessa olevista tehtävistä tuli poimittua vuoden 2025 lämpimälle kaudelle seuraavanlaisia omaan karttaan:

• Liikennevalojen olemassaolo risteyksissä (Are there traffic signals that show when to cross here?). Tämä oli kesän ja alkusyksyn pääprojekti.
• Keskisaarekkeen olemassaolo risteyksissa (Does this crossing have an island?). Tämä tuli otettua listalle sen jälkeen, kun liikennevalojen olemassaolo oli saatu kartoitettua.

Keskisaareketietoa en saanut käytyä läpi ennen kuin lämmin kausi loppui ja sää oli liian kylmä, että olisi pärjännyt ilman hanskoja.

Vuoden 2026 lämpimälle kaudelle otin hoidettavaksi loput tienylityspaikkojen tietoja kyselevät StreetCompleten tehtävät. Lisäksi OpenStreetMapissa olevat bussipysäkit tulee täydennettyä niillä tiedoilla, joita StreetComplete kyselee. Näitä paikkapisteitä on omassa kartassani tällä hetkellä yli 3000, joten näissä toivottavasti riittää hommaa ja pyöräilykilometrejä.

StreetCompleten tehtävien tekeminen siirtää OpenStreetMapin päivitystä pyöräpysäköintialueiden osalta enemmän stokastiseen suuntaan, jossa en mene enää tiettyyn paikkaan katsomaan, että löytyisikö sieltä runkolukittavia pyörätelineitä. Vaan tarkkailen ympäristöä pyörätelineiden varalta samalla kun kuljen näiden StreetComplete-tehtävien perässä. Ja näiden reittien monipuolisuuden ansiosta tulee sitten käytyä paikoissa, joihin ei muuten olisi tullut mieleenkään mennä.

Katujen pintamateriaalit

StreetCompletessa minulla on näkymä käytössä, joka näyttää tiedon siitä, millainen tienpinta on kyseessä (kuva 1). Käytän tätä pyöräillessä tarkistaakseni, että vastaako ympäristön tiet sitä, mitä ne OpenStreetMapin mukaan on. Navigaattorit käyttää jossain määrin tätä tietoa siinä, että millaisia reittejä painottaa millekin kulkutavalle ja sen asetuksille. Pyöräillessä tästä on erityisesti hyötyä, kun kaikki reilusti epätasainen pinta ikävästi tuntuu hampaita kolisuttavana tärinänä.

♦ Kuva 1: katujen pintamateriaali korostettuna eri värein.

Luulen, että tämä tienpintojen kartoitus Helsingin kantakaupungissa alkaa tuottaa tulosta. Olen muutamaan otteeseen huomannut jo navigaattorin (OsmAnd) asetusten mukaisesti tosiaan välttelevän katuja, joissa on nupukiviä ja ohjaavan kortteleiden kautta, joissa tien pinta on asfalttia. Tämä näin läskirenkaattomana pyöräilijänä on erinomainen navigointimukavuutta vähemmän tutuilla alueilla lisäävä tekijä.

Pyöräpysäköintipaikkojen kehitys

Tässä on alkanut huomaamaan, että tutu paikat alkaa toistua pyöräpysäköintipaikkojen etsimisessä. Lisäksi kun näitä on nyt muutaman vuoden tullut kartoitettua, niin luonnollisesti uusia runkolukittavia telineitä ei enää löydy näiltä alueilta niin helposti. Nyt talven jäljiltä ei ollut kuin noin 30 muiden lisäämää pyöräpysäköintialuetta, joissa ei ollut paikkojen määrätietoa saatavilla.

♦ Kuva 2: Pyöräpysäköintipaikkojen kehitys telinetyypeittäin heinäkuusta 2021 OpenStreetMapin tietokannassa tarkastelualueella.

Runkolukittavia telineitä luonnollisesti luodaan lisää, kun huonolaatuiset renkaanväännintelineet korvaantuu saavutettavammilla laajemman rengasvalikoiman ja runkolukituksen mahdollistavilla telineillä. Mutta vaikka OpenStreetMapiin kirjattujen telineiden lukumäärä on jo viisinumeroisissa lukemissa tarkkailemallani alueella, se ei ole hirveän suuri kun vertaa koko alueen väestöön ja katsoo millaisia aukkoja jopa Helsingin kantakaupungissa on laadukkaan pyöräpysäköinnin osalta. Kuva 2 näyttää teoreettisten pyöräpysäköintipaikkojen kehityksen viimeisen vajaan 5 vuoden ajalta.

Tällä vajaan 100000 teoreettisen kirjatun pyörätelinepaikan alueella on luokkaa miljoona asukasta. Ja erillisiä alueita on kirjattuna hieman yli 4500. Luonnollisesti kaikki eivät ole samanaikaiseti pyörillä liikkeellä ja polkupyörillä on suhteellisen paljon vapauksia sen suhteen, että minne pysäköidä. Mutta varkausriskivaikutelma on myös korkea, sillä alle 20 kg painavan polkupyörän saa helposti kannettua mukanaan. Tämä vähentää intoa pistäytyä paikoissa, joihin ei ole alunperin ajatellut menevänsä, jos lähellä ei ole sopivaa kiinteää kohdetta lukita pyörää.

Ideaalitapauksessa tiheämmillä asuin- ja kaupallisen toiminnan alueilla olisi niin tiheästi runkolukittavia pyörätelineitä, että jokaisessa korttelista olisi näkyvyys lähimmälle käyttökelpoiselle runkolukittavalle telineelle. OpenStreetMapin karttadata olisi tällöin tarpeeton pätevän pysäköintipaikan hakemiseen. Vielä ollaan kaukana tästä.

3 days ago

Ein Spaziergang durch Weißig und Döhlen

Am heutigen Donnerstag machte ich einen meiner vielen Streifzüge durch Döhlen. Besonders ins Visier genommen hatte ich die Streuobstwiese in Freital-Weißig, die mir durch eine Meldung im Freitaler Anzeiger wieder aufgefallen war. Kommend von der Bushaltestelle an der Schulstraße gelangt man über einen Weg zum Zaun der Wiese, wo weiter rechts eine Infotafel aufgestellt ist. Da keinerlei Verbotsschilder auffallen, nahm ich die Gelegenheit war, das Tor selbst zu öffnen und auf die Wiese zu gehen. Bei einem früheren Besuch kamen mir viele Schafe entgegen, heute sah ich kein einziges Tier. Negativ viel mir auf, dass sich vom Eigentümer lediglich um die Streuobstwiese gekümmert wird, nicht jedoch um das Gebiet um den Wettingrundweg bis zum Beginn der Böschung auf dem Gelände des Getränkehandels. So ist der Wettingrundweg unpassierbar. Die Wiese ist glücklicherweise keine Sackgasse, da am oberen Ende des Hanges ein weiteres Tor existiert, durch das man auf das im Süden angrenzende Feld gelangen kann. Von da an ging ich gen Osten zu dem in den Wald führenden Weg. Über eine erst kürzlich entdeckte Schneise gelangte ich wieder in den Wettingrund. Obwohl es Niederschlag gegeben hatte, konnte ich meine zweite Mission, die Kartierung des periodischen Gewässers, nicht fortsetzen, da dessen Verlauf zu verwinkelt ist und kein Wasser zur Nachvollziehung des tatsächlichen Verlaufes floss. Das steht also noch als Ausflugsziel für einen Regentag aus. Um wieder zur Weißiger Straße zu gelangen, schlug ich mich teilweise durchs Niemandsland die Böschung hinauf. An der Bushaltestelle am Mittelweg endete meine heutige Tour.

4 days ago

This text was written by me a couple weeks ago. In the mean time I noticed that my computer struggles with the amount of data to process. That’s why I will need to use another way how to create my map. Anyway, I did not want to scrap this diary entry. I learned already a lot of things and maybe you are curious about my map, so here it is:

♦ Like this or similar could the map look like. This mock-up was made with the QGIS GUI and OSM data downloaded over the overpass api. bigger resolution here

In this diary post, I want to show you what I am currently working on in my free time, what my motivations and inspirations were for starting the project, and what problems I have encountered. I also want to share what I have learned and what I plan to do with the project in the future.

I was inspired by the map Straßenraumkarte by Supaplex030, which shows micromapping in the urban area of Berlin-Neukölln in great detail. The map visualizes a wide range of different OSM elements such as trees, advertising columns, manhole covers, parking lots, pedestrian and bike paths, Stolpersteine, as well as lanes and their markings.

Unfortunately, the Straßenraumkarte has not been updated in a while. Supaplex030 is currently working on a new version that covers all of Berlin but has not yet been released. Therefore, I thought I would try to render the tags I am interested in myself.

Looking at the map gives me good feedback on whether I have worked correctly or if important tags are still missing, such as the specification of the surface=.

♦ In the upper right corner next to the e-scooter parking lot, the asphalt area is not rendered correctly (the white map background is shining through). The roadway area shown here in light red is missing a surface specification in OSM. ♦ Details such as roadway markings, manhole covers, and trash bins (evaluates colour= and operator=)

So far, I have created the map using Overpass API queries for my neighborhood. However, I want to render the entire city of Berlin. I also aim to reduce my dependency on Overpass, as the servers are overloaded by scrapers. This has opened up a new learning opportunity for me to process OSM extracts (.osm.pbf files).

I started with the roadway areas. After downloading the OSM extract for Berlin from the Geofabrik download server, I run a Python script that saves all objects with the key area:highway into a new file using an Osmose command. I then import this file with another Python script into QGIS and process it there in a semi-automated manner.

Before I can further process the data from the extract as I am used to from the data downloaded via Overpass, I need to use the QGIS tool “Explode Hstore Field.” This tool converts the column other_tags, in which many OSM tags are stored as comma-separated list entries, into separate fields in the attribute table. I’m not so sure why the data is stored like this, if this is a general osm-extract thing or if it’s only like this with the extracts from geofabrik, but I was happy that I could find a solution quickly by searching on the internet.

before:

area:highway other tags residential “surface”=>”sett”,… secondary “surface”=>”asphalt”,”junction”=>”yes”,… … …

after:

area:highway surface junction … residential sett NULL … secondary asphalt yes … … … … …

In addition to a few other edits, I can already apply my styling (QGIS Layer Style File QML) from the mock up to the highway areas using a script.

♦ All highway areas for Berlin, often still without surface tags. The blue rectangle roughly indicates the previous bounding box of my mock-up map.

I am curious whether my computer will cope with importing more and more data for the entire city into QGIS. The feature count for the area:highway objects is already just below 15,000. The count for other objects will be significantly higher. Fortunately, the data already comes as spatially indexed, which greatly speeds up the processing and display of the objects.

If everything goes as I imagine, I would like to evaluate additional objects that have not yet been rendered in my mock-up and add rules for displaying features only at specific zoom levels. Regular updates of the data should not be too complicated; I will just need to run the Python scripts. Ultimately, I will render tiles of the map. I hope then to find support for hosting and publishing the map, as this is something I have never done and not even an idea where to begin.

♦ Preview: Area around Kottbusser Tor. It renders the subway-platforms on different layers and displays the ref of the subway entrances

Addendum: As written above. I will need to find a better way. Supaplex030 recommended that I take a look at osm2pgsql and PostGIS. Fortunately I just watched todays presentation Setup and update of an OSM-based map with osm2pgsql (on media.ccc.de; German language only) from Mathias Gröbe at FOSSGIS 2026 conference, so I have a good overview where to start.

4 days ago

Yesterday or the day before, Florian contacted me to see could we map hogbacks on OpenStreetMap. Short answer: Yes.

Long answer: Florian and I have spoken at two Digital Humanities conferences about citizen science and mapping and Wikidata and all that craic before, and one of our co-panellists Meagan’s doctoral thesis was about hogbacks. These are very large stones carved into the shape of very likely buildings (longhouses mostly) and date to the 10th to 12th century. They are pretty cool, to be honest. They are called hogbacks, because they also resemble the curved back of a pig, especially, when the carving is very worn and cannot be made out, which is maybe why they called them that back in the 19th century. The Vikings presumably had a far cooler name for them, but they didn’t write that down for us. Those stones were used as grave markers. (I don’t watch any of the Viking Netflix and other series, but maybe they made an appearance? Let me know in the comments - as if this was YouTube.)

Hogbacks survive or are known to have survived (who knows what might still lie undiscovered underground) in Northengland and to a lesser extent and with stylistic differences in Scotland, Cornwall (where they are called “coped stone”). One example each is known in Ireland and Wales.

Following the pattern of ogham stones for which I did go through the proposal process, Florian and I decided that we would go for the tag historic=hogback with the additional subclassification of hogback=coped_stone for the Cornish examples. I made the “executive decision” that we would be the only people mapping them anyway and that the number is so small that a proposal process would be a waste of time. I’m prepared to be judged for that.

♦

It turns out that two had already been mapped, one as a historic=memorial and the other as historic=tomb. So as to not interfere with other people’s tagging, I only added hogback to the values. They are in a way memorials and mark tombs, but they are not tombs themselves, only grave markers, but I’ll give the other mapper the benefit of the doubt. In several cases, they have also been moved (into museums), so they don’t even mark the grave any longer.

In my opinion, they are special enough to deserve their own value, even if there are so few; it would be good to be able to filter for them.

Florian needed all this for a conference (OSM in action!) next week, so I quickly wrote a Wiki page for them: osm.wiki/Tag:historic%3Dhogback. As of today, it will say that there are none mapped, but that’s because Florian mapped two of them yesterday, when we hadn’t agreed on the tagging scheme.

If I get a chance to go to the one in Ireland, I will make a video. And a 3D scan!

5 days ago

Hello! I made my 1000th edit today which also just so happened to roughly coincide with the 1 year mark of my OSM journey. I have had so much fun learning about OSM and connecting with so many cool members of the community.

I started my work on OSM improving the data in my home town of Wilson Wyoming, which continues to be my main focus, although I have done some smaller projects outside of this area. It has been so rewarding to watch my work come together to create such a carefully detailed representation of its unique and beautiful geography. Through all this work I have not only deepened my passion for geographic data, I have had the pleasure of developing the understanding necessary to truly comprehend the marvel of the world’s greatest map, the open street map. I couldn’t be happier to be a part of such a remarkable feat of humanity and commendation to our planet.

Speaking of Wilson, I began a series of diary entries early on where I would provide updates for my “Wilson WY data overhaul project”… I have since stopped doing this and kinda wish I could delete them (if you know how to delete them let me know). Anyways, I bring this up because Wilson has served as a kind of playground where I have and continue to develop my process for creating the most useful, high detail, well tagged, good-lookin’ data possible. This unfortunately hasn’t happened without some growing pains if you will. There are many things that I am not super proud of. For example, the fact that Fish creek has 30 versions in its way history, or the many driveways, roads, and ponds that have an absolutely egregious amount of nodes due to my disdain for jagged curves and my proclivity for getting carried away in my endeavour to make every curve pretty. I am a victim to the coastline paradox. However, this is something I believe I have improved on. Anyways, this entry is mostly for my own personal posterity, but if you are reading this, or are interested in the work I have done on OSM please reach out to me. I absolutely love to make connections with other mappers!

6 days ago

Definition

From Wikipedia [2026-03-24] : “A boundary marker, border marker, boundary stone, or border stone is a robust physical marker that identifies the start of a land boundary or the change in a boundary, especially a change in direction of a boundary. There are several other types of named border markers, known as boundary trees, pillars, monuments, obelisks, and corners. Border markers can also be markers through which a border line runs in a straight line to determine that border. They can also be the markers from which a border marker has been fixed.”

Tagging in OpenStreetMap

Usual tags are:

• boundary=marker
• collection=yes the marker is a part of the collection of historical markers
• format:top=* describes the shape of the marker’s top
• format=* describes the shape of the marker
• height=* height of the marker
• historic=boundary_marker OR
• historic=boundary_stone
• inscription=* inscriptions on different sides of the marker could be separated by a sign “ “ ( vertical line) or “/” (forward slash)
• marker=border_stone
• material=*stone, concrete, iron, etc.
• moved=yes indicates that the marker is not on its original position
• name=*
• old_ref=* the (old, changed) number written on the marker
• ref=* the number written on the marker
• year=#### (year) (or documented tag start_date=*)

Existing sources Maps

• Institut cartographique militaire, Carte de Belgique, 1:20 000. [1969]. (historical.osm.be/)

• Geo.be. Sous les onglets Cartes > Couches > Unités administratives > AdminVector, on peut afficher une carte de Belgique, qui après zoom adéquat, présente outre les limites, des points représentant des bornes. (www.geo.be/)

• [more to follow]

Archives

The archives contain:

• general maps
• maps specific to boundary marking
• boundary agreements
• minutes of boundary surveys
• minutes of boundary marking

Belgium

• Archives générales du Royaume - Algemeen Rijksarchief

France

• Archives départementales

On-site surveys

My on-site surveys consist of:

• record of the location with a smartphone
• use of OsmAnd and a specific favorites category
• pictures of the marker from various angles (ideally with directions of the angles)
• record of specific characteristics of the marker

Panoramax

I intend to share the results of my surveys and upload them to the Panoramax database.

7 days ago

TL;DR:
I benchmarked my OpenStreetMap processing pipeline (Osmosis → Osmium → Tilemaker) across four machines. Updating the planet takes ~16–21 minutes, while generating worldwide vector tiles (z14) takes between 1h45 and 6h18 depending on hardware and parameters. With tuned Tilemaker parameters and sufficient RAM I was able to reduce tile generation to ~1h45.

The Full Story
Across my various ResultMaps for OpenStreetMap (OSM) contributions, several different tools and data formats appear in my processes and workflows. Since around mid 2024, vector tiles have been part of my setup. Initially, my motivation for learning about them was the idea of providing such tiles in the context of disaster response (for example during the 2023 Türkiye earthquake). Later, however, I started integrating vector tiles directly into several of my quality assurance tools (for example NeisBot in 2024). My goal with this was: A) to reduce the load my services place on the OSM API and B) to become more independent from other sources such as the Overpass API. However, in this blog post I want to share some processing times and show how long different OSM tools take to update and process data on various hardware setups.

Why I Prefer Planet Files Over a Database for OSM Processing
In several of my talks and workshop sessions I often say: the OSM ecosystem provides such good tools for keeping OSM data up to date that my first choice is not a database. Previously I used Osmosis, and currently I rely mostly on Osmium. Both are excellent tools that simply deliver, as you can see later in the timing results of this post. I use Osmosis to download the latest OSM replication changes. After that, I update my planet file and history dump using Osmium. For generating my vector tiles I use Tilemaker.

Setup and Hardware
In total I tested four different machines to represent different hardware configurations. The smallest machine was a Mac Mini (2023) with an M2 Pro processor and 32 GB RAM. The second machine was a Mac Studio (2023) with an M2 Max processor and 96 GB RAM. The third and fourth machines were Ubuntu desktop systems: Ubuntu machine 1 (2024): AMD Ryzen 7965WX, 512 GB RAM, two NVMe drives and Ubuntu machine 2 (2025): AMD Ryzen 9955WX, 256 GB RAM, two NVMe drives. For updating OSM data I use: Osmosis to download replication files and Osmium to update my planet and history planet files. Both Osmosis and Osmium were installed either through distribution packages or compiled from source via GitHub. For my custom worldwide vector tiles I use Tilemaker. This was compiled from the latest GitHub sources on all four machines. My configuration and Lua scripts are almost entirely based on OpenMapTiles [Config] [LUA]. During processing I generate worldwide tiles only for zoom level 14. For my QA/QS workflows this has proven to be a very reasonable compromise between detail and processing effort.

Benchmark Results
Osmosis command to fetch the latest OSM changes: osmosis –rri –wxc changes.osc.gz
Average runtime over seven days:

Mac Mini Mac Studio Ubuntu1 Ubuntu2 Seconds 40 45 44 40 Std. Dev. 9 9 8 6

Osmium command to apply changes: osmium apply-changes -v planet-old.osm.pbf changes.osc.gz -o planet.osm.pbf
Average runtime over seven days:

Mac Mini Mac Studio Ubuntu1 Ubuntu2 Minutes 21:34 21:32 21:19 16:03 Std. Dev. 9 sec 4 sec 8 sec 2 sec

Tilemaker command to generate vector tiles: tilemaker –shard-stores –store ./store –input ./planet.osm.pbf –config ./my-config.json –process ./my-process.lua –output ./planet.mbtiles
Average runtime over three days:

Mac Mini Mac Studio Ubuntu1 Ubuntu2 Hours 06:18 04:09 02:50 03:11 Std. Dev. 2 min 1 min 1 min 1 min

According to the documentation, I could also use the –compact parameter (see Running). However, since I want to include the OSM element IDs in my tiles, this option is currently not suitable for my use case. I also experimented with the number of threads used by Tilemaker. The best results were achieved when setting the number of threads to roughly 50% of the available CPU threads.
Tilemaker using 50% of system threads: tilemaker –thread 24 –shard-stores –store ./store –input ./planet.osm.pbf –config ./my-config.json –process ./my-process.lua –output ./planet.mbtiles
Average runtime over three days:

Ubuntu1 Ubuntu2 Hours 02:25 02:49 Std. Dev. 0 min 0 min

With my configuration and the larger RAM setup on one of the Ubuntu machines I achieved the following result: tilemaker –thread 24 –fast –no-compress-nodes –no-compress-ways –materialize-geometries –input ./planet.osm.pbf –config ./my-config.json –process ./my-process.lua –output ./planet.mbtiles

Ubuntu1 Hours 01:45 Std. Dev. 1 min

This is currently the command I use to generate my tiles. It is worth mentioning that this setup uses the Tilemaker sources from around February 2024. With the latest sources I was somehow unable to reproduce this speed (see GitHub issue). As an additional note: on my second Ubuntu server, Osmium currently takes about 32 minutes on average to update a historical planet file (~160 GB).

Conclusion and Future Improvements
I think the results show that Tilemaker is influenced by CPU and memory bandwidth. While the Apple machines perform well, the Ubuntu system with a high amount of RAM benefits from aggressive Tilemaker parameters and multi-threading. Anyway, I hope this blog post and the numbers presented here can be helpful to others. I am confident that I did not mix up the processing times, but of course mistakes are always possible. I am also definitely not a Linux or parameter tuning expert, although according to several GenAI prompts there should still be some room for further optimization. I am not sure how much impact using multiple NVMe drives has in this setup. Based on my server monitoring I do not really observe significant I/O bottlenecks when comparing it with the RAM-heavy setup.

When it comes to Linux kernel tweaks such as memory cache tuning, hugepages, or filesystem optimization, I am completely out of my depth. If you have experience with kernel tuning, filesystem optimizations, or Tilemaker parameter tuning for large OSM datasets, I would love to hear about your setup.

8 days ago

12/03/2026-18/03/2026

♦

[1] OpenArdenneMap is an open-source map style designed for the production of topographic maps for printing | © juminet | map data © OpenStreetMap Contributors.

 

Mapping

• After passing through the proposal process and being approved the ETCS Markers Tagging Scheme, an effort to unify the tagging of the markers used by the European Rail Traffic Management System, is available for everyone to use. Previously these were implemented using country-dependent schemes. The proponents are asking the mappers of countries where such systems are used to update the relevant wiki pages to include a redirect or a section unified with the new tagging scheme.

Community

• In their latest OpenStreetMap interview series, OpenCage spoke with Martin Ždila of Freemap Slovakia, the Slovak local chapter of the OpenStreetMap Foundation.
• The UN Maps team introduced its new community ambassadors, who plan different activities to bring OSM to local communities.
• KelsonV commented that the latest Pedestrian Working Group’s crosswalk corner tagging scheme is better than the way he had been doing it, so going forward he will use that scheme instead.
• Mateusz Konieczny has requested feedback for proposed preset changes in the iD tagging schema and shared a list of several currently being reviewed for potential inclusion.
• IXVG47QZ reported that last year Javi and Rebecca planned to bike-pack from the Austrian Alps into Asia using CoMaps, an OpenStreetMap-based mobile navigation app. ‘It has safely taken me to many countries in Asia and now in Oceania’, said Javi.

Local chapter news

• Habi has vibe-coded ♦ a script that monitors the official Swiss municipal boundary data from swisstopo and compares it with the boundary data in OpenStreetMap. The script runs daily at 2 am UTC via GitHub Actions, and is accessible here.
• Lyft, an American ride-sharing platform, has joined as the latest OSM US organisational member.

OSM in action

• Vasily Ivanov is developing ♦ a mobile-friendly bike route web map ♦ for the Ertlav ♦ cycling club. You can view other members’ routes and upload your own tracks and photos. OpenStreetMap is used as the base map and the map itself runs on MapLibre.
• rbb24 used ♦►♦ an OpenStreetMap-based map to visualise the locations of cycle paths that will be closed for renovations in the Oberspreewald-Lausitz district, Brandenburg, Germany.

Open Data

• The UNIPLU-BR dataset is the first unified and standardised national database of point precipitation (non-interpolated) in Brazil, consolidating raw data for 40 years and from five official monitoring networks: CEMADEN, INMET, ANA (Hidroweb), Telemetria, and ICEA. The dataset is available on Zenodo.org/EU.

Software

• The March Organic Maps update report includes release notes about improvements related to conditional speed limits, more detailed contours for China, split/smaller Tanzania regions, leather shops, and more. According to the developers this update took more time due to hotfixes and Google Play review.
• The project Geowiki provides a modular ecosystem for processing and visualising OpenStreetMap data, originally developed for OpenStreetBrowser. Its JavaScript library, geowiki-api, retrieves data via the Overpass API or OSM files, makes it usable in Leaflet, or exports it as GeoJSON, and can also act as an Overpass proxy server.
• vizsim has developed ♦ Missing Mapillary GraphHopper Routing for Germany, a web application that plans routes along roads without Mapillary imagery. The tool combines OpenStreetMap data with Mapillary coverage, highlights missing segments through colour-coded routes, and uses ♦►♦ GraphHopper for routing.
• Eugene published a report about the results of the OsmAnd 2026 user surveys that were conducted recently.
• Zkir announced that UrbanEye3D version 2.0, a JOSM plugin for visualising OpenStreetMap’s 3D data, will be released at the end of March 2026.

Releases

• [1] Juminet, who has been developing their topographic style over nine years, has announced the release of OpenArdenneMap winter 2025–2026 version. OpenArdenneMap is open-source map style designed for the production of topographic maps for printing, available for use with QGIS and the Mapnik/cartoCSS libraries.

OSM in the media

• Jules Grandin, of Les Échos, explained the history of roundabouts ♦►♦ in France and tries to answer the question of how many roundabouts there are in France using OpenStreetMap data.
• Ishaan Kocchar wrote, on Substack, about the triple axes of the ‘Digital Communities Trilemma’: openness, activity, and quality, in the context of OpenStreetMap and open data. Ishaan argued that the ‘big corporate consumers’ of the contributed data do not always provide any benefit to the OSM community or the project itself. They compared the Indian context of collaborative mapping with OSM with the local commercial market.

Other “geo” things

• Coordinate Mapper is a professional-grade geospatial tool for plotting, analysing, and exporting coordinate data in multiple systems, including WGS84 and the UK National Grid.
• PGlite, a open-source project that allows you to run PostgreSQL locally in a browser, has added long-awaited support for the PostGIS extension. You can try it out in the browser or use it as an npm package.
• The Instituto Geográfico Nacional (Spain) is offering ♦►♦ some courses on GIS and geoprocessing on its e-learning platform and using the OGC platform over 2026. The course about data management is open ♦.

Upcoming Events Country Where Venue What When OSMF Engineering Working Group meeting ♦ 2026-03-20 ♦ Olomouc Přírodovědecká fakulta Univerzity Palackého Missing Maps Day Olomouc 2026 ♦ 2026-03-21 ♦ Perímetro Urbano Yopal OSM video Encuentro virtual: Introducción a OpenStreetMap ♦ 2026-03-21 ♦ Tiranë osmvideo.cloud68.co/user/ird-zqk-9vq-szt OpenStreetMap Virtual Meetup Tirana ♦ 2026-03-21 ♦ Domplatz Fulda Frühlingsmapping 2026 ♦ 2026-03-22 Missing Maps : Mapathon en ligne – CartONG [fr] ♦ 2026-03-23 ♦ Bruxelles – Brussel ULB Solbosch Campus – Building U – UB4.126 Belgian Interuniversity Mapathon 2026 ♦ 2026-03-23 ♦ Stadtgebiet Bremen Online und im Hackerspace Bremen Bremer Mappertreffen ♦ 2026-03-23 ♦ Pôle Numérique Brest Iroise Rencontre OpenStreetMap et Territoires ♦ 2026-03-24 ♦ Göttingen Uni Göttingen FOSSGIS-Konferenz 2026 ♦ 2026-03-24 – 2026-03-27 ♦ Derby The Brunswick, Railway Terrace, Derby East Midlands pub meet-up ♦ 2026-03-24 UN Mappers Mappy Hour: UN Maps Community Ambassador Pilot Initiative ♦ 2026-03-25 ♦ Düsseldorf Online bei meet.jit.si/OSM-DUS-2026 Düsseldorfer OpenStreetMap-Treffen (online) ♦ 2026-03-27 ♦ Göttingen Uni Göttingen, Fakultät für Geowissenschaften FOSSGIS 2026 – OSM-Samstag ♦ 2026-03-28 ♦ Chemnitz Neues Hörsaalgebäude, TU Chemnitz Chemnitzer Linux-Tage 2026 ♦ 2026-03-28 – 2026-03-29 Local Chapters & Communities Congress 2026 ♦ 2026-03-28 ♦ Vélo Utile rencontre OSM ♦ 2026-03-28 ♦ Mira-Bhayander DBT Café, Mira Road OSM Mumbai Mapping Party No.8 (Western Line – North) ♦ 2026-03-28 ♦ Hannover Kuriosum OSM-Stammtisch Hannover ♦ 2026-03-30 ♦ Saint-Étienne Zoomacom Rencontre Saint-Étienne et sud Loire ♦ 2026-03-30 ♦ Stuttgart Stuttgart Stuttgarter OpenStreetMap-Treffen ♦ 2026-04-01 ♦ Le Schmilblick, Montrouge Réunion des contributeurs de Montrouge et du Sud de Paris ♦ 2026-04-02 ♦ नई दिल्ली Jitsi Meet (online) OSM India – Monthly Online Mapathon ♦ 2026-04-05

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, TrickyFoxy, barefootstache, derFred, izen57, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

9 days ago

此文本同時提供 英文版本 This article is also available in English

OpenStreetMap 是一張由和你一樣的使用者共同協作編輯的地圖，這種協作既是它最大的優點，也是資料品質持續出現問題的原因之一。當成千上萬的貢獻者各自為商店、餐廳、診所和政府機關添加 phone 標籤時，每個人都會帶入自己的格式習慣。對臺灣而言，結果就是一個資料庫中同一個國家代碼可能出現 +886、+886+ 或 +886(2)，而光是一個城市的電話號碼就可能跨越十幾種不同的慣例。

都亂成一鍋粥了，趁熱喝了吧。（悲

這篇文章記錄了我們在掃描六個直轄市及另外五個縣市的 OSM Elements 時所發現的情況，我們正在開發正規化工具（normalizer） 一勞永逸。

問題的規模

在十一個隨機取樣的區域中——包括所有六個直轄市（臺北市、新北市、桃園市、臺中市、臺南市、高雄市）加上苗栗縣、新竹市、臺東縣、連江縣、金門縣——我們在 49,229 個元素上發現了 49,260 個標籤（phone 或 contact:phone）。在將以分號分隔的多重值欄位拆分後，總共得到 50,643 個獨立的電話號碼字串進行分類。

格式類別 數量 佔比 E.123 空格 (+886 2 1234 5678) 41,842 82.6% RFC 3966 連字號 (+886-2-1234-5678) 6,655 13.1% 無分隔符號 (+886212345678) 1,158 2.3% 本地格式，無國家代碼 (02-1234-5678) 854 1.7% 錯誤/誤打的國家代碼 (+866 …, +886(2)…) 92 0.2% 其他（錯誤國家、垃圾內容） 42 0.1%

大約 每 5 個獨立值中就有 1 個 偏離了最常見的貢獻者慣例，這種不一致性使得去重（deduplication）、顯示和機器解析變得複雜。

♦ 情況從糟糕變成難以理解

各區域的格式分佈有顯著差異：

區域 標籤數 數值數 E.123 RFC 3966 其他 臺北市 ★ 9,804 10,146 85% 11% 4% 新北市 ★ 13,963 14,395 85% 11% 4% 桃園市 ★ 4,177 4,277 83% 12% 5% 臺中市 ★ 8,065 8,282 73% 24% 4% 臺南市 ★ 4,246 4,322 84% 11% 6% 高雄市 ★ 5,168 5,262 84% 10% 5% 苗栗縣 1,318 1,338 77% 18% 5% 新竹市 1,088 1,094 82% 12% 6% 臺東縣 1,101 1,178 96% 3% 1% 連江縣 95 103 98% 0% 2% 金門縣 235 246 90% 8% 2%

★ 直轄市。臺中市以 24% 的 RFC 3966 使用率脫穎而出——大約是其他主要城市的兩倍——這表明該貢獻者社群中存在某種主導的本地編輯模式或工具預設值。離島縣市（連江縣、臺東縣、金門縣）具有最高的 E.123 一致性，可能是因為其較小的貢獻者群體更容易收斂到非正式規範。

何謂「正確」：OSM 的格式標準

在列舉具體問題之前，值得先釐清在 OSM 的脈絡下，「正確」究竟代表什麼。

OSM wiki 的 Key:phone 頁面 並未 強制規定單一格式。它記錄了 ITU E.123 國際標記法、RFC 3966（tel: URI 連字號標記法）以及 NANP 格式，而沒有表達明確的偏好。在實務上，E.123 空格標記法是臺灣貢獻者最常用的格式——這也是為什麼我們將其作為正規化的目標——但 RFC 3966 連字號標記法也是 wiki 明確承認的正當替代方案。

因此，正規化的目標並非嚴格遵守某個強制標準，而是為了 內部一致性：對於編輯者、驗證器和下游使用者來說，所有值都遵循相同慣例的資料集，比隨機混合三種格式的資料集要容易處理得多。

理想的一致格式

對於臺灣，最常見的貢獻者慣用格式是 E.123，其次是 RFC 3966/ NANP (北美地區 +1，類RFC 3966)：

ITU E.123
----------------------------------------
+886 2 2034 5678    ← 臺北市話
+886 4 3034 5678    ← 臺中市話
+886 37 203 456     ← 苗栗市話 (3 位數區碼)
+886 89 203 456     ← 臺東市話 (3 位數區碼)
+886 919 114 514    ← 手機
+886 800 000 123    ← 免付費電話 (0800)

NANP
----------------------------------------
+886-2-2034-5678    ← 臺北市話
+886-4-3034-5678    ← 臺中市話
+886-37-203-456     ← 苗栗市話 (3 位數區碼)
+886-89-203-456     ← 臺東市話 (3 位數區碼)
+886-919-114-514    ← 手機
+886-800-000-123    ← 免付費電話 (0800)

多個號碼以分號分隔，末尾不加分號：

ITU E.123
----------------------------------------
+886 2 8787 8787;+886 2 8787 8765

(或)

NANP
----------------------------------------
+886-2-8787-8787;+886-2-8787-8765

♦

小孩才可以全都要，正規化必須作出抉擇

兩者都是可以接受的正規化格式。目前需要社群成員討論的是選擇一種格化並正規化管理，解決混用的問題。

我們的發現 問題 1：不一致的分隔符號

最常見的偏差是混用連字號和空格。這兩者代表的都是同一個號碼：

+886 2 2181 2345     ← E.123（空格，臺灣 OSM 資料中最常見）
+886-2-2181-2345     ← RFC 3966 連字號（正當但較少見）

真正的問題是 在單一數值中混用兩者，這不符合任何一種慣例：

+886 2 2873-6548     ← 國家代碼後用空格，內部用連字號
+886-2-28358739      ← 用連字號，但用戶號碼部分沒有分組

我們發現了 1,554 個數值 在單一電話字串中同時包含空格和連字號——這在任何標準下都是明顯錯誤的。

問題 2：缺少國家代碼

有些貢獻者輸入電話號碼的方式就像他們在本地撥號一樣——沒有 +886 前綴：

02-2581-7780
02 8751 3227
0222346763
0921067050

OSM 的 phone 標籤旨在儲存可國際撥打的號碼。像 02-2581-7780 這樣的值在臺灣以外是具有歧義的：使用者無法知道適用哪個國家的區碼規則。我們發現了 854 個這樣的值，包括直接輸入 09XXXXXXXX 字串的手機號碼。

問題 3：國家代碼後缺少分隔符號

另一種變體是省略了國家代碼與號碼其餘部分之間的分隔符號：

+886288613257
+886228839850

這些在 E.164（電信 API 使用的全數字形式）語法上是有效的，但無法通過大多數顯示驗證器，且作為儲存的 OSM 資料也不易閱讀。我們發現了 1,158 個這樣的值。

問題 4：錯誤或畸形的國家代碼

少數但不可忽視的項目包含明顯的輸入錯誤：

+866 2 29126883      ← 數字位置顛倒（應該是 886 而非 866）
+886+2 2311 2940     ← 多餘的加號
+886(2)28232410      ← 帶括號的區碼（北美風格）
+886.2 2322 3477     ← 使用點號作為分隔符
+8886 2 8780 6278    ← 國家代碼中多了一個數字
+00886-2-23825234    ← 前面加了國際撥號前綴 00

我們發現了 92 個這樣的值。這些在任何執行 ITU-T E.164 語法的電話號碼解析函式庫中都會靜默失敗。

問題 5：多重值欄位中的重複項目

OSM 支援使用分號為一個元素儲存多個電話號碼。我們在整個資料集中發現了 1,320 個多重值標籤。其中，24 個包含重複項目——同一個號碼出現超過一次：

+886 2 2916 0300;+886 2 2916 0300
+886 89 862 326;+886 89 862 326;+886 89 862 326

這表明在編輯過程中發生了複製貼上錯誤。雖然本身無害，但它會誇大聯絡選項並干擾去重邏輯。

問題 6：分機號碼——格式大亂鬥

除了主機號碼本身，資料中還有 635 個以上的值 編碼了分機號碼，使用了至少五種不同的慣例：

慣例 範例 數量 井號 # +886 2 2536 3001#8653 572 波浪號 ~ +886 2 2368 0031~2 26 ext. / ext +886 2 2741 5991 ext.21 30 中文 分機 +886 4 2528 5394分機6000 7 逗號 , (iOS) +886 2 2938 2300,630 ~1+

♦ 冒牌貨！！（指

(@M4HCHE3ZY from X (formerly Twitter))

偵測分機是可行的

正如社群成員在群聊裏指出，一條簡單的規則就夠了：任何不是數字、空格或連字號的字元 ([^\s\d-]) 都可以被視為分機後綴的開頭。這基本上就是我們的正規化工具所做的——在第一個此類字元處拆分，將基礎號碼正規化，然後原樣重新附加後綴。

編碼分機才是問題所在

OSM wiki 的 Key:phone#Extensions 頁面目前記錄了 三種 不同的慣例而沒有從中選出一種，這本身就反映了這個問題多麼懸而未決。

E.123 指定 ext 作為分隔符號。它是在印刷目錄時代標準化的——ext 8653 在名片上清晰易讀，但應用程式無法可靠地解析它。它沒有 DTMF 解釋，分機字串純粹是資訊性質的。

Apple iOS (以及 macOS 聯絡人) 使用逗號 , 作為暫停撥號分隔符號來儲存分機：+886-2-2938-2300,630。逗號指示撥號器在通話接通後等待，然後將剩餘數字作為 DTMF 音頻發送——因此 630 會在主號碼接通後自動撥打。這在設備上是實用的行為，但在 OSM 資料中會產生兩個截然不同的問題：

1. 與多重值分隔符號的歧義。 OSM 使用 ; 在單個標籤中分隔多個電話號碼。逗號在 OSM 中沒有這種定義好的角色，因此像 +886 2 2938 2300,630 這樣的 iOS 風格數值很可能被誤讀為單個格式錯誤的號碼，而不是號碼加分機。我們在資料集中發現了 16 個帶有逗號的值；大多數是錯誤地用 , 而非 ; 分隔的多個號碼，但至少有一個看起來是真正的 iOS 導出的分機。
2. 不可移植性。 以逗號編碼的分機僅對支援 DTMF 的撥號器有意義。它不傳達人類可讀的資訊，且對於任何不理解暫停撥號慣例的解析器來說都是不可見的。

libphonenumber 可以偵測多種分隔符號（#、ext、x、, 等）後的分機，但不會為分機部分發出規範的輸出格式，而是留給呼叫者處理。

RFC 3966 (tel: URI) 是規範最正式的選項——它使用 ;ext=NNN。但 RFC 3966 的分機語法與 OSM 的資料模型產生了結構性衝突，值得詳述。

RFC 3966 分號衝突

OSM 使用分號 ; 作為 phone 標籤的多重值分隔符號：

+886 2 1234 5678;+886 2 8765 4321    ← 兩個電話號碼，標準 OSM 格式

RFC 3966 的分機語法也使用分號作為參數分隔符號：

tel:+886-2-1234-5678;ext=8653        ← 帶分機的 RFC 3966

如果貢獻者將其儲存在 OSM 標籤中，任何單純在 ; 處拆分的 OSM 編輯器或資料使用者都會將其解譯為兩個值：tel:+886-2-1234-5678 和 ext=8653。分機變成了一支憑空冒出的電話號碼。

顯而易見的解決方法是將分號轉義為 \;，這是一些 OSM 標籤對數值內字面分號使用的慣例。但這會產生自己的問題：

• OSM 編輯器 並不一致地支持 \; 轉義；許多編輯器仍會在該處拆分或直接顯示轉義符。
• RFC 3966 解析器 期望原始的 ; 作為參數分隔符——反斜槓轉義的 \;ext=8653 不是有效的 RFC 3966，且不會被任何符合規範的 tel: URI 解析器正確解析。
• 機器可讀性 並未提高：使用者現在需要同時了解 OSM 的反斜槓轉義慣例 以及 RFC 3966 的參數語法，並調和兩者。它增加了編碼複雜性，卻沒有給任何解析器一條清晰的路徑來獲取分機數字。

反斜槓轉義是一個漏洞百出的解決方法，無法完全滿足任何一個標準。實際上，它是疊加在兩個已經衝突的編碼之上的第三種編碼。

結果就是 RFC 3966 分機標記法與 OSM 的分號作為多重值慣例在結構上不相容，目前沒有完美的解決方案。出於這個原因，我們的正規化工具會原樣保留分機後綴，而不是嘗試將其重寫為任何標準形式。

E.123 與機器可讀性

有件事值得特別說明：即使是 完美 正規化的 E.123 電話標籤，也不像看起來那麼對機器友善。

E.123 是由 ITU-T 在 1988 年標準化的——當時電話號碼的主要媒介是名片、信頭或印刷目錄。+886 2 1234 5678 中的空格是為人類讀者提供的視覺分組輔助，而非語義標記。遇到該字串的解析器必須去除空格、推斷國家代碼並找出區碼邊界——這一切都是靠啟發式方法完成的。

RFC 3966 的 tel:+886-2-1234-5678 結構稍微好一點（連字號作為顯式分隔符號，URI 方案標示「這是一個電話號碼」），但仍需要真正的解析器來解譯數字分組。真正對機器友善的形式是 E.164——+886212345678，全數字，無標點符號——這才是電信 API 和資料庫真正需要的。而這些都不是 OSM 預設儲存的格式。

問題的根源說到底，是個無法迴避的矛盾：：OSM 的 phone 標籤是面向人類的。正規化為 E.123 是為了讓資料對貢獻者來說保持一致且易於編輯，而不是為了產生一種應用程式可以直接使用而不需解析的格式。下游應用程式仍然需要像 libphonenumber 這樣的函式庫來完成實際工作——這也正是為什麼該函式庫對於臺灣邊緣案例區碼的正確性至關重要。

google/libphonenumber 微妙的區碼分組方式

非常好的專案，使我大腦旋轉。Google 的 libphonenumber——幾乎所有電話號碼解析器使用的標準函式庫——對某些臺灣區碼的分組方式，與本地使用慣例有所不同。這個問題相當微妙。

臺灣的公眾電信網路號碼計畫分配了數組 3 位數和 4 位數的區碼。libphonenumber 的元資料似乎將這些區碼表示為其 2 位數鄰居的延伸，產生了與本地慣例不同的分組方式：

撥號 libphonenumber 輸出 預期輸出（E.123） 037-123-456 +886 3 7123 456 +886 37 123 456 049-123-4567 +886 4 9123 4567 +886 49 123 4567 082-123-456 +886 8 2123 456 +886 82 123 456 0826-12345 +886 8 26123 45 +886 826 12345 0836-12345 +886 8 36123 45 +886 836 12345 089-123-456 +886 8 9123 456 +886 89 123 456

受影響的地區：苗栗 (037)、南投 (049)、金門 (082)、烏坵 (0826)、馬祖/連江 (0836) 以及 臺東 (089)。

這意味著即使是已經以 +886 X XXXX XXXX 形式儲存的電話號碼，如果是透過使用 libphonenumber 的工具輸入的，也可能帶有不同的數字分組。本文所採用的分組方式依據「公眾電信網路號碼計畫」及公部門聯絡方式標示——不過這也可能是 libphonenumber metadata 的刻意設計。

另見：

• Issue Tracker: Unexpected formatting of the TW numbers with 3/4-digit area codes
• 公眾電信網路號碼計畫 (Public Telecommunication Network Numbering Plan, Chinese only) [PDF]
• TG Group Chat

NNNN

21 hours ago

The Virtual Institute for Sustainable Development - IVIDES.org® , a virtual research institute on the SD matter, and the IVIDES DATA®, a small Brazilian company on information technology consultancy, are lauching a new partnership with the State University of Campinas (UNICAMP) in order to use OpenStreetMap on the collaborative mapping of disaster risk for coastal communities on the northern coast of the state of São Paulo (Brazil). The Virtual Institute for Sustainable Development - IVIDES.org® and the IVIDES DATA company®, in a partnership with the State University of Campinas - UNICAMP), is starting an effort to provide technical supervision and training for collaborative mapping with OpenStreetMap involving three localities (one of them in indigenous lands) along the Northern Coast of São Paulo (Brazil). These communities are still suffering with the consequences of the latest big disaster, occurred on 2023, and constitute areas with common environmental problems, like inapropriate solid waste, rivers’ pollution and deforestation. The research focus on the micromapping with OpenStreetMap and uMap in order to develop the “Participatory Environmental Mapping” approach[1] using the collaborative approach. We hope this project can show better the usability of open data and open software on the disaster risk reduction research, with community participation and improving the personal skills of the collaborators. It is very important, specially on areas with low income levels and literacy. This citizen science approach can opportunize the community participation.

♦ First meeting. Source of basemap (c) OpenStreetMap contributors.

A start meeting was promoved privately on March 27, 2026 and the team is very anxious to use the OSM cartograhic database and related apps. If you want to contribute and(or) communicate about this effort, please, send a message to this address: ivides [at] ivides.org. We are very happy in account with your participation. As a virtual institute for research on sustainable development (and sustainability), with an approach based on the visions of Milton Santos and Ignacy Sachs, we are very honored to contribute with this effort, which we consider very legitm and useful for the local people (residents), which were included in the methodology, as mandatory to the co-working initiatives.

Reference

[1] The Participatory Environmental Mapping (in Brazilian portuguese: Mapeamento ambiental participativo) is an approach which was proposed by Carpi Junior and other authors over the last two decades or so. This type of mapping takes into account the views of local residents on environmental issues, as well as on people, their health and general well-being.

♦

♦

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

a day ago

%{count} contribution(s) in the last year

%{count} contribution(s) in the last year

section on the user page, should be edited. For numbers greater than four digits, periods are placed in groups of three for easier reading, but OSM user profiles have numbers that are difficult to read, such as 1234565885. If we write this as 1.234.565.885 or 1,234,565,885. The contribution counter will be easier to read.

2 days ago

testblog

2 days ago

Javni overpass serveri su u zadnje vrijeme preopterećeni i bacaju greške…

Jedino trenutno “rješenje” je dizanje vlastitog servera. Postoje razne upute za ručno dizanje svoje instance servera, ali se čini kao puno pipkavog posla: osm.org/user/SomeoneElse/diary/408252

Srećom, @Johannes_Gramsch je spomenuo da postoji gotov Docker container; i zaista, postavljenje istog je dosta malo posla (i većinom samo nekoliko sati čekanja da downloadi završe, i parsto GB mjesta na disku).

Meni je trebalo ispod pola sata posla, ali sa uputama može i za ispod 10ak minuta. Detalji na:

community.openstreetmap.org/t/overpass-api-performance-issues/140598/35

3 days ago

Ale o co chodzi?

4 days ago

♦
It's seventeen years since I rode National Cycle Route 1 from Newcastle to Edinburgh. This year I'm gradually revisiting the Northumberland section. Last time I covered this in one go, in one direction, over a few days. Now I'm now riding it in both directions, in short sections, over several months. 

Bit by bit I've already covered quite a lot of the section between the Tyne and Seahouses. Some of it I've ridden in both directions, and some of it several times. However, there are also some parts that I have yet to revisit. Today I was able to plug one of the local gaps by riding from Hipsburn to Dunstan and back.

It was a bit of a grey day. A cold wind was blowing off-shore, but that only had a noticeable effect on progress when the route departed from the coast. I expected the climb out of Alnmouth to be a bit of a challenge. In the event I was pleased (and quite surprised) to manage it without having to get off and push. The rest of today's route is fairly flat. So this was a relatively speedy ride (by my standards).

Between Boulmer an Howick there's a choice between an on-road and an off-road option. I've ridden parts of the off-road option in the past, and walk it quite often. I cleaned the bike yesterday and at this time of year I'd expect the off-road option to be quite wet and clarty. Also, at this time of year, on the roads, the volume of visitor traffic is only just starting to build up. So today I decided to stick with the on-road option in both directions.

I didn't have anything that resembled a plan, but there were several alternatives for a refreshment break when I felt like one. The Arch Cafe just outside Craster is more-or-less at today's half-way point. So that seemed a sensible choice. It turned out to be a good one.

In sumamry, a very pleasant ride. But lacking in anything that I need to bring to the attention of the world. Except for this UFO Monitoring Station just outside Alnmouth.

♦
 

 

5 days ago

I’ve recently learnt how to use the “Building” plugin on JOSM and it’s so slay.

6 days ago

Estimados

Hace 22 días aproximadamente subi una traza llamada Potrerillos, he revisado y hasta la fecha no se visualiza en el mapa, por favor me gustaría saber cual es el motivo o como debo hacer para sea visible en los mapas; ya que será de mucha ayuda a los montañistas que visitan esta zona y con cierta regularidad se pierden.

Gracias.

6 days ago

HOT Mentorship Program 2025: Mapping Fire Incident Hotspots in Nairobi, Kenya.

In the last quarter of 2025, I was privileged to be part of the HOT Mentorship Program. I was a mentee in the third cohort, focusing on Open Community Building. I got to experience first-hand what it takes to work on an individual research project here in Kenya. My project was voluntary, but I learned a new meaning of that word through the project. According to the Oxford Learners’ Dictionary, voluntary is an adjective that refers to “actions done willingly, of one’s own accord, or by free choice, rather than being forced, paid, or compelled by law”. I understood that part very well, but I had little knowledge that free will doesn’t necessarily mean zero budget. So there was that.

What does it take to carry out a research project in Kenya?

While there is no “one size fits all” blanket that defines the needs for all projects, here are a few key points to consider before starting any project:

• General purpose of the project: academic thesis, community building, etc.
• Data: required datasets, available data sources, required licenses and terms of use.
• Scope of the project: geographical extent, objectives of the research project,
• Resource allocation: time, human resources/ stakeholder engagement, financial resources or physical resources.
• Legal Requirements: Associated licenses that may be required depending on the nature of the project.

Mapping Fire Incidents in Mukuru Kwa Njenga

Nairobi is the largest metropolitan city in Kenya, serving as a central hub for various economic and political activities in the country. Affordable housing is a major challenge in the city, leading to the formation of several informal settlements across the county, which lack proper infrastructure. Mukuru Kwa Njenga is one of these settlements. Like many others, the area is characterised by clustered mabati structures and narrow access roads that connect the region to other parts of the city. Fire incidents are a common tragedy in this area, leading to loss of property and lifelong scars.

♦ Image credits: Nairobi Leo News

Research Objectives

The main objectives of the project were:

1. To identify the causes of fire incidents in Mukuru
2. To map fire incident hotspots in the area
3. To identify the role of community leaders and residents in fighting the recurrent fire incidents

Data and Methods

The project was mainly qualitative, seeking to understand the patterns behind the causes of recurring fire incidents in Mukuru, how the fires start and where the incidents occur frequently. The project was carried out in the following steps:

• Data Acquisition/ Exploratory Data Analysis: Acquiring relevant data from the International Centre for Humanitarian Affairs (ICHA), OpenStreetMap and ground verification.

• Hotspot Analysis: Identifying the fire incident hotspots within Mukuru Kwa Njenga and the surrounding settlements, as established from the data and field survey.

• Qualitative Data Analysis: Identifying the causes of fires in Mukuru and identifying the gaps in the distribution of emergency care services around the fire incident hotspots.

• Capacity Building: Conducting a fire safety awareness training and community engagement forum.

Research Findings

The following map shows the distribution of fire incident hotspots around Mukuru Kwa Njenga and the surrounding areas: ♦

From the research findings, fire Incidents in Mukuru Kwa Njenga are majorly caused by:

1. Faulty Cooker Valves: Commonly used cookers have valves that gradually become loose and pose a fire hazard caused by gas leakage.
2. Traditional lanterns (koroboi): These lamps pose a fire hazard when knocked over or left unattended, and are a common cause of fire ignition.
3. Abandoned cooking stoves: When cooking stoves are abandoned for a long time, they slowly ignite cooking pots and nearby curtains, hence starting a fire.
4. Faulty Wiring: Most power cables in the area do not meet the required standards of installation, and they pose a risk of electrocution and ignite fires.
5. Building material of the houses: Most of the houses in Mukuru are mabati houses, which are crowded and catch fire very easily
6. Lack of supportive infrastructure: lack of a nearby fire station, narrow access roads, insecurity and inadequate water supply in the area slow the response rate to fire incidents in Mukuru Kwa Njenga and surrounding areas.

♦ *Image Credits: Online

Challenges and Limitations

• Limited Project Funding - Challenges in facilitating the community members and field assistants who participated in the mapping exercise
• Limited Project Scope: The project only covered a few villages in Mukuru, due to limited project timelines and funding.

Recommendations

• The community members should collaborate with the Fire Brigade Team to organise more fire safety training programs
• The residents of Mukuru should replace their gas valves regularly to prevent fire incidents caused by gas leakages.
• Further research should expand the project scope to cover a wider area and propose solutions for the recurring fire incidents.

Conclusion

Recurring fire incidents are one of the major challenges that the people of Mukuru have continued to endure for several years. This project highlighted the major causes of fire incidents and mapped some of the incident hotspots within Mukuru. The OpenStreetMap database was particularly useful in geocoding street addresses, locating emergency amenities such as health centres, providing building footprint data, access roads and social amenities such as water points. The project aimed at increasing the visibility of Mukuru to the relevant stakeholders and inviting some action on the subject matter.

Mentor: Farhina Hoque Manager- Student Affairs Asian University for Women (AUW) Bangladesh. Mentee: Evalyne Nyawira Geospatial Analyst   Nairobi, Kenya. 7 days ago

 

♦Maelmin Henge is just outside Millfield. It's a reconstruction of the nearby Milfield North Henge: one of several henge monuments in the Till Valley that date from the Later Neolithic and Early Bronze Age.

Today's ride started in Millfield, then passed through a series of small settlements: Ford, Crookham, Branxton and Mindrum.

Apart from Maelmin Henge I took in the site of the Battle of Flodden, which was fought outside Branxton in 1513. The Church of St Michael and All Angels at Ford dates from the 13th Century, and was heavily restored by John Dobson in 1853. There has been a mill at Heatherslaw since 1291. The current one was restored and re-opened in 1975, but was closed today.  For more local history I could have made a brief diversion via the 14th Century Etal Castle. But enough is enough.

Part of my route followed NCN68 - the Pennine Cycle Way. The two sections on the A697 were both very brief and traffic wasn't a problem. The rest of the ride was on quiet country lanes. 

Once again I chose a route that is more hilly than I'm used to. On my personal scale of difficulty I couldn't rate this as an "Easy" ride. Others describe it as "Moderate", but I'd have to rate it as more difficult than that. "Challenging"  would be putting it too strongly. I'd like to rate it as "Satisfying", but for now, I think I'll settle on "Demanding".

8 days ago

Durant les mois d’Avril et de Mai, je vais faire comme à Jassans en 2025, c’est à dire faire des relevé hebdomadaires de ref=* des lampadaires de Chaleins:

Carte: umap.openstreetmap.fr/fr/map/carte-releve-lampadaire-de-chaleins_1371864#13/46.051374/4.819221

Dates actuelles:

Aujourd’hui (22/03)=Zone 1=Lancement Chaleins !

28/03/2026=Zone 2

04/04/2026=❌ Annulé=FCO 2026

11/04/2026=Zone 3

18/04/2026=❌ Annulé=Conscrits de Frans

25/04/2026=Zone 4

02/05/2026=Zone 5

09/05/2026=Zone 6

16/05/2026=Zone 7

23/05/2026=Zone 8

30/05/2026=Zone 9

06/06/2026=Zone 10=Finalisation de Chaleins

Les dates peuvent bougé en fonction de mon planning perso…

9 days ago