Je suis un peu inquiet de voir à quel point GoogleMaps semble être l’alpha et l’omega de bien des développeurs du monde OpenSource, comme si tous les efforts actuels devaient se concentrer sur la mise en oeuvre d’une solution concurrente. Entre OpenLayers, dont les fonctionnalités se veulent le décalque de celles de GoogleMaps, et les interrogations surgissant ici ou là, c’est comme si toute application de webmapping devait se résumer à singer GoogleMaps. On a l’impression que, surfant sur la vague du Web 2.0, les applications cartographiques sur le web on été investies par des gens pour lesquels elles se résument à afficher des points, traits ou polygones à un endroit convenable.
Mais rappelons-le, GoogleMaps, quelques soient ses indéniables qualités (plus architecturales que fonctionnelles au demeurant), n’en est pas moins une application qui affiche 1 ou 2 couches de données images précalculées et permet quelques facéties dans un calque de dessin vectoriel. L’ergonomie est certes remarquable, mais fonctionnellement on est loin de ce que peut réclamer une réelle application SIG en ligne.
Loin de devoir garder la tête dans le guidon à la poursuite de GoogleMaps, je pense donc que la communauté OpenSource, forte de son expérience dans le domaine du SIG en général, à plutôt intérêt à développer des WebServices cartographiques performants, permettant peu à peu de transférer vers le navigateur ce qui ne se fait encore que dans des applications SIG desktop. A trop vouloir faire du web 2.0 en WebMapping, on dégrade les fonctionnalités purement cartographiques pour ne conserver que l’affichage. C’est bien pour partager de l’information géolocalisée (ou des ressources géolocalisées : photos, parcours…), mais c’est insuffisant pour traiter ces informations au sens cartographique du terme et donc exploiter la réelle plus-value spatiale et attributaire qu’elles recèlent.
Mots-clefs : GoogleMaps, OpenLayers
J’aurais aimé un billet moins vindicatif à l’égard de Google Maps et de la communauté Open Source.
Effectivement, on peut regretter que Google Maps soit perçu comme la référence incontournable en matière d’application web de géolocalisation.
Cependant, je trouve injuste de dire que Google Maps n’apporte rien du point de vue fonctionnel. Le fait que Google mette en ligne et quasi en libre accès l’API de Google Maps est tout à fait remarquable et participe grandement à son succès. Street View et le calcul d’itinéraire de Google Maps sont moins connus mais présentent tout de même des innovations que je trouve très intéressantes.
Pour ma part, mais c’est peut-être parce que j’ai la tête dans le guidon
, je trouve que :
- Google a atteint son objectif comme nul autre acteur de l’information géographique n’a su le faire jusque là ;
- Cette notoriété ne cesse de tirer vers le haut les attentes des utilisateurs.
Je trouve également injuste le fait de présenter l’effort de la communauté Open Source comme une simple copie de Google Maps :
- OpenLayers et Community Map Builder ont intégré des outils de saisie avant Google
- Ils ont intégré le support de GML, WMS et WFS alors que Google ne le fait pas (on n’est pas obligé d’aimer ces standards mais au moins on ne pas les accuser de copier Google sur ce point)
Par ailleurs, on ne peux pas s’attendre à trouver des fonctionnalités de très haut niveau dans des applications qui se destinent au grand public. Il faudrait plutôt les chercher dans des applications de niche. Cela dit, le fait d’avoir une API publique permet aux développeurs de fonctionnalités de haut niveau de les intégrer dans Google Maps.
Véhément peut-être, mais vindicatif je ne crois pas. D’un point de vue fonctionnel GoogleMaps reste dans le domaine du gadget (hmm, vindicatif ça). La recherche d’itinéraire n’est pas dotée par exemple des multiples options proposées par les grands acteurs du domaine (ViaMichelin, Mappy…). StreetView ? Les Pages Jaunes font mieux depuis longtemps. Il est cependant vrai que ces deux « applications » de Google disposent d’une ergonomie à nulle autre pareille, comme je l’indiquais dans un billet antérieur (on ne peut pas être vindicatif tous les jours). Mais un outil non OpenSource comme GeoClip par exemple fait depuis longtemps bien plus fonctionnellement parlant que GoogleMaps.
Concernant la communauté OpenSource, je réagis simplement à une tendance qui privilégie le contenant au contenu. La mode étant à l’interropérabilité, les efforts actuels, remarquables au demeurant, vont vers les formats d’échanges, au GeoFeed, à la syndication tous azimuths. Mais la question du « pour en faire quoi » demeure. Ce n’est sans doute qu’une passade, la réflexion sur la véritable finalité de la diffusion de l’information géographique viendra sans doute quand ces étapes auront été franchies. La communauté OpenSource a ce handicap de devoir tout laisser ouvert et interropérable, ce qui prend beaucoup de temps et de ressources.
Sorry, I can’t respond in French, but just my two cents:
Although OpenLayers seeks in many ways to achieve the same performance, usability, etc. of Google Maps, that doesn’t mean that it is ignoring the GIS capabilities that many users need from the desktop — they just tend to be harder to demonstrate without a particular use case.
Some things which OpenLayers does:
* Loads many different geographic formats: WKT, GML, KML, GeoRSS, GeoJSON, etc.
* Will soon support SLD for choosing how to render these features based on Rules
* Will, in the next version, support client side reprojection of features to match the base layer in use
In addition, using OpenLayers as a client, you can implement a number of more ‘serious’ GIS tasks:
http://crschmidt.net/mapping/wpserverdemo/
Union, Intersection, Difference, Buffering, line simplification, you name it.
You can edit features, and store them back to the server: the demos of this ( http://featureserver.org/demo.html , for example ) are naive, but this technology is being integrated into Desktop GIS applications like QGIS — simply point qgis to a featureserver instance, and it wil lbe able to load features, and store them back on the server when you’re finished modifying them, including editing attributes, etc.
http://www.cartoweb.org/v4/demos/v0.1/demos/world_factbk/geostat.html uses the vector drawing in OpenLayers to draw both chloropeth and proportional symbols, entirely on the client side.
GIS applications are not the first goal for OpenLayers. MetaCarta, the primary instigator of the project, *is not a GIS company*. But companies like Camptocamp are, and they are getting involved, and using OpenLayers, and they’re doing GIS with it.
So, I have to respectfully disagree with you: Although OpenLayers is, at its heart, a library for building highly functional and usable applications, this is *not* at the cost of abandoning GIS. Instead, it is the first step on a path towards moving GIS to the web — and I’d say it’s doing pretty well at that.
The demo is quite impressive. I think there »s a great step forward there. As you pointed it, GIS applications were not the first goal of OpenLayers, and that is exactly what I wanted to emphasize. And I’m quite happy having witten this exaggerated post as the reactions to it make things move forward for me. Thanks for these comment, and for all these thing done in OpenLayers.
By the way, just a technical point. In WPS demo, you’re making the topological operations on the server side, which is normal in a webservice approach. But I remember having seen, a long time ago, some examples showing these operations done on the client side. I’ve checked it out, but couldn’t found it back.
Toplogical operations on the client side might be possibly, but why bother? The server side in this case is extremely easy to set up — it can be run anywhere, including locally to your laptop or desktop machine, so what’s the harm in doing things using the existing tools?
The line simplification is written entirely in Python — it would be trivial to write a line simplification algorithm in Javascript, and use that instead, but part of the goal of OpenLayers is quick, responsive, user-friendly behavior — and moving all your topological operations to the client doesn’t achieve that too well.
I think it would be faster though.