Vào lúc 00:59 2023-01-03, Simon Poole đã viết:
Not quite unexpected this discussion has already gone off on a tangent
about stable ids. My question on the other hand would be: what do you
actually want to achieve and what would you expect an application to do
with the parameter?
Furthermore, would these goals align with the goals that the IETF laid
out for the geo: URI scheme in RFC 5870?
* Compact
* Simple
* Human-readable
* Protocol-independent
An OSM element ID is compact, and a number is simple. But an element ID
by itself is neither human-readable nor protocol-independent. This
sounds more like a proposal for a new URI scheme that happened to latch
onto geo: because it's also about geography.
While I think it would be an uphill battle to convince the IETF that OSM
is important enough to have its own standard URI scheme, it would be
much more feasible to register a URN namespace under the urn: scheme.
For example, node 8330986510 could be <urn:osm:node:8330986510>.
You could think of it as the machine-readable analogue to how mappers
often refer to "node 8330986510" in the middle of a sentence. It would
allow software to decide whether to resolve the URN as:
https://www.openstreetmap.org/node/8330986510
https://www.openstreetmap.org/api/0.6/node/8330986510
https://nominatim.openstreetmap.org/ui/search.html?q=n8330986510
etc.
A formal, keyword-like URN namespace can be registered with IANA as long
as it meets some requirements. [1] It needs to have organizational
backing, which sounds like a role for the OSMF or one of its working
groups. A given URN would need to be stable: for example, if one refers
to a particular restaurant in Medellín, then the restaurant can close
and be deleted in OSM, but the URN can never refer to a barber shop just
because a mapper repurposed the OSM node to represent the barber shop
across the street.
IANA also accepts informal, sequentially numbered namespaces that aren't
subject to these constraints. For example, there's an informal namespace
for Wikitravel, which uses Wikitravel article names (just as stable as
OSM Wiki article names) as the identifier string following the
namespace. [2] Someone would just need to write up an application and
send it to IANA, but I suspect it still need to convincingly answer the
question, "What for?"
[1] https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
[2] https://www.iana.org/assignments/urn-informal/urn-6
It should be noted that we already have a couple of URI schemes in use
for OSM based tools/editors, and naturally the website object/element
browsing support.
Simon
Am 02.01.2023 um 18:57 schrieb Sören Reinecke:
Hey,
It came into my mind to get IETF to standardize a parameter explicitly
linking to osm objects with their corresponding type and id.
The 'geo' URI scheme is standardized as RFC 5870
<https://www.rfc-editor.org/rfc/rfc5870> with examples of usage
<https://www.rfc-editor.org/rfc/rfc5870#section-6>. It allows us to
link to geospatial ressources from web pages or applications
supporting URI schemes in general. It allows (web) developers to
direct their users to their map browser of use e.g, Organic Maps,
Google Maps, Apple Maps, ... The official osm.org makes use of this
specification in the "share" feature already. Currently it only
supports linking to geospatial ressources by their coordinates and not
some id. As OpenStreetMap is playing an important part in the
geospatial world, the OSMF should try to get IETF convinced.
See registered URI parameters in the 'geo' URI scheme:
'geo' URI Parameters registry at IANA.org
<https://www.iana.org/assignments/geo-uri-parameters/geo-uri-parameters.xhtml>
Our own parameter could have the following syntax:
osmid=(N|W|R)<osm id>
What do you think?
Greetings
Sören Reinecke
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
