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

[Pierre-Olivier GREGOIRE]

Selon moi réservation et commande sont deux choses bien distinctes (en
anglais comme en français) :
* on réserve une chambre ou une table : elle ne sera pas affectée à une
autre personne (d'après le larousse : "Action de retenir une place (dans un
train, un avion, au théâtre, etc.), une table (au restaurant), une chambre
(dans un hôtel)."
* on commande avec paiement un bien (d'après larousse "Action de commander
une marchandise, un travail, une œuvre, un repas ; la chose commandée ")

Je trouve personnellement qu'avoir un tag pour ce service (la commande et
retrait en magasin) assez simple.
.

Le lun. 16 nov. 2020 à 23:10,  a écrit :

> Le 16/11/2020 à 22:52, Pierre-Olivier GREGOIRE - po.grego...@gmail.com a
> écrit :
>
> > cette chaine de brasseries très connue sur Lyon propose bien
> > distinctement "vente à emporter" (possibilité d'emporter sa
> > consommation) de "click & collect" (possibilité de commander à
> > distance et de récupérer sa commande une fois qu'elle est prête). Et
> > ce n'est pas un cas isolé.
>
> Oui takeaway=only (à emporter)
>
> et
>
> takeaway=only
>
> reservation=only (à commander puis à retirer)
>
> sont deux choses distinctes.
>
> La page reservation n'est pas réservée ;-) à la réservation d'un créneau
> horaire.
>
> Si tu peux aller au resto et que tu dois réserver tu auras
>
> reservation=only
>
>  > Par contre on peut préciser si il peut être acheté sur place ou si un
> service de "commande puis retrait en magasin" est proposé ou un service
> de livraison.
>
> Là encore : reversation=only, required... ou pas.
>
> takeaway n'est effectivement pas indispensable ici.
>
> KISS
>
> Si on veut faire la combinatoire réservation y compris le mode
> (téléphone, internet, courrier), le mode de retrait (en magasin, à
> l'extérieur) ou de livraison et mettre un tag spécifique à chaque fois
> ça va être compliqué...
>
>
>
> ___
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[osm . sanspourriel]

Le 16/11/2020 à 22:52, Pierre-Olivier GREGOIRE - po.grego...@gmail.com a
écrit :


cette chaine de brasseries très connue sur Lyon propose bien
distinctement "vente à emporter" (possibilité d'emporter sa
consommation) de "click & collect" (possibilité de commander à
distance et de récupérer sa commande une fois qu'elle est prête). Et
ce n'est pas un cas isolé.


Oui takeaway=only (à emporter)

et

takeaway=only

reservation=only (à commander puis à retirer)

sont deux choses distinctes.

La page reservation n'est pas réservée ;-) à la réservation d'un créneau
horaire.

Si tu peux aller au resto et que tu dois réserver tu auras

reservation=only

> Par contre on peut préciser si il peut être acheté sur place ou si un
service de "commande puis retrait en magasin" est proposé ou un service
de livraison.

Là encore : reversation=only, required... ou pas.

takeaway n'est effectivement pas indispensable ici.

KISS

Si on veut faire la combinatoire réservation y compris le mode
(téléphone, internet, courrier), le mode de retrait (en magasin, à
l'extérieur) ou de livraison et mettre un tag spécifique à chaque fois
ça va être compliqué...



___
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"

[Pierre-Olivier GREGOIRE]

Bonjour

Le lun. 16 nov. 2020 à 21:10,  a écrit :

> On a déjà les moyens de payement, pas la peine d'en inventer (sauf à
> suffixer par covid19).
>
> https://wiki.openstreetmap.org/wiki/FR:Key:payment#Argent_liquide
>
> Ça donnerait :
>
> payment:cash:covid19=no
>
> Par contre un commerçant en dessous d'une certaine somme doit accepter
> le liquide (car contre il peut imposer un payement à la réservation ce
> qui revient à peu près au même).
>
> Et par rapport au message de Vincent : KISS, en français c'est réserver
> et emporter donc :
>
> reservation=only
>

reservation ( https://wiki.openstreetmap.org/wiki/FR:Key:reservation )
indique une réservation d'un créneau plutôt qu'un bien. Ainsi pour un
restaurant, il s'agit de réserver une table avant de venir dîner, pas de
réserver de la nourriture avant de partir avec.
Je me permets une digression au passage : On commence à entendre parler
dans les médias d'une piste pour les magasins de ville : réserver des
créneaux horaires avant de venir. J'utiliserais plutôt
reservation:covid19=required pour un cas de ce type.


le service de "commande à distance puis retrait en magasin" me semble
suffisamment spécifique pour qu'on lui assigne un tag spécifique.

Pour un restaurant, Je le distingue de la possibilité de "plat à emporter"
(qui est plutôt commandé sur place). Exemple :
https://www.ninkasi.fr/infos-covid-19-ninkasi/ : cette chaine de brasseries
très connue sur Lyon propose bien distinctement "vente à emporter"
(possibilité d'emporter sa consommation) de "click & collect" (possibilité
de commander à distance et de récupérer sa commande une fois qu'elle est
prête). Et ce n'est pas un cas isolé.
Au passage ce n'est pas une raison mais pour info la "concurrence" fait
aussi cette distinction.

Pour un magasin de biens, le fait qu'on puisse "emporter" (takeaway) le
bien qu'on vient d'acheter (un livre, une table...) n'a pas besoin d'être
précisé puisque c'est tout le but du magasin. Par contre on peut préciser
si il peut être acheté sur place ou si un service de "commande puis retrait
en magasin" est proposé ou un service de livraison.



>
> takeaway=only
>
> (avec les suffixes covid19 si c'est du temporaire).
>
>
> Le 16/11/2020 à 20:27, Philippe Verdy - ver...@gmail.com a écrit :
> > le paiement sur place en espèces impossible.
> >
>
>
> ___
> 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] Suppression de l'attribut source

[osm . sanspourriel]

Le 16/11/2020 à 12:18, Marc_marc - marc_m...@mailo.com a écrit :


3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
d'un tag source sur le changeset. iD le permet aussi.
tous les éditeurs proposent facilement d'ajouter des sources
ainsi que l'imagerie sat utilisée pour l'alignement.
en tout état de cause, la présence de meta-donnée (les tags de
changeset) sont renseigné par le contributeur de cette modif là
et concernerait cette modif, donc fiable (quand elle existe)
pour connaître la source de ces modifs.


Ceci est partiellement vrai : ils utilisent en général les couches
sélectionnées lors de l'expédition des modifications.

Ce n'est pas parce que tu affiches l'ortho de l'IGN que tu n'as pas
utilisé le cadastre avant.

De même si tu fusionnes deux bouts de bâtiments issus du cadastre,
quelle est la source ?

Cadastre (disons 4 points inchangés, l'ensemble du bâti globalement est
inchangé) ou survey (tu sais qu'il n'y a qu'un bâtiment : les 2 points
supprimés) ou ortho (tu as vérifié sur l'ortho qu'il n'y a qu'un bâtiment).

Donc même avec des outils pas mal faits, dans certains cas je ne sais
trop quelle est la source !

Avoir des outils style DeepHistory intégrés aux éditeurs, ça permettrait
d'y voir plus clair.

N. B. : certaines sources ne portent évidemment que sur certaines
parties objets, ainsi le cadastre ne joue que sur la géométrie, quelques
fois sur le nom ou la plaque de rue.

Et oui, source sur l'objet, sur une partie de l'objet, sur la changeset
ça n'aura de validité que si chacun s'y astreint.

Les sources ajoutées automatiquement sans contrôle explicite de
l'utilisateur ça peut induire le suivant en erreur.

Ce n'est pas pour autant qu'il ne faut pas essayer de le faire proprement.

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"

[Pierre-Olivier GREGOIRE]

Bonjour


Le lun. 16 nov. 2020 à 16:03, Vincent Bergeot  a
écrit :

>
>
>
> On pourrait plus tard décliner la différentiation moyen de commande /
> moyen de retrait :
> peut-être :
> "order:covid19" : yes/no/phone/website voir même "order:url"
> "pick-up:covid19" : "in-store"/"drive"
>
>
> peut-être que description:covid19 est suffisant pour préciser ensuite tous
> les cas, plutôt que de trop décliner en des tags différents ?
>

Oui je suis d'accord. J'aimerais bien y réfléchir sur tagging plus tard
mais pour ça reste ouvert à court terme je pense aussi qu'on peut utiliser
description:covid19 pour les détails.

En regardant à la concurrence (google maps, bing maps, pages jaunes...),
ils ne structurent pas non plus les canaux de commande ou de retrait.

à vous
>
> --
> Vincent Bergeot
>
> ___
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[osm . sanspourriel]

On a déjà les moyens de payement, pas la peine d'en inventer (sauf à
suffixer par covid19).

https://wiki.openstreetmap.org/wiki/FR:Key:payment#Argent_liquide

Ça donnerait :

payment:cash:covid19=no

Par contre un commerçant en dessous d'une certaine somme doit accepter
le liquide (car contre il peut imposer un payement à la réservation ce
qui revient à peu près au même).

Et par rapport au message de Vincent : KISS, en français c'est réserver
et emporter donc :

reservation=only

takeaway=only

(avec les suffixes covid19 si c'est du temporaire).


Le 16/11/2020 à 20:27, Philippe Verdy - ver...@gmail.com a écrit :

le paiement sur place en espèces impossible.




___
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"

[Philippe Verdy]

Note aussi: les magasins ouverts en "clickandcollect" n'obligent pas tous à
commander en ligne: on peut passer commande sur le pas de la porte et
revenir plus tard. Le problème, c'est surtout le paiement (les boutiques en
clickandcollect ou vendeurs "à la roulotte" y compris les foodtrucks, ne
veulent pas mettre leur caisse près de la porte ouverte (même si elle est
barrée par un meuble de service) pour des raisons de sécurité aussi, et ne
peuvent pas non plus ouvrir s'il y a une file d'attente sur la rue (c'est
un gros problème pour la vente de nourriture à emporter, type fastood: en
général on veut manger quand c'est prêt, sans attendre et c'est vite
périmé, donc comment éviter les files d'attente sur le trottoir? Certains
ont des livraisons, comme les pizzas, mais en plus il y a le couvre-feu qui
les oblige à fermer très vite le soir).

La vente à emporter c'est pas évident pour tout le monde.

Au final pour beaucoup les seuls magasins encore accessibles sont les
supermarchés et hypers (avec restriction de l'affluence et
controle/surveillance des entrées devenu obligatoire, par un vigile ou par
certains employés du magasin pour réguler les entrées et répartir les
clients en caisse : si les caisses ont trop de monde à attendre, l'entrée
est refusée, les clients doivent attendre leur tour dehors et entrent au
compte-goutte avec la sortie des autres clients; pour accélérer le flux,
les commerces ont déjà réduit leur offre au delà même des restrictions
gouvernementales, et les espaces de circulation, on ne doit plus "trainer"
dans les rayons et certains limitent les quantités dans les charriots, le
temps dans le magasin est limité, on vous invite alors à prendre
l'essentiel, passer vite aux caisses et revenir plus tard pour le reste; ça
se passe surtout en début de soirée ou le samedi; moins de choix, plus
aucune "promotion", plus de produits "en vrac", plus de produits en lots
importants, moins de marques... Là aussi on vous invite à commander sur
Internet et retirer en "drive" mais ce n'est pas possible pour tout le
monde). Pour les familles nombreuses, ou les personnes éloignées sans
véhicule (avec des transports en commun également très réduits et limités
en capacité et fréquence), faire ses courses est devenu compliqué.


Le lun. 16 nov. 2020 à 16:03, Vincent Bergeot  a
écrit :

> Bonjour,
>
> je reprends ce petit bout de ton mail
> Le 10/11/2020 à 11:52, Pierre-Olivier GREGOIRE a écrit :
>
> *Les tags :*
>
> Maintenant il est vrai que "takeway:covid19" a été utilisé pendant le
> premier confinement pour un mélange des deux concepts : "retrait en
> magasin" et "consommer à emporter". Personnellement je préfererais :
> * Introduire une nouvelle clef "order_and_collect:covid19"
> * il faudra décider ce qu'on fait des anciens tags pour les magasins : en
> tant que consommateur de donnée, toujours interpréter takeaway:covid19
> comme équivalent à "order_and_collect:covid19" quand il ne s'agit pas d'un
> restaurant ou d'un café ou d'un bar peut-être ?
>
> Pour les livraisons je pense qu'on peut rester sur "delivery:covid19" qui
> personnellement ne me pose aucun souci.
>
> pour ma part, favorable à la notion order_and_collect:covid19 -> l'accès
> au magasin est fermé sauf pour venir chercher une commande préalablement
> réalisée. C'est sans doute un des cas les plus fréquents en ce moment.
>
>
>
>
> On pourrait plus tard décliner la différentiation moyen de commande /
> moyen de retrait :
> peut-être :
> "order:covid19" : yes/no/phone/website voir même "order:url"
> "pick-up:covid19" : "in-store"/"drive"
>
>
> peut-être que description:covid19 est suffisant pour préciser ensuite tous
> les cas, plutôt que de trop décliner en des tags différents ?
>
> à vous
>
> --
> Vincent Bergeot
>
> ___
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Philippe Verdy]

Le lun. 9 nov. 2020 à 20:40, Yves P.  a écrit :

> - 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 ?
>

Non car "delivery" indique un service de livraison (à domicile). le
"clickandcollect" c'est la possibilité de retier sur place (la boutique est
fermée à l'exception du pas de porte avec une barrière, on ne peut pas
entrer mais on peut se faire remettre les colis préparés (aux heures
d'ouverture indiquées, éventuellement adaptées avec :"covid19") et
éventuellement payer.

Attention : certains commerces "clickandcollect" ne traitent QUE les
commandes payées en ligne, car il n'y a plus de caisse ni échange de
monnaie). Ceux qui n'ont pas d'internet ou de carte de paiement à distance
ne peuvent PAS aller dans ces commerces (tout le monde n'a pas une carte
"CB", beaucoup n'ont que des cartes de retrait simple d'espèces). Nombre de
commerces n'acceptent pas non plus les paiements mobiles (eux aussi
réservés à certaines catégories de personnes, et pas sur tous les
abonnements mobiles, et il faut un terminal compatible: le commerçant ne
veut pas toucher votre smartphone, pas plus que la monnaie, pour ne pas
risquer de contaminer son propre commerce: ça commence maintenant dans les
bureaux de tabac et marchands de journaux, dont déjà le bar est fermé; il
n'est pas évident de décontaminer des pièces et billets et les manipuler
facilement et sans risque).

Donc il faudrait un autre tag pour le paiement en ligne obligatoire, ou le
paiement sur place en espèces impossible.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jérôme Amagat]

Je suis d'accord, aucune solution n'est parfaite. Mais dire, on supprime
source=* car la source est quelque part dans l'historique de l'objet, je
n'y vois pas la solution miracle, loin de là.

Il faut revenir au sujet de cette discussion, on parle de modifier un tag
sur 1000 objets en France. Est ce qu'au niveau mondial, il a été décidé de
supprimer le tag source=* ? A ma connaissance non.

Je ne vois pas de problème à parler de la façon d'indiquer la source, mais
le principal ici, c'est d'aider David pour son import en se limitant à
l'usage aujourd'hui. Et pour moi, ça veut dire, (toujours pour son
changeset sur les heures d'ouverture), on ne touche pas à source=*, et on
met la source sur le changeset, on peut aussi l'ajouter dans
source:opening_hours=* mais pas d'obligation.

Et si un jour, il est décidé que le tag source=* était superflu, il sera
facile de le supprimer à ce moment-là.

Mon avis sur la façon d'indiquer la source : c'est le truc que je n'aime
pas lors de mes contributions à osm, je sais jamais quoi mettre et où,
surtout que la plupart du temps, je modifie des choses très différentes
avec des sources différentes. Quant tout (ou presque) vient d'une même
source, c'est facile de mettre la source sur le changeset mais c'est pas la
solution la plus simple pour les suivant qui voudrait savoir qui et à
partir de quelle source a été ajouter un tag, "il faudrait" que chaque tag
ait sa source et sa date de modification, c'est la ou le tag source:*=* est
utile mais comme il n'est pas lié au *=*, on peut modifier l'un sans
modifier l'autre et ça complique beaucoup l'édition. "Il faudrait" que
l'éditeur face le gros du travail, si lorsque l'on modifie un tag,
l'éditeur lie au tag la source du changeset et sa date de modification et
que cette info était facile à avoir dans l'éditeur pour les suivant, ça
simplifierait les choses mais il y a toujours le problème des sources
multiples et s'il faut écraser l'ancienne source ou l'ajouter...

Le lun. 16 nov. 2020 à 12:22, Marc_marc  a écrit :

> Bonjour,
>
> Le 16.11.20 à 10:23, Jean-Claude Repetto a écrit :
> > L'indication exclusive de la source sur le changeset n'est qu'un
> > pis-aller,
>
> dr;tl : la "vie" d'un tag source dans les différents cas
> de figure explique mieux les problèmes et les solutions.
>
> version longue :
>
> dans cette discussion, j'ai l'impression qu'il y a une tendance
> à "ce que je fais est parfait, les autres font du mauvais"
> qui ne se base pas assez sur la réalité tant des capacités
> des éditeurs que du comportement réel des contributeurs.
>
> prenons un exemple :
> j'importe un bâtiment à partir du cadastre avec source=cadastre
> sur l'objet building comme jadis et source=cadastre sur le changeset.
> ensuite un autre contributeur modifie la géométrie (la position
> des 4 nœuds) du bâtiment parce que celle du cadastre est erronée,
> ainsi qu'il a pu le constater sur place.
> il modifie aussi building=yes en building=detached
>
> Quel est la source actuelle de l'objet et de sa géométrie ?
> il ne subsiste plus aucune information venant du cadastre.
> toutes les infos de l'objet actuelle proviennent du terrain.
> est-t-on d'accord qu'il ne devrait donc plus y avoir
> aucune trace de source=ccadastre sur la version actuelle ?
>
> voyons ce qui se passe dans la réalité lors de cette modif
>
> 1) AUCUN éditeur à ma connaissance ne va modifier la source
> déclarée sur l'objet sauf intervention humaine spécifique,
> elle va donc se désynchroniser. si quelqu'un se base sur la source
> de l'objet et crois que l'objet actuel vient du cadastre il se trompe.
> à l'inverse tous les éditeurs vont fournir des meta-donées (le
> changeset) puis celui-ci est imposé par l'api.
>
> 2) certains préconisent alors d'ajouter source:geometry
> et source:building. mais là aussi aucun éditeur
> ne les traire comme une meta-donnée. c'est qu'une donnée
> comme une autre, uniquement modifié par intervention humaine
> spécifique. donc cela revient exactement à la même chose que
> le point précédent (source:geometry=cadastre sur l'objet
> ne dit pas que la géométrie actuelle vient du cadastre).
>
> 3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
> d'un tag source sur le changeset. iD le permet aussi.
> tous les éditeurs proposent facilement d'ajouter des sources
> ainsi que l'imagerie sat utilisée pour l'alignement.
> en tout état de cause, la présence de meta-donnée (les tags de
> changeset) sont renseigné par le contributeur de cette modif là
> et concernerait cette modif, donc fiable (quand elle existe)
> pour connaître la source de ces modifs.
>
> 4) le cas d'une session de modif avec plus d'une source.
> certains changeset mixent plusieurs sources
> et mixent donc aussi des âges de source différents.
> Il faut se souvenir que le tag source dans osm permet
> la traçabilité et la communication entre contributeur.
> Pour gérer ces mix, il y a 3 écoles :
> - plusieurs source:tag1 source:tag2 sur l'objet
> Hors on a vu ci dessous que cela ne 

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

[Vincent Bergeot]

Bonjour,

je reprends ce petit bout de ton mail
Le 10/11/2020 à 11:52, Pierre-Olivier GREGOIRE a écrit :

*Les tags :*

Maintenant il est vrai que "takeway:covid19" a été utilisé pendant le 
premier confinement pour un mélange des deux concepts : "retrait en 
magasin" et "consommer à emporter". Personnellement je préfererais :

* Introduire une nouvelle clef "order_and_collect:covid19"
* il faudra décider ce qu'on fait des anciens tags pour les magasins : 
en tant que consommateur de donnée, toujours interpréter 
takeaway:covid19 comme équivalent à "order_and_collect:covid19" quand 
il ne s'agit pas d'un restaurant ou d'un café ou d'un bar peut-être ?


Pour les livraisons je pense qu'on peut rester sur "delivery:covid19" 
qui personnellement ne me pose aucun souci.


pour ma part, favorable à la notion order_and_collect:covid19 -> l'accès 
au magasin est fermé sauf pour venir chercher une commande préalablement 
réalisée. C'est sans doute un des cas les plus fréquents en ce moment.






On pourrait plus tard décliner la différentiation moyen de commande / 
moyen de retrait :

peut-être :
"order:covid19" : yes/no/phone/website voir même "order:url"
"pick-up:covid19" : "in-store"/"drive"



peut-être que description:covid19 est suffisant pour préciser ensuite 
tous les cas, plutôt que de trop décliner en des tags différents ?


à vous

--
Vincent Bergeot

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

Re: [OSM-talk-fr] composteur

[Vivien MICHON]

Bonjour,

Bien vu le recensement des composteurs.
Je préciserai la problématique comme suit: comment différencier un point de 
collecte/récupération d'un point de compostage (avec possibilité aussi que ce 
soit les deux).

En d'autres termes, est-ce l'usager qui apporte de la matière organique à 
composter et qui s'occupe lui-même de l'entretien (matière sèche, mélanger, 
veiller à mettre dans le bon bac >> compost de type libre-service ou 
libre-utilisation) ou bien l'usager ne fait que déposer de la matière organique 
et elle est ensuite utilisée en compostage?

De la même façon, l'information sur la possibilité de récupérer ou non du 
compost mature (prêt à être réutilisé comme engrais) serait intéressante.
Enfin, il y a parfois des lombri-composteurs en accès, dont le fonctionnement 
est différent (ne pas y mettre de matière organique acide en particulier, type 
citron ail oignon). Ajouter un TYPE?

Bon... avoir la première info serait déjà top!

Merci :!
Vivien


-Message d'origine-
De : Marc_marc  
Envoyé : lundi 16 novembre 2020 12:30
À : talk-fr 
Objet : [OSM-talk-fr] composteur

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment des composteurs.  
une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac de récupération qui 
serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

Cordialement,
Marc




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

Re: [OSM-talk-fr] composteur

[osm . sanspourriel]

Bonjour, on peut, ça ne mange pas de pain.

Perso, ça me semble d'un intérêt limité (les utilisateurs verront bien)
mais si certains y trouvent un intérêt ça me semble tout à fait correct.

Jean-Yvon

Le 16/11/2020 à 12:30, Marc_marc - marc_m...@mailo.com a écrit :

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment
des composteurs.  une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac
de récupération qui serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

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

[OSM-talk-fr] composteur

[Marc_marc]

Bonjour,

de nombreux nouveaux contributeurs renseignent en ce moment
des composteurs.  une idée de comment les tager ?

le wiki renseigne
https://wiki.openstreetmap.org/wiki/FR:Comment_cartographier_un...#Composteurs
amenity=recycling
+ recycling:green_waste=yes
et/ou recycling:garden_waste=yes
et/ou recycling:organic=yes

mais rien dans ce tag ne différencie le composteur d'un bac
de récupération qui serra composté ou méthanisé ailleurs.
ne faudrait-il pas rajouter produce=compost ?
autre idée ?

Cordialement,
Marc



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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Marc_marc]

Bonjour,

Le 16.11.20 à 10:23, Jean-Claude Repetto a écrit :
> L'indication exclusive de la source sur le changeset n'est qu'un
> pis-aller,

dr;tl : la "vie" d'un tag source dans les différents cas
de figure explique mieux les problèmes et les solutions.

version longue :

dans cette discussion, j'ai l'impression qu'il y a une tendance
à "ce que je fais est parfait, les autres font du mauvais"
qui ne se base pas assez sur la réalité tant des capacités
des éditeurs que du comportement réel des contributeurs.

prenons un exemple :
j'importe un bâtiment à partir du cadastre avec source=cadastre
sur l'objet building comme jadis et source=cadastre sur le changeset.
ensuite un autre contributeur modifie la géométrie (la position
des 4 nœuds) du bâtiment parce que celle du cadastre est erronée,
ainsi qu'il a pu le constater sur place.
il modifie aussi building=yes en building=detached

Quel est la source actuelle de l'objet et de sa géométrie ?
il ne subsiste plus aucune information venant du cadastre.
toutes les infos de l'objet actuelle proviennent du terrain.
est-t-on d'accord qu'il ne devrait donc plus y avoir
aucune trace de source=ccadastre sur la version actuelle ?

voyons ce qui se passe dans la réalité lors de cette modif

1) AUCUN éditeur à ma connaissance ne va modifier la source
déclarée sur l'objet sauf intervention humaine spécifique,
elle va donc se désynchroniser. si quelqu'un se base sur la source
de l'objet et crois que l'objet actuel vient du cadastre il se trompe.
à l'inverse tous les éditeurs vont fournir des meta-donées (le
changeset) puis celui-ci est imposé par l'api.

2) certains préconisent alors d'ajouter source:geometry
et source:building. mais là aussi aucun éditeur
ne les traire comme une meta-donnée. c'est qu'une donnée
comme une autre, uniquement modifié par intervention humaine
spécifique. donc cela revient exactement à la même chose que
le point précédent (source:geometry=cadastre sur l'objet
ne dit pas que la géométrie actuelle vient du cadastre).

3) JOSM/Vespucci/StreetComple poussent fortement l'ajout
d'un tag source sur le changeset. iD le permet aussi.
tous les éditeurs proposent facilement d'ajouter des sources
ainsi que l'imagerie sat utilisée pour l'alignement.
en tout état de cause, la présence de meta-donnée (les tags de
changeset) sont renseigné par le contributeur de cette modif là
et concernerait cette modif, donc fiable (quand elle existe)
pour connaître la source de ces modifs.

4) le cas d'une session de modif avec plus d'une source.
certains changeset mixent plusieurs sources
et mixent donc aussi des âges de source différents.
Il faut se souvenir que le tag source dans osm permet
la traçabilité et la communication entre contributeur.
Pour gérer ces mix, il y a 3 écoles :
- plusieurs source:tag1 source:tag2 sur l'objet
Hors on a vu ci dessous que cela ne garanti en rien la source
de l'object actuel dès lors que c'est un donnée à gérer
humainement et non une méta-donnée gérée par l'api.
- plusieurs tags sur le changeset (oui on peux aussi
facilement mettre source:geometry=BDORtho source:name=survey
sur un changeset
- plusieurs changeset : un premier pour ajouter
les objets manquant avec la géométrie basé sur l'imagerie,
un 2ieme pour ajouter ce qui a été vu sur le terrain.

piste d'amélioration :
1) améliorer les éditeurs pour qu'ils affichent dans l'état actuel
de l'objet la source du changeset à côté de la valeur du tag

2) améliorer les éditeurs pour qu'ils invalident le tag source
précédent lorsque la source de l'objet actuel n'est plus celle-là.
Je viens justement de découvrir une règle optionnel dans josm
qui affiche un avertisement bien pratique en modif d'objet avec source=*

3) avis perso : encourager des chageset humainement lisible au lieu
de bloc indigeste qui laisse le contributeur suivant dans le doute :
ajout bati et en même temps un magasin est supprimé : erreur ou
volontaire ? c'est illisible.
quand il y a 2 modifs, c'est évidement possible de les lister
dans le commentaire du changeset. quand un changeset fait 20 choses
en même temps, on se retrouve avec des "..." nocifs.

> mettre source:opening_hours= (...) sur chaque bureau de poste modifé

ce qui ne résout rien, la prochaine modif opening_hours n'invalidera
pas ce tag sur l'objet. par conséquent quant tu vois ce tag
sur un objet, il ne te rient de la source de la valeur actuelle.

PS: ne va oublier la déformation "on a jadis fait comme cela en fr".
il suffit de voir taginfo mondial pour constater la sur-représentation
des sources en fr sur les objets: la moitié des tags source au monde
sur les bâtiments provient de la France alors que le nombre de bâtiment
en France ne représente que 10% du total mondial.
cela montre qu'ailleurs ils n'ont pas ou plus ou moins ce dogme.

Cordialement,
Marc



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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[Jean-Claude Repetto]

Le 15/11/2020 à 21:56, Éric Gillet a écrit :


La majorité des modifications dans osm utilise encore source=*. Osmose 
ajoute source=* et beaucoup de gens l'utilisent toujours.


Si mes calculs sont bons il y a :

64 millions de changesets (sur 93) ont un tag source.
213 millions d'objets (sur 7 milliards) ont un tag source

Ça me semble bien pencher vers l'usage des tags de changeset.

https://aws.amazon.com/fr/blogs/big-data/querying-openstreetmap-with-amazon-athena/ 



https://wiki.openstreetmap.org/wiki/Stats#Nodes.2C_ways_and_relations 



Bonjour,

Indiquer la source d'un changeset est tout à fait insuffisant pour 
assurer une bonne traçabilité d'OSM. En effet, il est rare qu'on utilise 
une seule source dans un changeset, à moins que celui-ci soit très petit.


Par exemple, j'ajoute un bâtiment: la source sera peut-être une imagerie 
aérienne, peut-être le cadastre. Il s'agit d'une chapelle ? La source 
sera mon observation.
Je modifie un chemin: la source sera peut-être une trace GPS,le cadastre 
ou l'imagerie aérienne...


L'indication exclusive de la source sur le changeset n'est qu'un 
pis-aller, destiné à simplifier la tâche des contributeurs. On peut 
éventuellement s'en dispenser mais il ne faut pas inciter les 
contributeurs à ne plus indiquer les sources dans l'objet, et encore 
moins à les supprimer lorsqu'elles existent.


Dans le cas de l'importation dont on discute ici, je suggère de mettre 
source:opening_hours=datanova.laposte.fr (ou équivalent) sur chaque 
bureau de poste modifé.


Jean-Claude

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