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
https://lists.openstreetmap.org/listinfo/talk
