Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Une partie (à priori) des données d'AED Map sont publiées sur data.gouv : https://www.data.gouv.fr/fr/datasets/defibrillateurs-publics/ Cela ne concerne que ceux déclarés par les collectivités, donc pas la partie contribution bénévole. Une fusion de ces jeux de données en août 2019 par Christian laissait ressortir 900 DAE de cette base. Je ne sais pas dans quelle mesure ils ont été contactés pour diffuser les données créées par les bénévoles. Cordialement, Adrien P. Le 04/08/2020 à 23:51, Francois Gouget a écrit : Quelqu'un sait-il sur quelle base de donnée s'appuie l'application Staying Alive ? Et surtout quelle est la license de cette base de donnée de défibillateurs ? Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur le site de AEDMap rien de bien précis : https://aedmap.org/ J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le travail de bénévoles. Mais leur coeur de métier ne semble pas être cette base de donnée mais plutôt la maintenance de défibrillateurs. Bon indépendamment de ça j'ai décidé de prendre un peu d'avance et j'ai ajouté un défibrillateur à Montparnasse. Un modèle solaire que je n'avais jamais vu avant et qui serait opéré par la Ville de Paris (3ème photo) : https://www.paris.fr/pages/mille-defibrillateurs-prevus-a-paris-d-ici-cinq-ans-4567 Et la carte dépassée et illisible des mille^H^H^H ~100 défibrillateurs de cette initiative : http://labs.paris.fr/commun/pdf/carte_33_sites.pdf Tiens, ça fait penser au xkcd d'aujourd'hui https://xkcd.com/2341/ ___ 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] Pourquoi inventer un aire urbaine imaginaire ?
Je me suis mal exprimé
L'analyse Osmose serait pour les point d'entrée de ville. Pas pour les way qui
ne respecte pas les admin_level existant
Si ça peut permettre de placer les panneaux d'entrée/sortie de commune ce
serait pas mal (et autres infos placée au même endroit)
Le August 4, 2020 7:13:56 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
> > Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette
>anomalie vers Osmose pour ajouter un nouveau contrôle ?
>
>Peut-être parce que la seule possibilité c'est de supprimer cette
>infox.
>
>Sur les 4639 points ajoutés par notre ami, approximativement 703 sont
>sur des highway (703 routes passent par ces points).
>
>Concernant 4 000 points environ : on a l'information que le
>contributeur
>a estimé que la limite urbaine c'était par là (au vue d'une imagerie
>_aérienne_ comme si les limites correspondaient forcément !).
>
>Absolument pas parce qu'il y a un panneau là.
>
>Donc tu fais quoi ? Tu regardes une imagerie de rue pour voir s'il y a
>un panneau dans le coin ?
>
>Non, supprimer ces 4 000 points c'est hélas la bonne solution.
>
>À ne pas confondre avec le cas de Florian (il a vu le panneau et a mis
>la limite non au niveau de la route mais au niveau du panneau, il peut
>mettre à jour sans problème).
>
>Jean-Yvon
>
>
>Le 04/08/2020 à 07:28, Gad Jo - perche...@toutenkamion.net a écrit :
>>
>>
>> Je suis sûr que d'autre contributeur en ont créé de la même façon et
>> qu'il pourraient bénéficier de ce type de correction.
>> Au passage ça évite les suppression accidentelle de nœud où d'autres
>> tag seraient ajoutés (honnêtement ça m'étonnerait mais autant
>prévoir).
>>
>> Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT
>> a écrit :
>>
>> Je viens d'envoyer un message par la messagerie interne
>d'osm.org.
>> J'attends donc encore un peu avant de passer au
>> traffic_sign=city_limit.
>>
>> Romain
>>
>>> De : Christian Quest
>>> À : talk-fr@openstreetmap.org
>>> Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un
>>> aire urbaine imaginaire ?
>>> Date : 03/08/2020 09:00:10 Europe/Paris
>>>
>>> Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
>>> > Les hésitations ont trop duré, c'est souvent le problème dans
>>> OSM, on
>>> > n'ose pas toujours pour ne pas froisser des susceptibilités.
>Je
>>> n'ai
>>> > rien contre le tag boundary=urban, c'est juste que dans le cas
>>> > présent, son emploi s'est fait sans tenir compte des données
>déjà
>>> > présentes...
>>> >
>>> > Romain
>>> >
>>> Pour ça que la première chose à faire est de prendre contact
>avec le
>>> contributeur avant de faire la modification massive, surtout
>>> quand c'est
>>> un régulier comme ici.
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> --
>> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>> brièveté.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
On Tue, 4 Aug 2020, PanierAvide wrote: [...] > Il y a quelques semaines, la Direction Générale de la Santé a publié sa > base GéoDAE (en cours de constitution), qui recense les défibrillateurs > du pays. [...] > En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. > Évidemment les deux bases ne se recoupent pas, certains DAE sont > présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. Quelqu'un sait-il sur quelle base de donnée s'appuie l'application Staying Alive ? Et surtout quelle est la license de cette base de donnée de défibillateurs ? Sur https://www.stayingalive.org/ je vois "Powered by AEDMap". Mais sur le site de AEDMap rien de bien précis : https://aedmap.org/ J'ai l'impression qu'il s'agit d'une base propriétaire construite sur le travail de bénévoles. Mais leur coeur de métier ne semble pas être cette base de donnée mais plutôt la maintenance de défibrillateurs. Bon indépendamment de ça j'ai décidé de prendre un peu d'avance et j'ai ajouté un défibrillateur à Montparnasse. Un modèle solaire que je n'avais jamais vu avant et qui serait opéré par la Ville de Paris (3ème photo) : https://www.paris.fr/pages/mille-defibrillateurs-prevus-a-paris-d-ici-cinq-ans-4567 Et la carte dépassée et illisible des mille^H^H^H ~100 défibrillateurs de cette initiative : http://labs.paris.fr/commun/pdf/carte_33_sites.pdf Tiens, ça fait penser au xkcd d'aujourd'hui https://xkcd.com/2341/ -- Francois Gouget http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Aire du viaduc de Millau
Bonsoir, En rentrant de Clermont-Ferrand pour aller vers le sud avec une halte à l'aire du viaduc de Millau j'ai eu droit à une belle erreur de routage. J'étais invité à descendre 15km plus au sud en ignorant l'aire pour remonter vers le nord et rejoindre l'aire Après simulation avec Osmand, il s'avère que l'aire est en fait composé de deux aires de repos. Les véhicules ne peuvent pas changer d'aire (portail visible à fort zoom) mais les piétons peuvent le faire pour admirer le point de vue. Dans les fait, l'intitulé de l'aire sélectionne celle dans le sens sud-nord. Pour l'autre sens il ne faut pas sélectionner l'aire du viaduc de Millau mais placer l'étape dans le parking existant au sud. Sachant qu'on ne tague pas pour le rendu mais que beaucoup d'utilisateur peuvent rencontrer la même erreur (j'ai pesté grave et ma chérie a sortie GoogleMaps + Waze), comment corriger cela ? Identifier deux aires ? Sur le terrain il y a qu'un seul nom mais ça à le mérite d'être compréhensible Revoir la géométrie de l'aire pour que le barycentre soit mieux placer ? Pas sûr que ça tienne sur le long ou très long terme Créer une relation ou multipolygone avec un nœud comme centre ? Cela risque de complexifier les modifications pour les nouveaux au risque que des doublons soient ajouter Là je sèche... Si vous avez des suggestions je prend PS : le bug existait l'année dernière mais j'ai accusé les applications sans regarder la carte. Cette fois ci j'avais placé un marqueur au sud de l'aire (pour le sens nord-sud) mais j'arrivai de l'autre sensm (sud-nord)... Résulta je ne m'y suis jamais arrêté à cause d'un gros détour à 5 km au nord pour revenir dans le sud Fallait savoir que l'aire était séparée en deux. De loin ça à l'aire d'une grosse aire qui n'en manque pas (de l'air) -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag Info France en panne ?
Le 04/08/2020 à 18:37, Jocelyn Jaubert a écrit : Bonjour, Le souci de nombres incorrects sur http://taginfo.openstreetmap.fr a été corrigé. Merci de reporter tout nouveau problème qui pourrait apparaitre Bonsoir, merci pour la correction http://taginfo.openstreetmap.fr/search?q=ref%3AFR est passé de 7 pages à 16, mais me donne 261 éléments et https://taginfo.openstreetmap.org/search?q=ref%3AFR%3A 254 éléments cordialement leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag Info France en panne ?
Bonjour, Le souci de nombres incorrects sur http://taginfo.openstreetmap.fr a été corrigé. Merci de reporter tout nouveau problème qui pourrait apparaitre -- Jocelyn Le 10/07/2020 à 09:41, Christian Quest a écrit : > Le 09/07/2020 à 23:36, Christian Rogel a écrit : >> Je n’ai vu nulle part d’indication sur une panne de TagInfo Fr >> inaccessible depuis 3 jours. >> Au niveau mondial, pas souci. >> >> Qui a des infos ? >> >> >> Christian R. > > Accessible pour moi, par contre, les chiffres n'ont pas l'air cohérents... > > https://taginfo.openstreetmap.fr/tags a des chiffres qui m'ont l'air > corrects, dès qu'on demande le détail, tout est à 0... > > > Issue ouverte sur: https://github.com/osm-fr/infrastructure/issues/214 > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Le 04/08/2020 à 15:32, Donat ROBAUX a écrit : Hello, Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence (et pas que pour ce projet) puisque Geo DAE est en LO donc incompatible dans le sens OSM => GeoDEA, alors que des contributeurs sont prêts à améliorer les données. Donat Cette base n'a pas de fondement contributif volontaire. 1) la loi oblige à fournir les données (mais ne prévoit pas de sanction quand on ne le fait pas) 2) seuls les "exploitants" peuvent alimenter la base, et la DGS a considéré que cela ne concernait que les propriétaires et pas ceux qui assurent la maintenance. 3) rien n'a été mis en place pour du contrôle qualité digne de ce nom*, ou alors ça ne fonctionne pas C'est pas faute d'avoir prêché la bonne parole lors de sa mise en route, d'avoir expliqué qu'il fallait aussi collecter ces données auprès des sociétés qui assurent la maintenance, car elles savent vraiment où il y a des DAE (fonctionnels) et d'avoir poussé pour qu'elle soit en ODbL car c'est un vrai commun à construire. Les propriétaires de bases existantes auraient aussi été rassurés par l'ODbL, qui oblige les utilisateurs des données à partager les améliorations et donc met un peu tout le monde au même niveau. Ceci aurait pu les convaincre de participer au commun. Je trouve que c'est malheureusement mal parti, je ne sais pas dans quelle mesure c'est rattrapable pour avoir une base de qualité et à quelle échéance, car là, de ce que j'ai vu, on a une chance sur 4 de trouver un DAE là où la base indique qu'il y en a un (et à 100m près). Les premiers utilisateurs que sont les SAMU ou pompiers risquent de s'en détourner bien vite après quelques échecs... on ne peut faire bonne impression qu'une fois, la première ;) La qualité dépend beaucoup de chaque source. Décathlon semble vraiment savoir où sont ses magasins, mais pas Gifi. Pour convaincre la DGS de notre utilité, il me semble nécessaire de commencer par un contrôle qualité de terrain sur un échantillon car l'enjeu est plus la qualité que la quantité. La quantité viendra petit à petit. Prenons quelques centaines de DAE dans leur base, autant dans OSM et on retourne les vérifier un à un. Le projet du mois pourrait prioriser l'ajout de survey:date=* et permettrait de faire le tri entre des intégrations en fauteuil et du mapping de terrain. * j'ai proposé une correction du modèle de données hier sur les codes INSEE des communes, qui étaient décrits comme à 5 chiffres... donc sans la Corse (2A/2B). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chantiers d'été pour OSM-FR ;)
Je me demande pourquoi les océans ne pourraient pas être découpés arbitrairement en cellules plus nombreuses juxtaposées en damier, pour ensuite réduire cette dépendance à une complexité de plus en plus exponentielle qu'on accroît la complexité des côtes. Ne peut-on pas envisager de limiter TOUS les polygones à une bounding-box maximale, découpée préférablement sur les limites des "quadtiles" ou limiter le nombre de noeuds qui les définit ? Avantage: une grande partie des mers serait stable, ultra simple (des carreaux, qu'on redivise seulement là où c'est nécessaire pour ne pas dépasser cette limite), sans pour autant augmenter drastiquement le nombre total de polygones pour dessiner de grande zones (comme la carte du monde). Cela devrait même être automatisé dans les éditeurs, en élaborant un nouveau type d'objet (pseudo-relation) groupant les éléments découpés dont tous les attributs sont communs (strictement aucun attribut sur ces découpes artificielles, maximisation et renforcement de l'option d'héritage pour ne plus jamais dupliquer les attributs et simplifier la collecte des découpes dans un objet collecteur). Et là je parle de la création d'un nouveau type d'objet "fragment", qui n'aura JAMAIS aucun autre attribut que la référence à l'objet parent (non-fragment) qui le référence en liste, de sorte que ces fragments sont librement réassemblables et optimisables sans jamais avoir à revoir le "tagging" porté uniquement et strictement dans l'objet principal collecteur (way fermé ou pas, ou relation multipolygone/multiline). Ces fragments n'aurait donc aucune autre propriété que leur géométrie "synthétique" découpée arbitrairement et que n'importe quel outil de dessin/rendu pourra regrouper librement avec les autres fragments par des opération purement géométriques simples (d'où des contraintes sur la géométrie des fragments: les lignes de découpe arbitraires devraient être de simples horizontales/verticales le long des "quadtiles", et on ne peut assembler les fragments que s'ils partagent un côté commun qui est sur une ligne de découpe du quadtile de niveau supérieur. Cependant on peut imaginer que cette transformation peut se faire sur le serveur de rendu sans que cela soit visible dans OSM, mais le faire dans OSM aurait l'avantage d'assurer que les découpes sont recalculées sur la base elle-même et maintenues de façon synchrone: on ne serait donc plus obligé de charger les objets entiers mais des fragments et c'est la base OSM qui s'occupe du réassemblage optimal. Au final on ne travaille alors plus au niveau global mais toujours localement sur des fragments homogènes et complets. La gestion des historiques s'en trouve simplifiée, le rendu aura mois de travail à faire. La question alors du découpage et du traitement spécial des océans est oublié: on pourra tout traiter localement sans chercher loin, les requêtes sont optimisées sur les quadtiles, on peut même avoir un rendu effaice à la demande et quasi instantané sans traitement complexe car toute la géométrie nécessaire est localisée. Et plus de problème d'accollement des tuiles rendues de façon complètement incohérente (même si là on devrait faire l'effort de mettre fin au rendu bitmap pour avoir des tuiles vectorielles partout, rendant obolètes les rendus PNG sur quelques gros serveurs surchargés et jamais à jour). Le sam. 1 août 2020 à 17:38, Christian Quest a écrit : > Le 26/07/2020 à 23:53, Christian Quest a écrit : > > Moins de trafic aussi sur les serveurs de l'asso alors c'est le moment > > des chantiers ! > > Le chantier continue avec la remise à jour des limites terre/mer et > l'occupation des sols à petite échelle... > > > Limites terre/mer : > > Les natural=coastline mises bout à bout forment d'immenses polygones qui > sont nécessaires pour avoir la mer en bleu et la terre dans une couleur > claire par défaut. > > Ces polygones sont relativement coûteux à calculer, car composés de très > nombreux noeuds. Ils sont gigantesques car couvrant des continents entiers. > > Du coup, ils sont calculés de temps en temps et mis à disposition sur > https://osmdata.openstreetmap.de/ sous une forme découpée (oui, façon > puzzle) avec une version aux géométries simplifiées adaptée aux petites > échelles. > > Les derniers fichiers shapefile dataient de janvier et ils ont été remis > à jour hier. > > Pour le rendu FR, j'en ai profité pour changer la logique car depuis > toujours, on mettait un fond bleu par défaut et on dessinait les > continents par dessus. > > Or... on calcule bien plus souvent des tuiles sur terre que sur mer, > donc autant avoir ça de moins à dessiner dans la majorité des cas même > si c'est sûrement négligeable. > > > L'occupation des sols à petite échelle : > > Pour les premiers niveaux de zoom, le rendu FR affiche l'occupation des > sols (landuse=*). Le problème ici c'est le très grand nombre de > polygones, parfois très petits et non visibles à ces échelles. > > Il y a quelques années, j'avais calculé une couche transparente
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Les licences... éternelle prise de tête pour (presque) aucune valeur ajoutée ;-) On peut peut-être les convaincre de passer sur l'Odbl, ça s'est fait pour les adresses pourquoi pas ici. Adrien P. Le 04/08/2020 à 15:32, Donat ROBAUX a écrit : Hello, Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence (et pas que pour ce projet) puisque Geo DAE est en LO donc incompatible dans le sens OSM => GeoDEA, alors que des contributeurs sont prêts à améliorer les données. Donat ___ 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] Projet du mois de septembre (en préparation) : défibrillateurs !
Hello, Ce qui m'emmerde dans tout ca, c'est surtout cette histoire de licence (et pas que pour ce projet) puisque Geo DAE est en LO donc incompatible dans le sens OSM => GeoDEA, alors que des contributeurs sont prêts à améliorer les données. Donat ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Et c'est d'autant plus intéressant de travailler avec eux maintenant, puisque la communauté peut clairement apporter la précision et qualité qui manquent actuellement dans la base officielle. Si leur base était déjà exhaustive et propre, on aurait plus grand chose à apporter ;-) J'ai l'impression que la formulation sur le wiki est assez claire pour indiquer que l'essentiel du projet du mois est à réaliser par relevé terrain (mais ça peut être modifié pour insister davantage si besoin). Et donc à discuter avec la DGS (j'ai un appel prévu demain matin) sur les aspects alimentation OSM -> GéoDAE, la licence, la possibilité d'améliorer le géocodage chez eux en amont, et une communication commune sur cette démarche. Cordialement, Adrien P. Le 04/08/2020 à 13:04, Christian Quest a écrit : A l'aide d'osmose, j'ai exploré les données de GéoDAE pour mon département fétiche, l'Yonne... et bien c'est une catastrophe. Cette base semble essentiellement géocodée, et mal géocodée. Les positions sont souvent très mauvaises, il faut absolument la re-géocoder proprement en repartant des adresses postales indiquées, même si c'est un pis allé par rapport à un lat/lon propre à l'origine. J'ai contacté par mail les gestionnaires de géodae à ce sujet et pour voir comment collaborer. Pour info, j'avais accompagné la DGS au démarrage de cette base alors que j'étais à Etalab. On est donc TRES loin d'une intégration des données GéoDAE, par contre, ça peut aider à aller effectivement sur le terrain, ce qui d'ailleurs permettrait une remontée sur la qualité auprès de la DGS. Il y a aussi un sujet annexe... celui de la licence. Aider la DGS à améliorer cette base à partir des données OSM ça impose que la base soit ensuite diffusées en ODbL... ce que j'avais recommandé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Le 04/08/2020 à 12:29, PanierAvide a écrit : Bonjour à tous, Et si on s'organisait un projet du mois en septembre, par exemple sur les défibrillateurs (DAE) ? :-) https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs # Pourquoi les défibrillateurs ? Il y a quelques semaines, la Direction Générale de la Santé a publié sa base GéoDAE (en cours de constitution), qui recense les défibrillateurs du pays. Un vaste chantier engagé depuis plusieurs mois, et qui commence à être visible par ces données. On y compte pour l'instant ~15000 défibrillateurs, dont 10% vérifiés par leur opérateur. En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. Évidemment les deux bases ne se recoupent pas, certains DAE sont présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. Alors si on s'y met en tant que communauté, on a possibilité d'obtenir une liste exhaustive sur le territoire de ces équipements ! # Quels sont les objectifs ? L'objectif principal sera de recenser le plus possible de défibrillateur sur le terrain. On pourra ainsi s'aider de la base GéoDAE via Osmose et des bases ouvertes par certaines collectivités. Mais le gros du travail va consister à arpenter les établissements pour retrouver ces équipements. Dans la mesure du possible, on renseignera les attributs annexes (localisation, opérateur, niveau...). # Comment aider à la préparation ? D'ici le début du projet en septembre, il y a quelques tâches qui restent à réaliser, si vous voulez prendre part à l'organisation c'est l'occasion ! - Vérifier / compléter la documentation sur le wiki, notamment sur les réutilisations existantes de ces données - Écrire un article pour annoncer le projet du mois sur le site OSM France pour publication fin août, de manière générale préparer la communication vers l'extérieur sur cette démarche - Prendre contact avec les groupes locaux OSM, les collectivités locales, les assos de secouristes... Toute structure susceptible de mobiliser ses membres pour contribuer au projet du mois Au plaisir de discuter avec vous sur ce projet :-) A l'aide d'osmose, j'ai exploré les données de GéoDAE pour mon département fétiche, l'Yonne... et bien c'est une catastrophe. Cette base semble essentiellement géocodée, et mal géocodée. Les positions sont souvent très mauvaises, il faut absolument la re-géocoder proprement en repartant des adresses postales indiquées, même si c'est un pis allé par rapport à un lat/lon propre à l'origine. J'ai contacté par mail les gestionnaires de géodae à ce sujet et pour voir comment collaborer. Pour info, j'avais accompagné la DGS au démarrage de cette base alors que j'étais à Etalab. On est donc TRES loin d'une intégration des données GéoDAE, par contre, ça peut aider à aller effectivement sur le terrain, ce qui d'ailleurs permettrait une remontée sur la qualité auprès de la DGS. Il y a aussi un sujet annexe... celui de la licence. Aider la DGS à améliorer cette base à partir des données OSM ça impose que la base soit ensuite diffusées en ODbL... ce que j'avais recommandé. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Projet du mois de septembre (en préparation) : défibrillateurs !
Bonjour à tous, Et si on s'organisait un projet du mois en septembre, par exemple sur les défibrillateurs (DAE) ? :-) https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Defibrillateurs # Pourquoi les défibrillateurs ? Il y a quelques semaines, la Direction Générale de la Santé a publié sa base GéoDAE (en cours de constitution), qui recense les défibrillateurs du pays. Un vaste chantier engagé depuis plusieurs mois, et qui commence à être visible par ces données. On y compte pour l'instant ~15000 défibrillateurs, dont 10% vérifiés par leur opérateur. En parallèle, dans OSM sur la France, on compte ~6500 défibrillateurs. Évidemment les deux bases ne se recoupent pas, certains DAE sont présents dans l'une et pas l'autre. En 2020, c'est quand même dommage. Alors si on s'y met en tant que communauté, on a possibilité d'obtenir une liste exhaustive sur le territoire de ces équipements ! # Quels sont les objectifs ? L'objectif principal sera de recenser le plus possible de défibrillateur sur le terrain. On pourra ainsi s'aider de la base GéoDAE via Osmose et des bases ouvertes par certaines collectivités. Mais le gros du travail va consister à arpenter les établissements pour retrouver ces équipements. Dans la mesure du possible, on renseignera les attributs annexes (localisation, opérateur, niveau...). # Comment aider à la préparation ? D'ici le début du projet en septembre, il y a quelques tâches qui restent à réaliser, si vous voulez prendre part à l'organisation c'est l'occasion ! - Vérifier / compléter la documentation sur le wiki, notamment sur les réutilisations existantes de ces données - Écrire un article pour annoncer le projet du mois sur le site OSM France pour publication fin août, de manière générale préparer la communication vers l'extérieur sur cette démarche - Prendre contact avec les groupes locaux OSM, les collectivités locales, les assos de secouristes... Toute structure susceptible de mobiliser ses membres pour contribuer au projet du mois Au plaisir de discuter avec vous sur ce projet :-) -- Adrien P. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un aire urbaine imaginaire ?
Oui aussi pourquoi pas mais je me pose quand même la question de la source
utilisée pour ajouter autant de panneaux.
Romain
De : Gad Jo
À : Discussions sur OSM en français ;
Romain MEHUT ;
talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un aire urbaine
imaginaire ?
Date : 04/08/2020 07:28:31 Europe/Paris
Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette anomalie
vers Osmose pour ajouter un nouveau contrôle ?
Je suis sûr que d'autre contributeur en ont créé de la même façon et qu'il
pourraient bénéficier de ce type de correction.
Au passage ça évite les suppression accidentelle de nœud où d'autres tag
seraient ajoutés (honnêtement ça m'étonnerait mais autant prévoir).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?
> Au lieu de supprimer autant de nœud, pourquoi ne pas remonter cette
anomalie vers Osmose pour ajouter un nouveau contrôle ?
Peut-être parce que la seule possibilité c'est de supprimer cette infox.
Sur les 4639 points ajoutés par notre ami, approximativement 703 sont
sur des highway (703 routes passent par ces points).
Concernant 4 000 points environ : on a l'information que le contributeur
a estimé que la limite urbaine c'était par là (au vue d'une imagerie
_aérienne_ comme si les limites correspondaient forcément !).
Absolument pas parce qu'il y a un panneau là.
Donc tu fais quoi ? Tu regardes une imagerie de rue pour voir s'il y a
un panneau dans le coin ?
Non, supprimer ces 4 000 points c'est hélas la bonne solution.
À ne pas confondre avec le cas de Florian (il a vu le panneau et a mis
la limite non au niveau de la route mais au niveau du panneau, il peut
mettre à jour sans problème).
Jean-Yvon
Le 04/08/2020 à 07:28, Gad Jo - perche...@toutenkamion.net a écrit :
Je suis sûr que d'autre contributeur en ont créé de la même façon et
qu'il pourraient bénéficier de ce type de correction.
Au passage ça évite les suppression accidentelle de nœud où d'autres
tag seraient ajoutés (honnêtement ça m'étonnerait mais autant prévoir).
Le August 3, 2020 10:05:46 AM UTC, Romain MEHUT
a écrit :
Je viens d'envoyer un message par la messagerie interne d'osm.org.
J'attends donc encore un peu avant de passer au
traffic_sign=city_limit.
Romain
De : Christian Quest
À : talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] {Disarmed} Re: Pourquoi inventer un
aire urbaine imaginaire ?
Date : 03/08/2020 09:00:10 Europe/Paris
Le 02/08/2020 à 22:51, Romain MEHUT a écrit :
> Les hésitations ont trop duré, c'est souvent le problème dans
OSM, on
> n'ose pas toujours pour ne pas froisser des susceptibilités. Je
n'ai
> rien contre le tag boundary=urban, c'est juste que dans le cas
> présent, son emploi s'est fait sans tenir compte des données déjà
> présentes...
>
> Romain
>
Pour ça que la première chose à faire est de prendre contact avec le
contributeur avant de faire la modification massive, surtout
quand c'est
un régulier comme ici.
--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
brièveté.
___
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
