Au cours de la présentation de la nouvelle version de son OS pour mobile, Google a présenté Maps Navigation, évolution de Google Maps Mobile. Ce logiciel disponible pour Android 2.0 propose la navigation GPS avec pour source d'information les données de Google, c'est à dire vue 3D, satellite ou StreetView. Ce logiciel offre la possibilité, comme de nombreux logiciels de se type, d'être guidé par la voie. Le premier petit plus est la possibilité de faire un recherche vocal. Le second plus et non des moindres est la gratuité de la solution. Tous les futurs possesseurs d'un téléphone équipé d'Android 2.0 y auront accès.
Après avoir fait bougé le monde des solutions cartographiques web, Google jette un pavé dans la mare des solutions GPS. TomTom en a déjà fait les frais sur les places boursières même si les 2 solutions diffères notablement.
Dans le cas de la solution de Google, le données géographiques et les systèmes de calcul restent sur le réseaux.
Les utilisateurs de la solution de Google auront l'avantage de ne pas avoir à mettre à jour les données de leur application GPS, tout comme les utilisateurs d'OVI Map de Nokia. Mais les solutions de TomTom conservent un avantage non négligeable. Les solutions du néerlandais sont exploitable même dans des zones non couvertes par la 3G ou le wifi. Cette contrainte limite tout de même l'intérêt de la solution de Google, à moins que les opérateurs télécoms n'y voient une bonne raison d'améliorer leur couverture ou que les utilisateurs se contentent de s'en servir à pied.
The Walmartization of technology continues. Why pay for anything if Google will eventually give it away free?
La Walmart-isation des technolgies continue. Pourquoi payer pour quelque chose que Google fournira gratuitement par la suite ?
J'aime à croire que l'arrivé de Google dans le domaine des solutions de navigation GPS créera une émulation tout comme Google Maps l'a fait dans le domaine de la cartographie Web, même si tous les jours on me retourne la question suivante :
Pour quoi ne pas utiliser Google Maps ? C'est gratuit, non?
Plusieurs volontaires et developpeurs OpenLayers se sont rassemblés samedi après les FOSS4G pour participer au Code Sprint. Et devinez quoi : de nombreuses choses ont été accomplies! En voici un petit apperçu :
Julien a également commencé à étudier la stratégie de rafraichissement (''Refresh Strategy'') qi avait été introduit par Kris Geusebroek (Xebia).
Robert Coup (Koordinates Ltd) a étudié en profondeur le problème des fuites mémoires et réalisé plusieurs patches, le tout accompagné de tests de mémoire. Il continue son travail de fixation des fuites mémoires. Le tout est basé sur un patch originel de Kris.
Klokan Petr Přidal a réalisé un petit mais performant patch pour le support des grilles composées de tuiles tronqués en bordure bas et droite de la grille. Ce patch est nécessaire pour le support de couches de ce type comme Zoomify, pour lequel un autre patch est en attente d'examen.
Marc Jansen (Terrestris) a commencé le nettoyage des exemples : il a ajouté de nouveaux mots clefs, amélioré les descriptions et ajouté des notes à propos des pratiques obsolète que certains exemples présentent encore.
Volker Mische (LISAsoft) a dépensé de l'énergie a faire en sorte que les cartes OpenLayers soit déplaçable même lorsque le curseur de la souris sort de la fenêtre de la carte (comme dans Google Maps). Cela nécessite encore du travail, mais Andreas Hocevar aidera Volker et le correctif devrait bientôt être intégré au tronc. Il faut ajouter que ce problème est ancien - Billet #39.
Roald De Wit (LISAsoft) a fait en sorte que les tuiles roses qui indique qu'une image n'est pas disponible soient configurable en CSS.
Roald et Volker ont également rejoint Andreas au tableau, et en observant le slider du contrôle PanZoomBar ils ont trouvé le moyen de créer une nouvelle class séparant l'interface utilisateur de l'interaction avec la carte. Ils n'ont pas eu assez de temps pour réaliser un proof-of-concept, mais Roald et Volker devrait le mettre en oeuvre dans un des bacs à sable. Il faut donc s'attendre à une discussion plus approfondie à propose de cela prochaine sur la liste dev.
Bart van den Eijnden (OSGIS) et Eric ont passé en revue certains nombres de billets qui étaient dans les tuyaux et ont mis les correctifs dans le tronc.
Avoir des développeurs de différents projets assis dans la même pièce entrainent des synergies : Klokan Petr Přidal (connue pour MapTiler) étant assis à côté de Mike Adair (connue pour proj4js), ils ont rapidement codé un démonstrateur de reprojection côté client de matrice avec <canvas/> et proj4js. J'en ai parlé dans un billet précédent.
Andreas Hocevar (OpenGeo) a fait de son mieux pour aider les participants. Il s'excuse si il n'a pas pus répondre à toutes les questions qui ont été posé au cours du sprint, mais il restera à disposition pour du support et des conseils à propos de tous les bons développement qui ont été commencé, donc ils pourront être amené à leur terme.
En raison de l'utilisation de l'élément <canvas/>, ce prototype n'est pas disponible que pour les utilisateurs de Firefox (version 3 minimum), Chrome, Safari et Opera.
Essayez la démo :
Cette démonstration est intéressante, il faudrait voir comment exploiter les Web Workers, afin de réaliser la reprojection sans freezer l'interface utilisateur, et quelle pourrait être son utilisation avec OpenLayers.
Just after the EuMozCamp09HTML5 Roundtable, I've proposed to Vladimir Vukićević the idea to add the possibility to say "Where I Am" in Firefox. He said that this functionnality it's more suitable as an add-on.
During this conversation, I've thought that the Firefox user should be able to choose his geolocation directly in the notification. It's what I've done.
Yesterday, Gervase Markham proposed to add "Where I Am" in Firefox with a feature in the geolocation info bar "Find Myself On A Map", and when I read it, I said to myself: "It's What I Done With My Add-On: Geolocater, Isn't it ?"
Besides, Gervaseasks this question : Would you like to see "Where I Am" directly implemented in Firefox 3.7 ?
Le Zoo Projecta été présenté aujourd'hui à Sydney. Ce projet a pour objectif de fournir un serveur de services WPS (Web Processing Service norme de l'OGC). Les Web Processing Services permettent de réaliser des opérations sur des données en mode distribué comme par exemple la reprojection, la modification de format, etc. La particularité du Zoo Project est de pouvoir charger dynamiquement des modules externes codés dans différents langages comme le C/C++, le python ou le perl. Les premiers modules réalisées par Geolabs sont basé sur GDAL/OGR, GEOS et Proj4. C'est donc un serveur de services WPS extensible et personnalisable. La seule limite étant votre propre imagination.
Guillaume Sueur en fait la base pour le développement des Web SIG de demain voir même une version full Web de FME!
Bien sûr il reste encore quelques développements avant que le zoo-project soit visible et que vous puissiez le tester. Stay tune!
Le week-end dernier à Plouarzel a eu lieu la "cartopartie" la plus à l'ouest du continent (Ouest France).
Je profite de l'évènement pour mettre en avant le sondage d'opinion proposé par Pieren pour inventer un néologisme traduisant "mapping party". Le journaliste de Ouest France a choisi son camp selon de "cartopartie" pourtant pour le moment aucun terme n'a été choisi pour communiquer dans les pays francophones sur ces évènements.
Les "mapping parties" ou "cartoparties" ou encore "festographies" sont des évènements où des OSMeurs, contributeurs à OpenStreetMap, chevronnés convient tous ceux qui le souhaitent à cartographier un territoire. Lors de ces "cartoparties", les débutants sont initiés à l'utilisation des récepteurs GPS qui sont souvent prêtés par les organisateurs. L'intérêt des "cartoparties" est de faire ce qui n'a pas encore été cartographié et de s'intéresser à des monuments particuliers. Par exemple à Plouarzel, la "cartopartie" s'est intéressée aux fours à goëmon, calvaires, lavoires, fontaines, etc.
The Geolocation API is fairly well implemented by the different browsers on the market. The problem is that it's perceived as only useful on mobile. This perception is due to the fact that the Geolocation API is presented as a means to indicate to a web application where we are, but this information is provided by the browser, it is therefore possible to allow a user to decide where he wants to be geolocated when he is on the Internet. Geolocater offers users to choose the way to be geolocated when a Web application requests it.
The interest you can save locations to choose which geolocation use when an application requests it and facilitate the use of location-based information.
To highlight the importance of being able to choose your position on earth when you're on the Web, I made a video demonstration with Flickr. The Flickr mapping application is equipped with a 'Find my location' button. This button launches a geolocation request to the browser. As mentioned in the specification of the Geolocation API, the browser must notify the request, unless you have specified that you no longer wanted notification. If you have installed Geolocater and you have not disabled notification for Flickr, you can select the geolocation you want to send to Flickr to find photos nearby. You can easily navigate through the world and discover images from around the world.
L'API de Géolocalisation est plutôt bien implémentée par les différents navigateurs du marché. Le problème est quelle est perçue comme étant seulement utile sur mobile. Cette perception est dûe au fait que l'API de Géolocalisation est présenté comme un moyen d'indiquer à une application Web où l'on est, hors cette information est fournie par le navigateur, il est donc possible de permettre à un utilisateur de décider où il souhaite être géolocalisé quand il est sur internet. Geolocater propose aux utilisateurs de choisir le moyen de se géolocaliser lorsqu'une application Web le lui demande.
L'intérêt de pouvoir enregistrer des localisations est de choisir quelle géolocalisation utiliser lorsqu'une application le demande et de faciliter l'utilisation d'informations géolocalisées.
Pour mettre en avant l'intérêt de pouvoir choisir sa position sur terre lorsque l'on est sur le Web, j'ai réalisé une vidéo de démonstration avec Flickr. L'application cartographique de Flickr est munie d'un bouton 'Find my location'. Ce bouton lance une demande de géolocalisation au navigateur. Comme cela est précisé dans la spécification de l'API de Géolocalisation, le navigateur doit notifier la demande, à moins que vous ayez précisé que vous ne vouliez plus de la notification. Si vous avez installé Geolocater et que vous n'avez pas désactivé la notification pour Flickr, vous pouvez sélectionner la géolocalisation que vous souhaitez transmettre à Flickr pour qu'il trouve des photos à proximité. Vous pouvez ainsi facilement naviguer à travers le monde et découvrir des images du monde entier.
Les circuits de formule 1 présents dans OpenStreetMap maintenant consultable, via Mapperz.
Les contributeurs Google Maps vont pouvoir facilement créer des batiments dans 50 villes grâce à Google Building Maker.
TomTom a collecté plus de 800 milliards de mesure de vitesse en 3 ans et ce nombre augmente de 1 milliard chaque jour. Avec une telle source de données il est possible de mieux connaître les réseaux routiers. Source ERTICO.
Après de nombreux mois de discussion et 12 jours d'imports, les données OpenStreetMap en France ont été complétées par les données Corine Land Cover. Tous ceux qui naviguent régulièrement sur OpenStreeMap ont dû s'en apercevoir la carte de la France est moins vide (plus de forêt, de zone urbaine ou agricole, etc).
Je me permet ici de dupliquer le mail envoyé par Pieren à la liste OpenStreetMap France suite à la fin de l'import :
L'import automatique des données Corine Land Cover France 2000-2006
est terminé. Tout le monde aura pu constaté ses effets sur la carte en
ligne.
Mais il reste encore beaucoup à faire ! Une partie des polygones CLC
n'a pas été importée, soit parce que nous n'avons pas pu déterminé de
correspondance entre la nomenclature d'origine et celle d'OSM (voir
1), soit parce qu'ils entraient en collision avec les "landuse" déjà
présents. On peut aussi voir que ces polygones sont souvent mal
positionnés ou même parfois que l'usage des sols n'est plus à jour. Ce
qui était prévisible lorsqu'on sait que ces données sont faites pour
un usage au 1/100.000e avec une surface minimale de 25 hectares et une
largeur d'au moins 100 mètres.
N'hésitez donc pas à modifier, découper, déplacer et torturer ces
polygones si vous disposez d'informations de meilleure qualité (GPS,
cadastre, imagerie Yahoo, etc) et n'oubliez pas de supprimer les tags
"CLC:" du même coup. Il faudra en particulier revoir toutes les lignes
de côtes mais ne pas forcément effacer tout ce qui dépasse (les
natural=wetland et water=tidal en particulier).
Pour ceux qui voudraient récupérer les polygones CLC manquant pour
pouvoir les intégrer manuellement, Étienne devrait mettre rapidement
une application en ligne.
Pour finir, je voudrais quand même adresser quelques remerciements.
D'abord aux autorités françaises qui ont libéré ces données en les
rendant compatibles avec la licence CC-BY-SA d'OSM et qui ont toujours
répondu promptement à nos questions (2 et 3), en particulier à Philippe
Dorelon, de l'Ifen et responsable Corine Land Cover France et aux
responsables européens co-producteurs de ces données.
Ensuite, à tous ceux qui ont participé aux discussions sur la
traduction des classes Corine en tags OSM en mai et juin, en
particulier Vincent Pottier, initiateur de la page "nomenclature CLC"
sur le wiki, Valérie-Emma Leroux, Sylvain Letuffe, Émilie Laffray,
Yann Coupin, Mathieu Arnold, Frédéric Bonifas, Antoine et tous autres
(Julien, Didier, g.di, etc).
Et enfin, merci à l'équipe qui s'est constituée pour l'occasion et qui
n'a pas compter ses heures: à Yann pour avoir modifier le script
python bulk_upload.py pour lui faire avaler les 1.3 Go du fichier
.osm, à Sylvain pour avoir toujours mis promptement nos cartes Corine
en overlay sur son site et identifié certains de nos problèmes,
Vincent qui m'a aidé pour l'upload durant ces douze jours, Étienne
pour son soutien et l'outil qui permettra d'intégrer le reste des
polygones et surtout Émilie qui était la seule capable de convertir
(en modifiant les scripts d'origine), trier et générer les polygones
CLC en tenant compte des landuse déjà présents dans OSM.
C'est officiel depuis mercredi, Google va progressivement remplacer les données Tele Atlas par ses propres données géographiques en commençant par les USA. Cette information a été confirmer par Tele Atlas jeudi à la conférence Location Intelligence 2009 à Denver, GeoInWeb.
Mais la question principale est d'où viennent la majorité des données si Google n'utilise plus Tele Atlas. James Fee et OpenGeoData supposent que Google réutilise des données d'agences nationales comme celle de l'USGS ou les données TIGER.
Tout ça me fait penser qu'OpenStreetMap est la solution qu'il nous faut promouvoir au près des collectivités locales. Car si elle décide de faire partager leurs connaissances à leurs administrés via un système de publication de carte, avec OpenStreetMap elles pourront réutiliser les données fournies et les corrections réalisées par la communauté. En fait elle profiterais d'un échange donnant-donnant. Ce qui n'est pas vraiment le cas avec Google puisque les données porte la marque de Google.
Andre Aime d'OpenGeo coordonnera la mise en place et la configuration de GeoServer ainsi que de fournir une expertise dans l'analyse comparative qu'il a acquise en travaillant sur les épreuves des années précédentes.
Pour des raisons de sécurité, il n'est pas possible de faire en JavaScript une requête XML sur un autre domaine. Il existe tout de même des astuces mais pas très propres...
Cette limitation est légitime mais pour certains services comme GeoNames, cette limitation n'a pas de sens. Par exemple, GeoNames est prévu pour être accessible par tous et de partout.
Il est possible d'ouvrir son service à tout ou partie du Web via HTTP access control.
Paul Rouget (Mozilla evangelist) a contacter l'équipe GeoNames pour leur demander si il pouvait ouvrir leur service. Ce qu'ils ont fait en ajoutant un nouveau header HTTP :
Access-Control-Allow-Origin: *
Maintenant il est possible d'utiliser GeoNames de n'importe quel nom de domaine an JavaScript via XMLHttpRequest. C'est ce que l'on appelle le cross-site XHR.
Donc :
si vous êtes développeur de web services, réfléchissez à autoriser le cross-site XHR.
si vous utilisez un web service, contacter l'auteur et faites lui savoir qu'il peut ouvrir son service.
A votre avis OpenStreetMap devrait-il ouvrir son service au cross-site XHR ?
MapServer 5.6.0 beta 1 a été publié. C'est une version pour développeur que vous pouvez tester pour valider un certains nombres d'évolutions. La version finale devrait être publié pendant les FOSS4G.
Taguer vos photos sur flickr avec OSM. Vous pouvez ajouter un tag osm dont la valeur est l'identifiant d'un objet OSM. Ce qui permet de géolocaliser facilement les photos et de visualiser précisément l'objet associer à celles-ci. La difficulté est qu'il faut connaître l'identifiant de l'objet OSM.
