[OSM-talk-fr] Une carte orientée biologie ? (arbres, insectes, oiseaux, plantes)

[Philippe Verdy]

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) <liste at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr