Re: [OSM-talk-fr] Données Overture Maps
Bonjour,
Il y a les données mais...
En ce qui me concerne je persiste à penser que tout cela est
symptomatique d'une course à la donnée alors que les données n'ont de
sens que quand on s'en sert. OSM est maintenu par des fadas (dont je
fais parti...) qui pour certains passent leurs soirées à boucher des
trous pour la beauté de la chose, selon un idéal (auquel j'adhère) qui
n'est pas en phase avec l'ordre (économique) de ces plus ou moins
grosses boîtes qui les consomment. Que l'on ne me fasse pas dire ce que
je n'ai pas dit : les données sont le carburant d'OSM et on aura
probablement jamais fini de les affiner mais ceux qui font du business
autour des données géographiques veulent du rendement, du retour sur
investissement (ce qui n'est pas une critique négative de ma part, juste
un constat sur leurs statuts). Or, dans la lignée de Marc, malgré tous
les outils en place, la base d'OSM reste de l'artisanat. Ca a beau être
le premier employeur de France, ca reste de l'ordre dispersé (fantassin
LeTopographeFou, au rapport !).
Donc oui il y a les données (comme déjà expliqué) mais je vois surtout
la mise à disposition de ces données. Comment faciliter la vie des
fournisseurs de service en faisant abstraction des limites du modèle de
stockage OSM et de la géométrie variable et non canonique de ces données
(ex : deux manières de gérer les adresses, wikidata avec/sans wikipédia,
schéma pour les transports, gestion des langues, presets, any tag you
want, numéro de téléphone...). Et c'est là où ce genre d'initiative
(Overture) peut également marquer des points : fournir des données (à
jour/pas à jour à la limite c'est un détail pour eux eu égard au volume)
mais après les avoir nettoyé (des attributs inutiles la plupart des
cas), pré-processé et harmonisé pour les rendre efficaces à diffuser et
traiter. Exit les querelles internes, les trolls.
A mon avis (et comme j'ai déjà eu l'occasion de l'évoquer de manière
sporadique) OSM gagnerait à disposer d'un service facilitant la mise à
disposition des données qu'il agrège. En entrée ce service prendrait la
base OSM avec ses forces et ses faiblesses, en sortie il proposerait une
(ou plusieurs...) bases de données propres et pré-processées, aux
schémas clairs et pensés pour être efficace et sans interprétation.
L'exemple typique est l’harmonisation des adresses (ce qui oui pourrait
nécessiter de poser des choix plus ou moins arbitraires pour certains).
Cela resterait facultatif, une genre de surcouche pour ceux qui veulent
quelque chose de plus stable et plus qualitatif sans réinventer la roue.
Le service pourrait aussi proposer des modèles de données (par exemple
la correspondance avec le modèle administratif local qui aujourd'hui est
en vrac dans le wiki ou encore la construction de l'adresse postale) et
des éléments contextuels qui ne viennent pas d'OSM (par exemple les PH
dans les opening_hours pour tel pays ou région). Pour cela il existe
d'autres projets ou librairie qui pourraient être intégrées pour
mutualiser les forces, pas besoin de tout réinventer.
Plus les données sont faciles d'accès => plus elles sont visibles =>
plus elles seront exhaustives et pertinentes par le mécanisme de la
contribution à OSM.
Pour l'instant cela reste un rêve, un "il n'y a qu'à... faut qu'on",
mais si quelque chose se monte, alors le fantassin que je suis
considérera fortement d'y consacrer une partie de son temps, pour la
plus grande gloire d'OSM.
Cordialement,
LeTopographeFou
Le 28/07/2023 à 15:19, Marc_marc a écrit :
Bonjour,
cela parle partout d'Overture depuis 24h :)
Le 28.07.23 à 13:31, Francois Gouget a écrit :
Overture Maps est une fondation
mettons "fondation" entre "" puisque le but est vénal
c'est comme l'association non lucrative "lutte contre
le piratage de Microsoft" qui a été requalifié comme
lucrative par la justice à plusieurs reprises
qui ont été vérifiés
je préférerais dire "qui ont passé certains filtres" :
ce matin sur matrix/irc, un contributeur a trouvé
un noeud "pacific ocean", categories
{"main": "beach", "alternate": ["structure_and_geography",
"landmark_and_historical_building"]}
websites
["http://en.wikipedia.org/wiki/pacific_ocean;]
socials
["https://www.facebook.com/1012436518820283;]
personne n'a évidement vérifié ce poi :)
PS: l'erreur est dans le profil FB du poi
on peux donc supposer que la base des poi
d'overture contient probablement au moins
un dump des poi FB
et sont prêts à être utilisés en production.
osm est tout aussi prêt :) et utilisé en prod :)
je comparerais plutôt Overture au maj "lente"
existant par exemple dans le monde OpenSource
soit tu veux quelque chose très vite à jour,
soit tu veux quelque chose qui est passé
à travers plus de tests donc + lent.
tu as moins d'erreur... et aussi moins de nouveauté.
ils ne font pas co
Re: [OSM-talk-fr] Umap
Bonjour, Je ne pense pas que tu ai eu de réponse, j'ai jeté un oeil et le problème semble toujours présent. Via les outils de debug Web je vois que le serveur umap.openstreetmap.fr renvoi des erreurs 500 au chargement des données (ex : https://umap.openstreetmap.fr/fr/datalayer/1813900/), ce qui laisse à penser que c'est une erreur côté configuration serveur et/ou UMAP mais pas une erreur côté configuration de la carte ou jeux de données (en gros si le code retourné est conforme au standard alors ce n'est pas un problème que tu pourras régler). Donc je me retournerai vers UMAP: https://github.com/umap-project/umap/ Je vois un ticket similaire à ton problème : https://github.com/umap-project/umap/issues/998 Sauf que la carte en question semble maintenant fonctionner et le ticket reste ouvert donc je ne peux pas dire ce qu'il s'est passé. Le mieux est probablement que tu créé un nouveau ticket et que tu y fasse référence au ticket #998. Et si tu veux faire avancer le schmilblik demander en plus sur le ticket 998 si le problème est bien réglé et si c'est le cas savoir si odolbeau a fait quelque chose en particulier ou si c'est "tombé en marche" tout seul. Je ne peux pas trop faire plus sinon... Cordialement, LeTopographeFou Le 01/08/2022 à 13:25, André Laurenti a écrit : Bonjour, Quelqu'un peut-il m'expliquer pourquoi la première carte sur "le patrimoine endommagé" n'est plus accessible ? et que faut-il faire ? https://umap.openstreetmap.fr/fr/user/alaurenti/ Merci pour vos conseils André Laurenti ___ 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 perd des corrections
Bonjour François, J'ai également constaté qu'aucune de mes modifications via Osmose n'avaient été prise en compte il y a quelques semaines/jours alors que les erreurs disparaissaient bien d'Osmose. Concrètement j'ai "empilé" les modifs dans Osmose sans être connecté, puis après m'être connecté ma pile de modif est apparue comme vide. J'avais également une centaine de changements pour autant que je me souvienne. Je me suis dit qu'il les avait peut-être automatiquement téléversées (c'était la première fois que j'utilisais cette fonction Osmose) mais comme je ne voyais aucun changeset associé je me suis dit que soit c'était normal de purger la pile à la connexion (tant pis pour moi...), soit il y avait une tempo/bufferisation, soit un bug lié à la connexion et que je devrai revérifier un peu plus tard avant éventuellement de faire un ticket (si il n'en existe pas déjà un). Une chose une autre et voila mon attention monopolisée à des sujets plus persos... Bref : la conséquence est la même que la tienne mais la cause peut être différente, même si je vois des points communs (nombre de modifs, besoin de se connecter...).Il va falloir passer par la case ticket (veux bien que tu initie le sujet). LeTopographeFou Le 20/07/2022 à 23:53, Francois Gouget a écrit : J'ai l'impressions que cela fait quelques semaines qu'Osmose perd des changements. Je n'ai pas noté de problème lorsque je fais un changement et que je le sauve immédiatement. Par contre j'ai fait quelques chanegsets de 40 à 150 corrections qui ne sont jamais apparues dans ma liste de changesets. Et pourtant je n'ai eu aucun message d'erreur lors de la sauvegarde. Par exemple ce soir : * J'ai fait quelques corrections dans iD à Saint-Georges-de-Rex. https://www.openstreetmap.org/changeset/123867221 * Puis j'ai fait 47 corrections toponymiques et orthographiques directement dans Osmose à la Réunion. * Puis j'ai fait une correction toponymique directement dans Osmose, toujours à la Réunion. https://www.openstreetmap.org/changeset/123867502 Dans mon historique de changesets aucune trace du changeset du milieu. Avec un peu de chance les modifications ont été sauvegardées mais ne m'ont pas été attribuées ce qui serait un moindre mal. Mais je me souviens avoir corrigé un "Chemin des Pelicans" à Saint-Joseph qui je pense était ce noeud : https://www.openstreetmap.org/node/7605262476 Or aucune trace de correction (accent dans Pélicans). De plus la semaine dernière il me semble bien avoir refait des corrections que j'avais déjà faites. Mais comme je n'avais pas noté la liste des noeuds corrigés la première fois difficile d'être sûr. Du coup je n'ai pas l'impression que ce c'est lié à l'heure de la sauvegarde mais plutôt que c'est lié à la taille du changeset, la durée d'édition, ou à d'éventuels conflits (probabilité croissante avec la taille du changeset mais je doute un peu). Ouvrir iD à partir d'Osmose nécessite souvent de se reconnecter ce qui me paraît louche mais il n'y a peut-être pas de rapport. Quelqu'un sait-il ce qui se passe ? Navigateur : Firefox 102.0.1 (64 bits) / Debian 11 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] JOSM - Désignation des shop=farm
Bonsoir, J'avais justement hésité avec "Vente à la ferme" (qui est une expression communément utilisée j'ai l'impression) mais je me disais que la logique était de dire ce qui était vendu et pas de rappeler que c'est de la "vente". idem pour "Magasin de ferme". D'où le "Produits de la ferme" qui me semble en plus être plus précis (on y vend des "produits" et on la notion de "la" ferme, pas un truc vague genre "fermiers" ce qui pourrait coller à tout magasin vendant au moins une carotte même si elle vient de l'autre bout du monde). J'ai fait la modif sur Launchpad, on verra ce que cela donnera (je ne suis pas habitué à cet outils). Cela ne pourra pas être pire que "Primeur". Cordialement, LeTopographeFou Le 06/06/2022 à 18:52, Christian Rogel a écrit : Quelque chose signifiant «items produits sur place » serait plus approprié et pourrait être utilisé pour d’autres site comme la poterie, les fleurs ou les produits maraîchers (voire les pierres tombales) pour distinguer l’aire de production de l’aire de vente. Christian R. Le 6 juin 2022 à 12:40,osm.sanspourr...@spamgourmet.com a écrit : Bof (ni pour ni contre). Car oui primeur est clairement mauvais mais "Produits de la ferme" indique que les produits viennent de la ferme. Un hypermarché n'est pas une ferme, "Produits fermiers" serait ambigu. "Vente à la ferme" ne dit pas si ces produits viennent de la ferme en question (je pense à des marchés de producteurs à la ferme). Donc au final je botte en touche. ___ 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] JOSM - Désignation des shop=farm
Bonjour à tous, Soit la clé suivante : shop=farm JOSM en français la nomme "Primeur" là où le wiki (et je suis d'accord avec lui) parle de produits de la ferme. "Primeur", c'est en théorie shop=greengrocer (nommée "Fruits et légumes" dans JOSM). A mon avis cela a dû créer des erreurs. Aucun soucis pour que je fasse changer la traduction JOSM de shop=farm en "Produits de la ferme" ? Cordialement, -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modifications automatiques de operator:type sur les ecoles francaises
Bonjour, J'ai archivé la quête, elle ne devrait plus apparaitre. Je laisse à d'autres le soin de coordonner les restants. Cordialement, LeTopographeFou Le 17/05/2022 à 19:46, osm.sanspourr...@spamgourmet.com a écrit : J'oubliais : LeTopographeFou, tu peux a minima mettre à jour ta quête MapRoulette ? https://www.openstreetmap.org/node/4566756072 a été mis à jour il y a plus d'un an et maintenant le taux doit être proche de 100 % de fait. Jean-Yvon ___ 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] Bureaux de poste manquants
LeTopographeFou Le 26/11/2020 à 21:08, Romain MEHUT a écrit : Bonjour, Bonsoir, Suite au projet d'intégration des horaires des bureaux de poste, David indique qu'il manque encore pas mal de bureaux à intégrer. Je suis en train de parcourir le département 54 à l'aide d'Osmose et cela m'amène à quelques questions : - quelle est l'utilité de demander l'ajout du tag addr:postcode ? Aucune idée... - quand un bureau est de type post_annex (au sein d'une mairie) ou post_partner (chez un commerçant), la valeur du tag operator ne devrait pas être La Poste, il s'agirait plutôt dans ce cas d'utiliser network=La Poste ou brand. Entièrement d'accord que cela ne devrait pas être operator vu qu'ils n'y opèrent pas. Pas de préférence entre network et brand... chacun son rôle. Donc pourquoi pas les deux ? Qu'en pensez-vous ? Romain ___ 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] Ajout cartes des DOM sur Taginfo FR
Bonjour à tous, Pour information Geofabrik a exclu Jersey et Guernsey du polygone de la France. Cordialement, LeTopographeFou Le 04/06/2020 à 15:39, Topographe Fou a écrit : Note : http://taginfo.geofabrik.de/europe/france/tags/maxspeed=35%20mph#map <http://taginfo.geofabrik.de/europe/france/tags/maxspeed=35%20mph#map> me sors des objets à Guernsey, et en effet en regardant de plus prêt le périmètre de l'export sur https://download.geofabrik.de/europe/france.html <https://download.geofabrik.de/europe/france.html> c'est inclut dedans. Vais leur demander de retirer Jersey et Guernsey de leur export France. Le jeu. 4 juin 2020 à 14:58, Topographe Fou <mailto:letopographe...@gmail.com>> a écrit : J'ai fait une pull-request changeant uniquement le nom de l'instance taginfo. J'ai tout laissé en anglais mais me suis demandé pourquoi ce n'est pas en français. Ce qui sauterait au yeux serait de mettre une précision près du drapeau mais en effet je ne le trouve pas non plus. Le meilleur Github pour ouvrir un ticket concernant le drapeau est-il celui infrastructure ou ansible-scripts ? Concernant geofabrik cela se complique : sur https://download.geofabrik.de/europe/france.html <https://download.geofabrik.de/europe/france.html> la zone géographique de l'export n'englobe que la métropole mais dans la liste des 'Sub regions' on retrouve les DOM. Peut-être est-ce lié au fait que France soit sous Europe dans leur arborescence (Europe géographique vs Europe politique). Du coup soit je leur demande si ils peuvent renommer "France" en "France métropolitaine" (et dans ce cas les DOM n'auraient pas leur place en Sub-regions... arg la cohérence) soit je leur demande si ils peuvent inclure les DOM dans l'export France (et dans ce cas on est tout bon ! et notre taginfo sera bien sur la France) soit si ils peuvent rajouter un niveau (donc avoir un export France complet + un export France métropolitaine + Un export par région/DOM). Je penche pour la 2 ou la 3. Avis ? Je ne suis pas spécialement demandeur d'une instance taginfo France incluant les DOM, j'aime simplement quand les choses sont cohérentes et sans ambiguïté :) . Le jeu. 4 juin 2020 à 13:20, Marc M. mailto:marc_marc_...@hotmail.com>> a écrit : oui pour le moment taginfo .fr n'a pas les données domtom. Mais les données ne sont pas un soucis, elles sont dispo sur l'infra. avec plaisir pour le ticket osm-fr ajout de l'info "métropolitaine" :) et au moins des liens dans about vers les instances domtom https://github.com/osm-fr/infrastructure <https://github.com/osm-fr/infrastructure> si tu es motivé, la configuration est là https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo <https://github.com/osm-fr/ansible-scripts/tree/master/roles/taginfo> la partie France saute aux yeux :) mais le drapeau ne semble pas là oü il devrait l'être. n'hésites pas à en soumettre un si tu le souhaites. pour le ticket geofabrik, je peux pas garantir qu'ils le traiteront mais cela me semble toujours une bonne idée de signaler une erreur. à toi de me dire si cela correspond à ton besoin ou si une instance france complète serrait aussi utile. Le 04.06.20 à 12:43, Topographe Fou a écrit : > Ahhh !!! En fait le taginfo France est un taginfo France > _métropolitaine_. Donc à supposer que l'on puisse mettre plusieurs > cartes côte à côte il n'y aurait probablement pas les données pour les > remplir... Donc ma question tombe à l'eau. > > Un peu trompeur ce drapeau français et ce .fr. Ne peut-on pas rajouter > un petit "METROPOLE" sous le drapeau de > https://taginfo.openstreetmap.fr/ <https://taginfo.openstreetmap.fr/> ou rajouter dans le titre ? De même > sur geofabrik remplacer "Database: France" par "Database: France > métropolitaine" serait adéquat. Je peux créer des tickets si retours > positifs. > > Le jeu. 4 juin 2020 à 12:29, Marc M. mailto:marc_marc_...@hotmail.com> > <mailto:marc_marc_...@hotmail.com <mailto:marc_marc_...@hotmail.com>>> a écrit : > > la liste https://rlin.eu/osm/geofabrik/?id=france <https://rlin.eu/osm/geofabrik/?id=france> > mais il n'y a pas d'instance France. > ce que osm-fr et geofabrik nome France est la France métropolitaine > https://taginfo.geofabrik.de/europe/france/keys/building#map <https://taginfo.geofabrik
Re: [OSM-talk-fr] Data OSM
Génial comme site ! Comme nous n'avons pas à rougir de notre belle langue je suis pour un nom francophone et n'est pas pour autant imprononçable pour un anglophone. 'themes' me parait remplir les deux critères en matière de sous-domaine et en plus cela illustre bien l'usage. Osmose est génial pour cela. Par contre pour ce qui est du nom/logo du site l'appeler juste 'Thèmes' me fait tout bizarre. Mais c'est peut-être une question d'habitude. LeTopographeFou Le 20/06/2020 à 23:02, Georges Dutreix via Talk-fr a écrit : +1 20 juin 2020 21:20:39 osm.sanspourr...@spamgourmet.com: J'aime la dernière proposition sur Loomio : themes.openstreetmap.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] Comment orthographier un nombre ordinal
Pour être plus précis deux extraits de ce lexique (dernière édition, celle de 2002) : * Abréviation des nombres ordinaux : on abrégera première, deuxième, troisième... : 1re, 2e, 3e, et non 1ère, 2me ou 3ème... [Note : avec 're' et 'e' en exposant, difficile à retranscrire dans un mail] * Il convient de rappeler que 1°, 2°, 3°... sont les abréviations de primo, secundo, tertio..., le signe supérieur étant un o et non un zéro. Cette règle de l'imprimerie nationale ne suffisant pas pour dire que 28ème soit une faute d'orthographe ;o) . LeTopographeFou Le 13/06/2020 à 21:27, Topographe Fou a écrit : Selon les règles typographiques de l'imprimerie nationale (très bon bouquin que je recommande) : 28e . Cependant ce n'est pas rare de voir 28ème sur des documents officiels ou dans la presse écrite. LeTopographeFou *De:* bernard.lefranc...@free.fr *Envoyé:* 13 juin 2020 7:42 PM *À:* talk-fr@openstreetmap.org *Répondre à:* talk-fr@openstreetmap.org *Objet:* [OSM-talk-fr] Comment orthographier un nombre ordinal Bonjour, Je cherche la meilleure façon d'orthographier le "Quai du 28ème Bataillon de Chasseurs <https://www.openstreetmap.org/way/147706751>". 28ème comme ci-dessus avec accent (ma préférence) 28Eme, 28Ème, 28E Sans espace, avec espace. En tout cas la graphie actuelle 28° ma parait la pire. Qu'en pensez-vous? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete
En effet j'ai voulu retrouver le source de cette affirmation et il semblerait qu'il ne doive pas y avoir de différenciation de l'émetteur... c'est comme cela que l'on peut interpréter le "peuvent" dans "Tous les titres-restaurant des huit sociétés citées ci-dessus peuvent être acceptés en paiement d'un repas." (http://www.cntr.fr/V2/presse/infocntr.php) Me coucherai moins bête. Dans ce cas en effet pas besoin de différencier dans OSM et payment:meal_voucher=yes/no suffit (même pas besoin de brand) J'en ai profité pour clarifier le wiki (https://wiki.openstreetmap.org/wiki/FR:Key:payment#Titres_et_ch.C3.A8ques_affect.C3.A9s), extraire les titres restaurant de la rubrique cryptomonnaie (?) du wiki et mis une ligne vierge pour les chèques vacances en vue d'un choix (je voulais justement lancer le sujet un jour déçu par la carte en ligne ANCV). LeTopographeFou Le 08/06/2020 à 15:24, Marc M. a écrit : ok pour le besoin de doc. Donat vient de nous informer que c'est tout ou rien en France, donc la marque n'est pas nécessaire voir induirait en erreur. pour le namespace, oki lorsqu'il y a un conflit (par exemple une route sur un point peux avoir un nom pour la route et un pour le pont, donc logique d'avoir bridge:name) mais pour les tickets restaurants, cela me sembble une mauvaise idée de faire dépendre le tag en fonction de l'étendue commerciale d'une marque genre payment:meal_voucher=Sedexo puisque mondial et payment:meal_voucher:FR=trucmuchlocal parce que fr-fr avoir besoin de consulter le plan d'affaire d'une entreprise pour choisir le tag n'a pas de sens. Le 08.06.20 à 15:01, Topographe Fou a écrit : Par "pas claire" j'entends que le wiki ne propose rien aujourd'hui (ni sur la page anglaise, ni sur la française) et que la clé n'étant utilisé que 212 fois dans le monde dont seulement 30 fois pour autre chose que yes/no (pour Sodexo en l'occurrence) c'est qu'il doit sûrement rester un peu de discussion à avoir (83 fois en France métropolitaine avec 82 yes/no + 1 chèque vacances). Par ailleurs il peut y avoir plus d'un émetteur de titre (certes la CRT centralise les 4 plus gros émetteurs mais il n'y a pas qu'eux). Par 'brand' tu veux dire une liste des titres acceptés séparés par un ; ? Cela peut être une option mais d'expérience cela cafouille vite et puis la limite du nombre de caractères jouera probablement vite les troubles fêtes avec l'arrivée des nouveaux acteurs. D'où ma suggestion de rester dans la veine des autres moyens de paiement, ce qui renforce la cohérence. Le 'FR:' est une touche personnelle pour éviter d'éventuels conflits de noms quand un émetteur est clairement franco-français (ex : chèque vacances). Le lun. 8 juin 2020 à 14:42, Marc M. mailto:marc_marc_...@hotmail.com>> a écrit : Le 08.06.20 à 13:58, Topographe Fou a écrit : > il faudrait déjà un schéma claire, ce qui n'est pas le cas aujourd'hui. =yes/brand/no c'est pas clair ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr -- LeTopographeFou ___ 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] booking=* <> reservation=*
Je pense également que réserver "booking=*" au seul site Booking n'est pas souhaitable. Il existe plein d'autres services et on est pas à l'abris qu'il y en ai un qui s'appelle "amenity" ou "building". Il faudrait à minima l'isoler dans un namespace, "reservation:booking" ou même "reservation:url:booking" pour pouvoir différencier différents moyens de réservation. Cependant il serait bon de ne pas résumer le débat à "Booking" mais parler de tous les sites de location entre particuliers et, en allant plus loin, aux plateformes de réservation de rendez-vous médicaux, de soins de beautés, de cours, de billets de train/avion/bus, de courses, de restauration, de voiture (y compris entre particuliers type Drivy), de places de théatre/cinéma... Cela dit mettre du Booking dans OSM présente aujourd'hui quelques soucis. Je ne suis pas opposé mais je dis 'attention' : 1. Ils n'ont pas de système de clé unique, publique et international partageable dans un "ref:booking" et attaquable via API Booking (ce qui serait bien plus propre qu'une URL) 2. Leurs URL sont moches, tout le monde ne sait pas les simplifier à leur stricte nécessaire en virant les éléments qui ne sont là que pour faire du suivi de navigation dans le cadre d'une recherche (ce qui n'a plus de sens dès qu'on le met dans OSM) 3. Dans l'URL il y a la langue (du moins quand je consulte un hébergement j'ai un '/fr/'), il conviendrait probablement de préciser le code ISO dans la clé (sinon un allemand peut se retrouver avec un lien en chinois) Cordialement, LeTopographeFou Le 04/07/2019 à 15:29, marc marc a écrit : Bonjour, je fais écho ici d'une discussion qui a commencé sur la ml tagging pour indiquer qu'un POI accepte/refuse/recommande une réservation, la clef la plus courante est reservation=* un contributeur avait crée une page booking=* et l'avait ajout en recommandation sur plusieurs autres pages. mais outre le fait d'avoir 2 clefs pour la même chose, cela entrait en conflit avec booking=l'url booking.com En est arrivé la conclusion de migrer - booking=* vers reservation=* lorsque concerne la possibilité ou non de réserver - garder dans booking=* les url booking - il y a aussi quelques urls de réservation non booking. rien n'a été décidé mais sans doute que reservation:website serrait le + cohérent. a noter que le plus grand nombre de cas (125) sont des lignes de train passant par la France. à vos correcteurs, prêt ? partez :D et si cela ne motive personne, je m'y collerai :) Cordialement Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin
Désolé, je n'avais pas vu que tu proposais de mettre Alt+Maj+Bas, j'ai lu Alt+Maj+B... :-( Donc je retire mon commentaire. Par contre j'ai essayé dans JOSM 15155, le raccourci est bien Alt+Maj+D et non pas Alt+Maj+Bas. Donc je pense qu'il faut laisser Alt+Maj+D. Ou alors je n'ai (encore) rien compris ? Pour Launchpad, la liste des phrases non traduits (14 à ce jour pour le français) est accessible là : https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?show=untranslated . Sauf que actuellement j'ai une erreur de Timeout :-( . Quoi qu'il en soit merci pour ce temps passer à la traduction des outils ! LeTopographeFou Le 24/06/2019 à 18:59, Topographe Fou a écrit : Perso quand je vois Alt+Maj+B je fais Alt+Maj+B, pas Alt+Maj+Bas. Si le B fais référence à la touche Bas alors mieux vaut mettre Bas. Sinon autant mettre A+M+B. Ou alors mettre un symbole flèche vers le bas si les caractères spéciaux (unicodes ?) sont gérés. Mes deux cents, LeTopographeFou Message original De: lenny.li...@orange.fr Envoyé: 22 juin 2019 10:22 AM À: talk-fr@openstreetmap.org Répondre à: talk-fr@openstreetmap.org Objet: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin Bonjour, En mettant à jour la page du wiki https://josm.openstreetmap.de/wiki/Fr%3AHelp/Action/SplitWay avec la version anglaise : je me suis aperçu, en faisant la copie écran de la fenêtre contextuelle qui s'affiche (en mode expert) que le titre de la fenêtre est restée en anglais. Je suis allé voir Launchpad ; mais je dois avouer que c'est un peu trop compliqué pour moi ... De plus, dans le menu Fichier, le raccourcis-clavier de "Télécharger le long" est indiqué "Alt + Maj + D" alors que le "D" de "Down" en anglais devrait être remplacé par "Bas" : "Alt + Maj + Bas" Si quelqu'un connaissant Launchpad pouvait s'en charger, merci Cordialement Leni ___ 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] Tag pour les Archives (départementales, municipales...) ?
Bonjour à tous, Merci pour vos retours sur la question, vais essayer de résumer. Il y a archives publiques (assurées par le service public) et il peut y avoir localement (ou à l'étranger) des archives privées (associatives, religieuses, fondations...) mais accessibles au public. Ma question portait principalement sur le service public (origine de ma recherche amenity=public_building) mais pourquoi pas converger vers une solution pouvant correspondre au public comme au privé. Je met par contre de côté les entreprises hébergeant des serveurs contenant des archives que lui aurait confiées le service public. Par 'archives' on peut entendre les services administratifs comme le lieu de consultation. Je pense qu'ils sont souvent par commodité localisés au même endroit (même si je suis sûr qu'il y a des exceptions, des annexes, des antennes...) et n'imaginais pas à ce stade différencier si ce sont des bureaux ou un espace de consultation mais de manière général un 'service public gérant des archives'. Mais l'avenir d'OSM allant à la précision on pourrait se diriger vers : * Pour la consultation (public, privé...) : 'amenity=archives' (avec dans le cas d'un service public 'admin_level=*') * Pour la partie plus administrative (gestion des fonds, communication, juridique...) : 'office=government' + 'government=archives' + 'admin_level=*' pour le public ou tout tag approprié existant (associations, fondations...) Il faudra probablement porter le débat (une fois consolidé) au niveau de la liste tagging une fois la question francophone relativement claire. Cela vous va ? Cordialement, LeTopographeFou Le 16/05/2019 à 17:29, LeTopographeFou a écrit : Bonjour, En faisant le point sur l'usage (marqué obsolète) de la clé 'amenity=public_building' je suis tombé sur le cas des archives publiques (départementales, municipales...) pour lesquelles je ne trouve pas de schéma claire. En regardant l'existant je trouve 'office=government' ou 'amenity=library' ou 'amenity=archives' . Je serait bien tenté par 'office=government' avec 'government=archives' mais suis ouvert à autre chose. Une idée ? Pour info (pour les francophones) : * 64 objets avec "Archives (D|d)épartementales" à ce jour * 32 objets avec "Archives (M|m)unicipales" à ce jour -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tag pour les Archives (départementales, municipales...) ?
Bonjour, En faisant le point sur l'usage (marqué obsolète) de la clé 'amenity=public_building' je suis tombé sur le cas des archives publiques (départementales, municipales...) pour lesquelles je ne trouve pas de schéma claire. En regardant l'existant je trouve 'office=government' ou 'amenity=library' ou 'amenity=archives' . Je serait bien tenté par 'office=government' avec 'government=archives' mais suis ouvert à autre chose. Une idée ? Pour info (pour les francophones) : * 64 objets avec "Archives (D|d)épartementales" à ce jour * 32 objets avec "Archives (M|m)unicipales" à ce jour -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment indiquer qu'un cimetière est ouvert aux véhicules ?
Oui mais access=permissive couvre aussi les piétons, donc si seules les véhicules doivent demander une autorisation pour entrer mais que le piéton lambda peut entrer/sortir librement il vaut mieux affiner en utilisant vehicle=permissive et non access=permissive. LeTopographeFou Le 20/12/2018 à 13:12, JB a écrit : Bonjour, Comme déjà noté, tu ne taggues pas le cimetière, mais chaque voie du cimetière. Ce sont sur elles que les gens circulent habituellement. Par exemple celle-ci : https://www.openstreetmap.org/way/23793441. Cependant, access=permissive indique que c'est déjà le cas actuellement. Pour tout type de véhicule, jusqu'à ce que le gestionnaire du cimetière décide de changer. Cordialement, JB. Le 20/12/2018 à 12:52, Shohreh a écrit : Merci, mais comment faire ? Doit-on créer une relation avec "service=highway=service" et y inclure toutes les ways (comment ?) qui composent les voies dans le cimetière ? https://www.openstreetmap.org/way/13793222 -- 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment indiquer qu'un cimetière est ouvert aux véhicules ?
Bonjour, Je ne suis pas partisan de relations dans ce cas de figure... Juste tagger les voies (chemins piétons et routes carrossables) avec les bons attributs. LeTopographeFou Le 20/12/2018 à 12:52, Shohreh a écrit : Merci, mais comment faire ? Doit-on créer une relation avec "service=highway=service" et y inclure toutes les ways (comment ?) qui composent les voies dans le cimetière ? https://www.openstreetmap.org/way/13793222 -- 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] Comment indiquer qu'un cimetière est ouvert aux véhicules ?
Bonsoir,
Et bien je dirai que se sont avant tout des routes, même si elles sont
spéciales de par leurs destinations/restrictions, et en l’occurrence je
dirai que c'est de type "service" => highway=service
Pour les intra-muros (besoin d'une autorisation médicale...) je mettrai
à minima la restriction d'accès suivante => vehicle=private (ce qui
englobe du vélo jusqu'au semi-remorque en passant par voiture, bus et
calèche)
Je ne mettrai pas de access=destination à moins que ce ne soit
explicitement indiqué sur place.
Cordialement,
LeTopographeFou
Le 18/12/2018 à 21:59, Shohreh a écrit :
Bonjour,
Les six cimetières parisiens <https://www.paris.fr/cimetieres> hors de la
ville ("extra-muros" en patois) sont ouverts aux véhicules, et donc
notamment aux vélos.
Il ne semble pas exister de relation pour celui de Bagneux par exemple :
https://www.openstreetmap.org/way/13793222
Selon vous, quelle est la bonne façon d'indiquer que ces cimetières sont
ouverts à autre chose que les piétons ?
Merci.
--
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] Carte scolaire
Attribution corrigée, et ce dans l'heure qui suit ! LeTopographeFou Le 10/03/2018 à 13:24, LeTopographeFou a écrit : Pour info : j'ai envoyé un message via le formulaire de contact. LeTopographeFou Le 10/03/2018 à 06:06, Philippe Verdy a écrit : il y a bien un lien en haut de la page "A propos" qui ouvre un panneau "crédits" qui n'affiche que: * Leaflet.js <http://leafletjs.com/>: librairie de cartographie interactive * Bootleaf <https://github.com/bmcbride/bootleaf>: template Bootstrap pour Leaflet * Openrouteservice <https://maps.openrouteservice.org/>: API de geocodage des adresses et de calcul d'itinéraires Autrement dit juste les outils utilisés pour le design du site, rien concernant les données avec ces outils qui ne mentionnent que: * data.gouv.fr<http://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/>: Adresse et géolocalisation des établissements d'enseignement du premier et second degrés * opendata.paris.fr <http://opendata.paris.fr/explore/dataset/secteurs-scolaires/>: Secteurs scolaires Paris Le 10 mars 2018 à 06:03, Philippe Verdy <verd...@wanadoo.fr <mailto:verd...@wanadoo.fr>> a écrit : Je confirme que "www.cartescolaire.paris" est bien une carte avec les données OSM, des détails précis (comme ceux concernant les tracés des lignes ferroviaires) ne trompent pas du tout, de même que le tracé des contours fluviaux, et même des erreurs d'approximations de batiments (existants mais difficiles à délimiter sur les orthophotos et absents du cadastre, ou pas forcément bien alignés quand des orthophotos ont été révisés et les batiments tracés à des dates différentes). Même les fautes d'orthographe dans les noms de certaines rues, ou des désaccords avec le cadastre (qui lui est en erreur, pas OSM !). De même ce rendu montre certains défauts concernant les tracés de voies paralllèles, ou certains carrefours pour des raisons de routage. Ce rendu a de gros défauts comme celui de quasiment masquer complètement les rues piétonnes (et dans un quartier piétonnier, impossible de se repérer facilement alors que ce sont des rues importantes) alors qu'on voit parfaitement les voies de service des parkings autour. Donc oui il manque les attributions nécessaires. Le 10 mars 2018 à 00:21, LeTopographeFou <letopographe...@gmail.com <mailto:letopographe...@gmail.com>> a écrit : Hors-sujet : c'est moi où c'est une carte OSM qui ne dit pas son nom ? A y voir certaines intersections et quartiers que j'ai cartographié moi-même cela correspond assez bien. Si quelqu'un partageant cette impression se sent de les contacter, il est le bienvenue. Cordialement, LeTopographeFou Le 09/03/2018 à 23:10, althio a écrit : L'exemple de Paris, uniquement collèges et lycées : http://www.cartescolaire.paris/ <http://www.cartescolaire.paris/> ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr <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] Carte scolaire
Attribution corrigée, et ce dans l'heure qui suit ! LeTopographeFou Le 10/03/2018 à 13:24, LeTopographeFou a écrit : Pour info : j'ai envoyé un message via le formulaire de contact. LeTopographeFou Le 10/03/2018 à 06:06, Philippe Verdy a écrit : il y a bien un lien en haut de la page "A propos" qui ouvre un panneau "crédits" qui n'affiche que: * Leaflet.js <http://leafletjs.com/>: librairie de cartographie interactive * Bootleaf <https://github.com/bmcbride/bootleaf>: template Bootstrap pour Leaflet * Openrouteservice <https://maps.openrouteservice.org/>: API de geocodage des adresses et de calcul d'itinéraires Autrement dit juste les outils utilisés pour le design du site, rien concernant les données avec ces outils qui ne mentionnent que: * data.gouv.fr<http://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/>: Adresse et géolocalisation des établissements d'enseignement du premier et second degrés * opendata.paris.fr <http://opendata.paris.fr/explore/dataset/secteurs-scolaires/>: Secteurs scolaires Paris Le 10 mars 2018 à 06:03, Philippe Verdy <verd...@wanadoo.fr <mailto:verd...@wanadoo.fr>> a écrit : Je confirme que "www.cartescolaire.paris" est bien une carte avec les données OSM, des détails précis (comme ceux concernant les tracés des lignes ferroviaires) ne trompent pas du tout, de même que le tracé des contours fluviaux, et même des erreurs d'approximations de batiments (existants mais difficiles à délimiter sur les orthophotos et absents du cadastre, ou pas forcément bien alignés quand des orthophotos ont été révisés et les batiments tracés à des dates différentes). Même les fautes d'orthographe dans les noms de certaines rues, ou des désaccords avec le cadastre (qui lui est en erreur, pas OSM !). De même ce rendu montre certains défauts concernant les tracés de voies paralllèles, ou certains carrefours pour des raisons de routage. Ce rendu a de gros défauts comme celui de quasiment masquer complètement les rues piétonnes (et dans un quartier piétonnier, impossible de se repérer facilement alors que ce sont des rues importantes) alors qu'on voit parfaitement les voies de service des parkings autour. Donc oui il manque les attributions nécessaires. Le 10 mars 2018 à 00:21, LeTopographeFou <letopographe...@gmail.com <mailto:letopographe...@gmail.com>> a écrit : Hors-sujet : c'est moi où c'est une carte OSM qui ne dit pas son nom ? A y voir certaines intersections et quartiers que j'ai cartographié moi-même cela correspond assez bien. Si quelqu'un partageant cette impression se sent de les contacter, il est le bienvenue. Cordialement, LeTopographeFou Le 09/03/2018 à 23:10, althio a écrit : L'exemple de Paris, uniquement collèges et lycées : http://www.cartescolaire.paris/ <http://www.cartescolaire.paris/> ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr <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] Carte scolaire
Pour info : j'ai envoyé un message via le formulaire de contact. LeTopographeFou Le 10/03/2018 à 06:06, Philippe Verdy a écrit : il y a bien un lien en haut de la page "A propos" qui ouvre un panneau "crédits" qui n'affiche que: * Leaflet.js <http://leafletjs.com/>: librairie de cartographie interactive * Bootleaf <https://github.com/bmcbride/bootleaf>: template Bootstrap pour Leaflet * Openrouteservice <https://maps.openrouteservice.org/>: API de geocodage des adresses et de calcul d'itinéraires Autrement dit juste les outils utilisés pour le design du site, rien concernant les données avec ces outils qui ne mentionnent que: * data.gouv.fr<http://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/>: Adresse et géolocalisation des établissements d'enseignement du premier et second degrés * opendata.paris.fr <http://opendata.paris.fr/explore/dataset/secteurs-scolaires/>: Secteurs scolaires Paris Le 10 mars 2018 à 06:03, Philippe Verdy <verd...@wanadoo.fr <mailto:verd...@wanadoo.fr>> a écrit : Je confirme que "www.cartescolaire.paris" est bien une carte avec les données OSM, des détails précis (comme ceux concernant les tracés des lignes ferroviaires) ne trompent pas du tout, de même que le tracé des contours fluviaux, et même des erreurs d'approximations de batiments (existants mais difficiles à délimiter sur les orthophotos et absents du cadastre, ou pas forcément bien alignés quand des orthophotos ont été révisés et les batiments tracés à des dates différentes). Même les fautes d'orthographe dans les noms de certaines rues, ou des désaccords avec le cadastre (qui lui est en erreur, pas OSM !). De même ce rendu montre certains défauts concernant les tracés de voies paralllèles, ou certains carrefours pour des raisons de routage. Ce rendu a de gros défauts comme celui de quasiment masquer complètement les rues piétonnes (et dans un quartier piétonnier, impossible de se repérer facilement alors que ce sont des rues importantes) alors qu'on voit parfaitement les voies de service des parkings autour. Donc oui il manque les attributions nécessaires. Le 10 mars 2018 à 00:21, LeTopographeFou <letopographe...@gmail.com <mailto:letopographe...@gmail.com>> a écrit : Hors-sujet : c'est moi où c'est une carte OSM qui ne dit pas son nom ? A y voir certaines intersections et quartiers que j'ai cartographié moi-même cela correspond assez bien. Si quelqu'un partageant cette impression se sent de les contacter, il est le bienvenue. Cordialement, LeTopographeFou Le 09/03/2018 à 23:10, althio a écrit : L'exemple de Paris, uniquement collèges et lycées : http://www.cartescolaire.paris/ <http://www.cartescolaire.paris/> ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr <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] Carte scolaire
Hors-sujet : c'est moi où c'est une carte OSM qui ne dit pas son nom ? A y voir certaines intersections et quartiers que j'ai cartographié moi-même cela correspond assez bien. Si quelqu'un partageant cette impression se sent de les contacter, il est le bienvenue. Cordialement, LeTopographeFou Le 09/03/2018 à 23:10, althio a écrit : L'exemple de Paris, uniquement collèges et lycées : http://www.cartescolaire.paris/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carte scolaire
Bonjour, Perso je pense qu'une carte uMap a encore moins de chance d'être trouvée, maintenue et (re)exploitée que la BDD OSM... De plus cela ferme la porte a des potentiels usages, même si spécialisés (quelles sont les écoles publiques auquel j'ai accès habitant à Truc-Muche ?). C'est une force d'OSM que de savoir proposer les données consolidées aux utilisateurs pour bâtir leur propres services géographiques, par rapport aux alternatives commerciales (gratuites ou payantes) et à la proliférations des portails de données géographiques locales (qui s'adressent d'avantage à des développeurs). Les données ne sont pas maintenues tant qu'elles ne sont pas accessibles et utilisées, voila le problème (si personne n'utilise le tag opening_hours, on ne risque pas de découvrir que l'horaire d'ouverture à changé... et si personne n'ajoute ce tag à un magasin, personne ne saura si le magasin est ouvert ou pas à un instant T...). Donc la maintenance pour moi n'est pas là le débat (sinon on ne mettrait rien, pas même les frontières ou rivages). Mettre des données pertinentes dans OSM c'est bien, mais leur donner ensuite une visibilité et un usage, c'est mieux afin de permettre et encourager leur maintenance. Perso quand je tombe sur un fond de carte (libre) intéressant mais que je me dis qu'aucun outils n'est fait pour mettre en valeur cette information, je m’abstiens de la verser au projet. Les cartes scolaires touchent potentiellement tous les français, même si c'est surtout ceux en situation de scolariser leurs enfants. La carte umap en question semble être issue d'une instance officielle de la ville de Mayenne, ce qui je l'espère garanti sa qualité et sa pérennité, mais le danger pour un particulier de faire une carte dans son coin est de laisser trainer sur Internet une carte erronée ou obsolète sans possibilité d'y collaborer. De même le danger d'utiliser un schéma de tag qui n'est pas commun et n'est supporté par aucun outils. Le débat est plutôt de savoir si il existe une manière unifiée et documentée pour, au moins en France, cartographier les cartes scolaires. Si il n'y en a pas, alors elle peut être proposée (en se basant sur des tags existants) et soumise au vote. Cordialement, LeTopographeFou Le 09/03/2018 à 16:09, Xavier Cremaschi a écrit : Bonjour, si je veux rajouter une carte scolaire, par ex en m'appuyant sur : http://www.deliberations.antibes-juanlespins.com/files/20170519-1500/11_1_modif_carte_scolaire_vieille_ville.pdf Ça se passe sur la db officielle (donc sur openstreetmap.org ), ou alors il faut faire des trucs à part comme sur : https://umap.openstreetmap.fr/fr/map/carte-scolaire-ville-de-mayenne_61543#14/48.3069/-0.5988 ? ___ 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] Site de pêche litigieux
Bonjour,
Je suis tombé par hasard sur la page
https://ou-pecher.fr/coins-de-peche-detail/55a6344a2b6dff21167dcaa3/ruisseau-des-coutumes
où je constate au moins deux infractions selon
https://operations.osmfoundation.org/policies/tiles/ :
1. OpenStreetMap n'est pas crédité
2. Le site envoi des en-têtes qui désactivent le cache (“Cache-Control:
no-cache” + “Pragma: no-cache”)
Le site utilise les serveurs de tuile {a,b,c}.tile.openstreetmap.org (ce
qui n'est pas explicitement interdit tant que l'on respecte les règles).
Je suspect que le nombre de thread dépasse la limite autorisée mais ne
me prononcerait pas avec assurance sur ce point (impression que toutes
les tuiles sont téléchargées en simultané quand je regarde le graphique
Réseau de mon navigateur).
Toutes les pages de coins de pêche (ruisseaux, étangs...) sont
concernées. Le site parent http://comptoirdespecheurs.com semblant
payant je n'ai pas pu y regarder plus loin.
Quelqu'un de chevronné ici est-il chargé de faire corriger ces problèmes
ou bien dois-je aller au charbon avec doigté ?
En vous souhaitant de belles fêtes de fin d'années,
Cordialement,
--
LeTopographeFou
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (osm: message 1 of 20) Noms des routes à des intersections doubles/triples...
Bonjour à tous, Ok merci. Je mettrai à l'occasion quelque chose sur ces cas de figure sur le Wiki. Cordialement, LeTopographeFou Le 14/06/2017 à 19:52, osm.sanspourr...@spamgourmet.com a écrit : Et concrètement on peut le faire (j'avais répondu en MP par erreur) : S'il n'y a pas de nom sur le terrain noname=yes <https://wiki.openstreetmap.org/wiki/FR:Key:noname> S'il y en a un sur le cadastre et que c'est celui de A ou B, pourquoi pas mais inutile de passer des heures s'il n'y a rien sur le terrain. Le 14/06/2017 à 09:47, Teuxe - te...@free.fr a écrit : Bonjour, Ce genre de section de route n'a pas besoin d'être nommé car il n'est jamais adressé. Dans la pratique il est géré dans la continuité de la route principale. Il faudrait donc que dans OSM on lui dise "volontairement pas de nom". Teuxe ___ 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] Noms des routes à des intersections doubles/triples...
Bonjour, Je cherche à nommer (ou indiquer qu'il n'y a pas de nom...) des sections de routes (en bleu sur l'image) qui ont la particularité d'être à des intersections "doubles" (ou pire : triple/quadruple !) c'est -à-dire qu'elles ont pour caractéristique : 1. d'assurer la transition entre deux routes éventuellement alignées (appelons les A et B) _avec des noms différents_ 2. en permettant de couper un grand axe séparé par un terre-plein, appelons C et D les deux sens de circulation 3. bien entendu et sauf restriction particulière on peut aussi utiliser ces routes pour tourner (de A à C, de D à B...) Exemples dans Paris : 1. http://www.openstreetmap.org/way/19518124 2. http://www.openstreetmap.org/way/18498298 3. http://www.openstreetmap.org/way/4039334 4. ... Dans ces cas de figure le cadastre ne semble pas être d'une très grand aide ni le wiki (https://wiki.openstreetmap.org/wiki/FR:Jonctions, https://wiki.openstreetmap.org/wiki/FR:Normes_et_conventions_d%27%C3%A9dition#Croisements et leurs homologues anglais). Le terrain non plus n'est pas toujours d'une grande aide (trop courts et sans adresse pour qu'un panneau de rue soit mis). Après une petite enquête c'est parfois le nom du "grand axe à voies séparées" qui est choisi (mais sur quel critère ?), parfois l'une de deux rues débouchant (de manière arbitraire ?). Mais le plus souvent il n'y a pas de nom de renseigné. Existes-t-il une règle/un outil pour savoir comment nommer ces axes ? Un cadastre "hyper précis" ? Je me dis que mon soucis peut concerner pas mal de gens et que le Wiki gagnerait à aborder ce cas de figure. Cordialement, -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Valeurs multiples pour des altitudes
Bonjour, A mon avis la réponse pour le premier noeud mentionné se trouve dans le tag description : /Clocher : Centre de la boule - Point vu en place en 2004;Clocher : Centre de la croix - Point vu en place en 2004/ Donc comprendre que le premier ele est pour le centre de la boule, le second pour le centre de la croix. Maintenant cela n'a pas plus de sens pour moi et un outils ne saura rien en tirer. Il vaut mieux mettre deux nodes dans ce cas, un pour chaque point référencé. Sauf que ces deux nodes doivent rester à la coordonnée actuelle, ce qui risque de générer d'autres erreurs type "noeuds superposés" (si la troisième dimension n'est pas prise en compte). Cordialement, LeTopographeFou Le 02/04/2017 à 15:50, Francois Gouget a écrit : Osmose se plaint que la valeur du tag 'ele' n'est pas une valeur numérique valide. Tout le problème c'est que beaucoup de ces tags ont deux valeurs séparées pas un point-virgule. Par exemple : https://www.openstreetmap.org/node/670606434 https://www.openstreetmap.org/node/670608867 Je suis allé voir la description du champ ele mais je n'ai pas trouvé quel sens cela aurait d'avoir deux valeurs dans ce champ. Quelqu'un sait-il de quoi il retourne ? Si cela a un sens d'avoir plusieurs valeurs alors cela devrait probablement être documenté dans le wiki et il faudrait corriger Osmose. Mais comme le wiki dit que de nombreuses applications dépendent du fait que ele est une valeur numérique en mètres et rien d'autre cela semble peu probable. http://wiki.openstreetmap.org/wiki/FR:Key:ele ___ 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] FANTOIR et métro parisien ?
Pour info : certaines stations ont deux codes FANTOIR, notamment celles à cheval sur deux arrondissements (ex : métro Vaneau à cheval entre 6e et 7e <http://www.openstreetmap.org/node/473070143>) ou celles qui dans un même fichier apparaissent deux fois dans un même arrondissement sans raison connue (ex : métro St Jacques dans le 14e <http://www.openstreetmap.org/node/235369898>). A l'exception des stations en deux parties (comme Montparnasse), j'ai mis les deux codes séparés par un point-virgule quand je sais qu'il y a clairement une seule et unique station. Dans le doute : je n'ai pas renseigné. J'ai également ajouté ce cas de figure dans le Wiki : https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR#Cas_particuliers (je sais que les valeurs multiples avec un ';' font débats... mais en attendant il faut bien un exemple !). Cordialement, LeTopographeFou Le 24/01/2017 à 21:33, LeTopographeFou a écrit : Bonjour, ok et merci ! Il n'y a plus qu'à... Cordialement, LeTopographeFou Le 23/01/2017 à 22:41, Vincent de Château-Thierry a écrit : Bonsoir, Le 22/01/2017 à 22:55, Vincent de Château-Thierry a écrit : Le 22/01/2017 à 22:37, LeTopographeFou a écrit : A mes heures perdus j'essaie de forcer le rapprochement des données cadastres avec OSM via Osmose ou le site cadastre.openstreetmap.fr <http://cadastre.openstreetmap.fr>. Et il s'avère que certaines stations de métro parisiennes (pas tous ?) ont un numéro FANTOIR et apparaissent dans l'onglet des Lieux-dits. Ex : http://cadastre.openstreetmap.fr/fantoir/#insee=75113=4 La question à 5 sous : est-ce que rajouter à ces stations (ou à la "relation définissant la station" quand elle existe, qu'on l'aime ou pas) un attribut ref:FR:FANTOIR suffit ? Faudrait-il ajouter un place=* (si oui quelle valeur ?) pour en faire un "lieu-dit" ? Ou bien il faut mettre ces deux attributs sur un node à part car le lieu-dit existe et qu'il n'est pas nécessairement restreint à la station (ex : sa surface au sens du cadastre couvrant un quartier entier alors que la station est plus petite) ? Je penche pour un ref:FR:FANTOIR sur le node station (ou la relation...) et puis basta. A ce jour aucune station de métro ne semble avoir une réf FANTOIR dans OSM, d'où aussi ma question de savoir si c'est volontaire. La même question peut se poser sur un hôpital (ex : hôpital de la Salpêtrière), un cimetière (ex : cimetière du Montparnasse), une gare... Oui, rajouter le ref:FR:FANTOIR directement sur les objets (ici les stations, en node ou en relation), pourquoi pas. En l'état ça ne devrait pas suffire pour permettre le rapprochement, car côté lieux-dits on cherche explicitement un tag name ET un tag place. Mais l'idée, hormis pour le tag ref:FR:FANTOIR lui-même, a toujours été d'adapter BANO à OSM et pas l'inverse. Donc il faudra côté BANO élargir le critère de recherche des lieux-dits (au sens FANTOIR du terme) dans OSM pour provoquer des rapprochements. Un assouplissement pourrait être notamment de chercher un tag place OU un tag ref:FR:FANTOIR. Ça fonctionnerait pour un metro, mais aussi un hôpital ou un cimetière comme tu l'évoques. => https://github.com/osm-fr/bano/issues/131 J'ai traité le cas, en élargissant aux objets dôtés conjointement des tags name=*, ref:FR:FANTOIR=* et d'au moins un tag parmi amenity=* et railway=*. Par un effet de bord, les metros du XIIIe et l'hôpital de la Pitié se retrouvent non plus dans les lieux-dits, mais dans les "voies sans adresse" : http://cadastre.openstreetmap.fr/fantoir/#insee=75113=3 vincent ___ 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] FANTOIR et métro parisien ?
Bonjour, ok et merci ! Il n'y a plus qu'à... Cordialement, LeTopographeFou Le 23/01/2017 à 22:41, Vincent de Château-Thierry a écrit : Bonsoir, Le 22/01/2017 à 22:55, Vincent de Château-Thierry a écrit : Le 22/01/2017 à 22:37, LeTopographeFou a écrit : A mes heures perdus j'essaie de forcer le rapprochement des données cadastres avec OSM via Osmose ou le site cadastre.openstreetmap.fr <http://cadastre.openstreetmap.fr>. Et il s'avère que certaines stations de métro parisiennes (pas tous ?) ont un numéro FANTOIR et apparaissent dans l'onglet des Lieux-dits. Ex : http://cadastre.openstreetmap.fr/fantoir/#insee=75113=4 La question à 5 sous : est-ce que rajouter à ces stations (ou à la "relation définissant la station" quand elle existe, qu'on l'aime ou pas) un attribut ref:FR:FANTOIR suffit ? Faudrait-il ajouter un place=* (si oui quelle valeur ?) pour en faire un "lieu-dit" ? Ou bien il faut mettre ces deux attributs sur un node à part car le lieu-dit existe et qu'il n'est pas nécessairement restreint à la station (ex : sa surface au sens du cadastre couvrant un quartier entier alors que la station est plus petite) ? Je penche pour un ref:FR:FANTOIR sur le node station (ou la relation...) et puis basta. A ce jour aucune station de métro ne semble avoir une réf FANTOIR dans OSM, d'où aussi ma question de savoir si c'est volontaire. La même question peut se poser sur un hôpital (ex : hôpital de la Salpêtrière), un cimetière (ex : cimetière du Montparnasse), une gare... Oui, rajouter le ref:FR:FANTOIR directement sur les objets (ici les stations, en node ou en relation), pourquoi pas. En l'état ça ne devrait pas suffire pour permettre le rapprochement, car côté lieux-dits on cherche explicitement un tag name ET un tag place. Mais l'idée, hormis pour le tag ref:FR:FANTOIR lui-même, a toujours été d'adapter BANO à OSM et pas l'inverse. Donc il faudra côté BANO élargir le critère de recherche des lieux-dits (au sens FANTOIR du terme) dans OSM pour provoquer des rapprochements. Un assouplissement pourrait être notamment de chercher un tag place OU un tag ref:FR:FANTOIR. Ça fonctionnerait pour un metro, mais aussi un hôpital ou un cimetière comme tu l'évoques. => https://github.com/osm-fr/bano/issues/131 J'ai traité le cas, en élargissant aux objets dôtés conjointement des tags name=*, ref:FR:FANTOIR=* et d'au moins un tag parmi amenity=* et railway=*. Par un effet de bord, les metros du XIIIe et l'hôpital de la Pitié se retrouvent non plus dans les lieux-dits, mais dans les "voies sans adresse" : http://cadastre.openstreetmap.fr/fantoir/#insee=75113=3 vincent ___ 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] FANTOIR et métro parisien ?
Bonjour, A mes heures perdus j'essaie de forcer le rapprochement des données cadastres avec OSM via Osmose ou le site cadastre.openstreetmap.fr <http://cadastre.openstreetmap.fr>. Et il s'avère que certaines stations de métro parisiennes (pas tous ?) ont un numéro FANTOIR et apparaissent dans l'onglet des Lieux-dits. Ex : http://cadastre.openstreetmap.fr/fantoir/#insee=75113=4 La question à 5 sous : est-ce que rajouter à ces stations (ou à la "relation définissant la station" quand elle existe, qu'on l'aime ou pas) un attribut ref:FR:FANTOIR suffit ? Faudrait-il ajouter un place=* (si oui quelle valeur ?) pour en faire un "lieu-dit" ? Ou bien il faut mettre ces deux attributs sur un node à part car le lieu-dit existe et qu'il n'est pas nécessairement restreint à la station (ex : sa surface au sens du cadastre couvrant un quartier entier alors que la station est plus petite) ? Je penche pour un ref:FR:FANTOIR sur le node station (ou la relation...) et puis basta. A ce jour aucune station de métro ne semble avoir une réf FANTOIR dans OSM, d'où aussi ma question de savoir si c'est volontaire. La même question peut se poser sur un hôpital (ex : hôpital de la Salpêtrière), un cimetière (ex : cimetière du Montparnasse), une gare... Par avance merci, Cordialement, -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a visiblement pas été lu ;) Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci. En terme de logique de tagging je verrai plutôt quelque chose comme: type=boundary (il s'agit d'une frontière qui découpe un ensemble plus grand) boundary=forest (frontière forestière) forest=section (il s'agit d'une section) Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache... [...] Tout là fait d'accord (sans rentrer dans la discussion ici : j'aime bien ta proposition, elle est plus proche de l'existant et donc plus naturelle que la proposition Section). Pour info il se trouve que j'ai eu un échange de mail avec l'auteur de la proposition Section cet été (à propos d'un cimetière que je visitais/cartographiais à l'époque) et il m'a dit qu'il n'avait pas eu le courage pour animer sa proposition jusqu'au bout. Il m'a encouragé à la retravailler voir à faire une contre-proposition, car il reste persuadé du besoin initial (parcelles forestières, sections dans un cimetière...). Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache... surtout que l'import des données est pas génial non plus car les données d'origine ne sont pas forcément bien calées... Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682 Alors là c'est drôle car pendant que tu changeais le type de relation je recalais exactement l'endroit que tu cite (ce qui m'a valu de résoudre quelques conflits d'éditions quand j'ai voulu envoyer sur le serveur). Donc en me basant sur le cadastre j'ai regroupé hier ce qui devait l'être dans la zone (je n'ai pas déplacé les frontières administratives mais les layons, chemins et bordures de forêt. Il reste encore une bonne partie du périmètre à recaler) et j'en avais profité pour ajouter un gros morceau de forêt manquant côté Yvelines (http://www.openstreetmap.org/relation/6770020). Bref il reste du boulot mais problème de rendu de parcelle réglé, je déploierai la solution sur les forêts alentours qui ont le même soucis, merci ! Cordialement LeTopographeFou Le 05/12/2016 à 23:18, Christian Quest a écrit : J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a visiblement pas été lu ;) Ces sections forestières sont bien des frontières et ça évite à osm2pgsql de chercher à savoir par une euristique imparfaite ce que sont ces multipolygones mystérieux... En terme de logique de tagging je verrai plutôt quelque chose comme: type=boundary (il s'agit d'une frontière qui découpe un ensemble plus grand) boundary=forest (frontière forestière) forest=section (il s'agit d'une section) Mais ça mérite discussion sur le wiki plutôt que d'y aller à l'arrache... surtout que l'import des données est pas génial non plus car les données d'origine ne sont pas forcément bien calées... Exemple: http://umap.openstreetmap.fr/en/map/test-rendu-osmfr_99740#18/48.53494/1.97682 Les tuiles sont en train de se remettre à jour... un peu de patience. Le 5 décembre 2016 à 22:17, <osm.sanspourr...@spamgourmet.com <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com <mailto:letopographe...@gmail.com> a écrit : Bonsoir à tous, A vrai dire je croyais que le moteur ne dessinait que les objets issus d'une requête (donc les objets connus) et pas tous les objets. Visiblement ce n'est pas le cas. Jusqu'à peu c'était le cas. J'ai vu que maintenant les "noms" des transformateurs apparaissent sur la carte. Assez absurde pour une carte générique. Entre nous, ce système de "je fais remonter les valeurs communes" me parait biaisé et n'incite pas à correctement tagger. Je préfère 100x plus un moteur de rendu stricte et exigent qui pousse à bien faire mais dessine avec ce qu'on lui donne plutôt qu'un qui interprète les données avec des attributs qui n'existent pas et dessine des relations qu'il ne connait pas (avec 50% de risque de se planter). Si le moteur ne connait pas une relation, il devrait l'ignorer. Si il lui manque une propriété, il devrait pouvoir faire sans. Dixit un gars qui n'a pas sué dans le développement de ces beaux outils :-) . Si c'est une info commune, pourquoi pas ? Je dis bien commune c'est à dire identique dans tous les membres. Sinon c'est éventuellement un candidat pour un outil d'assurance qualité (que des noms identiques ou pas de noms : peut-être que les sans noms devraient avoir le même nom, ça peut avoir du sens pour des réseaux, des trajets tels que des pistes cyclables sans nom connectés à d
Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières
Bonsoir à tous, Merci pour vos réponses. A l'heure actuelle le rendu est pire encore car j'ai (à priori) terminé de réparer les mp mal taggés. Et il apparait que si la précédente carte était plutôt bien dessinée, c'est plus par "chance" que par la qualité des mp qui existaient. Maintenant avec des parcelles "propres" (fermées, etc.) les bugs ressortent et... c'est catastrophique. Je partage globalement ton analyse Philippe (nom sélectionné arbitraire et valeur par défaut supposément erronées de area). Au delà du fait que se soient des relations non reconnues, je pense qu'il y a un comportement par défaut bizarre du rendu (ou de la moulinette qui le nourrit). Je ferai remonter les bugs à Mapnik à l'occasion (que mes dernières modifs se stabilisent). A vrai dire je croyais que le moteur ne dessinait que les objets issus d'une requête (donc les objets connus) et pas tous les objets. Visiblement ce n'est pas le cas. Entre nous, ce système de "je fais remonter les valeurs communes" me parait biaisé et n'incite pas à correctement tagger. Je préfère 100x plus un moteur de rendu stricte et exigent qui pousse à bien faire mais dessine avec ce qu'on lui donne plutôt qu'un qui interprète les données avec des attributs qui n'existent pas et dessine des relations qu'il ne connait pas (avec 50% de risque de se planter). Si le moteur ne connait pas une relation, il devrait l'ignorer. Si il lui manque une propriété, il devrait pouvoir faire sans. Dixit un gars qui n'a pas sué dans le développement de ces beaux outils :-) . Cordialement, LeTopographeFou Le 03/12/2016 à 22:17, Philippe Verdy a écrit : Ceci dit si je prend l'exemple du triangle formé entre les carrefours de la Réserve, des Grès et de Madame par les trois routes forestières de la Fresnaye, des Grès et de Madame, il y a bien un attribut highway commun, mais aucun nom commun. L'attribut highway est "remonté" au niveau de la relation mais le nom "Route Madame" (pioché au hasard entre les 3 possibles) n'a pas à l'être car il n'est pas commun: c'est bien un bogue de la conversion OSM-GIS. D'autre part, remonter l'attribut highway **linéaire** (par défaut) à la relation ne devrait pas avoir lieu non plus (les 3 chemins sont des "highway=*" qui ne sont pas tagués avec "area=yes" donc à interpréter comme "area=no" par défaut, conformément à la documentation de "highway=*"). Donc là encore un bogue de la conversion OSM-GIS. Le 3 décembre 2016 à 22:05, Philippe Verdy <verd...@wanadoo.fr <mailto:verd...@wanadoo.fr>> a écrit : Le rendu ne fait pas cette interprétation tout seul: il ne le fait que si tous les chemins membres d'une même relation partagent exactement le même attribut, et dans ce cas il rapporte cet attribut à la relation, et seulement si cette relation décrit une surface fermée (en un ou plusieurs anneaux s'il y a des enclaves). Certains attributs sont exclus de ce traitement (dont highway qui est la plupart du temps uniquement linéaire, à moins qu'il y ait aussi sur les chemins un area=yes). Ces cas de transformation sont détectés dans la validation de JOSM qui indique de taguer la relation et non les chemins membres. Ensuite si la relation n'est pas exclue comme surface par ses attributs (dont area=no), elle peut être rendue comme une surface Le 3 décembre 2016 à 18:52, JB <jb...@mailoo.org <mailto:jb...@mailoo.org>> a écrit : Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et parfois, c'est absolument impraticable dans la réalité. Et impossible à maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt qu'utiliser un chemin fermé simple ? Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au milieu, c'est Mapnik qui considère que le MP représente un chemin (highway=*) : comme il ne reconnait pas le type de multipolygone utilisé (forest=section + ref), il prend le premier way, voit un highway=*, et considère que la surface est un highway avec un multipolygone mal conditionné. Et hop. Foireux pour foireux, tant qu'à faire… JB. Le 03/12/2016 à 18:29, LeTopographeFou a écrit : Bonjour, Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais pas que...) génèrent des soucis de dessin alors qu'elles paraissent toutes homogènes en terme de tags et qu'elles sont toutes fermées. Marron, gris, blanc, transparent... ce n'est pas homogène ! A noter que je suppose que les parcelles ne sont à priori pas dessinées (sinon on verrait son numéro, il n'y aurait pas de statut "proposition", et le rendu serait
[OSM-talk-fr] Problème de représentation avec des parcelles forestières
Bonjour, Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais pas que...) génèrent des soucis de dessin alors qu'elles paraissent toutes homogènes en terme de tags et qu'elles sont toutes fermées. Marron, gris, blanc, transparent... ce n'est pas homogène ! A noter que je suppose que les parcelles ne sont à priori pas dessinées (sinon on verrait son numéro, il n'y aurait pas de statut "proposition", et le rendu serait plus homogène que cela). Voici mes constatations : * Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502 o /Route de Madame/ et /Route de la Lieue/ ne sont pas écrits le long du chemin mais au milieu de parcelles à l'horizontal (à partir du niveau de zoom 15). En consultant les ways en question, rien à signaler. Une idée ? o Il y a des zones marrons qui correspondent bizarrement aux délimitations de certaines parcelles. Sauf que ces parcelles n'ont rien de bizarre quand on regarde les tags (elles sont bien fermées et toutes ne sont pas rendues de la même manière alors qu'elles ont des tags identiques). Exemple : http://www.openstreetmap.org/relation/1866710 Une idée ? o Là on a carrément une parcelle grise : http://www.openstreetmap.org/relation/1853819 * Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment récupérer un lien vers la zone consultée...) o Beaucoup plus de chemins sont tracés avec les noms au milieu des parcelles et non le long du chemin. En fait c'est comme ci le rendu dessinait les parcelles et prenait le nom du dernier élément de la relation pour lui donner un nom de relation. Une idée ? o Il y a moins de parcelles bizarrement dessinées mais il y en a qu'en même (et on notera que ce ne sont pas les mêmes que sur OSM.org). Exemple avec celle sous "Route de la jumelle" qui apparait plus claire Résultat : c'est moche et ca fait penser zone en construction... Je me demande si la manière avec laquelle les parcelles ont été cartographiées ne perturbe pas le moteur de rendu. Ou alors c'est un bug dans le moteur de rendu ? A vous lire, Cordialement, -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag des intersections nommées en forêt
Bonjour, Merci pour vos réponses dans (et à côté de) la liste. Pour information j'ai mis à jour dans les forêts de Saint-Arnoult et celle de Dourdan les intersections nommées "Carrefour Xxxx". Le changeset : http://www.openstreetmap.org/changeset/44095448 J'ai mis à jour le Wiki : https://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dforest#Comment_cartographier_une_for.C3.AAt_.3F Pour l'instant je ne touche pas aux parcelles existantes. Cordialement, LeTopographeFou Le 30/11/2016 à 09:18, Romain MEHUT a écrit : Bonjour, Le 29 novembre 2016 à 23:17, <osm.sanspourr...@spamgourmet.com <mailto:osm.sanspourr...@spamgourmet.com>> a écrit : Dans le coin il y a d'autres trucs bizarres : http://www.openstreetmap.org/relation/1853814 <http://www.openstreetmap.org/relation/1853814> Le numéro d'une parcelle sur le terrain ? Si cet échange peut permettre d'avancer sur les parcelles forestières, voici une autre façon de faire http://www.openstreetmap.org/relation/6601581 <http://www.openstreetmap.org/relation/6601581> cf. http://wiki.openstreetmap.org/wiki/IOF_mapping#Vegetation <http://wiki.openstreetmap.org/wiki/IOF_mapping#Vegetation> Romain http://wiki.openstreetmap.org/wiki/Proposed_features/Section <http://wiki.openstreetmap.org/wiki/Proposed_features/Section> ___ 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] Tag des intersections nommées en forêt
Tu veux dire par exemple http://www.openstreetmap.org/node/1034185308
à Dourdan.
Oulà oui, je me suis emmêlé les pinceaux ! Ton lien est un bon exemple,
merci.
Si c'est un carrefour, c'est un... carrefour, pas un lieu-dit.
Un carrefour pour des voies piétonnes ?
Ça me choque moins (surtout si c'est le nom) qu'un lieu-dit.
Pour moi c'est junction=yes mais autant vérifier avant de "corriger"
cette forêt :-) .
Sauf que selon le cadastre ceci est le Carrefour de la Frenaye :
http://www.openstreetmap.org/#map=20/48.53744/1.98240
Alors "carrefour" ou "lieu-dit" appelé carrefour ?
Pour ce carrefour il a la même police de caractère et taille que pour
les carrefours correctement placés. Les "lieux-dits" sont affichés dans
un autre style dans le cadastre. Je penche donc pour un label mal placé
dans le rendu (ou la base) du cadastre, le dit carrefour devant être
dans les environs. Par déduction je dirai au nord est de la parcelle
près du "lieux-dit" (qui lui est correctement cartographié !) /La
Frénaye/, mais c'est que de la déduction hein !
Dans le coin il y a d'autres trucs bizarres :
http://www.openstreetmap.org/relation/1853814
Le numéro d'une parcelle sur le terrain ?
http://wiki.openstreetmap.org/wiki/Proposed_features/Section
Oui j'avais remarqué également, on dirait que c'est une tentative pour
cartographier les parcelles. Ne me demandez pas pourquoi certaines
parcelles apparaissent en marron...
LeTopographeFou
Le 29/11/2016 à 23:17, osm.sanspourr...@spamgourmet.com a écrit :
Tu veux dire par exemple http://www.openstreetmap.org/node/1034185308
à Dourdan.
Si c'est un carrefour, c'est un... carrefour, pas un lieu-dit.
Un carrefour pour des voies piétonnes ?
Ça me choque moins (surtout si c'est le nom) qu'un lieu-dit.
Sauf que selon le cadastre ceci est le Carrefour de la Frenaye :
http://www.openstreetmap.org/#map=20/48.53744/1.98240
Alors "carrefour" ou "lieu-dit" appelé carrefour ?
Dans le coin il y a d'autres trucs bizarres :
http://www.openstreetmap.org/relation/1853814
Le numéro d'une parcelle sur le terrain ?
http://wiki.openstreetmap.org/wiki/Proposed_features/Section
Jean-Yvon
Le 29/11/2016 à 22:35, LeTopographeFou - letopographe...@gmail.com a
écrit :
Bonjour,
Afin de nommer des intersections en forêt ("Carrefour de Xxxx",
"Poteau de Yyyy") à partir du cadastre j'utilise junction=yes
(puisque ce sont des intersections nommées...).
Exemple en forêt de Rambouillet :
http://www.openstreetmap.org/node/963477209
Mais en progressant et en allant voir dans d'autres forêts je suis
tombé sur une utilisation massive par endroits de place=locality. Par
exemple dans une forêt voisine, celle de Dourdan, où toutes les
intersections utilisent ce tag :
http://www.openstreetmap.org/node/963477209 . Certes ce sont des
lieux souvent non-peuplés et nommés mais cela ne me semble pas
optimal comme choix.
Le Wiki ne m'est pas d'une grande aide sur ce coup là et je voudrais
d'une part savoir quelle est la meilleure méthode et d'autre part en
profiter pour l'illustrer dans le Wiki. De part la définition de ces
deux tags j'ai une nette préférence pour junction=yes qui est plus
précis quant à la nature de la chose.
Ai-je raison d'utiliser junction=yes pour nommer des intersections en
forêt ?
Cordialement,
___
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] Tag des intersections nommées en forêt
Bonjour,
Afin de nommer des intersections en forêt ("Carrefour de Xxxx", "Poteau
de Yyyy") à partir du cadastre j'utilise junction=yes (puisque ce sont
des intersections nommées...).
Exemple en forêt de Rambouillet :
http://www.openstreetmap.org/node/963477209
Mais en progressant et en allant voir dans d'autres forêts je suis tombé
sur une utilisation massive par endroits de place=locality. Par exemple
dans une forêt voisine, celle de Dourdan, où toutes les intersections
utilisent ce tag : http://www.openstreetmap.org/node/963477209 . Certes
ce sont des lieux souvent non-peuplés et nommés mais cela ne me semble
pas optimal comme choix.
Le Wiki ne m'est pas d'une grande aide sur ce coup là et je voudrais
d'une part savoir quelle est la meilleure méthode et d'autre part en
profiter pour l'illustrer dans le Wiki. De part la définition de ces
deux tags j'ai une nette préférence pour junction=yes qui est plus
précis quant à la nature de la chose.
Ai-je raison d'utiliser junction=yes pour nommer des intersections en
forêt ?
Cordialement,
--
LeTopographeFou
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bâtiments inscrits MHS et WHC dans Osmose
Bonjour Frédéric, A ce jour le patch semble avoir corrigé le soucis, merci !! Cordialement, LeTopographeFou Le 11/09/2016 à 22:23, Frédéric Rodrigo a écrit : Bonjour, J'ai effectué une modification pour garder les valeurs existantes d'un tag. Si vous en voyez d'autres que les ref et source (ou c'était déjà le cas) et que heritage:operator je peux les ajouter. Pour heritage:operator ça sera opérationnel d'ici quelque jours. https://github.com/frodrigo/osmose-backend/commit/46c9d3d177c0cb982641f3a56c041c25b52c8a27 Frédéric. Le 10/09/2016 à 14:06, LeTopographeFou a écrit : Bonjour, En traitant des erreurs Osmose je suis tombé sur ce qui je pense est une erreur dans l'algo de détection et/ou de correction. Le problème semble survenir quand un monument historique est également classé à l'UNESCO. Cela donne généralement /heritage:operator=whc;mhs/ (67 résultats dans taginfo) : https://taginfo.openstreetmap.org/tags/heritage:operator=whc;mhs Je sais qu'il y a un débat sur comment représenter plusieurs valeurs (avec des [], avec un point virgule, avec...) et qu'il n'y a pas de consensus clair. Je ne souhaite pas rentrer dans ce débat, ce qui m'inquiète le plus c'est qu'Osmose, dans sa tentative d'association avec une base de donnée du ministère, croit qu'il n'a pas été associé et propose un correctif qui élimine le whc (donc un fix plutôt destructif...). Exemples : * Basilique de Vézelay (http://osmose.openstreetmap.fr/fr/error/7981644480) * Cathédrale de Bourge (http://osmose.openstreetmap.fr/fr/error/7981642652) * Cathédrale d'Amiens (http://osmose.openstreetmap.fr/fr/error/7981644547) * ... Et dans le fix proposé par Osmose il ne met pas tellement en avant que ce fix supprime l'inscription whc (et toutes les autres inscriptions éventuelles). Donc un utilisateur distrait ou non-avertit pourrait faire des erreurs pensant bien faire. Ne peut-on pas avoir un algo de détection qui tienne compte de ces cas de figures ? Du genre ne pas chercher une chaine valant strictement "mhs" mais une chaîne qui contiendrait le mot mhs. Cordialement, -- LeTopographeFou ___ 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] Bâtiments inscrits MHS et WHC dans Osmose
Bonjour, En traitant des erreurs Osmose je suis tombé sur ce qui je pense est une erreur dans l'algo de détection et/ou de correction. Le problème semble survenir quand un monument historique est également classé à l'UNESCO. Cela donne généralement /heritage:operator=whc;mhs/ (67 résultats dans taginfo) : https://taginfo.openstreetmap.org/tags/heritage:operator=whc;mhs Je sais qu'il y a un débat sur comment représenter plusieurs valeurs (avec des [], avec un point virgule, avec...) et qu'il n'y a pas de consensus clair. Je ne souhaite pas rentrer dans ce débat, ce qui m'inquiète le plus c'est qu'Osmose, dans sa tentative d'association avec une base de donnée du ministère, croit qu'il n'a pas été associé et propose un correctif qui élimine le whc (donc un fix plutôt destructif...). Exemples : * Basilique de Vézelay (http://osmose.openstreetmap.fr/fr/error/7981644480) * Cathédrale de Bourge (http://osmose.openstreetmap.fr/fr/error/7981642652) * Cathédrale d'Amiens (http://osmose.openstreetmap.fr/fr/error/7981644547) * ... Et dans le fix proposé par Osmose il ne met pas tellement en avant que ce fix supprime l'inscription whc (et toutes les autres inscriptions éventuelles). Donc un utilisateur distrait ou non-avertit pourrait faire des erreurs pensant bien faire. Ne peut-on pas avoir un algo de détection qui tienne compte de ces cas de figures ? Du genre ne pas chercher une chaine valant strictement "mhs" mais une chaîne qui contiendrait le mot mhs. Cordialement, -- LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
Bonjour à tous, Suite à plusieurs demandes j'ai fais une analyse en Europe des relations type=route et route=road (telles que définies dans le Wiki). Cela se passe ici (pour le moment) : http://wiki.openstreetmap.org/wiki/User:LeTopographeFou Je n'ai pas fais tous les pays mais une sélection de 14 pays jugés "majeurs" en Europe (si j'en ai oublié un majeur => incident diplomatique !!). Bonne lecture, LeTopographeFou Le 06/07/2016 00:28, LeTopographeFou a écrit : Bonjour, J'ai attaqué un imposant chantier visant à améliorer la prise en compte des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à : 1. Faire qu'il y ait une relation par RD par département (ex : http://www.openstreetmap.org/relation/6335278) 2. Vérifier et corrigé le tracé des RD Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc et certaines n'étaient carrément pas (ou incomplètement) référencées par leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles. Pour le moment je mets 4 tags à chaque relations (cf. http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela très optimal d'où deux points à vous soumettre : 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la logique utilisées aux EU j'ai deux propositions à faire : 1. Utiliser le code pays et le code INSEE du département (en l’occurrence cela ferait 'FR:78') 2. Faire comme précédemment mais avec également le code INSEE du département (en l’occurrence cela ferait 'FR:11:78) 3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78') 2. Concernant le tag 'name' il y a des risques d'amalgames entre deux départements. Est-il judicieux d'y mentionner le nom du département ? Le hic est que, rigoureusement parlant, le nom "officiel" est 'Route départementale 29' sans autre fioriture 1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et concis, facile à parser 2. Exemple 2 : 'Route départementale des Yvelines 29' => bof 3. Autre solution : ne rien faire, se dire que l'ajout de 'network' suffit et que si amalgame il y a c'est un problème à gérer par l'éditeur/l'app et non par le cartographe => c'est ma solution préféré mais autant réfléchir avant d'aller plus loin. A ce jour je ne vois pas de réponse ni dans les relations existantes ni sur le wiki. Qu'en pensez-vous ? LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
Jean-Yvon, Message reçu, je regarde en Europe et fais une synthèse. Cdt, LeTopographeFou Le 14/07/2016 00:12, osm.sanspourr...@spamgourmet.com a écrit : Oui un exemple *aux États-Unis*. Je préfèrerais des exemples probants en Europe car leurs méthodes comme je l'ai déjà dit, ce n'est pas forcément une référence. On voit d'ailleurs comme tu le dis toi-même is_in:state <http://wiki.openstreetmap.org/wiki/Key:is%20in:state?uselang=fr>. Philippe, les panneaux indiquent Tartempion en direction, pas D234. Et quand tu vois un panneau de direction vers D234, c'est que tu n'es pas sur la D234. Le routage ne se fait pas par des noms de routes mais par des gabarits de voirie. Comme déjà dit sur ce long fil de discussion. Si tu veux un Paris-Brest (ce n'est pas qu'un gâteau) en passant par les anciennes N12 devenues départementales... et le nom ce n'est pas le Dx12... Franchement plus j'y pense et plus je pense que c'est plus nuisible qu'utile (je ne vois pas l'usage et pourtant j'emprunte des départementales qu'on nommera "ancienne route de" (la voie express étant devenue la voie normale)). Jean-Yvon Le 13/07/2016 à 23:16, LeTopographeFou - letopographe...@gmail.com a écrit : Et là je ferais mieux de sortir un exemple sur lequel je n'ai pas fait de modification (dsl pour le spam) : http://www.openstreetmap.org/relation/1502491 LeTopographeFou ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
Merci François pour cette liste. Mes commentaires dans ton mail. Mais j'ai deux questions : * La liste de diffusion est bien pour discuter mais pas pour avoir une vue d'ensemble. Y a-t-il un media plus approprié ? Le wiki ? * Tout n'a surement pas encore été dit mais un jour il faudra se décider sinon on pourra discuter pendant longtemps :-) . Quel est le process pour à la fin aboutir à une décision équilibrée et représentative ? Cdt, LeTopographeFou Le 14/07/2016 14:16, François Lacombe a écrit : [Envoyé depuis un téléphone] Bonjour a tous, En effet discussion passionnante, pas assez de temps pour y participer pleinement cette semaine Le 14 juil. 2016 11:32 AM, "Christian Quest" <cqu...@openstreetmap.fr <mailto:cqu...@openstreetmap.fr>> a écrit : > Oui, c'est un peu le problème... se focaliser sur le "comment" alors qu'il n'y a pas de consensus sur le "pourquoi", c'est à dire sur l'utilité même de ces relations. > > Si un consensus est trouvé sur l'utilité, on pourra passer au "comment". Là on met la charrue avant les boeufs. Sous cet angle, d'accord avec toi > > Donc... quels avantages/inconvénients pour ces relations ? De ce que j'ai retenu de l'échange : CONTRE : * Une relation complexifierait l'accès a l'information et la contribution C'est indéniable vue que le premier moyen d'accès utilisé est généralement la Way. Mais sans pour autant en faire un avantage cela simplifie aussi car : * cela permet de dissocier ce qui est de "la route" de ce qui est de "la départementale". La liste des attributs de la route n'en sera que plus claire. De même pour la RD. * plus tôt un utilisateur découvre les relations plus vite il se structurera dans le modèle OSM (et moins il prendra d'habitude malheureuse). * plus le concept de relation est structurant plus les outils s'améliorent pour rendre transparente la chose. Ex de la plupart des outils qui, quand on scinde une way, mettent à jour les relations avec les rôles qui vont bien. * Les relation seraient difficilement maintenables (a mettre en perspective avec la dispo et fonctionnalités des outils) Cf. point précédent. Je ne vois pas en quoi regrouper certaines infos rend les choses moins maintenables. Cela les rend plus accessibles et synchronisées. De plus, dans la proposition actuelle où le tag ref restent dans la way et que l'on créé une relation, c'est même un très bon moyen de détecter une incohérence (Osmose, validation JOSM...). Alors que si on a que le ref... et bien bon courage pour détecter ! * Dans le cas ou on a plusieurs relations RD, transport en commun, iti bis qui impliquent le même tronçon de route, le consommateur peut avoir plus de travail pour faire le lien "la ligne de bus Y emprunte une partie de la RD X". Quoi que des outils (osm2pgsql) peuvent largement aider dans cette tache de formatage pour un usage particulier. Tant que le tag ref est conservé cela ne change rien il me semble. POUR : * Le modèle proposé est déjà utilisé dans d'autres pays et fait l'objet d'une documentation sur le Wiki (statut "in use"). 115807 relations route=road de par le monde, soit 27 % des relations de type route ! route=bus n'occupe que la seconde place (retirer les relations RD que j'ai créé a un effet négligeable sur ces chiffres). Ce point est non négligeable ;-) . * Les relations permettraient l'unicité de certaines infos (référence Dxx, iti E...) et séparerait l'empruntant de l'emprunté. Ainsi un tronçon de route restant un tronçon de route, il pourrait être utilisé indépendamment dans plusieurs relations différentes (RD, iti bis, convois exceptionnels, transports en commun et d'autres que je n'imagine pas) Oui, c'est une histoire de sémantique. Une route empruntée peut avoir une propriété différente (ou inexistante) que la RD. * Selon le format de la relation, on obtiendrait une visibilité plus claire d'un itinéraire, en reliant explicitement les tronçons impliqués * Enfin, la relation peut regrouper les objets périphériques avec un rôle spécifique (bornage, panneaux, boucles de comptage) En effet, les bornes kilométriques sont spécifiques à la RD, pas à la route qu'emprunte la RD ni à la route qui passe en parallèle à côté. Cette liste peut être complétée au besoin, désolé d'avance pour tout oubli involontaire ou formulation maladroite 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] Tag 'network' et 'name' pour une relation de type route départementale
Et là je ferais mieux de sortir un exemple sur lequel je n'ai pas fait de modification (dsl pour le spam) : http://www.openstreetmap.org/relation/1502491 LeTopographeFou Le 13/07/2016 23:12, LeTopographeFou a écrit : Bonsoir Dominique, Non non ce n'est pas un Troll. Je pousse également depuis le début pour que la solution que nous ayons ne soit pas basée sur une spécificité Française (d'où le fait que je bloque sur l'argument "une RD n'est qu'une seule ref... donc on a pas besoin de relation"). En fait c'est plus moi le Troll en ayant lancé ce sujet. Je n'ai pas une connaissance mondiale d'OSM mais j'ai une plutôt bonne expérience avec ce qui est fait aux EU. Ce que je propose est rigoureusement compatible avec ce qui est fait aux EU (ex : http://www.openstreetmap.org/relation/1502491) et ce qui est décrit sur le Wiki (http://wiki.openstreetmap.org/wiki/Relation:route). J'ai même mentionné le fait qu'aux EU ils utilisent parfois plus le tag is_in que le tag network. Des commentaires reçus (et je suis d'accord avec eux) ce n'est pas approprié et network est à préférer. Donc je ne pense pas qu'avec l'approche que nous avons ici nous soyons en train de recréer un format franco-français mais au contraire de renforcer un format déjà documenté. En fait, mis à part quelques point que nous affinons, ce que je note est d'avantage un débat "/Pour ou contre les relations dans ce cas de figure/". Cdt, LeTopographeFou Le 11/07/2016 10:00, Dominique Faure a écrit : Bonjour, Je ne voudrais pas passer par le troll de service qui vient s'immiscer dans la conversation (même si dans les faits ça y ressemble beaucoup), mais quid des situations équivalentes chez nos voisins? Sommes-nous à ce point leader dans la structuration des données d'OSM que nous sommes en train de définir le modèle de données qui devra à terme être étendu à l'ensemble de la couverture, ou s'agit-il d'une problématique franco-franchouillarde qui n'aura qu'une portée nationale ? 2016-07-11 3:03 GMT+02:00 Jérôme Amagat <jerome.ama...@gmail.com <mailto:jerome.ama...@gmail.com>>: la relation que l'on voit là :http://scigrid.de/posts/2015-Jul-02_power-relations-in-openstreetmap.html ça ressemble beaucoup aux relations utilisées pour matérialiser une ligne de bus ou plutôt une ligne de metro (peu d'intercection), il y a des arrêts, les substastions et des morceaux de route (les line) pour aller de l'un à l'autre. ces morceaux de route peuvent servir pour plusieurs relations. Par contre, je viens de regarder comment c'est fait pour le chemin de fer. il y a des relations type=route route=train qui représentent les lignes train, avec le trajet du train et ses arrêts comme pour les bus , métro... Et il y a aussi les relations type=route route=railway qui représentent plutôt les ligne du point de vue des rails avec un nom du type "ligne de truc à machin" et un ref. ça ressemble beaucoup a ce qu'on dit qu'il faut pas faire avec les routes départementales. (par contre j'ai pas l'impression, avec 3 exemple :P, qu'il y ai des doublons info sur le way et sur la relation) ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr -- Dominique ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
Bonsoir Dominique, Non non ce n'est pas un Troll. Je pousse également depuis le début pour que la solution que nous ayons ne soit pas basée sur une spécificité Française (d'où le fait que je bloque sur l'argument "une RD n'est qu'une seule ref... donc on a pas besoin de relation"). En fait c'est plus moi le Troll en ayant lancé ce sujet. Je n'ai pas une connaissance mondiale d'OSM mais j'ai une plutôt bonne expérience avec ce qui est fait aux EU. Ce que je propose est rigoureusement compatible avec ce qui est fait aux EU (ex : http://www.openstreetmap.org/relation/380309) et ce qui est décrit sur le Wiki (http://wiki.openstreetmap.org/wiki/Relation:route). J'ai même mentionné le fait qu'aux EU ils utilisent parfois plus le tag is_in que le tag network. Des commentaires reçus (et je suis d'accord avec eux) ce n'est pas approprié et network est à préférer. Donc je ne pense pas qu'avec l'approche que nous avons ici nous soyons en train de recréer un format franco-français mais au contraire de renforcer un format déjà documenté. En fait, mis à part quelques point que nous affinons, ce que je note est d'avantage un débat "/Pour ou contre les relations dans ce cas de figure/". Cdt, LeTopographeFou Le 11/07/2016 10:00, Dominique Faure a écrit : Bonjour, Je ne voudrais pas passer par le troll de service qui vient s'immiscer dans la conversation (même si dans les faits ça y ressemble beaucoup), mais quid des situations équivalentes chez nos voisins? Sommes-nous à ce point leader dans la structuration des données d'OSM que nous sommes en train de définir le modèle de données qui devra à terme être étendu à l'ensemble de la couverture, ou s'agit-il d'une problématique franco-franchouillarde qui n'aura qu'une portée nationale ? 2016-07-11 3:03 GMT+02:00 Jérôme Amagat <jerome.ama...@gmail.com <mailto:jerome.ama...@gmail.com>>: la relation que l'on voit là :http://scigrid.de/posts/2015-Jul-02_power-relations-in-openstreetmap.html ça ressemble beaucoup aux relations utilisées pour matérialiser une ligne de bus ou plutôt une ligne de metro (peu d'intercection), il y a des arrêts, les substastions et des morceaux de route (les line) pour aller de l'un à l'autre. ces morceaux de route peuvent servir pour plusieurs relations. Par contre, je viens de regarder comment c'est fait pour le chemin de fer. il y a des relations type=route route=train qui représentent les lignes train, avec le trajet du train et ses arrêts comme pour les bus , métro... Et il y a aussi les relations type=route route=railway qui représentent plutôt les ligne du point de vue des rails avec un nom du type "ligne de truc à machin" et un ref. ça ressemble beaucoup a ce qu'on dit qu'il faut pas faire avec les routes départementales. (par contre j'ai pas l'impression, avec 3 exemple :P, qu'il y ai des doublons info sur le way et sur la relation) ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> https://lists.openstreetmap.org/listinfo/talk-fr -- Dominique ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
Bonsoir JB, Décidément, quand on ne dit pas ce qu'il arrive à un tag certains pensent qu'il est supprimé, d'autres qu'il est conservé... Précision/Rappel : il n'a JAMAIS été dans mon intention de déplacer/changer/supprimer/duppliquer les tags highway dans les relations que je propose. Je suis d'accord à 200% que cela n'aurait aucun sens et nous sommes tous d'accord sur ce point il me semble... C'est d'ailleurs pour cela que dans ma synthèse il n'apparait qu'au niveau des ways. Je ne vois pas comment être plus clair. Pour ce qui est du name : pas d'affolement, on discute et j'essaie de rassembler les points de vue (cf. synthèse) pour éviter qu'ils ne se noient dans nos très (trop ?) longs et construits échanges. Rien n'est acté pour le moment (ou alors que l'on me dise qu'un mail sur cette liste de diffusion fait office de loi !). J'ai précisé dans ma synthèse que ce tag était facultatif, l'interdire est un extrême qu'il faut éviter. Pour le moment j'ai eu en effet pas mal de personnes qui trouvaient cet attribut inutile si rempli par défaut mais utiles dans quelques cas de figures. Ne le jugeant pas personnellement indispensable (et c'est aussi ce qui ressort de vos commentaires), je l'ai mis en facultatif. Je ne vois pas comment être plus clair. Alors je veux bien que l'on me vois comme un aveugle ou un gars de "mauvaise foi" mais merci de lire sereinement mes mails, aussi longs soient-ils, avant de porter un jugement. Là où je veux bien que l'on me taxe de borné c'est sur le fait que ma proposition reste sur la création de ces relations. Oui, j'ai quand même des convictions que j'essaie de défendre. Désolé par ailleurs si le sujet passionne autant les foules. Non moins cordialement, LeTopographeFou Le 10/07/2016 20:40, JB a écrit : Le 10/07/2016 à 19:23, François Lacombe a écrit : Oui, c'est pour ça que j'ai donné l'exemple... les relations se cassent très facilement et si on ne jardine pas en permanence se baser uniquement dessus n'est malheureusement pas fiable. Il y a pourtant tous les contours de communes qui sont décris comme ça. Personne ne serait d'accord pour indiquer le nom de chaque commune sur les tronçons de limite pour utiliser une requête overpass de la même manière. TLDR : mauvaise foi ou aveuglement ? De moi, ou des autres ? Salut François, et la liste, Autant, je suis régulièrement d'accord avec toi sur les modèles pour les lignes électriques, autant, je trouve que tu accumules la mauvaise foi sur ce sujet, en essayant de coller ton schéma électrique sur les routes pour automobiles. Pour le vraiment mauvaise foi : comparer un multipolygone administratif et une route (pour automobiles). Franchement, entre un objet qu'il serait encore plus tordu de modéliser autrement que par un MP et que les débutant n'iront pas trop trifouiller ; et une route, objet concret, visible, compréhensible matériellement, tu veux vraiment y coller la même méthodologie ? (Je propose de ne pas revenir ici sur la comparaison route avec un ref=D* et les itinéraires d'autobus, que je trouve du même acabit). La logique relationnelle que tu appliques aux lignes électriques me semble compréhensible pour plusieurs raisons : réseau cohérent, à grande échelle, facilement modélisable intellectuellement, peu touché par des débutants ou avec peu de risques de dégâts (ajouts de pylônes, affinage de la géométrie). Pour la voirie, ça reste un sujet qui devrait être abordable pour tous dès la première approche d'OSM. Est-ce qu'on veut vraiment déplacer le tag highway dans une relation ? J'espère que non, et pour moi, les autres tags non plus. Et pour l'analyse de la discussion, puisque pas grand monde n'ose mettre les pieds dans le plat, je m'y colle : je propose un modèle, tout le monde (sauf si j'ai raté quelqu'un) dit que name=Route Départementale n'est pas valable, et je le conserve dans la synthèse finale, c'est de l'aveuglement aussi ? Aller, c'était bien trop long pour ce soir, je vais dormir dessus et ne pas reparler des autres sujets abordés qui m'ont aussi fait sauter au plafond. Oui, KISS ou vous finirez par ne plus pouvoir recruter de contributeurs dans le projet, JB. ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
Remarques intéressantes.
Le tag admin_level pourrait être conservé, que l'on soit sur type=route
ou type=admin_ref.
Si on regarde le Wiki je ne vois pas où est le détournement (certes tout
le monde peut l'éditer pour y mettre ce qu'il veut... mais quand même !) :
/http://wiki.openstreetmap.org/wiki/Relation:route
A route is a customary or regular line of passage or travel, often
predetermined and publicized. Routes consist of paths taken
repeatedly by people and vehicles: a ship on the North Atlantic
route, a car on a numbered road, a bus on its route or a cyclist on
a national route. /
Et je ne parle pas de la suite de l'article en question :
http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes
Ni de l'illustration qui accompagne le tag route=road :
http://wiki.openstreetmap.org/wiki/Relation:route#Route_relations_in_use
En ce qui me concerne cela ne me choque pas qu'un itinéraire comporte
des trous. J'y ai pensé en amorçant le chantier car naturellement en
France les ronds-points sont légions ! Et je me suis dit que cela
n'enlève pas son caractère d'itinéraire balisé. Mais si la condition
sine qua none est qu'une relation de type route n'ait pas
d'interruption... alors cela clos le débat et je trouverai cela très
dommageable.
Pour ce qui est de la comparaison avec les bus... perso je ne me fixe
pas pour limite de ne prendre une ligne de bus que si c'est pour aller
de terminus à terminus. J'en prend un éventuellement en milieu de ligne,
je descend pour en prendre un autre... peu importe le nom des rues par
où il passe. C'est la même logique pour les RD/RN/A : on rentre sur une
quand il le faut, on change quand il le faut et on la quitte bien
souvent avant son extrémité. Et de la même manière que je cherche le bus
de la ligne 59, et bien je cherche à sortir du rond point sur la D 59.
Mon exemple est peut-être caricaturale mais c'est pour vous dire à quel
point personnellement je ne trouve pas que ce soit un bon argument. J'ai
même envie de dire que les lignes de bus, elles, ont eux par
l'apparition de leurs relations le bénéfice de la maturité d'OSM que les
RD, RN n'ont pas eu aux débuts d'OSM.
Et les bus ont type=route, route=bus (et non pas type=route, route=road)
donc il n'y a pas de risque de confondre.
Cdt,
LeTopographeFou
Le 12/07/2016 11:13, Art Penteur a écrit :
Il me semble assez étrange (voire néfaste) de détourner le type de
relation "route" (qui veut dire itinéraire, ou trajet, en anglais)
pour un autre usage.
Même si la plupart des départementales sont nommées "RD N de
Pétaouchnok à Trifouilly", pas grand-monde ne les emprunte en continu,
contrairement à un itinéraire, que le bus emprunte globalement d'un
bout à l'autre (avec parfois des variantes ou extensions)
Autre problème : une "route" (au sens actuel dans OSM : càd un
itinéraire) doit être continue : un bus ne "saute" pas d'une portion
de route à une autre. Une départementale n'est pas systématiquement
continue : elle s'interrompt souvent sur quelques centaines de mètres
(ou quelques kilomètres) qu'elle "partage" avec une autre route
(souvent, seul le numéro le plus pett est conservé), puis reprend à un
carrefour un peu plus loin
Donc, si on juge souhaitable de relationiser les routes
départementales, mon avis est qu'il faut créer un nouveau type de
relation. Je propose admin_ref :
Quelque chose comme :
Relation
type=admin_ref
admin_ref=road
admin_level=6
ref=D 321
Art.
Le 7 juillet 2016 à 22:23, LeTopographeFou <letopographe...@gmail.com> a écrit :
Bonjour,
Merci à tous pour vos retours. A ce que je vois les avis sont partagés. Je
vais essayer de faire une synthèse ici.
Tout d'abord je suis personnellement convaincu que les relations apportent
un niveau d'information que des tags seuls peuvent plus difficilement
apporter et maintenir... Les arguments opposables sont très intéressant à
débattre mais si la conclusion de cette discussion et de savoir si oui ou
non il faut continuer à créer ces relations, j'ai bien peur de ne pas
changer d'avis :) . Donc je continue avec le postulat que c'est souhaitable.
Toutefois quelques précisions car de ce que je lis il y a peut-être eu des
incompréhensions.
La création d'une relation ne vise pas à supprimer tous les attributs en
commun dans ses ways (surtout si ces derniers ne caractérisent pas la
relation en question). Cce serait détourner ce pour quoi le concept a été
créé. L'attribut ref=* a pour moi tout son rôle autant dans la relation que
au niveau de la way et vous noterez que je ne parle pas de le supprimer (et
que je ne l'ai pas fait). De même qu'il n'y aurait pas de sens à mettre dans
la relation des attributs tels que highway, oneway, surface, maxspeed... En
revanche il en est d'autres, jugés secondaires, qui caractérisent la RD et
qui gagneraient à être stockés en priorité dans la relation (wikip
Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
Bonjour Jean-Yvon, Ok pour les int_ref, j'ai lancé une idée peu construite, elle reste à clarifier si elle est pertinente. Pour ce qui est des moteurs de recherche, trois éléments de réponses : 1. cela sous-entend que le moteur en question soit capable de faire cette analyse, et cela avec les problématiques multiculturelles (ex : un Espagnol en France, un Chinois en Argentine, un Russe au Canada (francophone !))... Un 'D 321' en France peut potentiellement avoir un sens complétement différent ailleurs. Bref pour avoir un peu baigné dans l'analyse syntaxique et grammaticale d'un moteur de recherche c'est un sujet très pointu et malheureusement de toutes les applications, services, sites Internet... se basant sur OSM, peu sont aussi intelligents que Google. 2. OSM ne sert pas que à faire de la navigation : il y a aussi des applications autres (métier, scientifique...) qui ont besoin d'afficher des résultats, parfois au grand public, et qui voient un avantage à utiliser le champ name... 3. ... voir un champ name:xx puisque cela permettrait de donner des traductions dans différentes langues si le besoin s'en fait sentir (je ne dis pas qu'il faille le faire, à chacun de juger). /"Quant aux représentations des panneaux, c'est un style propres aux départementales, pas spécifique à une départementale."/ +1. Je suis d'accord, cela casse un peu maa logique, peut-être qu'une relation 'defaults' permettrait de faire l'affaire, mais c'est un type de relation à l'avenir incertains. En fait je ne tiens pas spécialement à mettre 'panneau noir sur jaune' dans chaque relation RD, je regrette juste que ce soit à chaque application/service à se renseigner sur chaque type de route de chaque pays et qu'il n'y ai pas moyen d'avoir cette info via OSM. Check de cohérence entre la ref et le name : pourquoi pas. Oui pour le alt_name, cf. mon 'mail synthèse'. Cdt, LeTopographeFou Le 07/07/2016 23:55, osm.sanspourr...@spamgourmet.com a écrit : Le 07/07/2016 à 22:23, LeTopographeFou - letopographe...@gmail.com a écrit : Pour ce qui est de la cohérence des données j'imagine aisément un check JOSM (ID n'intégrant pas ce concept) qui vérifie que toute way dans une relation de ce type, en France, contienne un tag ref identique, sinon un warning. Après si l'utilisateur ignore le warning... Et aussi Osmose. Sauf qu'il n'y a pas qu'un ref, il y a int_ref et autres. Certes pas pour les départementales. Le 07/07/2016 à 22:23, LeTopographeFou - letopographe...@gmail.com a écrit : . Les moteurs de recherche (OSM, Internet, dans les Apps...) sont très intelligents mais entre 'D 321' et 'Route départementale 321' ce n'est pas le même niveau d'informations. Tu peux préciser ? D, RD, Route départementale, Départementale sont équivalents. => Si on cherche la D 765 du côté de Guidel ou de Rédéné, on doit se voir proposer les D 765 du Finistère et du Morbihan. S'il y a des habitations le long de la départementale qui sont référencés non par des lieux-dits, alors leur adresse sera sans doute Route Départementale 765. Par exemple si aux niveaux des 3 pierres en Guidel le nom ne se faisait pas par le lieu-dit mais la route, ce serait la Route Départementale (du Finistère) comme associatedStreet... de cette habitation du Morbihan. Quoique, selon Fantoir, à Rédéné il n'y pas de Route Départementale 765 mais une N 165 (la voie express qui a succédé à ce qui est devenu D 765). Il me semble plus judicieux de remplacer Route Départementale par D pour la recherche. Mais avis non tranché. C'est un peu comme si je cherche la gare de X, je cherche en fait la railway=station, name=Lorient <http://www.openstreetmap.org/node/250118779> ou la name=Gare de Lorient <http://www.openstreetmap.org/way/69936531> Pour les relations type bus, il y a déjà les couleurs (des routes). Quant aux représentations des panneaux, c'est un style propres aux départementales, pas spécifique à une départementale. Et comme dit par Philippe, c'est plus la largeur de la voie, la limite de vitesse que le statut de la voie qui intéresse l'utilisateur moyen. Si on veut le modéliser, c'est au niveau de métadonnées. À stocker dans OSM ou ailleurs. Si tu ajoutes un name alors il faut vérifier que c'est Route Départementale XXX si la ref=D XXX. Plutôt un alt_name en réservant les name aux 3Route Napoléon" et autres ? Jean-Yvon ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
Bonsoir Philippe, Nous sommes d'accord. Je ne parlais pas du rendu de la route mais de son symbole tel qu'affiché sur le petit panonceau (ex : ). La couleur de ce panonceau est une info potentiellement utile. Une appli GPS pourrait avantageusement conserver cette manière de présenter l'info au lieu d'en inventer une (quitte à faire des amalgames selon les pays). Cdt, LeTopographeFou Le 07/07/2016 23:36, Philippe Verdy a écrit : Le 7 juillet 2016 à 22:23, LeTopographeFou <letopographe...@gmail.com <mailto:letopographe...@gmail.com>> a écrit : Dans un second temps je vois bien dans chaque relation des infos permettant de faire le rendu du symbol de la RD par un renderer : texte noir sur fond jaune. Mais pour le moment il n'y a pas de standard défini (tel que OSMC) donc je m’abstiens (voila un bel exemple de l'avantage des relations !). Donc à mettre de côté.. En dehors des cas particuliers des autoroutes (en France au moins), je vois mal unifier le rendu des départementales dont la structure même varie énormément, entre d'une part les 4 ou 6 voies à chaussées séparées et avec échangeurs de type autoroutier, avec bandes d'arrêt d'urgence, et des limites de vitesse à 110, un profil aplani et peu de virage, et des tas de départementales à 2 voies peu larges, sans chaussée séparée, le plupart du temps avec une ligne continue, peu de visibilité à cause des virages et des montées et descentes, plein de limitations à 70 en traversant de petits villages, plein de ronds-points et de carrefour dangereux, le tout entre deux rangées de platanes, et régulièrement envahis d'engins agricoles (même si ces départementales relient deux villes majeures). La logique d'OSM est plutôt de colorer en fonction des conditions de circulation et d'accessibilité, et la capacité de l'infrastucture en terme de trafic, mais pas en fonction des gestionnaires (collectivités publiques ou concessions privées) qui peuvent changer au cours du temps. Et une voie majeure peut devenir secondaire snas changer de numérotation quand un autre axe de plus grande capacité est construit (et peu importe la collectivité qui l'a fait souvent en partenariat avec des financements multiples): que ce soint une commune, un EPCI/une métropole, un département. Avec la montée en puissance des régions et des EPCI, il est fort probable d'ailleurs que des axes actuellement gérés par plusieurs départements se voient transférés aux régions et aux EPCI (surtout les métropoles), on aura alors des routes "régionales" et des routes "intercommunales" (gérées par les EPCI). D'autres départementales sont aussi transférées aux communes après leur fusion et là encore il y aura une grande disparité entre les différentes voies communales. Il n'est pas impossible à l'avenir que des routes très rurales soient transférées à des syndicats de gestion de parcs naturels plutôt que par plusieurs EPCI, même chose pour les routes des grandes infrastructures portuaires (ports autonomes) ou aéroportuaires (d'importance internationale). Au final les numéros de référence ne doivent être uniques que pour chaque collectivité ou organisme gestionnaire et même entre eux ces organismes peuvent se transférer des usages plutôt que d'agir en tant "qu'opérateur" local. Et cela survient de plus en plus étant donné les difficultés financières des collectivités endettées. L'état veille au grain via ses services préfectoraux qui surveillent la sécurité des axes de transport et leur adéquation avec les schémas de transport urbain qui nécessitent des collaborations. Quand cette collaboration devient trop compliquée ou dépasse les capacités de gestion de l'entité gestionnaire. Pour les usagers, peu importe qui gère une route, ce qui compte c'est son état et sa praticité, le numéro est en fait assez accessoire, c'est juste un repère sur les panneaux directionnels aux carrefours pour savoir si on est sur le bon chemin. Mais comme pratiquyeemnt tout le monde a un GPS dans son véhicule, ces numéros devront devenir de plus en plus précis pour distinguer les voies quand le nom d'une ville destination ne suffit pas à choisir son chemin. ___ 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] Lot Talk-fr, Vol 120, Parution 27
Bonjour Donat, Oui bien sur le champs old_ref peut être rempli au niveau de chaque way si nécessaire (mais je ne crois pas qu'il soit pertinent à ce stade d'avoir en plus des relations par ancienne numérotation). Par contre si une way change deux fois de numérotation... le old_ref atteint sa limite. Oui pour Wikidata. Personnellement je le fais pour d'autres types d'objets mais pas encore pour les RD car aller vérifier un à un sur Wikidata prend du temps ! Il faudra d'autres fous pour cela. Et puis si je vois l'intérêt dans le futur je ne vois pas d'application à court terme de wikidata... Cela viendra j'imagine. Cdt, LeTopographeFou Le 10/07/2016 00:25, Donat ROBAUX a écrit : De tous vos commentaires voici l'architecture minimale à laquelle j’aboutis (qui contient une relation !) : * Relation o type=route o route=road o ref=D 321 o network=FR-78:d-road o /name/ (cf. plus bas) o /wikipedia/ (de la RD) o Membres + Way # highway # ref=D 321 # /operator/ + Way # highway # ref=D 321 # /operator/ + ... En bleu ce qui existe déjà dans OSM (et qui reste inchangé : =les ways). En rouge ce qui est ajouté (=la relation). En italique ce qui serait facultatif (en espérant que la liste de diffusion ne massacre pas le style). Dans un second temps je vois bien dans chaque relation des infos permettant de faire le rendu du symbol de la RD par un renderer : texte noir sur fond jaune. Mais pour le moment il n'y a pas de standard défini (tel que OSMC) donc je m’abstiens (voila un bel exemple de l'avantage des relations !). Donc à mettre de côté... Pour ce qui est du name=* je pense que, dans le cas de la Route Napoléon (qui est d'ailleurs une RN, mais l'exemple est intéressant) c'est là ou alt_name et name_x rentrent en scène. On peut imaginer avoir name=Route Napoléon et alt_name=Route nationale 85. Les moteurs de recherche (OSM, Internet, dans les Apps...) sont très intelligents mais entre 'D 321' et 'Route départementale 321' ce n'est pas le même niveau d'informations. De même quand on visualise l'objet OSM. J'aurai donc tendance à conserver la possibilité de mettre un name pour ceux qui le jugent utile. Par contre j'ai senti un consensus derrière le fait que dans tous les cas il ne faut pas y ajouter de fioriture tel que le nom du département. Pour ce qui est de la cohérence des données j'imagine aisément un check JOSM (ID n'intégrant pas ce concept) qui vérifie que toute way dans une relation de ce type, en France, contienne un tag ref identique, sinon un warning. Après si l'utilisateur ignore le warning... A vous lire... en attendant j'ai mis en pause le chantier (même en Essonne qui reste partiellement couvert). LeTopographeFou 2 avis/suggestions générales * Pensez-vous utile de mettre un old_ref=N4? Je sais que OSM ne cartographie pas le passé, mais... * Plutôt que le lien wikipedia, je mettrais le lien wikidata. Exemple pour la N4: https://www.wikidata.org/wiki/Q922320 wikidata=Q922320. Je sais que ce n'est pas encore dans les mœurs et qu'on ne sait pas encore comment tout ca va se goupiller, mais je pense qu'il faut le faire, et pas seulement pour les routes mais pour toutes les autres infos (je pense notamment aux communes). 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] Tag 'network' et 'name' pour une relation de type route départementale
Bonjour, Merci à tous pour vos retours. A ce que je vois les avis sont partagés. Je vais essayer de faire une synthèse ici. Tout d'abord je suis personnellement convaincu que les relations apportent un niveau d'information que des tags seuls peuvent plus difficilement apporter et maintenir... Les arguments opposables sont très intéressant à débattre mais si la conclusion de cette discussion et de savoir si oui ou non il faut continuer à créer ces relations, j'ai bien peur de ne pas changer d'avis :) . Donc je continue avec le postulat que c'est souhaitable. Toutefois quelques précisions car de ce que je lis il y a peut-être eu des incompréhensions. La création d'une relation ne vise pas à supprimer tous les attributs en commun dans ses ways (surtout si ces derniers ne caractérisent pas la relation en question). Cce serait détourner ce pour quoi le concept a été créé. L'attribut ref=* a pour moi tout son rôle autant dans la relation que au niveau de la way et vous noterez que je ne parle pas de le supprimer (et que je ne l'ai pas fait). De même qu'il n'y aurait pas de sens à mettre dans la relation des attributs tels que highway, oneway, surface, maxspeed... En revanche il en est d'autres, jugés secondaires, qui caractérisent la RD et qui gagneraient à être stockés en priorité dans la relation (wikipedia ? symbol ? network ?...). Notez le conditionnel, le "en priorité" et non pas "exclusivement". De tous vos commentaires voici l'architecture minimale à laquelle j’aboutis (qui contient une relation !) : * Relation o type=route o route=road o ref=D 321 o network=FR-78:d-road o /name/ (cf. plus bas) o /wikipedia/ (de la RD) o Membres + Way # highway # ref=D 321 # /operator/ + Way # highway # ref=D 321 # /operator/ + ... En bleu ce qui existe déjà dans OSM (et qui reste inchangé : =les ways). En rouge ce qui est ajouté (=la relation). En italique ce qui serait facultatif (en espérant que la liste de diffusion ne massacre pas le style). Dans un second temps je vois bien dans chaque relation des infos permettant de faire le rendu du symbol de la RD par un renderer : texte noir sur fond jaune. Mais pour le moment il n'y a pas de standard défini (tel que OSMC) donc je m’abstiens (voila un bel exemple de l'avantage des relations !). Donc à mettre de côté... Pour ce qui est du name=* je pense que, dans le cas de la Route Napoléon (qui est d'ailleurs une RN, mais l'exemple est intéressant) c'est là ou alt_name et name_x rentrent en scène. On peut imaginer avoir name=Route Napoléon et alt_name=Route nationale 85. Les moteurs de recherche (OSM, Internet, dans les Apps...) sont très intelligents mais entre 'D 321' et 'Route départementale 321' ce n'est pas le même niveau d'informations. De même quand on visualise l'objet OSM. J'aurai donc tendance à conserver la possibilité de mettre un name pour ceux qui le jugent utile. Par contre j'ai senti un consensus derrière le fait que dans tous les cas il ne faut pas y ajouter de fioriture tel que le nom du département. Pour ce qui est de la cohérence des données j'imagine aisément un check JOSM (ID n'intégrant pas ce concept) qui vérifie que toute way dans une relation de ce type, en France, contienne un tag ref identique, sinon un warning. Après si l'utilisateur ignore le warning... A vous lire... en attendant j'ai mis en pause le chantier (même en Essonne qui reste partiellement couvert). LeTopographeFou Le 06/07/2016 00:28, LeTopographeFou a écrit : Bonjour, J'ai attaqué un imposant chantier visant à améliorer la prise en compte des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à : 1. Faire qu'il y ait une relation par RD par département (ex : http://www.openstreetmap.org/relation/6335278) 2. Vérifier et corrigé le tracé des RD Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc et certaines n'étaient carrément pas (ou incomplètement) référencées par leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles. Pour le moment je mets 4 tags à chaque relations (cf. http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela très optimal d'où deux points à vous soumettre : 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la logique utilisées aux EU j'ai deux propositions à faire : 1. Utiliser le code pays et le code INSEE du département (en l’occurrence cela ferait 'FR:78') 2. Faire comme précédemment mais avec également le code INSEE du département (en l’occurrence cela ferait 'FR:11:78)
Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
C'est en effet la méthode que j'utilise pour avoir un premier extract des RD d'un département afin de les vérifier, de les compléter et de les relier. Mais c'est laborieux et gourmand côté serveur. C'est généralement quand on n'a pas besoin de quelque chose que l'on n'en voit pas l'intérêt. Là on touche à l’intérêt d'une relation de manière générale, et il y a déjà beaucoup d'infos sur le Wiki et sur Internet. Les relations sont assez récentes et les outils ne demandent qu'à évoluer. Plus une relation aura de sens, mieux elle sera exploitée par les outils. Pour ma part c'est justement le fait de centraliser certaines informations qui les rendra plus visibles et donc moins erronées. Je fais notamment appel à vous pour m'aider à donner plus de sens (et de robustesse) à ce qui existe actuellement. En ce qui me concerne (RD) voici les avantages que je vois : 1. Eviter de répéter 10 fois les mêmes propriétés avec le risque que si elles changent pour une way les autres ne soient pas mises à jour (et des infos obsolètes il y en a dans OSM nous le savons). Certaines RD ont une page wikipédia, elles ont toutes un symbol (on pourrait faire comme osmc et préciser dans la relation que c'est du noir sur fond jaune. Ex : )... 2. Structurer les infos pour améliorer les services tiers (Mapnik, Maps.ME, OsmAnd, WIkiSaria...). Là j'en appel à la créativité dont ils font preuve. 3. Améliorer la gestion des routes pouvant avoir plusieurs valeurs dans un même tag (notamment les routes Européennes qui, si je doute qu'elles prennent des RD, passent par des RN et autoroutes). Cela engendre des conflits de tags (ex : si on admet que l'on puisse avoir deux ref, comment associer chaque ref à un network ? à une url ? à un identifiant de base de donnée externe ?...). Là on a deux relations pour un segment de route, les données sont clairement organisées. 4. Tout simplement pouvoir rendre accessible une donnée au commun des mortels qui ne maîtrise pas les arcanes du système. Ce chantier est notamment venu du fait que je voulais voir le tracé de plusieurs RD en particulier et que le seul moyen était de passer 1h à composer une requête Overpass ! Là en un lien OSM permet de visualiser une RD avec toutes les informations associées. Wikipédia (ou autre) peut pointer dessus et vice-versa. Alors oui bien sûr il y a un risque d'avoir des données cassées... c'est inévitable, avec ou sans relation j'en ai bien peur. LeTopographeFou Le 06/07/2016 16:13, Pierre-Yves Berrard a écrit : Le 6 juillet 2016 à 15:27, Jérôme Amagat <jerome.ama...@gmail.com <mailto:jerome.ama...@gmail.com>> a écrit : Je comprends pas l'utilité de ces relations. si on veux toute la D X du département Y, toute les info sont déjà dans les limites de département et dans le ref des routes. Des relations qui servent pas à grand chose c'est surtout des relations qui seront vite cassées. +1 ___ 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] Tag 'network' et 'name' pour une relation de type route départementale
En effet. Pour le moment j'ai pris le parti de faire des relations différentes et de ne pas tout mettre dans la même. C'est un choix arbitraire de ma part, qui peut être changé, motivé tout simplement par le fait que pour moi si ils sont référencés avec des suffixes de particularité, c'est qu'il doit y avoir un intérêt à les dissocier. LeTopographeFou Le 06/07/2016 12:27, Philippe Verdy a écrit : L'ennui c'est que localement la référence change (on a des sections avec des lettres supplémentaires qui font pourtant partie de l'itinéraire de la départementale qui a la référence simplifiée. Cela survient notamment dans les sections à sens de circulation séparés, parfois même à plus d'1 kilomètre d'écart (dans un sens on traverse un village, par une rue à sens unique, dans l'autre on prend une bretelle de contournement... Ces deux sections sont lettrées différemment, aucune des deux n'a la référence simple de la départementale) Le 6 juillet 2016 à 11:45, François Lacombe <fl.infosrese...@gmail.com <mailto:fl.infosrese...@gmail.com>> a écrit : Le 6 juillet 2016 à 11:33, JB <jb...@mailoo.org <mailto:jb...@mailoo.org>> a écrit : Pour ma part, je ne suis pas fan des relations non plus. Si elles sont élégantes sur le plan de la modélisation, elles sont peu accessibles aux nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation + ref sur certains tronçons. Vu la quantité de données croissante, les nouveaux mappeurs vont de plus en plus devoir s'adapter à une modélisation qui reste stricte pour organiser toute cette connaissance. On ne peut pas se passer des relations, mais on est pas obligé de commencer par ce domaine quand on arrive sur osm. Par contre sur la redondance ref sur le chemin et sur la relation, je croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas aller chercher dans la relation pour dessiner le chemin et ne sait pas rendre des relations sur la base de la géométrie de ses membres). A moins que ça ait changé ou que je me trompe complètement ? François ___ Talk-fr mailing list Talk-fr@openstreetmap.org <mailto: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] Tag 'network' et 'name' pour une relation de type route départementale
Sauf erreur de ma part OSM ne contient pas (encore) d'arbre des pays, régions, départements, cantons... ce ne sont pour le moment que des relations indépendantes, mises à plat, qui sont différenciées par leurs tags admin_level et cie. Et ce sont davantage des frontières que des départements, régions... En effet il me parait bizarre de mettre tout (routes, écoles...) "en vrac" dans les relations existantes, même avec les rôles qui vont bien. La solution 1.5 est de toute la plus élégante mais aussi la plus ambitieuse par rapport à ce qui existe. Elle dépasse cette simple discussion sur les RD et nécessiterait une discussion plus globale. Vous m'emmenez sur un terrain que j'affectionne mais que je n'imaginais pas proposer à ce stade. Toutefois c'est en visant loin que l'on évite de piétiner. Elle présente l'avantage de ne plus nécessiter de champ network dans le cas présent (RD). En gros, on aurait : * Relation France o Une relation frontière avec pour rôle 'boundary' (relation actuelle) o Une capitale* o Un admin_level o Une relation par région avec pour rôle 'territory' (ou autre tag générique) + Une relation frontière avec pour rôle 'boundary' (relation actuelle) + Un chef lieu* + Un admin_level* + Une relation par département avec pour rôle 'territory' (ou autre tag générique) # Une relation frontière avec pour rôle 'boundary' (relation actuelle) # Un chef-lieu* # Un admin_level # Une relation par route départementale avec pour role 'road' ou 'route' ou que sais-je. Pas besoin de lui mettre un network : le simple fait d'appartenir à un département suffit * Way 1 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) * Way 2 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) * ... # Une relation par ligne de bus départemental # Une relation par ville (à moins qu'il faille intercaler les cantons) * ... et ainsi de suite... vous avez saisi l'idée je pense o Une relation par route nationale avec pour role 'road' ou 'route' ou que sais-je + Way 1 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) + Way 2 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) + ... o Une relation par autoroute avec pour role 'road' ou 'route' ou que sais-je + Way 1 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) + Way 2 avec le tag ref qui va bien (pour compatibilité avec les outils actuels) + ... * dans un premier temps en doublon de celui dans la boundary Mais j'ai peur que ce soit trop pour mon déjà très ambitieux chantier. Et pour faire bien il faudrait que tous les pays utilisent la même archi sinon les outils galéreront. Donc c'est une discussion qui ne peut avoir lieu ici. Si les OSMiens initiés pense que c'est judicieux je peux faire une proposition dans ce sens sur le wiki en prenant la France pour terrain d'étude. Les bonnes nouvelles : aux vues de ce qui se fait actuellement il n'y a pas de consensus et c'est quelque chose qui peut être déployé progressivement sans perte de compatibilité tout en conservant les network et autres is_in actuels. La France commencerai à se structurer d'une belle façon. LeTopographeFou Le 06/07/2016 11:40, François Lacombe a écrit : +1 Avec Francescu sur le is_in : on a les relations pour ça, à minima l'analyse spatiale. Également sur le fait de traduire une arborescence dans les tags, c'est pas forcément adapté. Ici la route départementale est effectivement dans un périmètre fermé correspondant à la région, inutile de le faire transparaitre dans le code. Ajouter ces infos dans les tags facilite la recherche c'est certain, mais ça pose autant de problèmes pour la maintenance (cf fusion des régions). Parce qu'on pourrait faire pareil avec le millefeuille : canton, arrondissement... Et aussi on aurait du mal à traduire un cas où une route quelle qu'elle soit est partagée sur plusieurs territoires. Si des codes ISO sont disponibles, autant les utiliser sans inventer autre chose Et dans ces codes ISO si il y a le code pays, région ou autre, ca devient le problème de l'ISO et pas celui d'OSM. Il y a un compromis à trouver entre grouper des objets selon une valeur de tag et utiliser une relation. Ta proposition 1.5 est intéressante. Si je comprends bien, tu indiquerais network=* sur cette méta-relation ? Résultat quand deux départements fusionnent : un seul objet à modifier et pas 300. L'édition de cet unique objet est cependant peu aisée vu le nombre de membres potentiel
[OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
Bonjour, J'ai attaqué un imposant chantier visant à améliorer la prise en compte des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à : 1. Faire qu'il y ait une relation par RD par département (ex : http://www.openstreetmap.org/relation/6335278) 2. Vérifier et corrigé le tracé des RD Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc et certaines n'étaient carrément pas (ou incomplètement) référencées par leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles. Pour le moment je mets 4 tags à chaque relations (cf. http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela très optimal d'où deux points à vous soumettre : 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la logique utilisées aux EU j'ai deux propositions à faire : 1. Utiliser le code pays et le code INSEE du département (en l’occurrence cela ferait 'FR:78') 2. Faire comme précédemment mais avec également le code INSEE du département (en l’occurrence cela ferait 'FR:11:78) 3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78') 2. Concernant le tag 'name' il y a des risques d'amalgames entre deux départements. Est-il judicieux d'y mentionner le nom du département ? Le hic est que, rigoureusement parlant, le nom "officiel" est 'Route départementale 29' sans autre fioriture 1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et concis, facile à parser 2. Exemple 2 : 'Route départementale des Yvelines 29' => bof 3. Autre solution : ne rien faire, se dire que l'ajout de 'network' suffit et que si amalgame il y a c'est un problème à gérer par l'éditeur/l'app et non par le cartographe => c'est ma solution préféré mais autant réfléchir avant d'aller plus loin. A ce jour je ne vois pas de réponse ni dans les relations existantes ni sur le wiki. Qu'en pensez-vous ? LeTopographeFou ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
