Ce code source n'apporte strictement rien. Pas même sa description qui est fonctionnellement aberrante concernant la formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui réclame un nombre premier pour encoder le couple de coordonnées alors que cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit premier, on peut directement utiliser "180*10^precision" à la place de "prime" en voyant que les latitudes sont données en degrés entre -90.0 et +90.0, ou bien "360*10^precision" si les latitudes ne sont pas normalisées à cet intervalle et reboucle chaque méridien avec son antiméridien (au quel cas un module 360 suffit sur chacune des deux coordonnées à les normaliser "à moitié", sans unifier un point et son antipode situé à la même longitude mais à la latitude+180°)
round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) * 360*10^precision Les arrondis sont mal exprimés aussi dans la formule originale qui va donc confondre une partie de la précision de la longitude en recouvrant des points ailleurs à une autre longitude. [Pour une unification complète des points antipodiques, il faut un test d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de l'intervalle de latitude, et en remplaçant ou pas la latitude par son complémentaire à 180° selon la même parité]. Et je pense même que c'est inutile à moins que la base QGis stocke des coordonnées non normalisées (avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180° pour la cartographie le long de la ligne de changement de date (aux îles Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie extrême-orientale, et sinon sur le continent antarctique dans le secteur revendiqué par l'Australie). Et concernant le paramètres "layer" qui multiplie le tout, c'est encore plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend tous les ids générés nuls. J'espère qu'une telle formule (totalement fausse) n'a jamais réellement été utilisée pour importer des géométries dans OSM! > Le mer. 13 mai 2020 à 16:25, <[email protected]> a écrit : >> >>> DCbrain rend public un convertisseur de données, sur son compte Github. >>> Il s'agit d'un convertisseur de données géographiques postgresql en format >>> openstreetmap >>> Apparemment c est en rapport avec OSRM >>> Source: >>> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553 >> >>
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
