C'est vrai que MySQL ici montre ses limites. Faute justement d'intégrer un vrai système d'indexation géographique ou de permettre d'utiliser un tel plugin (pour remplacer ses index classiques hiérarchisés, incompatibles avec toute info 2D, ni aucun type de données 2D, pas même un nombre complexe qu'il ne saurait pas indexer correctement pour les recherches).
Il y a des solutions de contournement (partiel). J'en ai déjà parlé ici : on peut convertir un couple de coordonnées sous une forme binaire entrelacée, permettant d'avoir un index à peu près efficace (même si cela impose un découpage bidimensionnel sur des seuils arbitraires de coordonnées). En gros cela consiste à diviser l'espace 2D alternativement en deux suivant l'axe horizontal, puis sur l'axe vertical, en alternant. La position de coupure est arbitraire (on peut prendre le milieu même si les deux parties ne sont pas équilibrées en terme de volumétrie). Pour cela la donnée binaire va devoir stocker suffisamment de chiffres significatifs de chaque coordonnée. Si on utilise un "double" pour la donnée transformée à indexer, ses 48 bits de précision permettent de stocker 24 bits de précision de chaque coordonnée 2D. On peut aussi utiliser un entier 64 bits pour stocker 32 bits entrelacés de précision de chaque coordonnée 2D exprimée sur un entier (les coordonnées d'OSM sont de type longitude/latitude dans la projection sur le géoïde WGS84, comme ce sont des angles dans un intervalle bien défini, on peut donc sur 32 bits représenter une précision angulaire meilleure de l'ordre de quelques dixièmes de milliseconde d'arc, bien au delà de la précision nécessaire; en fait 21 bits suffisent par coordonnée pour une précision d'1 seconde d'arc, raison pour laquelle on n'a pas besoin des double non plus pour stocker les coordonnées de longitude ou de latitude). Un vrai indexeur spacial s'il effectue aussi un découpage alterné, se distingue en ne prédéterminant pas les valeurs seuils de coupure. Il gère son index de façon à maintenir chaque partie à peu près égale en volumétrie (dans une fourchette de tolérance). Il peut aussi faire un découpage sur une grille plus grande que 1x2 ou 2x1, par exemple 2x2, 3x3 ou plus, et peut même changer ce découpage dynamiquement, selon les données qui se présentent ou sont modifiées, il peut même identifier dans des grilles de découpage 3x3 et supérieures plusieurs cases à indexer ensemble, pour que la volumétrie de chaque case soit à peu près équilibrée avec les autres cases regroupées de la même grille. Ensuite, les autres extensions offertes par les plugins sont les extensions de calcul (intersection par exemple), mais impossible de les implémenter efficacement sans avoir un vrai indexeur multidimensionnel efficace. MySQL ne pourra rien offrir là dessus, ce genre de requête se fera donc de façon externe. Ces plugins ne changent pas la méthode de stockage ou d'indexation de la base, leur intérêt c'est qu'ils s'exécutent directement au sein du moteur, et font donc l'économie de pas mal d'interfaces de communication pour éviter le goulot de la bande passante nécessaire en sortie du moteur SQL. En revanche ces plugins d'extension ne font aucune économie en terme de bande passante sur les accès disques (raison pour laquelle il faut des index très efficaces et si possible optimums pour les recherches d'objets dans des espaces délimités le plus souvent par un rectangle). Le 24 février 2012 17:06, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > >> Au risque de nourrir un troll... > > Ouais mais on peut, c'est trolldis ;-) > >> PHP dispose de peu de modules pour traiter l'information géographique > > Il est vrai, mais c'est pas très important car il est possible de faire une > grosse partie du traitement géographique du coté du moteur spatial. > > php, ce n'est que la "colle" entre le moteur de base de donnée et l'interface > utilisateur (html/navigateur/javascript) > > Le problème à mon avis dans "SIG pour tous" tel que cyrille le souhaiterais, > c'est la non disponibilité de bases spatiales chez la plupart des > hébergeurs "à pas cher" et ça, ça va être difficile de s'en dépêtrer. > > Pour avoir développé sur www.refuges.info de nombreux éléments qui > s'approchent des SIG (polygones, intersections, appartenance, recherche de > proximité) je peux dire que le problème n'a pas vraiment été php, mais bien > le moteur MySQL sous-jacent que j'ai converti misérablement et à grand frais > de CPU perdu et redondance en moteur à peine spatial. (et quand je vois le > résultat, je tire mon chapeau à l'équipe postgis !) > > > > -- > sly > qui suis-je : http://sly.letuffe.org > email perso : sylvain chez letuffe un point org > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
