Le 12 juin 2015 22:31, Christian Rogel <christian.ro...@club-internet.fr> a écrit :
> J’avais l’intention de parler des horaires à mettre dans OSM et je voulais > souligner que, pour qui est familier de l’anglais, la syntaxe requise est > plutôt simple, bien qu’elle demande quelque entraînement. à voir le résultat, il y a encore du boulot, cf. la carte des erreurs de tagging de opening_hours : http://ypid.de/~osm/?setLng=fr&zoom=12&lat=48.86189&lon=2.37245&layers=B0T&filter=errorOnly&tags=opening_hours On a encore un nombre assez important de valeurs inexploitables. Je vous présente donc YoHours, la petite interface web pour passer > d'horaires compréhensibles par un humain au format opening_hours > (compréhensible, mais moins) : http://github.pavie.info/yohours/ > génial ! En effet quelques optimisations graphiques et techniques serraient à faire mais c'est un bon début. Tu aurais besoin de gérer des cas complexes (horaires dépendant de la > saison...) ou juste la semaine de base ? > la semaine de base serait un bon point de départ. Je pense qu'il faut passer plus de temps sur l'interface que sur les fonctionnalités avancées. Sinon le résultat est exactement ce que j'attendais : un simple champ à copier-coller dans l'éditeur de mon choix. Idée pour un développement à plus long terme : permettre une recherche NOMINATIM pour sélectionner un élément et éditer ses horaires d'ouverture en live ... j'imagine bien quelque chose d'assez simple pour pouvoir l'envoyer à un commerçant en lui demandant de compléter ses horaires. Encore une fois la simplicité de l'interface serait clef pour un tel outil. à ta dispo PanierAvide si tu veux qu'on en parle plus en détails. ++ Le 13 juin 2015 10:21, PanierAvide <panierav...@riseup.net> a écrit : > Merci pour ce retour, je vais commenter au fur et à mesure, en reprécisant > le contexte : ça a été fait en 2h, c'est (pour l'instant) juste une ébauche > ;) > > > Le 13/06/2015 09:56, Philippe Verdy a écrit : > >> C'est très moche oui, pas un problème sauf qu'on s'attend à une >> présentation façon tableau "emploi du temps" scolaire pour les ouvertures, >> une icone "+" pour scinder une tranche horaire en deux ou pour l'étendre >> aux jours précédents ou suivants de la semaine (on peut aussi "tirer" >> depuis bords du tableau si tu gères la souris, un plus compliqué que des >> boutons). >> > Ce serait effectivement l'idéal, c'est plus complexe à mettre en place (il > faut créer un widget dédié), mais ça doit bien pouvoir se faire en prenant > le temps. > >> >> Mais le résultat n'est pas terrible non plus quand on obtient >> >> "Mo-Su 09:00-18:00; We off; Th off; Fr off; Sa off" >> >> où les "off" peuvent être abrégés en "We-Sa off"... et même encore plus >> simplement : >> >> "Su-Tu 09:00-18:00" >> > C'est vrai, je n'avais pas vu ça. Cela vient de l'algorithme du plugin > JOSM OpeningHoursEdit (il a le même comportement dans JOSM), donc à voir > pour améliorer celui-ci en amont. D'ailleurs, on pourrait même imaginer > créer une bibliothèque dédiée à cette question des horaires d'ouvertures, à > la manière de opening_hours.js mais dans le sens saisie utilisateur -> clé > opening_hours. > >> >> Tu sembles assumer que la commence commence uniquement le lundi (à la >> façon dont on numérote les semaines ISO y compris en France dans >> l'adminstration et la plupart des entreprises mais pas dans tous les >> métiers), mais les anglosaxons protestants et le judaïsme voient la semaine >> commencer un dimanche après la samedi de shabbat, les musulmans la voient >> commencer le samedi après le vendredi rituel). >> > C'était par souci de simplicité, je connais ces aspects mais rien > n'empêche actuellement quelqu'un de commencer par saisir le dimanche, il > faut juste aller le chercher dans le menu déroulant. Si l'on raisonne dans > l'autre sens, en souhaitant effectivement implémenter cet aspect là, il > faut connaître au minimum la position de la personne (et extrapoler sur les > coutumes locales), au mieux sa religion. Le dernier cas n'est pas > envisageable, le premier cas donne des résultats variables (la position par > localisation d'adresse IP vaut ce qu'elle vaut). Après il existe peut-être > une autre solution implémentable, dans ce cas pourquoi pas :) > >> >> La semaine légale varie d'un pays à l'autre (essentiellement selon la >> religion majoritaire), mais on devrait pouvoir définir un intervalle de >> jour de la semaine valide comme "Sa-Tu" signifiant samedi, dimanche, lundi >> et mardi alors que "Tu-Sa" signifie mardi, mercredi,... vendredi et samedi: >> l'énumération se fait toujours dans l'ordre croissant des jours de la >> semaine et peut passer sans problème d'une semaine légale à la suivante. >> > À priori la syntaxe opening_hours le permet, il suffirait de l'implémenter. > >> >> Autant que possible éviter les "off" pour les jours de fermeture >> hebdomadaires (par exemple en France de nombreux commerces comme coiffeurs >> ou boulangers sont fermés le lundi on indique "Tu-Su" ce qui positionne >> dimanche en fin de l'intervalle, mais d'autres sont fermés plutot le >> dimanche et on indique "Mo-Sa" pour les ouvertures). >> >> Le "off" devrait plutôt être utilisé pour indiquer les périodes >> saisonnières ou exceptionnelles de fermeture (par exemple pour une >> fermeture en congés scolaires ou un mois de l'année, ou les jours fériés >> officiels, ou pour certaines dates religieuses mobiles non fériées dans les >> services publics mais qui peuvent l'être dans le privé, par exemple durant >> ou à la fin du mois de Ramadan, ou des fêtes relatives aux différentes >> dates de Pâques selon les églises, ou le nouvel an chinois). >> > C'est certain que si on peut éviter d'avoir trop de "off" la clé sera plus > lisible. > >> >> Si l'ouverture est uniquement saisonnière une petite mineure de l'année >> (par exemple unqiuement en périuoide estivale, il faut le mettre dans le >> premier attribut avec la plus grande période d'ouverture hebdomadaire. Si >> c'est ouvert tous les jours (même avec des différences horaires certains >> jours, cette première période ne devrait même mentionner aucun jour de la >> semaine). >> >> Dans de nombreux services ne pratiquant pas la journée continue, la >> période matinale est la même tous les jours d'ouverture et seul >> l'après-midi varie uniquement par l'horaire de fermeture en fin de journée >> : on a intérêt alors à grouper ensemble les matinées et séparer les >> après-midi mais souvent ça se limite à un seul des jours hebdomadaire >> d'ouverture et on crée une entrée séparée pour ce jour (typiquement pour le >> vendredi après-midi en France quand samedi et dimanche sont fermés): on >> sépare alors le vendredi des autres jours lundi-jeudi, et on ne met rien >> pour samedi et dimanche qui sont déjà "off" par défaut dès qu'un attribut >> "*:open_hours=*" est utilisé pour mentionner les périodes d'ouverture) >> >> D'une façon générale on doit privilégier en premier l'écriture des heures >> d'ouverture sur les périodes en jour les plus longues et les plus >> fréquentes, en affichant ensuite les jours supplémentaires sans utiliser >> "off", puis seulement utiliser "off" pour les dates plus rares ou certaines >> périodes de l'année : la première entrée (séparée par point-virgule) doit >> correspondre à la période d'ouverture la plus longue (hors exceptions "off" >> listées à la fin) car c'est la première qu'on lira (même si une interface >> utilisateur la traduit en interprétant la donnée OSM) >> >> La syntaxe telle que définie par le wiki permet déjà (il me semble) de > gérer tous ces aspects, encore faut-il qu'ils soient implémentés ;) C'est > également l'intérêt de la démarche, en proposant des implémentations on a > l'occasion d'en discuter pour converger vers des outils plus conviviaux à > utiliser, et donc qui incitent à renseigner ces informations là. La magie > du libre en somme :) > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- *Florian Lainez* @overflorian <http://twitter.com/overflorian>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
