En plus les arrondis des rayons sont différents: - 6366,000 km pour la formule PHP - 6378,137 km aux pôles et - 6356,752 km à l'équateur pour la formule Python
Près de 20 kilomètres d'écart entre les deux dernières, ce n'est pas rien et c'est TRES significatif (la formule simplifiée en PHP n'en tient pas compte). La différence est de l'ordre de 1/3000 C'est suffisant comme différence pour ne pas pouvoir distinguer deux points dans OSM ; comme si on passait d'une carte à précision décimétrique (OSM) à une carte de précision seulement kilométrique (ou hectométrique aux latitudes moyennes). Si on n'en tient pas compte, il ne sert alors plus à rien de donner le résultat obtenu sur le chemin total avec une précision décimétrique, les derniers chiffres étant tous complètement faux. Au mieux on ne peut arrondir le résultat qu'à 100 mètres près (c'est pas si mal, mais ça passe mal pour mesurer des objets plus petits qu'un itinéraire routier, par exemple le rayon d'un rond-point, la longueur correcte d'une rue de quelques centaines de mètres, ou obtenir une distance asez précise entre deux points de visées). Pour des distances d'approche ou de sécrité en vol à basse altitude, on peut rater la piste et se poser loin ou se crasher (pas les avions de ligne qui ont de bons instruments et un guidage imposé depuis le sol, et n'aterrissent que sur des aéroports bien balisés, mais pour la navigation amateur sur des petits aérodromes c'est plus problématique, l'approche se fait surtout à vue et on a besoin de pouvoir localiser précisément ce qui est autour: la précision décimétrique ou au minimum métrique, mais surtout pas kilométrique, est nécessaire même si pour l'itinéraire entier sur des centaines de kilomètres la différence n'est pas très significative...) Cependant si on veut optimiser le calcul des distances, pour mesurer les longueurs de ways, on a aussi intérêt à faire la transformation des coordonnées cartographiques(avec ou sans altitude) en coordonnées cartésiennes une seule fois et non deux fois pour chaque point intermédiaire, les formules ne sont pas rapides car on le fait sur des centaines ou des milliers de points. Une boucle parcourera chaque point d'un chemin en les convertissant tout de suite en cartésiennes, puis on ne garde que les cartésiennes dans la boucle. Sur une appli interactive, la différence de temps se fait vite sentir sur les chemins longs avec ne nombreux points. Il fallait le préciser pour que les formules ne soient pas utilisées sans précaution : on doit savoir ce qui est une approximation et quelles en sont les limitations pour ne pas les appliquer à tout. D'ailleurs c'est sur la mesure des petits objets qu'il faut plus de précision d'autant plus qu'on n'a pas beaucoup de noeuds pour les définir et que leur géométrie est déjà approximative avec de nombreux virages dessinés avec des angles trop importants qui parfois font même des segments sortant complètement de la chaussée Autre exemple, mesure d'une distance entre un panneau et un carrefour dans un virage : sur un assistant de navigation cela fait une différence dans le temps que met le navigateur à nous avertir de l'approche d'un carrefour et de la bonne voie à prendre, il peut réagir trop tard... et on aura loupé une sortie, ou celui ci peut nous induire en erreur en nous demandant de tourner à droite au carrefour suivant alors qu'au bon carrefour il nous disait de continuer tout droit, et ce n'est pas juste une question de précision du récepteur GPS. Heureusement OSM cherche à produire une cartographie décimétrique. Pour la précision kilométrique, on a assez de cartes statiques depuis longtemps sans OSM (mais avec peu de renseignements locaux), qui sont immédiatement utilisables mais réduisent souvent toute une ville à une grosse icône sans le détail des rues (ou seulement quelques grands axes sommairement tracés dans les plus grandes). Le 30 juin 2016 à 12:42, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Ce n'est pas juste de l'optimisation, c'est de la géométrie... Ces > formules étaient données pour être exactes. > > Oui cela fait une différence, certe petite, mais tout dépend de la > précision qu'on attend (même 0,01% cela fait vite une différence mesurable > sur une distance assez longue (toutefois non significative si c'est un > trajet routier car on ne tient pas compte de la géométrie des voies sur les > routes et des petits écarts à droit ou à gauche et encore moins des > dépassements). > > En revanche la non-rotondité de la terre a une impact bien plus important > que la petite erreur sur la non-orthonormie du repère sur l'axe des > altitudes. Dans OSM on utilise le géoïde WGS84 partout, pas la sphère ! Et > là ce calcul PHP ne tenait compte que du rayon moyen de la sphère (qui est > correct uniquement aux latitudes moyennes : les distances seront trop > courtes à l'équateur et trop longues aux pôles). La formule Python est bien > meilleure. > > > Le 30 juin 2016 à 12:08, <osm.sanspourr...@spamgourmet.com> a écrit : > >> C'est vraiment de l'optimisation à la petite semaine car le calcul d'une >> valeur absolue n'est pas bien compliqué. >> >> Bien plus intéressant est de changer la dimension des lignes afin de >> stocker la distance depuis le premier nœud. >> Typiquement dans un modèle d'itinéraire tu ajoutes deux coûts : le coût >> en distance et le coût en temps (en plus des lat/lon et éventuellement ele). >> >> N.B. : les points étant rapprochés, je doute même de la nécessité de >> tenir compte de la rotondité de la terre entre deux points, une droite >> géométrique est, étant donné l'absence d'information sur l'altitude, à >> peine plus fausse qu'une ligne loxodromique. >> >> Adrien, si jamais ton calcul depuis le GPX tient compte de l'élévation et >> si la trace est de bonne qualité, tu dois avoir le meilleur calcul... qui >> plus est sans effort de programmation. >> >> Jean-Yvon >> >> Le 30/06/2016 à 11:38, Philippe Verdy - verd...@wanadoo.fr a écrit : >> >> D'ailleurs dans la formule Python les fonctions abs() pour les trois >> composantes distParallele, distMeridien, et distVertical sont inutiles, >> puisqu'on ne va utiliser que leur carré respectif. Il suffit juste de les >> voir comme des composantes d'un vecteur 3D orienté et non comme des >> distances positives. >> >> Le 30 juin 2016 à 07:52, <pepilepi...@ovh.fr>pepilepi...@ovh.fr < >> pepilepi...@ovh.fr> a écrit : >> >>> Le 29/06/2016 à 23:20, François Lacombe a écrit : >>> >>> Bonjour Adrien, >>> >>> A mon sens c'est un calcul de distance loxodromique entre chaque nœud, >>> de chaque portion de véloroute qui composent le chemin à parcourir. >>> https://fr.wikipedia.org/wiki/Loxodromie >>> >>> Concrètement, voici un bout de PHP qui te donne la distance entre deux >>> points dont tu connais le lat/lon >>> Tu n'as plus qu'à faire la somme de tous tes segments pour avoir la >>> distance totale >>> >>> $l = 6366 * 2 * asin( >>> sqrt( >>> pow( sin((deg2rad($lat)-deg2rad($ll[1]))/2) >>> , 2) + cos(deg2rad($lat))*cos(deg2rad($ll[1]))* pow( >>> sin((deg2rad($lng)-deg2rad($ll[0]))/2) , 2) >>> ) >>> ); >>> >>> >>> >>> Pour ceux que ça peut intéresser la même chose en Python : >>> >>> import math >>> >>> def distance ( lat1 , lon1 , lat2 , lon2 , alt1 , alt2 ) : >>> rEquat = 6378137 >>> rPole = 6356752 >>> rLat = rEquat - ( ( rEquat - rPole ) * abs( lat1 / 90 ) ) + alt1 >>> >>> distParallele = abs ( rLat * math.cos( (( lat1 + lat2 ) / 2 ) * >>> math.pi / 180 ) * ( ( lon2 - lon1 ) * math.pi / 180 ) ) >>> distMeridien = abs ( rLat * ( lat2 - lat1 ) * math.pi / 180 ) >>> distVerticale = abs ( alt2 - alt1 ) >>> distTotale = math.sqrt ( ( distParallele * distParallele ) + >>> ( distMeridien * distMeridien ) + ( distVerticale * distVerticale ) ) >>> >>> return distTotale >>> >>> (distance en mètres) >>> >>> >>> >>> >>> >>> >>> Où $lat et $lng sont les coordonnées de ton point B et $ll[0] et $ll[1] >>> celles de ton point A. >>> Cette formule a un défaut : elle ne tient pas compte de l'altitude des >>> points, réputée négligeable ici. >>> >>> >>> A+ >>> >>> *François Lacombe* >>> >>> fl dot infosreseaux At gmail dot com >>> www.infos-reseaux.com >>> @InfosReseaux <http://www.twitter.com/InfosReseaux> >>> >>> Le 29 juin 2016 à 20:46, adrien < <pe...@adrieng.fr>pe...@adrieng.fr> a >>> écrit : >>> >>>> Bonjour, >>>> >>>> J'aimerais connaître la distance entre deux points sur une relation >>>> route=bicycle,en l'occurence la distance entre Nantes et Blain sur la >>>> Vélodyssée. >>>> >>>> Je suppose que c'est facilement faisable, mais je sèche complètement sur >>>> comment faire, et quel outils utiliser… >>>> >>>> Si vous avez des pistes, je vous en serait reconnaissant. >>>> >>>> Bonne soirée >>>> >>>> Adrien >>>> >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>> >>> >>> >>> _______________________________________________ >>> Talk-fr mailing >>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >> >> _______________________________________________ >> Talk-fr mailing >> listTalk-fr@openstreetmap.orghttps://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
