Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Minh Nguyen]

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 .


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 
 with examples of usage 
. 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 



Our own parameter could have the following syntax:

osmid=(N|W|R)


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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Tue, 2023-01-10 at 08:39 +0100, Yves wrote:
> 
> 
> Le 10 janvier 2023 08:12:43 GMT+01:00, Snusmumriken
>  a écrit :
> > On Mon, 2023-01-09 at 23:06 +, Andy Townsend wrote:
> > > On 09/01/2023 20:17, Snusmumriken wrote:
> > > > On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
> > > > > You seem unwilling to understand that defining a way to refer
> > > > > to
> > > > > ids
> > > > > will cause social pressure not to change ids,
> > > > Is there actually evidence that would corroborate this claim?
> > > 
> > > There have definitely been complaints to the DWG when people
> > > "resurrect" 
> > > old long-deleted nodes, or exhibit "unusual mapping behaviour"
> > > such
> > > as 
> > > never deleting any nodes, and always re-using them in some other 
> > > feature.  There have also been complaints about changes to
> > > objects
> > > that 
> > > people consider "special" such as
> > > https://osm.mapki.com/history/node/1 
> > > and, er,
> > > https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .
> > 
> > Right, I guess one could say that when it comes to retaining
> > existing
> > osm ids there is bad practice and good practice, and a grey area.
> > Any
> > proof or indications that creating a URI scheme would increase the
> > bad
> > practice?
> > 
> No, adding such a URI scheme wouldn't change at all the way
> contributors contribute.
> 
> However it would further degrade the impact of the "bad practice". 

Could you elaborate?



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 10 janvier 2023 08:12:43 GMT+01:00, Snusmumriken 
 a écrit :
>On Mon, 2023-01-09 at 23:06 +, Andy Townsend wrote:
>> On 09/01/2023 20:17, Snusmumriken wrote:
>> > On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
>> > > You seem unwilling to understand that defining a way to refer to
>> > > ids
>> > > will cause social pressure not to change ids,
>> > Is there actually evidence that would corroborate this claim?
>> 
>> There have definitely been complaints to the DWG when people
>> "resurrect" 
>> old long-deleted nodes, or exhibit "unusual mapping behaviour" such
>> as 
>> never deleting any nodes, and always re-using them in some other 
>> feature.  There have also been complaints about changes to objects
>> that 
>> people consider "special" such as
>> https://osm.mapki.com/history/node/1 
>> and, er,
>> https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .
>
>Right, I guess one could say that when it comes to retaining existing
>osm ids there is bad practice and good practice, and a grey area. Any
>proof or indications that creating a URI scheme would increase the bad
>practice?
>
No, adding such a URI scheme wouldn't change at all the way contributors 
contribute.

However it would further degrade the impact of the "bad practice". 

I put "bad practice" between quotes because if it is considered good practice 
to try to keep IDs when editing because it's easier to retrieve history when 
trying to understand each other edits, it's not mandatory. 

Yves

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Mon, 2023-01-09 at 23:06 +, Andy Townsend wrote:
> On 09/01/2023 20:17, Snusmumriken wrote:
> > On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
> > > You seem unwilling to understand that defining a way to refer to
> > > ids
> > > will cause social pressure not to change ids,
> > Is there actually evidence that would corroborate this claim?
> 
> There have definitely been complaints to the DWG when people
> "resurrect" 
> old long-deleted nodes, or exhibit "unusual mapping behaviour" such
> as 
> never deleting any nodes, and always re-using them in some other 
> feature.  There have also been complaints about changes to objects
> that 
> people consider "special" such as
> https://osm.mapki.com/history/node/1 
> and, er,
> https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .

Right, I guess one could say that when it comes to retaining existing
osm ids there is bad practice and good practice, and a grey area. Any
proof or indications that creating a URI scheme would increase the bad
practice?

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Greg Troxel]

Snusmumriken  writes:

> On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
>> 
>> You seem unwilling to understand that defining a way to refer to ids
>> will cause social pressure not to change ids, 
>
> Is there actually evidence that would corroborate this claim? 

Do you mean like actually publish the scheme and wait and see?

Of course we are all talking about what we think will happen.

I think it's entirely plausible that if there are published references
to ids then people will be told they shouldn't edit in a way that
changes them.

I agree that gratuitous changes are best avoided.

But, I often take a way, split it multiple times, retag various
sections, and glue parts back together to rationalize parking lot ways,
for example.  It moves the ids around for sure.  I don't think  there's
anything wrong with that and it would be unreasonable to tell  me not to
do it because it breaks an ill-conceived linking scheme.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Andy Townsend]

On 09/01/2023 20:17, Snusmumriken wrote:

On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:

You seem unwilling to understand that defining a way to refer to ids
will cause social pressure not to change ids,

Is there actually evidence that would corroborate this claim?


There have definitely been complaints to the DWG when people "resurrect" 
old long-deleted nodes, or exhibit "unusual mapping behaviour" such as 
never deleting any nodes, and always re-using them in some other 
feature.  There have also been complaints about changes to objects that 
people consider "special" such as https://osm.mapki.com/history/node/1 
and, er, https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .


I'm not saying those complaints are defensible, but they do occur.

Best Regards,

Andy



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
> 
> You seem unwilling to understand that defining a way to refer to ids
> will cause social pressure not to change ids, 

Is there actually evidence that would corroborate this claim? 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 9 janvier 2023 16:19:14 GMT+01:00, Niels Elgaard Larsen  a 
écrit :
>
>I sometimes do get annoyed at especially new mappers that often
>excessively delete and recreates objects. Because it obscures the
>history.
>
If it is a trend for new mappers, which I understand well because sometimes it 
is easier to re-create from scratch, then you shouldn't be annoyed by it. The 
good news here is that a new mapper tries to improve the map!
A new mapper that could be put off by the slightest social pressure.
Yves 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Niels Elgaard Larsen]

On Mon, 09 Jan 2023 08:21:42 -0500
Greg Troxel  wrote:

>Sören Reinecke  writes:
>
>> Using osm id is far from ideal but it is sufficient enough. If POI
>> owners are using OSM data, they will likely also pay attention to the
>> osm entry they have to keep it updated. So they will notice any
>> change.  
>
>You seem unwilling to understand that defining a way to refer to ids
>will cause social pressure not to change ids, and that this harms the
>community.


How would it harm the community?

Actually I would welcome a little social pressure to preserve objects
when (and only when) it is possible and it makes sense

I sometimes do get annoyed at especially new mappers that often
excessively delete and recreates objects. Because it obscures the
history.

And id's are never changed. They just might represent objects that have
been deleted.

If an application receives such a geo:osmid it could choose to show a
"removed" icon at last position of the object before deletion.
It could also show the message of the changeset, where the object was
deleted. That might cause a social pressure for better commit messages.

Giving the recipient the last position of a deleted object would be at
least as helpful as the alternative which is that the sender had used a
position from some point in the objects lifetime.

A bigger problem would be when an object is not deleted when it should
have been, i.e., when an id is reused to represent something different
in the real world. 

For example if a restaurant burns down and the area is used for a
parking lot, it would be best to delete the restaurant and create a new
object for the parking lot.

Or someone could know that e.g., a restaurant had closed in Copenhagen
and that a new traffic light was installed in Berlin and decide to use
the same object, replace all the tags in the restaurant object and
change the position. That would be confusing. But very rare, and I
think that we should discourage such a style of editing.

I believe that it useful to consider object identity, even if can turn
into philosophy discussions.

For example restaurant Koks,
https://www.openstreetmap.org/node/1228100335

is temporarily relocated to Greenland
https://www.openstreetmap.org/node/1228100335

Is that the same restaurant?
Should I just fix the coordinates?



>Therefore it is not ok to do it.



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Andy Mabbett]

On Mon, 2 Jan 2023 at 17:57, Sören Reinecke  wrote:

> It came into my mind to get IETF to standardize a parameter explicitly 
> linking to
> osm objects with their corresponding type and id.

1) Do we have any indication that IETF would be willing to
"standardize a parameter" for an ID scheme used by one data provider
(rather than something generic and transferable; like coordinates)?

2) There is already a standard for referring to osm objects with their
corresponding type and id; for example:

   https://www.openstreetmap.org/way/22814079

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Greg Troxel]

Sören Reinecke  writes:

> Using osm id is far from ideal but it is sufficient enough. If POI
> owners are using OSM data, they will likely also pay attention to the
> osm entry they have to keep it updated. So they will notice any
> change.

You seem unwilling to understand that defining a way to refer to ids
will cause social pressure not to change ids, and that this harms the
community.  Therefore it is not ok to do it.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Martin Koppenhoefer]

sent from a phone

> On 6 Jan 2023, at 23:34, Niels Elgaard Larsen  wrote:
> 
> Maybe we could maintain a list of tags that are practical permanent unique 
> identifiers. And then have a tool that for most objects could generate a url 
> (https or geo) that references that object using that tag.


“ref:vatin”, the VAT id number, is also such an id for businesses that is 
typically available on receipts and sometimes on websites.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Niels Elgaard Larsen]

Sören Reinecke:

 > way/node/relation ids in OSM are unstable, not promised to be stable
and anything relying on their stability can break at any point

Right, I know that OSM ids are not stable. The same applies to
coordinates too. If a restaurant puts a 'geo' link on their online pdf
menu card with the coordinates to their shop then this is in the same
manner unstable as osm id.



I agree. It is useful to refer to  a unique ID for an object.

And we do have some good candidates for that.

osm id's are not completely permanent. I would not use them on a website, but I have 
used them in many emails for 15 years for invitations, event announcements, 
conferences, meetups etc, without any problems at all. Because really, what are the 
chances that that public park, community center, cafe, train station will have a new 
OSM id in the next week or two?
If I have booked a meeting room at a facility, it is very unlikely that someone will 
delete it before the meeting takes place, unless the place unexpectedly closes, in 
which case it does not matter.


Wikidata tags are more stable. But there is not a wikidata ID for all OSM 
objects.

In Denmark, almost all restaurants, cafes, supermarkets etc has a ref:DK:cvr:pnummer 
tag which identifies a the business/branch in Denmark's Central Business Register 
(Company House for you Brits). That is a reasonable way to identify a business. The 
ref:DK:cvr:pnummer for an OSM object could change if e.g., a restaurant continues at 
the same address with new owners or even with the same beneficial owners in a new 
company.


But that is specific to each country and only work for businesses.

I am not sure how to do it elegantly with the flat OSM key/value structures.

Maybe we could maintain a list of tags that are practical permanent unique 
identifiers. And then have a tool that for most objects could generate a url (https 
or geo) that references that object using that tag.


And it could use name, id and position or a mix of those as a fallback.


This is because how humans use coordinates.
Coordinates are stable to the point we use them as a reference of earth
scoped physical space only. But we use them for not just as reference
values for physical space on earth but more likely as a estimate where
to look for our destination. In the example the POI is a restaurant.
Imagine the restaurant moves to another position and thus changing its
physical position on earth. They forgot to update their 'geo' url. Now
the geo: url still points to the same physical position on earth because
it won't be changed by any action caused by individuals. But the feature
of letting map apps centering their view on that geographic reference
point is now useless because the user cannot find the POI there anymore.

To sum up: Coordinates can be used in the same wrong way as OSM id as
they're both not sufficient enough for the use case most people are
using it (indirectly). Coordinates are already part of the 'geo' URI
scheme. There is no visible reason to me why adding another unstable
identifier like the osm id is a bad idea. As long as OSM ids are used in
a dynamic and not in a hardcoded way and proberly updated by the tools
people are using to retrieve these data (e.g. Overpass, Sophox or
end-user apps like OrganicMaps) 'geo' uris are always generated by
tools. If some does that manually then this person is in charge to
change that when the physical position of the POI changes too. People
tend to forget about these little urls as long as they don't see a GUI
(graphical user interface) connected to it like a map on their website.

On 04/01/2023 13:28, Marc_marc wrote:

Hello,

Le 02.01.23 à 18:57, Sören Reinecke a écrit :

It allows (web) developers to direct their users to their map browser
of use e.g, Organic Maps, Google Maps, Apple Maps


if it allow to open an osm editor from an "osm datauser app",
that look fine.
for ex I use Organic Maps, I see an error or an improvement for a POI,
it allow me to open Vespuccci with that object.

could the iD of the object have changed between the data of the "user"
app and the osm database used by the "editor" app ?
of course it may.
in the same way that this iD could have changed between an osmose
analysis and the moment I click on edit to open it in josm.
In this case, it's not serious, it will be enough to find the
object in the editor.
this does not change the fact that it is much easier than opening
an area, loading the area, zooming, finding the object and finally
selecting it in the 99.999% of cases where the iD has not changed

Regards,
Marc



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


--
Niels Elgaard Larsen


___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Yves via talk]

Le 6 janvier 2023 15:49:53 GMT+01:00, "Sören Reinecke"  a 
écrit :
>
>Better would be to have a separate FOSS platform for storing POI information 
>using a permanent identifier connected to OSM somehow e.g. by a key 
>"somepoiplatformid". But no one created such a platform yet.
>
Probably because it is slightly complicated to do and ressource-intensive?
For this reason, data consumers creating geo:id would not be likely to do it 
either.
Yves 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Sören Reinecke]

Ok, sry. I messed up with my example. I wanted to explain that using 
coordinates is not stable either because they don't point directly to the POI, 
they just point to the physical reference of the ground on earth.

But at the end we may clarify strongly that osm ids are not stable and keep 
saying this. The most software using OSM data deals with such cases already.

But you're right: From a physical ground view these coordinates are stable. But 
as osm ids they are not reliable enough when connected to some other 
information like a restaurant.

Using osm id is far from ideal but it is sufficient enough. If POI owners are 
using OSM data, they will likely also pay attention to the osm entry they have 
to keep it updated. So they will notice any change.

Better would be to have a separate FOSS platform for storing POI information 
using a permanent identifier connected to OSM somehow e.g. by a key 
"somepoiplatformid". But no one created such a platform yet.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Fri, 2023-01-06 at 13:47 +, Ed Loach wrote:
> > Good point. Also consider that OSM ids have an advantage over
> > coordinates, because if an OSM object gets deleted then a query for
> > that id will return "Not found". That in itself is valuable
> > information
> > to a data consumer.
> 
> But rather than being deleted, they may become a different thing

True but it would still be up to the data consumer to handle it 


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Ed Loach]

> Good point. Also consider that OSM ids have an advantage over
> coordinates, because if an OSM object gets deleted then a query for
> that id will return "Not found". That in itself is valuable information
> to a data consumer.

But rather than being deleted, they may become a different thing, such as:
https://www.openstreetmap.org/node/1/history

Ed


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 6, 2023, 11:50 by valin...@gmx.net:

> To sum up: Coordinates can be used in the same wrong way as OSM id as
> they're both not sufficient enough for the use case most people are
> using it (indirectly).
>
But coordinates can be used correctly (shop updating their location
when their location moves).

It is impossible to guarantee it with OSM ids (in theory they could check
OSM object daily to check whether its id changed but that would be absurd)

> There is no visible reason to me why adding another unstable
> identifier like the osm id is a bad idea.
>
Coordinates are stable, information attached to coordinates can become
outdated (shop relocated, landmass moved etc) but coordinate itself is stable.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Fri, 2023-01-06 at 11:50 +0100, Sören Reinecke wrote:
> To sum up: Coordinates can be used in the same wrong way as OSM id as
> they're both not sufficient enough for the use case most people are
> using it (indirectly). Coordinates are already part of the 'geo' URI
> scheme. There is no visible reason to me why adding another unstable
> identifier like the osm id is a bad idea. As long as OSM ids are used
> in
> a dynamic and not in a hardcoded way and proberly updated by the
> tools
> people are using to retrieve these data (e.g. Overpass, Sophox or
> end-user apps like OrganicMaps) 'geo' uris are always generated by
> tools. If some does that manually then this person is in charge to
> change that when the physical position of the POI changes too. People
> tend to forget about these little urls as long as they don't see a
> GUI
> (graphical user interface) connected to it like a map on their
> website.

Good point. Also consider that OSM ids have an advantage over
coordinates, because if an OSM object gets deleted then a query for
that id will return "Not found". That in itself is valuable information
to a data consumer. 

I really don't understand why anybody would make that into some kind of
Pandora's box that must not be opened. 

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Frederik Ramm]

Hi,

On 06.01.23 11:50, Sören Reinecke wrote:

Right, I know that OSM ids are not stable. The same applies to
coordinates too. If a restaurant puts a 'geo' link on their online pdf
menu card with the coordinates to their shop then this is in the same
manner unstable as osm id.


No. The restaurant has full control over if and when they move. But they 
have no control over if and when their OSM ID changes. This can happen 
at any time, without even the knowledge of the restaurant, and is 
therefore not comparable to the restaurant moving to another location.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Sören Reinecke]

> way/node/relation ids in OSM are unstable, not promised to be stable
and anything relying on their stability can break at any point

Right, I know that OSM ids are not stable. The same applies to
coordinates too. If a restaurant puts a 'geo' link on their online pdf
menu card with the coordinates to their shop then this is in the same
manner unstable as osm id. This is because how humans use coordinates.
Coordinates are stable to the point we use them as a reference of earth
scoped physical space only. But we use them for not just as reference
values for physical space on earth but more likely as a estimate where
to look for our destination. In the example the POI is a restaurant.
Imagine the restaurant moves to another position and thus changing its
physical position on earth. They forgot to update their 'geo' url. Now
the geo: url still points to the same physical position on earth because
it won't be changed by any action caused by individuals. But the feature
of letting map apps centering their view on that geographic reference
point is now useless because the user cannot find the POI there anymore.

To sum up: Coordinates can be used in the same wrong way as OSM id as
they're both not sufficient enough for the use case most people are
using it (indirectly). Coordinates are already part of the 'geo' URI
scheme. There is no visible reason to me why adding another unstable
identifier like the osm id is a bad idea. As long as OSM ids are used in
a dynamic and not in a hardcoded way and proberly updated by the tools
people are using to retrieve these data (e.g. Overpass, Sophox or
end-user apps like OrganicMaps) 'geo' uris are always generated by
tools. If some does that manually then this person is in charge to
change that when the physical position of the POI changes too. People
tend to forget about these little urls as long as they don't see a GUI
(graphical user interface) connected to it like a map on their website.

On 04/01/2023 13:28, Marc_marc wrote:

Hello,

Le 02.01.23 à 18:57, Sören Reinecke a écrit :

It allows (web) developers to direct their users to their map browser
of use e.g, Organic Maps, Google Maps, Apple Maps


if it allow to open an osm editor from an "osm datauser app",
that look fine.
for ex I use Organic Maps, I see an error or an improvement for a POI,
it allow me to open Vespuccci with that object.

could the iD of the object have changed between the data of the "user"
app and the osm database used by the "editor" app ?
of course it may.
in the same way that this iD could have changed between an osmose
analysis and the moment I click on edit to open it in josm.
In this case, it's not serious, it will be enough to find the
object in the editor.
this does not change the fact that it is much easier than opening
an area, loading the area, zooming, finding the object and finally
selecting it in the 99.999% of cases where the iD has not changed

Regards,
Marc



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Marc_marc]

Hello,

Le 02.01.23 à 18:57, Sören Reinecke a écrit :
It allows (web) developers to direct their users to their map browser of 
use e.g, Organic Maps, Google Maps, Apple Maps


if it allow to open an osm editor from an "osm datauser app",
that look fine.
for ex I use Organic Maps, I see an error or an improvement for a POI,
it allow me to open Vespuccci with that object.

could the iD of the object have changed between the data of the "user" 
app and the osm database used by the "editor" app ?

of course it may.
in the same way that this iD could have changed between an osmose 
analysis and the moment I click on edit to open it in josm.

In this case, it's not serious, it will be enough to find the
object in the editor.
this does not change the fact that it is much easier than opening
an area, loading the area, zooming, finding the object and finally 
selecting it in the 99.999% of cases where the iD has not changed


Regards,
Marc



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Greg Troxel]

stevea  writes:

> I'll state even more strongly than Frederik just did: "linking to an
> OSM object by ID and expecting the ID to remain constant is asking for
> trouble" is putting it mildly.  It IS trouble.  All it takes is one
> single change to one single datum and boom, the assumption that doing
> so can work is proven false.  I'll offer to be the first to change an
> ID to do this just on the general principle that it proves this is a
> bad idea.
>
> So, this (linking to an OSM object by ID and expecting the ID to remain 
> constant) is a non-starter.  Right here, right now.

And, the real harm is the seconds-after-links-exist push that people
should not edit in a way that changes IDs.

The IETF should not support referring to unstable IDs because that's bad
engineering.

People who want to refer to osm objects need to

  understand what it means when it's a named way and how the reference
  should behave as the way is split and micromapped

  how to bind by type/name so it's stable in some sensible semantic
  sense, sort of a combo of
name
type
rough coordinates (to disambiguate the above)

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 2, 2023, 21:59 by ajt1...@gmail.com:

> On 02/01/2023 20:44, Mateusz Konieczny via talk wrote:
>
>> way/node/relation ids in OSM are unstable, not promised to be stable and
>> anything relying on their stability can break at any point
>>
> Unfortunately, that sort of "black and white" answer doesn't really answer 
> the question of whether it's useful to link to OSM data like that.
>
It is often useful, but we should try to avoid implying that this ids will stay 
stable forever.

https://www.openstreetmap.org/node/1325892214 works well as link for such cases,
making some official uri scheme is implying things that we should not be 
implying.


> It's certainly possible (as I've said in that discussion) to use OSM IDs as 
> "stable enough to do real work with" - I do it all the time.
>
I also do this, but without expectations of id stability. 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[stevea]

I am “with” Andy here, yet I am also “with" Frederik here:  you might be able 
to get away with this “most of the time,” but when it fails (and it will), 
you’ll be disappointed and perhaps even upset with OSM.  There is simply no 
reason why we should be suggesting or supporting this.  Because it WILL fail.

For that reason, I say “don’t do it.”  And please don’t suggest others should, 
either.  At least once, it won’t end well, and that will be one too many times.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Frederik Ramm]

Hi,

On 02.01.23 21:59, Andy Townsend wrote:
It's certainly possible (as I've said in that discussion) to use OSM IDs 
as "stable enough to do real work with" - I do it all the time.


But establishing a "standard" to do it would likely exert pressure on 
mappers not to do anything that would change an ID (I am imagining pink 
warning boxes on the wiki explaining that you should avoid this or that 
because it will cause lots of dangling links from the outside into OSM).


You're currently doing at your own risk and if it doesn't work then you 
have no right to complain. Once we encourage people to create such links 
from outside applications that are unknown (and might be inaccessible) 
to us, these people will complain when links break.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Simon Poole]

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?


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 
 with examples of usage 
. 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 



Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Martin Koppenhoefer]

Am Mo., 2. Jan. 2023 um 22:03 Uhr schrieb Andy Townsend :

> It's certainly possible (as I've said in that discussion) to use OSM IDs
> as "stable enough to do real work with" - I do it all the time.
>
> Can I guarantee that the shop at "No 55 Main Street" will always have
> the same OSM ID?  No, but it's unlikely to change.  Can I guarantee that
> in real life it'll always be the same shop?  Of course not - businesses
> close and open; buildings get knocked down and replaced.



I agree, with route relations it is even more likely that they do not
change (if the route does not change/cease to exist), because there is no
converting from node to polygon or back.

Cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Andy Townsend]

On 02/01/2023 20:44, Mateusz Konieczny via talk wrote:

way/node/relation ids in OSM are unstable, not promised to be stable and
anything relying on their stability can break at any point

Unfortunately, that sort of "black and white" answer doesn't really 
answer the question of whether it's useful to link to OSM data like 
that.  This community thread discusses it with rather more nuance:


https://community.openstreetmap.org/t/persistent-and-stable-identifiers/6819

It's certainly possible (as I've said in that discussion) to use OSM IDs 
as "stable enough to do real work with" - I do it all the time.


Can I guarantee that the shop at "No 55 Main Street" will always have 
the same OSM ID?  No, but it's unlikely to change.  Can I guarantee that 
in real life it'll always be the same shop?  Of course not - businesses 
close and open; buildings get knocked down and replaced.


Best Regards,

Andy



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Shawn K. Quinn]

On 1/2/23 11:57, Sören Reinecke wrote:

Hey,

It came into my mind to get IETF to standardize a parameter explicitly 
linking to osm objects with their corresponding type and id.

[...]

Would it make sense for Google Maps, Bing Maps, etc to have similar 
schemes under the geo URI scheme? I don't think it would. The only 
reason it even comes close to making sense for OSM is because the users 
see those IDs much more often, and even then I still don't see the value 
in it, with the potential of it causing more problems than it solves.


--
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[stevea]

I'll state even more strongly than Frederik just did:  "linking to an OSM 
object by ID and expecting the ID to remain constant is asking for trouble" is 
putting it mildly.  It IS trouble.  All it takes is one single change to one 
single datum and boom, the assumption that doing so can work is proven false.  
I'll offer to be the first to change an ID to do this just on the general 
principle that it proves this is a bad idea.

So, this (linking to an OSM object by ID and expecting the ID to remain 
constant) is a non-starter.  Right here, right now.


On Jan 2, 2023, at 10:11 AM, Frederik Ramm  wrote:
> Hi,
> 
> On 1/2/23 18:57, Sören Reinecke wrote:
>> As OpenStreetMap is playing an important part in the geospatial world, the 
>> OSMF should try to get IETF convinced.
> 
> Until now we've concentrated on making a good map, rather than convincing 
> others that our map is good ;)
> 
> I think that linking to OSM objects by ID is only relevant in the immediate 
> and time-limited QA or debugging context ("does anyone else think way 1234 
> has a problem here") because our IDs are not stable; linking to an OSM object 
> by ID and expecting the ID to remain constant is asking for trouble.


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 2, 2023, 18:57 by valin...@gmx.net:

>
> Our own parameter could have the following syntax:
>
>
>
>
> osmid=(N|W|R)
>
>
>
>
> What do you think?
>
>
way/node/relation ids in OSM are unstable, not promised to be stable and
anything relying on their stability can break at any point

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Frederik Ramm]

Hi,

On 1/2/23 18:57, Sören Reinecke wrote:
As OpenStreetMap is 
playing an important part in the geospatial world, the OSMF should try 
to get IETF convinced.


Until now we've concentrated on making a good map, rather than 
convincing others that our map is good ;)


I think that linking to OSM objects by ID is only relevant in the 
immediate and time-limited QA or debugging context ("does anyone else 
think way 1234 has a problem here") because our IDs are not stable; 
linking to an OSM object by ID and expecting the ID to remain constant 
is asking for trouble.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[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
 with examples of usage
. 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


Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk