[openstreetmap/openstreetmap-website] Add OpenLocationCode to OSM website (#1807)
Peter
notifications at github.com
Fri May 9 09:44:10 UTC 2025
ppKrauss left a comment (openstreetmap/openstreetmap-website#1807)
@erik55 You're on the right track when you say, "We just need interoperability and standards". We also need infrastructure to demonstrate usage, enable testing, and build an ecosystem. In this context we need to:
1. Discuss here how to transform `OSM.codes` into a set of [endpoints](https://en.wikipedia.org/wiki/Web_API#Endpoints) for simple **code resolution** (like "name resolution" in [RFC2169](https://datatracker.ietf.org/doc/html/rfc2169)) and future [PURL behavior/functionality](https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator), similar to a [DOI](https://doi.org).
2. Discuss here how to extend the **geo URI** standard (a mature 15-year-old RFC that has never received attention from big tech companies), likely because it's centered on interoperability. See https://en.wikipedia.org/wiki/Geo_URI_scheme <br/> My suggestion for next steps is to adopt the syntax `geo:$x,$y;u=$u` as a Latitude/Longitude input. For example, `geo:-23.55,-46.63;u=15`. The `u` parameter stands for "uncertainty radius" (in meters), which can be used to infer the number of digits in the [grid geocode](https://en.wikipedia.org/wiki/Geocode#Hierarchical_grids). In this example, with `u=15`, the OLC geocode is `588MC8QV+C` and the Geohash is `6gyf4bv4`.
3. Discuss here whether we need additional [grid geocodes](https://en.wikipedia.org/wiki/Geocode#Hierarchical_grids) (beyond just OLC and Geohash), and how to extend the geo URI scheme to include them. <br/> My suggestion is to adopt the syntax `geo:$t:$g`, where `$t` is the type abbreviation (e.g., "olc" for OLC or "ghs" for Geohash) and `$g` is the geocode. Using the earlier examples: `geo:olc:588MC8QV+C` for OLC and `geo:ghs:6gyf4bv4` for Geohash.
____
PS: regarding your other comments:
* We cannot interfere with the `openstreetmap.org` website; unfortunately, that is out of the question.
* "We prefer to popularize OLC" is also Google's preference, but in this community, we also want to *offer code resolution* for Geohash and perhaps other popular geocodes (like Uber H3).
* The geo URI as interoperability standard is important as "zero [vendor_lock-in](https://en.wikipedia.org/wiki/Vendor_lock-in)".<br/> (pure OLC is a Google-standard without any clear technical advantage over Geohash). <br/>Imagine using `geo:olc:588MC8QV+C` in WhatsApp text, "I'm here!", or in ChatGPT prompt-text for geographic contextualization.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/1807#issuecomment-2865891223
You are receiving this because you commented.
Message ID: <openstreetmap/openstreetmap-website/issues/1807/2865891223 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250509/2f961ccb/attachment.htm>
More information about the rails-dev
mailing list