onthegomap
[FEATURE] Add utility to abbreviate road names
When implementing the basemap layer, I did not port road name abbreviations from https://github.com/giggls/mapnik-german-l10n because of the licensing and just pass road names from OpenStreetMap directly. This is not ideal because clients like MapLibre won't show labels on a line if we can't fit the entire string, so overall shorter label names will increase label density.
I think it would be best to abbreviate all road names (not just long ones), for example:
| Input | Output |
|---|---|
| Park Avenue | Park Ave |
| Northeast Boulevard | NE Blvd |
| East 61st Street | E 61st St |
| First Street | 1st St |
| South Park Street | S Park St |
| South Street | South St |
Planning to use https://github.com/Project-OSRM/osrm-text-instructions/tree/master/languages/abbreviations as a starting data source (other possibilities from OpenCageData address formatter and geocoder-abbreviations but search-specific datasets will likely be too aggressive)
Subtassk to build/test:
- [ ]
(coordinate) => (admin level 2/admin level 4) or (adm2/adm4)[]- this will support pluggable datasets (natural earth, overture division areas) to choose a resolution and POV and fall back to country-coder geojson files. It will also be usable for profiles to get the country/region for a feature for other purposes besides abbreviation - [ ]
(element, country, region?) => language or languages[]to infer what language anametag is based on its location and other tags on it - [ ]
(name, language, country?, region?) => abbreviation- that applies rules to a name based on that language
mapnik-german-l10n doesn’t produce very good results in English because it has to avoid stepping on the toes of the French abbreviation code and also abbreviates words out of context (e.g., “Court Street” becomes “Ct Street”). I’d imagine it would be straightforward to write more robust abbreviation code from scratch. Ideally, the abbreviator would know the country that the feature is in, allowing it to make language-specific assumptions about name and perhaps avoid abbreviating a French name in France that was copied to name:en.
/ref openmaptiles/openmaptiles#1360
Some possible data sources:
These projects have different use cases, so they apply different inclusion criteria. The abbreviations in OSRM Text Instructions are used by the Mapbox Directions API, which tags words in name or destination with potential abbreviations that the Mapbox Navigation SDK can progressively apply[^navigation] until the text fits the allotted space. Priority is given to directions abbreviations, then classifications abbreviations, then abbreviations abbreviations in a last-ditch attempt to make the text fit.
Mapnik has a similar ability to progressively abbreviate labels, but as you’ve noted, MapLibre does not yet have this capability. If you use OSRM Text Instructions’ abbreviations without progressive abbreviation, avoid the abbreviations table, which would make the results look desperate but probably wouldn’t salvage many labels of borderline length.
[^navigation]: This is a link to the last open-source version of the code in question.
Thanks for the feedback @1ec5 ! Of those 3 options above, I was leaning towards geocoder-abbreviations since it includes things like "one" -> "1" and "fifteenth" -> "15th" with something like: point -> country -> default language for that country -> tokens file for that language. Do you foresee any issues going that route? Or alternatively are you aware of any other better data sources to power these kinds of abbreviations?
geocoder-abbreviations is more comprehensive; however, it doesn’t distinguish the more aggressive abbreviations from the less aggressive ones. You’d need to be careful about applying abbreviations only to words that are unlikely to be the base name, so that “South Park Street” would get abbreviated as “S Park St” rather than “S Pk St”, which wouldn’t be very recognizable. This touches on a broader problem with OSM’s unstructured representation of street names, combined with insisting on spelled-out words in name, but some heuristics like avoiding abbreviating the middle word(s) could help.
Good points, I'll keep a running list of test cases that should pass at the top of this issue.
Another thought I had was using libpostal (https://github.com/openvenues/jpostal) to try to extract some more structure from raw street names. Not sure it would handle street names and not addresses though...?
Moved the openmaptiles profile to https://github.com/openmaptiles/planetiler-openmaptiles. This ticket will track adding the generic capability of abbreviating road-names, and https://github.com/openmaptiles/planetiler-openmaptiles/issues/17 will track using that from the openmaptiles profile.