from:"osm . sanspourriel"


J'ai vérifié : il existe une réalisation de ce formatage en PHP, donc si
vous pensez que c'est intéressant un petit +1 sur

https://github.com/osm-search/Nominatim/issues/213#issuecomment-652466541

Je vois une scorie d'une ancienne version anglaise qui est présente sur
la page FR:Key:place  :

postal_code  Text
nœud  chemin
 zone
 Code postal. (Lui
préférer addr:postcode
=*)

Or la pratique en France (sauf par Philippe !) c'est d'utiliser comme
ailleurs dans le monde postal_code
 sur les communes
et et de réserver les addr:* aux adresses.

On met en cohérence avec la pratique ? On vire l'info ?

Jean-Yvon


Le 01/07/2020 à 13:26, Yves P. - yves.prat...@gmail.com a écrit :

C'est un problème de Nominatim qui ne dit pas tout simplement "14,
Chemin des Gravas, 04000 Digne-les-Bains, France"

J'avais demandé il y a quelques années aux développeurs de mettre un
formatage par pays pour éviter ce problème, sans résultat :/


J'ai retrouvé le ticket.
https://github.com/osm-search/Nominatim/issues/213

Il y a un projet qui formate les adresses en fonction des usages dans
les pays : https://github.com/OpenCageData/address-formatting

Je viens d'essayer avec l'API de démo
 du géocodeur OpenCage pour ton adresse
à Digne :
 14 Chemin des Gravas, 04000 Digne-les-Bains, France

Il est aussi mentionné un fichier de config par pays dans iD, mais je
ne sais pas si il est utilisé : iD/data/address-formats.json


Il faudrait peut-être relancer les développeurs de Nominatim pour
intégrer ça ?

__
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] édition en masse sur les adresses des cinémas


Le 01/07/2020 à 17:49, Christian Quest - cqu...@openstreetmap.fr a écrit :


Voilà pourquoi on a toujours poussé pour séparer et ne pas mélanger.


Entièrement d'accord sur le raisonnement.

Maintenant si on regarde les règles en France il y a en fait un
qualificatif en plus de l'adresse. "Type de position" selon
adresse.data.gouv.fr mais je n'ai pas trouvé la définition. J'ai trouvé
entrée, inconnu.

Procéder de cette manière permettrait d'avoir plusieurs adresses tout en
sachant à quoi ça correspond.

addr:role=contact par exemple.

*Le gros avantage c'est que c'est compatible avec les éditeurs
existants* (il faut "juste" convaincre d'ajouter un champ, pas de tout
casser pour que les addr: des POI atterrissent dans les contact:addr:*).

Et transformer les contact:addr:* en addr: se ferait sans perte.

C'est sans doute plus facile que d'imposer un schéma de facto
franco-français.

En rêvant tout haut :
contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque;entrance.

Registry : l'adresse là où la met le cadastre, le SIG de la ville, unicité

Mailbox : là où se trouve la boîte-aux-lettres pour distribuer le
courrier à cette adresse (peut être loin dans le cas des CIDEX
), unicité

Contact : tous les POI ayant cette adresse ont au moins
addr:role=contact mais ça peut aussi être addr:role=contact;registry.
Pas nécessairement unique.

Plaque : là ou se trouve la plaque de rue, unicité. Pas nécessairement
unique.

Entrance : l'endroit par lequel on arrive à cette adresse. Pas
nécessairement unique.

J'ajoute volontairement water;electricity;gas;FTTH pour provoquer des
réactions : là où se trouvent les différents compteurs (eau,
électricité, gaz) ou entrées (FTTH). Pour l'électricité c'est peut-être
plutôt l'endroit d'entrée dans la place.

En effet, j'ai vu le concessionnaire de l'eau potable relever les
positions géographiques des compteurs. Actuellement ces relevés il les
garde pour lui. Je me dis comme François que préparer le terrain ne peut
nuire ;-).

Christian R., non, adresse n'implique pas bâti. On a déjà évoqué sur la
liste le cas des lotissements où les nom de rue et les numéros sont
fixées avant la construction. Il y a aussi des cas limites intéressants
comme cette adresse de bateau-restaurant détruit
.

Pour compléter le tableau, si certaines fois Nominatim se plante sur les
lieux-dits bornés c'est que Nominatim ne se sert pas des adresses mais
des rues
.

Question subsidiaire : quelle(s) adresses à mettre dans associatedStreet
? Toutes ? Que celles registry et/ou plaque ?

Jean-Yvon

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

Re: [OSM-talk-fr] Noms des quartiers en ville



Le 01/07/2020 à 12:57, Yves P. - yves.prat...@gmail.com a écrit :

On réserverait "hamlet" à des communes constituées exclusivement de
hameaux, comme par exemple Valjouffrey :

oui

Non

Il peut y avoir des villages, des hameaux et pourtant une ou des zones
urbaines avec des quartiers. On ne met pas de hamlet (ou pire des
isolated_dwelling comme signalé à Dignes) dans la zone urbaine.

C'est juste du bon sens.

Si l'étalement urbain fait qu'un hamlet ou un village se met à toucher
cette zone, ça devient un neighbourhood.

Jean-Yvon

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

Re: [OSM-talk-fr] Noms des quartiers en ville


Effectivement on ne tague pas pour tel ou tel outil.

hamlet n'a rien à faire dans la zone urbaine d'une ville, on ne met pas.

> tous les quartiers mêmes excentrés sont à tagguer "neighbourhood

Excentrés mais partie de la zone urbaine agglomérée.

Si c'est discontigu, c'est village, hamlet, isolated_dwelling.

Et si quel ou tel cas ne marche pas on ouvre ou commente pour que Sarah
regarde :

https://github.com/osm-search/Nominatim/issues/1505

Jean-Yvon

Le 01/07/2020 à 12:31, ades - ades.s...@orange.fr a écrit :

Ah bon ?
Je croyais avoir compris que l’on ne ,taggait pas pour le rendu ?
C’est vrai dans tous les cas ? Après les tags spécialement adaptés aux calcul 
d’itinéraires, voici les tags adaptés à nominatim ! Que ce soit l’un ou l’autre 
il me semble qu’il s’agit de rendus et que c’est au « moteur » de rendu de 
faire son boulot, non ?



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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-30 Thread osm . sanspourriel


Le 30/06/2020 à 15:22, Yves P. - yves.prat...@gmail.com a écrit :

https://www.openstreetmap.org/relation/11186492
Les relations type=site sont à éviter : pas rendu, peuvent être
remplacer par un polygone ou un multipolygone

C'est curieux ?
Relier des toilettes au bout d'un dédale de souterrain? qui mène au
cinéma (le polygone du bâtiment) ?
Et pour l'autre relier une entrée sur une autre rue avec la salle de
cinéma ??


Justement les dédales ne sont pas dans la relation :
https://www.openstreetmap.org/way/445308489. Est-ce des couloirs publics
? J'imagine mal des toilettes réservées aux clients en dehors du
bâtiment (même si je connais le cas).

Alors j'ai d'autres problèmes :

- toilet=yes Indicates that a feature has a toilet.

Ce n'est donc pas les toilettes elles-mêmes (qui sont publiques amenity
=toilets
).

Donc je mettrais simplement toilet=yes sur le cinéma.

Je suppose que les gens utilisent OSM pour trouver des toilettes
publiques mais par contre que dans un cinéma ils suivent les flèches (et
non les mouches^^ ou OSM).

Mais y a-t-il des cinémas sans toilettes ? Hormis les cinémas en plein
air peut-être.

À voir l'historique du point ça semble avoir été considéré comme le
cinéma. Une entrée ?

source=survey reste depuis le début.

On en déduira que quelqu'un a vérifié que le cinéma a été transformé en
toilettes^^.

Ça ressemble plus à un nettoyage partiel.

Jean-Yvon

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

Re: [OSM-talk-fr] Comment restaurer des données supprimée

2020-06-30 Thread osm . sanspourriel


La question est ambigüe, porte-t-elle sur le comment le faire auquel cas
Adrien a répondu ou sur le comment retrouver le changeset.

" je m'en rend compte très tardivement. La zone est très limité. Sur
deux immeubles."

À partir de https://www.openstreetmap.org/user//history
tu peux retrouver le changeset à problème que tu annules comme dit par
Adrien.

Tu peux utiliser overpass en mode diff avec deux dates, aussi près que
possible de la date de la boulette (avant et après) et tu cherches les
building supprimés. Il ne doit pas y en avoir beaucoup si tu zoomes
assez avant de lancer la requête. Là encore le plus simple c'est de
trouver ainsi le changeset et se ramener au cas précédent.

Jean-Yvon

Le 30/06/2020 à 07:53, PanierAvide - panierav...@riseup.net a écrit :


Bonjour,

Pour référence : https://wiki.openstreetmap.org/wiki/Change_rollback

Et dans ce cas là, à priori le plus simple est le plugin "undelete" de
JOSM https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete

Cordialement,

Adrien P.
Le 30/06/2020 à 06:33, Gad Jo a écrit :

Bonjour,


J'ai fait une suppression malheureuse mais je m'en rend compte très
tardivement. La zone est très limité. Sur deux immeubles.

C'est plus simple de refaire un import du cadastre mais je demande ça
aussi pour apprendre comment répondre à cette étude de cas.

J'ai posté la demande sur le forum pour que le plus grand nombre
profite de la réponse mais sans succès depuis depuis mai.

Est-ce qu'une personne aurait une solution ?
https://forum.openstreetmap.fr/viewtopic.php?f=5=7400
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
brièveté.

___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-06-30 Thread osm . sanspourriel


Le 30/06/2020 à 09:40, Yves P. - yves.prat...@gmail.com a écrit :


Si oui, faut-il créer un place=hamlet "Les Sieyes" qui est le
quartier du lieu correspondant à la position donnée ?

Peut-être ?


En tous cas pas des isolated_dweling comme ici :
https://overpass-turbo.eu/s/VBo

On devrait faire des requêtes pour vérifier l'absence de bâtiments
nombreux autour !


Le problème est que nous définissions les lieux-dit, hameaux,
quartiers dans OSM sous forme de noeuds.

Pour régler ce problème il faudrait définir un polygone, que nous
n'avons presque jamais concernant les lieux dits


Mais quand on l'a il faut le faire.


Le 30/06/2020 à 10:04, Christian Quest - cqu...@openstreetmap.fr a écrit :

Ce défaut disparaît-il quand on définit le hameau en surfacique plutôt
qu'avec un unique noeud ?


La réponse est non par contre on a des arguments pour demander à
Nominatim de ne pas retourner un tel résultat.

Exemple assez fort de café :

https://www.openstreetmap.org/search?query=jardins%20de%20vitalis%2C%20guidel#map=18/47.78742/-3.48546

2 réponses : le lotissement en question (bien) et une piscine en dehors
qui ne porte pas de nom ni d'adresse !

Arnaud, ici c'est un neighbourhood, pas un hamlet donc déjà testé ;-).

Jean-Yvon




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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-06-29 Thread osm . sanspourriel


STOP !

Malgré ce qui précède je suis pour.

Mais avec précautions.

Je vais à nouveau de me faire avoir avec iD. Tu me diras qu'en utilisant
iD il ne faut pas se plaindre après.

Un cinéma était donné comme étant le chemin building=yes.

Id propose de l'extraire.

Sans toucher à la relation associatedStreet.

Du coup je me suis retrouvé avec un membre house sans addr:housenumber
ou addr:housename. Heureusement Osmose est passé derrière.

Là tu risques d'avoir le même problème : il ne faut pas perdre d'adresse.

Si le cinéma est dans une associatedStreet il faut créer un point
d'adresse dans le bâtiment ayant cette adresse, le mettre dans la
relation, supprimer le cinéma de la relation puis roule ma poule.

Yves : en France on veut l'unicité des points adresse.

Jean-Yvon

Le 29/06/2020 à 22:03, Florian LAINEZ - winner...@free.fr a écrit :

Hello,
On avance bien sur le référencement des cinémas en france et leur
publication sur
https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap et
il est temps de s'occuper de leurs adresses.

Comme beaucoup d'entre vous le savent, en france, une décision
communautaire est de créer un node séparé du cinéma (ou de tout autre
POI) pour indiquer sont adresse.
En conséquence, en théorie, les tags suivants n'ont pas leur place sur
les objets amenity=cinema : addr:housenumber, addr:street,
addr:postcode, addr:city ainsi que les autres tags commençant par
"addr". Ces informations doivent apparaître sur un nœud séparé.

En conséquence, dans la ville de Montrouge, on a déjà fait le choix de
passer toutes les addr en contact (voir la discussion
).
/exemple : addr:housenumber=* en contact:housenumber=*
/

Le problème principal de cette solution est la non-comptabilité avec
les éditeurs iD et Maps.Me, qui proposent tous les 2 la seule édition
des adresses formatées de manière standard.
Malgré cette limitation je compte respecter la décision (très
européano-centrée
) de
la communauté Française et en conséquence changer sur tous les cinémas :
addr:housenumber -> contact:housenumber
addr:housename -> contact:housename
addr:street -> contact:street
addr:postcode -> contact:postcode
addr:city -> contact:city
addr:district -> contact:district
addr:place -> contact:place
addr:suburb -> contact:suburb
addr:territoire -> contact:territoire
addr:unit -> contact:unit

Je suis preneur d'éventuels commentaires avant de lancer l'édition de
masse avec le compte "overflorian-mass-edits".

--

*Florian Lainez*

@overflorian 

___
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] Poteaux de randonnée aux tags "baroques" dans le Vaucluse

2020-06-29 Thread osm . sanspourriel


Le 29/06/2020 à 11:48, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 29/06/2020 à 11:04, Yves P. a écrit :

- pole:position=green : je ne comprends pas ce tag, et je n'ai rien
trouvé dans le wiki. Quelqu'un peut-il expliquer ?

c'est par analogie avec fire_hydrant:position
=lane/parking_lot/sidewalk/green

C'est utile quand la précision des coordonnées est mauvaise ou en
l'absence de photo de situation, sinon complètement inutile.


je ne pense pas que la présence d'une photo soit un argument pour
sortir une donnée car il est plus facile il me semble d'utiliser une
donnée pour du routing ou de la synthèse vocale par exemple (d'autant
plus pour les cas où l'on ne peut pas voir la photo).


- Yves, pourquoi tu as supprimé la N 4 ?

- Il y avait des photos Mapillary qui montraient que là il y avait une
route et on voyait que c'était la N 4.

MdR. Bah, on connait bien des utilisateurs expérimentés qui remplacent
des baies représentées par des multi-polygones par des points...


La pertinence du tag en lui-même je ne sais pas.



Le 29/06/2020 à 11:54, Yves P. - yves.prat...@gmail.com a écrit :

Dans ce cas, il me semble que non. Que va faire un calculateur
d'itinéraire avec la position d'un poteau sur le trottoir, dans
l'herbe ou au dessus de la chaussée ?


Ben si : toi, TU n'as pas besoin de ça pour avoir TON itinéraire.

Mais OSM ce n'est pas fait juste pour qu'Yves puisse faire SA randonnée.

start_date, oui c'est moins utile que pour un bâtiment mais si le
département utilise OSM pour trouver les poteaux en bois plantés dans
l'herbe qui datent de 1994 parce qu'ils sont à remplacer, la base de
certains pourrissant, j'ai du mal à voir où est le mal. En plus tu
cherches à libérer des données poteaux, ne va pas reprocher aux gens de
mettre ces informations dans OSM, c'est contre productif.

A-t-on vu un utilisateur utiliser la référence STIF/IdFM des arrêts de
bus ? Est-ce pour autant inutile ?

Si tu ne veux pas dans ta base avoir les dates des poteaux, en une
requête SQL tu as fait le ménage chez toi pour toi.

> Pas sûr que les devs en tiennent compte pour 279 tags, mapillary en
plus !

Au début il n'y avait pas 279 building=yes non plus ;-).

Ceci dit le problème est un tag mapillary:wide dont on n'a pas la
définition et on ne sait si ça veut dire "photo d'ensemble, pris de
loin" ou "photo panoramique".

Du coup peu utilisé et peu utilisable.

Peu utile à mon avis aussi.

Après du Mapillary multi-valeur est peu utile, on va vouloir "la"
meilleure photo. Et bien sûr suivant ses propres critères^^.

Jean-Yvon

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

Re: [OSM-talk-fr] Zone de croisement pour fauteuil roulant

2020-06-26 Thread osm . sanspourriel


highway =passing_place


ne serait pas déconnant non plus.

Voir https://wiki.openstreetmap.org/wiki/FR:Key:lanes#Routes_.C3.A9troites.

Le 26/06/2020 à 08:24, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 25.06.20 à 22:38, Emmanuel Aubert a écrit :

il y a des pistes piétonnes  pas bien larges.
Sur ces pistes, il y a des surfaces que je soupçonne être
des zone de croisement.
Y a t’il un tag pour ça ?

un bout de way avec le width=* qui va bien ?

Cordialement,
Marc

___
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] vérification utilisationRPG et OCS_GE

2020-06-25 Thread osm . sanspourriel


L'URL d'accès des données est claire et en navigant naturellement on
passe bien par un bandeau "Licence Ouverte".

https://geoservices.ign.fr/documentation/diffusion/telechargement-donnees-*libres*.html#ocs-ge

Jean-Yvon

Le 25/06/2020 à 13:21, ades - ades.s...@orange.fr a écrit :

lire "sous licence,  Ouverte/Open License Version 2.0" et pas
« licence ocs etc."



Le 25 juin 2020 à 12:26, ades mailto:ades.s...@orange.fr>> a écrit :


bonjour,
le RPG et l’OCS_GE sont disponibles (pas pour tous les dpt) sous
licence OCS_GE
(https://geoservices.ign.fr/documentation/diffusion/index.html)
J’en déduis, peut-être à tort ?, que l’on peut utiliser les .shp
dispos pour contribuer.
A mon sens le RPG est trop précis et a des lacunes (parcelles non
renseignées), alors que OCS_GE, plus « général » semble mieux
convenir pour OSM.
Possible ou pas, à une échelle communale je compte vérifier sur le
terrain…
___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Alternatives à Mapillary

2020-06-22 Thread osm . sanspourriel


Bonjour,

> C'est en ligne. Vous pouvez le tester.

Pour ça il faudrait avoir été producteur et non seulement consommateur ;-).

> Pas floutage, c'est les photo brutes.

Très bien, on récupère l'original.

Maintenant la demande au Père Noël :

S'il y a moyen en fonction de ces adresses de trouver les adresses des
photos floutées, même sous-échantillonnées ça permettrait par différence
de trouver les zones de floutage, ce qui nous permettrait si les
conditions le permettent d'entraîner une IA de reconnaissance de visages
et de plaques.

Yves, je suppose que ce que tu as trouvé marche mal par faute
d'entrainement.

Jean-Yvon




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

Re: [OSM-talk-fr] Facebook achète Mapillary !

2020-06-21 Thread osm . sanspourriel


Je ne connaissais pas mais tout ça marche aussi depuis un Droid sans
compte BigBrother.

Et mon téléphone n'est pas un des modèles en question :-( Pas loin
pourtant !

Et non je n'ai jamais créé de compte Google (ni utilisé les applis
propriétaire Google).

Enfin si l'autre jour à cause d'une vidéoconférence mais je n'ai pas
donné mon numéro de téléphone mais celui de quelqu'un d'autre^^.

/e/ utilise l'ersatz de Google Plaie Sévices ?

Merci pour ce retour d'expérience.

Jean-Yvon

Le 21/06/2020 à 16:49, Georges Dutreix via Talk-fr -
talk-fr@openstreetmap.org a écrit :



Le 21/06/2020 à 15:50, Philippe Verdy a écrit :

Tu as un compte Google sur ton Android dès le moement où tu acceptes
les conditions initiales de l'OS et que tu inscrit ton numéro de
téléphone ou email (même hors Google)


Bonjour,

Il existe des alternatives hors google, comme lineageos ou /e/, même
si elles ne sont pas encore très répandues.

J'ai un téléphone "android" fonctionnant sous /e/
(https://e.foundation/?lang=fr), et je crois que d'autres personnes
ici ont également installé cet OS.
Je peux affirmer ne jamais avoir saisi de compte google sur ce téléphone.
Je précise aussi que j'ai pû installer toutes les applis dont j'avais
besoin (banque, applis synology, sncf, etc.), et en plus elles
marchent :-)

Bien cordialement,
Georges



___
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] Data OSM

2020-06-20 Thread osm . sanspourriel


Bof : si à la fin on télécharge des données thématiques.

J'aime la dernière proposition sur Loomio : *themes.openstreetmap.fr*

Sinon comme on extrait de la donnée d'OSM :

datamine.openstreetmap.fr

extraits.openstreetmap.fr

mines.openstreetmap.fr

En fait peu importe le nom, peu de gens vont le taper, ce qu'il faut
c'est qu'on le retienne facilement.

Et qu'il soit accessible depuis la page principale du site.

Jean-Yvon

Le 20/06/2020 à 17:27, Laurence P - laupic...@posteo.net a écrit :


Hello

visiOSM ?

puisque ça permet de "voir" les données

Laurence

Le 20/06/2020 à 15:34, Stéphane Péneau a écrit :

Le 20/06/2020 à 14:56, PanierAvide a écrit :


Ça fait doublon avec les échanges sur le Loomio
https://www.loomio.org/d/awNJn3j1/comment/2278570?utm_campaign=discussion_mailer_medium=email_source=new_comment

Mais ce qui a été dit c'est que "data" on s'attend à voir des
données brutes en mode téléchargement automatique. J'aime bien
"carte" / "portail" qui est plus révélateur du service.



C'est une sorte de catalogue de données. Donc pourquoi pas
catalogue.openstreetmap.fr ?

Stf


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

--
Laurence

___
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] Facebook achète Mapillary !

2020-06-19 Thread osm . sanspourriel


Comme dit par ailleurs takeout : utilise le script pour récupérer toutes
tes photos.

Après ils te proposent de détacher les photos de ton compte, ça évitera
que Facebook ne sache encore plus de choses sur toi.

Par contre ils ont tous les droits sur tes photos, ils peuvent les
supprimer ou les garder.

Ce serait intéressant de récupérer les deux version (HR et MR) : si
l'une est avec floutage et l'autre sans, ça donne de quoi entraîner une
IA. Ou si on récupère la HR floutée et qu'on l'original localement.

Jean-Yvon

Le 19/06/2020 à 11:58, Laurence P - laupic...@posteo.net a écrit :


Je viens d'envoyer un email au support pour supprimer toutes mes
photos et supprimer mon compte, ils m'ont répondu qu'ils pouvaient
aussi détacher les photos de mon compte et sinon ils peuvent m'aider à
les supprimer ça leur prendra une semaine.

Laurence

Le 19/06/2020 à 11:52, Vincent Bergeot a écrit :

Le 19/06/2020 à 09:56, Stéphane Péneau a écrit :

Ce qui change aujourd'hui :
A part l'utilisation gratuite pour l'usage commercial, pas grand-chose.

je cite :
"Historically, all of the imagery available on our platform has been
open and free for anyone to use for non-commercial purposes. Moving
forward, that will continue to be true, except that starting today,
it will also be free to use for commercial users as well."

DeepL : "Historiquement, toutes les images disponibles sur notre
plateforme ont été ouvertes et gratuites pour toute personne
souhaitant les utiliser à des fins non commerciales. À l'avenir, cela
continuera d'être vrai, sauf qu'à partir d'aujourd'hui, l'utilisation
sera également gratuite pour les utilisateurs commerciaux."

je ne comprends pas l'argument qu'ils donnent dans l'article de blog,
repris ici.

Les images sont en cc-by-sa, cela n'a jamais empêché un usage
commercial ? Où ils parlent de l'accès à certaines services ?

Qu'est ce que je ne comprends pas ?

à plus


--
Laurence

___
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] Tickets Restaurants et StreetComplete

2020-06-17 Thread osm . sanspourriel


D'où ma proposition de faire une quête en plusieurs étapes :

- tous tickets, papier et/ou carte et/ou carte sans contact
- certains
- aucun.

Soit une matrice de 9 cases (plutôt douze : ajouter tous supports pour
remplacer trois clics par un ?). Il est probable que si dans un coin on
accepte les cartes avec ou sans contact à côté ce sera sans doute pareil
: retenir les dernières configurations rencontrées serait un gain de temps.

Et dans le cas de la seconde ligne on passe au détail des cartes.

Je ne sais si cette solution est implémentable avec SC.

Mais au moins on répond à tous les cas sans transformer son passage à la
caisse en un clicodrome.

Jean-Yvon

Le 17/06/2020 à 10:57, Marc M. - marc_marc_...@hotmail.com a écrit :

Le 17.06.20 à 10:33, Guy Godfroy a écrit :

Je ne sais pas quoi déduire ce cette conversation.

au plus on essaye de faire ultra compliqué en une fois,
au moins cela abouti.
j'ai proposé de faire la première étape "papier"
et même là il y a pas concensus puisque Donat
dit qu'un poi doit les accepter tous (ce qui implique
qu'il n'est pas nécessaire de demander la marque)
tandis que d'autre disent que ce n'est pas exact.
et pourtant ce point doit être vérifié pour pouvoir
faire une quête SC efficace et correcte à la fois.

___
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] Numéro sans nom de rue : faux positifs dans la validation de JOSM

2020-06-16 Thread osm . sanspourriel


Éligible, oui. C'est aussi bien-sûr le nom du truc entre les rues^^.

Sauf que ça reviendrait à créer une associatedStreet sans house.

Car la mairie n'a pas d'adresse.

Plus exactement toute la place est numérotée de 2 à 20. Manque le 1 et le 6.

La Mairie pourrait être le 1 ou le 6.

Donc en toute logique il faudrait sortir la mairie de l'associatedStreet
(qui est la seule de la relation actuellement).

Le 15/06/2020 à 16:12, Philippe Verdy - ver...@gmail.com a écrit :

"La Place" ici est le nom de la boucle. Les rues qui s'y connectent
ont leur propre nom, dont cette place n'hérite pas.
S'il y a des panneaux je suis presque certain que ça affiche "La
Place" comme nom de "rue".
Bref "La Place" serait donc éligible à une relation associatedStreet
sous ce nom pour ensuite mettre les noeuds membres des adresses
situées autour (s'il y en a, en principe oui et c'est porté au
cadastre même si ce n'est pas affiché sur le terrain)

Le sam. 13 juin 2020 à 20:09, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

La précision "pour la France" est importante car certains pays
n'ont pas encore les délimitations des différents échelons
administratifs et donc le is_in est encore utile dans certains pays.

On peut continuer le nettoyage, tell que le nom de rue des points
d'adresses qui sont dans une relation associatedStreet.

Pour avoir viré des références INSEE sur les mairies des
départements 59/62, je peux affirmer que le nombre de noms mal
tapé est impressionnant (merci Osmose).

Et j'ai un cas limite :

https://www.openstreetmap.org/way/122685881#map=19/50.14744/3.81485

https://www.taisnieres-en-thierache.fr/ confirme que l'adresse est
la bonne.

à savoir :
La Place
59550 Taisnières-en-Thiérache

Pas de numéro donc logiquement

add:place=La Place

Et on met La Place en place=square ?
Mais dans ce cas on ne met pas dans une associatedStreet.

Ou on considère au niveau d'Osmose que c'est un faux positif ?

Le 13/06/2020 à 19:25, Yves P. - yves.prat...@gmail.com
 a écrit :

Il me semble qu'il y a eu du ménage de fait sur les is_in=*

Est-ce que ça vaudrait le coup de faire pareil ?

Un petit coup de requête Overpass dans JOSM (pour la France) et… c'est 
réglé :)

__
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


___
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] « Faut-il/Pourquoi/Comment intéresser les POI à la présence/exactitude des leurs données dans OSM. »


La réponse : gilet haute visibilité OpenStreetMap France. Tu dis que tu
fais un relevé, tu dis que c'est pour alimenter la base OSM.

S'il ne comprends pas, tu te retournes, lui dit de flasher le QR code.

Tu as raté le STOM 2017 ?

/Et comme la police n'est pas violente en France, pas de risque d'être
pris pour un vulgaire GJ ou sans risque^^/

Le 14/06/2020 à 21:11, Jacques Lavignotte - jacq...@lavignotte.org a écrit :

Bonjour,

dans la liste du père Noël lancée par Marc_Marc

https://annuel2.framapad.org/p/osm-retour-communaute-9h8d

 j'ai ajouté  (lignes 15-18 en vert) un sujet tel que dans l'objet de
ce mail.

Mon questionnement vient de mon expérience terrain :

- que dire au commerçant dont vous photographiez la devanture,
a qui vous demandez ses horaires et plein de questions qui lui font se
demander qui vous êtes...

- quels éléments mettre en avant pour l'inciter à tenir à jour ses
données ?

- comment en faire un contributeur limité mais impliqué ?


Ces question ont pour moi des réponses « politiques » plus que
techniques tenant dans un plaidoyer construit en se mettant à la place
du commerçant/artisan/whatever

A vous lire sur ce sujet.

Jacques

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

Re: [OSM-talk-fr] Comment orthographier un nombre ordinal


Ades, le Grévisse est compatible, il ajoute juste le cas du pluriel.


28^e? Mais pour saisir name=28^e dans JOSM (avec e en exposant), je
sais pas faire. Et je crains que ça perturbe certains outils.


Effectivement on saisit sur une seule ligne, et comme le note Ades : « …
écrire le suffixe sur la ligne, comme on le fait parfois, est
regrétable, parce qu’il risque d’entrainer une mauvaise lecture. »

C'est regrettable mais c'est le boulot du moteur de rendu que de
remplacer e par ^e . Que le nombre soit en chiffres
romains ou arabes.

Oui la probabilité que le moteur de rendu le fasse pour les textes en
français est à peu près nulle ! Mais ce n'est pas ta question ;-). La
réponse à ta question c'est qu'au nombre cardinal correspondant tu
ajoutes usuellement er, ère ou e. Le fait que ce soit en exposant c'est
de la typographie, pas de l'orthographe^^.

Jean-Yvon

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

Re: [OSM-talk-fr] Les glaciers noirs ou partiellement noirs


Typiquement un truc décomposé en deux ici partageant une frontière, ça
se modélise par une relation site et tu mets le nom dessus.

Sinon avec la version de Marc tu vas avoir 3 glaciers.

Plus simple :

- il y a le glacier (couvert de glace ou de moraines) natural=glacier
name=
- il y a la partie blanche surface=ice
- il y a les moraines et le glacier noir surface=scree. A priori cette
zone jouxte la précédente mais va au delà de la première.

3 polygones (a priori), un glacier.

Sur la page de discussion
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Glaciers_tags
il est aussi question de glacier:moraine
=medial/terminal/lateral


Comme l'exploitation de l'imagerie aérienne n'est pas évidente, c'est
peut-être le plus simple.

Cette proposition est restée à l'état de proposition.
Et je ne suis pas à l'abri d'avoir dit une connerie, je connais mieux le
littoral que les glaciers !

Note : il existe 23 natural=moraine à comparer aux 160 000 natural=scree
1 surface=moraine et 301 surface=scree.

Jean-Yvon

Le 14/06/2020 à 09:44, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 14.06.20 à 09:28, Arnaud Champollion a écrit :

Quand le glacier a une partie visible et une partie recouverte, on le
coupe en deux et on ajoute surface=scree sur la partie recouverte ?
Est-ce que les deux parties doivent alors porter le nom ?

vu qu'il n'ŷ a qu'un glacier avec ce nom,
je ne ferrais qu'un objet pour le nom (qui comprend la partie blanche
et sa moraine). puis si on veux faire plus précis, 2 autres objets
pour tager séparement les 2 parties, sans nom.

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete


> Moins de 10 cartes bancaires utilisables en France, et moins de 5
pour les titres restaurant si j'ai bien tout relu.
Soit 2*10 + 3*5=35, Marc exagère donc mais n'est pas si loin car il y a
d'autres moyens de payement ;-). Et n'oublions pas que pour les
terminaux c'est à faire par terminal et non par commerce si tous ne sont
pas équipés pareil.

Il faut penser un minimum à l'ergonomie et SC c'est fait pour les cas
simples.

Soit on propose :
- non/oui 4 types de tickets/oui (autres)
- Si oui : papier oui/non, cartes oui/non, sans contact oui/non.

On peut aussi proposer :

Ticket restaurant papier oui/non
Ticket restaurant carte oui/non
Ticket restaurant carte sans contact oui/non

Apetiz papier oui/non
Apetiz carte oui/non
Apetiz carte sans contact oui/non

Chèque Déjeuner papier oui/non
Chèque Déjeuner carte oui/non
Chèque Déjeuner carte sans contact oui/non

Pass restaurant papier oui/non
Pass restaurant carte oui/non
Pass restaurant carte sans contact oui/non

Et pareil pour les cartes bancaires (sauf la version papier)
Après on peut ajouter les chèques, les gros billets, le liquide en
général...

Si SC me propose ce b... dans son intégralité, je n'utilise pas.
Maintenant si Yves nous fait une passe sur tous les commerces (allez, on
commence par les restaurants), tope-là ;-).

En France carte bancaire implique de facto CB, Visa, Mastercard et
titres restaurant les 4, non ?

KISS

Jean-Yvon

Le 09/06/2020 à 14:48, Yves P. - yves.prat...@gmail.com a écrit :

Doit-on profiter pour demander en plus si le terminal accepte le sans
contact ?

On demande tout ce qu'on peut concernant les moyens de paiement :)
Comme ça il n'y a plus à revenir.

__
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] Comment orthographier un nombre ordinal


Ne pas être plus royaliste que le roi.

En effet les bataillons et régiments comme les rois utilisent
normalement la forme abrégée.

C'est comme pour les dates, on n'écrit pas Rue du Dix-Neuf Mars 1962.

Quai du 28^e  bataillon de chasseurs : tu peux ajouter

name:etymology:wikidata
=Q2815671


Le 14/06/2020 à 09:33, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 13.06.20 à 20:25, Florimond Berthoux a écrit :

abréviation de vingt-huitième

https://wiki.openstreetmap.org/wiki/FR:Names#Abr.C3.A9viation_.28.C3.A0_ne_pas_faire.29

la règle est de ne pas mettre d'abréviation dans name


mais le terrain prime :)

ce n'est pas parce qu'une plaque de rue a une taille limitée,
que osm doit se limiter.
sinon supprimons 99% des noeuds des frontières administratives,
le terrain prime, et il n'y a rien sur le terrain ? :)

Cordialement,
Marc

___
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] Comment orthographier un nombre ordinal

2020-06-13 Thread osm . sanspourriel


http://www.circaete.net/eric/Lexique%20des%20r%C3%A8gles%20typographiques%20en%20usage%20%C3%A0%20l%27Imprimerie%20nationale.pdf

À afficher 28^e   ça va de soi, comme indiqué page 62 /123.

Avec un clin d’œil page 38 (74) pour l'échelle cartographique.

Petite correspondance : Donat, du coup je vois que l'ONU s'écrit
Organisation des Nations unies (et pas Organisation des nations unies ou
Organisation des Nations Unies).

Sinon plus accessible :
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#Adjectifs_num%C3%A9raux_ordinaux

Le 13/06/2020 à 21:27, Topographe Fou - letopographe...@gmail.com a écrit :

Selon les règles typographiques de l'imprimerie nationale (très bon
bouquin que je recommande) : 28e . Cependant ce n'est pas rare de voir
28ème sur des documents officiels ou dans la presse écrite.

LeTopographeFou
*De:* bernard.lefranc...@free.fr
*Envoyé:* 13 juin 2020 7:42 PM
*À:* talk-fr@openstreetmap.org
*Répondre à:* talk-fr@openstreetmap.org
*Objet:* [OSM-talk-fr] Comment orthographier un nombre ordinal


Bonjour,

Je cherche la meilleure façon d'orthographier le "Quai du 28ème
Bataillon de Chasseurs ".

28ème comme ci-dessus avec accent (ma préférence)
28Eme, 28Ème, 28E
Sans espace, avec espace.

En tout cas la graphie actuelle 28° ma parait la pire.

Qu'en pensez-vous?


___
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] Numéro sans nom de rue : faux positifs dans la validation de JOSM

2020-06-13 Thread osm . sanspourriel


La précision "pour la France" est importante car certains pays n'ont pas
encore les délimitations des différents échelons administratifs et donc
le is_in est encore utile dans certains pays.

On peut continuer le nettoyage, tell que le nom de rue des points
d'adresses qui sont dans une relation associatedStreet.

Pour avoir viré des références INSEE sur les mairies des départements
59/62, je peux affirmer que le nombre de noms mal tapé est
impressionnant (merci Osmose).

Et j'ai un cas limite :

https://www.openstreetmap.org/way/122685881#map=19/50.14744/3.81485




https://www.taisnieres-en-thierache.fr/ confirme que l'adresse est la bonne.

à savoir :
La Place
59550 Taisnières-en-Thiérache

Pas de numéro donc logiquement

add:place=La Place

Et on met La Place en place=square ?
Mais dans ce cas on ne met pas dans une associatedStreet.

Ou on considère au niveau d'Osmose que c'est un faux positif ?

Le 13/06/2020 à 19:25, Yves P. - yves.prat...@gmail.com a écrit :

Il me semble qu'il y a eu du ménage de fait sur les is_in=*

Est-ce que ça vaudrait le coup de faire pareil ?

Un petit coup de requête Overpass dans JOSM (pour la France) et… c'est réglé :)

__
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] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

2020-06-13 Thread osm . sanspourriel


J'ai été étonné qu'Yves n'a pas réagi sur "URL de chaque point de vente
d'une enseigne" car grosso-modo c'est une expression régulière basée sur
une ref... comme les liens Wikidata.

Mais je pense que c'est plus un projet du mois pour qu'on recherche pour
les enseignes ces infos.

Après l'assos peut avoir un outil surveillant l'ajout de ref ou d'url
sur une enseigne pour proposer d'ajouter l'url spécifique (objet du
message de Florian, oui il dit que ce n'est pas vraiment une ref).

Mais l'outil sans que les gens ne contribuent à trouver les URL... C'est
vrai que la recherche dans le cadre du covid nous a fait progresser.

Pour d'autres, il n'y a pas d'URL pour chaque point de vente, exemple
https://www.marionnaud.fr/magasins  et là, c'est le drame.

Non, je dirais : ils n'ont pas un site ergonomique mais un site pistant
via GM, qu'ils assument, tant pis pou eux.

Je me demande si la licence "tout droits réservés" de ces sites n'est pas
un blocage à réaliser ces opérations. Peut-être est-ce le cas uniquement
pour la réutilisation des géoloc des lieux, ce qui bloquerait uniquement la
réutilisation par OSMOSE.

A priori c'est dans leur intérêt que les magasins soient bien
documentés. certains ne font-ils pas appel à SeFaireConnaitre pour être
présents dans OSM ?
Avoir un message type pour demander de libérer les données en ODbL (ou
toute licence compatible avec OSM^^) précisant le cadre et l'intérêt
devrait suffire... à condition d'arriver à faire tomber l'info dans la
boite-aux-lettres d'une personne pouvant approuver.

Concernant la géolocalisation, si le magasin est déjà dans OSM elle peut
être relativement imprécise. Voir on peut se baser juste sur l'adresse.

Jean-Yvon

Le 10/06/2020 à 21:57, Romain MEHUT - romain.me...@mailo.com a écrit :

J'ajoute aussi ce qu'a proposé Florian
https://lists.openstreetmap.org/pipermail/talk-fr/2020-May/099075.html
mais resté sans réponse.

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

Re: [OSM-talk-fr] et si c'était Nöel ? liste de souhait et d'intérêt des outils existant

2020-06-11 Thread osm . sanspourriel


Le 11/06/2020 à 12:50, Yves P. - yves.prat...@gmail.com a écrit :

Il y a un prérequis assez important qui exclut la mailing liste ou le
forum actuel :
Pouvoir insérer des photos ou captures d'écrans très facilement. Un
glisser-déposer ou ctrl+v doit suffire.

Matrix fait ça bien et il est libre :)

Oui, si la réponse est d'utiliser forcément un réseau propriétaire c'est
que la question n'est pas bonne^^.

Le glissé-déposé de photos est possible sur Thunderbird depuis déjà pas
mal de temps, c'est donc au plus la restriction de la taille maximale
d'un message qui peut poser soucis et que peut être ajustée je suppose.

Rien n'empêche donc d'utiliser cette liste-ci.

Jean-Yvon

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

Re: [OSM-talk-fr] type de rivière pour la bièvre

2020-06-09 Thread osm . sanspourriel


J'aurais dit comme toi.

Jean-Yvon, non spécialiste du sujet.

Le 09/06/2020 à 14:55, Georges Dutreix via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Bonjour,

La bièvre est river sur certains tronçons et stream sur d'autres. Ça
fait un peu brouillon sur le rendu, Même si elle est enterrée presque
partout.

J'aurais tendance à mettre stream mais je suis certain qu'il y a ici
des connaisseurs de la base Sandre qui pourront me préciser la bonne
étiquette :
http://www.sandre.eaufrance.fr/geo/CoursEau/F70-0400

Merci
Georges

___
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] Tickets Restaurants et StreetComplete

2020-06-09 Thread osm . sanspourriel


Je dirais comme Guy *actuellement* mais si on regarde l'évolution des
chèques (dont le principe est similaire sauf que le risque d'impayé est
plus élevé), on voit de plus en plus de magasins refuser les chèques. Il
est possible, et c'est le but du cartel, qu'à terme ils éliminent les
tickets (gestion dématérialisée mais frais identiques).

Si c'est pour simplifier une quête  StreetComplete ça semble
raisonnable, si c'est pour changer le modèle de tags je suis plus réservé.

Doit-on profiter pour demander en plus si le terminal accepte le sans
contact ?

Jean-Yvon

Le 09/06/2020 à 11:09, Guy Godfroy - guy.godf...@gugod.fr a écrit :

Honnêtement je crois que j'ai jamais vu de gens qui acceptaient la carte
mais pas le papier.

D'autre part il me semble (mais je peux me tromper) que seul EdenRed
émet des cartes à puce pour titre restaurant, et s'appuie sur le réseau
MasterCard pour ça, de sorte que si un commerce est habilité à recevoir
des titres restaurant et possède un terminal compatible mastercard, il
me semble que ça passera forcément.

À noter que si effectivement seul EdenRed emet des cartes à titre
restaurant, ces cartes peuvent toutes faire des paiement sans contact.

Le 09/06/2020 à 10:51, Marc M. a écrit :

Bonjour,

Le 09.06.20 à 10:41, Guy Godfroy a écrit :

pour l'instant il suffit de répondre oui ou non à la question
"Est-ce que ce restaurant accepte les titres restaurants".
Est-ce qu'on est d'accord là dessus ?

Pour la France oui, avec le soucis papier<>électronique.
est-ce que tout ceux qui accepte l'electronique accepte
aussi obligatoirement le papier ?

Cordialement,
Marc

___
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



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

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national


Le 08/06/2020 à 14:59, didier2020 - osm2...@free.fr a écrit :

c'est quelqu'un dont le métier est la route
12+1600 veut dire 1600 m après 12


D'après les photos
,
j'avais cru comprendre

ref= A 86 (ou A 86 extérieur)
distance= 29.

Si maintenant c'est 1+29 et que ce n'est pas sur le terrain... ça change
tout !

Jean-Yvon

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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete


En France, d'après ce site je dirais effectivement inutile.

Par contre il importe de faire la distinction version papier/version
dématérialisée.

Certains commerçants acceptent la version papier pas la version
dématérialisée.

Par homogénéité avec

payment:mastercard
payment:mastercard_contactless

Je dirais :

payment:meal_voucher=yes
payment:meal_voucher_contactless=yes

(merci Yves).

Comme ce sont les terminaux qui sont acceptés ou pas par l'organisme
central, pour bien faire il faut faire de l'indoor ! Car dans un même
magasin toutes les caisses vont accepter le papier et pas toutes la
carte. payment:meal_voucher=paper;pin;contactless est moins verbeux.

Je ne sais si contactless est uniquement une propriété du terminal
(auquel cas c'est payment:contactless=yes qu'il faudrait mettre) ou si
ça dépend des contrats des commerçants.

Car il y a 3 moyens de payer : version papier, version sans contact et
version avec code.

Les "gentils organisateurs" se sont faits prendre les mains dans le pot
de confiture en s'échangeant des données personnelles.

Jean-Yvon

Le 08/06/2020 à 18:10, LeTopographeFou - letopographe...@gmail.com a écrit :

Dans ce cas en effet pas besoin de différencier dans OSM et
payment:meal_voucher=yes/no suffit (même pas besoin de brand)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration du bornage du réseau routier national


https://www.mapillary.com/app/?lat=48.8611312=2.4841852=17=G1IiVslryLcBZplrme2ENA=photo=0.30771109667569485=0.7322106887594706=3

Ce serait A 86 ou A 86 extérieur ? Sur le panneau il y a A 86 extérieur.

Et à partir de ça on sait reconstituer la référence RRN ?

"+" pour indiquer que la distance est positive ? Semble évident !

Le 08/06/2020 à 15:07, didier2020 - osm2...@free.fr a écrit :

Le lundi 08 juin 2020 à 14:31 +0200, Marc M. a écrit :

Le 08.06.20 à 13:26, didier2020 a écrit :

- 9057 ont un tag ref

ce serrait sans doute utile de chercher quelques photos
de borne avec la ref visible.

https://www.mapillary.com/app/?lat=48.8247647=2.4636774=17=IlaESQuLBwKEqsw1F-FV4w=photo=0.5059995150967409=0.4975920048505564=0

https://www.mapillary.com/app/?lat=48.8611312002=2.484185199562=16.84333642656937=G1IiVslryLcBZplrme2ENA=photo

https://www.mapillary.com/app/?lat=49.073468617885425=2.332858531006834=17=vxFrND-wENkm_OfdYDqsmA=photo


  60 sont du texte/inclus un . ou +

. est le séparateur décimal dans osm, du coup c'est numérique.
le + est + étrange.


ref:highway
serait une solution

à mon avis, quand il n'y a pas consensus, osmose doit s'abstenir
donc intégrons déjà toutes les bornes sans ref:highway


"notre" besoin de référence unique

quel besoin ? si la ref dans la source n'est pas unique, elle n'est
pas
unique.
prenons un exemple fictif : si la sncf décide de peindre ses places
de parking en commençant par 1 sur tous ces sites, cela ferra des
ref=1
non unique dans osm.
ce n'est pas le rôle d'osm d'inventer une ref genre ref:FR:SNCF:siteA
par dogme d'unicité dans osm.
ou exemple réel : la route ref=1 n'est pas unique dans osm,
c'est la réalité, cela n'empêche pas son utilisation.

dupliquer + tard un ref:highway s'il y a un cas d'usage et un
consensus,
c'est toujours possible

___
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



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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete


Ou acceptent la version papier mais pas la version carte.

Le 08/06/2020 à 13:36, Yves P. - yves.prat...@gmail.com a écrit :

Demander quand même car certains commerces n'ont plus le lecteur et n'ont pas 
enlevé l'autocollant sur la vitrine.



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

Re: [OSM-talk-fr] Proposition d'analyse pour Osmose


Peut-être tout simplement :

mean (camera, guard)
function (licence_plate, facial_recognition, traffic...) - ou ALPR
(Automatic licence-plate recognition)

Je suppose que pour la reconnaissance des plaques d'immatriculation ils
utilisent maintenant des caméras, même si du côté de Bure ils utilisent
encore des gendarmes (non tagués dans OSM, ils bougent, sauf à mettre
une zone).

Blague à part, la lecture des plaques est une fonction mais ce qu'il est
fait de cette collecte de données n'est pas indiqué. Par exemple les
radars tronçons utilisent cette technique mais du coup sont des
relations enforcement=average_speed.

Maintenant se pose la question de la vérifiabilité sur le terrain. On
peut imaginer des caméras "ordinaires" sur les rues d'une ville et
d'ajouter la détection faciale au niveau du PC de coordination. Par
exemple en le justifiant par le "besoin" de retrouver ceux qui jettent
des masques usagés : rien ne l'indiquera sur le terrain.

C'est d'ailleurs le cas des caméras de mesure moyenne de vitesse : les
plaques doivent être lues (et transmises à l'autre caméra ou au PC),
est-ce que les images brutes sont aussi transmises au PC ?

Si les autres personnes de la liste n'ont pas d'objection on peut faire
une proposition dans ce sens.

Jean-Yvon

Le 08/06/2020 à 09:36, Percherie OnDaNet - perche...@toutenkamion.net a
écrit :

Ah oui quand même... je n'avais pas fait attention qu'il est en proposed

Merci pour la précision quant au mélange des moyens et fonctions de ce
tag. J'espère qu'il sera amélioré ou remplacé par une autre proposition.

Le 08/06/2020 à 08:34, osm.sanspourr...@spamgourmet.com a écrit :

Le statut de cet horrible ":type" est proposed.

Horrible car mélangeant le moyen utilisé (caméra, humain) et la fonction
(identification des plaques d'immatriculation).

Donc ne pas faire d'intégration Osmose.

Jean-Yvon

Le 07/06/2020 à 20:24, Gad.Jo - perche...@toutenkamion.net a écrit :

(...)

Autre remarque concernant les caméras de surveillance. J'ai souvent
remarqué qu'elles ne portent pas le tag surveillance:type=*, très
souvent c'est le tag surveillance:type=camera qui est manquant :
https://wiki.openstreetmap.org/wiki/Key:surveillance:type

Est-il envisageable de prévoir ces cas pour Osmose ?

Cordialement




___
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



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

Re: [OSM-talk-fr] Proposition d'analyse pour Osmose


Le statut de cet horrible ":type" est proposed.

Horrible car mélangeant le moyen utilisé (caméra, humain) et la fonction
(identification des plaques d'immatriculation).

Donc ne pas faire d'intégration Osmose.

Jean-Yvon

Le 07/06/2020 à 20:24, Gad.Jo - perche...@toutenkamion.net a écrit :

(...)

Autre remarque concernant les caméras de surveillance. J'ai souvent
remarqué qu'elles ne portent pas le tag surveillance:type=*, très
souvent c'est le tag surveillance:type=camera qui est manquant :
https://wiki.openstreetmap.org/wiki/Key:surveillance:type

Est-il envisageable de prévoir ces cas pour Osmose ?

Cordialement




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

Re: [OSM-talk-fr] Attributions manquantes sur Mon GR !

J'étais gentil.

Si vous cherchez de l'aide vous trouvez ceci :

Les données cartographiques (traces, pas à pas et *POI hébergeurs*)
issues de la consultation en ligne figurant sur le site MonGR.fr sont la
propriété de la FFRandonnée. ©FFRandonnée - Reproduction interdite

Je ne sais ce qu'ils entendent par là. Si par hébergeur ils entendent
des chambres d'hôtes et Cie pourquoi pas.

Si par contre ce sont les points d'intérêts fournis par ESRI et donc les
POI d'OSM...

Le 04/06/2020 à 23:15, Jean-Yvon Landrac a écrit :

C'est un peu comme ceux qui utilisent MapBox :
- tu sélectionnes OpenStreetMap (comme quoi OSM est bien cité)
- et après non une référence à MapBox (et pour cause) mais "powered by
ESRI".

Tu trouves un lien qui te mène vers https://www.esri.com/fr-fr/home

Et en cherchant tu tombes sur :

https://www.esri.com/arcgis-blog/products/arcgis-online/announcements/whats-new-with-openstreetmap-basemap-june-2019/

Sur lequel est précisé :

/You just need to give appropriate credit for use of the map (i.e.
“Map data © OpenStreetMap contributors, Map layer by Esri”) in your work./

C'est sûrement un oubli de la FFRP vu qu'ils sont à cheval sur les
propriétés intellectuelles.

Jean-Yvon

Le 04/06/2020 à 21:01, Yves P. - yves.prat...@gmail.com a écrit :

Bonsoir,

https://www.mongr.fr permet d'afficher des itinéraires avec différents fonds
de plan, dont OSM 

Mais pas de trace du mot OpenStreetMap dans leur site, et encore moins
d'attributions 

__
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] Attributions manquantes sur Mon GR !


C'est un peu comme ceux qui utilisent MapBox :
- tu sélectionnes OpenStreetMap (comme quoi OSM est bien cité)
- et après non une référence à MapBox (et pour cause) mais "powered by
ESRI".

Tu trouves un lien qui te mène vers https://www.esri.com/fr-fr/home

Et en cherchant tu tombes sur :

https://www.esri.com/arcgis-blog/products/arcgis-online/announcements/whats-new-with-openstreetmap-basemap-june-2019/

Sur lequel est précisé :

/You just need to give appropriate credit for use of the map (i.e. “Map
data © OpenStreetMap contributors, Map layer by Esri”) in your work./

C'est sûrement un oubli de la FFRP vu qu'ils sont à cheval sur les
propriétés intellectuelles.

Jean-Yvon

Le 04/06/2020 à 21:01, Yves P. - yves.prat...@gmail.com a écrit :

Bonsoir,

https://www.mongr.fr permet d'afficher des itinéraires avec différents fonds de 
plan, dont OSM 

Mais pas de trace du mot OpenStreetMap dans leur site, et encore moins 
d'attributions 

__
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] Intégration du bornage du réseau routier national


> - la distance c'est distance= :)
Et par défaut c'est en km (d'où l'utilisation de kp/pk au lieu de
distance par le passé)

> - la ref de la voie n'est pas la ref de la borne
+1, tu veux dire que sur la voie il faut ref:FR:RRN ? ;-) Private joke.

Il me semble qu'une modélisation proche de celle des associatedStreet
serait adaptée pour factoriser l'information disons associatedRoad :

- en membres road les segments de route dans l'ordre croissant des
distances (l'équivalent des street)
- en membres milestone les plo dans l'ordre croissant des distances
(l'équivalent des street)

- en attributs :
ref=la fameuse référence qui n'est pas celle de la voie.
network=RRN

Ainsi on peut présenter facilement facilement les infos Bison Futé soit
précisément (en utilisant les road) soit grossièrement (en faisant une
courbe entre les différents milestone).

Après il faudrait voir les cas des différents sens.

Typiquement comme pour les transports publics avec une super route si
besoin ? backward=yes si on est du côté "gauche" au sens du RRN /(c'est
à dire probablement dans le sens province-Paris (*))/ ?

  + DB pour début bretelle (plo DB1 pr 1, plo DB2 pr 2)
  + FB pour fin bretelle (plo FB1 pr 1, plo FB2 pr 2)

J'avoue ne pas comprendre si on devrait avoir l'info de début/fin de
bretelle dans OSM. Ce sont grosso-modo les extrémités de la bretelle.
Donc distance=0 pour la première et max(distance). Et pas de super
routes dans ce cas là : les bretelles ont un sens sauf sous l'emprise de
l'alcool ;-).

Ça permettrait de modéliser plus proprement et d'éviter les ambiguïtés
de ref.

Juste une idée, à jeter, à améliorer, à discuter (ici, tagging ou wiki).

Jean-Yvon

/(*) calcul de la distance pour aller d'un point A a un point B en
France = distance (Paris, A) + distance (Paris, B) ;-(./

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

Re: [OSM-talk-fr] Quelle est la solution la plus simple de remplacer une carte Google avec des POI.


Pas de soucis pour ton "franglais". Ce serait déjà  bien si tous les
Français parlaient comme ça. Ce qu'on n'aime pas ces quand certains
commencent une discussion dans une autre langue - tu devineras laquelle
- sans essayer même un résumé en français, ne serait-ce qu'une
traduction via deepl.com par exemple.

Liste francophone sur le projet OSM.

Jean-Yvon

Le 04/06/2020 à 10:04, European Water Project -
europeanwaterproj...@gmail.com a écrit :

Merci Cyrille !

J'espère que mon franglais passe aussi :)

Amicalement,

Stuart

On Thu, 4 Jun 2020 at 09:54, Cyrille37 OSM via Talk-fr
mailto:talk-fr@openstreetmap.org>> wrote:

Bonjour Stuart,

Le 04/06/2020 à 08:38, European Water Project a écrit :

Je vous prie de m’excuser pour cette demande de conseil sur un
sujet qui n’est pas lié à OSM France.


Juste une précision: cette liste de discussion n'est par réservée
"OSM France" mais bien à tout ce qui concerne le projet
OpenStreetMap, avec des échanges en langue française ;-)

Bonnecontinuation,

Cyrille37.

___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-06-02 Thread osm . sanspourriel


Perdu, permissive veut dire permissif, laxiste.
Tu ajoutes un "et l'affiche" qui te permet de retomber sur tes pieds.
Sauf que ce n'est pas dit.

Et là on a un trottoir que la municipalité laisse utiliser par des vélos
alors qu'un trottoir n'est normalement pas autorisé à la circulation
autre que piétonne.

https://www.linguee.fr/francais-anglais/search?source=auto=permissive

/permissive

adjectif/
/permissif
 adj
(permissive f sg, permissifs
 m
pl, permissives
 f
pl)//
/
///
//laxiste
 adj/

https://dictionary.cambridge.org/dictionary/english/permissive

/permissive/
/adjective/
/uk
/pəˈmɪs.ɪv/us
/pɚˈmɪs.ɪv//
///
//permissiveadjective(LIBERAL) //
///
//
//
//
/A //person
//or
//society
//that is
permissive //allows
behaviour
//that
other //people
//might
//disapprove
//of: /
/It's a very permissive school
 where the
children 
are allowed 
to do whatever they want
./
/He claims 
that society
 has been
far  too
permissive *towards* drugs
./

Jean-Yvon

Le 01/06/2020 à 23:02, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Perdu, permissive ne veut pas dire toléré (illégal mais autorisé)
« permissive : Open to general traffic until such time as the owner
revokes the permission which they are legally allowed to do at any
time in the future. »
C'est un truc d'abord anglais où le propriétaire autorise l'accès
public (et l'affiche) mais peut le fermer à tout moment.
Voir
https://en.wikipedia.org/wiki/Rights_of_way_in_England_and_Wales#Permissive_path

Je ne dirais pas que ça n'existe pas en France, mais ça me semble très
rare.

Le lun. 1 juin 2020 à 22:32, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

/J'avais l'impression que les pistes cyclables à Paris ça servait
aussi aux voitures comme place de parking :-(. Ah, non seulement
les bandes !
/

Donc si on revient sur le coin d'où on est parti :

- y a-t-il un panneau autorisant les cycles ? Non
- y a-t-il un panneau interdisant les cycles ? Non

De partout on arrive sur ce qui ressemble soit à un trottoir soit
à une place piétonne.

Dans le premier cas bicycle=no (implicite, c'est un footway).

Dans le second cas bicycle=yes (implicite c'est un pedestrian).

Et comme c'est pas clair on met bicycle=permissive : pas fait pour
mais personne ne dit rien.

J'ai l'impression d'avoir suivi ta logique et j'aboutis à une
solution qui semblait convenir aussi à Eric.

Le 01/06/2020 à 21:19, Florimond Berthoux -
florimond.berth...@gmail.com 
a écrit :

Non, il n'y a pas de panneau "motocycle autorisé" donc tu ne tag
que highway=cycleway, de la même manière qu'il faut un panneau
"piéton interdit" pour tagguer foot=no sur un cycleway.
Et de plus tu verras aussi que les deux roues motorisés qui
roulent dessus se font verbaliser.
On tag la piste cyclable pas son interprétation légal.

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



--
Florimond Berthoux

___
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] Désaccord sur un highway=footway

2020-06-01 Thread osm . sanspourriel


/J'avais l'impression que les pistes cyclables à Paris ça servait aussi
aux voitures comme place de parking :-(. Ah, non seulement les bandes !
/

Donc si on revient sur le coin d'où on est parti :

- y a-t-il un panneau autorisant les cycles ? Non
- y a-t-il un panneau interdisant les cycles ? Non

De partout on arrive sur ce qui ressemble soit à un trottoir soit à une
place piétonne.

Dans le premier cas bicycle=no (implicite, c'est un footway).

Dans le second cas bicycle=yes (implicite c'est un pedestrian).

Et comme c'est pas clair on met bicycle=permissive : pas fait pour mais
personne ne dit rien.

J'ai l'impression d'avoir suivi ta logique et j'aboutis à une solution
qui semblait convenir aussi à Eric.

Le 01/06/2020 à 21:19, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Non, il n'y a pas de panneau "motocycle autorisé" donc tu ne tag que
highway=cycleway, de la même manière qu'il faut un panneau "piéton
interdit" pour tagguer foot=no sur un cycleway.
Et de plus tu verras aussi que les deux roues motorisés qui roulent
dessus se font verbaliser.
On tag la piste cyclable pas son interprétation légal.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cycleway, footway ou path ? — Re: Désaccord sur un highway=footway

2020-06-01 Thread osm . sanspourriel


Le 01/06/2020 à 10:33, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :


Le lun. 1 juin 2020 à 09:32, Yves P. mailto:yves.prat...@gmail.com>> a écrit :

Le 31 mai 2020 à 22:24, Marc M. mailto:marc_marc_...@hotmail.com>> a écrit :

- pour éviter le flip-flop cyclway<>footway : utiliser path plus
neutre (en survolant, je n'ai vu ni panneau pour l'un ou l'autre là)


Pourquoi pas un tag neutre voie verte
 ?

Parce qu'il n'existe pas ? On est d'accord tu ne parles plus du sujet
initial ?


highway=path me gène : à la campagne, on montagne, en bord de mer…
c'est (pour moi) un sentier.


Je ne saurais dire en français la différence entre sentier et chemin.
Dans tous les cas, il me semble préférable de ne pas essayer de
traduire, car highway=path n'est pas un mot anglais c'est un tag, un
mot clé d'un langage intermédiaire entre machine et humain qui sert à
modéliser et simplifier le monde.
highway=path s'inscrit dans la hiérarchie des highways, le niveau le
plus bas, d'usage mixte et non motorisé, c'est tout.


"tout en bas de la hiérarchie", alors c'est piéton uniquement, même pas
VTT et donc moins "bien" qu'un footway (qui sera plutôt goudronné,
revêtu de stabilisé).

La différence ? Les anciennes dénominations étaient CD, CC, CR, CE :
chemin départemental, chemin communal, chemin rural, chemin
d'exploitation. On trouve toujours des CR et des CE sur le cadastre (je
crois avoir vu des CD aussi).

Donc un chemin peut supporter du trafic motorisé.

À l'opposé un sentier côtier sera en général exclusivement réservé aux
piétons (vélos et cavaliers interdits). Ça peut dépendre des coins.

Mais ici on parle d'un trottoir/place piétonne ou la circulation des
cycles n'est pas explicitement interdite.

La signalisation sur un panneau suggère qu'elle est tolérée.

C'est donc un footway, éventuellement un pedestrian, pas un path.


La voie verte, piste cyclable… est aménagée, le plus souvent
(toujours ?) goudronnée.


Pas toujours, ça peut être du stabilisé.

Jean-Yvon

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Thread osm . sanspourriel


Le 31/05/2020 à 10:46, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

je ne souhaite pas "nous tirer dans les pattes"
au contraire, je pense que tu poses le bon diagnostic :
un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
mais je pense étrangement ton outil n'est pas adapté pour cela.

je pense qu'il y a 3 cas :

1) les objets dont la position existe dans osm et auquel on ajoute des
infos opendata : à mon avis on n'a pas besoin d'un contributeur
qui fait un clic par objet sans aucune plus-value.
ex : il y une borne très proche dans osm et dans l'opendata.
l'opendata dit operator=A. c'est quoi la plus-value de le faire
à la main ? à mon avis on fait mieux de faire une procédure pour
importer tout cette donnée en une fois.


Non, cas des bornes 29 et 30 du SDIS17.

Une borne a été rapprochée (la 30), maintenant l'outil propose de
rapprocher la 29 et la 30.

Là il y a un soucis, je ne sais si c'est la 29 qui manquait dans OSM ou
la 30.

Mais c'est à voir sur le terrain (ou regarder à nouveau entre la 29 et
la 30 laquelle aurait dû être fusionnée avec la borne OSM).

Nicolas, ça veut dire que sur la carte tu ne devrais pas afficher que la
borne OD en cours mais aussi les autres (d'une autre forme et couleur)

Grosso modo on est d'accord : autant rapprocher automatiquement ce qu'on
peut rapprocher.

Sauf que l'outil permet aussi de gérer les conflits entre les valeurs
OSM et OD.

Il n'empêche ce serait autant de n'avoir à regarder que les conflits.


2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
bonne. ton outil ne permettant pas de voir la borne, il va falloir
ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
de n'avoir un outil ne nécessitant pas de basculer avec un autre.


Non, l'outil a maintenant l'imagerie aérienne. On peut imaginer que l'on
puisse créer une note afin que quelqu'un sur le terrain puisse chercher
la borne afin de la positionner.

Sinon oui pic4Review, etc...

Et pourquoi ne pas faire X % dans un outil et quand ce qui était
faisable dans cet outil a été fait, passer à un autre.

C'est à dire faire ce que l'on peut faire avec un outils sans en changer
puis passer à une autre outil pour la suite.

Par exemple quand on dit non rapprochable on peut dire :
- n'existe pas sur le terrain
- à chercher avec de l'imagerie de rue (pic4review)
- à chercher sur place.

Les deux derniers points sont peut-être confondus : on passe le reste à
pic4review et pour ceux pour qui on fait choux blanc on passe à la revue
sur le terrain. Et on peut mettre ça dans Osmose éventuellement.

Jean-Yvon



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

Re: [OSM-talk-fr] OSM Relation Analyzer — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Thread osm . sanspourriel


Tu peux demander à ne pas passer par le cache.

http://ra.osmsurround.org/analyzeMap?relationId=4840541&*noCache=on*


Et là ça marche, pas la peine d'aller embêter les admin d'OSM France, il
suffit de savoir utiliser l'outil^^.

Jean-Yvon

Le 31/05/2020 à 09:19, Yves P. - yves.prat...@gmail.com a écrit :


J'avais affichée cette relation dans Waymarked Trails: À vélo
 et
dans OSM Relation Analyzer
.
La mise à jour a été très rapide dans Waymarked Trails, par contre 32
mn après, toujours rien dans RA.


Une modification faite il y a 7 heures n'apparait toujours pas. La
dernière modification
 remonte
à 7 jours !
Il semble qu'il y a un gros retard de mise à jour de la base de
données de RA.

Est-ce qu'il est possible de faire tourner une instance sur un serveur
d'OSM France ayant déjà la base postgresql à jour ?
Cette application à besoin de la table suivante :
https://github.com/grundid/relation-analyzer/blob/master/src/main/schema/test-data.sql

__
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] Ancestris

2020-05-30 Thread osm . sanspourriel


Il est écrit :

/Vos données sont uniquement dans un fichier Gedcom, donc jamais perdues
ni illisibles d’autres logiciels, et donc pour toujours transmissibles à
vos proches./

Donc ce que je comprends c'est qu'il s'agit d'un fichier local.

Après ce que les gens en font c'est de leur responsabilité.

Pour la collaboration en ligne il existe un projet mondial
https://www.wikitree.com/ dont le but ultime est de montrer que tout le
monde est issu d'une même famille.

Avec des engagements pour participer.

Il n'empêche un projet situé aux États-Unis... et utilisant GM au lieu
d'une cartographie libre.

Jean-Yvon

Le 30/05/2020 à 04:04, Philippe Verdy - ver...@gmail.com a écrit :

Maintenant j'ai de gros doute si je lis cette page, concernant les
échanges de données:
https://docs.ancestris.org/books/mode-demploi/page/informations-partag%C3%A9es

Il n'y est fait strictement aucune mention du droit des personnes
vivantes ou décédées depuis peu de temps. Hors les données sont
riches: profession, religion, enfants, alliances, numéro d'identité ou
de sécurité sociale, célébrations religieuses, divorces, requêtes en
divorce, certifications ou autorisations, diplômes,
immigration/émigration, caste, résidence, retraite, propriété ou
patrimoine. Il ne manque plus que les revenus et les préférences ou
pratiques sexuelles, ou encore si la personne préfère la vanille ou la
fraise, ou quelle chaine TV elle regarde: pratiquement toute la vie ou
le CV découvert sur une personne est étalé, "outé" publiquement, et
partagé sans aucune forme de restriction (et sans droit à l'oubli, au
moins le temps de la vie de cette personne) :
https://docs.ancestris.org/books/mode-demploi/page/les-%C3%A9v%C3%A9nements

Le seule critère exigé c'est la conformité à un format technique
GEDCOM pour ces échanges, ce qui ne limite en fin de compte pas grand
chose.
Et absolument rien dans GEDCOM ne permet de qualifier les données pour
savoir celles soumises à des restrictions d'usage, c'est
totalement passé à la trappe. Cette spécification technique semble
être née dans des pays qui se fichent pas mal de la protection de la
vie privée (mais même dans nombre d'entre eux c'est en train de
changer, y compris aux USA); en l'état et sans le protocole qu'elle
devrait imposer dans les applications conformes, l'usage de cette
pseudo-norme seule est aujourd'hui illégal dans plein de pays; mais
rien dans cette appli ne met en garde les utilisateurs sur le fait
qu'ils ont une responsabilité et ne devraient pas échanger n'importe
quoi à n'importe qui sans autorisation explicite et vérifiable (et
sans sous-délégation à des tiers non autorisés, comme ce peut-être le
cas pour le seul logiciel mais pas les données manipulées)





Le sam. 30 mai 2020 à 03:44, Philippe Verdy mailto:ver...@gmail.com>> a écrit :

J'ai du mal à croire à une "généalogie libre" si elle met en base
de données "libre" des personnes vivantes (sans leur accord) ou
décédées depuis moins de 70 ans (ou leurs ayant-droits).

Une telle base de données nominative devrait faire l'objet d'une
déclaration à la CNIL, surtout si en plus on y attache des infos
comme les dates de naissance, lieu de naissance, liens avec
d'autres personnes vivantes, professions, lieux de travail, écoles
ou entreprises, mariages/partenariats/concubinages, enfants, et en
aucun cas une distribution libre, mais un accord de licence
personnelle pour un usage bien précis encadré par la loi et
interdisant l'exploitation en masse (à des fins commerciales par
exemple). Hors si on doit restreindre l'usage de ces données, ces
données ne sont nécessairement pas libres.
En revanche cela peut être utile seulement pour les recherches sur
les personnes décédées depuis longtemps et sans ayant-droit, dont
les données peuvent alors devenir publiques.

Bref toute personne mentionnée qui n'est pas décédée avant 1950
(aujourd'hui) ne devrait pas être du tout dans cette base de
données, et pour avoir les données, il faudrait faire des
démarches personnelles auprès de l'Insee ou l'état-civil,
précisant la finalité, et avec un engagement contractuel (et
pénal) signé auprès de l'autorité, contre les mauvaises
utilisations: le respect de la vie privée s'impose...

Je ne sais pas trop quels sont vos termes d'utilisation et ce que
contiennent les bases de données que vous développez, et encore
mois si c'est légal d'échanger entre "généalistes autodéclarés"
sur des forums publics pour obtenir de telles informations sans
l'accord des personnes nommées (et même si ces personnes figurent
dans un annuaire publié, leur exploitation à cette fin est aussi
soumise aux règles de droit et contractuelles de ces annuaires que
ce soit l'annuaire téléphonique universel, les fichiers postaux,
des adresses mail ou liens vers des pages perso sur des réseaux
sociaux, eux aussi protégés par leur éditeur selon leurs termes

[OSM-talk-fr] Fwd: Re: Désaccord sur un highway=footway

2020-05-29 Thread osm . sanspourriel


Eric, merci effectivement c'était une erreur (initialement je ne pensais
réagir que sur un point), cette fois-ci à la liste et non à toi seul !

Jean-Yvon

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :


Le 28/05/2020 à 17:27, Florimond Berthoux a écrit :

On peut s'amuser à être légaliste lorsque l'infra est correctement
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.


Je souhaite juste que les infras cyclistes et leurs défauts soient
correctement représentées. Cela permet d'informer les cyclistes sur
les zones pas pratiques voir dangereuses et pouvoir remonter les
problèmes de continuité aux municipalités afin que ça bouge. Si l'on
masque tous ces problèmes à coup de bicycle=yes afin que le routeur
soit content ça fait pas avancer les choses.


+1

Le 28/05/2020 à 18:29, Éric Gillet - e+talkfr2...@linuxw.info a écrit :

Je garderais le bicycle=yes, voire en designated.

Rien ne désigne le vélo comme autorisé sur cette place piétonne, ce
serait encore moins adapté qu'un bicycle=yes.


-1 : si on dit qu'ils ne sont pas prioritaires c'est qu'_ils sont
autorisés_. A minima tolérés.

Alors oui le panneau n'est pas explicitement dans le code de la route
mais c'est bien un panneau de signalisation routière de danger.

> Ce panonceau n'a aucune existence légale.

https://www.mapillary.com/map/im/6lubeDufWJhvkUBhpeADyA

C'est le panneau de danger A14
.
complété par le panneau M9 précisant le danger :

CYCLISTES
ATTENTION :
PIÉTONS PRIORITAIRES

On termine aussi l'obligation de voie cyclable.

S'ils avaient voulu signaler l'interdiction de continuer ils auraient
mis un panneau d'interdiction "circulation interdite" B0
.

On peut aussi noter les bandes rugueuses au sol signalant qu'on entre
dasn une autre zone.

Si l'autorité avait voulu marquer la fin de l'aménagement "complet", ils
auraient demandé de mettre pied à terre, voir mis une micro bordure de
début de trottoir.

Il n'y a rien de tout ça.

> /Autre exemple de ce panonceau [1], là encore pas utile car aux
passages piétons les piétons sont dans tous les cas prioritaires./

Exact mais si tu supprimes les panneaux inutiles, tu vas pouvoir créer
ton entreprise de recyclage de panneaux^^.

> /S'ils avaient voulu faire une continuité légale, ils auraient eu
plein d'autres moyens explicites. Ils ne l'ont pas fait, c'est un choix
actif de leur part./

> /Exemple de ce à quoi ça ressemble juste à côté, lorsqu'ils font le
choix de faire un "trottoir/accotement/zone piéton" partagé
vélos/piétons [2]/

Et donc ils ont voulu une continuité à la légalité douteuse car plus
loin il y aurait un problème de place.

On est d'accord : plus on représentera les choses telles qu'elles sont
dans OSM, plus on arrivera à montrer les problèmes sans aller
nécessairement sur le terrain.

> /À 50m à l'est de cette photo les piétons sont obligés de marcher sur
la piste cyclable [3], un autre problème d'aménagement de cette zone.../

> [3] /https://www.mapillary.com/map/im/ntQTeDajclvXt2wq63DZvA/

De manière symétrique je mettrais :
highway=cycleway
foot=permissive

(segregated=no ? Ça me semble implicite)

C'est d'ailleurs un problème : on dit aux cyclistes (qui selon Florimond
ne peuvent être arrivés là sauf à pied) qu'ils doivent continuer là.
Mais on ne dit rien aux piétons (alors qu'on le dit ailleurs).

Peut être ajouter les photos en référence comme images mapillary dans
OSM histoire de voir le pourquoi des choix et monter aussi les problèmes
aux aménageurs.

Et si Éric et Simon ne sont pas d'accord sur la manière de le
représenter, je crois que vous êtes d'accord pour dire que ce n'est pas
un bon aménagement. Idéalement rencontrer les élus et venir avec des
propositions pour améliorer l'existant.

Le strict minimum c'est d'indiquer aux piétons qu'ils peuvent croiser
des cycles sur ce qui leur semble un trottoir et aux cyclistes qu'ils
peuvent croiser des piétons sur la piste cyclable.

Ou interdire les deux.

J'ai remarqué qu'ils ont mis une interdiction piétonnes B9a

au niveau de la voie du tram. L'ont-ils mises au début du panneau B22a

(je suppose) de piste cyclable ? Sans doute que non.

Le 29/05/2020 à 10:44, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Il me semble que footway+bicycle=yes indique bien qu’il y a un
problème d’aménagement (normalement ça ne devrait pas exister sur un
axe de transit vélo).


Non, il y a plein d'endroits où la densité de piétons et de cycles ainsi
que la largeur de la voie permet une cohabitation apaisée. Par exemple
d'anciennes voies ferrées transformées en voies vertes : ça peut être un
axe de transit

Re: [OSM-talk-fr] Désaccord sur un highway=footway

2020-05-28 Thread osm . sanspourriel

Très clairement il est écrit que les piétons sont prioritaires, c'est
donc un footway.

S'ils sont prioritaires c'est que d'autres usagers ceux à qui s'adresse
le panneau, ici les cyclistes, sont autorisés _en tant que tels_ et donc
sans mettre pied à terre : malgré les apparence ce n'est pas un trottoir !

On ne demande pas aux cyclistes de mettre pied à terre donc ils ont le
droit de rester, donc :

bicycle =yes

(ça correspond à ce qu'a tagué Simon).

ou plutôt permissive. "Where bicycles do not have a legal right-of-way,
but the land owner has indicated that bicycles are allowed".

Est-ce que sur ce qui semble être un trottoir il y a un panneau
avertissant les piétons de la circulation de cycles ? Rien vu depuis
Mapillary.

Par contre ce n'est pas sur cette liste mais avec la mairie ou la com
com qu'il faudrait voir afin d'avoir une continuité dans de bonnes
conditions.

En cas d'accident il serait possible de se retourner contre l'aménageur
car il semble que le piéton puisse de bonne foi se croire sur un
trottoir. Et le cycliste sur une voie qui lui est ouverte.

Mais à côté on voit aussi des piétons sur la voie cyclable
...

Jean-Yvon

Le 28/05/2020 à 17:27, Florimond Berthoux - florimond.berth...@gmail.com
a écrit :

Bonjour,

On peut s'amuser à être légaliste lorsque l'infra est correctement
réalisée, malheureusement pour le vélo ce n'est trop souvent pas le cas.
Alors il faut je crois être raisonnable et essayer d'interpréter
l'intention de l'aménageur et surtout l'utilisation réelle.

Ici, surtout avec le panneau "attention aux piétons" et les logos de
sorties/entrées[1][2] il me semble que la continuité cyclable est de
rouler sur cet espace piéton/vélo.
Je garderais le bicycle=yes, voire en designated.
Je rajouterais que pour l'aspect légal, le trottoir n'étant pas
définit dans la loi on ne peut l'utiliser pour trancher la question ici :)

[1]
https://www.mapillary.com/app/?focus=photo=KJsoemkc4oYR4Xi5rqk2sQ=45.7528340908=4.86933412633=17=0.4937764232782991=0.5309130874519274=0
[2]
https://www.mapillary.com/app/?focus=photo=DZOXQywaxkgG0gIFFE9vBg=45.7527595999=4.86847119931=19.104624643089036=0.4927012280272741=0.5322403100702529=0

Le jeu. 28 mai 2020 à 15:26, Simon Réau mailto:simon.r...@geovelo.fr>> a écrit :

Bonjour,

Avec gileri nous avons
un désaccord sur un highway=footway situé dans la continuité de
deux pistes cyclables. Notre discussion ce situe ici
https://www.openstreetmap.org/changeset/85822975#map=19/45.75301/4.86788

Le débat porte sur l'accès aux vélo sur cette partie entre les
deux pistes cyclables.

J'aimerais avoir l'avis de la communauté pour trancher la question.

La voie en question
https://www.openstreetmap.org/way/808726332
https://www.openstreetmap.org/way/808726333

Cordialement

Simon REAU
*
*

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours

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

--
Florimond Berthoux

___
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] Une résidence dans une zone résidentielle ?

2020-05-28 Thread osm . sanspourriel


Bonsoir,

Le 28/05/2020 à 20:37, Florian_G - forums+...@floriang.eu a écrit :

Bonsoir,

Le 28/05/2020 à 16:44, Jérôme Amagat a écrit :

Moi, j'utilise place=neighbourhood pour les lotissements et les
résidences mais sur des nodes.


Pas moi, enfin plus maintenant, car ça n'indique pas la limite. Du
coup, des applications (au hasard, Nominatim) peuvent l’utiliser à
mauvais escient.


Que nenni, si tu l'utilises /aussi/ avec une relation tu donnes une limite.

Si tu ne bornes pas on est d'accord ce n'est pas borné, même pas
semble-t-il par des polygones de Voronoï.

Si tu bornes, Nominatim ne semble pas dépasser de beaucoup !

Si tu ne bornes pas j'ai effectivement vu des hérésies par le passé. Là,
pour reprendre mon exemple précédent Nominatim est certes dans l'erreur
: Swimming Pool Piscine Fit Océa Guidel, Rue Général De Gaulle, Les
Jardins de Vitalis, Kerprat, Guidel, Lorient, Morbihan, Bretagne, France
métropolitaine, 56520, France 

Mais c'est le segment précédent de la rue qui correspond aux Jardins de
Vitalis. C'est donc un cas tangent ;-).

Jean-Yvon

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

Re: [OSM-talk-fr] Une résidence dans une zone résidentielle ?

2020-05-27 Thread osm . sanspourriel


En terme de taille et pour Nantes tu as raison : neighbourhood c'est
trop grand.

Si tu prends une commune périphérique style 10 000 hab comme dans mon
cas c'est plus jouable.

plot correspond à la parcelle, c'est inadapté et trop petit.

En terme de taille, c'est city_block qui s'en approche le plus.

Mais veut-on l'utiliser? ÀMHA, c'est toujours préférable à plot.

Et pas parce que c'est affiché (je ne sais si ça l'est et c'est une
question de style).

Pour plot, il existe des cas où ça a l'air de bien correspondre à des
parcelles comme ici .

Jean-Yvon

Le 27/05/2020 à 21:13, Eric Brosselin - Osm - o...@eric.brosselin.fr a
écrit :

/Le 27/05/2020 à 12:20, Vincent Bergeot a écrit :
/

/
2 - j'ai regardé du coté de place=neighbourhood mais cela me semble
plus "large" qu'une simple résidence comme montré au-dessus

Ma question / comment taguez vous une résidence (comme l'exemple
précédent) dans une zone résidentielle ?
/



Pour ce qui concerne l'usage de place=neighbourhood pour les
résidences j'ai un doute.

Si on reprend le wiki on a en taille décroissante : city > borough >
suburb > quarter > neighbourhood > [city_block (pas applicable
partout)] > plot

Un exemple concret sera plus parlant.
Exemple : Nantes
- 11 quartiers en "admin_level=10" avec des "admin_centre=suburb"
- 94 micro quartiers en "admin_level=11" avec des
"admin_centre=neighbourhood"

Placer ici des zones résidentielles au niveau "neighbourhood" n'est
pas vraiment viable je pense.
Ne serait-ce que pour des raisons de superficie.

Exemple avec le quartier "Hauts-Pavés - Saint-Félix"
https://www.openstreetmap.org/relation/4597439
Superficie : 4,28 km2  soit 428 ha
Superficies des 10 micro-quartiers qui le composent : de 91,8 ha à
14,6 ha en passant par des superficies de 30/40 ha en moyenne.

Test de superficie (donc mesure du terrain incluant les espaces autour
des bâtiments) sur 24 résidences prises sur tout Nantes :
- 1000 à 3000 m2 => 6 résidences
- 3000 à 4000 m2 => 9 résidences
- 4000 à 5000 m2 => 5 résidences
- + de 5000 m2   => 1 résidence
- > ou égale à 1 ha => 3 résidences

Si on compare, les superficies des résidences sont bien en dessous de
celles des micros-quartiers.
Donc cartographier avec "place=neighbourhood" ne me paraît pas
possible pour ce genre de résidences.

Pour des lotissements plus grands pourquoi pas, mais alors il faudrait
vraiment qu'ils se comptent en hectares.

place=plot conviendrait donc mieux je crois.
C'est déjà utilisé en France http://overpass-turbo.eu/s/Urp
Peut être pas parfaitement car beaucoup en conjonction avec...
landuse=residential :-(
Voir https://taginfo.openstreetmap.org/tags/place=plot#combinations

/
/
/Le 27/05/2020 à 15:58, Florian_G a écrit ://
/
//

//

/Le wiki parle aussi de //place=plot
//. Si j'ai
bien compris la page, ce serait utile pour les résidences de
plusieurs bâtiments n'occupant en tout qu'une seule parcelle
cadastrale ?/



Il est dit dans le wiki qu'il n' y a pas forcément de correspondance
entre ce que l'on observe sur le terrain et les parcelles.
On l'observe tout les jours dans le cadastre : une même propriété peut
être découpée en plusieurs parcelles.

Actuellement il semble, contrairement aux autres "place=*", qu'il n' y
ait pas de rendu pour "place= plot".
Ce serait pourtant utile d'avoir visuellement ces noms comme point de
repères sur la carte.

Éric

___
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] Une résidence dans une zone résidentielle ?

2020-05-27 Thread osm . sanspourriel


C'est implicite mais ça va mieux en le disant : il y a donc aussi un
grand landuse=residential englobant au moins les 2.

Question subsidiaire : est-ce que la résidence ne fait pas partie du
neighbourhood plus grand ? Si probablement.

Le 27/05/2020 à 14:13, Jean-Yvon Landrac a écrit :


Oui, pour moi place=city_block c'est plus le bloc urbain à la
New-yorkaise. Adapté à Brest par exemple ! ;-). Sauf que je n'ai pas
l'impression qu'en France on donne souvent des noms dans ce cas -
l'exception étant les résidences occupant tout un ensemble urbain
entre 4 rues.

Comme dit Marc, on doit avoir un seul landuse.

Si on regarde mon exemple favori : Le Prat

jouxte Les Jardins de Vitalis
.

Décris comme relation place=neighbourhood (parce que ce n'est pas un
city_block, oui c'est un peu petit). Le nœud label label est
nécessaire pour un affichage sur la carte (il n'y a pas
d'admin_centre). Il a aussi le droit à place
=neighbourhood
.

Mettre des landuse identiques contigus, outre le manque de logique
topologique a pour effet de bord d'afficher des limites sur la carte
qui ne correspondent à rien dans la réalité. Mais les "bornes" sont
utiles pour savoir où s'arrête la résidence.

Ici c'est l'architecture et non une clôture qui permet d'associer un
côté de la rue à un ensemble et l'autre à l'autre.

Ça me semble la modélisation la plus propre même si idéalement on
devrait pouvoir se passer de ce nœud (via un prétraitement par exemple).

Jean-Yvon

Le 27/05/2020 à 12:59, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 27.05.20 à 12:20, Vincent Bergeot a écrit :

2 - j'ai regardé du coté de place=neighbourhood mais cela me semble plus
"large" qu'une simple résidence comme montré au-dessus

l'imagerie sat montre plusieurs bâtiments, du coup c'est ainsi
que je l'aurais renseigné
il y a aussi place=city_block que je n'utilise pas personnellement
mais qui pourrait convenu, même si le wiki donne l'impression
qu'un faut un bloc continue de bâtiments 2 facades.

Cordialement,
Marc

___
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] Une résidence dans une zone résidentielle ?

2020-05-27 Thread osm . sanspourriel


Oui, pour moi place=city_block c'est plus le bloc urbain à la
New-yorkaise. Adapté à Brest par exemple ! ;-). Sauf que je n'ai pas
l'impression qu'en France on donne souvent des noms dans ce cas -
l'exception étant les résidences occupant tout un ensemble urbain entre
4 rues.

Comme dit Marc, on doit avoir un seul landuse.

Si on regarde mon exemple favori : Le Prat

jouxte Les Jardins de Vitalis
.

Décris comme relation place=neighbourhood (parce que ce n'est pas un
city_block, oui c'est un peu petit). Le nœud label label est nécessaire
pour un affichage sur la carte (il n'y a pas d'admin_centre). Il a aussi
le droit à place
=neighbourhood
.

Mettre des landuse identiques contigus, outre le manque de logique
topologique a pour effet de bord d'afficher des limites sur la carte qui
ne correspondent à rien dans la réalité. Mais les "bornes" sont utiles
pour savoir où s'arrête la résidence.

Ici c'est l'architecture et non une clôture qui permet d'associer un
côté de la rue à un ensemble et l'autre à l'autre.

Ça me semble la modélisation la plus propre même si idéalement on
devrait pouvoir se passer de ce nœud (via un prétraitement par exemple).

Jean-Yvon

Le 27/05/2020 à 12:59, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 27.05.20 à 12:20, Vincent Bergeot a écrit :

2 - j'ai regardé du coté de place=neighbourhood mais cela me semble plus
"large" qu'une simple résidence comme montré au-dessus

l'imagerie sat montre plusieurs bâtiments, du coup c'est ainsi
que je l'aurais renseigné
il y a aussi place=city_block que je n'utilise pas personnellement
mais qui pourrait convenu, même si le wiki donne l'impression
qu'un faut un bloc continue de bâtiments 2 facades.

Cordialement,
Marc

___
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] Normalisation des bis, ter…

2020-05-25 Thread osm . sanspourriel


Le 25/05/2020 à 14:01, Yves P. - yves.prat...@gmail.com a écrit :


Est-ce que ça fonctionne si on met un espace insécable ?
Ou ça complique la saisie/recherche dans nominatim… ?


Tu veux sans doute dire un*e*

espace.

J'ai fait une recherche :

1bis rue de la mairie, Nominatim trouve des 1BIS, pas de 1 bis. 1B au
cadastre

1 bis rue de la mairie, Nominatim trouve des 1 bis, 1 BIS, pas de 1BIS.
1B au cadastre

Alors si tu veux en plus le perdre avec des signes typographiques
spéciaux...

N. B. : oui les espaces sont naturellement insécables mais comme c'est
une règle pour les références,

Sur Wikipédia
, ils
semblent attacher (0bis).

Sur ma com com ils mettent d'un côté le numéro et de l'autre le
"suffixe" : bis en minuscule et en entier.

Et FR:Key:addr  donne
pour exemple 12b;12c. Oui en minuscules ! La version anglaise ne dit rien.

Jean-Yvon

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

Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Thread osm . sanspourriel


> Je favoriserait le fait de coller les indices, car on peut facilement
les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
reste de l'adresse comme ça peut être le cas avec un "34 A" le "A"
pouvant être un "à...".

Non, ce serait À, le cadastre respectant notoirement les accents^^.

J'ai habité un bâtiment A et j'écrivais 3A, 3 A ne me choque pas, par
contre pour bis et ter l'usage est plutôt de séparer.

/Sachant que pour simplifier sur le terrain il y avait un 3, un A et un
B. Le 3B/3 B était en face du 5A/ 5B et quand les gens viennent par
l'entrée secondaire ils voient B et B puis A et A ;-)./

J'aurais donc dit 1 bis mais 1A.

J'ai regardé la plaque d'un 19 bis et il est écrit 19b...

19B et 19 bis permettrait de clarifier un peu.

Et si je reprends le 3A dans un célèbre annuaire en ligne je vois 3 A, 3
(il ne devrait y en avoir qu'un avec-entrée directe dans un appart du 3
A il y en a plusieurs, des 3 A, un bât 1 3 Bis - il avait dû fumer, 3
porte bât B). Comme ce sont les gens qui entrent ce n'est pas évident.

Les références des routes comportent des espaces et donc par exemple D
342 bis.

Maintenant comme dit Christian l'essentiel est se mettre d'accord et si
notre moulinette cadastre dit de mettre une espace, mettons la.

Jean-Yvon

Le 25/05/2020 à 13:36, Romain MEHUT - romain.me...@mailo.com a écrit :

Pour mémoire :
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html

Romain

Le 25/05/2020 à 12:36, Marc M. a écrit :

Bonjour,

Le 25.05.20 à 10:28, Yves P. a écrit :

Quel format faut-il utiliser ?
1bis, 1 bis, 1B, 1BIS, 1 BIS…

http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater A→␣A
donc "1 bis"
mais effectivement cela devrait se trouver sur le wiki qlq part.

Cordialement,
Marc

___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

2020-05-25 Thread osm . sanspourriel


C'est moi.

J'utilise bouche dans le sens générique (poteau, borne...).

C'est gênant que tu ne vois pas qui a mis cette info.

> D'où l'utilité des photos pour voir d'autres objets ? Ça aurait du
sens avec pic4review ?
Oui, même Osmose pour ouvrir dans JOSM avec les valeurs préparées.

Ajouter un objet aussi petit sans savoir où on doit le mettre, c'est
gênant et donc j'ai masqué sur cet outil les points non rapprochables.

N. B. : voir si des gens ont déjà essayé de cartographier l'objet
pourrait être intéressant.

Au fait on clique "impossible à rapprocher" et ça atterri dans
"rapprochement compliqué".

L'outil permet maintenant de rapprocher PI CLUNY 30 et PI CLUNY 29... :-)

Le 25/05/2020 à 10:33, Nicolas Bétheuil - nbethe...@free.fr a écrit :

Sinon j'ai pleins de "Pas de bouche OSM dans les parages" kiki à fait ça ?
Je comprends pas.

Est-ce qu'en faite avec ce jeu de données on ajoute des
emergency=fire_hydrant mais en fait ça se colle à côté d'une bouche ?
Je comprends pas. Les fire_hydrant ne sont pas des bouches à incendies
justement ? Du coup faut juste les créer. Il faut chercher un poteau ?
D'où l'utilité des photos pour voir d'autres objets ? Ça aurait du
sens avec pic4review ?



Le sam. 23 mai 2020 à 21:19, Yves P. mailto:yves.prat...@gmail.com>> a écrit :

Bonsoir,


Oups effectivement quelque troue dans la raquette.

@Nicolas

Premiers essais :

http://od2osm.cleverapps.io/#/quests/2/points/PI%20CLUNY%2019
*Conflation impossible* pourquoi ?
Overpass ne trouve pas de PI dans un rayon de 60 m. Mais il n'y a
pas cette option dans la liste ;)

J'ai cliqué sur "Impossible à rapprocher" : je me retrouve dans la
quête.
Si je choisi "Rapprochement compliqué", je retrouve ce POI.

Le terme "compliqué" est mal choisi : dans ce cas le rapprochement
est impossible faute de trouver un poteau d'incendie dans OSM.

Un lien/bouton permettant de d'*ajouter cet objet dans JOSM* (ou
iD) serait le bienvenu :)
Si il n'y a rien dans OSM, j'aimerais l'ajouter ;)

*Fond de carte* : pouvoir basculer entre OSM et BDOrtho IGN serait
appréciable :)

*Libellés tronqués* :
Sur Safari et Firefox ils sont tronqués (bouton "impossible à
rapprocher", choix dans la liste déroulante)
Sur Chrome, tout est lisible :)


@Antonin et Nicolas
D'où sort *name=PI CLUNY 19* ?
Il y a une référence dans les données ouvertes : ID_SDIS.

Dans le script d'Antonin
,
je ne vois pas de "recopie" dans le tag name.
J'en déduis que Nicolas "invente" des données :D

@Nicolas est-ce possible d'afficher un extrait du fichier de
donnée de la quête ?
Et/ou des infos sur la source de données ?

*Points traités :*
Le lien sur un point traité affiche {"statusCode":404,"error":"Not
Found","message":"Not Found"}.
Un lien sur l'objet OSM serait appréciable à la place :)

En cours : modification /création
Qu'est-ce que ça doit faire ?
En cliquant sur un POI, ça relance à nouveau la requête overpass
de rapprochement.

@Nicolas
Ton outil me semble un bon complément aux outils existants (JOSM
et Osmose).
Merci, continue :)
__
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment cartographier une prise électrique

2020-05-24 Thread osm . sanspourriel


Et je ne sais ce qu'est une prise standard en France. Si tu me dit que
c'est une prise E, je vois ce que c'est. Ça aurait pu être une C
(l'installation n'est pas forcément récente).

https://fr.wikipedia.org/wiki/Prise_%C3%A9lectrique

socket:typee=1 ou pas c'est la différence entre une information
utilisable et une autre.

Et les prises extérieures (pas forcément enterrées, souvent aussi dans
des boîtiers) des marchés seront facilement des prises "de force".

Donc autant taguer proprement, ce n'est pas plus difficile.

Jean-Yvon

Le 24/05/2020 à 03:17, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonsoir,

Le 23.05.20 à 23:50, Florimond Berthoux a écrit :

comment tagguer ces prises de courant ?

amenity=power_supply dont la proposition a été abandonné par manque
de temps de son auteur mais qui pourrait probablement passer avec
quelques efforts (entre autre ne pas se prendre le tapis de la
coexistence de charging_station)
https://wiki.openstreetmap.org/wiki/Proposed_features/amenity=power_supply


parce que tagguer socket:typee=1 c'est peut-être overkill, non ?

Si le type de prise n'est pas renseigné, on peux supposer que
c'est la prise standard du lieu mais ce n'est qu'une supposition.
Dans un camping cela restera ambigu vu les 3 sortes très courantes.

Cordialement,
Marc

___
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] Import de points d'eau incendie en Saône-et-Loire

2020-05-23 Thread osm . sanspourriel


Pour ma part je consolide les données existantes dans OSM avec
http://od2osm.cleverapps.io/.

N. B. : Nicolas, ce serait bien de virer "name", les PEI (j'ai appris
une abréviation) n'ayant pas de nom.

Jean-Yvon

Le 23/05/2020 à 18:09, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

ja'i du raté l'info de ce que tu fais pour pouvoir intégrer
ces bornes comparé à un import ?

Le 23.05.20 à 17:06, Antonin Delpeuch (lists) a écrit :

La possibilité d'ajouter les éléments manquants facilement depuis
l'outil est un vrai plus - je ne vois pas
comment faire ça depuis Osmose

exemple :
https://osmose.openstreetmap.fr/fr/map/#source=412054=8360=4=17=50.556896=2.899575=3==

clic sur "fix-josm" te l'ajoute en un clic dans josm

il y en a 1 en attente d'intégration en France :)

Cordialement,
Marc

___
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] Import de points d'eau incendie en Saône-et-Loire

2020-05-22 Thread osm . sanspourriel


ref:sdis

ou ref:FR:sdis71 pour Marc.

A priori il n'y a pas de bornes chez le voisin, donc quel intérêt de
préciser le sdis ?

Sinon si ce sont les numéros affichés sur les bornes, ref suffit
(visiblement non).

> "operator": "VEOLIA",
"operator": "Veolia",

Marc comme tu vois l'opérateur n'est pas ici celui qui met une
référence. Et chez moi il y un un petit numéro (<999) de peint.

C'est ce que je mets en ref. https://www.openstreetmap.org/node/5355380863

"source": "SDIS 71"

préciser la date (mois/année) du jeu de données.

On peut se contenter de mettre l'info au niveau du changeset.

Jean-Yvon

Le 22/05/2020 à 19:11, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 22.05.20 à 14:36, Antonin Delpeuch (lists) a écrit :

Quel tag utiliser pour ça ?

tu as 2 écoles :
- celle qui d'une ref doit être unique pour éviter tout clash
et donc va proposer quelque chose comme (ironie inside)
ref:TERRE:EU:FR:71:sdis:borne=l'id
cette école a des adeptes surtout en france
- celle qui dit qu'une borne n'a qu'une ref et que l'opérateur
est déjà décrit dans la clef operator et donc qu'il suffit de
faire ref=l'id
c'est la version la plus courante dans le monde

dans les 2 cas, ce que tu appelles un id, est une ref dans osm

Cordialement,
Marc

___
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] covid19 vert, covid19 rouge, CRO : natural=beach et cie

2020-05-21 Thread osm . sanspourriel


Bonjour, j'ai peur que ce soit aussi trop le b... pour nous.

Exemple de Saint-Nic.

À ce jour concernant les plages (je ne parle pas des ports), la page

consacrée au sujet sur le seul département du Finistère ne compte pas
moins de 18 arrêtés pris en 3 jours.

Exemple :

P029_20200513-plages_0006_CC-PCP

Est, vous l'avez deviné, l'arrêté concernant la Communauté de Commune de
Pleyben-Châteaulin-Porzay.
Oui c'est de l'humour. Et la réponse c'est que la plage de Pentrez est
ouverte.
L'arrêté du maire

précise de 7 à 22 h et que la plage de Caméros est interdite.

Heureusement une page

de la com com affiche une carte avec les restrictions.

Mais pour savoir qu'on peut y poser sa serviette (et pas que le temps
d'aller se baigner) il faut consulter la FAQ.

Si vous partez de la cale de Caméros faire une activité nautique, vous
devez vivre sous le même toit... en opposition avec les arrêts du Préfet
Maritime qui préfère lui que les gens risquent de se contaminer que de
s'échouer par manque d'expérience.

Sites consultés pour avoir l'info ;
- Préfecture du Finistère
- Com Com Pleyben-Châteulin-Porzay
- Plonévez-Porzay (oui la commune d'à côté)
- Saint-Nic
- MenezHom Atlantique (l'entité touristique)

Ajoutons que la CC du Porzay se trouve dans le Finistère Sud et qu'il y
a aussi 3 arrêtés préfectoraux portant sur les arrêtés (mais pas pour
ces communes).

Et de peur d'une restriction pour la période touristique, les maires
préfèrent fermer les plages.
/Par exemple parce qu'un groupe été aperçu buvant sur la plage. Il
serait bon de rappeler aux maires que la punition collective est
interdite en France, ah, non c'est peut-être seulement dans les écoles./
/Si un groupe boit alors que c'est interdit, c'est ce groupe qui est à
réprimander. Pas la population à 100 km à la ronde./
/Va-t-on demain interdire les routes parce qu'une personne a fait un
accès de vitesse ?/

Donc je n'ai pas l'impression que soit vraiment gérable dans OSM : trop
mouvant, trop plein de subtilités.

Jean-Yvon

Le 15/05/2020 à 21:08, Jean-Yvon Landrac a écrit :


Bonjour,

on est bon pour ajouter sur les natural=
beach
 des
opening_hours:covid19 : c'est trop le b... pour que les gens y
retrouvent leurs petits. En effet certains noms de plages sont assez
génériques et les site indiquant les plages ouvertes ne donnent pas
les criques et il faut repérer l'arrêté préfectoral pour savoir.

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

Re: [OSM-talk-fr] Améliorer la description des bibliothèques et centres de documentation

2020-05-21 Thread osm . sanspourriel


Le 21/05/2020 à 14:04, Christian Rogel -
christian.ro...@club-internet.fr a écrit :


Je vois que Jean-Yves ne craint pas d’être brûlé en plage de Keragan (
(-;) ). Appeler les usagers, des « customers » !!


/Jean-Yvon je suppose, n'est-ce pas Christophe^^./

/Plage ouverte mais les feux sont interdits sur les plages (et ailleurs
si tu n'es pas agriculteur car seules les fumées d'agriculteurs ne sont
pas polluantes, c'est comme pour les pesticides)./

/De plus plage dynamique : interdiction de faire du surplace./

Ben si, les usagers sont des customers. Tu peux dire users pour te faire
plaisir mais OSM n'a pas de raison de calquer les silos existants. C'est
un peu comme les instits qui veulent que les maternelles soient des
écoles maternelles. Ce qui n'est pas faux en soi mais dans OSM, on s'en
fout ! Ce qui nous intéresse c'est de catégoriser proprement les
[écoles] maternelles dans OSM.


Et les bibliothèques gratuites (Nice, Saint-Quentin-en-Yvelines, BPI,
BNF) ?


BnF (avec un n minuscule !) : acces=no du fait du covid19. De plus
l'accès est payant sauf de 17 à 20 h
.

Ajoutons qu'il y a une bibliothèque de recherche à la BnF dont les
tarifs sont différents, avec notamment des conditions d'âge
.

Un lien vers le site de la BnF me semble plus à même d'indiquer l'info
que 400 tags dans OSM.

access=yes 
access:conditional:no @ minage<=18 me semble capillotracté (mais
correspondant à la réalité).


Mais, je ne vois pas comment cela discriminerait pour l’accès
différencié aux types  service (tous seraient « customers »).
Va expliquer que le prof est un customer et pas ses étudiants.


access:conditional:no @ students

par exemple, mais ça confirme ce que je pense : il y a autant de
règlements intérieurs que de bibliothèques, OSM n'a pas pour objet de
retranscrire tout en tags.

> En plus, il faudrait faire de l’indoor.
Par exemple pour la BnF où la restriction d'âge ne vaut que pour la
partie recherche.

Actuellement dans OSM en France on a :
- 3500 bibliothèques
- 392 bibliothèques avec un site web
- 27 bibliothèques avec une référence ISIL (dont none, non et Unknown).

Il me semble plus efficace d'ajouter les références ISIL et d'ajouter
dans tag2link (coucou Yves) la transformation des ISL français (les
FR-*) en RCR (le reste) pour avoir un lien https://www.idref.fr/ comme

https://www.idref.fr/050939688

https://www.openstreetmap.org/?mlat=43.5804=7.1224#map=16/43.5804/7.1224

Il me semble plus intéressant d'ajouter ces informations (ISL, website)
permettant d'en récupérer d'autres et ajouter seulement des informations
"grand public" en nouveaux tags si nécessaire.

Exemple ici : on a un positionnement à 100 m dans idref, parfait dans OSM.

Dans idref on a en plus :

Organisme de tutelle : Communauté d'Agglomération Sophia-Antipolis (CASA)
Numéro ILN : 230
Centre régional Sudoc-PS de rattachement : 67 : PROVENCE-ALPES-COTE
D'AZUR. Nice
Type d'établissement : Autre bibliothèque de lecture publique sur fonds
publics
Forme précédente du nom de l'établissement : Bibliothèque municipale

Tél. renseignements : 04.92.19.75.80
Fax : 04.92.19.75.81
Adresse électronique : anti...@mediatheque-casa.fr
Ouverture : Mardi : 13h-18h ; mercredi et samedi : 9h30-18h ; jeudi :
13h-18h ; vendredi : 13h-19h
Conditions d'accès : Tous publics

Collections et services
Codes DEWEY et intitulés RAMEAU :

- 027     Pluridisciplinaire

Oui tu vas me dire que toutes les bibliothèques n'ont pas un code ISIL.

Il y a 225 médiathèques dans idRef, 1500 bibliothèques.

Mais des sites web en 2020 ? Ne me dis pas que ça ne te permet de faire
de stats sur le type de livres car si on a à peine plus de 10 % des
bibliothèques qui ont le site web de renseigné, avant que les
contributeurs précisent le type de bouquins empruntables, ça va durer
"un certain temps".

Jean-Yvon

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

Re: [OSM-talk-fr] Améliorer la description des bibliothèques et centres de documentation

2020-05-21 Thread osm . sanspourriel


Non, quand tu mets access=no il suffit d'un panneau par exemple, par
besoin de portail, corde et autre barrage physique.

Tu mets permit, c'est plutôt customers.

Le 20/05/2020 à 23:39, Christian Rogel -
christian.ro...@club-internet.fr a écrit :

J’hésite toujours sur access qui me paraît désigner un accès physique
plutôt qu’un accès aux divers types de service.




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

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

2020-05-19 Thread osm . sanspourriel


Tu vas polluer, c'est sûr.

C'est pourquoi en France on préfère passer par Osmose pour que les gens
repositionnent.

Tu peux aussi exclure les points qui tombent sur du bâti et par exemple
utiliser le greffon todolist de JOSM pour les importer à un endroit plus
réaliste.

Tu peux aussi ajouter un fixme=repositionner, précision X m

si tu ne sais pas le faire mais que tu as une bonne estimation de X avec
le jeu de données (à intégrer par département/caserne si c'est le
critère pour expliquer la précision).

Mes 2 c€.

Jean-Yvon

Le 19/05/2020 à 21:16, Antonin Delpeuch lists -
li...@antonin.delpeuch.eu a écrit :

Ou
est-ce que je vais polluer la carte avec des points imprécis dont tout
le monde se fiche ? C'est pas clair pour moi…

Antonin



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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement

2020-05-18 Thread osm . sanspourriel


Le 15/05/2020 à 13:51, David Pédehourcq - da...@pedehourcq.fr a écrit :


@yves

Comme les couleurs doivent être normalisées en France

Malheureusement non, si on pousse même un peu le sujet les consignes de tri,
le nom des déchets et même les picto de représentation ne sont pas les mêmes
d'une ville à l'autre ... ça devrait s’harmoniser, c'est en cours et ça
avance bien, mais la couleur y en a pour 10 ans:)


Pire : de mémoire les couleurs de convergences en France ne sont pas
celle de l'Allemagne par exemple. Sans doute pour la poubelle
bleue/grise/noire (poubelle non recyclables, OMR).

Il faudrait un greffon par commune et compatible daltonien (10 % de la
population qui utilise aussi le système de collecte^^).


Moi aussi, mais à gérer dans le temps et dans les softs ça complique : KISS

-> amenity= recycling  + recycling:waste=yes seulement
C'est le plus simple effectivement mais du coup waste_disposal ne sert plus
?

Et on a une clé qui ne veut plus dire grand chose. On peut faire ça,
comme des titalflat qui ne désignent plus des zones d'estran plat, des
reef utilisés pour décrire des eaux peu profondes et à la fin les tags
ne veulent plus rien dire. C'est bon iD a gagné (oui, je suis sarcastique).

C'est simple à migrer. C'est compliqué pour faire arriver de nouveaux
contributeurs (ou des contributeurs nouveaux sur le sujet) : quand je
cherche un attribut pour qualifier un point de collecte d'ordures
ménagères, je ne pense pas spontanément à chercher une collecte autour
du recyclage. Ce serait presque recycling=none.

@Marc, do-ocratie : si c'est simple des non spécialistes renseigneront
aussi (est-ce qu'il y a un anneau au sommet? un champignon ? Avec une
illustration, c'est facile), sinon ce sera fait par les professionnels.

Ça ne me pose pas soucis.

Jean-Yvon

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

Re: [OSM-talk-fr] Street food/food truck

2020-05-17 Thread osm . sanspourriel


Le 17/05/2020 à 16:12, deuzeffe - opensm@deuzeffe.org a écrit :


Le 17/05/2020 à 14:57, osm.sanspourr...@spamgourmet.com a écrit :

Utilisé mondialement 109 fois.


Je crois que Vincent parlait davantage de street_vendor=yes (comme
décrit dans l'exemple qu'il a pointé) que de shop=street_vendor.

Moi aussi, je voulais juste dire que les deux coexistaient et qu'il
fallait se poser la question du plus idoine dans ton cas.



C'est à dire qu'il est en général là (style baraque à frites qui est
sur un parking pendant une saison) ou pas (camion à pizza 1-2 fois
par semaine pendant quelques heures) ?


Il est en "tout le temps" là, un soir ou une matinée ou les deux par
semaine, toujours le même jour. Ça pourrait être considéré comme un
restaurant temporaire régulier.


Contrairement à la "baraque à frites" qui en saison est là 24/7 mais pas
toujours ouverte.

Là c'est plus le marketplace à un commerce^^.


shop=street_vendor me semble moins bon (en tant qu'utilisateur je
vais chercher à me restaurer plutôt que chercher un commerce nomade
qui vend des produits alimentaires !).


Oui, je te suis. J'ai l'impression que shop=street_vendor, c'est
plutôt ou le forain régulier ou la baraque (à
pizza/chichi-fregi/sandwich/etc), mais pour le second cas, si j'ai
bien compris, il y a shop=kiosk ?


Je ne connaissais pas mais non ça c'est en dur. Je parlais d'un truc
style caravane : mobile mais de facto immobile à la belle saison.

Jean-Yvon



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

Re: [OSM-talk-fr] Street food/food truck

2020-05-17 Thread osm . sanspourriel


Utilisé mondialement 109 fois.

381 shop=street_vendor


Selon que vous considérez que c'est l'activité principale ou pas.

C'est à dire qu'il est en général là (style baraque à frites qui est sur
un parking pendant une saison) ou pas (camion à pizza 1-2 fois par
semaine pendant quelques heures) ?

shop=street_vendor me semble moins bon (en tant qu'utilisateur je vais
chercher à me restaurer plutôt que chercher un commerce nomade qui vend
des produits alimentaires !).

Ce n'est pas parce que Mateusz n'a pas lancé de vote, qu'il ne faut as
en lancer un.

Jean-Yvon

Le 17/05/2020 à 14:07, deuzeffe - opensm@deuzeffe.org a écrit :

Le 17/05/2020 à 10:10, Vincent Bergeot a écrit :


j'étais arrivé sur cela aussi :
https://wiki.openstreetmap.org/wiki/Proposed_features/street_vendor%3Dyes


Le draft "since 2018" m'a un peu effrayée.


avec comme exemple un food-truck
https://wiki.openstreetmap.org/wiki/Proposed_features/street_vendor%3Dyes#Tagging



Effrayée, donc, je n'étais pas allée si loin. Merci !


my2cents


You mean "20", I guess.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [M] rendu de la mer et modèle de tag pour les cotes. Était : Evolution des règles pour les plages et la ligne de côte (zones et traits)

2020-05-16 Thread osm . sanspourriel


Le 15/05/2020 à 19:23, Djo_man via Talk-fr - talk-fr@openstreetmap.org a
écrit :



Donc, je voudrais, ici lancer une petite hola pour les contributeurs
Imagico et Jeisenbe pour les soutenir.


Sans moi ! Grosso modo on a cassé le rendu (il suffit de comparer le
rendu FR du rendu par défaut) pour justifier une modélisation qui
permettra un rendu futur.

Ce n'est plus taguer pour le rendu c'est ignorer des tags existants et
ayant un sens (tidal=yes). S'ils veulent il peuvent appliquer le bleu
peu transparent sur les zone water (ou océaniques) à l'exclusion des
zones tidal=yes.

Tant qu'on a n'a pas de données sous-marines (on en a mais sous la
surface), quel intérêt ?

tidal=yes permet d'afficher après les autres couches un rendu de l'estran.

J'avais fait un comparatif des rendus.


On avait du sable, Christoph -imagico) nous dit que le sable c'est
essentiellement sur terre. Exact dans le Sahara, pas sûr que ce soit
l'endroit où OSM est le plus utile et le plus utilisé.

Il refuse de rendre natural=shoal. En soit le tag est mauvais (natural
indique normalement une surface hormis pour coastline).

Effectivement tidal=yes serait plus logique *mais* ce n'est pas son avis.

low_level_water=yes serait sans doute plus idoine qu'un natural=reef.
Mais la notion est utile.

L'argument que tidleflat est plus utilisé est pervers : Christoph et
Josef change unilatéralement le wiki, rendent ce qui les intéresse et
après disent que ce sont les bons tags car plus rendus.

Voir :

https://github.com/gravitystorm/openstreetmap-carto/issues/3840 (c'est
le même ticket, simplement j'ai répondu) Jean-Yvon

Note : le rendu vectoriel n'a pas la notion d'océan, c'est la valeur par
défaut.

Jean-Yvon

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

Re: [OSM-talk-fr] Point d'apport volontaire, point de collecte, point de regroupement


Le 15/05/2020 à 22:39, deuzeffe - opensm@deuzeffe.org a écrit :


Donc, si on essaie de résumer pour donner à Vincent une réponse
claire pour une première étape, ça donne ?

Et ton esprit de synthèse propose ? ;D

Son esprit de synthèse dispose^^.


Existe-t-il un tag qui décrit la réalité (genre amenity=waste_disposal
mais en plus gros) ?

Oui ? -> On l'utilise.
Non ? -> On en crée un (un gros, donc).

S'il faut raffiner (colonne, support, couleur, toussa), c'est dans un
2e temps. Non ?


J'en sens motivés pour proposer un changement de clé.

Je disais à Jérôme S. en message privé :

/Finalement collect n'est peut-être pas mal : on collecte le verre comme
on collecte l'amiante. Enfin pas exactement j'espère pour l'amiante !
/

/collecting_centre, collecting_station ?/

Car point d'apport volontaire, point de regroupent de "poubelles" ou
déchèterie, on collecte des matériaux, recyclables ou non.

Ce n'est ni un terme ésotérique (du jargon) ni un terme chargé sur la
partie aval (recyclage, enfouissement, incinération) mais un terme neutre.

Il semble possible de faire une proposition simple, à soumettre à
l'international. Portant donc juste sur cette clé majeure (avec mise à
jour des sous-clés si nécessaire).

De plus je vois que depuis David parle de 2 services qui ont comme point
commun de s'appeler collecte.

Bons soins David, mais tu vas avoir besoin d'années pour apprendre OSM
(on en apprend tous les jours). Notamment que pour changer une clé
largement utilisée c'est assez coton.

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte (limites des fleuves)


Bonjour,

le trait de côte en zone "normale" état trop simple, parlons maintenant
des limites fleuves/rivières.

TL;DR : prendre comme ailleurs la limite PMVE, la LTM étant un indice.
En distinguant les deux on évite les conflits d'édition à la con style
Rio Del Plata.

A priori pour paraphraser Jérôme : c'est simple, le DPM s'arrête à la
LTM, ça tombe bien c'est la LTM qui a été utilisée historiquement en
France... mais le DPM n'est pas le trait de côte.

Et pour paraphraser Yves, maintenant la traduction :

DPM = Domaine Public Maritime, à partir de là, le Préfet Maritime dit
aux Préfets Départementaux d'aller jouer ailleurs (*).

LTM = Limite Transversale de la Mer, ça sert aussi à déterminer si une
commune est une commune littorale ou pas, ce qui change pas mal de
règles d'urbanisme. C'est d'ailleurs ainsi que j'en ai pris
connaissance, trouvé un jeu de données
 et
que Thomas a trouvé la couche correspondante

au SHOM.

Sauf erreur Djo Man et nous deux sommes d'accord pour trouver la donnée
trop spécifique.

Ça permet de savoir pourquoi Landerneau est une commune littorale et pas
Quimperlé alors que les deux communes voient en aval le niveau varier en
fonction de la marée : Landerneau

est coupé en deux au niveau de L'Élorn
 Maritime dite rivière de
Landerneau alors que même à l'embouchure de la Laïta

(Ellé Maritime ou rivière de Quimperlé), les communes de Clohars-Carnoët
et de Guidel se touchent.

Donc on a des communes tracées en fonction des limites DPM/LTM, c'est
bon on n'y touche pas (sauf exception, merci Djo man !).

De plus les jeux de données sont incohérents. Selon le jeu de données de
data.gouv.fr, la limite pour la Laïta c'est l'embouchure mais selon
data.shom.fr c'est grosso modo Kerulo
...
entre Quimperlé et l'embouchure et la limite où l'on a naturellement
tendance à dire que c'est une rivière (.

Comme pour l'Odet

(rivière de Quimper), Thomas a fait remonter le trait de côte à une
marée de 95 ou 120 (comme les villes ont des quais à ces endroits, le
trait de côte est sensiblement le même).

Pour l'Odet il y a aussi incohérence sauf que là c'est le SHOM qui coupe
au niveau de l'embouchure
 et
data.gouv.fr remonte jusqu'au pont sud de Quimper.

Je dis data.gouv.fr mais le jeu de données est produit par... le SHOM.
Sachant que le trait semble issu... d'OpenStreetMap. En effet j'ai
regardé l'Aulne. L'Aulne Maritime ou rivière de Châteaulin commence au
niveau d'une écluse.
C'est le trait de côte.

data.gouv.fr donne comme LTM le Pont de Terenez : c'est la limite
communale telle qu'indiquée dans OpenStreetMap. Or d'après le cadastre
et data.shom.fr, la bonne limite est le Passage (un peu en aval, lieu
historique de passage).

Donc prendre la LTM est douteuse.

Il me semble au moins pour la Bretagne logique d'avoir une limite aux
marées de 95 éventuellement de 120, indépendamment de la LTM (mais
forcément en amont de la LTM si différente).

En effet cette partie est nommée XX maritime (Ellé Maritime=Laïta, Aulne
Maritime, Élorn Maritime).

Djo Man : pour la Vilaine le DPM vient bien jusqu'à Redon selon le
cadastre. Donc c'est sûrement historique (avant la construction du
barrage d'Arzal) mais la LTM actuelle

selon le SHOM est... l'embouchure de la Vilaine. En clair : le trait de
côte est bon, les limites des communes fausses mais je ne sais si c'est
de Redon à Arzal ou d'Arzal à l'embouchure.

Jean-Yvon

(*) Pour un terrien, il est moins dangereux de mettre conjoints et
enfants dans un même bateau. Pour un marin il vaut mieux avoir deux
personnes expérimentées même si elles ne sont pas de la même famille.

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

Re: [OSM-talk-fr] covid19 vert, covid19 rouge, CRO : natural=beach et cie


Bonjour,

on est bon pour ajouter sur les natural=
beach
 des
opening_hours:covid19 : c'est trop le b... pour que les gens y
retrouvent leurs petits. En effet certains noms de plages sont assez
génériques et les site indiquant les plages ouvertes ne donnent pas les
criques et il faut repérer l'arrêté préfectoral pour savoir.

Adrien, et sans doute des liens vers les règlements départementaux pour
que les gens puissent retrouver facilement les arrêtés préfectoraux.

De même pour leisure
=marina
 et
leisure
=slipway
. Et
natural =water
 + water=lake
.

hier j'ai dit une inexactitude ;-) : le terme de plage recouvre
l'ensemble des débris accumulés en bas de la côte, c'est à dire une
plage de sable mais aussi une grève (graviers ou galets) et même des
blocs de pierre. Brignogan

à marée haute, c'est toujours une plage pour la réglementation. Donc
c'est bien l'équivalent de beach. Par contre dans les arrêtés "plage"
signifie une plage de sable !

On a vu des maires demander et obtenir des ouvertures de grèves.

Les règles sont très différentes selon les départements. La préfère de
Bretagne avait demandé aux préfets bretons de se coordonner. Je ne sais
ce que ça aurait donné sans concertation.

Résultat : pour le Morbihan sur 64 communes littorales, 33 ouvrent
toutes leurs plages, les accès aux ports *sauf exceptions* sont
autorisés
.
Là au moins vous avez une commune, c'est facile.

Pour le Finistère, à l'opposé, les ouvertures ne concernent quecertaines
plages de certaines communes
.
Je n'ai pas vérifié pour les ports mais je suppose que certains sont
ouverts et d'autres pas. et actuellement l'info n'est pas en ligne sur
la page covid-19 dédiée
.
Là visiblement au moins deux communes ont jugé bon ne ne pas ouvrir les
plages proches d'un camping ou d'un bar. Allant jusqu’à inventer des
noms pour couper la plage en deux (une "plage des marais" n'existe sur
internet que depuis cet arrêté).

Et donc il est possible de faire des activités nautiques (au moins en
Manche/Atlantique : c'est le préfet maritime de Brest qui décide pour le
domaine public maritime) mais il est possible que les ports n'étant pas
ouverts vous puissiez pratiquer de jure mais pas de facto !

Sur la densité, évidemment Philippe a tort (je pense qu'il voulait dire
une rangée au moins) : ce n'est pas en agglutinant les personnes sur une
seule rangée qu'on améliore la situation, là où c'est possible c'est sur
plusieurs rangées. Mais pour le moment la serviette c'est juste le temps
de se changer pour piquer une tête (ou autres activités sportives), là
où c'est autorisé donc la question ne se posera pas avant le 1^er juin.

> je ne vois pas ce qui est choquant pour une personne agée de vouloir
s'asseoir au milieu de sa promenade.
Ce n'est pas choquant, ce n'est pas dangereux, c'est interdit. Et
suivant sur qui vous tombez vous pouvez avoir 88 ans, rentrer de la
plage à deux pas de chez vous et vous prendre une prune de 135 € parce
qu'un gendarme a décidé que pour rentrer vous n'auriez pas dû être entre
la route et la mer mais le long de la route et de l'autre côté (histoire
vécue par une connaissance). Route déserte précisons-le et ce n'est pas
un cas isolé (prune pour circulation sur une "continuité de sentier
littoral" (!) après avoir laissé le promeneur passer dans un sens). Il
est aussi des forces de l'ordre douées de bon sens.

La seule utilisation active autorisée est à ma connaissance les
activités nautiques (la plage n'étant ouverte qu'à la marche et à
l'accès aux activités nautiques).

>  Pour les ballades dans les grands parcs naturels ou dans la
campagne, il y a rarement beaucoup de monde, la distanciation est plus
facile à garantir même sans beaucoup de contrôle.

Tout dépend de la configuration et en n'ouvrant pas tout on augmente les
phénomènes de concentration.

Donc on est "bon" pour étiqueter les plages, les ports et les cales avec
des opening_hours:covid19

Re: [OSM-talk-fr] Nouvel outil : od2osm


Bonjour, en fait Nicolas avait bien compris :
PDI = Point d'intérêt, POI en anglais
PDA = Point d'adresse

mais j'ai du retard dans mes messages, notamment sur le trait de côte !
Et je n'avais pas pris le temps de lui dire qu'il avait bien compris. Je
voulais et veux toujours essayer plus son logiciel.

Oui mettre des tickets sur github ça permet de ne pas surcharger cette
liste-ci et ne ne mettre que les points de discussion ici.

Comme la gestion (en France et ailleurs) de la fusion ou pas des
PDI/PDA. Et je crois qu'en France on préfère ne pas mélanger.

Jean-Yvon

Le 15/05/2020 à 12:12, Nicolas Bétheuil - nbethe...@free.fr a écrit :

Bonjour,

On m'avait parlé de PDI / PDA, de distance du bati pour la conflation
mais j'ai pas tout compris (même les acronymes).

On parlait du point
https://www.openstreetmap.org/node/3688329411
que j'ai créé en dev (parce qu'inexistant dans la conflation que
j'avais faite, à cause de la distance et du changement d'environnement
et que c'est pas ça que je testais)
https://master.apis.dev.openstreetmap.org/node/4319598216

L'échange en résumé
> Jean-Yvon
> Il ne me semble pas pertinent de placer le restaurant/traiteur (déjà
> Osmose va râler : restaurant ou traiteur ?) sur un point adresse.

> Moi :
> il y a beaucoup de points dans Osm ou le restaurant est à l'adresse.

> Jean-Yvon :
> Oui, à cause d'iD notamment qui incite à le faire ainsi.
> Pas forcément vigoureusement contre : il y a du positif et du négatif.
>Par contre "pourrir" la base en renforçant le cas ne va pas aider.

> Moi
> Le rapprochement se fait par tag principal : shop ou amenity pour
l'instant.
> Il n'y aura pas de "pourrissement supplémentaire", si le point
existe déjà à l'adresse ( ou un autre shop, amenity ...), les autres
tags seront rajoutés.
> Si le point n'existe pas, il sera créé.

Enfin :
J'ai trié mon ticket "améliorations"
https://github.com/wadouk/od2osm/issues/1

Je vais traiter 4 points avant de basculer sur le vrai OSM
- interdire de créer si requête des points à proximité à échoué
(surcharge overpass (quand sera en vrai) ou credentials OSM (pour le
test) par exemple)
- avertir si champ principal (pour l'instant shop ou amenity) contient
un point virgule
- ajouter ou supprimer un tag manuellement
- rajouter en source du changeset l'url du jeu de données OpenData

Il y en a d'autres dans l'issue mais que je considère moins important.
Une fois ces 4 points traités, je basculerais sur le vrai OSM.

Salutations


Le jeu. 14 mai 2020 à 12:18, Nicolas Bétheuil mailto:nbethe...@free.fr>> a écrit :

J'ai complété le readme avec plusieurs détails. à discuter.
Fait une issue sur les prochaines modifs en vrac.

Le mer. 13 mai 2020 à 19:00, Nicolas Bétheuil mailto:nbethe...@free.fr>> a écrit :

Bonjour,

Comme je vous l'avais annoncé, j'ai réalisé un nouvel outil :
OpenData2OpenStreetMap aka od2osm.

Vous pouvez aller jouer avec à l'adresse
https://od2osm.cleverapps.io

Il faut être authentifié sur l'environnement de dev OSM
https://master.apis.dev.openstreetmap.org en attendant vos
commentaires acerbes et votre jugement implacable pour le
mettre sur le vrai "OSM".

Vous pouvez en quelques clics ajouter de la données à OSM à
partir d'un jeu de données de test : les commerces parisiens
qui livrent pendant le confinement (oui c'est un peu parigo
centré et peut être un peu dépassé, mais c'est pour jouer aussi).

Ces données sont comparées avec l'environnement de dev d'OSM
qui est plutôt vide et incohérent avec le fond de carte, vous
allez donc faire beaucoup de création.
Rien n’empêche de faire plusieurs fois une création par
l'outil, charge au contributeur de vérifier si un point existe
déjà, l'outil aide à retrouver les éventuels points dèjà existant.
J'en ai moi même déjà ajouté pour tester et que vous puissiez
voir comment se passe une comparaison (même si du coup les
tags vont être identique).

J'attends vos commentaires, avec une certaine impatience, ici
ou en issue sur le repo github
https://github.com/wadouk/od2osm/issues.

Je cherche déjà à valider l'usage contributeur (ajout
communautaire et collaboratif) avant d'ajouté d'autres jeu de
données.

D'avance merci pour votre aide et vos critiques aiguisées.


___
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] Point d'apport volontaire, point de collecte, point de regroupement

2020-05-14 Thread osm . sanspourriel


Je ne crois pas qu'il faut y voir un parti pris idéologique : recycling
suppose qu'il y a recyclage et mettre reycling et waste ensemble forme
un oxymore. Et oui il y a de l'écoblanchiment pour certains à parler de
recyclage là où il n'y en a pas.

Je ne connais pas l'équivalent de répurgation en anglais. DeepL dit
repurgation.

end of life ? Mais changer une clé très utilisée... avec en plus le
problème que EOL a plusieurs significations et pas spécialement
celle-là. Alors un avertissement sur le wiki pour signaler qu'il s'agit
de la fin de vie en général, que le produit collecté soit effectivement
recyclé ou pas ?

Si ça vous sert de savoir quel système de préhension, pourquoi ne pas
grip=hook, sucsion ... mais il faut se mettre d'accord sur la partie
qu'on modélise : est-ce l'outil pour appréhender ou le côté statique.

Décrire le côté statique c'est simple (la personne le voit, ici un
anneau) ou pas (savoir comment est récupéré ce que j'aurais appelé une
benne et que tu appelles un caisson, ce n'est pas évident).

Tu nous fais une traduction jargon / noms pour béotiens francophones
ou/et anglophones (Yves a bien commencé) et une proposition de schéma de
tags "à la François" ?

Pour certains cas (les défibrillateurs par exemple) on met marque et
modèle, ça c'est peut être facile à trouver et permet de compléter les
autres attributs techniques a priori.

Jean-Yvon

Le 14/05/2020 à 11:12, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
écrit :


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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte (zones et traits)

2020-05-13 Thread osm . sanspourriel


Bonjour,

résumé : on a un carroyage plus qu'un code barre, mais pour donner une
image il faut dessiner les lignes et pas les carreaux.

/on a verticalement des natures de sol /(vase, sable, gravier,  galets,
blocs, roche).

avec potentiellement des couvertures (landcover ?) pour les dunes
. Je connaissais les dunes blanches,
grises, il faut ajouter les dunes vertes, les noires et les brunes.

Typiquement on ne trouvera pas les dunes vertes dans OSM (trop mobiles :
c'est le bas de dune comportant juste quelques plantes pionnières et le
sable reste bien visible).

/Et horizontalement du plus haut au plus bas des traits plus ou moins de
côte/ (DPM, PMVE, 0 cartes terrestres, BMVE, 0 cartes marines, ligne de
base) :

- la limite théorique haute (pleine mer "maximale" de coefficient de
120) correspond en théorie à la limite du domaine public maritime (DPM
pour les intimes) et des communes. En théorie car des polders peuvent
avoir changé la donne et placé - ou pas - des zones asséchées en zones
terrestres,
- la limite de trait de côté OSM (pleine mer de vive-eau moyenne de
coefficient de 95) - PMVE,
- la mi-marée (correspond au 0 des cartes terrestres même s'il est
mesuré à partir de la mi-marée à Marseille) - MM,
- la limite de basse mer de vive-eau moyenne (de coefficient de 95) -
BMVE, c'est traditionnellement le 0 des cartes marines britanniques) !
- la limite théorique basse (basse mer "maximale" dite astronomique, de
coefficient de 120) correspond en zone rocheuse saillante à la ligne de
base - ligne servant à la délimitation des zones en mer, ligne qui se
tague boundary=administrative + boundary:type=baseline. C'est le 0 des
cartes électroniques marines et actuellement aussi le 0 des cartes du
SHOM et de ses équivalents britanniques et allemands.

Ouf ;-).

Les références sont toujours par pression atmosphérique normale et pour
les cours d'eau avec un débit d'eau douce moyen. Et les coefficients
calculés à partir du port de Brest. Oui une définition franco-française
mais homogène avec les définitions internationales.

95 ou 100 ? il n'y a guère de différence pratique, selon Wikipédia on
devrait prendre 95 comme indiqué sur le wiki :

   *C = 95*, définit une vive-eau moyenne
   *C = 100*, définit une vive-eau équinoxiale moyenne

Je serais pour ne pas découper plus que nécessaire en strates
horizontales pour ne garder que des iso-lignes ou des isobathes :
limites des communes, trait de côte, sans doute 0 des cartes terrestres
et en plus 0 des cartes marines. Mais le wiki parle de BMVE et non du 0
des cartes marines.

Pour les beach (plages ou grèves - la distinction est importante puisque
les plages sont interdites par défaut et les grèves pas sauf si elles
servent d'accès à la mer(*)), on les met du DPM à quoi ? BMVE serait
logique dans OSM, car on utilise PMVE. Et si quelqu'un veut mettre son
rond de serviette, heu sa serviette, au niveau 0 absolu, il risque de ne
le mettre qu'une fois tous les 20 ans sur un sable détrempé.

Djo man, c'est bien le BMVE et non le BMME.

Blague à part, *vus les profils des plages ça revient à positionner les
plages en mer* ! Donc les arrêter à la ligne de mi-marée ne serait pas
déconnant (c'est aussi la partie de la plage la plus utilisée). Je dis
plages mais je pense beach : les grèves sont incluses. Mais peut-être
qu'on peut laisser le moteur de rendu repositionner le nom dans les terres.

De plus (mais c'est une mauvaise raison) l'imagerie est souvent coupée
avant.

Pourquoi le 0 des cartes terrestres ? C'est intéressant pour avoir une
idée du profil de marée / de la plage. Pas prévu par OSM, sauf à faire
des way avec ele=0.

Trait absolu de basse mer : idem et de plus utile pour le calcul des
lignes de base. Et comme dit par Thomas on a ce qu'il faut pour le faire
en France.

Et comme ça, pour faire un rendu propre, on ajoute un dégradé
transparent bleuté entre ces lignes.

Et on évite ces hérésies de tidalflat et de tidal=yes : natural=sand,
mud, gravel d'un côté et des traits de côtes y compris de basses côtes
(désolé pour les végans^^).

Je dis hérésie c'est pourtant cette horreur qui est décrite dans le wiki
anglais  :

/Mean low water springs
//is the position of
the lowest tide. There is currently no agreed way of tagging this line
in OSM. One way of tagging it is to tag the area between mean low water
springs and OSM coastline as //natural
=wetland
//+//wetland
=tidalflat
//. /

Si on arrive à nous mettre d'accord, on pourra envisager une proposition
au niveau international.

Le 13/05/2020 à 14:36, Denis Bigorgne - denis.bigor...@gmail.com a écrit :

en clair que la position de la coastline change

[OSM-talk-fr] covid19 : horaires post confinement

2020-05-13 Thread osm . sanspourriel


Bonjour,

dans cette phase de déconfinement, les horaires parfois ne sont ni ceux
d'avant le confinement ni ceux du confinement.

Doit-on les mettre en opening_hours ou en opening_hours:covid19 ?

Je suppose que nous devons conserver l'usage des :covid19 tant qu'il y a
des restrictions liées au covid-19.

Jean-Yvon



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

[OSM-talk-fr] Fwd: Référencement, cartes uMap

2020-05-12 Thread osm . sanspourriel


Tu peux créer un ticket sur https://github.com/umap-project/umap et
proposer un PR.

Jean-Yvon

 Message transféré 
Sujet : [OSM-talk-fr] Référencement, cartes uMap
Date :  Mon, 11 May 2020 16:29:08 + (UTC)
De :Pierre Béland
Pour :  talk-fr 
Copie à :   Pierre Béland 



Il existe plusieurs cartes uMap portant sur la thématique Covid-19. 
Mais j'observe qu'elles sont mal référencées. En recherchant pour mots
clés [umap  Covid-19], j'observe effectivement peu ou pas de
référencement des cartes uMap.

Recherche umap Covid-19

Qwant.com et Bing : aucun résultat
Google : Quelques pages, et description peu pertinente

Ces problèmes pourraient facilement être corrigés à mon avis en ajoutant
des balises dans les pages uMap.

Il serait facile d'ajouter à la page HTML la balise  en y insérant la description contenue dans chacune
des cartes.  L'utilisation de moteurs de recherche fournirait une
description plus claire de la carte et retournerait plus de résultats
pertinents.

Pierre
___
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] On touche au vin, un bordelais réagit :)

2020-05-10 Thread osm . sanspourriel


Deux choses ou plutôt trois :
- modification mondiale et non par pays
- modification non discutée
- modification incorrecte (non pas un changement sur les shop= mais sur
les nœuds des shop=).

shop=wine ou shop=alcohol et alcohol=wine, le second est plus précis.
Comme dit le wiki /This /_/may/_/be a better alternative than using
//shop =wine//as a
different top level tag/.

Je suppose que ça désigne des caves à vin mais par chez moi les caves à
vin vendent aussi du whisky (sauf quand le préfet ne veut pas). Donc
typiquement ne pas modifier sans en discuter avant.

Non le vin n'est pas un produit essentiellement composé d'alcool mais
d'eau. Comme le gel hydroalcoolique mais les usages sont différents. Là
dessus Vincent devrait être d'accord.

Par contre n'en déplaise à Vincent c'est bien ce que l'on appelle un
alcool. Je sais que ça ne plait pas au lobby viticole mais cidre, bière,
vin, whisky, etc.. sont des alcools.

Vincent, pas de soucis, on peut faire du vin sans alcool comme on fait
de la bière sans alcool, on appelle ça alors du jus de raisin :-D.

Yves, tu signales au géomètre qu'on en cause ici :
http://gis.19327.n8.nabble.com/On-touche-au-vin-un-bordelais-reagit-td5965366.html
?

Même en cas de soucis, vaut mieux un revert de l'essentiel (les nœuds
des buildings) que rien du tout.

Oui on a de bons contributeurs sur Orange.

Mais là un revert avant de voir (du) rouge ? ;-)

Jean-Yvon

Le 10/05/2020 à 15:41, Yves P. - yves.prat...@gmail.com a écrit :


c'est un peu violent cela quand même (commentaire : FRANCE :
basculement tag shop=wine vers shop=alcohol + alcohol=wine")



C'est le changeset mondial qui est violent…
Ou le fait que le vin soit composé essentiellement d'alcool (un
produit neuro toxique et addictif ) ?


j'ai fais un revert avant que trop de choses ne bougent


La modification est récente, vendredi était un jeu férié : tu aurais
pu le laisser faire son revert tout seul ;)

Le "coupable" : https://fr.linkedin.com/in/stéphane-courbi-736a5250


__
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

[OSM-talk-fr] ouvert, fermé, confiné


À compter de lundi on pourra refaire une passe sur les lieux ouverts,
fermés.

Et sans doute recommencer les semaines suivantes le temps que les
services et boutiques s'adaptent.

Met-on ces horaires dans la clé normale ou attend-on le retour d'un
fonctionnement essentiellement normal (quand les restaurants et bars
seront ouverts par exemple)

Déjà Mayotte reste confiné.

Pour les lacs, les plages et le littoral, ça va être comme pour les
marchés ouverts : au bon vouloir du préfet du département (en principe
en fonction des plans soumis par les maires).

Et là ça se complique : on va voir des voiries autorisées (ou pas), des
accès à la plage en sens unique, etc.

Est-ce qu'on essaye de mettre l'info dans OSM ? Jusqu'ici l'info état
nationale donc inutile dans OSM.

oneway:covid19=yes sur les accès ?

Ou considère-t-on comme pour les écoles que les utilisateurs potentiels
sauront se débrouiller sans OSM ?

Je suppose que pour trouver l'info il faudra éplucher les sites des
mairies du littoral (et de l'intérieur pour les lacs) donc en théorie 35
000 sites environ.

Il y a 5 000 plages (beach) dans OSM en France mais seulement 1621 où on
sait s'il s'agit de vraies plages (sand) ou des grèves (gravel ou
pebblestone). Alors si vous passez dessus...

Jean-Yvon



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

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten


Je n'avais pas cru utile de répondre, mais :

amenity=social_facility
social_facility=day_care
social_facility:for=child

Me va.

Mettre les maternelles avec les élémentaires ou pas, je m'en fiche un
peu (je n'ai pas d'égo de professeur des écoles facultatives^^)
maintenant si ces professeurs nous font un caca nerveux pour une erreur
de traduction.

Simplement en France il y a beaucoup de primaires.

Et mélanger les amenity=school et les amenity=kindergarten en

amenity=school;kindergarten

amenity=school
amenity_1=kindergarten

amenity_1=school
amenity=kindergarten

ou

amenity=school
amenity=kindergarten

en déplaçant arbitrairement un point (les locaux ne sont pas
nécessairement distincts).

Bof, bof et bof. À la limite le dernier (souvent une partie de bâtiment
est plus pour l'un ou l'autre).

Donc on regarde ce que font les autres et sauf gros clash, on fait pareil.

Jean-Yvon


Le 08/05/2020 à 18:39, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

Le 08.05.20 à 18:18, Christian Rogel a écrit :

On ne peut pas esquiver la question du contenu éducatif

je trouve que c'est cela justement le fond de la question
autant je suis partisan de tag les écoles maternelle en fr comme elles
le sont hors fr dans des systèmes similaires (par ex en Suisse)
autant pour le moment, dans kindergarden, il y a à la fois la garderie
et l'école maternelle, ce qui n'est pas très cohérent.

une autre solution que je trouve plus homogène est de migrer
les garderies en amenity=social_facility social_facility:for=child
et social_facility=day_care si j'ai bonne mémoire.
pas grand monde n'a donné son avis sur cette possibilité.

Cordialement,
Marc

___
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] Evolution des règles pour les plages et la ligne de côte


Le 08/05/2020 à 16:58, Jean-Yvon Landrac a écrit :


Il est possible que le rendu de Christian n'aille pas chercher les
bonnes données.

Maintenant ça se passe ici :

https://osmdata.openstreetmap.de/data/land-polygons.html


C'est bon, mais il faut que quelqu'un côté tech lance le script :

https://github.com/cquest/osmfr-cartocss/blob/master/get-shapefiles.sh


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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte


Le 08/05/2020 à 15:12, Jérôme Amagat - jerome.ama...@gmail.com a écrit :


https://www.openstreetmap.org/relation/1675626
sans doute que le rendu osm-fr ne connait pas
il y a un an c'était en natural=water

Ce n'est pas ça le problème,  en même temps que ce changement, les
côtes de la gironde sont devenus natural=coastline (exemple :
https://www.openstreetmap.org/way/538325176 )
Et le rendu des natural=bay sur le rendu osm ajoute juste le nom pas
le bleu.


Comme je le disais en aparté, c'est possible que ce soit le problème
mais j'en doute (la Laïta serait à marée basse et on pourrait aller y
marcher à compter du 11 mai^^).

Au contraire puisque la ligne de côte reculait, la mer avancerait.

Ce que tu nous dis me fait penser qu'effectivement à la base il y avait
un ensemble de polygones land créés par une moulinette de Frederik,
moulinette qui a changé il y a un ou deux ans.

Il est possible que le rendu de Christian n'aille pas chercher les
bonnes données.

Maintenant ça se passe ici :

https://osmdata.openstreetmap.de/data/land-polygons.html

N. B. : l'estuaire de la Loire est un des rares à ne pas avoir de
costline dans la partie maritime.

Jean-Yvon


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

Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

2020-05-07 Thread osm . sanspourriel


Le 07/05/2020 à 11:40, Marc M. - marc_marc_...@hotmail.com a écrit :

Je lui propose de s'inspirer du travail des développeurs de JOSM
qui fonctionne bien (ils utilisent wikidata, mais aussi data items).
Réponse à la con !!:(

il t'a dit "si qlq le fait, je regarderais, mais je ne le code pas".
je trouve cela plutôt ouvert d'esprit pour quelqu'un qui a un
avis totalement opposé à ta demande.
oui c'est con il est bénévole et non ton employé.
Réponse à la con de ma part.

Cordialement,
Marc


Marc, pas une réponse à la con de ta part (ni de celle d'Yves) mais Yves
a l'expérience d'une PR qui est restée trainer 5 ans (!) parce que Tom
je dirais ne daignait regarder les PR existants. Elle a fini par passer
parce que nous deux avons fait pression (nous n'étions pas à l'origine
ni du ticket ni du PR).

Tom a prétendu que le PR était passé en dehors des radars. Ce n'est pas
à exclure, admettons.

Mais du coup quand il dit "fait le boulot et je regarderai ce que j'en
fais", ça passe mal.

Car ça fait bien "gardien du temple". Que ce soit à juste ou titre ou pas.

Jean-Yvon

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

[OSM-talk-fr] covid19 vert, covid19 rouge


Bonjour,

concernant l'OpenData, le Ministère des Solidarités et de la Santé a des
progrès à faire : les cartes sont publiées sous forme d'images

!

On parlait de 3 critères mais seuls deux sont publiés. Si le troisième
c'est l'humeur de ou vis-à-vis de de Castagner, les Bretons sont mal
barrés^^.

Peu importe devraient rester deux zones.

Selon le HuffingtonPost les parcs et jardins seront rouverts dans les
départements verts, mais pas dans les rouges.

Sur le site du gouvernement j'ai trouvé la "Stratégie nationale de
déconfinemen
t"
mais "seul le prononcé fait foi".

Heureusement Etalab fait du bon boulot et via
https://www.data.gouv.fr/fr/reuses/carte-du-deconfinement/ on trouve
https://www.cartedudeconfinement.fr/ qui fait le récapitulatif (à lire,
très clair).

Et le statut n'importe que pour l'ouverture ou la fermeture des parcs.

Donc c'est un un peu comme pour les écoles : peu utile de connaître la
couleur du département pour CRO.

Par contre on aura le droit de faire le tour des commerces pour voir si
les horaires ont changé.

Extrait sur les différences entre avant et après déconfinement qui vont
concerner CRO :

 * /seront //accessibles//: médiathèques / bibliothèques / petits
   musées, forêts et cimétières/
 * ///seront //réouverts//: les commerces (hors bars / restaurants)
   et centres commerciaux < 40.000 m² (//masque recommandé//et sous
   réservé du respect de règles sanitaires et organisationnelles), les
   marchés en plein air, les coiffeurs / instituts de beauté /
   etc. (sous réserve du respect des guides sanitaires)/

Si j'ai bien compris Macron et/ou le gouvernement décide que les grands
musées pourront ré-ouvrir aussi.

N. B.  : si quelqu'un peut m'expliquer pourquoi les forêts seront
ouvertes, les parcs et jardins dans les zones vertes et les plages nulle
part. Il y a un virologue dans la salle ?

Jean-Yvon

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte


Djo man fait référence à une modification de Key:tidal
.

Du coup https://wiki.openstreetmap.org/wiki/FR:Key:tidal n'est plus à jour.

Et avoir un bon rendu sera plus difficile.

> /Le rendu de la mer à changé recemment. Maintenant le jaune des
plages est recouvert par le bleu de la mer. /

Encore une horrible décision venue de nulle part je crains (gouvernance
des forts en gueule ?).


/Donc maintenant on peut sans dommage changer le modèle de tag pour
dessiner une vraie plage unique estran compris et espèrer bientôt une
prise en compte des tidal./

/
/

Comme le fait le rendu HOT ou mieux le rendu OSM France
./
/

Résultat : la plage de la falaise à Guidel

disparait côté mer mais reste côté Laïta. D'ailleurs en regardant les
données ce n'est pas la ligne de côte (coastline) qui fait la différence
mais le fait que ce soit dans une commune ou pas. En effet la Laïta fait
partie du trait de côte depuis 10 mois.

Avec l'affichage actuel, la plage est réduite à la zone de marnage entre
la pleine mer de 95 et celle de 120, c'est à dire à une peau de chagrin.
D'un point de vue logique ça devrait être aussi entre la basse mer de 95
et la pleine mer de 95 (tidal=yes).

/D'ailleurs, vu que la costline doit etre accrochée sur la moyenne des
hautes mer elle est de fait amenée à evoluer avec le temps mais à mon
avis sans qu'aucun point de la coastline ne soit partagé avec le contour
de la plage ce qui permet de bouger cette ligne sans toucher à la limite
entre le sable et les rochers. /

Je ne comprends pas : le sable va et vient, facilement 50 cm de
différence entre l'été et l'hiver, la plage se déplace donc bien plus
que le trait de côte. Regardez les différentes vues aériennes de ce coin
par exemple.

Avec aussi des galets qui "disparaissent" ou "apparaissent" (sur
d'autres plages).

Et les deux évoluent en même temps.

Le trait de côte n'est pas la limite sable/rochers, il y a des zones
sableuses où le haut de la plage est une dune.

Que tu déplaces le trait de côte et que les deux côtés de la plage
(tidal=yes ou pas) suivent ou que tu utilises une plage de part et
d'autre de ce trait ne change rien : tu devras déplacer le trait de côte
s'il recule (ou plus rarement avance - dunes en arrière d'un estuaire
par exemple) et déplacer la plage si elle se déplace.

N. B; : plage est incorrect : beach recouvre aussi les grèves.

Jean-Yvon

Le 06/05/2020 à 22:03, Djo_man via Talk-fr - talk-fr@openstreetmap.org a
écrit :
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag "covid19" - Info sur le port obligatoire du masque


Sachant que c'est moins protecteur, est-ce que ce sera accepté comme
masque ? C'est plus vu en complément.

Et faut-il du coup une valeur style face_shield pour ça ?

Je ne pense pas : la définition de ce qu'est un masque va dépendre du
pays, de la région mais mask suffit au niveau d'OSM.

Bientôt ils vont autoriser le port des casques de moto dans les
supermarchés ;-).

Jean-Yvon

Le 06/05/2020 à 19:23, Philippe Verdy - ver...@gmail.com a écrit :

On commence à voir non pas des masques (jetables ou lavables en
tissus) mais des visières transparentes (3 euros dans les bureaux de
tabac : solution plus économique pour beaucoup, et plus pratique à
nettoyer et réutiliser... à moins qu'une directive décide qu'ils ne
sont pas conformes et qu'on doit utiliser des masques filtrants à
plusieurs couches. Car déjà sont proscrits l'usage des écharpes,
foulards ou bonnets ou des casques de motos... et des
chadors islamiques dans la sphère publique).
Pourtant je vois déjà des policiers/gendarmes faire les contrôles en
portant des casques à visière (pas équipés de filtres).


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

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten


La traduction importe aussi et la traduction n'est pas jardin
d'enfants... mais maternelle (voir ci-dessous).

OSM a une portée mondiale et si ça chagrine des professeurs d'école
maternelle, ça ne me fera ni chaud ni froid si c'est le bon terme au
niveau international.

Remarquez que ceux qui gèrent les marmots de ces kindergarten sont
appelés en anglais des _teachers_ c'est à dire des professeurs.

Jean-Yvon

Le 06/05/2020 à 15:36, Christian Rogel -
christian.ro...@club-internet.fr a écrit :


kindergarten (la traduction compte peu, nous sommes dans une convention de 
nommage).


https://www.linguee.fr/francais-anglais/search?source=auto=kindergarten

kindergarten
 nom  
(pluriel: kindergartens
)

maternelle
 f   
(pluriel: maternelles
 f)

Children learn the alphabet in kindergarten. Les enfants apprennent
l'alphabet à la maternelle.

plus rare :

école maternelle

f

garderie
 f

Exemples :

pre-kindergarten

n—

prématernelle

f

*kindergarten teacher

n **—*

*enseignant de maternelle

m***

**

kindergarten class

n—

classe de maternelle

f


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

Re: [OSM-talk-fr] Tag "covid19" - Info sur le port obligatoire du masque