Journal Et un site de plus sans flash : mappy

Posté par  .
Étiquettes : aucune
30
23
juil.
2009
Bonjour,

Il m'arrive d'utiliser les sites de cartographie pour obtenir un itinéraire - c'est ce pour quoi ils sont faits.
Souvent, c'est la croix et la bannière en terme de lourdeur avec mon G4 dû au flash inclus dans les pages. Surtout le site de Mappy.

Bonne nouvelle (au moins pour moi ;) ), Mappy n'utilise plus de flash, tout se fait en CSS et SVG dynamique (de ce que j'ai vu sur le code source de la page, je ne suis pas programmeur).

C'est une supère avancée car au moins je peux aller sur le site et obtenir l'information que je souhaite sans que mon processeur côtoie les 100% d'utilisation pendant toute la procédure.

Chez vous aussi ça marche ?

  • # anéfé

    Posté par  . Évalué à 7.

    anéfé, c'est une bonne nouvelle.

    LA concurence google maps est impitoyable :-)

    sinon, le gros carré vert est pas joli, et ca force à scroller pour voir le plan.

    • [^] # Re: anéfé

      Posté par  (site web personnel) . Évalué à 2.

      Vraiment tres tres bien pensé et bien codé en effet.

      Juste dommage (si on cherche vraiment loin...) que les fonctionnalitees n aient pas d'alternatives non-javascript.

      Certes les menu ont un href correct, mais cela s'arrete là...

      --
      tfe, qui cherche la petite bete

      • [^] # Re: anéfé

        Posté par  . Évalué à 1.

        Je vais faire le faux-naïf (mais peut-être en fait je le suis).

        Quelle est l'intérêt (à l'époque des netbook pas cher) d'avoir des fonctionnalités non-javascript pour un site de cartographie (donc visuel) ?

        • [^] # Re: anéfé

          Posté par  (site web personnel) . Évalué à 0.

          Très simple:
          au niveau de la page d'accueil, tu as des "news", du genre

          - Berlin, la porte de ....
          - Londres, ...

          Ces news (donc du texte), sont disponibles via javascript, mais non via html pure.
          De même pour les autres sections, en general.

          • [^] # Re: anéfé

            Posté par  . Évalué à 1.

            Tu ne réponds pas à ma question.

            • [^] # Re: anéfé

              Posté par  . Évalué à 2.

              Sans doute une question de légèreté de la page.

              « 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: anéfé

                Posté par  . Évalué à 2.

                C'est bien plus lourd à l'utilisation de devoir recharger toute la page à chaque click.

        • [^] # Re: anéfé

          Posté par  . Évalué à 0.

          Quelle fonctionnalité d'un site de cartographie serait impossible à avoir sans javascript ?

          • [^] # Re: anéfé

            Posté par  (site web personnel) . Évalué à 10.

            Le déplacement par glisser/déposer de la carte ? faire des tracés/annotations sur la carte ? Le zoom fluide ? en gros plein de trucs impossible en juste html + css.

  • # Oui

    Posté par  . Évalué à 6.

    Testé avec Konqueror, Firefox et opera, tout semble fonctionner au poil. C'est rapide et réactif. En revanche entre X et le navigateur, quand je bouge la carte ça me prend quand même un processeur.

    • [^] # Re: Oui

      Posté par  . Évalué à 7.

      En tout cas, je vois une trèèès grande différence d'utilisabilité dans mon cas.

      Je peux garder la musique et pidgin pendant que je regarde un itinéraire et tout reste très bien. ;)

    • [^] # Re: Oui

      Posté par  . Évalué à 3.

      C'est toujours du flash sur mappy.be mais ça marche sur mappy.com

      « 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: Oui

      Posté par  . Évalué à 3.

      Ca passe sous IE ?

      • [^] # Re: Oui

        Posté par  . Évalué à 3.

        Ie ne sachant pas afficher le SVG cela m'étonnerais...

        • [^] # Re: Oui

          Posté par  (site web personnel) . Évalué à 5.

          Ca marche impec sous IE.
          Ignorer le navigateur qui a le plus de part de marché, ca aurait été balo pour un site commercial tout de même.
          Y'a pas une once de SVG sur la page principale de ce site.

          • [^] # Re: Oui

            Posté par  . Évalué à 1.

            Ok je disais ça d'après ce qui est dit dans la news, sur la techno employée ...

            • [^] # Re: Oui

              Posté par  . Évalué à 2.

              Et c'est sûrement entièrement de ma faute, désolé. Si quelqu'un sait comment ils font pour avoir une image dynamique, je suis très intéressé, par pure curiosité !

              • [^] # Re: Oui

                Posté par  (site web personnel) . Évalué à 1.

                En tout cas, tout ce que je peux dire c'est que les images sont en PNG.
                Dans Firefox, avec l'onglet media qui se trouve dans 'information sur la page', on trouve la carte visualisee en pleins de petites images PNG.

              • [^] # Re: Oui

                Posté par  (site web personnel) . Évalué à 3.

                Les images sont je suppose statiques côté serveur. Après y'a du code javascript dans le navigateur qui change dynamiquement les images qui doivent être affichées en fonction de la direction et du zoom que l'utilisateur demande.

        • [^] # Re: Oui

          Posté par  (site web personnel) . Évalué à 2.

          IE ne sait pas afficher nativement le SVG mais il a existé des plugins pour l'ajouter (pour Adobe, c'est mort depuis janvier, mais il en a existé un second dont j'ai oublié le nom).

  • # Openstreetmap

    Posté par  (site web personnel) . Évalué à -1.

    Tu aurais pu faire un journal sur une solution vraiment libre tel qu'Openstreetmap. Il existe plusieurs solutions online de routage qui sont détaillées sur http://wiki.openstreetmap.org/wiki/Routing/OnlineRouters

    Par exemple http://maps.cloudmade.com/ permet de facilement calculer ton itinéraire, un clic droit pour mettre un point d'arrivée et de départ et c'est parti. La carte n'est pas vraiment finie pour la France mais ça avance vraiment vite !

    • [^] # Re: Openstreetmap

      Posté par  (site web personnel) . Évalué à 10.

      Bah tu peux le faire ce journal. Moi je trouve ça bien que les solutions non-libre fonctionnent avec le libre, ça facilite les migrations.

      Un site qui nécessite flash en moins, et qui utilise des standards ouverts à la place, c'est un web plus propre.

      • [^] # WMSC

        Posté par  . Évalué à 1.

        Standard ouvert à moitié car quand on regarde la méthode utilisée pour requêter les images, cela semble être une méthode maison alors qu'il existe des standards pour ça (WMSC,WCS). Surtout que leur protection semble pourvoir être compatible avec des clients du genre Openlayers.

        Ceci dit, je trouve que l'application est plutôt fluide, le protocole semble propre,bien qu'utiliser les entêtes http pour les méta data des images, c'est un peu bizarre. De plus, localiser les images par un triplé {zoom, numéro vertical, numéro horizontal} fait perdre la géo-localisation facile, mais ca doit être plus simple au niveau du cache des images car google utilise le même principe...

        Pour conclure à part quelques petits défauts, je trouve le nouveau mécanisme pas mal :)

    • [^] # Re: Openstreetmap

      Posté par  . Évalué à 9.

      Même si Openstreetmap avance à grands pas, comme tu le dis toi-même, la cartographie de la France n'est pas encore achevée, et donc partiellement inexploitable pour le moment.

      Cependant, la communauté Openstreetmap française est très active et volontariste, il suffit de suivre la mailing list quelques temps pour s'en rendre compte. Les outils spécifiques à ce projet ne sont pas triviaux, et pas mal d'explications et d'indications sont dispensées sur la ML. C'est vraiment un projet qui avance à grands pas.

      Le jour où Openstreetmap atteindra le niveau de qualité des cartographies payantes (Navteq, par exemple), je pense que l'on assistera à une réelle évolution des applications de géolocalisation, de calcul d'itinéraire ou de couplage "recherche d'informations / localisation géographique". D'autant plus que les cartographies payantes ne sont pas aussi "précises" que cela, et comportent bon nombre d'erreurs.

      En attendant, pour se rendre de Meaux à Quimper, hé ben la plupart des gens fera appel à Viamichelin ou Mappy avant d'utiliser un outil libre pour le moment.

      Mon commentaire ne se veut pas pessimiste, mais réaliste. Dans un des projets sur lequel on travaille, on a dû écarter Openstreetmap (pour le moment, en tout cas) à cause de son caractère "incomplet". Mais on a bon espoir de pouvoir l'intégrer à notre projet un jour.

  • # Pas de SVG

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Il n'y a plus de flash.

    Mais il n'y a absolument pas une once de balise SVG. Ou alors va falloir me dire où tu en as vu.

    En explorant l'arbre DOM avec Firebug, je n'ai vu que des images. La carte est découpée en plusieurs images (qu'on appelle des tuiles dans le jargon du domaine du zoom). Bref, une technique similaire à Google, open street map et cie. Que du JS (avec jQuery), et des balises html img. Pas de SVG.

    • [^] # Tuiles…

      Posté par  (site web personnel) . Évalué à 1.

      Tuiles : c'est peut-être le mot employé, mais ça ressemble à une mauvaise traduction de l'anglais “tile”. « Pavés » serait plus adapté, vu qu'on pave le plan avec des morceaux d'image.

      • [^] # Re: Tuiles…

        Posté par  . Évalué à 8.

        Non tuiles et pis c'est tout : des morceaux d'images qui se raccrochent les unes aux autres pour former un tout cohérent = tuilage, ça a du sens, c'est en français.

      • [^] # Re: Tuiles…

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        non, pas comme des pavés. Parce que des pavés, ça se chevauche pas. Des tuiles, ça se chevauche. Et justement, dans le domaine du zoom, en général, on fait légèrement chevauché les images, pour compenser les arrondis dans les calculs de zoom/taille. bon, peut être pas sur google map ou mappy, vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails). Mais quand on a un système de zoom sans "échelons", on est obligé de les faire chevaucher sinon on peut avoir des images disjointes à certains niveau de zoom, et ça c'est moche :-).

        Bref, des tuiles quoi..

        • [^] # Re: Tuiles…

          Posté par  (site web personnel) . Évalué à 2.

          > Des tuiles, ça se chevauche.

          heu non, en carto (mon boulot c'est justement de coder des applis cartographiques en web) les tuiles ne se chevauchent jamais.

          > vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails)

          Lorsqu'on utilise des tuiles (du "tile cache" en fait) les niveaux de zoom sont toujours prédéfinis et l'intégralités des tuiles (toute portion visible à tout niveau de zoom autorisé) sont précalculé.
          Ce qui peut prendre ... pfiou trop de temps entre autre, et aussi qu'il est beaucoup plus rapide d'accéder à des fichiers (qui peuvent être avec plusieurs niveaux de cache que ce soit sur les durs ou sur de la ram) que de lire les données et de les calculer.

          enfin c'est comme ça pour la carto en tout cas

          un peu de lecture ;)
          http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification

          • [^] # Re: Tuiles…

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            note : je bosse une boite qui fait de la techno sur le zoom de document et d'images.

            les niveaux de zooms sont prédéfinies ok, les tuiles sont bien entendu précalculés. Mais quand tu veux faire du zoom linéaire et non incrémentale, (donc, il faut étirer/rapetisser les tuiles au finale, quand le zoom est entre deux niveau de zoom), comme c'est le cas pour notre outils, bah tu as forcément à un moment ou à un autre des tuiles disjointes à l'affichage, à cause des arrondis. Il faut donc toujours qu'une tuile puisse déborder sur une autre, ne serait-ce que d'un pixel ou deux.

            Quand tu as un affichage de zoom à des niveaux prédéfinis (on ne peux pas zoomer entre deux niveaux de zoom), oui, tu n'a pas besoin que les tuiles se chevauchent, puisque tu affiches alors les tuiles telles quel (même si tu fais une jolie transition quand tu passes d'un niveau de zoom à un autre, en étirant/rapetissant les tuiles temporairement. si il n'y a pas de jointure parfaite durant la transition, c'est pas grave, ça ne se verra pas.

            • [^] # Re: Tuiles…

              Posté par  (site web personnel) . Évalué à 2.

              Comment tu fais pour obtenir des carré côté à côté ayant des trous entre-eux ? car les images qui composent le tiles sont carrées... je vois pas comment en zoomant un trou peut apparaître (même si c'est pas pré-calculé).

              • [^] # Re: Tuiles…

                Posté par  . Évalué à 3.

                À cause du zoom continu et du nombre de tuile représentant la même surface (en fonction du niveau de zoom) discret. Si tu zoom en continu, tu vas avoir des arrondi en agrandissant la tuile et ces arrondi peuvent provoquer des espaces de quelques pixels entre tes pavés.

                « 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: Tuiles…

                  Posté par  (site web personnel) . Évalué à 2.

                  Je pige toujours pas, à moins d'une méthode de zoom tordue, tous tes carrés ont le même zoom, donc peut pas y avoir de trou.

                  Ensuite pour le zoom fluide, tu zoom en Z1 et Z2 et seulement quand tu es en Z2 tu prends les tiles Z2, tu vas pas faire de l'interpollation entre Z1 et Z2 (sauf si il y a bcp de "zoom" entre les 2). Les carré étant composé de pixel et ayant *tous* la même taille au départ, je vois pas comment l'arrondi peut-être différent entre eux... tu peux pas zoomer de moins d'un pixel par côté donc je vois pas comment des trous peuvent apparaître à moins de vouloir zoomer par des pas de pixels non-entier (inutile pour du zoom fluide).

                  • [^] # Re: Tuiles…

                    Posté par  . Évalué à 3.

                    D'abord, on ne zoom pas de Z1 à Z2 mais de Z1 à Z1.5 ou Z3.141592. Les pixels étant des nombres discrets il faut arrondir la taille des tuiles pour les afficher. Et lors de cet arrondi, il se peut qu'il y a ait un pixel ou deux entre les pavés, il faut donc des tuiles qui se recouvrent pour éviter ce problème.

                    « 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: Tuiles…

                    Posté par  (site web personnel) . Évalué à 2.

                    justement, le mosieur te parles de zoom entre deux niveaux précalculés quand le zoom est entre deux niveau de zoom

                    genre tu as des tuiles au 1/50000 des tuiles au 1/100000 et tu veux afficher quelque chose au 1/75000

                    Pour des documents, des images, etc ça se comprend.
                    Pour de la carto ça ne se fait pas (genre même pour les orthophotos chez google le tuilage ne se recouvre pas)
                    En gros en carto on a plutôt deux cas, soit des serveurs de tuilage et on utilise que des zooms précalculés, soit on utilise des serveurs qui recalculent les données systématiquement (ou non avec du cache) pour tout niveau de zoom toute emprise demandée.

                    Donc pour en revenir à ce que LaurentJ disait, forcément si tu as une image à une définition donnée, que tu la zoom (l'image même) tu as finalement moins d'information et une moins bonne précision que le zoom où tu te place le nécessiterait, d'où l'apparition de problèmes, de trous, d'incohérence, etc

                    (sais pas si c'est compréhensible, au moins je me comprend... ;))

                  • [^] # Re: Tuiles…

                    Posté par  . Évalué à 3.

                    tu vas pas faire de l'interpollation

                    Ben si, justement ...

    • [^] # Re: Pas de SVG

      Posté par  . Évalué à 2.

      Ok, merci ;)

  • # Google Maps

    Posté par  . Évalué à 1.

    google maps n'utilise pas flash non plus, à ce que je sache

    Je ne suis pas plus programeur, mais vu qu'il marche avec chromium qui ne gère pas les plug-in et donc pas flash... J'en conclut que ça n'utilise pas flash. A noter que sur chromium, j'ai l'impression que le site est beaucoup plus rapide qu'avec FireFox.

    • [^] # Re: Google Maps

      Posté par  . Évalué à 0.

      google maps, c'est du javascript.

      Ce qui explique pkoi ca te parait plus rapide que sous ff, vu la qualite de la vm javascript chrome face a celle de FF (quoique la version 3 de ff s'est amelioree parait il).

      Apres, un truc qui ralentit beaucoup gmaps, c'est la vue satellite, faut tout telecharger et la tu ramasses, c'est potentiellement ce qui fait la difference de perf entre ton ff et ton chrome.

      my 2 cents.

  • # Photos aériennes

    Posté par  (site web personnel) . Évalué à 2.

    C'est mieux qu'avant. Cependant au niveau des photos aériennes, c'est pas de super qualité et surtout pas tout jeune... En tout cas vers chez moi ! Les photos ont au moins 4 ans, voire plus.

    • [^] # Re: Photos aériennes

      Posté par  . Évalué à 9.

      Et je suis certain que si on zoom suffisamment, on peut voit des photos de la seconde guerre mondiale. :)

      (Comment ça, ça n'est pas comme les photos spatiale ? Plus on regarde loin, plus on regarde dans la passé ?)

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Concurrent de deezer sans flash

      Posté par  . Évalué à 1.

      Je plussoie, c'est une bonne découverte. Merci pour le lien!

    • [^] # Re: Concurrent de deezer sans flash

      Posté par  . Évalué à 2.

      Ça marche pas partout, notamment en Belgique.

      « 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: Concurrent de deezer sans flash

      Posté par  . Évalué à 3.

      Et ça ne fonctionne pas à l'étranger /o\

    • [^] # Re: Concurrent de deezer sans flash

      Posté par  . Évalué à 1.

      Si il n'y a pas de flash, comment marche le streaming audio ? Via la balise vidéo de Firefox ?

    • [^] # Re: Concurrent de deezer sans flash

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Ben si, c'est du flash. les boutons sont en HTML, mais le player en lui même est bien en flash.. (ils pourraient utiliser la balise quand même...)

      Et sinon, franchement, je ne suis pas fier que ce soit français. Vu la gueule du HTML (via firebug), à la place des développeurs, je me cacherai. Parce que par exemple, imbriquer neuf DIV pour enfin afficher le contenu principal de la page, avec en plus du style inline et des classes (les mêmes en plus) dans tout les sens, ça craint du boudin... Je plains ceux qui doivent le maintenir (quoique, si c'est ceux qui l'ont développé...)

      Bref, leurs pages pourraient être bien plus light et compréhensibles... Deezer, au moins, le code est un peu mieux organisé.


      (désolé, c'est mon coté critique dev web qui ressort)

Suivre le flux des commentaires

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