이 부근에 거주하고 계시거나, 이 부근에 대해 잘 알고 있으신 분들의 맵핑 부탁드립니다.

I added data to the Mauritania mapping for the agricultural component of the UN. Most of these appear to have been a result of the shape of the landscape, around the farmland.
I think that next time I will use the Josm tool.

A style using the Shortbread vector tiles is now live on OpenStreetMap.org. There’s been some minor issues with the roll-out, but nothing that caused me to panic. I’ve been taking a couple of days to unwind and relax, as this has been a major milestone.

A feature like this includes work across multiple projects, so people have been asking where to report issues.

1. Any issues that are present on the OpenStreetMap website but not on the vector demo page should be reported to openstreetmap-website. Some issues reported have been with attribution controls and strange panning at extremely high zooms

2. Style issues (e.g. colors, symbology, fonts, etc) are handled by the VersaTiles Colorful and VersaTiles Eclipse styles. Both can be found in a VersaTiles repository.

3. What is supposed to be in the tiles is defined in the Shortbread Vector Tile Schema 1.0. There are lists of what features should appear, and where they should appear.

4. The code responsible for what is actually in the tiles is contained in the Street Spirit repo. If something is missing that is supposed to be in Shortbread, this needs fixing. This also handles simplifcation and other parts of generating the tiles.

5. The software that serves the tiles is Tilekiln. If the wrong HTTP headers are being sent, this is where you report it.

6. The chef code pulls everything together on the OSMF servers. It’s unlikely you should report an issue directly here.

7. Some font rendering issues are part of MapLibre GL JS. This is most likely to come up in Southeast Asia.

일주일 후에 선재도 매핑을 마쳤습니다. 재밌는 사실: 근처에 있는 5개의 작은 섬은 이전에 지도에 표시된 적이 없는데, 이는 OSM 지도에 존재하지 않는 섬이 한국에 수백 개나 있다는 것을 의미합니다. 즉, 아직 해야 할 일이 많다는 뜻입니다. 서쪽 해안에 있는 섬들을 지도에 표시할 계획입니다.

커뮤니티의 조언을 모두 참고했지만, 도로에 정확한 이름을 붙이는 방법을 여전히 찾지 못했습니다. 그래서 집 주소를 완벽하게 표시할 수 없었던 겁니다. 커뮤니티의 누군가가 제가 한 작업을 보고 도로와 주소를 알아낼 수 있다면 정말 좋을 텐데요.

Many OSM validators will report an error if a waterway crosses a highway without some additional tags or structure at the intersection, such as a bridge, culvert, or ford. That makes a lot of sense if you’re working in an area where the roads and waterways are already well mapped and where the waterways are actually wet. Those assumptions might work well in Europe, for example. They don’t work well in the Southwest United States.

Of the possible resolutions, adding a node with ford=yes is the easiest, so many mappers will do this to satisfy the validator – sometimes without looking closely at the situation. Then you get results like this, where the ford=yes nodes are meaningless.

If you get a warning from a validator that a waterway and highway intersect and need additional tagging, there are some things to consider first:

1. Is this a usable highway? If the highway should be tagged with access=no or with a lifecycle tag like disused: or abandoned: there’s no need for additional infrastructure to cross a waterway.

2. Does this “waterway” have water in it? Look closely at the aerial imagery and consider the local environment. Maybe this feature would be better tagged as natural=gully or something similar.

3. Are the highway and waterway in the right place? In the Southwest US, there are a lot of highways that were imported from TIGER with alignment that ranges from imprecise to atrocious and that have never been updated. And there are a lot of waterways imported from NHD that are just as bad. If you take the time to correct the alignment of the highway and waterway, you may find that they intersect somewhere else or don’t intersect at all.

As a related question, is the course of the waterway distinct? Many waterways meander within well-defined banks, so the precise location of the waterway is difficult to determine and varies over time. Consider this before deciding where the waterway and highway intersect, if they intersect at all.

4. Is there existing infrastructure such as a culvert or bridge to allow the waterway to pass under the highway? Look closely at the aerial imagery and consider local road building standards.

5. Does this waterway only have water under conditions that could be described as a flash flood?

If so, it is not possible to ford this waterway. Locations like this should not be tagged with ford=yes.

6. Does the highway follow the course of the waterway? In arid environments, it is common for routes of travel to follow dry waterways. These highways are only usable when the waterway is not flooded. In this case, please do not add ford=yes to every node in the highway. That’s just nonsense.

The Geofabrik dowload server is a wildly popular service that pushes out about 400 TB of OpenStreetMap data to users around the world – most of that in the form of country or regional .osm.pbf files. We publish these files with a date in the filename (e.g. germany-250723.osm.pbf) but for convenience we also have a downloadable file like “germany-latest.osm.pbf” that always gives you the most recent version.

Keeping these two as separate files does, however, interfere with caching; the proxies we use to speed up the download offering don’t know that “something-250723” and “something-latest” are the same file so they need to retrieve them both.

Starting 01 September, we’ll change this in line with best practices, and send a HTTP redirect if you request a “latest” file. The redirect then points the client to the appropriate URL with a data embedded in the file name. This should be transparent for most use cases, however if you have some sort of setup that does not follow HTTP redirects you might have to modify that. wget will follow redirects by default, whereas curl requires the command line flag -L.

I like to map trees. Last year, I wrote a diary about trees mapping, a wiki page to document tagging of Italian monumental trees tagging, a trivia thread about the tallest trees in the database etc. In this diary, I’d like to focus on quality assurance (QA) checks we can perform on tree data. Many of these checks have been turned in MapRoulette challenges in my Tree Validation project.

Measures 📐

• Circumference

The circumference=* tag is used to describe the circumference of a tree’s trunk at a height of 1.3 metres above the ground, with the implied unit of measure being metres. Therefore, circumference=2.3 describes a trunk with a circumference of 2.3 metres.

According to the Guinness World Records, the greatest circumference for a tree is 43 metres. Trees with circumferences exceeding this value are likely errors. Often people forget that metres is the standard unit, so they tag using centimetres, creating giant trees. E.g. they tag circumference=650 instead of circumference=6.50.

• Height

The height=* tag is used to describe the height of a tree in metres. Therefore, height=15 describes a tree that is 15 metres tall.

Hyperion is a coast redwood (Sequoia sempervirens) in California that is the world’s tallest known living tree, measuring 115.92 m. Trees with height exceeding this value are likely errors.

• Specific species measures

You can refine the above checks using known limits for individual species. For example, according to monumentaltrees.com, the biggest circumference for a Tilia cordata is 12.81 (instead of 43) and the tallest specimen is 41.60 (instead of 115.92).

• The “slenderness ratio”

The height-to-circumference ratio can be considered a form of “slenderness ratio”: lower values indicate stocky or stout trees, while higher values indicate slender or spindly trees. This can be helpful to find wrong circumference or heights.

• This Quercus robur has height=24 and circumference=0.01. This makes it the most slender tree of its species with a “slenderness ratio” of 2400, while the average for its species at the moment is 15.07.
• This Tilia cordata had height=26 and circumference=864. This made it the most stocky tree of its species. The problem here was the circumference expressed in centimetres instead of metres.

Leaves🌿

• Leaf type

The leaf type can be broadleaved, needleleaved or leafless. In case of woods and forests mixed could also be used. leaf_type=palm is also used, though disputed. Other values are likely incorrect.

Some examples I just took from taginfo:

• leaf_type=genus=Tilia is clearly an error, should simply be genus=Tilia
• leaf_type=Broad should be leaf_type=broadleaved
• leaf_type=oak should be leaf_type=broadleaved + genus=Quercus

• Leaf cycle

The leaf cycle can be decidous, semi_deciduous, evergreen or semi_evergreen. In case of woods and forests mixed could also be used.

Some examples from taginfo:

• leaf_cycle=broadleaved should be leaf_type=broadleaved
• leaf_cycle=coniferous is likely to be leaf_cycle=evergreen
• leaf_cycle=Quercus rubra should be species=Quercus rubra

• Specific species leaves

All trees of the same species should have consistent leaf_type and leaf_cycle.. I created a list of species on the wiki (inspired by the genus one). This list is actually used by Osmose and in the past I also proposed it to NSI for a new tree category.

This list can be used to improve trees without these tags or to QA trees that have mismatching values. For example, a tree of the Pinus genus should have evergreen needleleaved leaves, if not either the species/genus or the leaf tags are wrong.

Species and genus 🌳

An easy check is to check for species values that are one word only and for genus values that are not one word only:

• species=Quercus should be genus=Quercus
• genus=Quercus rubra should be species=Quercus rubra

Wikidata 🌎

Thanks to QLever, we can run some checks on Wikidata values. Some people often mistakes species:wikidata with wikidata, linking to a whole species instead that to a specific notable tree. Or they link genus/species:wikidata to Q-Items that are NOT instances of taxon.

• species:wikidata=Q52515011 this user wanted to link to the Laurus nobilis Q-Item, but linked an homonymous botanical illustration.
• species:wikidata=Q102322232 in this case the user wanted to link to the Malpighia emarginata Q-Item, but linked its fruit Q-Item instead.
• species:wikidata=Q55741734 the user wanted to link to the Quercus ilex Q-Item, but linked to a monumental trees of the same species (located +700km away) by mistake.

Mateusz’s OSM-wikipedia-tag-validator also has some wiki checks for species and genus.

Conclusion ✅

Tree mapping could benefit from far more QA checks in editors and tools. I believe more people would contribute if we had a dedicated site like WaterwayMap, but for trees. There’s still a lot of potential for improving data quality with better validation tools.

Die korrekte eingabe von Öffnungszeiten in OSM ist sehr hiflreich, damit Anwendungen wie Navigationssysteme, Karten-Apps oder lokale Verzeichnisse die Daten zuverlässig nutzen können. Nur korrekt formatierte Angaben können maschinell gelesen und verarbeitet werden. Fehlerhafte oder uneinheitliche Eingaben führen dazu, dass diese Informationen ignoriert oder falsch dargestellt werden. Das schmälert nicht nur die Qualität der Daten, sondern auch das Vertrauen in OSM-basierte Dienste.

Wiki eintrag dazu

Tool

Hallo, wir haben eine Übersichtskarte der Fahrradreparatur-Säulen sowie der E-Bike-Ladestationen für Deutschland erstellt. Leider auf GoogleMaps und möchten diese jetzt lieber auf OSM weiterführen, haben aber nicht die Kenntnisse, wie wir die bereits vorhandenen Einträge überführen können bzw. ob dies überhaupt erlaubt ist. Kann uns jemand unterstützen oder Tipps geben?

Slowly working to edit and add information about public infrastructure, along with surveillance information.

Heute vormittag kam in einem OSM-Channel die Frage auf, wie man den Bereich ermitteln kann, den die Feuerwehr beim Löschen rund um einen Hydranten abdecken kann. Die Annahme war dabei, dass die Feuerwehr bis zu 250 Meter lange Schläuche legen kann – aber nur entlang von Wegen, also nicht „kreisförmig“ rund um den Hydrantenstandort. Dort, wo die Feuerwehr mit ihren Schläuchen nicht hinkommt, bietet sich ein größeres Risiko im Fall eines Brandes, oder im Umkehrschluss ein Potential für zusätzliche Hydranten.

Abb. 1: Von Hydranten versorgte und nicht versorgte Bereiche in Schrems, Niederösterreich. Schwarz hervorgehobene Gebäude und straffierte Bereiche liegen außerhalb der Erreichbarkeit von Hydranten (wobei im Nordwesten vermutlich noch keine Hydranten gemappt wurden).

Diese kleine Aufgabenstellung ist ein ideales Beispiel dafür, wie OSM-Daten für Geodatenanalysen verwendet werden können. Im OSM-Universum haben wir viele Werkzeuge zur Verfügung, um geografische Fragen mit einfachen Mitteln zu beantworten, beispielsweise Overpass (vor zwei Wochen erst zeigte beispielsweise Discostu36, wie man mit OSM-Daten Standorte für Grünpfeile für den Radverkehr ermitteln kann).

Heute möchte ich den Fokus mal auf QGIS lenken, ein freies Geoinformationssystem (GIS), das die meisten sicherlich kennen, aber nur die wenigsten aktiv nutzen. Dabei bringt QGIS von allen verfügbaren Mitteln sicherlich mit die meisten Analysemöglichkeiten mit und ist nach etwas Eingewöhnungszeit auch nicht schwer zu bedienen.

Vorbereitungen und Datenbezug

Der Fall unserer Hydranten ist eine einfache Erreichbarkeitsanalyse: Welchen Bereich kann ich innerhalb einer bestimmten Zeit oder einer bestimmten Distanz von einem Startpunkt aus erreichen? Zahlreiche Routing-Dienste können solche Isodistanzen ermitteln, man benötigt aber meist einen Zugang oder API-Key und muss oft auch Geld dafür zahlen. Mit den nativen Werkzeugen von QGIS kann man das Ergebnis jedoch in wenigen Schritten selbst ermitteln und braucht noch nicht mal Plugins dafür (von denen es einige für Isochronen-Auswertungen gibt).

1) Daten herunterladen und in QGIS öffnen: Über Werkzeuge wie Overpass Turbo, das Quick-OSM-Plugin von QGIS oder die Geofabrik-Downloads kann man gezielt gewünschte OSM-Daten beziehen – in unserem Fall reicht eine einfache Overpass-Abfrage für Hydranten, das Wegenetz und optional noch Gebäude. Die extrahierten Daten lassen sich in Overpass Turbo als GeoJSON in einem Geodatenformat abspeichern und direkt in QGIS öffnen.

2) Daten reprojizieren: Um Entfernungen in Metern zu ermitteln, kommen wir nicht drumrum, die Daten vorher in ein metrisches Koordinatensystem umzuwandeln (schließlich liegen die Schläuche unserer Feuerwehr flach auf dem Boden und werden in Metern gemessen – und nicht in Breiten- und Längengraden auf der runden Erdkugel). In Mitteleuropa sind das beispielsweise die UTM-Zonen 32 oder 33. Also das QGIS-Werkzeug „Layer reprojizieren“ (reproject layer) auswählen und unter „Ziel-KBS“ das gewünschte System auswählen (z. B. „EPSG:25833“ für die UTM-Zone 33).

Anmerkung: Viele wichtige Werkzeuge lassen sich in QGIS über die Menüleiste erreichen, z. B. unter „Vektor“. Eine vollständige Liste aller Werkzeuge bietet die Verarbeitungswerkzeuge-Ansicht, die sich über „Ansicht” > „Bedienfelder“ > „Verarbeitungswerkzeuge“ einblenden lässt.

Erreichbarkeit von Hydranten ermitteln

3) Welche Bereiche werden von Hydranten versorgt? Zum nativen Funktionsumfang von QGIS gehört das Werkzeug „Dienstbereich (aus Layer)“ (service area from layer), welches uns die eigentliche Erreichbareitsanalyse ermöglicht. Als „Netzwerk-Vektorlayer“ wählen wir das Straßennetz, als „Startpunkt-Vektorlayer“ die Hydranten. Der „zu berechnende Wegetyp“ bleibt bei „kürzester“, und als „Reisekosten“ geben wir unsere maximale Schlauchlänge, also 250 Meter ein. Als Ergebnis erhalten wir je Hydrant ein Wegenetz, welches er „abdecken“ kann – und alle Wegenetze zusammen ergeben den Gesamtbereich, der in dieser Gemeinde über Hydranten mit Löschwasser versorgt werden kann.

4) Welche Bereiche werden im Umkehrschluss nicht von Hydranten versorgt? Ziehen wir diesen gesamten versorgten Bereich von unserem Eingangs-Wegenetz ab, erhalten wir die Bereiche, welche nicht mit Hydranten versorgt sind. Bevor wir diese Differenz ermitteln, sollten wir die versorgten Bereiche um einen kleinen Betrag puffern und somit von Linien in eine (dünne) Fläche umwandeln – so stellen wir sicher, dass die versorgten Bereiche geometrisch zuverlässig aus unserem Wegenetz ausgeschnitten werden: Werkzeug „Puffer“ (buffer) auf den Dienstbereich anwenden und als Abstand z. B. einen Meter auswählen.

Es entstehen viele Einzelflächen, die wir über „Auflösen“ (dissolve) zu einer Einzelfläche verschmelzen können. Dann die Differenz (difference) mit dem Wegenatz als Eingabelayer und dem leicht gepufferten Versorgungsbereich als Überlagerungslayer anwenden.

Abb. 2: „Dienstbereich“ eines beispielhaften Hydranten, unter der Annahme, dass man von ihm aus eine Schlauchstrecke von 250 Metern länge anlegen kann. Für das letzte Haus einer Stichstraße kann es im Brandfall knapp werden.

Nicht erreichte Gebäude: Potentielle neue Hydrantenstandorte

5) Welche Gebäude können im Brandfall nicht von Hydranten erreicht werden? Als Zugabe können wir nun noch Gebäude identifizieren, die im Brandfall nicht mit Löschwasser aus Hydranten erreicht werden können. Dafür gibt es verschiedenstee Möglichkeiten: Mit zusätzlichen Isochronen-Plugins für QGIS (siehe unten) ließen sich die versorgten Bereiche beispielsweise direkt als Flächen abbilden und man müsste nur prüfen, welche Gebäude außerhalb dieser Flächen liegen. Wir wollen aber lieber streng vom Wegenetz ausgehen und könnten statt dessen abfragen, ob die jeweils nächstgelegene Straße versorgt oder unversorgt ist – müssten dann aber noch Entfernungen zu dieser Straße bzw. zum nächsten Hydranten berücksichtigen.

Eine sehr einfache Alternative ist, für jedes Gebäude zu ermitteln, ob es fernab versorgter Wege liegt. Dafür die Gebäude um einen größeren Betrag (z.B. 50 Meter) puffern, sodass die Puffer in den meisten Fällen den nächstgelegenen Weg erreichen. Dann alle Puffer „nach Position extrahieren“ (extract by location), die „getrennt“ (disjoint) von den versorgten Bereichen sind. Die übrig bleibenden Puffer kann man wieder um -50 Meter puffern (also schrumpfen) und aus den originalen Gebäuden diejenigen auswählen („Nach Position extrahieren“), die diese schneiden (intersect).

Der Nachteil dieser Variante: Manche Gebäude sind weiter als 50 Meter vom nächstgelegenen Weg entfernt aber dennoch nah genug an einem Hydranten bzw. versorgten Straße. Diese würden als unversorgte Gebäude identifiziert werden, fallen in einer manuellen Nachkontrolle des Ergebnisses aber leicht auf und können bei Bedarf aus dem Ergebnis gelöscht werden.

6) Wo werden weitere Hydranten benötigt? Aus den identifizierten, nicht mit Hydranten versorgten Gebäuden ergeben sich potentielle neue Hydrantenstandorte – idealerweise im Umfeld dieser Gebäude. Daher lassen sich mögliche Standorte einfach identifizieren, in dem die unversorgten Gebäude wieder mit einem Puffer (z. B. 125 Meter oder maximal 250 Meter) versehen werden – innerhalb dieser Fläche fehlen Hydranten (oder sind einfach noch nicht in OSM erfasst).

Abb. 3: Unversorgte Gebäude und Potentialflächen für Hydranten.

Ausblick: Weitere Analysemöglichkeiten

Nach dem die Frage beantwortet war, wo möglicherweise Hydranten fehlen, kam gleich die nächste interessante Frage auf: Bei unterschiedlichen Einsätzen werden auch unterschiedliche (Feuerwehr-)Fahrzeuge bzw. Ausrüstungen benötigt. Nicht jedes Feuerwehrfahrzeug hat jede Ausrüstung an Bord. Lässt sich im Notfall auch ermitteln, welche Feuerwache mit dieser Ausrüstung den kürzesten Weg zum Einsatzort hat? Professionelle Einsatzleitsysteme, die insbesondere für ihr Routing teils auf OSM-Daten zurückgreifen, können diese Frage vermutlich in Echtzeit beantworten. Aber in kleineren Gemeinden kann auch dies eine einfache GIS-Frage sein.

Spätestens hier sollte man sich mit Plugins für Erreichbarkeits- und Netzwerkanalysen in QGIS beschäftigen, beispielsweise die ORS Tools des OpenRouteService. Sie bieten erweiterte Möglichkeiten für Erreichbarkeitsanalysen, beispielsweise die Generierung von Isochronen-Flächen. Hier in die Details einzusteigen soll aber nicht Gegenstand dieses Blogbeitrags sein.

Abb. 4: Isochronen für zwei ausgewählte Rettungswachen. Angenommen, diese beiden Wachen besitzen eine bestimmte Aussattung, die im Notfall benötigt wird: Welche liegt am nächsten am Einsatzort?

Ich hoffe aber, das Praxisbeispiel konnte veranschaulichen, welche Analysemöglichkeiten OSM im Zusammenspiel mit QGIS mit relativ einfachen Mitteln bietet. Den Möglichkeiten sind dabei kaum Grenzen gesetzt, solange eine ausreichende Diche an OSM-Daten vorhanden ist: Vielleicht lohnt sich mal ein Blick darauf, wo in eurer Gegend die Dichte der Spielplätze, Restaurants oder Ein-Euro-Shops am höchsten ist? Wo gibt es Wohngebiete, die nicht mit dem Nahverkehr erreichbar sind oder in denen man nicht im Supermarkt einkaufen kann? Wo in einer Stadt gibt es viele Parkplätze, aber keine Straßenbäume? Sicherlich habt ihr eigene Ideen oder habt schonmal über eigene Auswertungen nachgedacht oder diese durchgeführt und könnt darüber berichten.

I haven’t written anything in this diary yet, so I decided to just do that.

I have no idea any more when I first heard of OpenStreetMap. What I do still remember is the time where I didn’t know how to make changes myself. I noticed this mostly back around 2015 when I was using a GPS navigator based on OSM data, and often it didn’t bring me to the precise location because of missing house numbers. This wasn’t too bad, I was in the general vicinity, and I could mostly figure out where to go from there, but it was annoying, and I do remember two occasions where the same street was actually separate parts, making it hard to find out where I needed to be. I was thinking that it would be nice if I’d knew how to add those house numbers. Some I encounter along the way wouldn’t be much, but if everyone does a bit, a lot can be done was my idea.

Somewhere in 2021, I met Pieter who is very active in the Belgian OSM community, and he was nice enough to give me a deep explanation of how it all works and what tools there are and what I can do to contribute. I decided to write this explanation down in a blog post, and from that moment on, I started to contribute to OSM. I was also pleased to hear that the house number problem I was having, was mostly a problem of the past, as the government released the needed data under a compatible open license, and people of the community are making sure the data is put to good use.

I mostly use MapComplete, which is a great tool for showing Points Of Interest, and adding them to the map. It has different themes, each showing their own category of POI’s. When I see a bench while walking, I often add it. Or, if it’s already on the map, I see if I can add more information, or even a picture. Same with artworks, information boards, picknick tables, and so on. I’ve also walked through town centers, mapping the small shops, bars and restaurants, and adding information like opening hours. In fact, my first contribution was a local bakery I typically go to. The main reason why I wanted to map it, was because I sometimes wonder about opening hours. I decided that keeping a copy of these opening hours somewhere was a good idea, and instead of using some personal notes, I added it through Mapcomplete.

While POI’s remained my main focus, I joined a mapathon at the end of 2024 where we did some work for the Lili app. Here is where I first added lines to the map. Streets, flower beds, fences, things like that. The day after, it was saturday then, I also spend some hours finishing the work I had started.

I also learned more about how it is for blind people to find their way. Finding a route for blind people isn’t just making sure they are safe from traffic or from falling down somewhere. They also need ways they know, and it’s important to not lead them in a way that they can accidentally end up in the middle of an open space. In Bruges there are 10 “main routes”. Those are routes that you should know almost by hearth if you want to visit Bruges as a blind person. All of them start outside the city at some public transport stop, and end up at the same square (Burg Square iirc). Finding your way to Bruges entails you follow these routes as much as possible. They have tactile pavings, and are optimised to not get lost. One example is that sometimes they’ll make you take a much longer route, just so you’d end up against a wall next to the square where you can find tactile pavement to follow, instead of making you walk a shorter route with the danger of walking into the open square if you miss the tactile pavement. On crossroads it’s also important to try to get crossroads at an angle of 90°. This is typically the case, but not always.

It was pretty cool to learn these things, and I also enjoyed adding these kind of details to the map. I didn’t really continue with adding such ways, though. The thing is, with Mapcomplete, adding POI’s is easy and can be done on the road. It’s nicer to be outside in the nice weather doing some things, than sitting inside behind a PC where you could be doing other fun things too. The latter just feels more like a chore, you know. Actually, the first time I mapped shops in a town center, I didn’t use my phone for the mapping itself. I made notes and added things later on my PC. It was all very tedious. When I got a newer phone, I went to map another town center, but now did it “on the road”, and it was such a joy!

About a month ago, I was adding some things near a shrine I sometimes pass by. I’ve known about that shrine since childhood, but never actually stopped there. Mapping gave me a great excuse! I noticed there was a path drawn across the street, but the path was not to be seen. I later went back to investigate. A part of the path was completely gone, overgrown by nature, not even visible that a path ever ran there. I tried to edit it “on the road” with iD, the default editor on the Openstreetmap website, but noticed it didn’t properly worked on my phone. I asked on fedi for suggestions, and Vespucci was highly recommended. It allows all that iD allows, so it’s somewhat advanced, but should be easy enough to figure out for someone who has done some mapping in iD.

There are different things I’d like to map with Vespucci (or similar app). There’s an artwork at the old Sint-Jan hospital in Bruges I’d like to properly map. I added it as a POI now, but it’s an installation deserving of more than just a point. There’s also the square in front of the church at Zuidwege. The story goes that some great-grand uncle or something of mine helped build this church somewhere during the 1800’s, doing the wood work of the roof. This person had lived during Napoleon times, before Belgium was even a thing. And there’s even a picture of him, which is quite rare as photography was quite new back then. There’s also a history filled ex-military location in a nearby forest I’d like to map out more. I already added some POI’s, including two artworks made by high ranking German military people, generals or something, when they were imprisoned there after the second world war. But there’s more details to be added, like fences and other things that haven’t been mapped on OSM yet.

As a first try out, I mapped an artwork representing a train wagon, which was put there as a remembrance of the history of the site. I had previously added this work as a single point, but now it shows the whole size of the thing. I also moved the point for the information board inside it, where it belongs. I was a bit disappointed to see how inaccurate my GPS signal apparently is. Luckily Vespucci shows the scale, so I was able to make a good guess on where to draw things, compared to the already mapped roads and guessing the size by counting number of steps. One thing I noticed is that I can’t seem to rotate the map. This would’ve made things even better. So, all in all, I’m still not really sure yet how well this type of mapping will go, but we’ll see. Practice makes perfect and all that.

Vietnamese

*

We are happy to announce the deployment of Vector Tiles on OpenStreetMap Foundation servers and the publication of the layer on the OSM website! We have been working hard to bring you a fresh look to OSM data, paired with exciting technological upgrades.

Work has been progressing since last year. In June 2024 we shared progress, including the launch of the vector tiles demo site, as well as details on the technical background on the tools being used. Since then we have put the tile generation process through months of testing, focused on reliability and speed improvements, and gotten ready for full production use.

Now, with integration of the vector tiles as a feature layer on the OpenStreetMap website, mappers and visitors get a visual layer that is sharper and quicker, based on an entirely new backend.

A major benefit of vector tiles is adaptability, so developers can leverage this vector source to develop their own styles based on the existing Shortbread styles or write a new one and use the new OSMF-hosted tiles. To use OSMF vector tiles in a project, in a development or production environment, consult the Vector Tile Usage Policy. Note that the policy may be subject to change to address any issues that come up after this launch.

From this point, you can expect further evolution of the Shortbread spec and styles. Input on the direction, ideas, and issues with OSMF vector tiles are welcome. Share in the appropriate repository: spirit for styles, tilekiln for tile generation, and shortbread-tiles for the tile content specification.

Al Nabi Colony, Gujrat, Punjab, Pakistan Sells groceries, snacks, and daily household items. This is a physical and actively operating business.

April 15–19, 2025, proved to be a special landmark in my mapping experience when I participated in the OSM Spring Mapathon 2025, sponsored by Youth Innovation Lab. I am excited to announce that I won the Beginner Category for 22,922 map changes!

This acknowledgement is meaningful to me—not only as a personal achievement, but also as a personal reminder of my growth since first hearing about OpenStreetMap (OSM) during 2021. At that time, OSM was merely another name, still learning its way into my periphery. Little did I realize the meaning that OSM would take on as an important part of my learning and contribution trajectory.

I committed a certain amount of time each day during the Mapathon to updating map data. Anything from adding roads, perfecting building footprints, or fixing map glitches and errors. Each change adding to a sense of satisfaction that somewhere someone would benefit from finally going through something that they could map out into a community, and their community becoming visible, sharing their data.

The event itself was inspiring. While Youth Innovation Lab was the primary host, the Mapathon brought together fellow mappers from across the land, and beyond. Each day’s schedule created an exciting and competitive environment that made staying sedimentary contagious.

Though I did not expect to win the Beginner Category, I am even more so grateful. The motivation of this experience is further proof that with the appropriate due diligence, sprinkling curiosity and learning, anything is possible!

HOT#OSM#Youth Innovation Lab# OSM Spring Mapathon2025

아파트 건물의 이름을 생성할 때 어떻게 해야 하나요 1. 000동 2. 000(동 없이 숫자만)

То самое письмо:

Первые кривые домики:

Первое робкое сообщение в Telegram-чате:

И к чему это привело:

Такие дела.

한국어(Korean)

제가 방금 OpenStreetMap wiki에 계정을 만들었는데, 편집할 권한이 없다고 뜹니다. 제가 문서를 편집하고 번역을 하기 위해서는 어떻게 해야 할까요?

Translated English

I just created an account on the OpenStreetMap wiki, but it says I don’t have permission to edit. What do I need to do to edit and translate articles?

Vitima de assedio financeiro, fisico, intelectual, moral sem recursos vivendo com invasão de empresa pirata, peco desesperadamente a remoção de idoso usuário de produtos ilícitos urgente

IS_WIM_4

대충만들었어요

https://ifh.cc/v-9nv75s

Hi guys!

Quick midterm update from me! Just as a little refresher, my name is Anqi and I’ve been working on the Transliteration of Search Results project this summer.

Time has really flown by and we are at the halfway point! Here I hope to give a summary of the work that’s been done so far, as well as what I hope to accomplish during the next part of the summer! We want to be able to return the transliterated name as a field during search results, with a proof of concept shown here! We can see in this proof of concept that the results are as expected, with the addition of one transliterated name field.

{
"place_id":100067,
"licence":"Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
"osm_type":"way",
"osm_id":1307932969,
"place_rank":30,
"category":"amenity",
"type":"school",
"importance":-0.004452559995167061,
"addresstype":"amenity",
"name":"丹东市第六中学",
"display_name":"丹东市第六中学, 七纬路, 站前街道, 丹东市, 振兴区, 118000, 中国",
"transliterated_name":"Dan Dong Shi Di Liu Zhong Xue, Qi Wei Lu, Zhan Qian Jie Dao, Dan Dong Shi, Zhen Xing Qu, 118000, Zhong Guo",
"bbox":[124.3804784,40.1271951,124.3830593,40.1292045],
"geometry":{
"type": "Point",
"coordinates": [124.38176886493923, 40.12819985]
},

The general flow can be visualized as below.

One additional comment: one big issue that we have run into so far is the difference between a script and a language. The script refers to the way it is written, i.e. both Cantonese and Mandarin spoken in Taiwan share the same script, the way English and French share the same script. However, language primarily refers to how it is spoken. This is important as although some languages that share the same script do pronounce characters the same way, i.e. English and French, some do not, such as Cantonese and Mandarin. This is especially important for transliteration, as the whole point is to preserve the pronunciation of the original text.

For the transliteration process, we first take in the result as to detect what country it is from. Using Nominatim’s internal list of countries, we are able to extract the languages spoken in the country. However, this does not yet work for autonomous regions Hong Kong and Macau, as they are not recognized as countries. Further work on this (and regionalization in general) is therefore needed, which I hope to tackle later. This will also allow us to potentially venture into dialects and region-specific pronunciations further in the future.

Similar to Nominatim’s current logic, if there is only one language spoken in the result country, we take that to be the given language of the result. If not, this is left undefined and no conclusions can be made. At this stage, if there is a given singular result language and the user knows it, we know that no transliteration is necessary and our new transliterated name field will just be the default name.

If the user does not know the language, or if there are multiple languages spoken in that country, we then move on to the second stage: localization. From the given name tags for a result, we try and return the best matching name from a dictionary of names containing different name variants, as well as an identifier with regards to what language used. This is slightly different from how display names are currently returned, due to the presence of a secondary return value. From this new function, we also set a new field which allows us to determine if we are in a user-understandable language. This is important as previously localization just assigned a name, but if no valid names were present, it would just default to the country default.

After this, we know that the result is not in a user-understandable script if both

• The user does not know the result country language, or if there are multiple languages spoken in that country

and

• There are no name tags at present in a user-understandable name, forcing the address component to still be in the default value.

From here, we can finally proceed with transliteration. For transliteration to any Latin-based script, we use the unidecode library. We can detect if the user knows any Latin-based script or not with a newly created list of languages, in which I have included all two letter ISO 639 codes (which can be found here) as well as the tag yue, for Cantonese. This list acts as a dictionary to see if the language has a Latin-based writing system or not, and also contains the full name of the language and a sample excerpt of the script, if available. The transliteration function will go through the list of user languages in an ordered fashion, targeting the users highest preferred languages first. This means if a user has English, Chinese, Arabic as their list of languages, transliteration will always be to a Latin-based script.

You might be wondering, what about transliteration to any non-Latin based script, what then? Well, due to the variety of tones and characters and inflections in many non-Latin languages, transliterating to their script is actually very difficult. For example, using Chinese to transliterate even the word “Normal” might result in 10 different iterations. However, we do want to provide support for this, creating a pluggable interface for future development. Therefore, for every language the user knows, not only do we check if the script is Latin-based, but we also check if we have a way of transliterating to that language. Currently, we have examples of this for Cantonese, Traditional Mandarin, and Simplified Mandarin.

The final part for this is actually understanding what languages the user does know. This is actually taken from the browser information, similar to what Nominatim currently does. However, if you have worked with browser codes before, you know that normally it is not just a nice two-letter code; the browser also tries to add some region-specific language identifiers such as en-US and en-CAD. To preserve regional locales, but remove general duplicates, we firstly preserve the ordering of the ‘importance’ of the language to the user due to its weighing, then upon the first instance of a non-generalized language code, add the generalized form directly after. This also allows us to normalize languages when needed, which is especially important for the case of Chinese, which spans Simplified Chinese script in a spoken Mandarin form, Traditional Chinese script in a spoken Mandarin form, and Traditional Chinese script in a spoken Cantonese form, and identifiers that can leave what the user actually understands unclear. Therefore, in the case of ambiguity, the largest number of languages will be added, which means that while zh-tw will only map to zh-Hant, zh could map to any of zh-Hans, zh-Hant, or yue. The normalization code can be found here.

Thank you guys so much for reading! Please leave any feedback if you have any!

Realizadas pequenas edições como número de casas, criação de edifício em vila sônia e local de interesse mercado dia também em vila sônia.