Google vient de lancer “Google Static Maps API“. Il ne s’agit pas d’une nouvelle feature de Google Maps API, mais véritablement un nouveau moyen de diffuser des carte plus facilement.

Les API cartographiques que l’on connait comme Google Maps API, Virtual Earth ou ViaMichelin Maps & Drive, ne sont destinées qu’à des sites web car utilisant des technologies Javascript de type AJAX. Seul un vrai navigateur web peut interpréter ce type de language. Une des révolutions de l’iPhone d’Apple est d’intégrer un dérivé du navigateur Safari sur le device et de pouvoir ainsi utiliser ce type de technologie. C’est un des premiers appareils a pouvoir le faire.

Mais qu’en ait il de 99,99% des téléphones formant le reste du marché? Les téléphones même perfectionnés ne peuvet afficher que des site web simple “statique” en HTML et image… comme sur le web il y a 10 ans. Les nouveaux OS pour téléphones mobiles comme Androïd ou les navigateurs dédiés comme Opéra Mini intégrent la possibilité des technologie d’affichage plus performantes. Mais pour l’instant ils ne sont pas encore lancés sur le marché.

Donc pour l’instant, il est encore difficile d’afficher sur votre site mobile des cartes adaptées pour votre téléphone mobile. Sans oublié que les capacités d’affichage des images sur les navigateurs des téléphones mobiles limitent la lisibilité. De plus l’écran est réduit, ne facilitant pas la lecture d’une carte détaillée.

Yahoo! déjà présent

Yahoo a depuis longtemps répondu à ce type de problématique avec  “Map Image API” de Yahoo! Maps Web Services. Il s’agit d’un Web Service de type REST où dans la requête vous indiquez le centre de la carte (adresse ou coordonnées géographiques), la taille (10 à 2000 pixels de hauteur et largeur), le format de l’image (png ou gif). Le système reste très simple et peut répondre à certaines problématiques mais pas vraiment au besoin “mobile”.

Voici un exemple (j’ai indiqué le centre, le zoom, la taille de la carte):

Google Static Maps API, qu’en est il?

Google Static Maps API fonctionne sur le même principe. Cette API vous permet de générer une carte statique, une image, depuis les serveurs de Google. Comme pour l’API Javascript vous devez avoir une API Key.

Attention, il y a tout de même une limite journalière de 1000 requêtes en sachant que le comptage se fait uniquement pour des cartes différentes. Vous pouvez demander l’affichage de 50000 cartes identiques sur une journée, ce qui est assez intéressant en fin de compte. L’image est au format GIF.

A partir de cette URL : http://maps.google.com/staticmap?parameters vous allez construire directement l’URL de la carte.

Voici les paramètres disponibles pour la création d’une carte statique :

• center : le centre de la carte en coordonnées géographiques latitude, longitude
  ex : ¢er=48.861433,2.334112
• zoom : le niveau d’échelle de votre carte (entre 0 et 19)
  ex : &zoom=16
• size :  la taille de carte en largeurxhauteur
  NB : la limite est de 512×512 pixels.
  ex : &size=400×320
• maptype :  le type de la carte. 2 possibilités (pour l’instant??), roadmap avoir pour les cartes classique et mobile pour avoir une carte vraiment adaptée aux écrans de mobiles (meilleur lisibilité)
  ex : &maptype=mobile
• markers :  pour déterminer les marqueurs présents sur votre carte. Ils sont listés sur la valeur du paramètre markers.
  Il n’est pas indiqué une limite du nombre de marqueurs affichables. Un marqueur se définit par sa latitude, sa longitude, sa couleur (optionel) et une lettre pour le distinguer (optionnel). Ces quatres élément sont séparés par une virgule. Si il y a plusieurs marqueurs, on les distingue avec le caractère |
  ex : markers=48.861433,2.334112,blues|48.865491,2.321098,green
  Les couleurs des marqueurs sont : red (rouge), blue (bleu) ou green (vert).
  La lettre n’est pas séparée par une virgule (?? étrange) : markers=48.861433,2.334112,bluesr|48.865491,2.321098,greeneNB: vous pouvez ne pas indiquer de centre et de zoom si vous avez des marqueurs. La carte la plus adaptée pour afficher les icônes sera fournie.

Exemples

Voici quelques exemples :

• Carte simple (centre/zoom)
  http://maps.google.com/staticmap?
  center=48.861666,2.32129
  &zoom=14
  &size=400×320
  &key=VOTREAPIKEY
   
• Carte avec un simple marqueurhttp://maps.google.com/staticmap?center=48.861666,2.32129&zoom=14&size=400×320&markers=48.861666,2.32129key=VOTREAPIKEY
  
• Carte avec marqueurs et un centre/zoomhttp://maps.google.com/staticmap?center=48.861666,2.32129&zoom=14&size=400×320&markers=48.861433,2.334112,bluer|48.865491,2.321098,greene&key=VOTREAPIKEY
  
• Si je retire le centre et le zoom en laissant les marqueurs :http://maps.google.com/staticmap?size=400×320&markers=48.861433,2.334112,bluer|48.865491,2.321098,greene&key=VOTREAPIKEY
  
• La même que la précédente en version mobilehttp://maps.google.com/staticmap?size=400×320&markers=48.861433,2.334112,bluer|48.865491,2.321098,greene&key=VOTREAPIKEY
   

En comparant les 2 cartes (version roadmap et version mobile), on peut se rendre compte que les voies sont moins larges pour une meilleure lisibilité des espaces. Les noms de rues sont écrits plus gros.

Conclusion

C’est une excellente initiative de la part de Google de proposer ce nouveau mode de requêtes de carte. Les requêtes sont très simples à formater et fournissent directement l’image. Pas de XML à parser pour avoir l’URL.

Cette nouvelle API est particulèrement adaptée aux supports mobile et ouvre donc de nouvelles persectives. Comme je le disais, les applications utilisant la cartographie dans le contexte mobile vont voir le jour plus facilement grâce à ce type d’outils. Cela va permettre d’effectuer un premier pas vers le mobile pour tous les mashups créés grâce à l’API Google Maps (ou autre). Mais attention, aucune intéraction n’est encore possible sur ces cartes. De plus les vues hybrides/satellites ne sont pas (encore) disponibles.

Points positifs :
- Multi plateforme et standard (pas de Javascript)
- Version mobile disponible
- Requêtes simples

Points négatifs :
- 1000 cartes uniques par jour (limité pour un site à fort trafic avec données dynamiques à afficher)
- Format unique d’image : GIF
- Taille des cartes un peu limite (512*512) pour certains cas

Dans ce billet je tente de donner quelques orientations pour 2008 concernant la géolocalisation. Je ne vais pas m’aventurer sur le thème de la cartographie online ou du geoweb. Par contre il est évident que 2008 promet de nouvelles perspectives en terme de géolocalisation pour le “3ème écran” : le téléphone mobile.

Positionnement de Google

Google n’est et ne sera par une entreprise de cartographie. Son objectif premier est d’organiser géographiquement l’information adaptée au contexte de consultation pour la rendre universellement accessible par les utilisateurs.

Il est donc nécessaire pour Google de canaliser le savoir des personnes sur leurs environnements et de le rendre accessible aux personnes connectées. C’est le début de la construction du GeoWeb.

Google Maps sera sûrement redesigné et pourrait inclure plus d’espace pour le contenu créé par les utilisateurs (user-generated content). Nous allons pouvoir partager plus facilement des événements proches de chez soi, du lieu où l’on se trouve, des recommandations d’amis proches. L’utilisation de Google Maps va devenir plus personnelle.

Avec Android et son consortium, Google souhaite donc installer son propre environnement sur des terminaux mobiles adaptés, facilitant ainsi l’accès à l’information.
Bon nombre de développeurs sont encore trop frustrés par les limites des terminaux mobiles (liées aux opérateurs et aux fabriquants de téléphone).

Mobilité

La géolocalisation est une valeur ajoutée pour toutes sortes d’applications et en particulier les applications mobiles (recherches locales ou messageries instantanées).

Les services de géolocalisation ne connaissent pas encore un véritable succès. Plusieurs raisons à cela :

• Complexité de l’interface
• Nécessité d’une géolocalisation précise : nécessité de terminaux avec GPS
• Manque d’investissement des opérateurs qui parient, pour l’instant, plus sur la télévision mobile que sur de vrais services utilisant la géolocalisation

Les utilisateurs d’applications mobiles font face à une interface complexe. Il est nécessaire que l’expérience utilisateur soit simple et rapide. L’information géolocalisée doit être accessible en un seul clic.

Il est pourtant évident que, dans les prochaines années, les services utilisant la géolocalisation généreront plus de profits que tout autre services mobiles. Il faut voir en cela que de nombreux contextes dans lesquels se trouve l’utilisateur l’orientent vers son téléphone mobile.

Francis Pisani parle de mobiquité :

La mobilité est elle-même en pleine mutation. Il s’agit de rendre compte à la fois du fait que nous pouvons depuis un nombre croissant de lieux et de situations avoir accès à un monde d’informations et de loisirs bientôt aussi riche (ou plus) et infiniment plus cool que celui que nous avions devant nos ordinateurs et nos télés.

Je vous conseille aussi la lecture de cet article de e-tourisme.info sur Dogeball, une sorte de réseau social mobile.

Téléphones et GPS de navigation

Il y a eu, ces 2 dernières années, une véritable démocratisation de l’usage de GPS de navigation. La gamme est de plus en plus étauffée et offre plus de services. Mais ce qui peut manquer à ce type d’appareil est de pouvoir communiquer en temps réel. Il reste encore assez fastidieux de devoir mettre à jour les données de son GPS de navigation pour avoir par exemple les derniers radars, les stations services proches. L’approche temps réel peut exister pour les conditions de trafic avec la norme TMC, mais cela reste assez limité en intéraction.

Tout est donc une question de contexte de mobilité. Pour faire un trajet de 500 km, le GPS de navigation est un très bon outil. En situation de mobilité piéton c’est autre chose et la plus value de ses données n’est pas vraiment des plus adaptées. Le mobile va donc compléter le GPS de navigation et pas le supplanter.

Il semble donc important, pour un service utilisant la géolocalisation sur téléphone mobile, d’éviter à l’utilisateur de saisir l’endroit où il se trouve. C’est une manipulation fastidieuse qui peut très rapidement le rebuter à utiliser le service.

Pour exemple, nous pouvons prendre l’iPhone qui est un appareil unique en son genre. L’interface est simple et accessible. Il est donc possible pour un appareil adapté (écran large et tactile) d’offrir une expérience utilisateur véritablement enrichissante en situation de mobilité. Il est aujourd’hui très complexe pour les développeurs d’applications mobiles d’offrir une application compatible sur parc d’appareils hétérogènes. Heureusement le renouvellement de ce parc est de plus en plus rapide (de 1 à 2 ans) et l’arrivée de l’iPhone et d’Androïd de Google peuvent changer la donne.

En résumé : 2008, l’arrivée de la mobilité version 2.0

• Applications nouvelles et compatibles
• Nouvelle expérience utilisateur
• Localisation automatique précise
• Réseaux sociaux mobiles