OpenStreetMap

Users' Diaries

Recent diary entries

On September 26 IHE Delft and the Humanitarian OpenStreetMap Team organized a mapathon to map the areas affected by the earthquakes in Morocco and the floods in Libya.

Many new mappers attended the mapathon. We collectively uploaded 813 changesets containing over 50.000 total map changes in the span of only 3 hours.

Map displaying the changesets in Libya that were uploaded during the event. Map displaying the changesets in Morocco that were uploaded during the event. You can find this interactive map here.

I heavily recommend anyone in the area attends one of these mapathons. Everyone is welcome, and you don’t need any mapping experience to participate. They’re also a good opportunity for those of you that already have mapping experience to teach new mappers! But just in case any of you are still not convinced, there’s free soda. :)

Media

Image of classroom where attendees met before the mapathon. Image of classroom where attendees met before the mapathon. Image of mappers at the mapathon. Image of mappers at the mapathon. Group photo taken at the end of the mapathon. If you would like to be blurred in any of these images please send me a message through my OSM profile.

Location: City Centre, Delft, South Holland, Netherlands, 2611, Netherlands
Posted by Реdактор on 29 September 2023 in Russian (Русский).

Я достаточно долго слежу за Open street map и участвую в развитии проекта, раньше я крутил пальцем у виска когда слышал от других участников: вот бы всё стереть и с нуля начать рисовать карту, но время идёт, и теперь в 2023 я это мнение полностью поддерживаю

Location: Северская, Северское сельское поселение, Северский район, Краснодарский край, Южный федеральный округ, 353240, Россия

Zoning

What:

Some stations divide its platforms in zones. You have in general two types of zoning (I call those two types) general zoning and specific zoning platforms. On general zoning platforms you will find panels A B etc. besides the platform number. Often you will even see those numbers reoccur multiple times on a specific platform. On specific zoning platforms however you will find panels like B2, B1, A1, A2 and those are uniquely placed along the platform.

Location of object in OpenStreetMap:

A station zoning signal is mapped as a point that is placed on a edge of a platform (polygon).

Tagging in OpenStreetMap:

  • railway=platform_marker
  • ref=A2 (I use for general zoning: track number and than the letter (ex. 2A) while for specific zoning I just put the zoning like A2).
  • level=1 (Look at the level value in the platform object, if none present you don’t need to add this.)

Rail signs

egzjb

Signals

signals efhlez

direction: Blickrichtung vs. Geltungsrichtung

Das folgende steht im deutschen Wiki: “Die Tags direction=forward und direction=backward sind nur für Knoten gedacht, die zu genau einer Linie gehören. Stützt der Knoten mehr als eine Linie, wären diese Angabe mehrdeutig. Dann sollten Himmelsrichtungen für direction=* verwendet werden. Hinweis: Bitte die gegensätzlichen Bedeutungen bei der forward/backward (Geltungsrichtung) und bei Himmelsrichtung (Oberflächenrichtung) beachten.” Quelle: https://wiki.openstreetmap.org/wiki/DE:Key:direction

Upps, diesen Hinweis im Wiki habe ich übersehen: Gut dass mich ein anderer Mapper auf meine systematischen Falscheingaben freundlich aufmerksam gemacht hat und er und ich mit Hilfe von https://overpass-turbo.eu/s/1B5L (Danke an den aufmerksamen Mapper) wenigstens viele von mir gemachte Fehler mit relativ viel Arbeit wieder korrigieren konnte (ganz durch bin ich damit aber noch nicht). Das passiert, wenn man mit dem Lesen der Beschreibung zu früh aufhört, oder meint, man hat nach Jahren OSM-Mapping schon genügend Erfahrung. Ehrlich gesagt, habe ich das Wiki auch erst mehrfach lesen müssen, um diese scheinbare Widersprüchlichkeit zu verstehen.

Es gibt also eine tückische Fehlermöglichkeit beim Mappen von Vorfahrtszeichen, da mit direction zwei grundsätzlich unterschiedliche und zudem gegensätzliche (!) Eigenschaften beschrieben werden.

Geltungsrichtung

1.) Bei Verkehrszeichen wie highway=stop oder highway=give_way ist die übliche Methode, mit direction=forward bzw. backward in Bezug auf die in OSM angegebene Richtung der Straße die Richtung anzugeben, in der gefahren wird, damit das Schild gilt. bzw. “The directions forward and backward can be used to specify the direction of a feature relative to an existing way. This only applies to features which are tagged on a node that is part of a way. Examples may include directed traffic signs.” Quelle: https://wiki.openstreetmap.org/wiki/Key:direction Nutzung: m.E. wichtig z.B. bei Navigationsansagen

Blickrichtung/Himmelsrichtung/Oberflächenrichtung

2.) Bei Angabe einer Himmelsrichtung z.B. mit direction=E (Ost) dagegen wird die Himmelsrichtung angegeben, in die das Schild blickt, und das ist üblicherweise natürlich entgegengesetzt der betroffenen Fahrtrichtung (hier: West): “Note that traffic signs traffic_sign=* are tagged the way the sign faces, i.e., against the direction of travel. For example, when travelling west, signs are facing east, so you tag them with direction=90 or direction=E.” Quelle: https://wiki.openstreetmap.org/wiki/Key:direction bzw.: “Bei einem Verkehrsschild wird dessen Oberflächenrichtung angegeben, die Geltungsrichtung liegt um 180° versetzt dahinter.” Quelle https://wiki.openstreetmap.org/wiki/DE:Key:direction Nutzung: Diese Sichtweise orientiert sich m.E. an Eingaben für die 3D-Ansicht.

Vielleicht fragt sich jemand, warum ich überhaupt begonnen hatte, die Himmelsrichtung statt forward/backward einzutragen: Ich war zu faul, beim Eintragen mit dem erstklassigen Vespucci jedesmal nachzusehen, in welche Richtung der betroffene Weg eingetragen ist. Außerdem dachte ich echt, das wäre weniger fehleranfällig…. (Aus wiki: “Manche Editoren könnten den Wert für direction=* an Knoten, die Teil eines Ways sind, missachten, wenn man die Richtung des Ways umkehrt. “). So kann man sich irren. Außerdem hatte ich an einigen Stellen versucht, nodes zu sparen und die Verkehrszeichen auf existierende nodes auf Wegen zu setzen, wobei z.T. 2 ways mit entgegengesetzer Richtung auf einem node zusammentragen (da kann man kein forward oder backward eintragen, siehe oben, allererster Satz)

Auch wenn ich offenbar einer der wenigen bin, die darauf reingefallen sind: vielleicht ist dieser Hinweis ja hilfreich. Laut Wiki gibt es auch noch andere Signale etc., für die das relevant ist.

PS: So habe ich mich erstmals mit dem OSM-Nutzerblog und mit overpass turbo beschäftigt. Scheint echt ein klasse Tool zu sein, und scheint für jemanden, der wie ich mit Logik und Programmieren bereits Erfahrung hat, nicht übermäßig kompliziert in der Anwendung zu sein. Beispiele wie das oben verlinkte helfen aber dabei enorm.

Right! I finally started using OpenStreetMaps.

Thanks to a friend who pointed me to Magic Earth I now have a viable navigation system which uses OSM data and thanks to StreetComplete I am slowly learning about tagging. The multiplicity of apps is not ideal, but a staged approach to OSM concept is clearly necessary. My previous attempts to become an OSM users failed because I was overwhelmed by complexity or perhaps I should say expressiveness.

In the foreseeable future I will be just using StreetComplete to improve my local area, but I am already seeing some issues that require more in-depth changes. Also, there are some edits that I have already submitted, but after reading the wiki I do not believe them to be accurate any more.

Here are a few topics I need to chase:

  • terraced houses - the terraced houses in my area are all lumped together. They are not divided up, so assigning numbers requires usually a comma separated list. I would like to fix it and break the rows into single terraced houses with one number each.
  • I need to figure out how to mark multiple buildings belong to a school or a care home for elderly.
  • terraced bungalow houses - I am guessing they are terraced houses as bungalow definition clearly states detached. My area has many rows of single storey houses
  • I may have messed up some bollards by marking them as fixed, whereas in fact some are removable with key. Will need to keep an eye on this and maybe learn to use Vespuchio to fix those in the future.
  • Sometimes I am not entirely sure whether a road is asphalt or concrete with some coarse aggregates inside. I was assuming it’s asphalt as that’s what we typically put, but maybe I should take some photos and asked someone who knows better.

natural=scree, natural=shingle, natural=blockfield

돌비알(scree;talus)

  • Something like a rock, built up almost exclusively by weathering and crumbling.
  • They build up as they are swept away, creating a steep slope.
  • The stones that make up the talus are generally small or variable in size.
  • Even if the stone masses are large, they are often sharp because they have not been worn down much.
  • scree’ in Wikipedia 돌비알

자갈밭(shingle)

  • A stone, or rock that has been chiseled, rounded, and piled up by being swept down by a force such as a torrent.
  • Because they are worn down by being swept away, they are usually not very large and are not angular.
  • Usually small in size, but sometimes large, depending on the force of the scouring. 자갈밭

너덜겅(blockfield;block field;boulder field;stone field;DE:felsenmeer)

  • A long period of volcanic or glacial activity that has finally left a pile of rocks.
  • Sometimes moss or herbaceous vegetation grows on them (e.g.: Gotjawal, Jeju, South Korea). What makes it different from a regular forest is that its herbaceous plants are not rooted in the ground, but in the crevices of rocks, and grow nourished only by rain and peat(something like a plant is not fully carbonized).
  • blockfield’, ‘stone run’ in Wikipedia 너덜겅
Posted by valhikes on 27 September 2023 in English (English).

Once upon a time, I was asked why I had only marked the south end of a trail and not the north end.

Well, I said, I haven’t been there, so I don’t have a GPS track. All I have is that USGS line and the one thing I know about it is it’s wrong. As long as it isn’t mapped, someone will be more likely to put down the correct line when they do want to map it. They might not even notice it’s needed if a bad line is there.

Then I said I might come down on the side of mapping everything you can as best you can sometime later.

Well, it’s later. Now I say map it all! And put down the source as you do it. Not just in the changeset note, but actually on the segment. And it can be good to make a guess about trail_visibility. I have more tools now.

Strava heatmap is the best as an average of GPS signals, if you can get it. I have found what is probably the firefighter loop through nearby private lands and not actually available to the public as a hike on there. It looks like a nice loop out there in Kneeland where there’s no public hiking. Only the most popular trails have enough heat to be an average. A random spattering of others have some kind of clues.

I can download system trails from the Forest Service’s data clearinghouse. Most of these match the Forest Service Topo (another source), but some have updated. Some of them match the USGS lines. Okay, a lot. And apparently Six Rivers has no system trails at all. They are seriously slacking. (And now a section of their roads has vanished from the Interactive Visitor Map. What is wrong with you, Six Rivers?)

And there’s ever more imagery. Sometimes it’s just visible. All the other lines available helps to differentiate the actual bit of trail from random fallen trees that make a line on the ground. A ridge trail might have a fuel break competing with trail, so there are plenty of bad signals just looking at photos. Down the gully, that might be just water course. Or trail. Or both.

So I’ve been working my way through the roads around the Trinity Alps Wilderness and some areas around Marble Mountain Wilderness and now the trails are going in. (I think I’ve got all the roads on the north side, west besides the reservation, and southwest sorted through.) I’ve just about got all the system trails in. Got a few things from USGS. Will have to ask Chris about his Orleans District trail maps. Shasta-Trinity has decided to usurp the Salmon Summit name for a bit that isn’t Salmon Summit while Six Rivers, where the National Recreation Trail actually goes, sits there without trails. There’s some “footpath” marked stuff that needs adjusted. Footpaths are for more developed trails than generally found in a designated Wilderness. Still lots to do.

Oh, and those trailhead parkings 200 feet inside the designated Wilderness? Mapping that as is. Ground truth!

Location: Trinity County, California, United States

In the previous episode

We finally managed to tackle a very popular feature request: datalayers’ fine-grained permissions 🎉. This is a huge step forward, allowing for a given map owner to only open a particular datalayer to edition. It will help people with contributive maps who need to setup a stable/fixed base layer. It also paved the way for even more control over the objects that are allowed for addition and/or edition. Please share with us your desired workflows.

Two datalayers with different permissions

On the UX side of the project, we made a couple of adjustments and fixes to make the editor more intuitive and consistent. Do you see these new crispy icons on the screenshot above? Hopefully it will bring more users, hence more contributors! A couple of new faces jumped in recently and we’re so happy about that 🤗.

You can also look up for icons by name in the ‘Shape properties’ panel, one of our next steps will be to ease icons’ management and additions, another long-awaited feature:

An example of icons search

We receive a lot of feedback (and bug reports) from the OSM France forum too which definitely helps us to improve the product in terms of user experience and to prioritize the roadmap. If you are working for the French public sector, do not hesitate to reach out and share your experience.

Stay tuned for the next additions, a brand new API is coming! We’ll be at the NEC - Numérique En Communs event (Bordeaux, France), on October 19th and 20th. See you there for more news and announcements!

Posted by Mitsjol on 26 September 2023 in English (English). Last updated on 27 September 2023.

Hi, I’m Mitsjol.

I’m still pretty new to the world of OpenStreetMap and this is my first diary entry here. Currently, I’m primarily focused on adding details to my charming hometown of Middelburg.

Recently, I stumbled upon a millstone in my hometown. This millstone, a large round stone once used for grinding grain, caught my attention and I wanted to add it to OSM. However, when I tried to add it to, I faced a challenge - there was no fitting tag to accurately represent it.

This got me thinking. How many other millstones around the world are missing from the map simply because there isn’t a dedicated tag for them? There must be a lot, because I’ve also seen them during travels. For instance, in the UK’s Peak District alone, there are estimated to be around 1,500 millstones scattered throughout the landscape.

So I took a significant step in contributing to the OpenStreetMap community by proposing the addition of a new tag - “historic=millstone” on the OpenStreetMap Wiki.

I decided to use “historic=millstone” as the primary tag, although I considered “man_made=millstone” with an optional “historic=yes” tag as an alternative. However, I believe that “historic=millstone” is more accurate and relevant for the majority of millstones that we encounter on the map. Not many new millstones are made in this day and age.

I provided examples from various parts of the world to illustrate the diversity and ubiquity of millstones. From Ireland to Japan, these stones can be found all over the world.

Some examples of millstones around the world.

The next step is to wait for comments and feedback from the OpenStreetMap community. I know it’s essential to address any concerns and fine-tune the proposal if necessary before moving on to the voting phase. Please take a moment to visit the Discussion page on the wiki and share your thoughts.

Thank you!

Location: Binnenstad, Middelburg, Zeeland, Netherlands

In Croatia some residential areas are well kept, while others are quite lacking. Example: Zadar vs Preko.

What to map?

This begs the question which entity should be mapped first with the largest gain for the effort? This can only be answered in the need of the beholder. For a tourist it would be street names, since accommodations are bound by an address and after the town name, the street name is the next factor to reduce the search area of the location.

There is a major requirement for this to fruition and that is that the town has to have varied street names. Depending where in the country one is traveling, it is quite typical that the street names are equal to the town’s name (e.g. Lazina). In such a situation latitude/longitude coordinates should be a requirement of the host to provide over the house number, because lots are not linearly arranged. Plus lots of such towns don’t have house numbers and/or buildings on the map.

Where are the buildings?

Lots of towns have buildings, though these are usually only a fraction of what actually exists. E.g. in Preko:

OSM data in JOSM depicting the lack of buildings mapped although the aerial imagery shows otherwise in Preko

Additionally, if the town has narrow pedestrian zones, one can expect that lots of buildings are missing and/or misaligned. e.g. in Komiža:

OSM data in JOSM depicting the misalignment of buildings in shape in Komiža

Narrow street in Komiža

Narrow street in Komiža

Mapping such towns are tricky without good aerial imagery and it might worth the investment to get a drone for such scenarios.

How to help map such towns?

GPX/GPS tracks and notes with street names help greatly. Notes can easily be made and shared on StreetComplete/SCEE. One should add the start of the street and at least take a picture of street name sign, if one is not willing to type it out.

Personally, I try to add the highway value and the compass direction to the note. This helps when the aerial imagery is to get an approximation of its presence on the map. E.g. in Komiža:

A set of notes in Komiža to help with street directions and names

Hint:

Change the keyboard layout to the language at hand, so in Croatia it would be Hrvatski. This eases the pain of getting their special characters.

What’s with Wikipedia?

Lots of the entries do not exist in the native tongue (e.g. Hum and plenty more do not exist in English (e.g. Žena Glava translates to wife’s head).

Tried to do site seeing via its information and was disappointed when the promised wasn’t there (e.g. Califfi Castle).

POI and existing data quality

To my surprise there was a good chunk of existing data with e.g. surface information of the roads or if benches have backrests. This is good news and most likely OSM’ers were there on holiday and maximised their StreetComplete contribution. So if more entities existed, data coverage could be quite quickly covered over the next couple of tourist seasons.

The interesting part of the POIs is that they were denoted in the native tongue of the mapper e.g. French or Hungarian and rarely in English.

Next steps

The next steps would be:

  1. Get the data on which towns see the most tourists.
  2. Go through the list and see what is the highway coverage, map ideally all roads.
  3. Go through the list and see what is the building coverage, map buildings around the main market square first.
Location: Komiža, Grad Komiža, Split-Dalmatia County, 21485, Croatia

Abstract

Most GPS navigation systems today rely heavily on street names and place names for route guidance. While this works well in some situations, it can be confusing and less user-friendly, especially when navigating unfamiliar areas or for people with language barriers.

This project aims to change the game by introducing landmark-based navigation into Valhalla, the OpenStreetMap (OSM) routing engine. Instead of hearing complex instructions like “Turn left onto Obmannamtsgasse,” users will get simple and intuitive directions like “Turn right at the Tesco supermarket.” This landmark-based approach makes navigation more accessible and user-friendly, reducing stress and improving the overall experience.

The high level implementation overview of this project is available here

Landmark Based Navigation Project - Github

Now let’s dive into the details!

Implementation Details

In simple terms, this project enhances Valhalla’s routing capabilities by bringing in landmarks as navigation support. We pull Points of Interest (POIs) from PBF files and store them as landmarks in a special intermediate storage. Then, we associate them to the map’s edges and store them into graph tiles. When clients call Valhalla services, these landmarks become part of the route directions and make navigation easier.

About Landmark Itself: Data Source and Selection Criteria

POIs are naturally supported in OSM PBF Format (“Protocolbuffer Binary Format”), a sort of digital map format. OSM uses “tags” in the form of “key=value” to describe places and things on the map. One special key, “amenity”, helps us find places that are useful or important for folks like visitors and residents. We use this key to select landmarks.

To pick the best landmarks for navigation, we look for ones that are clearly visible, very specific, easy to distinguish, and easy to understand. You can dig into the nitty-gritty analysis here. Based on these criteria, we’ve selected 18 types of POIs as landmarks. These include places like restaurants, gas stations, banks, clinics and more – all things that come in handy when you’re on the road.

Milestone 1: Setting up an Intermediate Storage for Landmarks

Now that we know where and how to select landmarks, we need to build a storage space to store them. Following Valhalla’s conventions, we opted to build a separate SQLite database to serve as the hub for storing landmarks data. This database was designed with a straightforward schema which consists of an id, landmark name, landmark type, and geographical coordinates represented by longitude and latitude. Spatial index is added to support and optimize spatial queries.

Database interactions implemented include classic putting and fetching. We also made sure to support spatial queries - getting all records in a given bounding box, i.e. getting all landmarks that are located within a defined geographic rectangle.

Landmark Intermediate Storage PR1 - database

Landmark Intermediate Storage PR2 - interaction

What’s cool is that we used the C++ pimpl idiom to implement our landmark database API. It is a powerful one especially for API design, allowing the designer to offer up the API interface without exposing the implementation details, effectively giving the API a private implementation.

Landmark Intermediate Storage PR3 - pimpl

Milestone 2: Parse Landmarks From Data Source to Intermediate Storage

With a designated storage now in place, our attention turned to the task of parsing landmarks from their data source, namely the PBF files. We confronted a design decision concerning the parsing process: whether to embed it within the tile-building pipeline or to develop a separate process capable of enriching an already established graph tile when necessary. We went with the second option because it gives us more flexibility for both testing and execution, especially since this is a prototype for a major feature.

“valhalla_build_landmarks”, the separate executable we build, is capable of extracting and parsing POIs from OSM PBF files and storing them as landmarks in the landmark SQLite database.

Landmark Parser PR

Milestone 3: Enhance Tile Storage to support landmarks

Once we’ve gathered all the data on landmarks, the next step is to incorporate this information into the graph tiles that actually fuel our routing system. To make room for landmarks, we made updates to the data structures within these graph tiles. Specifically, we tweaked the edge info data structure to accommodate associated landmarks which are encoded and stored as tagged values.

It’s worth mentioning that it took us some time to find and resolve the problem caused by null bytes. It’s also one of the triggers why we refactored the edgeinfo.cc file.

Enhance Tile Storage to Support Landmarks PR

Milestone 4: Associate Landmarks with Edges and Add to Tiles

The challenge at hand is how do we decide which landmarks should be paired with which edges. It is not so straightforward given the fact that all we have is the graph tiles and a database that contains all landmarks, relevant and irrelevant ones. Here’s how we cracked it: First, we pinpoint the area of interest on the graph tile and fetch all the landmarks within that zone. Then, for each landmark, we call Loki::Search to locate nearby edges. We make these search results into pairs, with each pair consisting of an edge ID and a landmark ID. Once we’ve got this sorted, merge and sort these pairs by edge ID. This step reveals which landmarks should be associated with each edge. Finally, we update the graph tiles to store these associations between edges and landmarks in the edge info.

As both searching for correlations between landmarks and edges and updating graph tiles involve substantial amounts of data processing, we’ve designed some mechanism to distribute workload evenly across threads in both cases. One more thing: updating graph tiles is much trickier than generating new ones. It requires an in-depth understanding of the data structures nestled within the tiles, and involves a great deal of manipulation on edge info offset. Currently, we are updating these offsets in an effective yet somewhat slow manner, which unfortunately introduces a performance bottleneck. Hopefully we can find a way to optimize it in the future.

Update Tile Storage to add Landmark Associations PR

Milestone 5: Update maneuver generation to add landmarks

In the navigation world, a “maneuver” refers to a specific action or instruction that a driver or traveler needs to perform at a particular point along their route. These maneuvers can range from turns and merges to exits and more. Think of them as your GPS’s way of saying, “Hey, make a right here!” In this milestone, we updated the maneuver generation process where a routing result is built into user-facing maneuvers, allowing landmarks to come along together.

Although route results coming from the routing service already include landmark data, we feel it’s not enough. So, we went the extra mile by incorporating additional information. This includes the distance from each landmark to the maneuver point and whether a landmark was on the same side of the road as the maneuver direction. The former is pretty intuitive - using the closest landmark to the maneuver point leads to better direction support. The latter means if the maneuver is to turn left then we should use some landmark on the left side as well, and vice versa. It is particularly handy when a traveler encounters wide urban streets or in case something blocking sights.

We managed to get these two additional pieces of information, and updated our Protobuf to handle the new data structure in maneuvers. Now, every maneuver comes with landmarks which have information about name, type, longitude, latitude, distance, and even which side of the road the landmark buddy is on.

Update Maneuver generation PR

Time to step into the last milestone!

Milestone 6: Update narrative generation to add landmark support

In Valhalla, the narrative generation process converts maneuvers into human readable text. Our final goal in this milestone is to introduce landmark-based phrases into specific instructions. To achieve that we fine-tuned the narrative generation process to support phrases that incorporate landmarks. We then added these phrases to support landmark replacements, specifically in the English locale, for certain instructions including “turn”, “sharp”, “bear” and “uturn”. We even took linguistic nuances into account when crafting these new phrases.

As a result of the last milestone, landmark-based navigation reached its full functionality. Travelers can now receive routing instructions like “Turn left at the supermarket Kaufland” or “Make a sharp right onto Bahnhofstrasse at the bank Credit Suisse.”

Update narrative generation PR

Future Improvements

Even though we’ve made significant progress in the feature of landmark-based navigation, this is just the beginning, and there is still room for enhancements in both design and technical aspects. Here, we highlight some key areas for potential improvements, and you can find more detailed tasks marked as “TODO” in our code base.

Design choices

  • Optimal Landmark Association Distance

One question to consider is whether our current 75-meter cutoff for associating landmarks with edges is ideal. This distance acts as a strict boundary beyond which landmarks are not going to be correlated with any edges. While this helps reduce interference and enhances guidance, we should consider whether it’s too restrictive or too lenient. Besides, introducing a user-configurable option for the cutoff distance could provide more flexibility.

  • Expanding Landmark Selection Criteria

Currently, we focus on the “amenity” key when parsing landmarks from PBF files. However, there are other key-value pairs that contain valuable information. For instance, the “historic” key with a value of “monument” could be particularly useful for guidance, especially when the landmark has a descriptive name. Expanding our criteria for selecting landmarks could enhance the user experience.

  • Handling Different Landmark Types

Among the 18 types of landmarks we’ve chosen, some are uniquely identifiable by type alone, while others require both type and name for clear recognition. For instance, in urban areas, it’s common for multiple restaurants to be clustered together. In such cases, combining the name and type of the landmark is crucial for unambiguous navigation instructions. We’ve analyzed each landmark type (see comments in the code) and need to devise strategies to implement these analyses for an improved user experience.

Technical details

  • Batch Retrieval for Landmark Database

We’ve implemented batch retrieval, dynamically generating query statements based on input size. However, this feature isn’t currently utilized in our code. To boost processing speed, it would be beneficial to support fix-sized batch retrieval and use it for landmark retrievals during tile updates.

  • Fetching Landmarks with Level 2 Tiles

Currently, we rely on bounding boxes from level 1 tiles to fetch relevant landmarks. However, these level 1 tiles are not always available. In cases where only level 2 tiles cover a region, we should still be able to access landmarks. Implementing this feature would ensure comprehensive landmark coverage in various scenarios.

  • Accelerating Graph Tile Updates

Updating graph tiles to incorporate landmarks, as opposed to generating entirely new tiles, presents some challenges. Specifically, optimizing the update process for the edgeinfo_offset_map, which is an unordered map, is crucial. Our current method, while effective, can be slow. Investigating performance enhancements in this area would be valuable.

  • Thread Balancing for Tile Updates

An associated challenge with tile updates is balancing thread workload. Since updates involve moving entries one by one, the workload isn’t solely dependent on the number of edges or landmarks; it also considers the location of edges within the entire unordered map. This makes it challenging to predict and balance threads in advance. Addressing this thread balancing issue is critical, as it has a significant impact on performance. A holistic optimization approach for both the graph tile update process and thread management would be great.

Acknowledgements

This is my first time contributing to an open source project and participating in a large-scale C++ project with real world data. I would like to express my sincere gratitude to both of my mentors Kevin Kreiser (kevinkreiser) and Nils Nolde (nilsnolde) for their amazing support, helping me when I was confused, guiding me when I was lost. As a toddler in the open source community, I would always remember the discussions we had, the pair programming we did, and the bugs we debugged together.

Contributing to Valhalla has been a fantastic learning experience. I’ve dived deep into modern C++, data structures, algorithms, and geographical information systems. I’ve gained a profound understanding of how to operate within the context of a large-scale project. Beyond that, I am surprised to find and deeply captivated by the remarkable versatility of Valhalla and how its implementations enable such adaptability. I’m excited to keep working on the landmark-based navigation feature, hoping it will eventually make life easier for folks like me. This is just the beginning, and I can’t wait to see where it takes us!

References

Tag, taginfo, key value pairs in OSM data

A detailed document of directions with landmark support in Valhalla

Improvments and bugs in this feature

Location: Hochschulen, Altstadt, Zurich, District Zurich, Zurich, Switzerland
Posted by petrusko on 24 September 2023 in French (Français).

Tracé du parcours de “Les Cortots” à Fontaine-lès-Dijon

Par ici https://www.openstreetmap.org/way/1210508694

Mais toujours pas visible sur la carte OSM… :’( Peut-être un jour… il y aura une mise à jour qui permettra aux visiteurs de voir ces informations…?

Parcours de disc golf Les Cortots

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

Parcours de disc golf Les Cortots - une corbeille

Parcours de disc golf Les Cortots - une corbeille

Parcours de disc golf Les Cortots - une corbeille

Location: 21121, Bourgogne-Franche-Comté, France métropolitaine, 21121, France

Why and How I Mapped all the Landcover in Belize

I joined OSM in 2016 when my friend suggested I do something useful. He knew I was interested in geography as I was trying to map on Google. But then a year later Google shut down mapping for users because of an Android pissing on Apple incident in Pakistan.

I then became really interested in OSM and started mapping. I had a desire for all the landcover to be mapped. I first started around my town of Spanish Lookout, then decided to do my entire district of Cayo.

It was slow work, but I persevered. After I completed the second and third districts of Stann Creek and Toledo, I learned a few tricks of mapping. By that time it was the year of 2022. The mapping tips I learned were so useful that by September of 2023 I had completed the other 3 districts, Corozal, Orange Walk and last of all Belize district.

There were a few other mappers that helped, but I did roughly 92% of the entire country. And in that time I would estimate that about 99% of roads and 97% of buildings have been mapped as well.

Going Forward

Going forward I’m planning on keeping the country up to date and continuing to map all buildings, power lines, speed bumps, etc.

And also I’m thinking of mapping all surrounding districts of Mexico and Guatemala, which we’ve started already.

Percentage of Landcover in Belize

TypeArea Sq. Km.Percentage
Wood/Forest14,81364.5%
Meadow/Grassland2,36610.3%
Wetland1,4706.4%
Scrub1,3816.0%
Farmland1,0534.6%
Water7823.4%
Orchard2951.3%
Residential/Ind/Com2241.0%
Beach/Sand20.0%
Location: Gnadenfeld, Spanish Lookout, Cayo District, Belize