Re: [OSM-talk-fr] [Talk-ht] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Non c'est le début, Pour les classes elles sont entrain d'être discutées en ce moment. D'ou l'interet de participer car ils sont entrain d'affiner leur algorithme maintenant. Il y a 44 classes pour l'instant, ils veulent en faire moins pour être sur d'extraire régulièrement l'information . Rien n'empeche de discuter par région et voir avec eux directement. D'ou une phase de test ( Juillet - Septembre). https://hackpad.com/Nomenclature-Pour-classification-avec-Sentinel-m04lIl5jKr4 Pour l'instant le CNES / ESA se focalisent sur l'Europe. Mais la donnée sera disponible tous les mois sur d'autre zones. Aprés à voir si cela peut permettre d'alimenter la base de donnée OSM ou si c'est une couche à part. A + FredM https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Le 14 juin 2015 00:19, Severin Menard a écrit : > Salut Fred, > > Merci pour l'info ! > > C'est 15-20 classes pour l'ensemble du monde, de milieu désertique à > équatorial, anthropisé ou non ? > > Comment cela s'est passé jusqu'à présent les imports de données de > télédétection dans OSM ? Batch ou par objet ? Quid du recoupement avec les > éventuels zonages existants ? Il y a déjà une méthodologie ? > > 2015-06-13 17:20 GMT+00:00 Frederic Moine : > >> Merci Sébastien pour ces informations, >> >> On avance donc >> >> J'ai essayé de faire une synthèse des discussions sur ce Hackpad >> >> que j'ai transformé en "Fiche Projet" >> >> ou chacun peut s'impliquer si il le veut. >> >> Pour ma part je vais surement aller faire des points du côté des écrins >> et de Barcelonnette en France. >> >> Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. >> >> Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils >> open source et la données attenantes pour voir comment mettre à jour le >> land cover sur certaines zones. >> Bangladesh ( innondation) etc >> >> http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 >> >> https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp >> >> Donc plus on est plus on rit enfin pas sur ... >> >> a plus FredM >> >> PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image >> prévue sur haiti. >> >> Mais comme la donnée image est gratuite il est possible surement de >> monter un serveur qui va récuperer la donnée sur cette zone >> >> ___ >> Talk-ht mailing list >> talk...@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ht >> Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) >> pour traduire les messages. > > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Talk-ht] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Salut Fred, Merci pour l'info ! C'est 15-20 classes pour l'ensemble du monde, de milieu désertique à équatorial, anthropisé ou non ? Comment cela s'est passé jusqu'à présent les imports de données de télédétection dans OSM ? Batch ou par objet ? Quid du recoupement avec les éventuels zonages existants ? Il y a déjà une méthodologie ? 2015-06-13 17:20 GMT+00:00 Frederic Moine : > Merci Sébastien pour ces informations, > > On avance donc > > J'ai essayé de faire une synthèse des discussions sur ce Hackpad > > que j'ai transformé en "Fiche Projet" > > ou chacun peut s'impliquer si il le veut. > > Pour ma part je vais surement aller faire des points du côté des écrins > et de Barcelonnette en France. > > Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. > > Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open > source et la données attenantes pour voir comment mettre à jour le land > cover sur certaines zones. > Bangladesh ( innondation) etc > > http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 > > https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp > > Donc plus on est plus on rit enfin pas sur ... > > a plus FredM > > PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image > prévue sur haiti. > > Mais comme la donnée image est gratuite il est possible surement de monter > un serveur qui va récuperer la donnée sur cette zone > > ___ > Talk-ht mailing list > talk...@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ht > Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) > pour traduire les messages. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Hot-francophone] Orfeo Tool box , Satellite Sentinelle
Merci Sébastien pour ces informations, On avance donc J'ai essayé de faire une synthèse des discussions sur ce Hackpad que j'ai transformé en "Fiche Projet" ou chacun peut s'impliquer si il le veut. Pour ma part je vais surement aller faire des points du côté des écrins et de Barcelonnette en France. Je devais me rendre sur le Burkina début juillet, mais c'est pas sur. Dans tous les cas j'aimerai bien apprendre un peu plus sur les outils open source et la données attenantes pour voir comment mettre à jour le land cover sur certaines zones. Bangladesh ( innondation) etc http://www.cesbio.ups-tlse.fr/multitemp/?page_id=4699 https://hackpad.com/Projet-Sentinel-2-H1xiw0Hs2Yp Donc plus on est plus on rit enfin pas sur ... a plus FredM PS: J'ai mis en copie sur la liste Haiti, pour l'instant pas d'image prévue sur haiti. Mais comme la donnée image est gratuite il est possible surement de monter un serveur qui va récuperer la donnée sur cette zone ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bano - nom de voie - point bleu
Effectivement, ce sont celles qui m'intéressent. Tu as tout compris... Se serait vraiment bien qu'on puisse récupérer cette information avec, éventuellement si elle existe aussi, le code Fantoir inscrit dans la relation. Par défaut, pour les autres, ne pourraient-ont pas récupérer l'identifiant du tronçon de la voie concernée (n'importe lequel ou le plus proche) ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien & chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/bano-nom-de-voie-point-bleu-tp5845781p5848058.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] outil user-friendly pour taguer les horaires opening_hours
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ég
Re: [OSM-talk-fr] outil user-friendly pour taguer les horaires opening_hours
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). 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" 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). 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. 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). 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) Le 12 juin 2015 22:47, PanierAvide a écrit : > Pour le challenge, j'ai codé une petite interface, en regardant ce qui se > faisait (de simple) par ailleurs. On trouve souvent le curseur que l'on > déplace le long d'une journée pour faire un créneau horaire. > 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/ > Pour l'instant c'est laid, mais ça fonctionne. La génération de la valeur > opening_hours est largement basée sur l'algorithme utilisé par le plugin > JOSM. > Si ça présente un intérêt pour quelqu'un, je verrai pour faire une > interface moins Web 0.1 ;) > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
