8
11 juin 2010

La cartographie et la localisation font partie intégrante de notre environnement web actuel. Le succès d'application comme GoogleMaps avec plus de 10 millions de cartes créées1 ou encore Google Earth qui recense plus de 500 millions de téléchargements2 en est la preuve concrète. Cette ouverture vers le spatial a apporté, à mon avis, autant de bouleversements que l'ouverture sociale du Web 2.0.

La plupart des cartes que j'ai pu voir se résument à quelques marqueurs auxquels ont été ajoutées des informations complémentaires. Rien de très méchant "cartographiquement" parlant. Néanmoins et même si les API sont relativement faciles à comprendre, il faut être un minimum intéressé par la programmation pour créer sa propre application.

D'où l'idée que je développe dans ce billet, celle d'une futur balise HTML , qui serait interprétée directement par votre navigateur. Celle-ci permettrait de créer automatiquement une carte en fonction des caractéristiques associées. Un exemple de squelette HTML est présenté ci-dessous afin d'illustrer mon propos :

<hypermap> 
    <mapoptions> 
        <zoom>4</zoom> 
        <lonlat>273950;5841011</lonlat> 
        <static>False</static> 
    </mapoptions> 
    <layers> 
        <layer>OSM</layer> 
    </layers> 
    <control> 
    </control> 
    <data> 
        <point>
            <lonlat>313385;6242152</lonlat> 
            <content>Paris</content> 
        </point> 
        <point> 
            <localisation>Nice,France</localisation>
            <content>Nice</content> 
        </point> 
    </data> 
</hypermap>

Détaillons un peu plus en détails chacune des sous balises :

  • mapOptions : spécifie les caractéristiques générales de la carte
  • layers : défini les couches à afficher
  • control : ajoute des contrôles spécifiques à la carte
  • data : définie les données qui seront affichées. Les positions peuvent être données au format longitude/latitude ou simplement nommées par leur localisation (celle-ci sera converti grâce à la librairie YQL)

De la théorie à la pratique, il y a tout de même un monde. C'est pourquoi, j'ai décidé d'implémenter cette idée afin de valider cette preuve de concept (exemple). Pour cela j'ai utilisé comme librairie OpenLayers et Prototype et comme source de données OpenStreetMap. L'architecture du DOM est la même que l'exemple présenté ci-dessus. Si vous affichez le code source de la page, vous ne verrez rien d'autre qu'une balise hypermap !

1 : http://maps-forum-announcements.blogspot.com/2009/01/juicy-facts-in-goog...

2 : http://www.gpsbusinessnews.com/Google-Earth-over-500-million-downloads_a...

img_slideshow: 
A propos de l'auteur: 
GeoTribu

Toute l'actualité de la géomatique Open Source ! Mais aussi des tutoriels, des billets de blog, des tests et surtout une bonne humeur géographique !

Commentaires

Tu viens de reinventer le KML. le html est deja devenu tellement vaste en soi qu'il n'est plus possible pour un developpeur de l'implementer seul ou en petit nombre. La version 5 n'arrange pas les choses.
Une nouvelle balise ne fera qu'agrandir encore la disparité entre les navigateurs.

Je pense qu'il vaut mieux laisser ce genre d'outil a des languages qui en sont vraiment capable, tel que les RIA en flash, Java ou silverlight.

Bonjour,

Merci pour votre remarque même si je ne suis pas tout à fait d'accord.

En effet, le KML est un conteneur de données. C'est un langage XML permettant de gérer l'affichage de données spatiales. Cela n'a donc rien à voir avec l'objectif de ce qui est présenté ici.

>> http://fr.wikipedia.org/wiki/Keyhole_Markup_Language

Maintenant concernant le HTML :

* Le HTML n'est pas un langage de développement, mais de mise en forme. N'importe qui avec un minimum de connaissance est capable de l'implémenter.

* La version 5 n'arrangera pas les choses... Oui et non, la preuve, certaines "directives" de l'HTML 5 sont déjà implémentées dans les navigateurs. Mais c'est vrai qu'il y aura un passage à vide avant l'implémentation totale.

* La disparité entre les navigateurs n'est pas du à cause du HTML, mais au fait que chaque navigateur, à un moment donné, a essayé d'imposer sa propre interprétation.

* FLASH, SILVERLIGHT... D'entendre cela me donne des sueurs froides. Je ne suis pas contre les RIA, bien au contraire. Mais premier point noir, il faut pour cela télécharger un plugin. Si on regarde combien d'entreprises fonctionnent encore avec IE6 parce que les DSI ne veulent pas mettre à jour leur parc info, cela pose déjà un premier souci. De plus, cela va à l'encontre de la philosophie de cet article. L'objectif ici est de programmer le moins possible. Que tout le code soit automatiquement géré par le navigateur.

Arnaud

Bonjour Arnaud,
Cette possibilité d'offrir à l'utilisateur une alternative au format xml n'est pas inintéressante en effet. Mais cela relance le vieux débat xhtml/html, non?? ;-)) Plutôt que d'introduire ce nouveau tag html (le w3c est-il prêt à le faire), utilisons xhtml à bon escient.

Comme l'a justement fait remarquer Benjamin Chartier sur son blog, cette possibilité d'ajouter une balise <geomap> - et non <hypermap> :-) - a été évoquée dans des discussions de l'OGC : https://lists.opengeospatial.org/mailman/private/mass-market-geo/2009-Se...
Il faut préalablement s'inscrire à la mailing-list Mass-Market-GEO pour pouvoir consulter les discussions : https://lists.opengeospatial.org/mailman/listinfo/mass-market-geo .

Fabien

Bonjour à tous,

Concernant les différentes remarques.

Il me semble, dites moi si je me trompe, mais l'introduction du XHTML a été une réponse à la trop grande permissivité de l'HTML (balise non fermée, majuscules...). Cela permettait ainsi de valider "facilement" sa page. Mais, il semblerait tout de même que l'impact du XHTML ai été assez limité.

>> http://fr.wikipedia.org/wiki/Extensible_HyperText_Markup_Language

De ce fait, que cela soit en HTML ou en XHTML le concept reste le même. La balise hypermap ou geomap (peut importe le nom) peut être implémentée dans chacun de ces deux langages de balisage.

Concernant la remarque sur les RIA, je suis tout à fait d'accord. De toute façon, l'objectif de ce billet n'était pas de faire une RIA mais plutôt de proposer une balise permettant de créer sa propre carte rapidement.
Comme je le souligne, les cartes que l'on retrouve sur internet aujourd'hui sont plutôt pauvres sémiologiquement parlant. Pas la peine de sortir la grosse armada (flash, silverlight...) juste pour afficher 2 POI ;)

Arnaud

D'ailleurs, peut-on réellement parler de RIA en parlant d'applets Java ou d'applications Flash ou Silverlight, étant donné que ce sont des applications téléchargées et qui ne sont donc pas des clients légers à part entière (même si elles s'exécutent dans un navigateur web).

Pour moi, ce genre d'application va à l'encontre de l'accessibilité et de l'esprit "internet" même.
Il est vrai qu'on utilise essentiellement le terme RIA pour définir flash etc., mais en réalité c'est une erreur. Une application RIA, c'est une application légère (HTML, css, javascript traditionnellement).

Aussi, l'idée d'une balise HTML "hypermap" serait une bonne idée effectivement, mais comme cela a été dit plus haut : problèmes de compatibilité entre les navigateurs, restriction de l'offre disponible... et bien d'autres désavantages également.

Petite erreur : 500 000 millions au lieu de 500 millions...

Oups, corrigé.