Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo
Au lieu d'écraser, on peut toujours renommer l'ancien tag avec un préfixe "fixme:" avant "ref:" et la valeur du tag inchangée. Au passage le bot peut générer une liste de ces "fixme" afin de procéder au nettoyage manuel sans rien perdre en attendant. L'autre solution c'est d'exporter ces conflits vers une liste gérée par Osmose. Le mer. 15 janv. 2020 à 21:25, François Lacombe a écrit : > Il n'y a pas eu de nouvel échanges dans ce fil > > Il me semble donc que je peux procéder à la migration ? > En tout cas passer de ref:ERDF:gdo à ref n'est pas possible sans perdre > l'information sur ce qui est effectivement présent sur le terrain (ref=P 57 > vs ref:ERDF:gdo=19132P0057) > Sauf erreur je crois qu'une réponse a été apportée sur tous les points > levés. > > Si vous avez une nouvelle objection levez la main assez vite s'il vous > plaît > > Bonne soirée > > François > > Le mer. 8 janv. 2020 à 13:33, François Lacombe > a écrit : > >> Bonjour Marc, >> >> Je suis d'accord avec Yves ici >> Ce n'est pas parce qu'un objet ne porte qu'une référence, qu'on ne peut >> pas associer des règles de validation ou de formatage particulières sur >> celle-ci. >> Plus que les tags de l'objet et le contexte d'utilisation de ref=*, il >> faut une clé dédiée à laquelle on associe une doc complète et des règles >> dans les éditeurs. >> >> Même si certaines fois l'exploitant est repris dans le nom de la ref >> (ref:FR:Orange par exemple), ce n'est pas le but de déterminer l'exploitant >> avec la ref; >> Nous n'avons pas le droit de reprendre systématiquement le nom du >> référentiel à cause de la propriété intellectuelle, donc on utilise la >> marque à la place qui correspond au nom de l'exploitant. >> >> Je serai bien embêté si il fallait exprimer sur la même page les règles >> pour ref:FR:gdo et ref:FR:FINESS. Ce n'est pas du tout la même chose, ce >> serait éminemment plus complexe à valider aussi. >> >> Voir aussi les objets qui portent plusieurs ref : ref:FR:ARCEP + >> ref:FR:Orange (avoir ref + ref:FR:Orange n'a pas plus de sens que >> ref:FR:ARCEP + ref) >> >> On utilise enfin les namespaces parce que ces règles, concepts et >> référentiels sont spécifiques à la France et peuvent collisionner ailleurs >> dans le monde. >> >> Le mar. 7 janv. 2020 à 16:20, marc marc a >> écrit : >> >>> Bonjour, >>> >>> Le 07.01.20 à 16:01, Quentin Salles a écrit : >>> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien >>> actif ? >>> >>> Nous n'avions pas terminé la discussion sur la migration. >>> Je te conseille d'utiliser l'ancienne clef en attendant, puisque >>> c'est elle qui est la façon de faire actuellement. >>> >> >> Je n'ai pas fait la migration, pour l'ancienne clé reste valable. >> Y a-t-il d'autres points à discuter ? >> >> >>> je vais faire une comparaison avec les routes : >>> en lisant une référence sur le panneau d'une route, cette référence >>> se retranscrit dans la clef ref=numéro et ceci indépendamment de >>> l'opérateur ou du pays. >>> >> >> Parce qu'on traduit avant tout ce qu'on lit sur le terrain sans chercher >> à la rapprocher d'un référentiel quelconque. >> >> >>> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur >>> pour préciser qui serrait l'auteur de la ref. >>> on n'utilise pas non plus de mot dans la clef pour donner le sens de >>> cette référence ou le terme légal que celui-ci aurait dans la loi. >>> >> >> Et on pourrait, mais le domaine routier n'est pas le meilleur pour >> produire des référentiel, je ne connais pas le nom de la base de données >> qui attribue les numéros de routes. >> >> >>> A l'inverse, dans le domaine énergétique (et des transports), au fil >>> du temps, on utilise des espaces de nom pour la clef ref en France, >>> sans que je perçoive ni le besoin ni même l'intérêt. >>> >>> Au final l'utilisateur qui lit une ref quelque part, ne peux pas >>> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle >>> particulière qui régit cet objet dans ce pays. >>> >> >> C'est nécessaire parce qu'on a besoin de formater cette valeur par >> rapport à ce qui est lu sur le terrain : infos incohérentes, valeurs >> partiellement effacées, techniciens fatigués... >> >> >>> cela nuit à mon avis grandement à l'encodage simple et même à >>> l'utilisation (essayez donc de connaître le nombre de power=substation >>> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit >>> que cela peux être ref ou ref:* chose que de nombreux outil tel que >>> tainfo ou overpass ne permettent pas ou pas facilement) >>> >>> > Est-il possible de remonter l'information >>> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non >>> > visibles sur le terrain ? >>> >>> bien sur, osmose ne propose rien sur le sujet ? >>> https://osmose.openstreetmap.fr/fr/map/ >> >> >> Pas encore mais la migration va être l'occasion d'ajouter de la >> validation dans JOSM et Osmose quand j'aurais le temps de m'en occuper. >> * substation=minor_distribution +
Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki
Et rien n'empêche sur la page des cas résolus d'y inclure un grand merci à ceux qui ont voulu corriger et pour leur compréhension. L'erreur est humaine, l'oubli aussi. Parfois c'est juste un fournisseur tiers qui a bâclé sa livraison et ça n'a pas été détecté dans la recette initiale ou ça a été mis en ligne dans une version intermédiaire avant une recette finale; sinon ça peut être une simple bévue, une suppression involontaire, par exemple en rechargeant une ancienne version ou suite à un problème logiciel ou de stockage une restauration rapide depuis une sauvegarde en oubliant de remettre les corrections déjà faites. Tant qu'on peut communiquer et qu'on a une réponse positive, on peut admettre des délais normaux. Il faut juste que cela ne dure pas trop longtemps (par exemple un mois sans réponse) et que ce ne soit pas un refus manifeste de changer quoi que ce soit et négation du droit (en vérifiant aussi que celui qui répond était en droit de faire quelque chose, donc en faisant nos demandes au bon endroit). C'est pour ça que tout bon site devrait avoir une page de contact officiel. Le mer. 15 janv. 2020 à 21:22, François Lacombe a écrit : > Salut à tous > > D'accord avec Marc, je souhaite aussi avoir une liste des cas qu'on a > traité. > Non pas pour les réciter toutes les semaines mais aussi pour bien avoir à > l'esprit que c'est un travail permanent. > > Le problème des évolutions de ces sites et le suivi des échanges passés > (l'attitude adoptée par l'équipe à ce moment là, etc...) est important. > > Ok pour réorganiser la page, moins pour supprimer les cas rencontrés donc > > Bonne soirée > François > > Le mer. 15 janv. 2020 à 18:54, Cyrille37 OSM > a écrit : > >> Merci Marc, j'entends ton argument. >> >> Cyrille. >> >> ps: you win ! :D >> >> Le 15/01/2020 à 18:22, marc marc a écrit : >> > Hello, >> > >> > Le but est de pouvoir répondre différemment à celui qui commet >> > une erreur <> l'entreprise bricole la prod sous la pression >> > mais perd l'info à chaque maj parce que pas remonté comme il faut. >> > >> > ceci dit je suis tout a fait d'accord pour un droit à l'oubli. >> > mais pas avec un délai "instantané". >> > Il y des infos à ce sujet dans une loi ou une jurisprudence ? >> > Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe. >> > >> > Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord. >> > on ne vise pas l'humain qui était affecté à la tâche, >> > on vise le site. la fréquence de changement des gars qui s'en occupent, >> > cela peux se comprendre comme "raison" mais cela ne nous regardent pas >> > et cela ne doit sûrement pas être accepté comme excuse pour justifier >> > un problème récurent, si cela se produit. >> > >> > Cordialement, >> > Marc >> > >> > Le 15.01.20 à 18:11, Cyrille37 OSM a écrit : >> >> Hello >> >> >> >> Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en >> >> conformité, l'affaire est terminée. Si un jour le même site pose à >> >> nouveau problème c'est une autre "histoire", non ? >> >> >> >> À mon avis un site qui se retrouve à nouveau en défaut d'attribution un >> >> an après, n'est pas le même site: c'est une nouvelle version, une >> >> nouvelle équipe, ou un nouveau je ne sais quoi. >> >> >> >> Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même >> >> en justice, qui selon la gravité oublie les fautes, de façon que si tu >> >> refais une faute après un certain délai on ne te reprochera pas les >> >> fautes précédentes puisqu'elles sont oubliées. >> >> >> >> Dit encore autrement, je n'aime pas conserver des infos qui me >> >> permettrai d'accumuler des reproches pour le prochain désaccord. ;-) >> >> >> >> Cyrille. >> >> >> >> Le 14/01/2020 à 13:26, marc marc a écrit : >> >>> Le 14.01.20 à 12:14, Cyrille37 OSM a écrit : >> il me semble qu'il serait plus "poli / respectueux" >> de supprimer les cas résolus >> >>> Il ne faut en effet pas les garder comme "à problème" >> >>> >> >>> Mais les effacer pose le soucis de l'historique, càd le manque >> >>> de possibilité de recherche : >> >>> regarde le dernier site ajouté, c'est "ajout site". >> >>> si celui-ci est supprimé avec comme résumé "suppression site", >> >>> tu n'as aucun moyen de retrouver son existence hormis regardant chaque >> >>> modif. >> >>> >> >>> Je verrais bien une page d'archive, un peu comme cela se fait avec les >> >>> pages de proposition. le contenu passé est caché derrière un clic. >> >>> je me demande même si cela ne disparait pas aussi du moteur de >> recherche >> >>> (à vérifier). mais cela permet au moins de se rendre sur la page >> >>> d'archive, avoir la date de l'incident, la date de résolution. bref >> >>> savoir si besoin au lieu de réécrire l'histoire. >> >>> ___ >> >>> Talk-fr mailing list >> >>> Talk-fr@openstreetmap.org >> >>> https://lists.openstreetmap.org/listinfo/talk-fr >> >> ___ >> >> Talk-fr
Re: [OSM-talk-fr] Fond de carte sans mention OSM
Ce n'est pas vraiment une preuve; le dépaertement a très bien pu reprendre un fond de carte simplifié à lui datant encore du moment où les voies ferrées étaient en service. Et il manque bon nombre de détails qui indiquent que ce sont des données OSM. Pour moi cela vient d'un fichier SIG du département lui-même, et ce qu'il montre est issu chez OSM des données des SIG publics (départements, préfectures) avec les annotations ajoutées spécifiquement pour cette carte... Je ne vois aucune violation dans ce qui est ici une simple image, dans un style de rendu qui n'est même pas ce qu'on fait avec OSM. Le jeu. 16 janv. 2020 à 00:06, PierreV a écrit : > je ne demande pas de "reconnaître" une carte OSM: Je t'assure que reconnais > que c'est des données OSM par les voies ferrées inexistantes maintenant > remplacées en grande partie par des voies cyclables. Ce rendu utilise le > tag > "rail" de OSM quelque soit l'attribut et donc fait donc "apparaître" des > voies ferrées qui n'existent plus... > > mais surtout si je viens ici c'est que je souhaite savoir si quelqu'un me > dise quel est le "rendu" utilisé car je ne trouve pas sur Umap. > > > > > -- > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html > > ___ > 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] Fond de carte sans mention OSM
je ne demande pas de "reconnaître" une carte OSM: Je t'assure que reconnais que c'est des données OSM par les voies ferrées inexistantes maintenant remplacées en grande partie par des voies cyclables. Ce rendu utilise le tag "rail" de OSM quelque soit l'attribut et donc fait donc "apparaître" des voies ferrées qui n'existent plus... mais surtout si je viens ici c'est que je souhaite savoir si quelqu'un me dise quel est le "rendu" utilisé car je ne trouve pas sur Umap. -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fond de carte sans mention OSM
A ce niveau de zoom, je suis incapable de reconnaître une carte OSM, surtout qu'elle est pas mal pixelisée et simplifiée. Donat -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fond de carte sans mention OSM
Bonsoir, Mon département a diffusé une carte des routes passant à 90km/h: https://www.deux-sevres.fr/toutes-les-actualites/routes-retour-aux-90-km/h Je suis certain que le fond de carte est un "extrait" OSM car il y a des voies ferrées avec le tag "railway=razed" ou "railway=abandoned" que l'on peu voir en "gris pointillé". Est ce que vous reconnaissez le "rendu"? -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Les Data Items : discussion en cours
Pour info, on vient tout juste d'intégrer Tag2link à JOSM core, et depuis les règles peuvent être obtenues à partir de wikidata: https://josm.openstreetmap.de/ticket/18542#comment:6 A+ Vincent Le mer. 15 janv. 2020 à 21:15, François Lacombe a écrit : > Salut à tous, > > Nous avions survolé le sujet au précédent SOTM, notamment lors de la > présentation de JOSM par Vincent > ( > https://peertube.openstreetmap.fr/videos/watch/adbeec6c-a3cc-406b-8f0b-4c50990dedc3 > à 49:20) > > Une discussion supplémentaire a été lancée sur le wiki pour proposer la > généralisation des "DataItems" pour décrire les tags (en anglais) > > https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information > > Ca va demander encore beaucoup de temps de se pencher sur la question et > de répondre à toutes les critiques. > Comme je l'ai écris à l'instant à la suite des autres contributions, je > suis sur surpris de la levée de bouclier que cela suscite. > Un énorme travail a déjà été fait par plusieurs membre pour l'intégrer et > proposer déjà des premières connexions. Mais à court terme et à juste titre > il reste des point d'expérience utilisateur à régler avant que le système > soit pleinement utilisable. D'autres arguments sont levés et je ne > comprends pas : le wiki code sur 126 traductions toutes non à jour pour la > même clé c'est mieux qu'un item centralisé à l'image de wikidata. Il faut > savoir garder son calme. > > On ne va pas refaire le match ici, contribuez directement sur le wiki si > vous maîtrisez l'anglais et que vous voulez ajouter quelque chose (sinon il > n'y a rien d'autre à faire qu'attendre) > Pour avoir relevé dans une bien moindre mesure ce genre de défis > précédemment, je me dit que finalement le problème n'est pas technique, il > est avant tout humain. > > Comme d'habitude on soulignera les contributions positives sur le trac de > JOSM où des solutions sont recherchées pour produire les presets et > maintenir à jour les traductions. Merci à eux > https://josm.openstreetmap.de/ticket/17842 > > Soyez sûr qu'on sera plusieurs à parler du sujet au prochain SOTM-fr > > Bonne soirée > > François > ___ > 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo
Il n'y a pas eu de nouvel échanges dans ce fil Il me semble donc que je peux procéder à la migration ? En tout cas passer de ref:ERDF:gdo à ref n'est pas possible sans perdre l'information sur ce qui est effectivement présent sur le terrain (ref=P 57 vs ref:ERDF:gdo=19132P0057) Sauf erreur je crois qu'une réponse a été apportée sur tous les points levés. Si vous avez une nouvelle objection levez la main assez vite s'il vous plaît Bonne soirée François Le mer. 8 janv. 2020 à 13:33, François Lacombe a écrit : > Bonjour Marc, > > Je suis d'accord avec Yves ici > Ce n'est pas parce qu'un objet ne porte qu'une référence, qu'on ne peut > pas associer des règles de validation ou de formatage particulières sur > celle-ci. > Plus que les tags de l'objet et le contexte d'utilisation de ref=*, il > faut une clé dédiée à laquelle on associe une doc complète et des règles > dans les éditeurs. > > Même si certaines fois l'exploitant est repris dans le nom de la ref > (ref:FR:Orange par exemple), ce n'est pas le but de déterminer l'exploitant > avec la ref; > Nous n'avons pas le droit de reprendre systématiquement le nom du > référentiel à cause de la propriété intellectuelle, donc on utilise la > marque à la place qui correspond au nom de l'exploitant. > > Je serai bien embêté si il fallait exprimer sur la même page les règles > pour ref:FR:gdo et ref:FR:FINESS. Ce n'est pas du tout la même chose, ce > serait éminemment plus complexe à valider aussi. > > Voir aussi les objets qui portent plusieurs ref : ref:FR:ARCEP + > ref:FR:Orange (avoir ref + ref:FR:Orange n'a pas plus de sens que > ref:FR:ARCEP + ref) > > On utilise enfin les namespaces parce que ces règles, concepts et > référentiels sont spécifiques à la France et peuvent collisionner ailleurs > dans le monde. > > Le mar. 7 janv. 2020 à 16:20, marc marc a > écrit : > >> Bonjour, >> >> Le 07.01.20 à 16:01, Quentin Salles a écrit : >> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien >> actif ? >> >> Nous n'avions pas terminé la discussion sur la migration. >> Je te conseille d'utiliser l'ancienne clef en attendant, puisque >> c'est elle qui est la façon de faire actuellement. >> > > Je n'ai pas fait la migration, pour l'ancienne clé reste valable. > Y a-t-il d'autres points à discuter ? > > >> je vais faire une comparaison avec les routes : >> en lisant une référence sur le panneau d'une route, cette référence >> se retranscrit dans la clef ref=numéro et ceci indépendamment de >> l'opérateur ou du pays. >> > > Parce qu'on traduit avant tout ce qu'on lit sur le terrain sans chercher à > la rapprocher d'un référentiel quelconque. > > >> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur >> pour préciser qui serrait l'auteur de la ref. >> on n'utilise pas non plus de mot dans la clef pour donner le sens de >> cette référence ou le terme légal que celui-ci aurait dans la loi. >> > > Et on pourrait, mais le domaine routier n'est pas le meilleur pour > produire des référentiel, je ne connais pas le nom de la base de données > qui attribue les numéros de routes. > > >> A l'inverse, dans le domaine énergétique (et des transports), au fil >> du temps, on utilise des espaces de nom pour la clef ref en France, >> sans que je perçoive ni le besoin ni même l'intérêt. >> >> Au final l'utilisateur qui lit une ref quelque part, ne peux pas >> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle >> particulière qui régit cet objet dans ce pays. >> > > C'est nécessaire parce qu'on a besoin de formater cette valeur par rapport > à ce qui est lu sur le terrain : infos incohérentes, valeurs partiellement > effacées, techniciens fatigués... > > >> cela nuit à mon avis grandement à l'encodage simple et même à >> l'utilisation (essayez donc de connaître le nombre de power=substation >> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit >> que cela peux être ref ou ref:* chose que de nombreux outil tel que >> tainfo ou overpass ne permettent pas ou pas facilement) >> >> > Est-il possible de remonter l'information >> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non >> > visibles sur le terrain ? >> >> bien sur, osmose ne propose rien sur le sujet ? >> https://osmose.openstreetmap.fr/fr/map/ > > > Pas encore mais la migration va être l'occasion d'ajouter de la validation > dans JOSM et Osmose quand j'aurais le temps de m'en occuper. > * substation=minor_distribution + operator=Enedis + ref=* => Alerte, il > manque ref:FR:gdo > * operator!=Enedis;GRDF + ref:FR:gdo => Alerte, ce n'est pas possible > > Et ainsi de suite > > François > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki
Salut à tous D'accord avec Marc, je souhaite aussi avoir une liste des cas qu'on a traité. Non pas pour les réciter toutes les semaines mais aussi pour bien avoir à l'esprit que c'est un travail permanent. Le problème des évolutions de ces sites et le suivi des échanges passés (l'attitude adoptée par l'équipe à ce moment là, etc...) est important. Ok pour réorganiser la page, moins pour supprimer les cas rencontrés donc Bonne soirée François Le mer. 15 janv. 2020 à 18:54, Cyrille37 OSM a écrit : > Merci Marc, j'entends ton argument. > > Cyrille. > > ps: you win ! :D > > Le 15/01/2020 à 18:22, marc marc a écrit : > > Hello, > > > > Le but est de pouvoir répondre différemment à celui qui commet > > une erreur <> l'entreprise bricole la prod sous la pression > > mais perd l'info à chaque maj parce que pas remonté comme il faut. > > > > ceci dit je suis tout a fait d'accord pour un droit à l'oubli. > > mais pas avec un délai "instantané". > > Il y des infos à ce sujet dans une loi ou une jurisprudence ? > > Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe. > > > > Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord. > > on ne vise pas l'humain qui était affecté à la tâche, > > on vise le site. la fréquence de changement des gars qui s'en occupent, > > cela peux se comprendre comme "raison" mais cela ne nous regardent pas > > et cela ne doit sûrement pas être accepté comme excuse pour justifier > > un problème récurent, si cela se produit. > > > > Cordialement, > > Marc > > > > Le 15.01.20 à 18:11, Cyrille37 OSM a écrit : > >> Hello > >> > >> Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en > >> conformité, l'affaire est terminée. Si un jour le même site pose à > >> nouveau problème c'est une autre "histoire", non ? > >> > >> À mon avis un site qui se retrouve à nouveau en défaut d'attribution un > >> an après, n'est pas le même site: c'est une nouvelle version, une > >> nouvelle équipe, ou un nouveau je ne sais quoi. > >> > >> Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même > >> en justice, qui selon la gravité oublie les fautes, de façon que si tu > >> refais une faute après un certain délai on ne te reprochera pas les > >> fautes précédentes puisqu'elles sont oubliées. > >> > >> Dit encore autrement, je n'aime pas conserver des infos qui me > >> permettrai d'accumuler des reproches pour le prochain désaccord. ;-) > >> > >> Cyrille. > >> > >> Le 14/01/2020 à 13:26, marc marc a écrit : > >>> Le 14.01.20 à 12:14, Cyrille37 OSM a écrit : > il me semble qu'il serait plus "poli / respectueux" > de supprimer les cas résolus > >>> Il ne faut en effet pas les garder comme "à problème" > >>> > >>> Mais les effacer pose le soucis de l'historique, càd le manque > >>> de possibilité de recherche : > >>> regarde le dernier site ajouté, c'est "ajout site". > >>> si celui-ci est supprimé avec comme résumé "suppression site", > >>> tu n'as aucun moyen de retrouver son existence hormis regardant chaque > >>> modif. > >>> > >>> Je verrais bien une page d'archive, un peu comme cela se fait avec les > >>> pages de proposition. le contenu passé est caché derrière un clic. > >>> je me demande même si cela ne disparait pas aussi du moteur de > recherche > >>> (à vérifier). mais cela permet au moins de se rendre sur la page > >>> d'archive, avoir la date de l'incident, la date de résolution. bref > >>> savoir si besoin au lieu de réécrire l'histoire. > >>> ___ > >>> 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 > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Les Data Items : discussion en cours
Salut à tous, Nous avions survolé le sujet au précédent SOTM, notamment lors de la présentation de JOSM par Vincent ( https://peertube.openstreetmap.fr/videos/watch/adbeec6c-a3cc-406b-8f0b-4c50990dedc3 à 49:20) Une discussion supplémentaire a été lancée sur le wiki pour proposer la généralisation des "DataItems" pour décrire les tags (en anglais) https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information Ca va demander encore beaucoup de temps de se pencher sur la question et de répondre à toutes les critiques. Comme je l'ai écris à l'instant à la suite des autres contributions, je suis sur surpris de la levée de bouclier que cela suscite. Un énorme travail a déjà été fait par plusieurs membre pour l'intégrer et proposer déjà des premières connexions. Mais à court terme et à juste titre il reste des point d'expérience utilisateur à régler avant que le système soit pleinement utilisable. D'autres arguments sont levés et je ne comprends pas : le wiki code sur 126 traductions toutes non à jour pour la même clé c'est mieux qu'un item centralisé à l'image de wikidata. Il faut savoir garder son calme. On ne va pas refaire le match ici, contribuez directement sur le wiki si vous maîtrisez l'anglais et que vous voulez ajouter quelque chose (sinon il n'y a rien d'autre à faire qu'attendre) Pour avoir relevé dans une bien moindre mesure ce genre de défis précédemment, je me dit que finalement le problème n'est pas technique, il est avant tout humain. Comme d'habitude on soulignera les contributions positives sur le trac de JOSM où des solutions sont recherchées pour produire les presets et maintenir à jour les traductions. Merci à eux https://josm.openstreetmap.de/ticket/17842 Soyez sûr qu'on sera plusieurs à parler du sujet au prochain SOTM-fr Bonne soirée François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki
Merci Marc, j'entends ton argument. Cyrille. ps: you win ! :D Le 15/01/2020 à 18:22, marc marc a écrit : Hello, Le but est de pouvoir répondre différemment à celui qui commet une erreur <> l'entreprise bricole la prod sous la pression mais perd l'info à chaque maj parce que pas remonté comme il faut. ceci dit je suis tout a fait d'accord pour un droit à l'oubli. mais pas avec un délai "instantané". Il y des infos à ce sujet dans une loi ou une jurisprudence ? Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe. Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord. on ne vise pas l'humain qui était affecté à la tâche, on vise le site. la fréquence de changement des gars qui s'en occupent, cela peux se comprendre comme "raison" mais cela ne nous regardent pas et cela ne doit sûrement pas être accepté comme excuse pour justifier un problème récurent, si cela se produit. Cordialement, Marc Le 15.01.20 à 18:11, Cyrille37 OSM a écrit : Hello Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en conformité, l'affaire est terminée. Si un jour le même site pose à nouveau problème c'est une autre "histoire", non ? À mon avis un site qui se retrouve à nouveau en défaut d'attribution un an après, n'est pas le même site: c'est une nouvelle version, une nouvelle équipe, ou un nouveau je ne sais quoi. Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même en justice, qui selon la gravité oublie les fautes, de façon que si tu refais une faute après un certain délai on ne te reprochera pas les fautes précédentes puisqu'elles sont oubliées. Dit encore autrement, je n'aime pas conserver des infos qui me permettrai d'accumuler des reproches pour le prochain désaccord. ;-) Cyrille. Le 14/01/2020 à 13:26, marc marc a écrit : Le 14.01.20 à 12:14, Cyrille37 OSM a écrit : il me semble qu'il serait plus "poli / respectueux" de supprimer les cas résolus Il ne faut en effet pas les garder comme "à problème" Mais les effacer pose le soucis de l'historique, càd le manque de possibilité de recherche : regarde le dernier site ajouté, c'est "ajout site". si celui-ci est supprimé avec comme résumé "suppression site", tu n'as aucun moyen de retrouver son existence hormis regardant chaque modif. Je verrais bien une page d'archive, un peu comme cela se fait avec les pages de proposition. le contenu passé est caché derrière un clic. je me demande même si cela ne disparait pas aussi du moteur de recherche (à vérifier). mais cela permet au moins de se rendre sur la page d'archive, avoir la date de l'incident, la date de résolution. bref savoir si besoin au lieu de réécrire l'histoire. ___ 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] Manque d'attribution, supprimer les cas résolus - wiki
Hello, Le but est de pouvoir répondre différemment à celui qui commet une erreur <> l'entreprise bricole la prod sous la pression mais perd l'info à chaque maj parce que pas remonté comme il faut. ceci dit je suis tout a fait d'accord pour un droit à l'oubli. mais pas avec un délai "instantané". Il y des infos à ce sujet dans une loi ou une jurisprudence ? Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe. Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord. on ne vise pas l'humain qui était affecté à la tâche, on vise le site. la fréquence de changement des gars qui s'en occupent, cela peux se comprendre comme "raison" mais cela ne nous regardent pas et cela ne doit sûrement pas être accepté comme excuse pour justifier un problème récurent, si cela se produit. Cordialement, Marc Le 15.01.20 à 18:11, Cyrille37 OSM a écrit : > Hello > > Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en > conformité, l'affaire est terminée. Si un jour le même site pose à > nouveau problème c'est une autre "histoire", non ? > > À mon avis un site qui se retrouve à nouveau en défaut d'attribution un > an après, n'est pas le même site: c'est une nouvelle version, une > nouvelle équipe, ou un nouveau je ne sais quoi. > > Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même > en justice, qui selon la gravité oublie les fautes, de façon que si tu > refais une faute après un certain délai on ne te reprochera pas les > fautes précédentes puisqu'elles sont oubliées. > > Dit encore autrement, je n'aime pas conserver des infos qui me > permettrai d'accumuler des reproches pour le prochain désaccord. ;-) > > Cyrille. > > Le 14/01/2020 à 13:26, marc marc a écrit : >> Le 14.01.20 à 12:14, Cyrille37 OSM a écrit : >>> il me semble qu'il serait plus "poli / respectueux" >>> de supprimer les cas résolus >> Il ne faut en effet pas les garder comme "à problème" >> >> Mais les effacer pose le soucis de l'historique, càd le manque >> de possibilité de recherche : >> regarde le dernier site ajouté, c'est "ajout site". >> si celui-ci est supprimé avec comme résumé "suppression site", >> tu n'as aucun moyen de retrouver son existence hormis regardant chaque >> modif. >> >> Je verrais bien une page d'archive, un peu comme cela se fait avec les >> pages de proposition. le contenu passé est caché derrière un clic. >> je me demande même si cela ne disparait pas aussi du moteur de recherche >> (à vérifier). mais cela permet au moins de se rendre sur la page >> d'archive, avoir la date de l'incident, la date de résolution. bref >> savoir si besoin au lieu de réécrire l'histoire. >> ___ >> 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] Manque d'attribution, supprimer les cas résolus - wiki
Hello Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en conformité, l'affaire est terminée. Si un jour le même site pose à nouveau problème c'est une autre "histoire", non ? À mon avis un site qui se retrouve à nouveau en défaut d'attribution un an après, n'est pas le même site: c'est une nouvelle version, une nouvelle équipe, ou un nouveau je ne sais quoi. Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même en justice, qui selon la gravité oublie les fautes, de façon que si tu refais une faute après un certain délai on ne te reprochera pas les fautes précédentes puisqu'elles sont oubliées. Dit encore autrement, je n'aime pas conserver des infos qui me permettrai d'accumuler des reproches pour le prochain désaccord. ;-) Cyrille. Le 14/01/2020 à 13:26, marc marc a écrit : Le 14.01.20 à 12:14, Cyrille37 OSM a écrit : il me semble qu'il serait plus "poli / respectueux" de supprimer les cas résolus Il ne faut en effet pas les garder comme "à problème" Mais les effacer pose le soucis de l'historique, càd le manque de possibilité de recherche : regarde le dernier site ajouté, c'est "ajout site". si celui-ci est supprimé avec comme résumé "suppression site", tu n'as aucun moyen de retrouver son existence hormis regardant chaque modif. Je verrais bien une page d'archive, un peu comme cela se fait avec les pages de proposition. le contenu passé est caché derrière un clic. je me demande même si cela ne disparait pas aussi du moteur de recherche (à vérifier). mais cela permet au moins de se rendre sur la page d'archive, avoir la date de l'incident, la date de résolution. bref savoir si besoin au lieu de réécrire l'histoire. ___ 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] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?
Le 15.01.2020 16:49, marc marc a écrit : Le 15.01.20 à 16:28, Cédric Frayssinet a écrit : Bonjour à tous et notamment aux techs :) j'ai ajouté la ml tech :) Je voulais présenter le live à mes élèves aujourd'hui mais cela semble casser. Ce matin, c'était très lent, actuellement, il ne fonctionne pas. https://live.openstreetmap.fr/ il y a du lag dans la generation des diffs dans l'infra osm-fr http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html qui semble caussé par le traitement des modifs des relations communales. Je comprends mieux pourquoi le rendu osm était lent à m'afficher mes modifs :) De mémoire, live utilise les diffs depuis le serveur ci-dessus. Jocelyn avait prévu un moyen de les contourner en cas de lag Je le prévient. tu veux encore présenter aujourd'hui ? si oui j’irai voir sur le serveur si Jocelyn n'est pas dispo Merci pour ta réponse. Non, pas besoin aujourd'hui, cela peut attendre vendredi 11h15 ;) Cédric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Talk-fr mailing list bounce policy
On Sun, 29 Dec 2019, Tom Hughes wrote: > This is a matter for the talk-fr admin - they need to change the > list settings (the from_is_list setting) to munge the from addresses > of senders with a hard DMARC policy or the resulting bounces caused > by the list forwarding to gmail and other sites that enforce DMARC > policies will cause those recipients to be unsubscribed. Who is "the talk-fr admin"? How can I contact him? The page below says the talk-fr list is managed by talk-fr-owner at openstreetmap.org so I sent an email to that address but I did not hear back and I'm still regularly getting kicked out (last time was last thursday). https://lists.openstreetmap.org/admin/talk-fr The "Admins" column is empty for the "talk-fr" line on the page below: https://wiki.openstreetmap.org/wiki/Mailing_lists And the page below provides no way to contact administrator of specific lists: https://lists.openstreetmap.org/admin The only address it provides is mail...@openstreetmap.org but as far as I can tell that's not who I should contact. So how can I get this to move forward? -- Francois Gouget http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Live HS - lié au lag de osm108 ? lui même lié aux modifs de nombreuses relations communales ?
Le 15.01.20 à 16:28, Cédric Frayssinet a écrit : > > Bonjour à tous et notamment aux techs :) j'ai ajouté la ml tech :) > Je voulais présenter le live à mes élèves aujourd'hui mais cela semble > casser. Ce matin, c'était très lent, actuellement, il ne fonctionne pas. > > https://live.openstreetmap.fr/ il y a du lag dans la generation des diffs dans l'infra osm-fr http://munin.openstreetmap.fr/osm12.openstreetmap.fr/osm108.openstreetmap.fr/osm_replication_lag_osmbin.html qui semble caussé par le traitement des modifs des relations communales. De mémoire, live utilise les diffs depuis le serveur ci-dessus. Jocelyn avait prévu un moyen de les contourner en cas de lag Je le prévient. tu veux encore présenter aujourd'hui ? si oui j’irai voir sur le serveur si Jocelyn n'est pas dispo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Live HS
Bonjour à tous et notamment aux techs :) Je voulais présenter le live à mes élèves aujourd'hui mais cela semble casser. Ce matin, c'était très lent, actuellement, il ne fonctionne pas. https://live.openstreetmap.fr/ Merci d'avance, Cédric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
plutôt d’accord avec source et date sur l’objet et pas sur le changeset. Quand je consulte ou utilise Osm, c’est l’objet que je regarde, pas le changeset, à vrai dire je n’en ai rien à fiche (pour rester poli). Il me semble que la connaissance du changeset ne sert et n’est utile qu’aux « gouroux » d’osm et pas à un utilisateur lambda… ;-) sauf si l’attribution d’une source à un changeset est reportée comme source sur l’objet, dans ce cas je n’ai rien dit… > Le 15 janv. 2020 à 10:10, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT > GE PPE) a écrit : > > -Message d'origine- > De : marc marc > Envoyé : mercredi 15 janvier 2020 09:43 > À : talk-fr@openstreetmap.org > Objet : Re: [OSM-talk-fr] Proposition de mise à jour : la population des > communes > > >> ce n'est pas parce que la méthode insee date de l'époque "que par papier" >> que d'autres ne font pas mieux (je connais une commune qui a publié le jour >> même le passage au millier supérieur). >> oui oui p_v c'est impossible mais elle l'a fait. > > Ce sera un chiffre sur lequel elle ne pourra pas s'appuyer que le calcul de > la Dotation Globale de Fonctionnement, par exemple. > Voir https://fr.wikipedia.org/wiki/Recensement_de_la_population_en_France > >> ta crainte est tout a fait justifiée, >> l'utilisateur lambda change le tag population sans autre :( > >> solution : se limiter à source=insee et sur le changeset uniquement :) ainsi >> c'est clair que si t'as changé la valeur de la population en 2010 avec >> source=insee, c'est que t'as utilisé l'info de l'insee la + à jour dispo à >> cette date et peu importe que l'insee ai mis 1 jour ou une décénie a publier. >> C'est ce qu'on fait quand on met source=imagery imagery_used=BDOrtho : >> on a utilisé l'imagerie la + récente sans se prendre la tête manuellement à >> aller chercher la date de l'image qu'on voit (mais qui serrait très pratique >> a récupérer automatiquement, mais ca c'est un autre sujet). >> après je suis pas contre si quelqu'un met sur le changeset de mis >> source=insee >> population:date=2017 >> source:date=2020 >> mais sur les objets, comme dit avant, de toute façon le contributeur lamba >> changera la valeur de l'un sans changer l'autre, c'est peine perdue et >> erroné de se fier aux source=* sur les objets. > > Pour ma part, je suis partisan de mettre les sources et les dates des source > sur les objets (sur les changesets c'est un plus et utile quand ce sont des > éditions en masse mono-sujet) > Donc, sur la relation de la commune : > population:date=2017 > source : Institut National de la Statistique et des Études Économiques > (INSEE) français > source:date : 2020 > Après rien n'empêche de mettre d'autres renseignements en notes ou d'autres > tags plus exotiques (une pop estimée, un comptage au doigt mouillé, etc.) > >> je ne comprend pas en quoi la commune n'est pas légitime vu que ce sont les >> infos de la commune que d'autres vont récupérer. >> c'est un peu comme dire qu'on ne devrait pas modifier un bâtiment dans osm >> tant que le cadastre n'a pas fait la maj légale. >> Je partage à 100% l'idée d'uniformiser tous le pays avec la source légal >> dispo en opendata. mais si quelqu'un a une source de meilleur qualité >> et tout aussi ouverte, ne nous gênons pas à faire mieux que le légal. > > Différence entre légal et "autres", il faut juste se mettre d'accord si > population=population légale > Pourquoi pas : alt:population= municipales> > > Denis > --- > Ce message et toutes les pièces jointes sont établis à l'intention exclusive > de ses destinataires et sont confidentiels. L'intégrité de ce message n'étant > pas assurée sur Internet, la SNCF ne peut être tenue responsable des > altérations qui pourraient se produire sur son contenu. Toute publication, > utilisation, reproduction, ou diffusion, même partielle, non autorisée > préalablement par la SNCF, est strictement interdite. Si vous n'êtes pas le > destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et > de le détruire. > --- > This message and any attachments are intended solely for the addressees and > are confidential. SNCF may not be held responsible for their contents whose > accuracy and completeness cannot be guaranteed over the Internet. > Unauthorized use, disclosure, distribution, copying, or any part thereof is > strictly prohibited. If you are not the intended recipient of this message, > please notify the sender immediately and delete it. > ___ > 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] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun
Le 21/12/2019 à 22:29, deuzeffe a écrit : Le 18/12/2019 à 19:06, lenny.libre a écrit : Et comme je disais, je souhaitais ce changement de tag car d'autres réseaux l'ont fait. Certes. Je ne sais pas si c'est une bonne raison :P ??? Formulé ainsi, ça ressemble à un argument d'autorité... les arrêts de Tisséo sont en opendata et les ref:FR:Tisséo sont visibles sur les arrêts et référencés dans l'opendata les arrêts du Réseau Arc-en-Ciel sont également en opendata et les ref:FR:aec31 sont visibles sur les arrêts et référencés dans l'opendata. Sur les arrêts commun, on peut lire les n° de l'arrêt pour les deux réseaux ; comme dit plus haut dans la liste sur le nœud platform il peut donc y avoir ref:FR:Tisséo=6745 + ref:FR:aec31=61040 Tu veux faire quoi ? ne pas faire comme les autres réseaux et ref=6745;61040 et on a la perte des liens avec les opendata Pas réussi à trouver la page qui liste les ref:FR:xxx concernant les réseaux de transport. J'ai seulement trouvé celle des références nationales (dans laquelle on trouve ref:FR:RATP d'ailleurs :///) moi non plus ... Ce qui m'amène à une question de béotienne (éternelle) mais plus générale : doit-on (ou jusqu'où doit-on) préciser/affiner les ref:FR pour les réseaux de transport ? Pour réanimer https://wiki.openstreetmap.org/wiki/France/WikiProject_Base_Arrets_Transports_Ouverte_(BATO) par exemple. Ou pas. (tant que je t'ai sous la souris : c'est moi ou cette page https://wiki.openstreetmap.org/wiki/France/Liste_des_transports_en_communs_en_France est en vrac quant à ses sections ou sous-sections ?) Peux-tu préciser ? leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
-Message d'origine- De : marc marc Envoyé : mercredi 15 janvier 2020 09:43 À : talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes >ce n'est pas parce que la méthode insee date de l'époque "que par papier" que >d'autres ne font pas mieux (je connais une commune qui a publié le jour même >le passage au millier supérieur). >oui oui p_v c'est impossible mais elle l'a fait. Ce sera un chiffre sur lequel elle ne pourra pas s'appuyer que le calcul de la Dotation Globale de Fonctionnement, par exemple. Voir https://fr.wikipedia.org/wiki/Recensement_de_la_population_en_France >ta crainte est tout a fait justifiée, >l'utilisateur lambda change le tag population sans autre :( >solution : se limiter à source=insee et sur le changeset uniquement :) ainsi >c'est clair que si t'as changé la valeur de la population en 2010 avec >source=insee, c'est que t'as utilisé l'info de l'insee la + à jour dispo à >cette date et peu importe que l'insee ai mis 1 jour ou une décénie a publier. >C'est ce qu'on fait quand on met source=imagery imagery_used=BDOrtho : >on a utilisé l'imagerie la + récente sans se prendre la tête manuellement à >aller chercher la date de l'image qu'on voit (mais qui serrait très pratique a >récupérer automatiquement, mais ca c'est un autre sujet). >après je suis pas contre si quelqu'un met sur le changeset de mis source=insee >population:date=2017 >source:date=2020 >mais sur les objets, comme dit avant, de toute façon le contributeur lamba >changera la valeur de l'un sans changer l'autre, c'est peine perdue et erroné >de se fier aux source=* sur les objets. Pour ma part, je suis partisan de mettre les sources et les dates des source sur les objets (sur les changesets c'est un plus et utile quand ce sont des éditions en masse mono-sujet) Donc, sur la relation de la commune : population:date=2017 source : Institut National de la Statistique et des Études Économiques (INSEE) français source:date : 2020 Après rien n'empêche de mettre d'autres renseignements en notes ou d'autres tags plus exotiques (une pop estimée, un comptage au doigt mouillé, etc.) >je ne comprend pas en quoi la commune n'est pas légitime vu que ce sont les >infos de la commune que d'autres vont récupérer. >c'est un peu comme dire qu'on ne devrait pas modifier un bâtiment dans osm >tant que le cadastre n'a pas fait la maj légale. >Je partage à 100% l'idée d'uniformiser tous le pays avec la source légal dispo >en opendata. mais si quelqu'un a une source de meilleur qualité >et tout aussi ouverte, ne nous gênons pas à faire mieux que le légal. Différence entre légal et "autres", il faut juste se mettre d'accord si population=population légale Pourquoi pas : alt:population= Denis --- Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas assurée sur Internet, la SNCF ne peut être tenue responsable des altérations qui pourraient se produire sur son contenu. Toute publication, utilisation, reproduction, ou diffusion, même partielle, non autorisée préalablement par la SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et de le détruire. --- This message and any attachments are intended solely for the addressees and are confidential. SNCF may not be held responsible for their contents whose accuracy and completeness cannot be guaranteed over the Internet. Unauthorized use, disclosure, distribution, copying, or any part thereof is strictly prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete it. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
Le 14.01.20 à 21:54, DH a écrit : > La population 2017 ne peut pas être connue méthodologiquement avant 2020. ce n'est pas parce que la méthode insee date de l'époque "que par papier" que d'autres ne font pas mieux (je connais une commune qui a publié le jour même le passage au millier supérieur). oui oui p_v c'est impossible mais elle l'a fait. > J'ai simplement la crainte que l'utilisateur lamba, sans chercher > à comprendre le pourquoi du comment, assume source:date=2020 <=> > population 2020 ce qui est bien évidemment faux. > Une note méthodologique ? sur le wiki ? ta crainte est tout a fait justifiée, l'utilisateur lambda change le tag population sans autre :( solution : se limiter à source=insee et sur le changeset uniquement :) ainsi c'est clair que si t'as changé la valeur de la population en 2010 avec source=insee, c'est que t'as utilisé l'info de l'insee la + à jour dispo à cette date et peu importe que l'insee ai mis 1 jour ou une décénie a publier. C'est ce qu'on fait quand on met source=imagery imagery_used=BDOrtho : on a utilisé l'imagerie la + récente sans se prendre la tête manuellement à aller chercher la date de l'image qu'on voit (mais qui serrait très pratique a récupérer automatiquement, mais ca c'est un autre sujet). après je suis pas contre si quelqu'un met sur le changeset de mis source=insee population:date=2017 source:date=2020 mais sur les objets, comme dit avant, de toute façon le contributeur lamba changera la valeur de l'un sans changer l'autre, c'est peine perdue et erroné de se fier aux source=* sur les objets. > note : autant la commune est légitime comme source sur la toponymie, > autant sur la population c'est l'INSEE la source légitime et légale. je ne comprend pas en quoi la commune n'est pas légitime vu que ce sont les infos de la commune que d'autres vont récupérer. c'est un peu comme dire qu'on ne devrait pas modifier un bâtiment dans osm tant que le cadastre n'a pas fait la maj légale. Je partage à 100% l'idée d'uniformiser tous le pays avec la source légal dispo en opendata. mais si quelqu'un a une source de meilleur qualité et tout aussi ouverte, ne nous gênons pas à faire mieux que le légal. Cordialement, Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes
Le 14/01/2020 à 22:09, DH a écrit : Le 14/01/2020 à 21:22, marc marc a écrit : oui et non. oui il y a bien 2 dates (récolte des données <> publication). non il ne me semble pas qu'il y ai 2 dates valide pour la source au sens osm. Quand je met une info dans osm et que j'ai le choix entre 2 sources, je vais prendre celle qui a les infos les + fraîche, cad celle dont la réalité "sur place" a une date la + fraîche. il me semble donc que la date de publication a peu d'intérêt pour osm, c'est la date "sur place" qui importe, ici 2017 en l’occurrence concrètement il y a des contributeurs (comme moi) qui mettent parfois à jour la population de la commune avec une source + fraîche (la commune elle-même). ils vont mettre source:date=2019 et se faire écraser par une valeur publiée en 2020 mais + veille. Je suis presque d'accord sur le raisonnement. La population 2017 ne peut pas être connue méthodologiquement avant 2020. J'ai simplement la crainte que l'utilisateur lamba, sans chercher à comprendre le pourquoi du comment, assume source:date=2020 <=> population 2020 ce qui est bien évidemment faux. C'était tout à fait le sens de ma question. Car comment fallait-il entendre "source:population = INSEE 2013" : entre 2013 et 2017 ou entre 2013 et 2020 ? Il faut se souvenir que sur osm il n'y a pas que des spécialistes; il y beaucoup plus de lamba Une note méthodologique ? sur le wiki ? note : autant la commune est légitime comme source sur la toponymie, autant sur la population c'est l'INSEE la source légitime et légale. "source:date" c'est pas une course à l'échalote pour être up to date; il faut que cela ait du sens aussi, non ? Denis ___ 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
