[OSM-talk-fr] DCbrain rend publique une partie de son code en open source

[Philippe Verdy]

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, <thevenon.julien at free.fr> 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
>>
>>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200526/5abd4798/attachment-0001.htm>