J'ai bien compris la role de 'layer" mais ça ne fonctionne pas dans la formule publiée où ce n'est qu'un facteur d'échelle: layer=2 multiplie les id retournés par 2 mais un id=2 créé par une telle valeur de layer entre en collision avec l'id=1 pour un autre noeud situé ailleurs sur la carte à la précision donnée. Ce n'est donc PAS une multiplication mais une addition (d'une constante) qu'il faut faire pour séparer les id's de noeuds sur des layers différents. Chaque layer numérote ses noeuds sur une grille N*N correspondant aux latitudes/longitudes arrondies au facteur de zoom près, il faut donc bien *ajouter* (layer*N*N). Ici N=2^zoom et c'est le zoom ici qui tient lieu de niveau de précision (avec zoom=0, la grille N*N ne fait que 1*1 et se réduit à 1 point pour toute la planète positionné à la longitude 0 et la latitude 0, donc sur sur l'équateur et le Méridien de Greenwich, légèrement décalé dans WGS84, ce point étant dans le Golfe de Guinée à l'ouest de l'Afrique centrale). Avec le zoom=1 on a 4 points sur la planisphère WGS84 mais 2 des points sont au pole sud, le troisième est l'antipode du premier point aussi sur l'équateur. Les points de la grille délimitent à chaque fois 4 carreaux divisant le premier en parties égales en surface et en côtés sur la planisphère.
Le facteur d'échelle (2^zoom) est ce qui est classiquement utilisé sur OSM, chaque zoom supplémentaire divisant l'angle total de 360° (en longitude comme en latitude) par 2. La niveau de zoom 8 correspond à une précision légèrement supérieure à 1 degré (on peut aussi le traduire en distance grâce au rayon moyen de la Terre pour une distance mesurée sur un géoïde parfaitement sphérique, ce que la Terre n'est évidemment pas à sa surface étant donné sa forme ovoïdale aplatie aux pôles et le relief, c'est pour ça qu'on parle juste de rayon moyen et sur OSM on retient une moyenne mesurée sur le plan de l'équateur au niveau moyen de la mer, ou bien la longueur totale de l'équateur, soit environ 10 000 km pour ses 90° de longitude sur un quart de l'équateur) De fait pas besoin du paramètre "précision", "zoom" en tient lieu. La combinaison de latitude et longitude en un seul entier peut se faire de deux façon: * avec la fonction ST_QUAD (par entrelacement alterné des bits de longitude et latitude), qui existe déjà dans la base PostGIS que tu utilises et qui sert déjà pour indexer les recherches par coordonnées proches au sein d'un même carreau et permet de définir un intervalle carré englobant le point cherché; * ou en multipliant une des coordonnées par la borne supérieure (non incluse) de l'autre coordonnée, donc (2^zoom), et non pas une multiplication par un "nombre premier supérieur à 10^précision"; le nombre premier n'apporte rien, plus facile à calculer mais pas pratique pour indexer les coordonnées 2D car cela divise la carte en bandes ultrafines avec de nombreux points faisant tout le tour de la Terre avant le point proche de la bande suivante ou précédente. L'anomalie que j'ai signalée concerne justement le facteur "layer" (utiliser un nombre premier > 10^précision dans la formule initiale marche, mais la restriction aux premiers ne sert à rien et le nombre=10^precision marche aussi donc pas besoin de ">"). Le mar. 26 mai 2020 à 19:30, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Philippe, je crois que tu ne comprends pas. > > Le mar. 26 mai 2020 à 17:24, Philippe Verdy <ver...@gmail.com> a écrit : > >> Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est >> nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel >> sans correction au risque d'importer des géométries farfelues, car un tel >> script peut servir à faire des imports en masse sans trop regarder... >> > > Proposer un patch de cette façon en l'assortissant de phrases buttoir > n'apporte rien et surtout décourage d'autres de publier leur contribution, > si c'est pour avoir à faire à ce genre de discours. > Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient > d'utiliser certains logiciels, en particulier osrm, avec des données qui ne > viennent pas d'OSM. > > Mon utilisation est certainement trop limitée pour avoir vu le problème > des antipodes. > Que le code soit perfectible, certes. On ne va quand même pas attendre > qu'il soit parfait pour le publier? > Tu ne semble pas avoir compris pourquoi les layers avaient été introduits > ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se > trouver au même endroit sans devoir être fusionnés. > > +1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la > suite. > > François > _______________________________________________ > 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
