Journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans)

Posté par . Licence CC by-sa
Tags : aucun
25
13
mar.
2012

Je viens de traduire sur mon blog un billet d'un des gros contributeurs à OpenStreetMap qui clame que «Google n'est pas notre ennemi». Vous pouvez le lire sur le blog en question où vous aurez quelques liens en plus mais je l'ai aussi copié-collé ci-dessous, sous CC-BY-SA.

Dans les billets récents qui peuvent vous intéresser, j'en profite pour signaler un papier d'un juriste allemand, traduit en français, assez long et un peu lourd mais intéressant, sur les rapports actuels en allemagne entre droits des médias et droit de l'Internet.


Frederik Ramm est développeur logiciel indépendant, contributeur de longue date à OpenStreetMap (OSM) tant pour le code que pour les données, co-auteur d'un livre sur OSM et un des dirigeants de la Geofabrik à Karlsruhe, qui permet entre autres de mutualiser les conseils, développements et de enseignements autour des cartes libres. Il explique les relations entre la fondation OSM et Google dans ce billet.

OSM est souvent perçu comme la némésis de Google en cartographie ou au moins, sans rêve de grandeur, un de ses concurrents. Il est vrai que quand je dois expliquer OpenStreetMaps en un paragraphe je commence souvent par « Contrairement à Google Maps, avec OSM, on peut… » C'est peut-être la raison pour laquelle beaucoup pensent que Google est notre ennemi.

Mais est-ce seulement vrai ?

Nous avons toujours eux de bonnes relations avec Google. Ed Parsons, le « technologist geospatial » de Google, et Steve Coast se connaissent depuis longtemps. Steve Coast a commencé à s'investir dans Open Street Maps parce qu'il était frustré par les licences radines de l'agence (semi)étatique de géodonnées Ordnance Survey en Angleterre. À cette époque, Ed Parsons était le patron d'Ordnance Survey et il a du défendre plusieurs la conduite de son entreprise par rapport à des nouveaux arrivants comme nous. (Quelques uns disent qu'il était aussi frustré des licences d'Ordnance Survey que nous). En 2006, Steve a même conduit une interview avec Ed pour le blog OpenGeoData. En 2007, lorsque notre premier congrès « State of the Map » a eu lieu à Manchester, Ed, qui était passé chez Google, a tenu le discours d'ouverture, et a sinon participé à de nombreux congrès ultérieurs comme invité ou orateur. À SOTM 2011 il a écrit « Semaine formidable à State of the Map. OpenStreetMap a tout l'air d'un projet déjà mûr. »

Google a sponsorisé les « State of the Map », nous a donné depuis notre première participation en 2008 plusieurs places dans son « Summer of Code », et lorsque nous avons pour la première fois orchestré un appel aux dons en 2009, nous a donné le plus gros don, 5 000 livres, sans que nous ayons rien demandé.

En outre, technologiquement parlant nous profitons aussi tous les jours du rôle de précurseur de Google. Que nous puissions mettre une carte OpenLayers sur n'importe quel site et que tout le monde sache comment ça fonctionne : Google. Les projections que nous utilisons tous et tranchent beaucoup de nœux GIS gordiens : Google. Le format de données PBF économe en espace de stockage et que nous utilisons de plus en plus : Basé sur les « protocol buffers » de Google. Et la liste continue. Je ne crois pas qu'OpenStreetMap ait plus profité du support direct comme indirect d'une entreprise qu'avec Google. Je me suis moi-même épargné d'innombrables heures en pouvant simplement déclarer : c'est comme Google Maps, sauf que chacun peut participer et réutiliser les données.

Certes, il y a eu quelques problèmes dans le passé, losque nous avons retrouvé des données OSM dans les cartes Google, mais ça a généralement pu être réglé rapidement à « l'échelon hiérarchique supérieur ». Aussi loin que je puisse m'en souvenir, c'était toujours des cas où un sous-traitant ou un utilisateur de « Map Maker » avait foutu le binns. Inversement, quand de temps en temps quelqu'un fait du zèle et utile des sources Google sans que ce soit permis, nous supprimons ces données sans avoir reçu aucune injonction à arrêter.

Je ne suis pas dans le système Google, mais pour moi il est clair comme de l'eau de roche que l'agenda de Google est l'amélioration (et l'observation des) flux d'information sur Internet. Google y gagne une compréhension précieuse de ce que la génération pré-facebook connaît encore sous le terme « vie privée », pour vendre de la publicité. Google lit tes mails, mais pas parce que ce sont des méchants, seulement parce que tu as librement décidé d'utiliser leur service gratuit et efficace de courriel. Google lit même les papiers internes de la fondation OpenStreetMap avant que nous lisions nous-mêmes, parce que nous utilisons Google Docs. J'accorde volontiers que cette omniprésence et presque-omniscience de Google est quelque peu menaçante, mais cela ne nous en fait notre ennemi. Je suis sûr que Google partagerait volontiers nos cartes pour observer ses utilisateurs, mais cela n'en fait pas un concurrent. À l'évidence c'est parce que notre licence leur paraît inappropriée pour ça, et je ne les en blâme pas. J'ai entendu que quelques grosses compagnies sont prêtes à lancer des services basés sur OSM dès que nous changerons de licence, parce qu'ils se méfient de notre CC-BY-SA.

Nous avons déjà approché maintes fois Google parce que nous utiliserions volontiers leurs photos aériennes. La couverture et la qualité du matériel de Google est souvent meilleure que ce que nous avons reçu de Bing. Sans succès. L'excuse officielle est qu'ils ne possèdent pas la permission de transformer ces images, ce qui me semble un peu bizarre vu Mapmakr, mais qui sait. J'ai déjà vu beaucoup de licence très bizarres dans le domaine de la cartographie. Les images de Google Street View pourraient aussi nous aider à cartographier mais nous n'avons pas de blanc-seing, même si dans quelques cas particuliers cela nous a déjà été permis.

OSM n'essaye pas d'être un meilleur « GoogleMaps ». Nous n'y arriverons jamais. Il nous manque quelques conteneurs remplis de matériels. Google s'est retrouvé à l'affiche des journaux parce qu'il a été dit qu'à l'avenir l'utilisation intensive de Google Maps serait payante et que quelques personnes influentes ont sauté dans le train switch2osm. Nous nous en réjouissons, mais en même temps il faut être honnête : Celui qui attend d'OpenStreetMap la même qualité de service que celle de Google Maps, avec un bon CDN, avec de la capacité à monter en charge et des infrastructures redondantes, comme dans l'offre Google, il ne s'en sortira pas forcément à meilleur compte que s'il restait chez Google. Dans un futur proche, OpenStreetMap n'offrira pas non plus de vue aérienne et beaucoup d'autres trucs que les utilisateurs de Google Maps pensent acquis.

Nous chez OpenStreetMap, nous ne cherchons pas à être une alternative à Google Maps, mais bien plutôt aux bases de geodonnées administratives ou produites commercialement. Nous sommes plutôt des concurrents pour TeleAtlas ou Navteq que pour Google. Google avait aussi commencé à récolter ses propres géodonnées dans sa jeunesse, mais seulement parce qu'ils souffrent du même problème qu'OpenStreetMap, à savoir le manque de géodonnées disponibles à des conditions acceptables.

Deux des membres de notre directoire dans la fondation OpenStreetMap, Steve Coast et Mikel Maron, ont récemment lancé quelques piques empoisonnées à Google. Le motif était un cas de vandalisme sur OSM pour lequel les deux ont prématurément supposé que Google était complice ou au moins avait négligemment laissé faire. En outre Mikel a sur son propre blog très clairement critiqué la stratégie de Google dans les pays émergents, où il voyait un affront contre les mouvements d'Open Data. Un accord que Google a récemment conclu avec la banque mondiale et qui, si appliqué, irait à l'encontre de l'engagement de cette banque en faveur de l'Open Data, a aussi amené Mikel et d'autres à critiquer Google.

Google est une organisation comme toutes les autres. Et suit les mêmes règles que tout le monde : Si vous n'y faites pas attention, les chefs qui s'aident avant tout eux-mêmes monteront dans la hiérarchie, parce que pour plaire au patron suivre un agenda personnel ou tel ou tel but lointain peut être plus important que faire ce qui est bien. Il est donc toujours possible que les choses déraillent et il serait bon que nous gardions sur Google et nous lui tapions sur les doigts de temps à autre. Mais dans l'ensemble, je trouve que nous sommes du même côté : pour « l'intelligence collective en mode bazar » plutôt que pour « les cathédrales de données des administrations et entreprises ». Et c'est sans doute plus vrai avec eux qu'avec d'autres entreprises qui se battent pour notre affection.

  • # Autre version publiée vers midi

    Posté par . Évalué à 4.

    • [^] # Re: Autre version publiée vers midi

      Posté par (page perso) . Évalué à 1.

      Sans vouloir t'offenser, je trouve que la traduction de René-luc est bien meilleure. Il y a des phrases dans ton journal que je n'ai pas compris…

      • [^] # Re: Autre version publiée vers midi

        Posté par . Évalué à 3.

        Et en donnant des exemples ?

        • [^] # Re: Autre version publiée vers midi

          Posté par . Évalué à 4.

          mais pour moi il est clair comme de l'eau de roche que l'agenda de Google est l'amélioration (et l'observation des) flux d'information sur Internet

          Cette phrase est très mal formulée…

          • [^] # Re: Autre version publiée vers midi

            Posté par . Évalué à 1.

            Globalement, je dirais que la traduction est assez lourde. Et là par exemple le «des» aurait du être après la parenthèse. À ma décharge c'était pas toujours très léger en anglais ou en allemand non plus. Mais ça me semble quand même compréhensible.

            • [^] # Re: Autre version publiée vers midi

              Posté par . Évalué à 1.

              Déplacer le "des" hors des parenthèses ne rend pas la phrase plus claire. ça signifie quoi "l'agenda de google est"? (pendant un moment j'ai cru que tu parlais de l'application agenda de google)

              • [^] # Re: Autre version publiée vers midi

                Posté par . Évalué à 2.

                Réponse grâce à Wikipédia : 

                Le terme « agenda » vient du latin ; plus précisément il s'agit de la déclinaison au nominatif pluriel de agendus, a, um, c'est-à-dire l'adjectif verbal de ago, agere (« faire »). Littéralement « agenda » signifie donc « ce qui doit être fait » ou, mieux : « [les choses] à faire ».

                En anglais, il signifie « ordre du jour ». La proximité avec la signification en français fait qu'on observe assez souvent un glissement de sens, notamment dans le domaine journalistique devant traduire rapidement de l'anglais : « l'agenda du conseil des ministres... » ou « l'agenda de la réunion... ». Cet emploi est incorrect.

                Vu qu'en latin ça veut dire «ce qui est à faire» (sur le mode carthago delenda), ça me paraissait clair. Agenda de Google : ce que Google a prévu de faire.

                • [^] # Re: Autre version publiée vers midi

                  Posté par . Évalué à 0.

                  Oui je me doutais bien que c'est ce que tu voulais dire mais a) je trouve ça pas très clair b) en français ce n'est pas très correct comme le rappelle ta citation, et on peut difficilement deviner que tu nous parle en anglais ou en latin. donc "l'ordre du jour", ce serait mieux et encore il faudrait quand même revoir ta phrase je pense

        • [^] # Re: Autre version publiée vers midi

          Posté par . Évalué à 0.

          Les projections que nous utilisons tous et tranchent beaucoup de nœux GIS gordiens : Google

          je comprend pas trop cette phrase. Que vient faire le "et" ici par exemple

  • # Il des mots.

    Posté par . Évalué à 3.

    Avant-dernière phrase : « il serait bon que nous gardions (un œil ?) sur Google et (que) nous lui tapions sur les doigts de temps à autre ».

    (Pour le titre, j’ai adapté une citation de Grunt.)

    Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Il des mots.

      Posté par . Évalué à 1.

      Merci pour le retour ! N'hésitez pas à les signaler, je ne suis pas adepte des posts bourrés de fautes :)

      • [^] # Re: Il des mots.

        Posté par . Évalué à 3.

        Je viens de corriger encore quelques mots manquants, fautes d'accord etc… de l'autre côté, mais bon, ici c'est pas possible. Dsl pour les lecteurs auxquels j'ai écorché les yeux.

  • # Détail…

    Posté par (page perso) . Évalué à 6.

    Google lit tes mails, mais pas parce que ce sont des méchants, seulement parce que tu as librement décidé d'utiliser leur service gratuit et efficace de courriel.

    Ou parce que ton correspondant à fait ce choix (ou que la personne qui lui à créé sa boite mail à fait ce choix).

    • [^] # Re: Détail…

      Posté par (page perso) . Évalué à -9.

      Ouais et si t'es pote avec un SS les nazis sauront que t'es juif.

      • [^] # Re: Détail…

        Posté par . Évalué à 0.

        Seulement 6 commentaires avant d'atteindre le point Godwin: record battu?

    • [^] # Re: Détail…

      Posté par . Évalué à 2.

      Oui enfin le choix, qui le fait ?

      Tu as "choisi" d'utiliser gmail qui te fournit une boîte mail et quelques applis sympa pour "pas d'euro" (vu que tu payes en nature) parce que tu ne pannes rien à l'informatique, tu veux pas savoir comment ça marche mais t'as (au moins tu en est persuadé) bien compris comment tu pouvais l'utiliser ?

      Tu as "choisi" de prendre la carte de fidélité, qui traces tes moindres habitude de consommateur, de ton dealer de biens de consommation pour pas payer 1 ou 2 % plus cher ce que tu lui pécho ?

      • [^] # Re: Détail…

        Posté par . Évalué à 10.

        D'une part, il n'y a pas qu'une seule solution aux mails persos, et je ne suis pas sûr que Google soit les plus intrusifs dans le domaine.

        En tout cas eux ne rajoutent pas de signatures qui clignotent en bas des e-mails.

        De plus, il n'y a pas que les neuneus de l'informatique qui n'y comprennent rien qui choisissent GMail, il suffit de voir le résultat du sondage ici-même.

        Et même pour les gens qui ne sont pas experts, encore une fois, cessons de croire qu'il faut toujours être expert sur tout pour faire quelque chose.

        Tu refais souvent les calculs de pression d'eau et taille des tuyaux de plomberie quand tu visites un appartement? Pourtant c'est important et une mauvaise installation pourrait mener à la catastrophe! Ah mais non, c'est le boulot du plombier, tu te contentes de tourner le robinet.

        Les plombiers n'exigent pas qu'on apprenne la plomberie, mais curieusement, beaucoup d'informaticiens seraient prêts à conditionner la vente d'un ordinateur à l'obtention d'un permis sur examen!

        Je comprends grosso-modo (--pas plus!!--) comment marche les e-mails et même comment installer un serveur pour ça.
        Mais j'ai pas que ça à foutre, et je pense que je mets beaucoup moins mes données en danger en les confiant à un Google qui regarde dedans qu'en tentant de les sécuriser moi-même, sur mon serveur, avec mes maigres compétences!
        Et je ne parle pas de la gestion des pannes!

        • [^] # Re: Détail…

          Posté par . Évalué à 3.

          Les plombiers n'exigent pas qu'on apprenne la plomberie, mais curieusement, beaucoup d'informaticiens seraient prêts à conditionner la vente d'un ordinateur à l'obtention d'un permis sur examen!

          En même temps, les gens confient la conception, l'entretien et la réparation de leur plomberie à un plombier, donc l'analogie s'arrêtait là.
          J'avais un chauffe eau à gaz, et j'étais obligé d'avoir un contrat d'entretien fait par un plombier pour être couvert en cas d'incendie, par exemple.

          Les utilisateurs veulent des systèmes informatiques aussi simples que tourner un robinet ou se servir du téléphone, qui couvrent leurs usages et pas les autres 85% que peuvent faire un ordinateur, ce qui est compréhensible.
          Par contre, ils ne veulent pas et surtout ne peuvent payer le prix en temps pour apprendre la maintenance, et ne veulent pas et surtout ne peuvent pas payer un informaticien pour le faire. Et les informaticiens veulent faire autre chose que de la maintenance quand ils peuvent.

          La vraie différence avec la plomberie, c'est qu'il n'y avait pas de responsabilité quand quelque chose allait mal.
          Un système informatique mal conçu qu'il faut redémarrer tout le temps, réinstaller en cas de panne, qui fait perdre tous ses mails? Des ordinateurs vendus sans la mémoire ou la carte graphique qu'il faut? Des programmes, des OS, qui plantent tout le temps? Des OS qui permettent les virus, les troyens?
          En informatique personnelle, c'est pas grave, on achète, on réachète, on réinstalle.

          Mais personne n'était responsable des milliards perdus en argent ou en temps.
          Si tu as une fuite d'eau, elle va chez ton voisin ou fait s'effondrer la peinture sur ta tête, ça motive à appeler un professionnel, surtout quand c'est toi le responsable et que tu vas payer.

          Par contre, du fait des problèmes récurrents, les utilisateurs se sont formés à leurs usage contre l'informatique personnelle telle qu'elle était conçue du coup. Je réinstalle, je rachète mais je déteste et je n'ai plus confiance dans les professionnels, je veux juste que ça marche, je m'accommode de la situation pour l'instant mais elle est trop compliquée.
          A partir de là, il était simple de voir qu'ils allaient passer à autre chose et que la direction que l'informatique allait prendre était celle de la simplification des interfaces et des matériels, et que la seule alternative au courant normal proposée par les informaticiens, un système promouvant l'éthique (probablement la racine du problème) mais mettant la ligne de commande au centre et haussant la complexité pour l'utilisateur (c'était déjà le problème) ne réussirait pas à combler cette aspiration.
          Donc les macbook, les téléphones, les applis cloud, et les tablettes, et la révolution n'a pas eu lieu.
          Si elle avait eu lieu, peut être que ça ressemblerait plus à la plomberie avec une responsabilisation à tous les étages.

      • [^] # Re: Détail…

        Posté par (page perso) . Évalué à 7.

        parce que tu ne pannes rien à l'informatique,

        Juste pour info, beaucoup de gens très pointus en informatique utilisent Gmail.
        Tout comme des développeurs de Linux utilisent Mac OS X, si si.

        Quand on aura fini de jouer les élitistes plutôt que de regarder que des outils répondent à des besoins (de simplicité en autre, même si on connait on n'a pas forcément envie de se faire chier), on aura fait un grand pas.

        tu veux pas savoir comment ça marche

        Je n'ai pas le temps de savoir comment tout marche. Par contre, ça marche. Vaut mieux que ça marche sans que je sache comment plutôt que ça ne marche pas tout en sachant pourquoi, question de priorités.

        Ah c'est gens qui veulent que l'informatique soit réservée à une élite…

        PS : je n'utilise pas gmail. Mais plus parce que j'avais déjà un hébergement ailleurs et que j'ai la flemme de changer (on en revient au temps qu'on n'a pas envie de passer dessus) qu'autre chose.

    • [^] # tant qu'on y est...

      Posté par (page perso) . Évalué à 10.

      Google lit tes mails, mais pas parce que ce sont des méchants, seulement parce que tu as librement décidé d'utiliser leur service gratuit et efficace de courriel.

      Ou parce que ton correspondant à fait ce choix (ou que la personne qui lui à créé sa boite mail à fait ce choix).

      Ou parce que ton correspondant et toi ont choisi de communiquer en clair.

  • # openstreetmap et apple

    Posté par (page perso) . Évalué à -1.

    OpenStreetMap est désormais employé par Apple, et on veut nous faire croire que Google n'est pas leur ennemi :-)
    http://www.numerama.com/magazine/21958-apple-migre-vers-openstreetmap-mais-oublie-de-le-signaler.html

  • # s/OpenStreetMaps/OpenStreetMap/

    Posté par (page perso) . Évalué à 1.

    La faute revient souvent, et ça c'est à cause de google (maps) ;-)

  • # Protocole adapté ?

    Posté par . Évalué à 2.

    Celui qui attend d'OpenStreetMap la même qualité de service que celle de Google Maps, avec un bon CDN, avec de la capacité à monter en charge et des infrastructures redondantes, comme dans l'offre Google, il ne s'en sortira pas forcément à meilleur compte que s'il restait chez Google.

    D'un autre côté, le protocole HTTP est pas super bien foutu pour distribuer les mêmes données identiques à plein de gens. Y'a des projets de distribution en P2P de OSM ? Ce serait génial de s'appuyer sur le succès de OSM pour le rendre plus performant à chaque nouvel utilisateur, au lieu de crever des serveurs sous la charge.

    On ne peut pas utiliser les outils du Minitel 2.0 (la webbisation à outrance, avec un NDD qui regroupe toutes les données et les distribue) pour un projet collaboratif et s'étonner que ça marche pas très bien. J'aimerais bien contribuer à OSM en proposant un "cache" des données, et je pense pas être le seul :)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Protocole adapté ?

      Posté par (page perso) . Évalué à 6.

      D'un autre côté, le protocole HTTP

      En fait, je viens de me rendre compte que t'es super fort, comment tu fais, tu as un grep qui tourne en permanence sur les commentaires / journaux pour chopper tout ce qui tourne autour d'http ?

      Ce serait génial de s'appuyer sur le succès de OSM pour le rendre plus performant à chaque nouvel utilisateur, au lieu de crever des serveurs sous la charge

      Ha ok, comme ça c'est chaque utilisateur que tu va blinder…

      On ne peut pas utiliser les outils du Minitel 2.0 (la webbisation à outrance, avec un NDD qui regroupe toutes les données et les distribue) pour un projet collaboratif

      On doit pas avoir la même définition du minitel 2.0 alors.
      la "webbisation" n'a pas vraiment de lien avec le minitel, c'est beaucoup plus la centralisation et le fournisseur unique.
      OSM n'est pas dans ce cas puisque tu peux très bien récupérer les données et les faire fournir par ton propre service. Donc où est le côté minitel 2.0 ?

      J'aimerais bien contribuer à OSM en proposant un "cache" des données, et je pense pas être le seul :)

      Heu, ben pourquoi tu ne le fais pas ?

      Celui qui attend d'OpenStreetMap la même qualité de service que celle de Google Maps, avec un bon CDN, avec de la capacité à monter en charge et des infrastructures redondantes, comme dans l'offre Google

      D'un autre côté, le protocole HTTP est pas super bien foutu pour distribuer les mêmes données identiques à plein de gens.

      Oué enfin y'a pas que http. Pour monter en charge, pour avoir des infra redondantes, que tu utilises http ou pas le problème reste sensiblement le même.
      Et d'ailleurs tu peux aussi avoir un CDN en P2P, c'est pas du tout incompatible.

      Donc où est le problème ?

      Maintenant, sans http, comment tu fais pour afficher un plan de localisation sur une page web ? Ok, tu vas me dire que ça devrait pas être dans le web, mais c'est faux. Donc comment tu fais ? Tu fais un nouveau protocole et tu l'implémente dans ton navigateur ?

      • [^] # Re: Protocole adapté ?

        Posté par . Évalué à 4.

        En fait, je viens de me rendre compte que t'es super fort, comment tu fais, tu as un grep qui tourne en permanence sur les commentaires / journaux pour chopper tout ce qui tourne autour d'http ?

        C'est plutôt tous les journaux et commentaires qui parlent de HTTP. Ce n'est pas moi qui ait décidé que le Web serait "LE" protocole d'Internet. Si 90% des choses dites sur LinuxFR tournaient autour de IRC tout le monde parlerait d'IRC sans même le mentionner. Je ne fais qu'expliciter cette préférence pour le Web que d'aucuns trouvent évidente et allant de soi.

        Heu, ben pourquoi tu ne le fais pas ?

        Parce que je n'ai pas assez de bande passante pour ne serait-ce que 10 personnes qui regardent une carte en même temps depuis chez moi. Et c'est tout le problème avec HTTP (désolé, hein, mais bon) : tu te retrouves avec un serveur qui va servir un nombre indéterminé de clients. Le client est connecté à un seul serveur, et l'utilisateur s'impatiente si ça rame.

        J'aimerais pouvoir dire "ok, je seede 50ko/s au maximum de OSM", et que ça s'ajoute au 50ko/s d'autres caches, jusqu'à fournir à chaque client la quantité nécessaire, plutôt que dire "je pose un cache OSM", qui serve à rien pendant certains moments, et à d'autres moments tout mon upload serait bouffé par dix personnes qui trouvent que ça rame.

        Maintenant, sans http, comment tu fais pour afficher un plan de localisation sur une page web ? Ok, tu vas me dire que ça devrait pas être dans le web, mais c'est faux. Donc comment tu fais ? Tu fais un nouveau protocole et tu l'implémente dans ton navigateur ?

        C'est une obsession, le "navigateur" ?

        Comment je fais pour regarder OSM dans mon client IRC, moi ? :|

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Protocole adapté ?

          Posté par (page perso) . Évalué à 2.

          Parce que je n'ai pas assez de bande passante pour ne serait-ce que 10 personnes qui regardent une carte en même temps depuis chez moi. Et c'est tout le problème avec HTTP

          Heu, http ou pas si tu n'as pas assez de bande passante … ben t'en as pas assez.

          tu te retrouves avec un serveur qui va servir un nombre indéterminé de clients

          Quel est le rapport avec HTTP ? Tu peux très bien avoir un service http qui te répond une 503 service unavailable lorsque le nombre d'utilisateur maximum autorisé est atteint.

          Le client est connecté à un seul serveur, et l'utilisateur s'impatiente si ça rame.

          Pas forcément. Le but des CDN est justement contraire non ? En gros le DNS va prendre en compte certains critères pour te diriger vers le bon serveur (entre autre, en général, la localisation géographique afin de te faire servir par un serveur le plus proche possible, mais rien n'empêche d'avoir d'autres critères comme la disponibilité, le temps de réponse, le statut, etc).

          C'est une obsession, le "navigateur" ?

          Non, c'est juste un exemple. Et la réponse "comment je fais ailleurs" n'y répond justement pas.

          Comment je fais pour regarder OSM dans mon client IRC, moi ? :|

          Et le truc c'est que HTTP est tout fait pertinent lorsqu'il s'agit de fournir une ressource. Ecrire un client HTTP est simple et si tu veux avoir ta localisation dans ton client IRC ça devient justement simple puisqu'il te suffit d'une url pour que ça fonctionne. Et sur ton super client, comme t'aimes bien la séparation, tu peux simplement lui demander de faire un curl de la bonne url dans un fichier temporaire, ton client irc va alors afficher le fichier image dans et hop, c'est fait. Il est donc où le problème avec HTTP ?

          • [^] # Re: Protocole adapté ?

            Posté par . Évalué à 2.

            Heu, http ou pas si tu n'as pas assez de bande passante … ben t'en as pas assez.

            Ben j'ai assez de bande passante pour (avec l'aide d'autres gens intéressés) seeder des fichiers de plusieurs Go.

            Je devrais pouvoir être capable (avec d'autres gens intéressés) d'uploader le tas de fichiers nécessaires à l'affichage d'une carte donnée.

            Sachant que l'espace de stockage n'est pas un problème, j'ai de quoi stocker tout le contenu de OSM. Et j'aimerais juste que les gens puissent venir me demander le petit bout de carte qu'ils consultent, et demandent à d'autres seeders d'autres petits bouts, et construisent leur carte chez eux.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Protocole adapté ?

              Posté par (page perso) . Évalué à 5.

              Je devrais pouvoir être capable (avec d'autres gens intéressés) d'uploader le tas de fichiers nécessaires à l'affichage d'une carte donnée.

              Mais avec une latence de merde, ce qui n'est pas gênant pour un fichier de plusieurs Go mais beaucoup plus pour un petit fichier.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Protocole adapté ?

              Posté par (page perso) . Évalué à 2.

              Bon, je comprends plus. Tu as assez de bande passante ou pas ?

              Sachant que l'espace de stockage n'est pas un problème, j'ai de quoi stocker tout le contenu de OSM.

              Heu, quelle partie du contenu ? Les données (je crois dans les 250Go) mais qu'en est-il des tuiles ? Si tu veux tout rendre il faut compter dans les 54To, la partie communément visible faisant de l'ordre de 1.2To (http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage)

              Héberger une partie de la data tout seul dans ton coin ça va pas servir à grand chose, ce qui compte c'est aussi de pouvoir rendre la tuile (et ça on va pas le faire sur chaque client, d'ailleurs ce serait plutôt idiot car ça voudrait dire que chaque client embarque un serveur de rendu carto) et les perfs seraient assurément catastrophiques.

              Mais dans tous les cas, je vois pas bien le rapport avec http dans l'histoire.
              Qu'est ce qui est bloquant avec HTTP dans ton histoire et qui ne le serait pas avec un autre protocole ? En quoi un autre protocole résoudrait le problème ?

              • [^] # Re: Protocole adapté ?

                Posté par . Évalué à 2.

                Les données (je crois dans les 250Go) mais qu'en est-il des tuiles ? Si tu veux tout rendre il faut compter dans les 54To, la partie communément visible faisant de l'ordre de 1.2To

                Y'a des tuiles vectorielles ? (comme celles de google maps pour android). Ça devrait prendre beaucoup moins de place.

                • [^] # Re: Protocole adapté ?

                  Posté par (page perso) . Évalué à 3.

                  Y'a des tuiles vectorielles ?

                  Je ne crois pas.
                  Dans tous les cas le problème de tuiles vectorielles est que ça ne fait plus vraiment un TMS et qu'il faut rendre (dessiner) ces tuiles côté client. Vu que les tuiles vectorielles ne sont pas vraiment standards et que les nombreux clients ne les supportent pas, ça devient malheureusement peu envisageable.
                  Maintenant rien n'empêcherait d'en générer (ce qui serait il est vrai intéressant côté place et donc bande passante nécessaire, le tout contre un coût d'affichage un peu plus élevé - en terme de puissance demandée)

                  • [^] # Re: Protocole adapté ?

                    Posté par . Évalué à 3.

                    Vu que les tuiles vectorielles ne sont pas vraiment standards et que les nombreux clients ne les supportent pas, ça devient malheureusement peu envisageable.

                    Les clients OSM sont codés en fonction de ce que OSM envoie, non ? Je veux dire que si OSM passe au vectoriel, alors les clients vont (bien obligés) suivre.

                    J'avoue être surpris par ces problèmes de "rendu de carte" alors que la moindre config vendue actuellement est capable de faire tourner un jeu 3D du genre d'OpenArena. À priori ça me paraît capable de faire le rendu d'une carte à partir de données de base :|

                    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                    • [^] # Re: Protocole adapté ?

                      Posté par (page perso) . Évalué à 2.

                      Les clients OSM sont codés en fonction de ce que OSM envoie, non ? Je veux dire que si OSM passe au vectoriel, alors les clients vont (bien obligés) suivre.

                      Non

                      OSM c'est avant tout de la donnée. De la donnée brut. Il faut alors la rendre (générer la carte). Et là plusieurs serveurs existent.
                      Ensuite, côté client, ben en général c'est souvent du WMS / WFS / TMS / KML. En dehors de ça y'a pas énormément de choses.
                      Et les clients sont souvent des clients TMS (tuiles) car c'est quand même simple.
                      Les clients ne sont pas spécifiques à OSM, loin de là. En général ce sont des clients qui lisent les formats OGC (plus ou moins).

                      J'avoue être surpris par ces problèmes de "rendu de carte" alors que la moindre config vendue actuellement est capable de faire tourner un jeu 3D du genre d'OpenArena. À priori ça me paraît capable de faire le rendu d'une carte à partir de données de base :|

                      Le problème n'est pas uniquement en temps de rendu. Déjà il y a quand même un côté idiot à vouloir que tout le monde rende la même donnée, ça va un peu à l'encontre d'une mutualisation de moyen et fait du boulot auprès de tout le monde.
                      Ensuite, je pense que tu sous-estime le temps de dessin d'une (ou plusieurs) tuiles. Si les gens apprécient Google Maps (comme dit dans l'article) c'est parce que ça va vite. Il est illusoire de croire qu'on peut avoir les mêmes performances sans un minimum de prégénération de tuiles.
                      Bon après c'est pas si blanc/noir, lorsqu'on envoi un kml à afficher à Google il l'envoi sur ces serveurs et le tuile côté serveur plutôt que de le rendre côté client. Idem pour les markers.
                      Mais concrètement, côté temps de rendu on aura pas de bonnes performances. Et un moteur de rendu c'est pas si léger que ça non plus.
                      Une tuile vectorielle c'est déjà différent car c'est juste que ce n'est pas une image bitmap qui est envoyée mais une image vectorielle. Une partie du traitement est déjà faite.

                      Pour présenter un peu les autre problématiques au rendu côté client : le placement des étiquettes de lieux, nom de rue, etc. C'est une opération qui est loin d'être négligeable. Lesquelles afficher. Gestion de conflits. Gestion d'importance. Comment faire pour que leur position ne dépende pas de la vue du client. etc.

                  • [^] # Re: Protocole adapté ?

                    Posté par . Évalué à 2.

                    Il existe un renderer qui crache du svg: http://wiki.openstreetmap.org/wiki/Osmarender

                    Il était accessible depuis la page principale d'OSM (dans les layers) mais il a disparu il y a quelques jours…

        • [^] # Re: Protocole adapté ?

          Posté par (page perso) . Évalué à 5.

          J'aimerais pouvoir dire "ok, je seede 50ko/s au maximum de OSM", et que ça s'ajoute au 50ko/s d'autres caches, jusqu'à fournir à chaque client la quantité nécessaire, plutôt que dire "je pose un cache OSM", qui serve à rien pendant certains moments, et à d'autres moments tout mon upload serait bouffé par dix personnes qui trouvent que ça rame.

          C'est une solution qui marche que pour des gros contenus. Là, le client il va perdre plus de temps à faire de tour de toutes les sources pour avoir une pas trop lente qui va lui permettre de télécharger les 500ko de la carte plutôt que de les télécharger depuis une source fixe mais plus lente.

          Comment je fais pour regarder OSM dans mon client IRC, moi ? :|

          Rien ne t'empêche de télécharger les données d'OSM pour fournir un service de rendu qui afficherait ses résultats par un moyen autre qu'HTTP et si d'autres sont intéressés, ils te suivront, mais ce n'est pas le but du projet OSM qui se veut plus une base de données de données géographique qu'autre chose, la carte n'est là que pour se rendre compte des données (d'ailleurs toutes les données dans la bdd ne sont pas affichées sur la carte).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.