Le mar. 26 mai 2020 à 06:52, Philippe Verdy <ver...@gmail.com> a écrit :
> Ce code source n'apporte strictement rien. > Ça a le mérite d'être clair! > > 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 > Le code source est libéré je pense que tu peux proposer quelque chose en ce sens qui permettrait à la communauté quelque choses de constructif > > 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. > Pareillement. Peut-être que ça a une utilité justement pour le projet originale pour filtrer un niveau d'échelle un peu comme le fait INTERLIS > > 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! > Peut-être que SeFaireConnaitre ... Non je sors > > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
