Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Christian Quest]

Le 09/11/2020 à 21:11, Vincent Bergeot a écrit :


Le 9 novembre 2020 20:53:41 GMT+01:00, "Yves P."  a 
écrit :


mais surtout qu'il faut maintenant indiquer le Click and collect.

delivery:covid19=yes va bien ?

Oups, je voulais dire takeaway:covid19=yes | only

Il me semble que le click and collect se rapproche plus du concept de drive, on 
commande et paye en ligne puis on passer chercher les achats.

Takeaway c'est plutôt que l'on ne consomme pas sur place mais que l'on emporte 
(son kebab) ?

My2masks



Le drive c'est du takeaway en bagnole par opposition à takeway plutôt 
piéton... donc le click-and-collect au pas de la porte, je vois ça 
plutôt en takeaway (et c'est ce que j'ai fait sur ma commune avec les 
listes publiées en PDF par la mairie).


delivery = livraison chez toi, tu n'a pas à te déplacer

takeaway = tu te déplace (plutôt à pieds)

drive = tu y va en bagnole (ou autre, c'est pas interdit aux vélos)


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Romain MEHUT]

Le 09/11/2020 à 21:35, Yves P. a écrit :

Takeaway c'est plutôt que l'on ne consomme pas sur place mais que l'on emporte 
(son kebab) ?
C'est ça, tu ne consommes pas dans le magasin, tu emportes ;)


Je suis d'accord aussi avec l'emploi de "takeaway" pour désigner click 
and collect.


Romain




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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Yves P.]

> Il me semble que le click and collect se rapproche plus du concept de drive, 
> on commande et paye en ligne puis on passer chercher les achats.

Pour moi un drive c'est la possibilité de faire ses courses, d'aller au cinéma, 
de "tirer" de l'argent ou de poster une lettre… sans descendre de sa voiture.


> Takeaway c'est plutôt que l'on ne consomme pas sur place mais que l'on 
> emporte (son kebab) ?

C'est ça, tu ne consommes pas dans le magasin, tu emportes ;)


> My2masks

Mes 2 pistaches :D

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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Yves P.]

> C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?
> Ou bien c'est une suggestion "à faire standardiser d'abord" ?

Comme tu le sens :)

Il n'y a pas de règle, et si il y en a une, il a les exceptions :D

Un compromis, c'est d'avoir une discussion ici. Si il n'y a pas de levée de 
boucliers, tu peux le faire, le documenter sur la page FR.
Ça deviendra un standard de facto.

Même si tu lances une discussion sur tagging, un vote et que ta clé est 
approuvée, si aucune application ne l'affiche, ça ne sert pas à grand chose.

> Existe-t-il un terme générique anglais pour [les chronoposts]

Il y a peut être des sites spécialisés qui décrivent les services postaux dans 
différents pays. Wikipedia ?

> Comme je disais, ça fait pas du "1 sur 2" au changement d'année, alors que 
> c'est vraiment ça que je vois dans certains bureaux de poste…

opening_hours=2020 week 01-53/2 Sa 09:00; 2021 week 01-53/2 Sa 09:00

Tu peux regarder si l'année suivante il faut commencer par semaine paire ou 
impaire.

Une autre piste est d'écrire à l'auteur de la grammaire pour voir comment gérer 
ce cas.


> D'autres font du Sa[-1], j'ai pas fini de tomber sur des cas tordus :-)
ce n'est pas tordu (pour un développeur).
[-n] signifie le nième élément d'un tableau en partant de la fin
[n] le nième élément d'un tableau en partant du début


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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Frédéric Rodrigo]

Si le générateur des horaires d'ouvertures est codé en python ça serait 
bien aussi de l'ajouter à Osmose

https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_poste_FR.py
http://osmose.openstreetmap.fr/fr/map/#zoom=9&lat=45.215&lon=0.104&item=7050%2C8020%2C8021%2C8022&level=1%2C2%2C3&tags=&fixable=


Le 09/11/2020 à 21:11, David Faure via Talk-fr a écrit :

On lundi 9 novembre 2020 19:42:59 CET Yves P. wrote:

Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
ne vont pas dans opening_hours, donc je les considère hors périmètre.
C'est déjà assez compliqué comme ça :-)

On pourrait suffixer collection_times ;)

On trouve cet exemple dans le wiki :
collection_times = Mo-Fr 09:00-12:00,17:00; Sa 14:00
collection_times:local = Mo-Fr 23:00; Su 23:00

Ça donnerait donc quelque chose comme :
collection_times:parcel = Su-Fr 23:00

OK, noté dans la TODO list :)
C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?
Ou bien c'est une suggestion "à faire standardiser d'abord" ?


collection_times:chronopost = Su-Fr 18:00
Parcel est générique et doit se retrouver dans tous les pays.
chronopost est une marque. Existe-t-il un terme générique anglais pour ce
type de paquets ?

Ça ne me rappelle rien.

Dans les autres pays les paquets sont livrés, contrairement aux chronoposts,
bien souvent :-) :-)


Detect cases like "every other Saturday", which seems to happen.

Je ne comprend pas cette expression. DeepL me dit "un samedi sur deux".

Oui.


C'est bien ça ? Ça ne serait pas plutôt premier et 3e samedi du mois ?
Ou samedi des semaines paires (ou impaires) ?

Non.


Le langage d'opening_hours permet cela :
Su[1,3] # 1er et 3e samedi du mois
week 01-53/2# semaines impaires
week 02-53/2# semaines paires

Comme je disais, ça fait pas du "1 sur 2" au changement d'année, alors que
c'est vraiment ça que je vois dans certains bureaux de poste...

D'autres font du Sa[-1], j'ai pas fini de tomber sur des cas tordus :-)


Il faut peut-être l'ajuster d'une année sur l'autre ?

Oui je vais devoir faire ça du coup...




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 19:42:59 CET Yves P. wrote:
> > Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
> > Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> > ne vont pas dans opening_hours, donc je les considère hors périmètre.
> > C'est déjà assez compliqué comme ça :-)
> 
> On pourrait suffixer collection_times ;)
> 
> On trouve cet exemple dans le wiki :
> collection_times = Mo-Fr 09:00-12:00,17:00; Sa 14:00
> collection_times:local = Mo-Fr 23:00; Su 23:00
>
> Ça donnerait donc quelque chose comme :
> collection_times:parcel = Su-Fr 23:00

OK, noté dans la TODO list :)
C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?
Ou bien c'est une suggestion "à faire standardiser d'abord" ?

> collection_times:chronopost = Su-Fr 18:00
> Parcel est générique et doit se retrouver dans tous les pays.
> chronopost est une marque. Existe-t-il un terme générique anglais pour ce
> type de paquets ?

Ça ne me rappelle rien.

Dans les autres pays les paquets sont livrés, contrairement aux chronoposts, 
bien souvent :-) :-)

> >>> Detect cases like "every other Saturday", which seems to happen.
> 
> Je ne comprend pas cette expression. DeepL me dit "un samedi sur deux".

Oui.

> C'est bien ça ? Ça ne serait pas plutôt premier et 3e samedi du mois ?
> Ou samedi des semaines paires (ou impaires) ?

Non.

> Le langage d'opening_hours permet cela :
> Su[1,3]   # 1er et 3e samedi du mois
> week 01-53/2  # semaines impaires
> week 02-53/2  # semaines paires

Comme je disais, ça fait pas du "1 sur 2" au changement d'année, alors que 
c'est vraiment ça que je vois dans certains bureaux de poste...

D'autres font du Sa[-1], j'ai pas fini de tomber sur des cas tordus :-)

> Il faut peut-être l'ajuster d'une année sur l'autre ?

Oui je vais devoir faire ça du coup...

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Vincent Bergeot]

Le 9 novembre 2020 20:53:41 GMT+01:00, "Yves P."  a 
écrit :

>>> mais surtout qu'il faut maintenant indiquer le Click and collect.
>> delivery:covid19=yes va bien ?
>
>Oups, je voulais dire takeaway:covid19=yes | only

Il me semble que le click and collect se rapproche plus du concept de drive, on 
commande et paye en ligne puis on passer chercher les achats.

Takeaway c'est plutôt que l'on ne consomme pas sur place mais que l'on emporte 
(son kebab) ?

My2masks


-- 
Vincent Bergeot

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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Yves P.]

> Oui. Jamais utilisé, j'ai vu des commerçants en donner quand une
> personne avait oublié son masque et allait le chercher par contre jamais
> vu de "don de masque" officiel (sauf en mairie pour les habitants).

J'en ai vu mais… payants. Aaaah, le commerce :D


>> mais surtout qu'il faut maintenant indiquer le Click and collect.
> delivery:covid19=yes va bien ?

Oups, je voulais dire takeaway:covid19=yes | only

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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[osm . sanspourriel]

Le 09/11/2020 à 20:08, Florian LAINEZ - winner...@free.fr a écrit :


- safety:mask:covid19
=yes/given/sold
pas certain que l'on ai encore besoin de ça. On déprécie ?


Oui. Jamais utilisé, j'ai vu des commerçants en donner quand une
personne avait oublié son masque et allait le chercher par contre jamais
vu de "don de masque" officiel (sauf en mairie pour les habitants).

Je crois que ça n'a été fait par certains hypermarchés au début pour
qu'on parle d'eux.


Un truc du type clickandcollect:covid19=yesqui soit extensible en
clickandcollect:covid19=http://URLduMagasin.fr ?
Mais pour l'URL, on cherche peut-être quelque chose de plus générique
qui s'applique également à takeaway:covid19
=yes

? Peut-être website:booking:covid19=http://URLduMagasin.fr
(en se basant sur le tag déjà existant
website:booking:=*).


Pourquoi ne pas s'en tenir à takeaway ? L'emport sur réservation est
bien de l'emport. clickandcollect c'est du takeaway à réservation
obligatoire. Actuellement on va avoir des takeaway=only et
reservation=only. Ça correspond aussi aux drives des GMS. Je n'ai pas
d'avis tranché.

On a toujours deux manières de voir est-ce un website spécialisé dans la
réservation ou une précision de la réservation en donnant son website dédié.

Donc OK, pourquoi pas website:booking:covid19. Par contre je pense que
ces sites sont destiner à durer donc website:booking me semble souvent
suffisant. Côté interface CRO une boîte à cocher pour savoir si le site
de réservation devrait rester après le confinement ? Par défaut non
coché (utilisation de website:booking:covid19).

Et pour la livraison tu mets website:delivery:covid19= ?


- Je pense qu'il est temps d'utiliser un tag pour indiquer la dernière
fois qu'un lieu a été checké sur le terrain, et pour cela je propose
l'usage du tag survey:date
=* (à moins
que l'on ne lui préfère check_date
=* ?) qui
pourrait être rajouté automatiquement par CRO à chaque mise-à-jour
manuelle d'un POI. Il pourrait être pris en compte par la suite pour
faire des propositions ultérieures de mise-à-jour. Je pense que la
date indiquée dans ce tag peut être différente de la date du changeset
et qu'il est donc pertinent d'utiliser un tag ad-hoc.


Bof, on a effectivement déjà check_date. Et on ne va pas tout vérifier.
Donc on va avoir des infos "fausses" : oui quelqu'un est passé mais
qu'a-t-il vérifié ? La partie covid ? Tout ? Juste les horaires ? En
plus on ne peut a priori pas "s'amuser" à se faire une rangée de commerces.

Et sur les "covid19" qui traînent, la date du changeset est nettement
dans le passé.


J'oublie sûrement 1000 choses, je suis sûr que vous aurez plein
d'idées, merci par avance pour vos retours.


Sûrement mais c'est déjà pas mal.

Jean-Yvon

Jean-Yvon



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

Re: [OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Yves P.]

> - safety:mask:covid19 
> =yes/given/sold 
> pas certain que l'on ai encore besoin de ça. On déprécie ?

Poubelle ! je ne comprends même pas comment c'est arrivé dans CRO ;)

> - delivery:covid19 
> =yes 
> 
>  fonctionne toujours pour indiquer la possibilité de livraison.
> Par contre j'ai l'impression que cela s'applique à plus de catégories de POIs 
> (pas uniquement sur les restaurant mais aussi pour les librairies 
> ,
>  et potentiellement je pense aussi aux bibliothèques)

A tous les commerçants qui le souhaitent (Tiens, ça ne fonctionne pas pour les 
coiffeurs, les ongleries… :D )


> mais surtout qu'il faut maintenant indiquer le Click and collect.

delivery:covid19=yes va bien ?


> Il faudrait d'ailleurs avoir la possibilité d'indiquer un URL pour faire la 
> commande. Les URLs pour acheter à distance peuvent être importants : il y a 
> un mouvement important de mise en ligne de l'offre des commerçants locaux 
> 
>  en ce moment …

website=* ;)


> Un truc du type clickandcollect:covid19=yes qui soit extensible en 
> clickandcollect:covid19=http://URLduMagasin.fr  ?

KISS : les 2 précédents à ça ira bien :)


> Mais pour l'URL, on cherche peut-être quelque chose de plus générique qui 
> s'applique également à takeaway:covid19 
> =yes 
> 
>  ? Peut-être website:booking:covid19=http://URLduMagasin.fr 
>  (en se basant sur le tag déjà existant 
> website:booking:=* ).

KISS stp ;)

Une boutique via mettre sont site web à jour.
Soit il deviendra la boutique en ligne, soit sa page d'accueil affichera le 
lien du click&collect.

De plus CRO gère les valeurs multiples pour les sites web.


> - Je pense qu'il est temps d'utiliser un tag pour indiquer la dernière fois 
> qu'un lieu a été checké sur le terrain, et pour cela je propose l'usage du 
> tag survey:date =* (à 
> moins que l'on ne lui préfère check_date 
> =* ?) qui pourrait 
> être rajouté automatiquement par CRO à chaque mise-à-jour manuelle d'un POI. 
> Il pourrait être pris en compte par la suite pour faire des propositions 
> ultérieures de mise-à-jour. Je pense que la date indiquée dans ce tag peut 
> être différente de la date du changeset et qu'il est donc pertinent 
> d'utiliser un tag ad-hoc.

Plutôt survey:date (752  829 selon taginfo) vs check_date (115  349).

Mais c'est pour moi un métadonnée, donc je préfère la date du groupe de 
modifications.

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

[OSM-talk-fr] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Florian LAINEZ]

Hello,
"Ça reste ouvert" va bientôt ré-ouvrir, mais il évident qu'il faut faire
évoluer le service qui était adapté au premier confinement mais pas à la
situation actuelle.
Discutons-en et discutons d'éventuels nouveaux tags à utiliser / anciens
tags à abandonner (cf. la page wiki
).

- access:covid19 =no

;yes et capacity:covid19
=* et
description:covid19
=* et
drive_through:covid19
=yes/only/no
et note:covid19 =* et
fonctionnent toujours bien
- safety:mask:covid19
=yes/given/sold
pas certain que l'on ai encore besoin de ça. On déprécie ?
- opening_hours:covid19
=*
fonctionne toujours pour indiquer l'ouverture d'un lieu et/ou ses horaires
d'ouverture
- delivery:covid19
=yes

fonctionne toujours pour indiquer la possibilité de livraison.
Par contre j'ai l'impression que cela s'applique à plus de catégories de
POIs (pas uniquement sur les restaurant mais aussi pour les librairies
,
et potentiellement je pense aussi aux bibliothèques) mais surtout qu'il
faut maintenant indiquer le Click and collect. Il faudrait d'ailleurs avoir
la possibilité d'indiquer un URL pour faire la commande. Les URLs pour
acheter à distance peuvent être importants : il y a un mouvement important
de mise en ligne de l'offre des commerçants locaux

en ce moment ...
Un truc du type clickandcollect:covid19=yes qui soit extensible en
clickandcollect:covid19=http://URLduMagasin.fr ?
Mais pour l'URL, on cherche peut-être quelque chose de plus générique qui
s'applique également à takeaway:covid19
=yes

? Peut-être website:booking:covid19=http://URLduMagasin.fr (en se basant
sur le tag déjà existant website:booking:=*
).
- Je pense qu'il est temps d'utiliser un tag pour indiquer la dernière fois
qu'un lieu a été checké sur le terrain, et pour cela je propose l'usage du
tag survey:date =*
(à moins que l'on ne lui préfère check_date
=* ?) qui pourrait
être rajouté automatiquement par CRO à chaque mise-à-jour manuelle d'un
POI. Il pourrait être pris en compte par la suite pour faire des
propositions ultérieures de mise-à-jour. Je pense que la date indiquée dans
ce tag peut être différente de la date du changeset et qu'il est donc
pertinent d'utiliser un tag ad-hoc.

J'oublie sûrement 1000 choses, je suis sûr que vous aurez plein d'idées,
merci par avance pour vos retours.

-- 

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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Yves P.]

> Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier, 
> Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> ne vont pas dans opening_hours, donc je les considère hors périmètre.
> C'est déjà assez compliqué comme ça :-)

On pourrait suffixer collection_times ;)

On trouve cet exemple dans le wiki :
collection_times = Mo-Fr 09:00-12:00,17:00; Sa 14:00
collection_times:local = Mo-Fr 23:00; Su 23:00
Ça donnerait donc quelque chose comme :
collection_times:parcel = Su-Fr 23:00
collection_times:chronopost = Su-Fr 18:00

Parcel est générique et doit se retrouver dans tous les pays.
chronopost est une marque. Existe-t-il un terme générique anglais pour ce type 
de paquets ?


>>> Detect cases like "every other Saturday", which seems to happen.
>> 
>> Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?

Je ne comprend pas cette expression. DeepL me dit "un samedi sur deux". C'est 
bien ça ?
Ça ne serait pas plutôt premier et 3e samedi du mois ?
Ou samedi des semaines paires (ou impaires) ?

Le langage d'opening_hours permet cela :
Su[1,3] # 1er et 3e samedi du mois (cf. doc 
)
week 01-53/2# semaines impaires
week 02-53/2# semaines paires

> 
> J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au changement 
> d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux 
> semaines impaires se suivent.
Il faut peut-être l'ajuster d'une année sur l'autre ?

Suite dans un prochain mél :D

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

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

[Axel Listes]

Bonjour,

Le 16/10/2020 à 17:30, Florimond Berthoux a écrit :
> En fait le tag serait plus simplement un traffic_sign
> https://wiki.openstreetmap.org/wiki/Key:traffic_sign
> traffic_sign=bicycle_give_way_right|left|forward|all
> 
> Ainsi ceux qui veulent faire le recensement des panneaux peuvent utiliser
> ce  traffic_sign,
> et ceux qui souhaitent interpréter les panneaux pour les routeurs peuvent
> ajouter des relations.

Merci pour cette « conclusion », mais je lui retire ce caractère car ne
répond pas à la demande initiale !
La demande consistait à substituer la création de relations pour des cas
simples.

Représenter le panneau juste à tire informatif, sans que cette
information ne soit exploitable par les outils de routage n'apporte pas
de facilitation à son implémentation, ainsi qu'à son entretient.

De plus, dans une logique d'effet inverse de la volonté absolue du
maintien d'une relation, des algorithmes peuvent théoriquement déduire
l’existence d'un tel panneau et sa position.

La proposition précédente
> highway:bicycle=give_way_right|left|forward|all

Me parait plus adaptée pour répondre à cette demande.

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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

[OSM-talk-fr] Rendu des healthcare

[Yves P.]

Bonsoir,

> Le 5 févr. 2020 à 14:57, Georges Dutreix via Talk-fr 
>  a écrit dans Re: [OSM-talk-fr] cabinets 
> infirmiers - healthcare=nurse :
> j'ai vu qu'un ticket était en suspens sur le rendu des healthcare=*
> 
> https://github.com/cquest/osmfr-cartocss/issues/43 
> Dans la lignée de ce 
> message, je propose de reprendre le chantier des POI healthcare non rendus 
> actuellement.

J'ai ouvert le ticket #1037 
 dans le projet de 
tuiles vectorielles openmaptiles.
Il concerne la première étape qui consiste à inclure ces POI dans les tuiles.

La seconde sera des les afficher dans les différents styles vectoriels.

Vous commentaires et votre aide sont les bienvenus :)

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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Jérôme Amagat]

Le dim. 8 nov. 2020 à 23:23, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour et merci pour toutes ces réponses !
>
> On dimanche 8 novembre 2020 16:43:36 CET osm.sanspourr...@spamgourmet.com
> wrote:
> >  > (ignore everything after 11:45, that's the max time for sending
> > > letters, parcels, etc.)
> > Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
> > colis même s'il part le lendemain, rencontrer un conseiller.
>
> Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
> Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> ne vont pas dans opening_hours, donc je les considère hors périmètre.
> C'est déjà assez compliqué comme ça :-)
>
> > Ne pas confondre avec collection_times
> > https://wiki.openstreetmap.org/wiki/FR:Key:collection_times
>
> Oui, c'est pas ça non plus, je suis d'accord.
>
> >  > Detect cases like "every other Saturday", which seems to happen.
> >
> > Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?
>
> J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au
> changement
> d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux
> semaines impaires se suivent.
> Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
> est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26,
> 2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.
>
> Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
> 1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...
>
> >  > Decide whether to add specific single-date exceptions to the OSM
> > > opening hours or to just ignore them. Do we want this level of detail?
> >
> > Il y a deux types d'exceptions : les jours fériés et les jours vraiment
> > exceptionnels.
>
> Les jours fériés je gère déjà [tant que le bureau fait la même chose tous
> les
> jours fériés...].
>
> > Rien contre indiquer les jours vraiment exceptionnels mais il faut alors
> > être sûr que la mise à jour soit régulière. Avoir mettons une journée
> > dans le passé pourrait faire conclure à des horaires non actuels.
>
> Oui si j'arrive à tout automatiser, l'import pourrait se faire
> régulièrement.
> Les données sont pour les 3 prochains mois, mais je ne sais pas si ça
> garantiopening t
> ces horaires. C'est peu probable (grêves, arrêts maladie, ...). Du coup
> d'une
> semaine sur l'autre, les horaires prévisionnels pour "dans 2 semaines"
> pourraient changer. Donc en toute théorie il faudrait importer tous les
> jours,
> LOL. Mais bon déjà si c'est une fois par mois ça me semble pas mal.
>
> > Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> > info bulle sur les bureaux avec les horaires actuels, les horaires
> > déduits et les horaires bruts dont tu pars. Par exemple en important tes
> > données dans une umap.
>
> Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal à
> voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier
> de
> départ et le fichier de sortie permet de regarder ça. Si c'est pour
> l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)
>
> >  > and new post offices
> >
> > Et surtout ceux qui disparaissent (c'est plus fréquent).
>
> Hmm, je veux mettre à jour les horaires, pas supprimer des bureaux de
> poste,
> ça semble dangereux et hors périmètre :-)
> Je pense que la création et la suppression seraient plutôt à faire à
> partir
> d'une autre source de données, la liste des bureaux de poste
> https://datanova.laposte.fr/explore/dataset/laposte_poincont2/
> Mais ça je laisse volontiers à quelqu'un d'autre...
>
> > Horaires : oui on a le droit d'ajouter/modifier des horaires, on met en
> > général un source=La Poste, 2020-11-08 (histoire de savoir d'où ça vient
> > et de quand ça date).
>
> Dans le changeset, j'imagine. OK.
> Pas de mention de l'outil d'importation, au cas où quelqu'un veuille
> remonter
> à comment un mauvais import a eu lieu ?
>
> > Mais dans un premier temps détecter les différences c'est déjà un bon
> > point pour savoir ce qu'il y a à vérifier.
>
> Je ne suis pas sûr de ce que tu veux dire par là.
> Si l'outil détecte une différence entre OSM et datanova, j'imagine que
> datanova est plus fiable, mais c'est pas en comparant 08:00 et 09:00 qu'on
> saura qui a raison. Il faut aller voir les horaires sur la porte, mais la
> France c'est grand et on est confinés :-)
>
> Mais oui pour commencer c'est plus sûr de ne rien écraser.
>
> > Pages éventuellement à compléter par la suite :
> > https://wiki.openstreetmap.org/wiki/Import/Catalogue
>
> Ah oui, j'ai vu cette page, mais je ne comprends pas bien la différence
> entre
> ses sections. Les imports ne sont-ils pas tous "communautaires" ?
>
> > https://wiki.openstreetmap.org/wiki/Contributors#France
>
> Merci pour l'info, c'est noté aussi.
>
> > Pour les imports, on va sans doute te conseiller de faire tes tests avec
> > JOSM
>
> OK.
>
> > mais pour la mise à jour réguli

Re: [OSM-talk-fr] Réouverture imminente de "Ça reste ouvert"

[Pierre-Olivier Grégoire]

Bonjour,

Personnellement je trouve normal que le projet puisse se développer dans ce
cadre.

Je cartographie pas mal les magasins sur Lyon donc si vous avez besoin
d'actions de terrain spécifiques n'hésitez pas à me contacter. Je peux
aussi aider pour de la validation sur le soft. Je ferai aussi passer le mot
sur les différents groupes facebook de quartier une fois le site rouvert.

Par contre le confinement est assez limitant. Je serai limité au km pendant
1h autour de chez moi pour les visites sur place.

Pierre-Olivier

Le lun. 9 nov. 2020 à 10:09, Brice  a écrit :

> Bonjour,
>
> Le 07/11/2020 à 18:08, Florian LAINEZ a écrit :
> > Le passage d'un projet bénévole à une prestation rémunérée est toujours
> > délicat au sein de la communauté OSM...
> > Les besoins de ce second confinement vont être, sans aucun doutes, très
> > différents du premier.
>
> Je pense effectivement qu'il y a une place pour une offre de services
> payante, construite à base de données OSM.
> Pour info un article en relation :
>
> https://www.banquedesterritoires.fr/commerce-de-proximite-une-numerisation-marche-forcee
>
> ___
> 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 indiquer une séparation centrale sur une rue ?

[Eric SIBERT via Talk-fr]

(ce qui est différent de la bordure dont il était sujet initialement :
https://www.mapillary.com/app/?pKey=s7OAvWZ8TzqcexpCIhKARw&focus=photo 
)


Pour un truc comme ça, je sépare en deux ways distincts sans hésiter 
(plus interdiction de demi-tour à chaque bout éventuellement).


Eric

PS : on se comprend mieux avec des images ;-)

Eric

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

Re: [OSM-talk-fr] Bonne attribution FlickR [était Facebook : défaut d'attribution]

[Yves P.]

>  "la taille de la carte est souvent une excuse pour ne pas attribuer OSM, 
> même si elle provient de membres "corporate" d'OSMF. Curieusement, Flickr 
> fait tout comme il se doit. Obtenez plus de clients comme ceux-ci @Mapbox  et 
> faites en la valeur par défaut 
> https://www.flickr.com/photos/136548402@N04/30863596060";

Bravo.

De plus je constate que cette mini carte à un système de zoom simple et clair 
en survolant simplement la "cartinette" :)

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

[OSM-talk-fr] Bonne attribution FlickR [était Facebook : défaut d'attribution]

[Vincent Bergeot]

Dans la continuité de cette discussion, un exemple qui vient d'un oiseau 
bleu :

https://twitter.com/iamnunocaldeira/status/1322854295713288197

Traduction deepL : "la taille de la carte est souvent une excuse pour ne 
pas attribuer OSM, même si elle provient de membres "corporate" d'OSMF. 
Curieusement, Flickr fait tout comme il se doit. Obtenez plus de clients 
comme ceux-ci @Mapbox  et faites en la valeur par défaut 
https://www.flickr.com/photos/136548402@N04/30863596060";




Le 24/09/2020 à 09:29, Denis Chenu a écrit :

Bonjour,

Je sais que il ya une procédure à suivre, et qui fonctionne sans doute
pour les plus petites entreprises ou même sur certaines plus grosse.
Mais avant de prendre contact avec facebook, j'aimerais vérifier
plusieurs chose.

Le système sur Facebook, exemple sur la page
https://www.facebook.com/Jardins-du-H%C3%AAtre-le-42-ex-Ferme-aux-Loisirs-101234147890218
Ce lieu à une adresse, sur le coté droit :
1. un mini plan est visible (aucune attribution)
2. je clic sur le mini plan : aucun attribution visible
3. Je vois un petit point d'exclamation
4. je clic sur le point d'exclamation :
4.1 : lien "Mention légale du mappage de donnée" clic : ouvre la page
https://www.facebook.com/maps/attribution_terms/
4.2 lien (c) OpenStreetMap donne sur
https://www.openstreetmap.org/copyright/

Alors mes questions :
1. sur la page de copyright (https://www.openstreetmap.org/copyright/) :
il est indiqué "Le crédit devrait apparaître" et non doit (en français):
est-ce que cela veut dire que Facebook satisfait aux obligations légales
? Ou non : les crédits doivent apparaître sur la carte.
2. Peut on bien considérer que 3 clic pour avoir l'information de
copyright des contributeurs ne satisfait pas le "Vous devez également
préciser clairement"
3. Est ce que je dois contacter mapbox, facebook ou les deux ?

Pour information : il y aurait déjà eu un contact avec Facebook :
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
(User:Nunocaldeira ) mais non daté.

D'autres ont ilk déjà commencé des remontées à facebook ?

Merci,
Denis



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



--
Vincent Bergeot


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

[OSM-talk-fr] Réouverture imminente de "Ça reste ouvert"

[Brice]

Bonjour,

Le 07/11/2020 à 18:08, Florian LAINEZ a écrit :
Le passage d'un projet bénévole à une prestation rémunérée est toujours 
délicat au sein de la communauté OSM...
Les besoins de ce second confinement vont être, sans aucun doutes, très 
différents du premier.


Je pense effectivement qu'il y a une place pour une offre de services 
payante, construite à base de données OSM.

Pour info un article en relation :
https://www.banquedesterritoires.fr/commerce-de-proximite-une-numerisation-marche-forcee

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