Deux nouveaux contrôles vont faire leur apparition dans OpenLayers 2.8 (ici pour la traduction française, à la grammaire près). Il s’agit d’outils d’aide à la saisie, bien utiles pour faciliter le travail et augmenter sa qualité géométrique.
Un outil de snapping (accrochage aux objets existants) avec une belle granularité des options puisqu’il propose l’accrochage aux noeuds, simples sommets et même bordures, chacune étant complètement configurable indépendamment des autres (activation, tolérance).
Un outil de découpage (split) qui permet de décomposer des géométries existantes à partir d’un nouveau tracé. C’est par exemple utile lors de la création de réseaux linéaires, une nouvelle ligne découpant automatiquement celles qu’elle coupe aux intersections, de manière à obtenir un réseau non pas encore topologique (il faudra séparer noeuds et arcs pour cela) mais bien structuré. Ca parait plus simple que le snapping, mais c’est plus délicat que ça en a l’air, car l’utilisation de cet outil impacte des géométries existantes à la différence du premier qui ne faisait que les utiliser. Un objet linéaire disposant d’un id et d’un attribut longueur par exemple va se retrouver segmenté en deux parties distinctes, dont il faudra donc corriger les attributs (nouveaux ids, recalcul des longueurs…). Fort heureusement l’outil de découpage a été bien conçu puisqu’il intègre un événement aftersplit qui permet de récupérer les objets venant d’être recomposés. Charge au développeur d’implémenter ce dont il a besoin à ce niveau.
Les objets à découper peuvent également être filtrés en fonction d’un attribut (afin, par exemple, de ne pas découper les autoroutes quand on trace des départementales)
Enfin, les deux contrôles peuvent être activés conjointement, et permettent d’interagir (en découpe ou accroche) avec d’autres couches que celles utilisées pour la saisie.
Au-delà de la prouesse technique, j’avoue que je suis surtout séduit par le professionnalisme de l’approche « métier ». Sans doute que le sponsor de ces développements, SWECO, spécialisé dans le génie civil et le BTP n’y est pas étranger ! Un seul défaut à mon sens, l’absence de curseur de contrôle du positionnement en tout début de saisie, qui fait que le premier point est placé sans savoir si l’accrochage est effectif ou pas. Et si la taille de celui-ci, qui serait alors un cercle, pouvait reprendre la tolérance, on toucherait au nirvana !
Plus prosaïquement, on se rapproche lentement de solutions full-web de saisie cartographique. Quelques contrôles de topologie effectués sur le serveur (au hasard avec… GeoDjango !) peuvent venir améliorer encore le résultat sans trop d’efforts (absence d’intersection entre les polygones, validité des géométries…). Reste que la manipulation d’objets vectoriels dans un navigateur a une limite liée à la capacité de ce même navigateur. Au-delà d’un certain nombre de points (sommets, noeuds…), l’application se fige et devient inutilisable. Mais cette limite est sans cesse repoussée par l’améliration des navigateurs et la puissance des machines. Donc oui, ça devient envisageable, sans être trivial.