Re: [talk-au] Gravel roads surface tagging

[Mateusz Konieczny via Talk-au]

though this round is about surface=fine_gravel (previous was about 
surface=gravel)
while surface=gravel old page claimed that it is for track ballast-sized chunks,
current surface=fine_gravel page describes it as duplicate of surface=compacted


Jan 7, 2023, 03:03 by fors...@ozonline.com.au:

> Hi all
>
> Gravel was discussed on talk_au back in March 2021. For anybody interested 
> its back in discussion at 
> https://community.openstreetmap.org/t/surface-fine-gravel-is-it-for-loose-gravel-or-duplicate-of-surface-compacted/7533/3
>
> Tony
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[lejun]

Le 06/01/2023 à 23:24, osm.sanspourr...@spamgourmet.com a écrit :

|crossing_strip| - Bande franchissable (tablier pour camions)


L’idée me plaît, mais est-ce qu’on est sûr de vouloir partir sur cette 
clé ? J’ai peur que le sens soit trop obscur et que ce soit rapproché du 
highway=crossing.


En second point, est-ce qu’il a été envisagé une extension pour 
détailler la bande ? J’y connais rien mais je suppose qu’on en trouve 
différent types qui peuvent être catalogués.


--
Lejun - Cart’hobyyiste du Bas-Rhin

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

[talk-au] Gravel roads surface tagging

[forster]

Hi all

Gravel was discussed on talk_au back in March 2021. For anybody  
interested its back in discussion at  
https://community.openstreetmap.org/t/surface-fine-gravel-is-it-for-loose-gravel-or-duplicate-of-surface-compacted/7533/3


Tony



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

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-fr] problème avec mes envois

[Maxime Chourré]

Bonjour !

J'ai également le même problème. Je reçois que certains mails, par 
exemple j'ai que la réponse du sujet "bac à marée" et je trouve ça très 
étrange ...


On 1/6/23 16:28, leni wrote:

Bonjour et Bonne Année 2023

J'ai envoyé deux messages sur la liste qui ne semblent pas être arrivés 
sur la liste : je ne les ai pas reçus et je ne les vois pas dans 
l'archive (j'y trouve bien le bac à marée que j'ai également reçu).


Je ne sais pas où ils ont été bloqués !!! Avez-vous eu un problème 
similaire ?


cordialement

leni



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

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

[OSM-talk-fr] mini giratoires et ronds-points traversants : crossing_strip ?

[osm . sanspourriel]

Bonjour,

une discussion sur le sujet a eu lieu sur
https://community.openstreetmap.org/t/mini-roundabout/7524/51

Au final je propose et ça à l'air de plaire :

|crossing_strip| - Bande franchissable (tablier pour camions)

Avec no comme valeur par défaut sur les "vrais" giratoires et yes sur
les mini-giratoires.

Comme ça les Anglais gardent les mini giratoires et sur le continent on
peut cartographier les giratoires accessibles aux poids lourds malgré
leur taille.

Résumé de la discussion :

elle fait suite à
https://lists.openstreetmap.org/pipermail/tagging/2019-October/thread.html#48852

Les définitions FR/EN/DE sont cohérentes :

https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dmini_roundabout

/Le tag //highway
=mini_roundabout//désigne
un micro giratoire où le terre-plein central est franchissable, soit car
il est absent (peinture au sol), soit car il dépasse très peu du sol. /

(et est réservé au ponctuel)

Les Anglais utilisent mini_roundabout pour des giratoires de petite
taille sur lesquels figurent le panneau même s'ils ne peuvent être
franchis (contraire à la définition du wiki). Ils doivent avoir
(contrairement aux autres giratoires) le panneau bleu à 3 flèches
blanches (dans le sens horaire car ils roulent à gauche).

Pour les Allemands un mini giratoire c'est de 13 à 22 m (taille
extérieure). Comme tous les giratoires il est signalé par le même
panneau (inversés, les Allemands roulant à droite). DE:215 (l'équivalent
de notre FR:AB25
).

Pour les Français moins de 24 m (bande roulante jusqu'aux bordures
intérieures de trottoir (le cas échant).

Partout ce sont les mêmes priorités aux véhicules sur le rond-point.

Malgré des échanges, les Anglais ne veulent pas supprimer les
mini-giratoires et les Allemands ayant de grands giratoires
potentiellement traversants veulent pouvoir signaler qu'un giratoire est
traversant si nécessaire. Comme ça le routage classique est bon (prenez
la 3e à droite), la géométrie est respectée. Et voulaient virer les mini
giratoires, ajouter la propriété d'être traversants aux ronds-points.

En France on a des machins tantôt définis comme giratoire
. Mapillary

Tantôt comme Mini giratoire

(carrefour suivant). Mapillary


En fait légalement

ce n'est pas un mini giratoire (la forme n'est pas une calotte sphérique).
Ici il y a un “Bande franchissable (tablier pour camions)” côté
intérieur./Crossing strip (truck apron)/ en anglais
.

D'où mon idée de |crossing_strip=yes| par défaut pour les
|highway=mini_roundabout| et les cas pathologiques comme ci-dessus.
|crossing_strip=no| pour les |junction=roundabout| et les cas
pathologiques comme ici  -
Mapillary

(ici légalement c'est un mini-giratoire).

Les anglais seraient contents, et continueraient à cartographier
contrairement au wiki.

Et sur le continent on pourrait cartographier proprement ;-).

Des opinions ?

Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec mes envois

[Marc_marc]

Le 06.01.23 à 16:28, leni a écrit :

Bonjour et Bonne Année 2023

Avez-vous eu un problème  similaire ?


je n'ai pas vu tes 2 messages (ou alors Alzaimer)
je n'ai rien vu en anomalie (je recois copie des messages d'erreurs 
tordues que la liste revoit parfois)


Cordialement,
Marc



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

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

[OSM-talk-fr] problème avec mes envois

[leni]

Bonjour et Bonne Année 2023

J'ai envoyé deux messages sur la liste qui ne semblent pas être arrivés 
sur la liste : je ne les ai pas reçus et je ne les vois pas dans 
l'archive (j'y trouve bien le bac à marée que j'ai également reçu).


Je ne sais pas où ils ont été bloqués !!! Avez-vous eu un problème 
similaire ?


cordialement

leni


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

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