Mapping over 42,000 Alpine huts, bivouacs, and peaks presents a unique technical challenge: many locations share the same name, such as 'Jagdhütte' or 'Rosskopf'. To solve this, biwak.info implemented a hierarchical slugging system that generates unique, shareable URLs while ensuring that once a link is published, it remains functional even if the underlying geographic data changes.
This is a portrait of the developer responsible for the technical implementation of the slug registry.
The Challenge of Non-Unique Alpine Names
In Alpine geography, names repeat frequently across different valleys. For example, the name 'Jagdhütte' appears in 70 different locations. Using a simple name-to-URL mapping would result in collisions, where a single URL like /p/jagdhuette could only point to one of those 70 spots.
The developer measured the impact of different naming suffixes and found that adding a country name provided little help, as most duplicates occur within the same country. Adding a region roughly halved the number of duplicates, but elevation data was required to resolve the majority of remaining conflicts.
Hierarchical Slug Generation Logic
The system follows a specific order of preference to generate the shortest unique slug. It first attempts the plain name; if that is taken, it appends the region; if still taken, it appends the elevation; and as a final resort, it appends the unique OpenStreetMap ID.
To determine the correct region, the system performs a point-in-polygon lookup using simplified Natural Earth boundaries. If a location falls outside a polygon due to simplified borders, the system identifies the nearest polygon to assign the correct regional suffix.
The process is automated via a generator that yields candidates in order of preference. This ensures that a place like 'Rosskopf' in Tyrol becomes /p/rosskopf-tirol, while a more specific location might become /p/rosskopf-tirol-2257.
Ensuring URL Stability via a Registry
A significant risk in dynamic data systems is 'slug drifting,' where adding a new entry causes an existing entry to change its URL to accommodate the new data. To prevent this, biwak.info maintains a committed slug registry that maps every issued slug to a specific OpenStreetMap ID.
The registry follows three strict rules: a slug in the registry never moves to a different place, a place keeps its registry slug as long as it still fits its current name, and new or renamed places receive the first available candidate from the hierarchy.
This architecture ensures that even if a second 'Matterhorn' were added to the source data, the original 'Matterhorn' would retain its /p/matterhorn URL, while the newcomer would be assigned a suffixed slug.
Trade-offs and Limitations
While the system prioritizes readability, it cannot guarantee a fully human-friendly URL for every location. Currently, 458 places require an OpenStreetMap ID in the slug because they share a name and lack elevation data in the source records.
The registry is a growing file that maps every slug ever handed out. Because it is a sorted JSON file, any changes to the slugging rules—such as the developer's switch from 'u' to 'ue' for German umlauts—result in a readable git diff that allows for easy auditing of thousands of affected URLs.