Re: [OSM-talk-fr] noms anglais en Allemagne ?

[Philippe Verdy]

Note aussi que rien n'empêche d'utiliser le nom "par défaut"  (name=*) mais
de le transcrire dans l'écriture que tu préfères. Si la seule chose trouvée
est un nom chinois, russe, japonais ou arabe, il y a des romanisations
standards qui te permettront de lire quand même le résultat.
Et dans les pays dont la langue officielle n'est pas écrite en alphabet
latin, il y a très souvent des romanisations proposées aussi et
standisées localement (et qu'on voit aussi sur le terrain, en Chine, au
Japon, en Inde, et presque tous les pays arabophones).
Bref inclure les algos de romanisation (ou de translitération vers d'autres
écritures pour les non-latinistes: utilisateurs russes, chinois,
arabophones, indiens...) est une extension utile pour afficher les
résultats.
Des standards mondiaux (promus par les agences de l'ONU ou d'autres
orgasisations internationales y compris l'UE) existent même pour la
toponymie, la navigation, les documents d'identité, passeports, les billets
de transport, les réservations, la poste et les envois de colis (voir aussi
les standards UPU, ITU, IAT, ...).

On s'en sort car même pour les écritures moins connues (écritures
indiennes, géorgiennes, arméniennes), il y a toujours au moins une
romanisation. La romanisation de l'arabe, du chinois et du russe a
plusieurs romanisations possibles mais certaines sont standards et
s'imposent dans les pays correspondant (en Chine, en Russie et au Japon par
exemple), ce qui permet de standardiser aussi chez eux les panneaux
multilingues sans les surcharger.

Pour le coréen c'est même standardisé dans Unicode lui-même (cas unique) et
la Corée se passe de mentionner ces romanisatiosn sur ses affichages
publics (le Coréen est facile aussi à transcrire par reconnaissance OCR, sa
forme est très régulière, c'est déjà un alphabet même si les lettres sont
groupées syllabe par cellule dans une juxtaposition "étrange" pour nous
mais complètement standardisée et ses lettres ont des tracés en fait très
simples et faciles à décomposer visuellement, ce qui l'est beaucoup moins
pour l'arabe ou les clusters complexes des abugidas indiens sont les
lettres et signes diacritiques changent de forme selon la position dans le
cluster ou selon la présence d'autres signes logiquement avant ou après
dans le cluster, car ces abugidas n'ont pas de disposition aussi régulière
que le coréen et il faut être déjà formé à leur lecture; pour l'hébreux
c'est assez "simple" à décomposer visuellement sauf que tous les signes ne
sont pas toujours transcrits, dont les voyelles: la romanisation simple des
lettres de base peut ne pas suffire à une lecture correcte et les signes
diacritiques s'ils sont présents sont difficiles à distinguer pour ceux qui
ne les connaissent pas, tellement ils sont petits; l'arabe est comme
l'hébreu mais en plus compliqué à cause des liaisons de lettres qui
changent de forme contextuellement et qui forment de nombreuses ligatures).

Romaniser automatiquement l'hébreu ou l'arabe peut aider beaucoup
cependant. Romaniser le chinois (ou les kanjis en Japonais) est difficile à
moins que la romanisation soit indiquée aussi dans OSM. Romaniser le grec
ou le cyrillique (russe...) est très facile (ajouter leurs romanisations
dans OSM n'est pas nécessaire, pas plus qu'il n'est utile de mentionner les
romanisations du coréen, ni celles du Japonais sans Kanji mais juste des
Kanas). Romanier l'hébreu et l'arabe dans OSM est cependant utile car le
nom usuel est souvent insuffisamment diacrité et cele nécessite une
connaissance de la langue.

Romaniser le Thai, le Laotien, le Khmer dans OSM est probablement inutile
aussi (car automatisable facilement). Romaniser le tibétain est en revanche
plus utile. Romaniser les langues dravidiennes (indiennes du sud) est aussi
inutile (contrairement aux autres écriture indiennes du nord): le tamoul
par exemple est un quasi alphabet et ces écrrtures dravidiennes utilisent
très peu de ligatures complexes.

Bref : les noms "par défaut" d'OSM (name=*) ne servent pas à grand monde ou
ne devraient pas leur servir souvent: autant que possible utiliser les
"name:=*" avec BCP 47, puis avec les translitérations standardisées
si on ne trouve pas son écrtiture préférée.

Note: si on a dans ses préférences "français, anglais, russe", on n'aura
jamais besoin de romanisation du bulgare ou du serbe, on peut afficher
directement le nom russe présent. Si le nom russe est absent d'OSM mais
qu'on a le nom bulgare (ou serbe, ou bélarusse), ce dernier nom
(cyrillique) peut servir tel quel en absence de nom français ou anglais
dans OSM car on a indiqué pouvoir lire le russe (donc le cyrillique) et on
n'a pas besoin de translitération cyrillique-latin.


Le jeu. 6 août 2020 à 22:37, Philippe Verdy  a écrit :

> A mon avis ce n'est pas un bogue.
> Dans tes préférences tu as indiqué de voir le français avant l'anglais
> puis l'allemand. Il ne trouve pas le français mais trouve l'anglais, donc
> affiche l'anglais même si le lieu est en Allemagne et que sa langue
> 

Re: [OSM-talk-fr] noms anglais en Allemagne ?

[Philippe Verdy]

A mon avis ce n'est pas un bogue.
Dans tes préférences tu as indiqué de voir le français avant l'anglais puis
l'allemand. Il ne trouve pas le français mais trouve l'anglais, donc
affiche l'anglais même si le lieu est en Allemagne et que sa langue
officielle est l'allemand.

Imagine-toi voyager en Chine ou en Algérie: veux-tu voir les noms officiels
en chinois ou arabe officiel, ou bien les noms que tu préfères lire en
français, sinon anglais ou allemand (s'ils sont là), quitte à n'afficher le
chinois que si c'est la dernière option disponible (en ignorant les
éventuels noms qui existeraient en italien, portugais ou espagnol)?

BCP47 permet pas mal de chose: pas seulement fixer une préférence de langue
mais aussi une préférence d'écriture. Si tes préférences sont le français,
puis l'anglais et l'allemand, dans tous les cas tu as émis une préférence
pour l'écriture latine (que tu sais lire). Donc même si tu n'as mis aucune
préférence pour le l'espagnol, le portugais, le néerlandais ou
l'indonésien, il pourraient t'afficher des noms dans ces langues
puisqu'elles sont latines avant même de t'afficher le nom officiel chinois
ou arabe (qui n'est que le dernier recours parce qu'on ne peut plus faire
autrement), ce qu'on appelle "le nom par défaut" mais qui n'est utilisé
"par défaut" que quand les choix pertinents possibles sont épuisés.


Le mer. 5 août 2020 à 21:23,  a écrit :

> En fait tu as dû mettre en préférences de ton compte OSM :
>
> fr en
>
> J'avais :
>
> fr-FR fr en en-US de
>
> Et je me retrouvais avec *Freiburg Minster* comme toi.
>
> J'ai mis :
>
> fr-FR fr de en en-US et j'ai bien *Münster Unserer Lieben Frau*.
>
> Donc le problème c'est que osm.org ne sait pas que la cathédrale de
> Fribourg-en-Brisgau est en Allemagne et que la langue officielle de
> l'Allemagne est l'allemand (default_language
> =de
> de la relation Allemagne ).
>
> Yves va se faire un plaisir d'ouvrir un ticket pour Tom^^.
>
> Jean-Yvon
> Le 05/08/2020 à 20:47, Muselaar - musel...@ouvaton.org a écrit :
>
> (...)
>
> Mais alors, pourquoi c'est le nom anglais qui apparaît sur la liste des
> objets(...)
>
> comme sur l'intitulé du chemin, alors que mon interface est en français ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Mapping disaperead vicinal paths

[Matthieu Gaillet]

Good point. 

A search led me to this discussion 
https://help.openstreetmap.org/questions/6728/tagging-historicunsignedunmaintained-trails
 which emphasizes the use of the disuse: or abandoned: prefixes. 

Matthieu G.  (en mode mobile)



Matthieu G.  (en mode mobile)
>> Le 6 août 2020 à 22:15, EeBie  a écrit :
>  Hello,
> 
> In my neighbourhood somone mapped paths and ways that don't exist anymore. I 
> didn't want to delete his work complete and 
> deleted highway=path and replaced it by  historic=path and left name=Voetweg 
> SLH°82. In this way the path isn't visible in the usual map
> but it is visible in an editor and in an eventual special historic map.
> 
> Regards,
> 
> Erik
> 
> 
> Op 6/08/2020 om 13:00 schreef joost schouppe:
>> Hi,
>> 
>> The example Wouter showed hurt my eyes too much, so I have deleted some 
>> bits; I marked a few that maybe exist as fixme:highway for now. The user 
>> also didn't snap roads to the rest of the road network properly. 
>> If they don't respond to comments, we might have to consider a user block. A 
>> convincing argument for them to do the work properly could be that we might 
>> be forced to just revert all their work.
>> 
>> Best,
>> Joost
>> 
>> Op do 6 aug. 2020 om 10:45 schreef Wouter Hamelinck 
>> :
>>> Hi,
>>> 
>>> Let me start by saying that I have all the sympathy for the aims of the 
>>> mapper. I also have been working with communities to keep vicinal ways 
>>> open. I am also aware that certain ways are only accessible certain times 
>>> of the year due to vegetation etc. Even if a path is not visible at the 
>>> moment you pass there, it might be at other times of the year. In general I 
>>> advocate leaving paths through fields (even plowed) that are legal rights 
>>> of way. My reasoning is that as soon as you pass with a small group a kind 
>>> of path will be visible. On the other hand, if the legal right of way 
>>> crosses buildings, gardens, canals... it makes no sense to put those in 
>>> OSM. Nobody will ever follow those.
>>> 
>>> With that in mind, I've taken a look at some of the changesets that you 
>>> linked to. I didn't like what I saw. People who want to check only one 
>>> example, this is a good one: https://www.openstreetmap.org/way/833838389 
>>> There is no place in OSM for that kind of legal fiction. Even not knowing 
>>> the situation on the ground, it is clear to me that nobody will try to 
>>> follow that track. So I would say to revert changes like that.
>>> 
>>> As for the arguments of the mapper:
>>> * Putting something in OSM does not put any pressure on the owner. Nobody 
>>> will be impressed by the argument "you have to keep the way open because I 
>>> just put it on a website where everybody can put things".
>>> * It makes the data in OSM useless. The tracks in OSM are used on a daily 
>>> basis by many, many hikers. The presence of legal fictions in OSM makes it 
>>> useless for them. They don't care where they should be able to pass in 
>>> theory. They want to know where they can pass in reality.
>>> 
>>> In conclusion, the mapper is trying to have some very dubious advantage for 
>>> his personal use and by doing that makes the data useless for all other 
>>> users. For me it is clear that those ways should be removed.
>>> 
>>> Regards,
>>> Wouter
>>> 
>>> On Thu, Aug 6, 2020 at 8:21 AM Matthieu Gaillet  wrote:
 Hi,
 
 Recently an user mapped a set of disappeared “communal” or "vicinal” ways. 
 By disappeared I mean they are physically absolutely not existent on the 
 ground. They were either plowed or constructions were built right on them.
 
 I believe it goes against the general rule that states that one might only 
 map what’s visible on the field. Additionally the mapping itself was 
 poorly done and the source mentioned was not relevant.
 
 Using the tag [trail]_visibility=no is not an option here since the user 
 decided to map a unmaintained track road (with width = 4m !) that doesn’t 
 offer such option.
 
 He denied reverting the changeset, arguing that mapping those paths was a 
 way to put pressure on the Commune and the owner in a discussion about the 
 openness and accessibility of surrounding paths for the general public. He 
 promised to delete the date once the case will be closed.
 
> Les sentiers et chemins que j'ai repris sur OSM sont légalement toujours 
> existants et personne n'est en droit d'empêcher quiconque de les 
> utiliser, de les réhabiliter ou de les débroussailler... c'est une façon 
> de mettre la pression sur le riverain... dès que des alternatives auront 
> été créées et un bon accord conclu, j'effacerai les données au profit des 
> alternatives qui auront été proposées.
 
 The changesets : 
 https://www.openstreetmap.org/changeset/88927383
 https://www.openstreetmap.org/changeset/88927894
 https://www.openstreetmap.org/changeset/88927825
 

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Philippe Verdy]

Je poense que pour des cas comme ça, il faudrait que l'algo de routage ne
cherche pas la route à partir du seul point accessbile le plus proche masi
à partir d'un ensemble de points accessibles facilement dans un rayon
acceptable (qu'on peut finir à pied).
Malgré tout la difficulté est de trouver ce qui est routable à pied: il n'y
a pas toujours de chemin précis mais des surfaces accessibles.

Bref, pourquoi ne pas chercher les routes qui aboutissent (ou passent) dans
les surfaces englobant le point cherché (aussi bien au départ qu'à
l'arrivée) il reste le bout de route inconnu entre le point cherché et le
dernier point routage: on doit malgré tout s'en sortir avec un rayon de
recherche où existe au moins un point accessible à pied.

Et quand il y a plusieurs point routables dans ce rayon et qu'il ne sont
pas routés directement entre eux, classer les résultats et ne pas se
contenter d'un seul résultat sur le seul point routable le plus proche (car
là on aura toujours des résultats aberrants, mais classer les résultats
obtenus par distance ou par temps de parcours sur la partie routable (tout
en estimant à la louche la distance ou le temps "à vol d'oiseau" de la
partie non routable) peut grandement améliorer les choses. On trouvera
parfois un classement incorrect mais afficher une liste de résultats et non
un seul peut aider beaucoup: il suffit de cliquer sur le choix suivant. Une
liste qui proposerait une choix avec au moins 5 ou 6 alternatives devrait
toujours permettre de s'en sortir.

Si le logiciel ne trouve aucun point routable dans le rayon raisonnable
cherché (environ 50 mètres devrait suffire, au delà le lieu devrait avoir
des chemins piétons ajoutés), il peut demander à l'utilisateur de préciser
mieux son point de départ ou d'arrivée en présentant un zoom sur la zone
déjà cherchée. Ce zoom devrait montrer les positions de départ (ou
d'arrivées) possibles déjà trouvée, de sorte que la plupart du temps il
suffira à l'utilisateur de choisir parmi les points proposés en cliquant
dessus, ou déplacer son point de recherche plus précisément)

Note que Google propose par défaut de compléter les chemins voiture trouvés
par des chemins à pied sur une distance courte (là aussi de l'ordre de 50
mètres).

Conclusion: dans des lieux au cheminement compliqué (barrières et
interdictions/restriuctions) diverses, ne pas oublier de tracer les
chémins pîétons entre les différentes zones. Le logiciel de routage
trouvera alors ce qu'il faut (en tenant compte des préférences:
voiture/vélo, sinon terminer à pied, et il trouvera non seulement le
chmin principal mais aussi les derniers segments de chemins piétons tracés
aussi même s'ils ne sont pas complets et ne détaillent pas les surfaces).


Le jeu. 6 août 2020 à 12:20, Percherie OnDaNet 
a écrit :

> C'est aussi vers cette réflexion que je m'orientais. Les données sont
> cohérente avec le terrain mais c'est au routage de s'adapter.
>
> Après essai sur l'Aire d'Hastingues :
> https://www.openstreetmap.org/way/473891861 :
>
>- OSRM : échec
>- GraphHopper : échec
>- OpenRouteService : échec
>- MapQuest : échec
>- Application OsmAnd : échec
>- Application MapFactor Navigator : déplace l'arrivé (drapeau)
>clairement sur le segment le plus proche, ça à le mérite d'être
>compréhensible
>- Application Magic Earth : échec
>- Bing Maps : échec
>- GoogleMaps y arrive seulement parce que le nœud de l'aire est bien
>positionné, autrement ça plante :
>   - Trajet 1 : https://goo.gl/maps/BTma9uZD7wuTEide6
>   - Trajet 2 : https://goo.gl/maps/y3XSoj7c1YPxzAJR9
>- Waze : échec avec des détours hallucinant
>- ViaMichelin plante avec une arrivée imposée en dehors de l'aire
>- Mappy ne connait pas l'aire
>
> En l'état seul un service GAFAM y arrive. Que faut-il faire ? Remonter
> l'anomalie à tous les services ?
> Le 06/08/2020 à 10:24, Christian Quest a écrit :
>
> Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :
>
> Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
>
> Si on remplace par un node, je pense qu'on aura toujours le problème, dans
> un sens ou dans l'autre de l'autoroute.
>
>
> Et si l'on met ce node sur une zone non accessible en voiture, par exemple
> une zone de pique-nique, peut-être que le routeur n'aura plus intérêt à
> faire effectuer un détour routier ?
>
>
> Le routeur ça chercher la voie d'accès la plus proche, y projet le POI
> d'arrivée et calculer la route sur ce point trouvé.
>
> Cela ne résoudra pas le problème qui est en fait lié à un routage
> mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il
> trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée que
> de faire un énorme détour en voiture.
>
> C'est pour moi plutôt un défaut des algos de routage sur le routage à
> l'arrivée qu'un problème dans les données OSM qui décrivent, il me semble,
> correctement le terrain.
>
>
> ___
> Talk-fr mailing list
> 

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

[Georges Dutreix via Talk-fr]

Ce site est il très vivant ? Pérenne ? Le dernier message de la page d'accueil 
est une bonne année 2019.

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

Re: [OSM-talk-be] Mapping disaperead vicinal paths

[EeBie]

Hello,

In my neighbourhood somone mapped paths and ways that don't exist 
anymore. I didn't want to delete his work complete and
deleted highway=path and replaced it by  historic=path and left 
name=Voetweg SLH°82. In this way the path isn't visible in the usual map

but it is visible in an editor and in an eventual special historic map.

Regards,

Erik


Op 6/08/2020 om 13:00 schreef joost schouppe:

Hi,

The example Wouter showed hurt my eyes too much, so I have deleted 
some bits; I marked a few that maybe exist as fixme:highway for now. 
The user also didn't snap roads to the rest of the road network properly.
If they don't respond to comments, we might have to consider a user 
block. A convincing argument for them to do the work properly could be 
that we might be forced to just revert all their work.


Best,
Joost

Op do 6 aug. 2020 om 10:45 schreef Wouter Hamelinck 
mailto:wouter.hameli...@gmail.com>>:


Hi,

Let me start by saying that I have all the sympathy for the aims
of the mapper. I also have been working with communities to keep
vicinal ways open. I am also aware that certain ways are only
accessible certain times of the year due to vegetation etc. Even
if a path is not visible at the moment you pass there, it might be
at other times of the year. In general I advocate leaving paths
through fields (even plowed) that are legal rights of way. My
reasoning is that as soon as you pass with a small group a kind of
path will be visible. On the other hand, if the legal right of way
crosses buildings, gardens, canals... it makes no sense to put
those in OSM. Nobody will ever follow those.

With that in mind, I've taken a look at some of the changesets
that you linked to. I didn't like what I saw. People who want to
check only one example, this is a good one:
https://www.openstreetmap.org/way/833838389 There is no place in
OSM for that kind of legal fiction. Even not knowing the situation
on the ground, it is clear to me that nobody will try to follow
that track. So I would say to revert changes like that.

As for the arguments of the mapper:
* Putting something in OSM does not put any pressure on the owner.
Nobody will be impressed by the argument "you have to keep the way
open because I just put it on a website where everybody can put
things".
* It makes the data in OSM useless. The tracks in OSM are used on
a daily basis by many, many hikers. The presence of legal fictions
in OSM makes it useless for them. They don't care where they
should be able to pass in theory. They want to know where they can
pass in reality.

In conclusion, the mapper is trying to have some very dubious
advantage for his personal use and by doing that makes the data
useless for all other users. For me it is clear that those ways
should be removed.

Regards,
Wouter

On Thu, Aug 6, 2020 at 8:21 AM Matthieu Gaillet
mailto:matth...@gaillet.be>> wrote:

Hi,

Recently an user mapped a set of disappeared “communal” or
"vicinal” ways. By disappeared I mean they are physically
absolutely not existent on the ground. They were either plowed
or constructions were built right on them.

I believe it goes against the general rule that states that
one might only map what’s visible on the field. Additionally
the mapping itself was poorly done and the source mentioned
was not relevant.

Using the tag [

trail]_visibility
=no


 is
not an option here since the user decided to map a
unmaintained track road (with width = 4m !) that doesn’t offer
such option.

He denied reverting the changeset, arguing that mapping those
paths was a way to put pressure on the Commune and the owner
in a discussion about the openness and accessibility of
surrounding paths for the general public. He promised to
delete the date once the case will be closed.


Les sentiers et chemins que j'ai repris sur OSM sont
légalement toujours existants et personne n'est en droit
d'empêcher quiconque de les utiliser, de les réhabiliter ou
de les débroussailler... c'est une façon de mettre la
pression sur le riverain... dès que des alternatives auront
été créées et un bon accord conclu, j'effacerai les données
au profit des alternatives qui auront été proposées.


The changesets :
https://www.openstreetmap.org/changeset/88927383
https://www.openstreetmap.org/changeset/88927894
https://www.openstreetmap.org/changeset/88927825
https://www.openstreetmap.org/changeset/88927566

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Philippe Verdy]

Le jeu. 6 août 2020 à 21:03,  a écrit :

> Le SIRET n'aurait pas plus d'intérêt : c'est celui de celui qui gère le
> DAE je suppose.
>

L'obligation légale ne concerne pas les gestionnaires (au choix de l'ERP)
mais les établissements ERP eux-mêmes. Ils devraient donc déclarer leurs
établissements équipés eux-mêmes.
Peu importe ensuite si pour cela ils passent par un prestataire externe.
C'est comme nous pour le choix du chauffagiste pour entretenir sa
chaudière. Certes il faut un professionnel agréé (donc numéro d'agrément à
vérifier). Idem pour le détecteur de fumée: à nous de choisir, mais c'est
notre logement qui doit être équipé à une adresse précise, c'est donc nous
qui sommes responsables (et de la faire savoir à son propriétaire si on est
locataire).
Bref identifier les ERP équipés devrait se faire avec leur propre SIRET et
pas celui de leur installateur. A chacun ensuite de voir que l'installateur
est conforme et agréé et d'obtenir l'engagement et la preuve de la
qulification de l'installateur ou la société de maintenance avant de se
décider pour une de leurs offres: ce choix reste privé, même si la loi
impose à ces installateur aussi de pouvoir justifier leur qualification:
mais on on consulte une base gouvernementale où ces agréments sont
délivrés, on doit pouvoir retrouver le professionnel mais pas la liste de
leurs clients, qui n'a rien à voir et reste du droit privé. Il n'est pas
nécessaire ni même utile de faire appraitre dans une base de données
publiques les relations commerciales entre un ERP et ses fournisseurs.
Bref le SIRET de l'installateur ou de la société de maintenance, on s'en
fout et en fait je pense qu'on n'a même pas le droit de l'indiquer dans une
base publique! Le SIRET de l'ERP en revanche si, car l'ERP doit s'engager
publiquement auprès du public qu'il reçoit ou qu'il peut recevoir, ou doit
être capable de recevoir (pour les DAE, il doit pouvoir recevoir tout le
monde, c'et bien pour ça que l'obligation d'équipement impose la pose à
l'extérieur et non à l'intérieur dans les espaces privés).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[Éric Gillet]

Le 06/08/2020 à 16:43, Yves P. a écrit :

Suite au travail lancé pour ajouter des jeux de données dans Osmose autour des défibrillateurs, la 
question se pose de la pertinence du tag name=* sur les défibrillateurs [1,2]. En effet, dans les 
jeux de données (GéoDAE, AEDMAP, bases locales), un nom est souvent associé au DAE. Ce nom est 
plutôt descriptif, exemples "DAE de la mairie", "Défibrillateur de la salle 
XYZ". Dans certains cas, il ressemble plutôt à une référence. Il est proposé ainsi d'opter 
pour l'utilisation de ref=* ou description=*.

En parallèle, dans la base de données OSM aujourd'hui, on constate que 14% des 
DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou description=* 
(moins de 3% ?). Une requête Overpass fait ressortir que les valeurs du champ 
name=* sur les DAE sont plutôt descriptives. C'est un usage qui dépasse nos 
frontières à la vue des langues utilisées. Même si ce sont des noms 
descriptifs, l'usage montre que name=* est l'attribut pour stocker cette info.

Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)

+1 :p

La question est donc la suivante : doit-on préferer le champ name=* pour cette 
info (usage international), utiliser un champ ref=* (plus logique 
sémantiquement, mais qui sera une spécificité FR), voire ne pas proposer 
d'ajouter l'info du nom dans OSM (arbitrage simple mais on perd une info) ? 
Merci pour vos avis qui permettront de débloquer l'ajout de nouveaux jeux dans 
Osmose :-)

Evitons le franco-français : name est parfait
(Il faut peut-être vérifier que les moteurs de rendu ne l'affichent pas).

Pour moi la question est : que mettre dedans pour retrouver un DAE rapidement ?

name="DAE de la mairie" est trop descriptif.

Je préfère :

name="Mairie"
defibrillator:location="Au premier étage à droite"


Je pense qu'il vaut mieux pas de nom, car il sera soit trop long 
(Premier étage mairie de Tourcoing), soit trop "simple" (Mairie) et ne 
correspondant pas à un panneau sur place ou un "identifiant".


Pour indiquer la position à un humain : defibrillator:location="Premier 
étage de la mairie à droite", mais même cet exemple peut être bien 
décrit avec les tags :


level=1
location=indoor
opening_hours=*
access=*
operator=Mairie de X (pas sûr, ça doit être une boîte externe qui gère)

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[osm . sanspourriel]

Le SIRET n'aurait pas plus d'intérêt : c'est celui de celui qui gère le
DAE je suppose.

Et si c'est la commune qui gère le gymnase et comme le gymnase n'est pas
un établissement au sens SIRET (personne travaillant là exclusievment)...

Renseigner le SIREN ne me semble pas savoir le coût/coup.

Car au mieux tu auras des stats sur les données entrées dans OSM sur une
donnée peu motivante (on ne va pas sauver quelqu'un avec un numéro SIREN).

Le 06/08/2020 à 20:49, PanierAvide - panierav...@riseup.net a écrit :


À noter que je n'ai jamais dit que le SIREN servait à géolocaliser ;-)
Je disais que ça peut pas faire de mal de renseigner le SIREN dans le
sens où on sait qui est le gestionnaire de l'appareil, plus
précisément qu'avec son nom uniquement. Une info qui peut permettre de
faire des statistiques à l'échelle nationale par exemple (telle chaîne
n'équipe que 12% de ses établissements...).

Adrien P.
Le 06/08/2020 à 20:13, Philippe Verdy a écrit :

Le jeu. 6 août 2020 à 09:17, PanierAvide mailto:panierav...@riseup.net>> a écrit :

On ne peut pas tout mettre, puisque seules les informations
publiques nous sont accessibles (pas de dates de péremption, de
maintenance...). Pour l'exploitant, au moins le nom ça me semble
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop
d'infos...).


Le SIREN ne géolocalise rien du tout, c'est juste un numéro
d'identité de personne morale dont on ne connait à priori qu'un siège
social (qui n'est pas nécessairement le lieu même de son
établissement principal mais juste une adresse de contact légal).

Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code
établissement).

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

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

[Yves P.]

> Désolé, je ne comprends toujours rien à wikidata

Il y avait un greffon dans JOSM qui s'appelait tag2link.
Il créait automatiquement un lien vers une page web à partir d'un tag.

La condition était d'avoir un tag "caractéristique" (reconnaissable) pour
générer le bon lien.
Une clé ref est trop générique.

Si tu crées par exemple une clé ref:t4t35, on peut mettre une règle pour
pointer vers http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=7271
(Ici 7271 est la référence de ton mégalithe sur ce site).

Et maintenant pour faire ça, on utilise Wikidata.
Ça tombe bien, le lien est déjà décrit, il suffit de rajouter la clé
utilisée dans OSM.

Je peux m'occuper de cette étape 

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

À noter que je n'ai jamais dit que le SIREN servait à géolocaliser ;-) 
Je disais que ça peut pas faire de mal de renseigner le SIREN dans le 
sens où on sait qui est le gestionnaire de l'appareil, plus précisément 
qu'avec son nom uniquement. Une info qui peut permettre de faire des 
statistiques à l'échelle nationale par exemple (telle chaîne n'équipe 
que 12% de ses établissements...).


Adrien P.

Le 06/08/2020 à 20:13, Philippe Verdy a écrit :
Le jeu. 6 août 2020 à 09:17, PanierAvide > a écrit :


On ne peut pas tout mettre, puisque seules les informations
publiques nous sont accessibles (pas de dates de péremption, de
maintenance...). Pour l'exploitant, au moins le nom ça me semble
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop
d'infos...).


Le SIREN ne géolocalise rien du tout, c'est juste un numéro d'identité 
de personne morale dont on ne connait à priori qu'un siège social (qui 
n'est pas nécessairement le lieu même de son établissement principal 
mais juste une adresse de contact légal).


Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code 
établissement).


Ce SIREN, c'est comme si on devait géolocaliser une personne physique 
d'après son numéro de sécu (qui géolocalise partiellement et très 
sommairement que sa commune de naissance ou d'enregistrement, le sexe 
et au mieux le mois et l'année de naissance s'ils sont connus, et pas 
la localisation actuelle).


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Philippe Verdy]

Le jeu. 6 août 2020 à 09:17, PanierAvide  a écrit :

> On ne peut pas tout mettre, puisque seules les informations publiques nous
> sont accessibles (pas de dates de péremption, de maintenance...). Pour
> l'exploitant, au moins le nom ça me semble essentiel, et le SIREN ça peut
> pas faire de mal (on a jamais trop d'infos...).
>
>
Le SIREN ne géolocalise rien du tout, c'est juste un numéro d'identité de
personne morale dont on ne connait à priori qu'un siège social (qui n'est
pas nécessairement le lieu même de son établissement principal mais juste
une adresse de contact légal).

Le SIREN ne sert à rien ici. Je veux bien le SIRET (SIREN + code
établissement).

Ce SIREN, c'est comme si on devait géolocaliser une personne physique
d'après son numéro de sécu (qui géolocalise partiellement et très
sommairement que sa commune de naissance ou d'enregistrement, le sexe et au
mieux le mois et l'année de naissance s'ils sont connus, et pas la
localisation actuelle).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Philippe Verdy]

Le mer. 5 août 2020 à 10:39, Yves P.  a écrit :

> Pour certains DAE, il faut* indiquer comment le trouver dans le bâtiment.*
>
>

Si c'est un ERP soumis à l'obligation, c'est non conforme. Il est précisé
que cela doit être installé depuis un site accessible par tous à
l'extérieur.

Cela permettriat donc de repérer (Osmose?) les batiments des ERP et voir
s'il y a autour de leur bâtiment ou à un point accessible de l'extérieur
(pas derrière un portail fermé la nuit) l'équipement requis.

Ceci dit rien n'empêche l'ERP d'en avoir aussi à l'intérieur, mais pour son
usage interne si cela lui facilite la vie (surtout si le DAE réglementaire
se trouve loin du bâtiment principal au bout d'une allée derrière un
portail fermé le soir donc pas facilement accessible si on ne peut sortir
facilement de l'ERP).

Mais cela ne l'abstient pas d'installer et entretenir le DAE réglementaire
à l'extérieur et pour tous, à toute heure (oui, aussi la nuit quand l'ERP
est fermé et n'a plus de personnel ou juste des personnels de
sécurité/surveillance qui ne doivent pas empêcher l'accès au DAE
réglementaire). Seront concernés par exemples les DAE dans les galeries
marchandes de centres commerciaux fermés la nuit mais suppléant le DAE
réglementaire accessible de l'extérieure depuis le parking public: ceux
dans la galerie étant plus pratiques et plus faciles d'accès dans la
journée.

Je me demande si la loi impose un nombre d'équipements en fonction de la
fréquentation ou la taille de l'ERP. Ce n'est pas la même chose pour un
petit gymnase municipal et un grand parc de loisirs (p.ex. Disneyland
devrait en avoir en divers endroits dans le parc pour satisfaire les
besoins réels: restaurants, hôtels, principales attractions intérieures ou
extérieures, et ceci indépendamment du fait que le parc dispose de ses
équipes de sécurité et de secours aux personnes déjà sur place et toute
l'année).

De même pour la tour Eiffel, il devrait y en avoir aux principaux étages
les plus fréquentés sans avoir à attendre et emprunter les quelques
ascenseurs. De même dans les grands musées (le Louvre devrait en avoir dans
ses couloirs sans avoir à sortir de l'enceinte), à moins que le lieu
dispose de ses propres équipes d'assistance sur place facilement joignables
apportant le matos nécessaire (DAE, civière) et en principe bien formée aux
gestes d'urgence (même si ce ne sont pas des pompiers mais des sociétés de
sécurité qui doit les former).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

[leni]

Le 05/08/2020 à 17:15, Yves P. a écrit :
Il semble que le ref soit calculé de la même façon 
"ref=megalithic.co.uk 9857" vers la 
pagehttps://www.megalithic.co.uk/article.php?sid=9857:
Oui. On le retrouve dans la propriété wikidata P4356 
.


On peut donc créer un clé ref:megalithic et la rajouter dans wikidata.
Ainsi, un clic droit dans JOSM sur le tag pointera directement sur la 
bonne page de ce site :)


http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=33300

Il y a aussi une propriété sur wikidata : P4346 
 et sont format d'URL.


Encore une clé à créer dans OSM ?
ref:t4t35 ??

Ou créer un mécanisme pour proposer un lien dans JOSM (et consorts) à 
partir de wikidata (pour éviter à Marc de s'arracher les cheveux)


Par exemple pour le Dolmen de Mané Rohr 
 
https://overpass-turbo.eu/s/WMF

site_type=megalith and wikidata →

  * identifiant T4T35 7271
 →
http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=7271
  * identifiant Mérimée PA00091767
 →
https://www.pop.culture.gouv.fr/notice/merimee/PA00091767

Désolé, je ne comprends toujours rien à wikidata ; je vais remplacer ces 
ref:fr par une une note  ; et mettre un lien vers tes réponses ?


leni

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

Re: [talk-cz] Pravidelně obdělávané polní cesta

[Miroslav Suchy]

Dne 06. 08. 20 v 18:01 VladaC napsal(a):
> v tomhle konkrétním případě se dá na existence cesty zaručit právě tak od 
> toho jara do orby. Když se cesta nestihne do
> zimy projezdit, tak potom v mokré zimě nemusí být sjízdná prakticky vůbec.
> 

Aha. Mě napadl případ
  https://www.openstreetmap.org/way/225608456
což je stezka v poli, která je na jaře a na podzim pravidelně zoraná. Ale do 
druhého dne tam je znovu, protože je tam
provoz jak na Václaváku.
M.


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

Re: [talk-cz] Pravidelně obdělávané polní cesta

[<0174]

Ahoj,

já si myslím, žes to zmapoval dobře. Pokud je sjízdná každoročně v létě 
a na jaře, tak bych to nechal, jak píšeš. Pokud to záleží na tom, co se 
zrovna zaseje, asi bych nechal jen seasonal=yes, protože, co si budeme 
povídat, "seasonal=spring;summer" je spíš pro dobrý pocit, v lepším 
případě si to renderer přeloží jako "seasonal != no" a upozorní 
uživatele, že něco může být špatně.


Ale možná to nějaký umí a pro renderer stejně nemapujeme :)

<0174

Dne 6. 8. 2020 v 18:01 VladaC napsal(a):


> To asi není úlně pravda. V zimě tam ta cesta je (aspoň v těch přípdech
> co znám já). Stejně tak na jaře. Prostě tam není
> jenom pár dní po orbě.
>
> Já bych to osobně vůbec neřešil. Pokud ano tak visibility=* plus ten 
tracktype.

>
> M.

Díky. Jsem začátečník, nerad bych vložil do mapy cestu, kterou pak 
bude někdo marně hledat. Bohužel to záleží na počasí, momentálně 
pěstované plodině atd. - v tomhle konkrétním případě se dá na 
existence cesty zaručit právě tak od toho jara do orby. Když se cesta 
nestihne do zimy projezdit, tak potom v mokré zimě nemusí být sjízdná 
prakticky vůbec.


Hádám, že většina map tagy jako seasonal nebo visibility stejně 
koncovému uživateli nijak nepředají?



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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Jacques Lavignotte]

Le 05/08/2020 à 10:38, Yves P. a écrit :


Comment publier des photos utiles ?
Une, deux ?


Une : https://postimg.cc/zHk0cms3


Sur quel site ? Dans quels champs ?



image=*

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [talk-cz] Pravidelně obdělávané polní cesta

[VladaC]

> To asi není úlně pravda. V zimě tam ta cesta je (aspoň v těch přípdech
> co znám já). Stejně tak na jaře. Prostě tam není
> jenom pár dní po orbě.
>
> Já bych to osobně vůbec neřešil. Pokud ano tak visibility=* plus ten
tracktype.
>

> M.




Díky. Jsem začátečník, nerad bych vložil do mapy cestu, kterou pak bude
někdo marně hledat. Bohužel to záleží na počasí, momentálně pěstované
plodině atd. - v tomhle konkrétním případě se dá na existence cesty zaručit
právě tak od toho jara do orby. Když se cesta nestihne do zimy projezdit,
tak potom v mokré zimě nemusí být sjízdná prakticky vůbec.





Hádám, že většina map tagy jako seasonal nebo visibility stejně koncovému
uživateli nijak nepředají?
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[Yves P.]

> Il me semble que le tag pour ça c'est plutôt defibrillator:location
> 
> Et en version simplifiée comme dit Yves.
> 
> Mais sans name=Mairie. C'est le DAE de la mairie, à côté de la mairie,
> dans la mairie Et non quand je cherche la mairie je ne cherche pas
> un DAE nommé Mairie. Là, c'est la proximité qui doit permettre
> d'indiquer que c'est à telle adresse près/dans tel équipement (public en
> général).
Oui et non :D

Ce que tu décris fonctionne bien pour trouver un DAE visuellement sur la carte.
Je vois un logo de DAE à côté ou dans la mairie.

Par contre, si tu dois expliquer à quelqu'un où se trouve le DAE (pourquoi pas 
avec une synthèse vocale) où trouver l'info ?
Pour l'adresse on fait un géo codage inverse et ça roule.

Pour dire que c'est contre le mur de la mairie ou dans la mairie, c'est plus 
dur pour une machine.

Dans OsmHydrant (cf. copie d'écran 
),
 on a une photo, on "voit" le logo du DAE à côté de celui de la mairie, mais 
pour moi il manque un titre bien visible "Mairie".

> J'avais fait une passe sur les DAE brestois (issus d'une base locale).
> 
> http://overpass-turbo.eu/s/WOK 
On a plusieurs tags pour une même infos.
Plusieurs infos dans un même tag (titre, localisation, date, parfois même le 
téléphone)
Je n'ai pas vu de photos. Elles sont dans Wikimedia Commons à la sauce OSM 
Hydrant ?

Il y a donc besoin de normaliser ça (quelque soit l'éditeur utilisé).

Et ça serait intéressant de voir avec quel éditeur ça a été éditer ?
(defibrillator:location avec JOSM, note avec id ?)

__
Yves
"note": "A l'exterieur de la Mairie de Saint-Pierre. 24/24 / Ajout : 
18/05/12",
"defibrillator:location": "À l'extérieur de la Mairie des Quatre-Moulins",
"note": "Au CCI (Port de Commerce) / Ajout : 18/05/12",
"defibrillator:location": "À l'intérieur du Trésor Public",
"note": "A l'EHPAD (résidence BRANDA) / Ajout : 18/05/12",
"defibrillator:location": "À l'extérieur de la Mairie du quartier de 
Saint-Marc.",
"defibrillator:location": "A l'extérieur de la Mairie de Bellevue",
"note": "A l'extérieur de la Mairie du quartier de l'Europe. 24/24. TEL:02 
98 34 26 30 / Ajout : 18/05/12",
"defibrillator:location": "À l'extérieur de la mairie de quatier",
"note": "A l'IFAC (CCI) / Ajout : 18/05/12",
"note": "A l'Hôpital des Armées / Ajout : 20/05/2012",
"note": "Au groupe scolaire Kerichen / Ajout : 20/05/12",
"note": "A la CPAM (Caisse primaire d'assurance maladie) / Ajout : 
20/05/2012",
"note": "A la résidence Ker Héol / Ajout : 20/05/12",
"note": "Au Centre Commercial Géant - Phare de l'Europe / Ajout : 20/05/12",
"note": "Au CIN (Centre d'Instruction Navale)/ Accès restreint / Ajout : 
03/06/12",
"note": "Au Centre de Soins de Suite et de Réadaptation TY YANN / Ajout : 
03/06/12",
"note": "A l'UBO (Université de Bretagne Occidentale), 13 défibrillateurs 
sont répartis sur le site / Ajout : 03/06/12",
"note": "Au groupe scolaire La Croix Rouge / Ajout : 03/06/12",
"note": "Chez Alcatel-Lucent / Ajout : 03/06/12",
"note": "A l'UFR Sciences et Techniques, à l'entrée du batiment C au 
rez-de-chaussée - Ajout 21/07/2012"
"defibrillator:location": "A l'infirmerie du Collège - Lycée Charles de 
Foucauld",
"note": "A Brest'aim (ex SOPAB) - Ajout 21/07/2012",
"note": "A la Marina du Port du Chateau / Ajout : 23/07/12",
"note": "Au Fourneau / Ajout : 23/07/12",
"note": "A la Piscine de Recouvrance / Ajout : 23/07/12",
"note": "Au centre Commercial Iroise/ Ajout :  23/07/12",
"note": "Au Quartz / Ajout : 23/07/12",
"note": "A Océanopolis / Ajout :  23/07/12",
"layer": "-2",
"note": "Situé dans le parking Liberté, Entrée côté Rue Jean Jaurès / Ajout 
: 23/07/12",
"note": "A la residence Amitie D'Armor / Ajout : 23/07/12",
"note": "A la marina du Moulin-Blanc / Ajout : 23/07/12",
"defibrillator:location": "Au Parking Jaurès, entrée par la Rue Yves 
Collet",
"defibrillator:location": "Au Parking de Coat-Ar-Gueven, Entrée par Rue 
Malherbe ou Rue Dupleix",
"note": "A la piscine Foch, centre de secours à proximité/ Ajout : 
23/07/12",
"note": "Au SDIS 29/ Ajout : 23/07/12",
"note": "Au Centre d'examens de Santé / Ajout : 23/07/12",
"defibrillator:location": "A la piscine Saint-Marc",
"defibrillator:location": "A la piscine de Kerhalet",
"defibrillator:location": "A la patinoire Rinkla Stadium",
"defibrillator:location": "A la piscine Ferdinand Buisson",
"defibrillator:location": "A l'ENSTA Bretagne (ex-ENSIETA)",
"defibrillator:location": "A la Caserne des Sapeurs Pompiers",
"description": "Dans le hall de la gare de Brest, vers l'accès aux quais à 
gauche",
"name": "défibrillateur",
"note": "A l'entrée de la vie scolaire du lycée."
"operator": "PC Sécurité",

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[osm . sanspourriel]

Il me semble que le tag pour ça c'est plutôt defibrillator:location

Et en version simplifiée comme dit Yves.

Mais sans name=Mairie. C'est le DAE de la mairie, à côté de la mairie,
dans la mairie Et non quand je cherche la mairie je ne cherche pas
un DAE nommé Mairie. Là, c'est la proximité qui doit permettre
d'indiquer que c'est à telle adresse près/dans tel équipement (public en
général).

J'avais fait une passe sur les DAE brestois (issus d'une base locale).

http://overpass-turbo.eu/s/WOK

Visiblement je n'ai pas assez fait le ménage comme on voit ici :

un défibrillateur qui est un point adresse
https://www.openstreetmap.org/node/1774509098

alors qu'il y a à côté un beau point adresse sans redondance :
https://www.openstreetmap.org/node/1702549045

Au fait on voit au passage que la source était privé ou n'est plus publique.

Pour le machin de GeoDAE c'est au plus official_name !

On met des contact:addr ?

Christian, quand je parlais de rapprochement, je pensais à rapprocher
les coordonnées OSM du géocodage (propre, pas Geo DAE) de l'adresse Geo
DAE. Même ça c'est pourri ?

Jean-Yvon

Le 06/08/2020 à 16:32, PanierAvide - panierav...@riseup.net a écrit :

Bonjour à tous,

Suite au travail lancé pour ajouter des jeux de données dans Osmose
autour des défibrillateurs, la question se pose de la pertinence du
tag name=* sur les défibrillateurs [1,2]. En effet, dans les jeux de
données (GéoDAE, AEDMAP, bases locales), un nom est souvent associé au
DAE. Ce nom est plutôt descriptif, exemples "DAE de la mairie",
"Défibrillateur de la salle XYZ". Dans certains cas, il ressemble
plutôt à une référence. Il est proposé ainsi d'opter pour
l'utilisation de ref=* ou description=*.

En parallèle, dans la base de données OSM aujourd'hui, on constate que
14% des DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou
description=* (moins de 3% ?). Une requête Overpass fait ressortir que
les valeurs du champ name=* sur les DAE sont plutôt descriptives.
C'est un usage qui dépasse nos frontières à la vue des langues
utilisées. Même si ce sont des noms descriptifs, l'usage montre que
name=* est l'attribut pour stocker cette info.

La question est donc la suivante : doit-on préferer le champ name=*
pour cette info (usage international), utiliser un champ ref=* (plus
logique sémantiquement, mais qui sera une spécificité FR), voire ne
pas proposer d'ajouter l'info du nom dans OSM (arbitrage simple mais
on perd une info) ? Merci pour vos avis qui permettront de débloquer
l'ajout de nouveaux jeux dans Osmose :-)

Cordialement,

[1] https://github.com/osm-fr/osmose-backend/issues/936
[2] https://github.com/osm-fr/osmose-backend/pull/940




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

[OSM-talk-fr] Presets - Re: Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> effectivement ça vaudrait le coup de vérifier les presets JOSM et iD (tu 
> pourrais t'en occuper ?).
> 
Les copies d'écran sont là : 
https://wiki.openstreetmap.org/wiki/User:Pyrog/defibrillateurs 


Dans JOSM c'est bien structuré : il manque le fameux tag name (en discussion) 
et la référence (notre ref:FR:GeoDAE).
Il faudrait probablement réorganiser les champs :
"nom"
description de l'emplacement
référence
boutons radio : extérieur / intérieur / ?
…

Dans iD, il manque l'essentiel : le nom du lieu, et l'emplacement dans ce lieu.

Dans les 2 cas, il n'y a rien pour suggérer de mettre une ou plusieurs photos 
dans le tag approprié.

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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[Yves P.]

> Pareil... name c'est pas là pour décrire un objet.
+1 pour une description "boite carré verte avec un voyant clignotant" :D

Par contre, ça peut-être considérer comme un nom :

Arrêt de bus "Mairie". C'est une description ? ;-)


> Pour moi, ce n'est donc pas un name=*, ce serait à concaténer avec les 
> instructions de localisation (au vu de ceux que j'ai voulu intégrer), sinon 
> on va avoir un bout dans un tag et l'autre dans un autre…
Tu proposes quoi concrètement ?

Dans les applications, sites web, listes en tout genre de DAE que j'ai consulté 
on trouve souvent deux infos (en plus de la géolocalisation) :
Un "titre".
Une description claire et concise de l'accès.

"Salle des fêtes" et "dans le hall du RdC à gauche"

Un pompier au CTA qui indique par téléphone la position du DAE ne va pas donner 
de coordonnées GPS.
Il se focalise sur l'info essentielle : c'est à la mairie, puis détail le reste…

> Le fait que name soit souvent mal employé n'est pas une raison suffisante 
> pour continuer.
Je maintiens que name est le plus adapté maintenant.

Une fois un consensus trouvé au niveau international, on aura plus qu'à faire 
des modifications de masses : name → le_bon_tag_sémantiquement_parlant

__
Yves


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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[Christian Quest]

Le 06/08/2020 à 16:43, Yves P. a écrit :

Suite au travail lancé pour ajouter des jeux de données dans Osmose autour des défibrillateurs, la 
question se pose de la pertinence du tag name=* sur les défibrillateurs [1,2]. En effet, dans les 
jeux de données (GéoDAE, AEDMAP, bases locales), un nom est souvent associé au DAE. Ce nom est 
plutôt descriptif, exemples "DAE de la mairie", "Défibrillateur de la salle 
XYZ". Dans certains cas, il ressemble plutôt à une référence. Il est proposé ainsi d'opter 
pour l'utilisation de ref=* ou description=*.

En parallèle, dans la base de données OSM aujourd'hui, on constate que 14% des 
DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou description=* 
(moins de 3% ?). Une requête Overpass fait ressortir que les valeurs du champ 
name=* sur les DAE sont plutôt descriptives. C'est un usage qui dépasse nos 
frontières à la vue des langues utilisées. Même si ce sont des noms 
descriptifs, l'usage montre que name=* est l'attribut pour stocker cette info.

Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)



Pareil... name c'est pas là pour décrire un objet.

Pour moi, ce n'est donc pas un name=*, ce serait à concaténer avec les 
instructions de localisation (au vu de ceux que j'ai voulu intégrer), 
sinon on va avoir un bout dans un tag et l'autre dans un autre...


Le fait que name soit souvent mal employé n'est pas une raison 
suffisante pour continuer.


--
Christian Quest - OpenStreetMap France


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

Re: [talk-cz] Pravidelně obdělávané polní cesta

[Miroslav Suchy]

Dne 06. 08. 20 v 12:48 VladaC napsal(a):
> V poslední době pozoruju, že mnoho polních cest - i dost frekventovaných, 
> dobře sjízdných a v katastru vyznačených -
> zemědělci každý rok po sklizni obdělají a osejí. Následně cestu ve stejné 
> trase někdo projede (často asi ten samý, kdo
> ji předtím rozoral) a dalším projížděním se postupně obnoví. Zřejmě to 
> souvisí s tím, jak se používají čím dál větší
> stroje, pro které je nejefektivnější obdělávat co největší lány v celku.
> 
> Jak takovou cestu tagovat?
> Zatím jsem dal:
> 
> seasonal=spring;summer
To asi není úlně pravda. V zimě tam ta cesta je (aspoň v těch přípdech co znám 
já). Stejně tak na jaře. Prostě tam není
jenom pár dní po orbě.

Já bych to osobně vůbec neřešil. Pokud ano tak visibility=* plus ten tracktype.

M.

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

Re: [OSM-talk-fr] Défibrillateur et tag name=*

[Yves P.]

> Suite au travail lancé pour ajouter des jeux de données dans Osmose autour 
> des défibrillateurs, la question se pose de la pertinence du tag name=* sur 
> les défibrillateurs [1,2]. En effet, dans les jeux de données (GéoDAE, 
> AEDMAP, bases locales), un nom est souvent associé au DAE. Ce nom est plutôt 
> descriptif, exemples "DAE de la mairie", "Défibrillateur de la salle XYZ". 
> Dans certains cas, il ressemble plutôt à une référence. Il est proposé ainsi 
> d'opter pour l'utilisation de ref=* ou description=*.
> 
> En parallèle, dans la base de données OSM aujourd'hui, on constate que 14% 
> des DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou description=* 
> (moins de 3% ?). Une requête Overpass fait ressortir que les valeurs du champ 
> name=* sur les DAE sont plutôt descriptives. C'est un usage qui dépasse nos 
> frontières à la vue des langues utilisées. Même si ce sont des noms 
> descriptifs, l'usage montre que name=* est l'attribut pour stocker cette info.
Tient, ça me rappel la discussion sur les panneaux d'informations touristiques 
;)

> La question est donc la suivante : doit-on préferer le champ name=* pour 
> cette info (usage international), utiliser un champ ref=* (plus logique 
> sémantiquement, mais qui sera une spécificité FR), voire ne pas proposer 
> d'ajouter l'info du nom dans OSM (arbitrage simple mais on perd une info) ? 
> Merci pour vos avis qui permettront de débloquer l'ajout de nouveaux jeux 
> dans Osmose :-)
Evitons le franco-français : name est parfait
(Il faut peut-être vérifier que les moteurs de rendu ne l'affichent pas).

Pour moi la question est : que mettre dedans pour retrouver un DAE rapidement ?

name="DAE de la mairie" est trop descriptif.

Je préfère :

name="Mairie"
defibrillator:location="Au premier étage à droite"

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

[OSM-talk-fr] Défibrillateur et tag name=*

[PanierAvide]

Bonjour à tous,

Suite au travail lancé pour ajouter des jeux de données dans Osmose 
autour des défibrillateurs, la question se pose de la pertinence du tag 
name=* sur les défibrillateurs [1,2]. En effet, dans les jeux de données 
(GéoDAE, AEDMAP, bases locales), un nom est souvent associé au DAE. Ce 
nom est plutôt descriptif, exemples "DAE de la mairie", "Défibrillateur 
de la salle XYZ". Dans certains cas, il ressemble plutôt à une 
référence. Il est proposé ainsi d'opter pour l'utilisation de ref=* ou 
description=*.


En parallèle, dans la base de données OSM aujourd'hui, on constate que 
14% des DAE ont un tag name=* associé. C'est plus que ref=* (5%) ou 
description=* (moins de 3% ?). Une requête Overpass fait ressortir que 
les valeurs du champ name=* sur les DAE sont plutôt descriptives. C'est 
un usage qui dépasse nos frontières à la vue des langues utilisées. Même 
si ce sont des noms descriptifs, l'usage montre que name=* est 
l'attribut pour stocker cette info.


La question est donc la suivante : doit-on préferer le champ name=* pour 
cette info (usage international), utiliser un champ ref=* (plus logique 
sémantiquement, mais qui sera une spécificité FR), voire ne pas proposer 
d'ajouter l'info du nom dans OSM (arbitrage simple mais on perd une 
info) ? Merci pour vos avis qui permettront de débloquer l'ajout de 
nouveaux jeux dans Osmose :-)


Cordialement,

[1] https://github.com/osm-fr/osmose-backend/issues/936
[2] https://github.com/osm-fr/osmose-backend/pull/940

--
Adrien P.


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

[Talk-it] OpenStreetMap compie 16 anni

[Anisa Kuci]

Ciao a tutti,

Quest'anno OSM compie 16 anni! \o/

Paesi di tutto il mondo hanno organizzato piccole iniziative per 
festeggiare il 16° compleanno 
 
questo fine settimana.


Mi sarebbe piaciuto proporre un incontro di persona, in modo che 
potessimo avere la possibilità di vederci e incontrarci, ma come tutti 
sappiamo non è possibile vista la situazione.


Allora, adattiamoci!

Ognuno manda gli auguri di compleanno a OSM da qualsiasi luogo si trovi, 
pubblicando su Facebook o Twitter una foto del suo gadget OSM più 
interessante o una foto propria con il gadget OSM o foto di cosa sta 
attualmente mappando in OSM.
Per favore taggate OSM Italia o inviatemi i link dei vostri post in modo 
da poterli poi condividere dai canali di OSM Italia (Facebook - 
@OpenStreeMap.Italia  / 
Twitter - @OpenStreetMapIt ), e non 
dimentichiamoci di usare l'hashtag #OpenStreetMap16. :D


Per chi non ha un account sui social, mandatemi entro questo weekend su 
telegram (AnisaKuci) o email una delle foto qui sopra e un'augurio e 
farò un album da condividere nei social di OSM Italia.


Grazie mille a tutti e buona mappatura,

Anisa

--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

Re: [Talk-es] Consulta de la OSMF: reestructuración de la Dirección de Asesoría, financiación del desarrollo de los editores de OSM

[Angel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


No me considero yo muy activo en OSM, pero no me parece que sea una
buena noticia que ande FB por aquí. No sé que se podría hacer. Cuando
Oracle se hizo con Sun y a su vez con mySQL se hizo un fork que es
MariaDB, no sé si con OSM se podría hacer.

Saludos

El 4/8/20 a las 22:23, franciscoferiolimarco via Talk-es escribió:
> Buenas tardes/noches, envío por primera vez un correo a esta lista. De
> hecho es la primera vez que envío un correo a una lista de correos.
>
> Por sugerencia de un administrador del grupo de Telegram OSM España,
> envío la traducción al español del debate que tuve con algunos miembro
s
> de OSM UK en Loomio.
> Dejo a disposición el enlace para que puedan ver los comentarios origi
nales:
> https://www.loomio.org/d/bgUF4wMz/osmf-consultation-advisory-board?dis
cussion_reader_token=qwxYk2C9qMB16DrUocf5i8Hc_campaign=discussion_ma
iler_medium=email_source=discussion_announced
>
> Mis comentarios intentan responder bajo una misma publicación tanto la
> consulta que se hizo a través del enlace de arriba como la consulta qu
e
> se hizo en este enlace:
> https://www.loomio.org/d/nlXVMYmt/osmf-consultations-funding-core-infr
astructure?discussion_reader_token=nnMNMYu4guVxV4sRecwZk1v6_campaign
=discussion_mailer_medium=email_source=discussion_announced
>
> Como complemento, me parece importante subrayar la estrategia de
> negocios que está llevando adelante Facebook para crear un conjunto de
> productos que trabajen de forma coordinada:
>
>   * 2014: adquisición de Oculus VR, un "casco" de realidad virtual.
>   * 2016: desarrollo de Pytorch mediante su laboratorio de investigaci
ón
> en Inteligencia Artificial.
>   * 2020: adquisición de Mapillary, plataforma de mapas e imágenes 3D
> georreferenciadas, las cuales pueden ser analizadas mediante las
> tecnologías de visión artificial desarrolladas por Mapillary.
>   * : postulación exitosa para para formar parte de la Dirección d
e
> la OSMF.
>
> La lista de arriba es un pequeño resumen/adaptación del artículo que
> publicó Joe Morrison en Medium:
> https://medium.com/@joemorrison/why-on-earth-did-facebook-just-acquire
- -mapillary-9838405272f8
>
> No les parece que la comunidad del software abierto le está cediendo
> demasiado poder a esta empresa que no tiene el más mínimo sentido de l
a
> ética?
>
> Pueden ver la traducción del sitio en tiempo real visitando este enlac
e:
> https://translate.yandex.com/translate
>
> Aunque sugiero leer directamente el texto plano traducido por deepl.co
m,
> ya que las traducciones suelen ser de mayor calidad:
>
> --
- 
- 
- -
>
> OpenStreetMap UK , 31 de
 Julio
>
>
> *Consulta OSMF: Dirección de asesoría
> *
> *RobJN · Director · Público · Visto por 40*
>
> Hola a todos. Los osmf están consultando sobre los cambios en su
> junta asesora. Actualmente esto tiene representantes de los
> capítulos locales (yo para nuestro capítulo local) y representante
s
> de miembros corporativos de oro. La propuesta es dividir esto en d
os.
>
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/0069
84.html
>
> Si desean que les envíe algún comentario, no duden en publicarlo a
quí.
>
> Gracias.
>
> --
- 
- 
- -
>
> *Nick · 2 Ago*
>
> Dado que los desafíos locales pueden ser bastante diferentes,
> probablemente tenga sentido dividir la carga de trabajo. En cuanto
 a
> los nombres, tal vez las alternativas podrían ser Junta Consultiva
> Mundial (por ejemplo, visión general estratégica, enfoque en
> programas grandes, por ejemplo, HOT, normas de datos, etc.) y Junt
as
> Consultivas Locales (lo que es más pertinente para las comunidades
> locales, enfoque nacional o similar) para reflejar la naturaleza
> geográfica de los desafíos futuros. Esto también puede ayudar a
> identificar el nivel de colaboración con diversos organismos, por
> ejemplo, el GAB trabaja en estrecha colaboración con las
> organizaciones mundiales de ayuda humanitaria para apoyar sus
> necesidades. Es posible que cada vez más tengamos que ser
> conscientes del propósito de hacer mapas y de los aspectos polític
os
> que esto puede implicar. En cuanto a la composición, tiene sentido
> un enfoque flexible, sobre todo porque la elaboración de mapas se
> hará más compleja (por ejemplo, el aumento del uso de la IA, los
> imperativos políticos) y puede exigir que se aporten 

[OSM-talk-fr] Ajout de l'ortho-photo de Bordeaux 2016 sur wms.openstreetmap.fr

[Christian Quest]

Je ne sais pas pourquoi je ne l'avais pas déjà ajoutée sur 
wms.openstreetmap.fr, peut être à cause du clicodrome pour récupérer les 
dalles d'images ?


Je l'ai ajoutée hier, couche bordeaux_2016 mais aussi intégrée à la 
couche "tous_fr" qui est la composite avec priorité données aux orthos 
les plus récentes/précises et que je vous recommande.


--
Christian Quest - OpenStreetMap France


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

[Talk-es] Ediciones usuario jlcc78

[xyg...@gmail.com]

Ha vuetlo a revertir los cambios en Medina del Campo, de momento los he dejado 
para no entrar en una guerra inútil dad su actitud.

Copio dos de sus mensajes, donde reconoce como fuente Google Maps:

A ver chaval. Ese es el nombre de esas calles en Medina del Campo. Solo tienes 
que utilizar otros mapas (google map) para ver que no hay vanadalismo alguno y 
lo tuyo es un invento y probablemente obsesión con otros ususarios de OSM. De 
vandalismo nada. Procedo a poner de nuevo el nombre real que tiene en esa 
localisdad las calles.

DE vandalismo nada. Es el nombre de esas vias en Medina del Campo. Véase Google

Un saludo.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] bug calcul itinéraire - Aire du viaduc de Millau

[Cyrille37 OSM]

Le 06/08/2020 à 12:18, Percherie OnDaNet a écrit :


C'est aussi vers cette réflexion que je m'orientais. Les données sont 
cohérente avec le terrain mais c'est au routage de s'adapter.


Après essai sur l'Aire d'Hastingues : 
https://www.openstreetmap.org/way/473891861 :


  * OSRM : échec
  * GraphHopper : échec

Juste pour imager le bug des routeurs avec cet exemple. Le routeur 
calcule un grand détour pour arriver au plus près du bâtiment, et manque 
donc la bretelle d'accès à l'aire.


https://pic.infini.fr/8qC7lhmj/6KJCdWLv

capture d'écran résultat routeurs OSM et Graphopper

Cyrille37.

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

[Talk-es] Ediciones usuario jlcc78

[xyg...@gmail.com]

Después de haber teminado su temporada de bloque, el usuario jlcc78 ha vuelto a 
las andadas:

- En el conjunto de cambios 89029211 ha cambiado el nombre de la carretera por 
su referencia: Carretera de Madrid a A Coruña por N-6
- En el conjunto #89028659 ha realizado otros cambios de nombre en principio 
más “inocuos” pero que también son incorrectos: ha cambiado el nombre de una 
parte de la N-6 por Camino de Santiago, ha movido el inicio de la Avenida de La 
Coruña para eliminar una parte del nombre de la N-6 y ha ampliado otra avenida 
para eliminar otro nombre. He comprobado las denominaciones en el Catastro y en 
algunos planos disponibles en la web del ayuntamiento de Medina del Campo y 
esos cambios no son correctos.

Un saludo
Jesús
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] [Osmf-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Colin Smale]

On 2020-08-06 11:47, Martin Koppenhoefer wrote:

> Am Do., 6. Aug. 2020 um 11:26 Uhr schrieb Lukasz Kruk 
> : 
> 
>> I'm not sure what rules govern this: "Londn" does find the capital of the 
>> UK, but "Warszaw" does not find the capital of Poland...?), which is only a 
>> little inconvenient when compared to the second-best online map.
> 
> this is because Londn is apparently the name in West Flemish 
> Londn (name:vls) 
> https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=65606

And which language is "Warszaw" supposed to be? It doesn't seem to match
any of the name strings in OSM. 
https://www.openstreetmap.org/relation/336074___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] Mapping disaperead vicinal paths

[joost schouppe]

Hi,

The example Wouter showed hurt my eyes too much, so I have deleted some
bits; I marked a few that maybe exist as fixme:highway for now. The user
also didn't snap roads to the rest of the road network properly.
If they don't respond to comments, we might have to consider a user block.
A convincing argument for them to do the work properly could be that we
might be forced to just revert all their work.

Best,
Joost

Op do 6 aug. 2020 om 10:45 schreef Wouter Hamelinck <
wouter.hameli...@gmail.com>:

> Hi,
>
> Let me start by saying that I have all the sympathy for the aims of the
> mapper. I also have been working with communities to keep vicinal ways
> open. I am also aware that certain ways are only accessible certain times
> of the year due to vegetation etc. Even if a path is not visible at the
> moment you pass there, it might be at other times of the year. In general I
> advocate leaving paths through fields (even plowed) that are legal rights
> of way. My reasoning is that as soon as you pass with a small group a kind
> of path will be visible. On the other hand, if the legal right of way
> crosses buildings, gardens, canals... it makes no sense to put those in
> OSM. Nobody will ever follow those.
>
> With that in mind, I've taken a look at some of the changesets that you
> linked to. I didn't like what I saw. People who want to check only one
> example, this is a good one: https://www.openstreetmap.org/way/833838389
> There is no place in OSM for that kind of legal fiction. Even not knowing
> the situation on the ground, it is clear to me that nobody will try to
> follow that track. So I would say to revert changes like that.
>
> As for the arguments of the mapper:
> * Putting something in OSM does not put any pressure on the owner. Nobody
> will be impressed by the argument "you have to keep the way open because I
> just put it on a website where everybody can put things".
> * It makes the data in OSM useless. The tracks in OSM are used on a daily
> basis by many, many hikers. The presence of legal fictions in OSM makes it
> useless for them. They don't care where they should be able to pass in
> theory. They want to know where they can pass in reality.
>
> In conclusion, the mapper is trying to have some very dubious advantage
> for his personal use and by doing that makes the data useless for all other
> users. For me it is clear that those ways should be removed.
>
> Regards,
> Wouter
>
> On Thu, Aug 6, 2020 at 8:21 AM Matthieu Gaillet 
> wrote:
>
>> Hi,
>>
>> Recently an user mapped a set of disappeared “communal” or "vicinal”
>> ways. By disappeared I mean they are physically absolutely not existent on
>> the ground. They were either plowed or constructions were built right on
>> them.
>>
>> I believe it goes against the general rule that states that one might
>> only map what’s visible on the field. Additionally the mapping itself was
>> poorly done and the source mentioned was not relevant.
>>
>> Using the tag [
>> 
>> trail]_visibility
>> =no
>> 
>>  is
>> not an option here since the user decided to map a unmaintained track road
>> (with width = 4m !) that doesn’t offer such option.
>>
>> He denied reverting the changeset, arguing that mapping those paths was a
>> way to put pressure on the Commune and the owner in a discussion about the
>> openness and accessibility of surrounding paths for the general public. He
>> promised to delete the date once the case will be closed.
>>
>> Les sentiers et chemins que j'ai repris sur OSM sont légalement toujours
>> existants et personne n'est en droit d'empêcher quiconque de les utiliser,
>> de les réhabiliter ou de les débroussailler... c'est une façon de mettre la
>> pression sur le riverain... dès que des alternatives auront été créées et
>> un bon accord conclu, j'effacerai les données au profit des alternatives
>> qui auront été proposées.
>>
>>
>> The changesets :
>> https://www.openstreetmap.org/changeset/88927383
>> https://www.openstreetmap.org/changeset/88927894
>> https://www.openstreetmap.org/changeset/88927825
>> https://www.openstreetmap.org/changeset/88927566
>>
>>
>> What do you think ? I believe that’s not a good way of doing things (I
>> don’t believe in maptivism in this situation) but can’t really find a clear
>> position of the community about this particular case.
>>
>> I don’t want to start a fight with that user because he’s really doing a
>> great job at preserving the right of use of those heritage vicinal ways by
>> confronting the Communes against those unfair owners. I would like to show
>> him some string arguments to explain him why his initiative is not good for
>> the community (If that’s the case).
>>
>> Thanks for sharing your thoughts.
>> Matthieu Gaillet
>>
>> ___
>> 

[talk-cz] Pravidelně obdělávané polní cesta

[VladaC]

V poslední době pozoruju, že mnoho polních cest - i dost frekventovaných,
dobře sjízdných a v katastru vyznačených - zemědělci každý rok po sklizni
obdělají a osejí. Následně cestu ve stejné trase někdo projede (často asi
ten samý, kdo ji předtím rozoral) a dalším projížděním se postupně obnoví.
Zřejmě to souvisí s tím, jak se používají čím dál větší stroje, pro které je
nejefektivnější obdělávat co největší lány v celku.




Jak takovou cestu tagovat?

Zatím jsem dal:




seasonal=spring;summer

surface=earth


tracktype=grade5


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

Re: [Talk-us] Marking structure as damaged or condemned

[Mateusz Konieczny via Talk-us]

Is building completely destroyed (no longer existing)?

Simply delete it or remove building tag and use demolished:building=yes / 
not:building=tag,
possibly add also note.

Deleting is fine, but others may remap it from aerial images.



Still building, just damaged, abandoned or seriously damaged?

abandoned=yes, ruins=yes, damaged=yes is a typical tagging



I am not aware about good standard tagging for ruins that appeared recently
that are no longer a building.

Aug 6, 2020, 03:11 by talk-us@openstreetmap.org:

> Tropical Storm Isaias left several homes in my neighborhood severely damaged 
> and condemned.  Is there a proper way to map these structures?
>
> Thanks,
> Eric
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

C'est là toute la question :-) À vérifier sur d'autres analyses, il y a 
peut-être des exemples ?


Adrien P.

Le 06/08/2020 à 12:17, Yves P. a écrit :


Par contre je ne saurais pas comment on gère le rapprochement avec 
plusieurs alternatives de tags côté Osmose.
Un seul analyseur avec les tags *emergency=defibrillator* et 
*disused:emergency=defibrillator* si on peut indiquer une condition "OU" ?


Sinon deux analyseurs, un par tag mais bof.

Mapping(

select = Select(

types = ["nodes"],

tags = {"emergency": "defibrillator"}),

__
Yves

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> On a un autre point à prévoir avec l'équipe de GéoDAE après le 15 août, on en 
> parlera à ce moment là.
Tant qu'à demander, mettre aussi un export CSV, JSON…

https://geodae.atlasante.fr/dae/1234.html 

https://geodae.atlasante.fr/dae/1234.csv 

https://geodae.atlasante.fr/dae/1234.json 

…

> Je n'ai pas d'accès au portail, une démo avait été présentée il y a quelques 
> mois en visio
Ok.

J'ai demandé aux élus Jurassiens si ils en ont un…

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

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Percherie OnDaNet]

C'est aussi vers cette réflexion que je m'orientais. Les données sont 
cohérente avec le terrain mais c'est au routage de s'adapter.


Après essai sur l'Aire d'Hastingues : 
https://www.openstreetmap.org/way/473891861 :


 * OSRM : échec
 * GraphHopper : échec
 * OpenRouteService : échec
 * MapQuest : échec
 * Application OsmAnd : échec
 * Application MapFactor Navigator : déplace l'arrivé (drapeau)
   clairement sur le segment le plus proche, ça à le mérite d'être
   compréhensible
 * Application Magic Earth : échec
 * Bing Maps : échec
 * GoogleMaps y arrive seulement parce que le nœud de l'aire est bien
   positionné, autrement ça plante :
 o Trajet 1 : https://goo.gl/maps/BTma9uZD7wuTEide6
 o Trajet 2 : https://goo.gl/maps/y3XSoj7c1YPxzAJR9
 * Waze : échec avec des détours hallucinant
 * ViaMichelin plante avec une arrivée imposée en dehors de l'aire
 * Mappy ne connait pas l'aire

En l'état seul un service GAFAM y arrive. Que faut-il faire ? Remonter 
l'anomalie à tous les services ?


Le 06/08/2020 à 10:24, Christian Quest a écrit :

Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :

Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
Si on remplace par un node, je pense qu'on aura toujours le 
problème, dans un sens ou dans l'autre de l'autoroute.


Et si l'on met ce node sur une zone non accessible en voiture, par 
exemple une zone de pique-nique, peut-être que le routeur n'aura plus 
intérêt à faire effectuer un détour routier ? 


Le routeur ça chercher la voie d'accès la plus proche, y projet le POI 
d'arrivée et calculer la route sur ce point trouvé.


Cela ne résoudra pas le problème qui est en fait lié à un routage 
mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il 
trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée 
que de faire un énorme détour en voiture.


C'est pour moi plutôt un défaut des algos de routage sur le routage à 
l'arrivée qu'un problème dans les données OSM qui décrivent, il me 
semble, correctement le terrain.



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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Par contre je ne saurais pas comment on gère le rapprochement avec plusieurs 
> alternatives de tags côté Osmose.
Un seul analyseur avec les tags emergency=defibrillator et 
disused:emergency=defibrillator si on peut indiquer une condition "OU" ?

Sinon deux analyseurs, un par tag mais bof.

Mapping(
select = Select(
types = ["nodes"],
tags = {"emergency": "defibrillator"}),
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] And the USRN tag proposal page

[Robert Skedgell]

On 22/07/2020 21:52, Rob Nickerson wrote:
> As promised, here is the second tag proposal page - this time for the
> USRN (Street).
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn
> 
> As before, any comments welcome, especially those that would prevent us
> moving to the voting stage.
> 
> P.S. Does anyone know if we need to highlight these proposals to the
> tagging mailing list? If we do, could someone kindly volunteer please.
> 
> Best regards,
> *Rob*

Where a street has a separately mapped footway/sidewalk, would it be
worth considering adding the USRN to this as well? The advantage might
be that the component parts of a street (or highway in HA 1980 terms)
can be groupeed together without the need to create relations.

In cases like this, we usually have the street tagged with
sidewalk=separate and the footway(s) tagged with footway=sidewalk or
cycleway=sidewalk

-- 
Robert Skedgell (rskedgell)


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

On a un autre point à prévoir avec l'équipe de GéoDAE après le 15 août, 
on en parlera à ce moment là. Je n'ai pas d'accès au portail, une démo 
avait été présentée il y a quelques mois en visio, et j'ai jeté un coup 
d’œil par le biais de ma conjointe (qui travaille en mairie) lorsqu'elle 
a déclaré celui de son lieu de travail.


Adrien P.

Le 06/08/2020 à 12:09, Yves P. a écrit :

Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.

Oui, mais on pourrait mettre quand même un lien dessus ?
Avec un peu de chance, ça n'affiche que les informations publiques si on n'est 
pas identifié ?

Et si non, on pourrait le suggérer ?
__
Yves

PS: Je pensais que tu avais un accès à l'interface car tu semblais l'avoir 
testé ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Oui c'est sûr qu'à terme ce sera intéressant d'avoir ce niveau de 
détail. Par contre je ne saurais pas comment on gère le rapprochement 
avec plusieurs alternatives de tags côté Osmose.


Adrien P.

Le 06/08/2020 à 12:06, Yves P. a écrit :

Et ne prend en compte que les DAE notés "En fonctionnement".

Elle pourrait aussi prendre en compte les autres mais avec le tag disused: 
emergency=defibrillator ;)

Ne serait-ce que pour prévenir qu'un DAE dans OSM n'est peut-être pas à jour.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.
Oui, mais on pourrait mettre quand même un lien dessus ?
Avec un peu de chance, ça n'affiche que les informations publiques si on n'est 
pas identifié ?

Et si non, on pourrait le suggérer ?
__
Yves

PS: Je pensais que tu avais un accès à l'interface car tu semblais l'avoir 
testé ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Et ne prend en compte que les DAE notés "En fonctionnement".
Elle pourrait aussi prendre en compte les autres mais avec le tag disused: 
emergency=defibrillator ;)

Ne serait-ce que pour prévenir qu'un DAE dans OSM n'est peut-être pas à jour.
__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Réservé aux propriétaires/mainteneurs de DAE, pas de lien public.

Adrien P.

Le 06/08/2020 à 12:00, Yves P. a écrit :

Du coup il doit y avoir un lien direct sur un DAE dans ce formulaire ?

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


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

L'analyse Osmose est ici pour référence : 
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_defibrillators_FR.py


Et ne prend en compte que les DAE notés "En fonctionnement".

Adrien P.

Le 06/08/2020 à 11:05, Yves P. a écrit :

Est-ce vraiment une bonne idée ?
J'ai l'impression qu'on essaye de coller au plus près des données fournies. Si 
un défibrillateur est hors-service ou supprimé, je conseillerai plutôt de la 
cartographier en disused:emergency=defibrillator.

+1

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


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Il y a effectivement bien une interface web pour gérer ses DAE, avec un 
> formulaire progressif. Ça se prête bien au cas où on a moins d'une dizaine de 
> DAE à gérer, ou pour les mises à jour. Bon évidemment l'ergonomie du 
> formulaire pourrait être améliorée par certains aspects, mais c'est encore 
> autre chose.
Du coup il doit y avoir un lien direct sur un DAE dans ce formulaire ?

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Il y a effectivement bien une interface web pour gérer ses DAE, avec un 
formulaire progressif. Ça se prête bien au cas où on a moins d'une 
dizaine de DAE à gérer, ou pour les mises à jour. Bon évidemment 
l'ergonomie du formulaire pourrait être améliorée par certains aspects, 
mais c'est encore autre chose.


Adrien P.

Le 06/08/2020 à 11:03, Yves P. a écrit :

Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, même si 
il ne comporte qu'une ligne... ridicule.

La FAQ dit qu'on peut saisir directement un DAE dans un formulaire ;)


On avait déjà ça avec les IRVE... mais là au moins il y avait une carotte : la 
subvention versée si les données sont publiées.

Ici la carotte est de sauver potentiellement des vies :)

Pour les petites structures, il faut qu'elles connaissent l'existence de GeoDAE et de son 
formulaire de "déclaration".

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


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

Re: [OSM-talk] [Osmf-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Martin Koppenhoefer]

Am Do., 6. Aug. 2020 um 11:26 Uhr schrieb Lukasz Kruk :

>  I'm not sure what rules govern this: "Londn" does find the capital of the
> UK, but "Warszaw" does not find the capital of Poland...?), which is only a
> little inconvenient when compared to the second-best online map.
>


this is because Londn is apparently the name in West Flemish
Londn (name:vls)
https://nominatim.openstreetmap.org/ui/details.html?osmtype=R=65606

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Est-ce vraiment une bonne idée ?

> J'ai l'impression qu'on essaye de coller au plus près des données fournies. 
> Si un défibrillateur est hors-service ou supprimé, je conseillerai plutôt de 
> la cartographier en disused:emergency=defibrillator.
+1

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, même 
> si il ne comporte qu'une ligne... ridicule.
La FAQ dit qu'on peut saisir directement un DAE dans un formulaire ;)

> On avait déjà ça avec les IRVE... mais là au moins il y avait une carotte : 
> la subvention versée si les données sont publiées.
Ici la carotte est de sauver potentiellement des vies :)

Pour les petites structures, il faut qu'elles connaissent l'existence de GeoDAE 
et de son formulaire de "déclaration".

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[JB]

Je profite de la discussion pour poser la question de la traduction de « 
etat_fonct » de GeoDAE, convertie dans OSM en :
operational_status=[[Tag:operational_status=operating/out_of_order/closed/short_term_absence/unknown|operating/out_of_order 
/closed/short_term_absence/unknown]] 
(https://wiki.openstreetmap.org/wiki/FR:Tag:emergency=defibrillator#Liste_des_donn.C3.A9es_obligatoires)

Est-ce vraiment une bonne idée ?
J'ai l'impression qu'on essaye de coller au plus près des données 
fournies. Si un défibrillateur est hors-service ou supprimé, je 
conseillerai plutôt de la cartographier en disused:emergency=defibrillator.
(Si je cherche un DAE, je cherche emergency=defibrillator, sans 
forcément filtrer sur les clés « secondaires » pour vérifier qu'il 
existe réellement.)

JB.

Le 06/08/2020 à 10:30, Christian Quest a écrit :

Le 06/08/2020 à 09:10, PanierAvide a écrit :


On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de 
maintenance...). Pour l'exploitant, au moins le nom ça me semble 
essentiel, et le SIREN ça peut pas faire de mal (on a jamais trop 
d'infos...).




ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique 
que la source est ce SIREN et pas quelle est la source du SIREN... 
donc plutôt ref:FR:SIREN:source ;)



Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une 
fiche web pour chaque DAE. Quasi toutes les infos exploitables sont 
celles qui ressortent dans Osmose.



Ça viendra d'une façon ou d'une autre, si facile à mettre en place.





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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 06/08/2020 à 10:34, Yves P. a écrit :
ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.

:)

Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ?
euh, la source serait plutôt GeoDAE et plus exactement le fichier OD 
sur data.gouv.fr  ?


Ici je parle de la source d'origine... GeoDAE n'est qu'une agrégation de 
celles-ci.



Le 06/08/2020 à 10:36, PanierAvide a écrit :
C'était pas bien sinon operator:ref:FR:SIREN=* ? Comme le champ 
operator=* contient déjà le nom du gestionnaire, la tendance est à 
operator:ref=*, mais comme on précise le type de référence et bien 
operator:ref:FR:SIREN. Et en terme d'ergonomie, les deux attributs 
seront affichés à la suite dans les éditeurs ;-)



Oui, c'est une bien meilleure option


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 06/08/2020 à 10:29, PanierAvide a écrit :
C'est pas utopique si c'est une obligation légale : ça fonctionne bien 
pour les prix des carburants et les déclarations de revenus, il n'y a 
pas de raisons que ça ne fonctionne pas pour les DAE. Le tout c'est 
qu'il y ait à terme des contrôles et sanctions en cas de manquements.


Une obligation sans conséquence quand elle n'est pas respectée n'est 
qu'un beau souhait...


Pour les carburants, il y a beaucoup moins de stations, et les plus 
petites sont exemptées de remonter leurs prix ;)


Pour les DAE, tout exploitant doit fournir un fichier CSV qui va bien, 
même si il ne comporte qu'une ligne... ridicule.


On avait déjà ça avec les IRVE... mais là au moins il y avait une 
carotte : la subvention versée si les données sont publiées.



Si on ajoute des contrôles et sanctions pour non déclaration de DAE dans 
la base nationale et bien on verra mécaniquement diminuer le nombre de 
DAE non obligatoires (hors ERP), pour ne pas avoir à s'emm*** avec des 
démarches administratives supplémentaires.



Pour alimenter des bases nationales, il faut viser le petit nombre 
d'acteurs par qui ces données passent déjà ou existent déjà.


Imaginerait-on devoir déclarer son bilan DPE à l'ademe de façon 
individuelle ? Non, ce sont les diagnostiqueurs qui les font remonter 
dans la base nationale, et du coup elle est quasi exhaustive (et quand 
même pas super propre).


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-be] Mapping disaperead vicinal paths

[Wouter Hamelinck]

Hi,

Let me start by saying that I have all the sympathy for the aims of the
mapper. I also have been working with communities to keep vicinal ways
open. I am also aware that certain ways are only accessible certain times
of the year due to vegetation etc. Even if a path is not visible at the
moment you pass there, it might be at other times of the year. In general I
advocate leaving paths through fields (even plowed) that are legal rights
of way. My reasoning is that as soon as you pass with a small group a kind
of path will be visible. On the other hand, if the legal right of way
crosses buildings, gardens, canals... it makes no sense to put those in
OSM. Nobody will ever follow those.

With that in mind, I've taken a look at some of the changesets that you
linked to. I didn't like what I saw. People who want to check only one
example, this is a good one: https://www.openstreetmap.org/way/833838389
There is no place in OSM for that kind of legal fiction. Even not knowing
the situation on the ground, it is clear to me that nobody will try to
follow that track. So I would say to revert changes like that.

As for the arguments of the mapper:
* Putting something in OSM does not put any pressure on the owner. Nobody
will be impressed by the argument "you have to keep the way open because I
just put it on a website where everybody can put things".
* It makes the data in OSM useless. The tracks in OSM are used on a daily
basis by many, many hikers. The presence of legal fictions in OSM makes it
useless for them. They don't care where they should be able to pass in
theory. They want to know where they can pass in reality.

In conclusion, the mapper is trying to have some very dubious advantage for
his personal use and by doing that makes the data useless for all other
users. For me it is clear that those ways should be removed.

Regards,
Wouter

On Thu, Aug 6, 2020 at 8:21 AM Matthieu Gaillet  wrote:

> Hi,
>
> Recently an user mapped a set of disappeared “communal” or "vicinal” ways.
> By disappeared I mean they are physically absolutely not existent on the
> ground. They were either plowed or constructions were built right on them.
>
> I believe it goes against the general rule that states that one might only
> map what’s visible on the field. Additionally the mapping itself was poorly
> done and the source mentioned was not relevant.
>
> Using the tag [ 
> trail]_visibility
> =no
> 
>  is
> not an option here since the user decided to map a unmaintained track road
> (with width = 4m !) that doesn’t offer such option.
>
> He denied reverting the changeset, arguing that mapping those paths was a
> way to put pressure on the Commune and the owner in a discussion about the
> openness and accessibility of surrounding paths for the general public. He
> promised to delete the date once the case will be closed.
>
> Les sentiers et chemins que j'ai repris sur OSM sont légalement toujours
> existants et personne n'est en droit d'empêcher quiconque de les utiliser,
> de les réhabiliter ou de les débroussailler... c'est une façon de mettre la
> pression sur le riverain... dès que des alternatives auront été créées et
> un bon accord conclu, j'effacerai les données au profit des alternatives
> qui auront été proposées.
>
>
> The changesets :
> https://www.openstreetmap.org/changeset/88927383
> https://www.openstreetmap.org/changeset/88927894
> https://www.openstreetmap.org/changeset/88927825
> https://www.openstreetmap.org/changeset/88927566
>
>
> What do you think ? I believe that’s not a good way of doing things (I
> don’t believe in maptivism in this situation) but can’t really find a clear
> position of the community about this particular case.
>
> I don’t want to start a fight with that user because he’s really doing a
> great job at preserving the right of use of those heritage vicinal ways by
> confronting the Communes against those unfair owners. I would like to show
> him some string arguments to explain him why his initiative is not good for
> the community (If that’s the case).
>
> Thanks for sharing your thoughts.
> Matthieu Gaillet
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
"Den som ikke tror på seg selv kommer ingen vei."
   - Thor Heyerdahl
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

C'était pas bien sinon operator:ref:FR:SIREN=* ? Comme le champ 
operator=* contient déjà le nom du gestionnaire, la tendance est à 
operator:ref=*, mais comme on précise le type de référence et bien 
operator:ref:FR:SIREN. Et en terme d'ergonomie, les deux attributs 
seront affichés à la suite dans les éditeurs ;-)


Adrien P.

Le 06/08/2020 à 10:30, Christian Quest a écrit :


ref:FR:SIREN devrait décrire une entreprise (plus exactement son 
siège, car ce n'est pas un SIRET correspondant à un de ses 
établissements), pas un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique 
que la source est ce SIREN et pas quelle est la source du SIREN... 
donc plutôt ref:FR:SIREN:source ;)


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> ref:FR:SIREN devrait décrire une entreprise (plus exactement son siège, car 
> ce n'est pas un SIRET correspondant à un de ses établissements), pas un 
> équipement exploité par cette entreprise.
:)

> Ici il s'agit de la source de l'info, donc un tag xxx:source ou source:xxx me 
> semblerait plus approprié, lequel ?
euh, la source serait plutôt GeoDAE et plus exactement le fichier OD sur 
data.gouv.fr  ?

__
Yves

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 06/08/2020 à 09:10, PanierAvide a écrit :


On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de maintenance...). 
Pour l'exploitant, au moins le nom ça me semble essentiel, et le SIREN 
ça peut pas faire de mal (on a jamais trop d'infos...).




ref:FR:SIREN devrait décrire une entreprise (plus exactement son siège, 
car ce n'est pas un SIRET correspondant à un de ses établissements), pas 
un équipement exploité par cette entreprise.


Ici il s'agit de la source de l'info, donc un tag xxx:source ou 
source:xxx me semblerait plus approprié, lequel ? celui qui indique que 
la source est ce SIREN et pas quelle est la source du SIREN... donc 
plutôt ref:FR:SIREN:source ;)



Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une 
fiche web pour chaque DAE. Quasi toutes les infos exploitables sont 
celles qui ressortent dans Osmose.



Ça viendra d'une façon ou d'une autre, si facile à mettre en place.

--

Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

C'est pas utopique si c'est une obligation légale : ça fonctionne bien 
pour les prix des carburants et les déclarations de revenus, il n'y a 
pas de raisons que ça ne fonctionne pas pour les DAE. Le tout c'est 
qu'il y ait à terme des contrôles et sanctions en cas de manquements.


Adrien P.

Le 06/08/2020 à 10:18, Christian Quest a écrit :
C'est toute la difficulté. Ce sont potentiellement des centaines de 
milliers d'exploitants qui vont devoir déclarer leur DAE dans la base 
ce qui est utopique.


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

Re: [OSM-talk-fr] Aire du viaduc de Millau

[Christian Quest]

Le 05/08/2020 à 22:37, Arnaud Champollion a écrit :

Le 05/08/2020 à 17:23, Jérôme Amagat a écrit :
Si on remplace par un node, je pense qu'on aura toujours le problème, 
dans un sens ou dans l'autre de l'autoroute.


Et si l'on met ce node sur une zone non accessible en voiture, par 
exemple une zone de pique-nique, peut-être que le routeur n'aura plus 
intérêt à faire effectuer un détour routier ? 


Le routeur ça chercher la voie d'accès la plus proche, y projet le POI 
d'arrivée et calculer la route sur ce point trouvé.


Cela ne résoudra pas le problème qui est en fait lié à un routage 
mono-mode. Si on faisait un routage multi-modal (voiture + pédibus) il 
trouverai bien sûr qu'il est plus simple de marcher un peu à l'arrivée 
que de faire un énorme détour en voiture.


C'est pour moi plutôt un défaut des algos de routage sur le routage à 
l'arrivée qu'un problème dans les données OSM qui décrivent, il me 
semble, correctement le terrain.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> On ne peut pas tout mettre, puisque seules les informations publiques nous 
> sont accessibles (pas de dates de péremption, de maintenance…).
> 
En théorie, c'est visible  sur le terrain : "Depuis le 1er janvier 2020, pour 
les dispositifs installés, il est obligatoire d’apposer sur le boîtier ou à 
proximité immédiate de l’appareil une étiquette conforme au modèle suivant" 
(cf. FAQ 
)
> SIREN ça peut pas faire de mal (on a jamais trop d'infos...).
> 
trop d'info tue l'info ;)

> Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une fiche web 
> pour chaque DAE. Quasi toutes les infos exploitables sont celles qui 
> ressortent dans Osmose.
> 
Il faut demander ça à data.gouv.fr  (en général) ou dans 
ce cas précis à https://geodae.atlasante.fr/  ?

__
Yves

PS: j'ai du mal avec data.gouv.fr  et ses cousins 
geo.data.gouv.fr … (il me semble qu'il en y en a 
d'autres)
Pourquoi plusieurs sites avec semble-t-il les mêmes données ?
Quelles sont leur différences ?___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Christian Quest]

Le 05/08/2020 à 20:58, osm.sanspourr...@spamgourmet.com a écrit :


Le 05/08/2020 à 19:57, Christian Quest - cqu...@openstreetmap.fr a écrit :


- peut-on améliorer le jeu de données OSM à partir de la base Geo DAE ?

On peut, mais c'est fastidieux vu la mauvaise qualité de la géoloc 
fournie par GeoDAE...


Je me suis mal fait comprendre je pensais aux champs autres de la 
base. Si tu prends ta commune et qu'il est écrit disons Mairie, tu 
sais où aller chercher le DAE s'il n 'est pas dans OSM (et ajouter la 
ref:FR:GeoDAE).


Pas sûr malheureusement. Les "noms" ne sont pas forcément cohérents à ce 
que j'ai pu voir sur ceux que j'ai voulu intégrer.


Avant d'avoir le moindre avis sur le contenu de cette base, je me suis 
pris les DAE d'un département pour voir... et j'ai pas été déçu (enfin 
si, déçu de ce que j'ai trouvé).



Au fait, emergency 
=defibrillator 
 
n'est plus affiché sur le style OSM FR ? On est resté sur le tag aed ?



Oups... je corrige ça.

Les deux tags sont reconnus, par contre, j'ai supprimé le rendu des 
medical=aed. Ceux en indoor=yes sont toujours un peu transparents pour 
les différencier.




Le 05/08/2020 à 20:11, Philippe Verdy - ver...@gmail.com a écrit :
Et tu crois que le 18/112 va chercher les DAE dans OSM pour guider 
l'appelant ?


15/18/112 : pourquoi veux-tu qu'ils utilisent la page osm.org ?

Je crois que tu sais que OSM c'est une base de données réutilisable^^ 
et que la création de GeoDAE est la preuve qu'actuellement 
l'information est mal consolidée.


Est-ce qu'un site départemental d'appel connait tous les DAE du 
département ?


J'aimerai en être sûr. Et si les données OSM peuvent servir de 
référence tant mieux. Alors soit une couche spécialisée sera faite 
pour leurs outils soit des applications/sites seront développés 
utilisant les données OSM.


Si effectivement les 15/18/112 connaissent toutes les positions des 
DAE, il faut qu'ils nous les donnent, ça leur fera gagner du temps !


Personne ne connait l'ensemble des DAE car il s'en installe de plus en 
plus dans des lieux non publics comme les commerces et les entreprises.


C'est toute la difficulté. Ce sont potentiellement des centaines de 
milliers d'exploitants qui vont devoir déclarer leur DAE dans la base ce 
qui est utopique.



--
Christian Quest - OpenStreetMap France

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

Re: [talk-cz] SotM a OpenAlt 2020?

[Jiri Vlasak]

On Wed, Aug 05, 2020 at 01:46:33PM +0200, Tom Ka wrote:
> st 5. 8. 2020 v 13:31 odesílatel Jiri Vlasak  napsal:
> > mám související otázku. Stejně jako loni bychom letos chtěli udělat Meeting
> > Missing Maps CZ & SK. Loni jsme to sfoukli v neděli po SotM CZ + SK na
> > OpenAltu, letos jsme to zatím neřešili.
> >
> > No a teď ta otázka, že jo -- mohli bychom se přidat k SotM CZ + SK? Pro nás
> > bude určitě zajímavé se SotM CZ + SK zúčastnit, zároveň ale asi budeme
> > pořebovat alespoň 2 hodiny na vlastní talky a diskuzi.
> 
> Zatim to asi nikdo nezacal resit, resp. se lidi ani neozvali na termin
> apod., takze nedokazu rict, jak bude prostor s casem. Asi to zacnu
> zase strkat at se neco deje, tak snad brzo bude nejaka predstava. BTW
> kolik vas je? Tto muze byt taky dulezite.

Loni nás bylo možná 10. Můj odhad je, že to bude letos podobné.

Díky,
jiri

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

Re: [OSM-talk-fr] noms anglais en Allemagne ?

[Yves P.]

> fr-FR fr de en en-US et j'ai bien Münster Unserer Lieben Frau.
> 
> Donc le problème c'est que osm.org  ne sait pas que la 
> cathédrale de Fribourg-en-Brisgau est en Allemagne et que la langue 
> officielle de l'Allemagne est l'allemand (default_language 
> =de
>  de la relation Allemagne ).
> 
Ok, je n'avais pas vu que Muselaar parlait du libellé affiché dans la page OSM 
et pas du tag name.

>> Par contre name:de fait doublon avec name…
> Sûr ? Pourtant il permet :
> 
> 1) d'être sûr d'obtenir un nom en allemand
> 
> 2) de détecter que name=* est ici en allemand vu qu'il est identique à 
> name:de=*
> 
Ok, je n'avais pas pensé à ça :)

Par contre si je te suis bien, il faut dupliquer tous les name en name:fr pour 
tous les objets OSM en France ??

Est-ce que ça ne serait pas plus "économique" de spécifier la langue dans le 
tag name comme dans le tag wikipedia ?
name="fr:Tour Eiffel"
name:en="Eiffel Tower"
…

Pour les noms multilingues comment fait-on ?
name="de;fr:Biel-Bienne"
name:de ="Biel"
name:fr ="Bienne"

ou 

name="Biel-Bienne" // ni français, ni allemand
name:de ="Biel"
name:fr ="Bienne"

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

On ne peut pas tout mettre, puisque seules les informations publiques 
nous sont accessibles (pas de dates de péremption, de maintenance...). 
Pour l'exploitant, au moins le nom ça me semble essentiel, et le SIREN 
ça peut pas faire de mal (on a jamais trop d'infos...).


Et pas sûr qu'il y ait (pour l'instant ?) de lien direct vers une fiche 
web pour chaque DAE. Quasi toutes les infos exploitables sont celles qui 
ressortent dans Osmose.


Adrien P.

Le 06/08/2020 à 08:55, Yves P. a écrit :
Les attributs supplémentaires sont décrits dans le tableau ici, qui 
fait le lien avec le schéma de données officiel : 
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator#En_France 


Doit on tout mettre dans OSM ??

Le SIREN de l'exploitant  : c'est pas le DAE qui a un SIREN, mais 
l'opérateur.
Ça serait plus logique de mettre operator:ref:FR:SIREN=* mais quel est 
l'intérêt ?


ref:FR:GeoDAE=* (avec le format d'URL approprié dans wikidata/data 
items) permet de retrouver ces infos (et évite les pb de mise à jour).


Note: il y a des infos intéressantes dans la FAQ
https://carto.atlasante.fr/IHM/cartes/infofactures/geodae/GeoDAE_FAQ_v1.pdf

Je pense qu'il faut se concentrer sur ce qui permet de trouver un DAE 
(en état) rapidement.

En texte "Mairie : sur la façade à droite de la porte d'entrée"
Avec des coordonnées GPS précis (certains l'utilisent)
Avec des photos : c'est complémentaire au deux localisations précédentes.

Sur la plateforme Atlasanté tu as les liens vers les flux WMS/WFS 
pour visualiser les données complètes dans QGIS ou Leaflet/OpenLayers 
par exemple : 
https://www.atlasante.fr/geonetwork/srv/fre/catalog.search#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9

Y-a-t-il un lien utilisable par JOSM ?

Et un lien vers la fiche du DAE à partir de sa référence GeoDAE ?

__
Yves


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

Re: [Talk-is] Ærslabelgir

[Sveinn í Felli]

Staðsetning ærslabelgjanna á belgir.eggald.in er oft ekki mjög nákvvæm, 
altént þeirra sem ég kannast við hér norðanlands. Hvað er raunhæft að 
miða við, vitandi að tengd leiksvæði eru endurhönnuð* reglulega?


Reyndar er ekki hlaupið að því að færa þessa belgi, það er kostnaður sem 
mörg smærri sveitarfélög myndu reyna eftir megni að forðast.


Ætti að láta merkingu belgjanna tengjast viðkomandi leiksvæði án þess að 
eltast við nákvæma teikningu, eða hafa þetta sem næst raunstaðsetningu í 
dag?


bkv,
Sveinn í Felli

*: Sundlaugargaðurinn á Akureyri virðist vera stokkaður upp á sirka 
15-20 ára fresti.


Þann 31.7.2020 21:38, skrifaði Jóhannes Birgir Jensson:

Sæl verið þið

Einhver er búinn að búa til ærslabelgjakort eftir minni - gögnin eru ekki til 
staðar á OSM að mestu
og ég er því að bæta við þeim sem ég veit um.

Fyrir belginn sjálfann notum við playground=cushion (ég set punkt) og hann er 
oftast innan svæðis
sem er leisure=playground

Ærslabelgjakortið: https://belgir.eggald.in (https://belgir.eggald.in/)

Leikvellir https://wiki.openstreetmap.org/wiki/Key:playground 
(https://wiki.openstreetmap.org/wiki/Key:playground)


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




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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[Yves P.]

> Les attributs supplémentaires sont décrits dans le tableau ici, qui fait le 
> lien avec le schéma de données officiel : 
> https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator#En_France
>  
> 
Doit on tout mettre dans OSM ??

Le SIREN de l'exploitant  : c'est pas le DAE qui a un SIREN, mais l'opérateur.
Ça serait plus logique de mettre operator:ref:FR:SIREN=* mais quel est 
l'intérêt ?

ref:FR:GeoDAE=* (avec le format d'URL approprié dans wikidata/data items) 
permet de retrouver ces infos (et évite les pb de mise à jour).

Note: il y a des infos intéressantes dans la FAQ
https://carto.atlasante.fr/IHM/cartes/infofactures/geodae/GeoDAE_FAQ_v1.pdf 


Je pense qu'il faut se concentrer sur ce qui permet de trouver un DAE (en état) 
rapidement.
En texte "Mairie : sur la façade à droite de la porte d'entrée"
Avec des coordonnées GPS précis (certains l'utilisent)
Avec des photos : c'est complémentaire au deux localisations précédentes.

> Sur la plateforme Atlasanté tu as les liens vers les flux WMS/WFS pour 
> visualiser les données complètes dans QGIS ou Leaflet/OpenLayers par exemple 
> : 
> https://www.atlasante.fr/geonetwork/srv/fre/catalog.search#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9
>  
> 
Y-a-t-il un lien utilisable par JOSM ?

Et un lien vers la fiche du DAE à partir de sa référence GeoDAE ?

__
Yves

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

Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)

[Christian Quest]

Le 05/08/2020 à 19:42, Jérôme Amagat a écrit :

Tout d'abord, merci pour ce très beau rendu !

Plusieurs améliorations possibles :

Les aires d'autoroutes highway=services ne sont pas rendu 
contrairement au aires sans service highway=rest_area
exemple : https://www.openstreetmap.org/way/125646404 
http://tile.openstreetmap.fr/?zoom=17=45.84394=5.07038=B


Les barrage non plus, pas rendu waterway=dam, il y a seulement le nom 
qu apparaît.
exemple : https://www.openstreetmap.org/way/37953758 
http://tile.openstreetmap.fr/?zoom=15=45.22418=6.95203=B


Les rivières waterway=river sans natural=water ou waterway=riverbank 
n'apparaissent qu'au zoom 15 ce qui est tard, il me semble.
exemple : https://www.openstreetmap.org/way/30785271 
http://tile.openstreetmap.fr/?zoom=14=42.6065=8.9894=B


Il y a des déserts en natural=desert et en natural=sand pour les 
déserts de sable, a faible zoom il sont rendu de la même façon mais à 
partir du zoom 8 les natural=sand disparaissent. Et il serait 
intéressant que leur noms apparaissent aussi et peut être une couleur 
un peu différente ?
exemple : https://www.openstreetmap.org/way/232227949 
http://tile.openstreetmap.fr/?zoom=8=30.16904=0.24451=B


Les mers, baies et détroits (place=sea, natural=bay, natural=strait) 
en surfacique pourraient avoir leur nom qui apparaissent pour les mer 
et détroit et plus tôt lorsqu'ils sont très grands pour les baies qui 
sont déjà rendu.
exemple : le golfe du lion 
https://www.openstreetmap.org/relation/9287303 
http://tile.openstreetmap.fr/?zoom=11=42.99137=4.17341=B


Il faudrait mettre ça en issues sur 
https://github.com/cquest/osmfr-cartocss/issues



Truc plus compliqué et je ne sais pas si c'est possible C'est un 
rendu fr, mais n' y a pas de name:fr partout :) et les noms sont 
illisibles pour la plupart des francophones lorsqu'il sont dans un 
autre alphabet, par contre les noms en anglais sont beaucoup plus 
présent et sont souvent les même que les français, serait il possible 
de faire apparaître les noms en anglais lorsque le name=* est dans un 
autre alphabet que l'alphabet latin et qu'il n'y a pas de name:fr ? Je 
pense surtout au noms des villes et régions en Chine, Japon, 
Thaïlande, pays arabe... mais aussi l'europe de l'est et la Grèce avec 
leurs alphabet plus proche du nôtre mais difficile à lire pour la 
plupart des francophones.

Je ne sais pas si c'est possible de trier par alphabet ou par pays.


C'est déjà en partie le cas, l'ordre c'est:

- name:fr
- intl_name
- name

Difficile par contre de déterminer l'alphabet utilisé et d'aller plus 
loin en insérant par exemple un name:en.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-be] Mapping disaperead vicinal paths

[Francois Gerin]

Hi,

I faced the same situation here. I sent the author a kind message, 
telling this fight, even if fully justified, is not to lead via OSM but 
via balnam.be (for the Wallonia part).


I got no reply, but pointing to an alternative for this justified cause 
is probably something that can help the destinator to think twice about it.


For the rest, I'm afraid if someone insists misusing OSM, the only 
alternative is to open a litigation...



NOTE: A few months ago, I sent a message on the current mailing for a 
specific/particular case... Ways covered by cultures for a few months 
every year, due to the farmers who do not respect the public area.
The conclusion was that there is clearly no ideal solution for that 
case, we cannot update every path every day! => According to me, this is 
an exception, based on the "common sense", to the general rule "map what 
is visible". (The exception "common sens" is also part of the OSM rules!!!)

This exception is acceptable, according to me, due to its particularity.

Regards,
François (user fgerin)


On 6/08/20 08:20, Matthieu Gaillet wrote:

Hi,

Recently an user mapped a set of disappeared “communal” or "vicinal” 
ways. By disappeared I mean they are physically absolutely not 
existent on the ground. They were either plowed or constructions were 
built right on them.


I believe it goes against the general rule that states that one might 
only map what’s visible on the field. Additionally the mapping itself 
was poorly done and the source mentioned was not relevant.


Using the tag [ 
trail]_visibility 
=no 
 is 
not an option here since the user decided to map a unmaintained track 
road (with width = 4m !) that doesn’t offer such option.


He denied reverting the changeset, arguing that mapping those paths 
was a way to put pressure on the Commune and the owner in a discussion 
about the openness and accessibility of surrounding paths for the 
general public. He promised to delete the date once the case will be 
closed.


Les sentiers et chemins que j'ai repris sur OSM sont légalement 
toujours existants et personne n'est en droit d'empêcher quiconque de 
les utiliser, de les réhabiliter ou de les débroussailler... c'est 
une façon de mettre la pression sur le riverain... dès que des 
alternatives auront été créées et un bon accord conclu, j'effacerai 
les données au profit des alternatives qui auront été proposées.


The changesets :
https://www.openstreetmap.org/changeset/88927383
https://www.openstreetmap.org/changeset/88927894
https://www.openstreetmap.org/changeset/88927825
https://www.openstreetmap.org/changeset/88927566


What do you think ? I believe that’s not a good way of doing things (I 
don’t believe in maptivism in this situation) but can’t really find a 
clear position of the community about this particular case.


I don’t want to start a fight with that user because he’s really doing 
a great job at preserving the right of use of those heritage vicinal 
ways by confronting the Communes against those unfair owners. I would 
like to show him some string arguments to explain him why his 
initiative is not good for the community (If that’s the case).


Thanks for sharing your thoughts.
Matthieu Gaillet


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

Re: [OSM-talk] Proposal for Software Dispute Resolution Panel

[Jo]

I support your nomination. You're a really good candidate for it. I would
propose myself, but I don't, as I have almost zero experience with using iD.

Polyglot

On Thu, Aug 6, 2020, 06:47 Roland Olbricht  wrote:

> Hello,
>
> first of all I'm glad to read that the board addresses the sudden
> funding hole for iD, and does in addition care about the critique around
> iD.
>
> I would like to self-nominate for the software dispute resolution panel.
>
> For my understanding of the task please (re-)read
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006909.html
> tl;dr: There is no silver bullet, hence no team of experts is going to
> find one. Conflict resolution is painful work for all involved, but it
> also likely to yield insight and an improved software. I see a panel's
> member's job in encouraging the involved people to keep walking through
> the resolution process.
>
> I also promise resp. reserve the right to share or paraphrase (for the
> purpse of removing personal issues) all communications regarding the
> nomination process. There have been concerns about whether the
> nomination process is balanced and being open is the best way to address
> them. On a personal note: I have no doubts it is, and the artifacts we
> currenty encounter are consistent with a board intensely keeping many
> trains in their rails in parallel.
>
> Regarding potential CoI:
> - I develop the Overpass API but it is intentionally tag agnostic.
> - I do not plan to put the Overpass API under the panel regime.
> Thus, I do not expect any CoI from my contributions as developer to
> OpenStreetMap.
>
> Best regards,
> Roland
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-be] Mapping disaperead vicinal paths

[Matthieu Gaillet]

Hi,

Recently an user mapped a set of disappeared “communal” or "vicinal” ways. By 
disappeared I mean they are physically absolutely not existent on the ground. 
They were either plowed or constructions were built right on them.

I believe it goes against the general rule that states that one might only map 
what’s visible on the field. Additionally the mapping itself was poorly done 
and the source mentioned was not relevant.

Using the tag [ 
trail]_visibility 
=no 

 is not an option here since the user decided to map a unmaintained track road 
(with width = 4m !) that doesn’t offer such option.

He denied reverting the changeset, arguing that mapping those paths was a way 
to put pressure on the Commune and the owner in a discussion about the openness 
and accessibility of surrounding paths for the general public. He promised to 
delete the date once the case will be closed.

> Les sentiers et chemins que j'ai repris sur OSM sont légalement toujours 
> existants et personne n'est en droit d'empêcher quiconque de les utiliser, de 
> les réhabiliter ou de les débroussailler... c'est une façon de mettre la 
> pression sur le riverain... dès que des alternatives auront été créées et un 
> bon accord conclu, j'effacerai les données au profit des alternatives qui 
> auront été proposées.

The changesets : 
https://www.openstreetmap.org/changeset/88927383
 
https://www.openstreetmap.org/changeset/88927894
 
https://www.openstreetmap.org/changeset/88927825 

https://www.openstreetmap.org/changeset/88927566 



What do you think ? I believe that’s not a good way of doing things (I don’t 
believe in maptivism in this situation) but can’t really find a clear position 
of the community about this particular case.

I don’t want to start a fight with that user because he’s really doing a great 
job at preserving the right of use of those heritage vicinal ways by 
confronting the Communes against those unfair owners. I would like to show him 
some string arguments to explain him why his initiative is not good for the 
community (If that’s the case).

Thanks for sharing your thoughts. 

Matthieu Gaillet

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

Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !

[PanierAvide]

Bonjour Julien,

Le fait de rapprocher les identifiants systématiquement avec les DAE 
déjà dans OSM n'a pas été activé dans Osmose pour cette analyse, mais ça 
aurait du sens de les rapprocher systématiquement. À voir si on l'active 
maintenant ou un peu plus tard quand la base GéoDAE sera plus complète.


Les attributs supplémentaires sont décrits dans le tableau ici, qui fait 
le lien avec le schéma de données officiel : 
https://wiki.openstreetmap.org/wiki/FR:Tag:emergency%3Ddefibrillator#En_France


Sur la plateforme Atlasanté tu as les liens vers les flux WMS/WFS pour 
visualiser les données complètes dans QGIS ou Leaflet/OpenLayers par 
exemple : 
https://www.atlasante.fr/geonetwork/srv/fre/catalog.search#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9


Cordialement,

Adrien P.

Le 05/08/2020 à 21:41, Julien Lepiller a écrit :


J'ai regardé sur la commune de mes parents, où j'avais renseigné deux
DAE. L'un d'entre eux n'est pas remonté par osmose (je me serais
attendu à ce qu'il propose un rapprochement, ne serait-ce que pour
ajouter un ref:fr:GeoDAE ou un nom) :

https://www.openstreetmap.org/node/6725173672

Le deuxième est rapporté par osmose (sans doute parce que mal
localisé) :

https://www.openstreetmap.org/node/6832700105

et

https://osmose.openstreetmap.fr/fr/error/c4cda4f3-e2ae-d720-ad31-9500c2ef7f15

Il y en a a priori deux autres dans la commune, et vu leur nom, tout
aussi mal localisés. Au passage, osmose indique que celui que j'ai déjà
renseigné est à l'intérieur, mais, à moins qu'il ait bougé depuis
l'année dernière, il est bien à l'extérieur.

Je ne comprends pas bien les attributs proposés (reception_desk,
security_desk, surveillance), ça n'a pas l'air indiqué sur la page du
wiki :).

Il y a moyen d'accéder à une carte qui affiche les données de GeoDAE,
en dehors d'osmose qui ignore normalement ce qui est déjà dans OSM ?


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