neogeo

Ca semble un peu inouï dit comme ça, mais un brevet a été déposé par A9.com, une société du groupe Amazon.com, concernant un “Search engine system supporting inclusion of unformatted search string after domain name portion of URL”, soit en bon français : “Moteur de recherche acceptant l’inclusion d’une chaine de recherche non formatée après le nom de domaine dans l’URL”, donc quelque chose du genre : http://www.recherche.com/spaghetti bolognaise (les espaces sont acceptés). Voir ici pour les détails. Il y est précisé que le principe breveté concerne la soumission d’une chaîne de caractères à un moteur de recherche si cette chaîne ne correspond pas à une ressource existante.
Est-ce que cela signifie que toute structuration un rien RESTFul tombe dans le champ d’application de ce brevet pour peu que l’URL corresponde au modèle breveté ? Si http://www.communes.com/31555 pointe sur une ressource, ça semble bon, mais si http://www.communes.com/Toulouse passe au travers d’un mod_rewrite qui appelle http://www.communes.com/search.php?q=Toulouse pour renvoyer ensuite la ressource http://www.communes.com/31555, on est bien dans le champ d’application du brevet.

Je ne suis pas spécialiste des brevets, mais je frissonne déjà à l’idée de devoir vérifier si ma structuration d’URL, et donc l’architecture de mon application web, ne tombe pas sous une telle protection. Car si A9.com a pu le faire pour quelque chose d’aussi simple et basique, qui va se gêner ? Wikipedia pourrait deposer les URL en http://xxxx/wiki/chaine_de_recherche par exemple. Enorme bourde de l’USPTO ou nouvel eldorado des verrouilleurs de tout poil ?

Via slashdot

Comme le remarque justement Peter Batty Google vient de changer les règles d’utilisation de son service de géocodage. On passe d’un mode de fonctionnement basé sur un nombre de requêtes journalières par clé à un nombre de requêtes journalières par IP, le nombre limite tombant de 50000 à 15000. Ca change tout, et chacun y trouvera avantage ou inconvénient selon son utilisation du service :

- vous proposez un service de géocodage en ligne ? Chacun de vos clients (au sens informatique, et, peut-être, commercial ;-)) pourra effectuer 15000 opérations par jour. MAIS le traitement devra être effectué par son navigateur, et non plus par votre serveur, car sinon vous n’auriez plus que 15000 opérations à partager entre tous vos clients. Donc les scripts doivent être éventuellement adaptés, de manière à tourner sur le navigateur, en utilisant l’API javascript du Geocoder. Ce qui ne va pas faciliter l’ergonomie, car concrètement cela se traduit par : upload d’un fichier d’adresses sur le serveur, renvoi du contenu du fichier au client (en XML par exemple, ou en JSON), traitement par javascript des adresses, renvoi des résultats au serveur, mise en forme et enfin renvoi au client du fichier d’adresses initial augmenté des coordonnées. Ces multiples allers-retours ne vont pas faciliter la manoeuvre. L’utilisateur quant à lui va devoir laisser ouvert son navigateur pendant tout le traitement, quand l’exécution côté serveur pouvait simplement lui renvoyer par mail un lien de téléchargement quand toutes le adresses avaient été traitées (ce qui donnait une raison très légitime à la demande d’identification de l’utilisateur).

- vous géocodez vous-même beaucoup d’adresses ? Sous réserve de recomposer vos scripts s’ils s’effectuaient sur un serveur (ce qui semble logique pour des traitements de masse), vous allez pouvoir mettre tout le monde au travail, chacun des postes de vos collègues pouvant traiter 15000 adresses par jour. En plus, ils auront même l’impression de travailler en regardant Firefox tourner tout seul ! SAUF QUE… vous avez un proxy ! Pas de chance, vous avez tous la même IP publique, donc c’est en fait 15000 pour toute la boîte. Ce n’est pas demain que vous terminerez de géocoder les Pages Jaunes (quoiqu’avec quelques stagiaires travaillant à domicile…)

Donc l’un dans l’autre, Google nous donne plus de souci que de liberté avec ses nouvelles règles (qui peuvent changer à tout moment, sans préavis, parce que Google c’est gratuit, mais ce n’est ni OpenSource ni Free Software). D’autant que la clé est toujours nécessaire et que le nouveau mode de fonctionnement donne à Google moyen de savoir plus précisément ce que vous faites avec son géocodeur puisque les cas d’utilisation ci-dessus sont facilement identifiables : beaucoup d’IP avec votre clé pour le premier, très peu mais flirtant quotidiennement avec la limite autorisée pour le second. Donc Google sait ce que vous faites, qui sont vos clients et quel est votre volume d’activité. Ne l’oubliez pas !

Il faut bien que je révise complètement mon jugement précédent concernant OpenLayers. Je lui reprochais son approche essentiellement mash-up, d’agrégateur de multiples formats de données (WKT, GML, KML, GeoRSS, GeoJSON) dans une interface certes très ergonomique mais relativement pauvre fonctionnellement, tout en souhaitant voir plus de réelles fonctionnalités SIG se traduire concrètement en webmapping…

Pendant que j’écrivais ces lignes donc, Christopher Schmidt était en train de mettre la touche finale à du WebProcessingService (WPS) intégré à OpenLayers. Ce qui donne  exactement le genre de résultat que j’appelais de mes voeux ! Voilà qui permettra mieux aux “Grey suit guys” de démontrer la qualité de cet environnement et d’en généraliser l’utilisation.

J’ai eu un peu de mal à installer OpenJump sous Ubuntu, donc je vous livre ces quelques indications qui peut-être vous seront utiles :

1. Installation de la machine virtuelle Java (si ce n’est pas déjà sur le système) :

sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-fonts
2. Récupération du zip sur le site d’OpenJump et extraction dans /opt/ par exemple

3. Modification des droits sur le fichier openjump-unix.sh :

sudo chmod a+x openjum-unix.sh

4. Nettoyage du fichier openjump-unix.sh qui est au format DOS :

sudo dos2unix openjump-unix.sh

N.B. : dos2unix corrige les retours chariot. Il se trouve dans le paquetage sysutils (sudo apt-get install sysutils)

5. Lancement de openjump-unis.sh

sudo ./openjump-unix.sh

Si une erreur Java à propos de awt apparaît, compléter l’install avec :

sudo apt-get install libgcj7-awt

6. Normallement, ça marche…

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.