Re: [OSM-talk-fr] Mesure d'une distance à vol d'oiseau
En géographie, normalement on calcule la distance à vol d'oiseau sur l'ellipsoïde. L'ellipsoïde utilisée est celle utilisée par le système WGS84. La distance est alors la longueur de la ligne géodésique. Ce site [1] (en anglais) fait ce calcul. Il trouve bien le chemin par un pôle quand les deux points sont diamétralement opposés sur l'équateur. Le site propose également le calcul de points intermédiaires sur la géodésique. Ce site [2] dessine des grands cercles sur une carte pour un globe sphérique. Le site [1] a un lien (que je n'ai pas essayé) vers une page qui dessine des géodésiques sur un carte. [1] https://geographiclib.sourceforge.io/scripts/geod-calc.html [2] https://www.greatcirclemapper.net/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?
Des relations intermédiaires pour les tronçons, c'est proposé depuis longtemps par Jo (Polyglot). [1][2][3][4][5][6] Je suis d'accord avec Jo que ça serait une bonne idée. Surtout, ça simplifierait l'édition de la voirie et réduirait les problèmes de casse de relations. Et le maintien des relations d'itinéraire serait souvent moins de travail. Un exemple des problèmes du système actuel - J'ai introduit des ponts dans la ligne du chemin de fer à l'ouest d'Agde (34) [7] et ça a entraîné la modification de 13 relations d'itinéraire. La plupart des relations comptaient plus de mille membres. J'ai fait les itinéraires de bus d'Agde de cette façon. Ça marchait très bien avec le rendu Transport d'Andy Allan. Mais ça provoquait des erreurs signalées par Osmose. L'utilisateur chamdam est venu tout refaire «comme il faut» (et sans me contacter). Vous voudrez peut-être voir comment je l'ai fait. Alors, faites cette requête du serveur Overpass allemand pour l'état de la base en 2022. Je la donne pour l'outil curl à la ligne de commande mais vous pouvez la modifier pour d'autres outils. curl -H "Accept-Encoding: gzip" -g -o Agde_2022.osm.gz 'https://overpass-api.de/api/interpreter?data=[date:"2022-10-26T00:00:00Z;];(node(43.27,3.44,43.32,3.53);%20<;node(w);rel(id:2720050,2810674,3854048,14732422););out%20meta;' (C'est la seule façon que j'ai trouvé d'obtenir les relations route_master. Toutes les autres choses que j'ai essayé donnent un timeout.) À noter que JOSM ouvre les fichiers .osm.gz tel quel. Aussi, les arrêts ne sont pas dans les relations tronçon, ils restent dans les relations du parcours entier. Chaque chemin est membre d'un maximum de deux relations d'itinéraire de bus. [1] https://lists.openstreetmap.org/pipermail/talk-transit/2012-July/001626.html [2] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/069587.html [3] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/069776.html [4] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070281.html [5] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070286.html [6] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070302.html [7] https://www.openstreetmap.org/changeset/67851999 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème Centipede
Le problème est résolu grâce à Stéphane Péneau. J'avais mis centipede.fr au lieu de caster.centipede.fr pour l'adresse du caster. Drôle d'effet quand même, qu'avec la mauvaise adresse on obtient les bases Trimble (30) et pas les bases ublox F9P (400+). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Problème Centipede
J'ai trouvé un problème avec le serveur Centipede. J'ai essayé quatre bases. Deux - AGDE et SETE - avec récepteur Trimble, marchent. Deux - ASAGI et CETTE - avec récepteur ublox F9P, ne marchent pas. Toutes sont marquées actives sur la carte Centipede. Mais les deux qui ne marchent pas sont absentes de la liste du caster (caster table). J'ai essayé de saisir ASAGI et CETTE avec deux clients différents. Avec Bluetooth GNSS (Android) le flux démarre et s'arrête toutes les quelques secondes et on obtient peu de paquets. Avec RTKLIB STRSVR il y a une erreur no mountp. Comment puis-je signaler ce problème? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV
Il y a deux ans environ, je voulais couper des chemins (ways) de chemin de fer pour introduire des ponts. Ces chemins étaient membres de plus que dix relations d'itinéraire. Comme toi, j'ai vu qu'il y avait deux genres de relation. Il y avait les itinéraires d'infrastructure, comme la ligne de Combs-la-Ville à Saint-Louis. Et il y avait les itinéraires passagers, les voyages sans correspondance proposés par la SNCF, comme le TGV 752. J'ai remarqué que les itinéraires passagers reflétaient l'état d'il y a cinq ans ou plus. Les relations étaient un vrai désordre. Toutes étaient cassées à multiples endroits avec des types diverses d'erreur. Quelques-unes étaient très longues avec jusqu'à trois mille membres. Le format de toutes les relations est un hybride de v1 et v2 des transports en commun. Il y a une liste des gares, et une liste des chemins dans les deux sens (sauf voie unique), sans les rôles forward ou backward. Les listes des chemins comprennent des blocs alternés de chemins dans le sens aller et chemins dans le sens retour. Les relations d'infrastructure contiennent souvent toutes les voies des gares, y compris les voies de garage et d'évitement. Les relations passagers contiennent souvent toutes les voies par lesquelles les trains pourraient passer par les gares. Je pense que les relations ont été créées ainsi par des enthousiastes des chemins de fer. Mais je n'ai pas cherché qui, ou pourquoi, ou si c'est documenté quelque part. J'ai passé des heures à faire une réparation partielle des plus-que-dix relations, sans changer le format. Une réparation entière aurait fallu beaucoup trop longtemps. Ainsi j'ai pu introduire les ponts sans empirer le bordel. À mon avis, un tel cas a besoin d'une méthode différente de cartographier les itinéraires. Les relations d'itinéraire devraient avoir comme membres, d'autres relations: des tronçons d'itinéraire. Ça pourrait être fait avec ou sans des relations superroute. On arriverait à une grande simplification. Et alors, que faire? Mettre en bonne état et à jour seulement les relations qui passent par ton coin, est un très grand boulot. Et en idéal, il faudrait discuter avec ceux qui cartographient les chemins de fer, quel est le format préféré des relations. Les relations sont utilisées par https://www.openrailwaymap.org/ et https://magosm.magellium.com/portail/#/carte p.ex. Supprimer des relations serait dommage, vu le temps que plusieurs contributeurs ont passé à les créer. À mon avis, il faudrait améliorer ou mettre à jour; ou bien laisser tel quel. À noter qu'il y a toujours des liaisons directes Lyon - Barcelone. Mais pas Lyon - Bordeaux, ça va plus vite maintenant via Paris que via Montpellier! Un projet du mois, peut-être? Mais je me demande s'il y aurait assez de contributeurs intéressés. Et comment découvrir la gamme des itinéraires passagers, vu qu'il n'y a plus de fiches horaires TGV disponibles en ligne? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR
Je n'ai pas vu un libellé FANTOIR changer, jusqu'à l'année dernière. Et puis Janvier 2019 340030085U CHE DE L ANGE GARDIEN 340030748P CHE DES EMPETRES 340032011M CHE DES FLAMANTS ROSES 340032028F IMP DE LA SAGUE 340032306H RUE VIGNIER Novembre 2019 340030085U IMP DE L ANGE GARDIEN 340030748P IMP DES EMPETRES 340032011M IMP DES FLAMANTS ROSES 340032028F IMP DE LA SAGNE 340032306H RUE CLAUDE VIGNIE En chaque cas, la mairie a changé le nom de la voie par arrêté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retrouver facilement le changeset ayant supprimé un objet
+1 Après quelques recherches - j'ai fouillé le changeset ayant crée les bâtiments voisins... J'ai l'impression que le bâtiment du 11 Rue Louis Bonnet a été manqué lors de l'import du Cadastre, et qu'il n'a jamais été dans la BDD OSM. Pour le problème en général, il n'y a pas de moyen simple (sauf Potlatch 1 si ça marche toujours). L'installation allemande d'Overpass contient tout l'historique depuis le changement de la licence en 2012. Le meilleur qu'on peut faire, c'est comme Marc. Télécharger des extraits de l'état de la BDD à des dates choisies. Ouvrir les extraits avec JOSM et trouver l'objet avant qu'il fut supprimé. Maintenant vous avez l'id de l'objet. Télécharger l'historique de l'objet pour trouver le changeset ayant supprimé l'objet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import OSM -> GeoServer Luxembourg et la grande région
Avec cette requête à l'Overpass API [1] curl -H "Accept-Encoding: gzip" -g -o 49.33_5.73_50.18_6.68.osm.gz 'https://overpass-api.de/api/interpreter?data=(node(49.33,5.73,50.18,6.68);%20<;node(w););out;' j'ai obtenu un fichier de 80Mo (550Mo décompressé) en 2 minutes environ. Le fichier ne contient pas les relations parents des relations, donc tu n'auras pas les superroute et route_master p. ex. Mais tu n'en as peut-être pas besoin. Si la zone que tu souhaites dépasse les limites de l'Overpass API, je conseille ainsi. Télécharger http://download.geofabrik.de/europe/luxembourg-180708.osm.pbf http://download.geofabrik.de/europe/belgium-180708.osm.pbf http://download.geofabrik.de/europe/france/lorraine-180708.osm.pbf http://download.geofabrik.de/europe/germany/rheinland-pfalz-180708.osm.pbf http://download.geofabrik.de/europe/germany/saarland-180708.osm.pbf En choisissant des fichiers avec la même date dans le nom plutôt que -latest, tu assures que les fichiers ont tous été découpés du même fichier maître. Ceci, à son tour assure qu'on peut fusionner les fichiers sans trou, sans doublon, et sans conflit. (La date est un exemple.) Fusionner les fichiers et clipper selon un polygone avec osmconvert [2]. Osmconvert est beaucoup plus rapide qu'osmosis et beaucoup plus facile à installer qu'osmium [3]. J'ai fait ce que je conseille avec succès, avec les fichiers France et Grande-Bretagne, en utilisant osmconvert. [1] https://wiki.openstreetmap.org/wiki/Overpass_API [2] https://wiki.openstreetmap.org/wiki/Osmconvert [3] https://wiki.openstreetmap.org/wiki/Osmium Adrian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Géodésiques IGN dans Osmose
Il y a quelque temps, j'ai fait deux noeuds conformément au wiki. Ce n'est pas facile. https://www.openstreetmap.org/node/518577471 - Sète, Mt St-Clair https://www.openstreetmap.org/node/3104840629 - Agde, Mt St-Loup J'ai fait les noeuds à partir des fiches IGN telles qu'elles étaient, 3430109 point a et 3400305 point a. (Les bornes sont toutes les deux détruites mais elles donnent une bonne idée de l'altitude des sommets.) Les fiches donnent les altitudes par rapport au NGF-IGN 1969. L'IGN fournit une grille qu'il faut interpoler, RAF09, qui donne l'hauteur du zéro IGN69 au dessus de l'ellipsoïde IAG-GRS 1980. Donc il s'agit d'un ellipsoïde, GRS80, d'un géoïde, EGM96, et d'un système altimétrique, IGN69. J'ai fait ainsi (en mètres). Mt St-Clair Mt St-Loup Hauteur zéro IGN69 p.r. à GRS80 49.52 49.39[RAF09] Hauteur géoïde EGM96 p.r. à GRS80 50.20 50.12[1] Altitude IGN69 (depuis la fiche) 175.6 112.8 Altitude GRS80 (par RAF09) 225.12 162.19 Altitude EGM96 174.92 112.07 [1] https://geographiclib.sourceforge.io/cgi-bin/GeoidEval Dans la zone de ces noeuds, la différence entre l'altitude IGN69 et l'altitude EGM96 est environ 0,7m. À noter que les fiches IGN emploient toujours la grille vieille RAF98. La différence RAF09-RAF98 est 5cm dans la zone de ces noeuds. Il vaut mieux ne pas extraire les altitudes GRS80 des fiches - l'altitude IGN69 est le chiffre de base et l'altitude GRS80 est un chiffre dérivé. Hauteur zéro IGN69 p.r. à GRS80 49.47 49.34[RAF98] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib
J'ai l'impression que très peu des OSMeurs savent que les positions WGS84 changent d'une année à l'autre. Le déplacement est de 25mm par an (au millimètre près). Ça fait déjà 25cm pendant les dix années d'OSM. C'est à cause du mouvement de la plaque tectonique européenne. Ce changement ne conviendrait pas à ceux qui gèrent le Cadastre, ni aux agences nationales de la cartographie comme l'IGN. Donc les agences européennes ont fait un accord sur le système ETRS. Elles ont pris les coordonnées WGS84 telles qu'elles étaient au 1er janvier 1989. Depuis, les coordonnées ETRS suivent le mouvement de la plaque tectonique. Ce qui fait que la différence entre WGS84 et ETRS est maintenant presque 70cm. La version officielle française de ETRS est RGF93. Les fiches IGN donnent l'impression que WGS84 et RGF93 sont la même chose mais ce n'est pas vrai. Les fiches IGN sont exprimées en RGF93. Comme ça, les chiffres ne changent pas au fil du temps. Le Cadastre, quand il est de bonne qualité, est calé sur RGF93. Donc OSM en France est forcément calé aussi sur RGF93. Moi aussi, j'ai un GPS de haute performance (u-blox NEO-7P avec PPP, pas RTK), et il a fallu déplacer les traces 50cm vers l'ouest et 40cm vers le sud pour accorder avec le Cadastre. Je crois que personne qui a à faire avec OSM, veut penser comment prendre en compte le mouvement des plaques tectoniques. Bien entendu, 70cm n'explique pas un écart de 2,4m. Mais il est clair qu'il y a besoin de savoir quelle est la référence des corrections. La référence du résultat sera la même que la référence des corrections. Dans le cas de mon NEO-7P, les corrections viennent des satellites EGNOS, et la référence est ITRF2011 (le même que WGS84 à quelques centimètres près). L'altitude est toute autre chose parce qu'il y a l'ellipsoïde, puis il y a un modèle du géoïde, puis il y a le zéro de l'IGN. J'ai acheté le NEO-7P chez u-blox https://www.u-blox.com/en/product/evk-7 J'ai mis le GPS en mode PPP (positionnement précis des points). L'inconvénient principal est qu'il y a besoin d'une bonne vue du ciel pour obtenir la meilleure précision, surtout il y a besoin de voir au moins un des satellites EGNOS. Ceux-ci sont en orbite géostationnaire, donc ils sont vers le sud à une hauteur d'environ 35°. L'avantage est que le récepteur est autonome. Comme antenne, j'ai utilisé le Tallysman TW2710 acheté chez Digi-Key. Je trouve cette antenne (et le TW2410) très bonne, elle est très sensible et elle rejette très bien les échos à un nombre impair de reflets. On dit que l'antenne marche mieux montée sur un disque en métal d'un diamètre de 10cm https://www.optimalsystem.de/os.aspx?x=4113 et c'est vrai - j'ai vérifié. L'antenne est montée par un aimant très fort, qui va démagnétiser les pistes magnétiques des cartes bancaires et des tickets de métro, et qui va magnétiser, même peut-être détruire les boussoles électroniques comme dans les smartphones. Je conseillerais d'acheter la version non-magnétique de l'antenne, avec NM dans le numéro du modèle. Celle-ci est montée avec des vis d'un type américain; ce sont les mêmes vis que celles employées pour monter les disques durs 3,5 pouces. Avec une bonne vue du ciel, j'ai obtenu un ECP (CEP en anglais) de 35cm. Et les traces sont belles. Adrian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Suppression de landuses
Un contributeur a supprimé plusieurs polygones 'landuse'. La plupart, mais pas tous, sont des données Corine (CLC). Voir, par exemple https://www.openstreetmap.org/changeset/37751550 https://www.openstreetmap.org/changeset/37727275 https://www.openstreetmap.org/changeset/37727114 Ici il a supprimé un des quatre 'inner' et le 'outer' d'un multipolygone. https://www.openstreetmap.org/changeset/37726551 Ici il a supprimé deux polygones, dont un était le 'outer' d'un multipolygone avec six 'inner'. La relation multipolygone est tagguée landuse=vineyard. En conséquence, des zones bâties des communes de Florensac, Pomérols et Pinet (34) sont devenues des vignobles dans le rendu principal de la carte (openstreetmap.org). https://www.openstreetmap.org/changeset/37712462 https://www.openstreetmap.org/changeset/37700255 Ici suppression 7 jours après la création. Il y en a peut-être d'autres. Je n'ai pas cherché plus loin dans le passé. Au premier coup d'oeil, les autres changements faits par ce contributeur paraissent raisonnables. Il a même ajouté des tags sur une relation multipolygone (1600920) mais peut-être avec iD on ne voit pas si on taggue une relation ou un chemin. Je ne m'y connais pas vraiment quand il s'agit des landuses. Je souhaite vos avis sur ce que le contributeur a fait. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
