Le portail francophone de la géomatique

Depuis son rachat de Macromédia, la technologie SVG n'avait effectivement plus trop d'intérêt pour Adobe.
Dans la série des mauvaises nouvelles, Adobe repousse le développement de la version 9 du player Flash pour Linux à mi 2007.
Pas bien!

Bonjour Patrick,

je crois comme toi qu'il ne faut pas forcément voir derrière la communication d'Adobe un jugement sur l'avenir du SVG.
Si on en reste aux faits :
après fin 2007, le lecteur SVG d'Adobe ne sera plus téléchargeable et ne sera pas garanti fonctionner avec les nouvelles versions d'OS Windows ou Mac, donc les développements SVG qui ne marchent bien qu'avec ce lecteur devront à terme être adaptés pour être compatibles Firefox ou Opéra. Cela ne chagrinera pas ceux qui n'aiment pas Internet Explorer, mais rendra SVG un peu moins crédible encore pour les projets devant toucher tous les publics utilisateurs.

Sur les questions de performances comparées Flash/Mapserver/SVG, je ne partage pas vraiment ton point de vue, mais c'est un autre débat, et nous ne sommes pas impartiaux. Aux utilisateurs de juger.

Cordialement,

Eric Mauvière

Bonjour à tous,

Etant l'auteur du billet de blog pointé ci-dessus, je suis à votre disposition si vous avez d'autres questions.

Bonjour à tous,

De notre côté, nous utilisons les deux solutions de client léger SVG et FLASH pour les produits que nous éditons.

Je suis déjà récemment intervenu sur le forum pour dire qu'effectivement SVG est la solution d'avenir, et ce n'est pas la nouvelle position d'Adobe qui va changer quelque chose. Au délà de Firefox qui intègre déjà SVG en natif, je ne serai pas surpris de voir apparaître courant 2007 une alternative pour IE. Le fort développement de SVG dans les applications mobiles montre également que l'abandon n'est pas pour demain.

Je ne reviendrais pas sur SVG et FLASH, qui à mon avis, répondent à des besoins différents et du coup, ne doivent pas être opposés (sauf à opposer propriétaire et opensource). Pour notre part, nous utilisons Flash pour la diffusion web (on est pas les seuls d'ailleurs) à des fins d'intégration de l'information géographique dans les sites internet. SVG est par contre la bonne réponse pour avoir des fonctions de SIG en ligne, notamment en terme de saisie topologique sur client web léger (ce que j'aimerai bien voir sur Mapserver par exemple).

Nous planchons également sur MapServer, parce qu'il le vaut bien (!) mais sans conviction par rapport à ce qu'apporte SVG. En tout cas, c'est pas avec MapServer qu'on arrivera à faire du SIG en ligne. Par contre, MapServer a d'autres atouts au niveau du serveur; et c'est pourquoi nous l'intégrons.

Enfin, Pierre a raison quand il dit qu'il faut 1 ou 2 mois homme pour intégrer une nouvelle technique d'affichage des données cartographiques; ce qui ne remet pas en cause le moteur bi-modal que Netagis utilise, ni même l'ensemble des outils non cartos (administration, applis métiers...). D'ailleurs, on pourrait voir apparaître d'autres solutions techniques. Ce qui est important pour une société comme nous, c'est de ne pas être lié et enfermé dans une seule technologie. Au travers de nos contrats de maintenance, nous garantissons à nos clients l'évolution de nos solutions en fonction des technologies : cela inclut donc de proposer d'ici fin 2007 des solutions sans le plug-in Adobe. Donc no soucis.

A la vitesse où cela change, il vaut mieux avoir plusieurs cartes en main. Je pense d'ailleurs que 2007 vont nous réserver quelques surprises ... on espère qu'elles ne seront pas toutes d'origine outre atlantique quand même.

Bref, nous croyons plus que jamais dans SVG et dans Flash aussi; pour MapServer, un peu moins à moyen terme.

Cordialement,

Patrick JULIEN

Bonjour à tous,

je voudrais réagir sur les performances comparées de Flash et SVG s'agissant d'afficher des couches cartographiques avec plusieurs milliers d'objets.

Je ne sais pas si je vais gagner des cadeaux (je manque notamment de stylos, que je perds tout le temps), mais cette affirmation me paraît totalement erronée, ou alors relever d'une expérience insuffisante en programmation Flash.

Voici un exemple avec plus de 3 000 objets (USA par county) :
http://www.emc3dev.com/usa_demo/carto.php?lang=en

et un autre jusqu'à 10 000 objets (observatoire des territoires de la Diact) :
http://www.territoires.gouv.fr/indicate … maille=com (déplacer et/ou agrandir le viseur de la carte repère pour tester la génération dynamique)
A titre de test, car je ne crois pas qu'il soit utile d'afficher trop d'objets sur une carte.

Il est facile de comprendre pourquoi une carte (bien construite) en Flash/SWF s’affiche toujours plus rapidement qu’une carte (bien construite) en SVG.
Cela tient à la nature XML/texte du SVG, format qui le pénalise.

Le temps d'affichage d'une carte vectorielle construite à partir d'objets lus dans une base géographique se décompose en :
1) temps d'extraction d'un jeu d'enregistrements dans une table spatiale : neutre vis à vis de Flash ou SVG, c'est du SQL et des index spatiaux
2) temps d'encodage du jeu résultant et de la géométrie associée dans le format :
- SVG est un format texte, SWF un format binaire, l'encodage en texte qui demande des conversions superflues nombres réels => chaînes de caractères est plus long
3) temps de transfert des données vers le poste client
SVG est un format texte XML qui, même compressé est 30 % plus volumineux qu'un format binaire compressé comme swf => temps de transfert 30 % plus long
4) chargement dans la mémoire du lecteur SVG ou Flash du flux de données 
SVG impose un décodage d'un lourd flux texte XML en données numériques codées en 16 ou 32 bits, SWF code déjà ces données comme des nombres en 16 ou 32 bits, ils sont chargés plus rapidement en mémoire ;
5) temps de dessin des objets à l'écran à partir des coordonnées chargées.
Il faudrait mettre côte à côte 2 applis équivalentes. Je soutiens que le lecteur Flash, mis à jour tous les ans, est mieux optimisé en termes de rapidité d'affichage et de gestion de la mémoire que le vieux lecteur SVG d'Adobe. Ce dernier va en plus disparaître dans quelques mois, et l'implémentation SVG dans Firefox est notoirement plus lente et plus limitée.

Cordialement,

Eric Mauvière

Bonjour Eric,

Effectivement, les temps de réponse sont pas mal dans les exemples que tu donnes. Je me pose toutefois une ou deux questions, que je te soumets : est ce que tu généres tes objets à la volée à partir d'une base de données ou as tu déjà des fichiers templates prêts à l'usage ? Si le stockage des objets est réellement dans une base, respectes tu les normes de l'OGC sur la description graphique de l'objet ?
Enfin, par curiosité, serais tu en mesure d'afficher les 36000 communes à la fois ? SVG le permet (et sans simplication des contours de communes); je reconnais quand même qu'il faut attendre un peu.

Dans l'attente de tes précisions,
Cordialement,

Patrick JULIEN

Bonjour,

concernant Mapserver, vous avez raison. Cela ne fait pas de saisie topologique.
Par contre un framework tel que CartoWeb.org offre des fonctionalites SIG avancees dans le module d'edition: http://www.cartoweb.org/demos/demoEdit.php. On peut creer et editer des formes geometriques (surfaces, lignes et points)
avec leurs attributs. Cela fonctionne avec une image raster en arriere plan et une interface dhtml d'edition par dessus.

La fonction d'accroche est presente: Allow vertex snapping (symbole: un aimant)!

A noter quelques points d'ergonomie encore a ameliorer dans la demo:

* apres creation d'un polygone, il faut valider avec le bouton "validate" et pas avec la touche enter.
* pour editer un polygon exitant, il faut d'abord le selectionner avec la fleche de selection (edit_sel), puis passer sur la fleche de deplacement (edit_mov).

Meilleures salutations,

Bonjour à tous,
Je voudrais savoir est-ce qu'il existe une solution gratuite / open source pour créer / lire des fichiers au format SWF ?

Merci pour votre réponse.

Cdlt.

merci beaucoup pour le lien, il est fort complet et m'apprend pas mal de choses.

pour info, la sortie d'une version Linux du lecteur Flash 9 est annoncée pour début 2007
http://weblogs.macromedia.com/emmy/arch … nia_th.cfm
une béta ne devrait pas tarder.

Voir aussi le blog du responsable de la version Linux du lecteur chez Adobe, qui explique pourquoi ce n'est pas de la tarte d'aboutir à une version correcte, vu la variété des distributions Linux existantes :
http://blogs.adobe.com/penguin.swf/

S'agissant du fait qu'il n'y ait qu'un lecteur Flash, c'est en effet une bénédiction ! Pourvu qu'il n'y en ait pas d'autres qui voient le jour, avec des compatibilités ou des stabilités variables, obligeant le développeur à vivre le cauchemar quotidien des programmeurs Javascript et/ou Ajax qui doivent tester le maximum de combinaisons navigateurs/OS...

Eric Mauvière

bonjour,

> Par contre j'aurais besoin d'un peu de lumière sur un point :
> le SVG et SWF est une technologie cliente pour l'affichage de données sous forme vectorielle.


oui, tout à fait. SVG est un standard ouvert (XML), l'autre est propriétaire mais documenté, un peu comme le format shape d'ESRI, donc tjs sous condition de modification sans préavis.

pour SVG on peut rajouter qu'il peut aussi servir de format intermédiaire côté serveur pour être transformé en PDF ou raster à la sortie. en gros ca fonctionne avec ces choses là:
http://xmlgraphics.apache.org/batik/, ansi que ca peut-être:
http://xmlgraphics.apache.org/fop/


> Mais comment utiliser ces supports dans le cadre de la cartographie ? Faut-il les compléter d'un serveur cartographique pour lire/écrire des données spatiales ? Y'a t'il des liens pour m'expliquer comment faire de la cartographie sur le web via SVG / SWG ?

il y a moyen d'encapsuler une solution uniquement "client", des exemples sont là http://www.carto.net/papers/svg/samples/#jscr et là
http://www.carto.net/papers/svg/links/

pour l'intégration de serveur carto voyez ici deux tutoriaux:
http://www.carto.net/papers/svg/ogc_wms_integration/ et
http://www.carto.net/papers/svg/postgis … tprequest/ . il ne
faut pas forcément un vrai serveur carto (allez definir ca, en passant!) une BD avec cartouch spatiale "sufftit" (et même, ca peut marcher sans si la projection est simple).

tous les liens données sont orientés SVG, pour les exemples SWF Eric Mauvière va surement dire qqch ;-)

a+
andré

--
___________________________________________________________________
andre m. winter,
  cartography for internet and multimedia applications
  schiessstand 4/1, a6091 goetzens, tyrol, austria
  tel.: ++43.5234.32732
  email: ml.winter@texte-a-enlever.carto.net

        new svg book with actual scripting samples out now!
             check    http://svg.carto.net/

Question posée : comment faire de la cartographie sur le web via SWF (Flash) ?

C'est pas forcément simple...
Et pourtant ça devrait l'être.
On a au départ des couches cartographiques au format Mapinfo, shape, etc, c'est-à-dire des fichiers avec dedans des listes d'objets avec leurs constituants (lignes, polygones, trous, îles...) , les coordonnées des sommets les décrivant et la projection utilisée.
A l'arrivée, on veut au format Flash en gros la même chose, des objets, des coordonnées, sauf qu'évidemment l'encodage (l'ordre dans lequel ces informations sont écrites dans le fichier) n'est pas le même.
Vous pouvez mettre entre les deux une base de données, pour pouvoir générer des cartes dynamiquement, mais tout se ramène toujours à des opérations de décodage-réencodage.

A partir de là, 3 routes sont possibles :
1) étudier et comprendre la structure des formats cartographiques de base (le format shape, le format wkb/wkt pour les serveurs spatiaux), faire pareil avec le swf, et écrire à la main les programmes de conversion. C'est un gros investissement, mais c'est ce qui permet d'avoir des interfaces rapides et réactives
2) s'appuyer sur des bibliothèques existantes tout en gardant un peu d'autonomie. Par exemple vous montez une base Postgis à partir de fichiers shape (Postgis incorpore un chargeur automatique), vous utilisez les fonctions SQL spatiales de Postgis pour obtenir des informations géométriques sur les objets à transférer (type, sous-objets, coordonnées, etc.), vous envoyez cette information à votre interface sous forme d'un flux texte pour alimenter les fonctions de dessin de Flash, ou vous vous appuyez sur la bibliothèque PHP-Ming pour générer automatiquement un flux swf
3) s'en remettre à un paquetage complet comme Mapserver et ses options de sortie au format swf.

Cordialement,

Eric Mauvière

Pas nécessairement, Mapserver peut très bien envoyer une MAP au sens HTML du terme., c'est à dire des zones cliquables qui permettront une interaction (affichage du contenu dans une balise DIV grâce à du javascript).

Cependant, je ne sais pas comment ceci peut être utilisé avec du SWF (et si c'est possible !). Pour une image PNG, GIF, ... cela est possible.

Y.

Mapserver permet de générer directement des cartes en swf, en définissant "l'output mode" swf dans le mapfile.
On peut également lui faire générer des images cliquables (image map), ou du svg.

On peut même générer du dxf avec mapserver ! (ça, c'est moins connu, mais ça marche).
En fait, Mapserver permet de générer à peu près n'importe quel type de format vectoriel.

Dans tous ces cas, pour les "line", le mieux est de définir des zones tampons de quelques pixels autour des lignes, parce que de toute façon, on ne peut pas avoir une page web ergonomique s'il faut cliquer sur une ligne au pixel près.

On peut utiliser PostGis pour définir ces zones tampons (buffer).

Cordialement,

--
Daniel FAIVRE
expert en géomatique
webmaster@texte-a-enlever.geomaticien.com

Je ne suis pas d'accord à 100% avec ce point de vue. Si l'on examine les possibilités par fonctionnalité, voici pourquoi:

1) Dans une application web, le "zoom côté client" me semble relever de la fausse bonne idée, car soit l'on doit pour pouvoir faire ce zoom avoir préchargé plus de données qu'utile à l'échelle précédente, soit on doit rappeller le serveur pour augmenter le niveau de détails. Dans les deux cas, il faut bien que des données transitent d'un serveur vers un client !

2) interpréter: là, oui, c'est possible de traiter côté client l'information déjà téléchargée, mais seulement celle-là. Ces traitements peuvent d'ailleurs porter sur des rasters.

3) interroger: même objection que pour le zoom: soit on envoie au client des tas de données inutiles, soit on rappelle le serveur.

Ce qu'il faut avoir à l'esprit, c'est que les données géographiques (et attributaires) sont de toutes façon volumineuses: on ne va pas toutes les envoyer par Internet avant de pouvoir afficher une carte. Il faut donc gérer le plus finement possible le type et le volume d'informations échangées entre client et serveur: c'est là que résident les enjeux, aussi bien pour des données rasters de toute façon nécessaires (images satellite, photos ...) que pour le vecteur.

Là où je suis d'accord à 100% avec André Winter, c'est lorsqu'il dit que la production de swf par Mapserver, en l'état actuel, n'apporte rien à l'ergonomie des applis web.

En effet, les progrès ne viennent pas d'un passage du raster au vecteur, mais plutôt du passage de technologies synchrones à des technologies asynchrones au niveau des communications client-serveur (et ce, pour des images ou des vecteurs; en précisant que pour le vectoriel celà reste à ce jour au stade des prémices, voire du concept ...).

Pour en revenir au cas particulier de Mapserver, on peut donc, à ce jour, générer côté serveur des tiles à partir de rasters, des tiles à partir de vecteurs, et des données vectorielles selon différents formats, qui peuvent elles-même être "tilées" et séparées par couches. C'est toutefois assez peu souple d'emploi, et ça peut encore largement s'optimiser. Mais c'est donc tout de même côté client qu'il y a l'essentiel des progrès à faire, puisque Mapserver peut d'ores et déjà en faire bien plus que ce qui lui est
généralement demandé.

--
Daniel FAIVRE
expert en géomatique
webmaster@texte-a-enlever.geomaticien.com

Je suis entièrement d'accord avec André.

Tout de même, avec Mapserver, tous ces pixels amorphes expédiés et réexpédiés sans relâche : ils encombrent la bande passante et saccadent la navigation, ce n'est pas bien malin !
- vous avez une analyse en classes, vous voulez changer une des bornes et hop, une nouvelle fournée de pixels à attendre, toute la carte à recharger ;
- vous voulez imprimer en qualité correcte ? Oubliez la pauvre image pixellisée dans votre navigateur, attendez que le serveur veuille bien, si c'est prévu, vous fabriquer et vous expédier un beau pdf tout propre ;
- vous voulez sélectionner quelques objets sur la carte, avoir une valeur de synthèse, faire un tri, c'est pareil tout dépend du bon vouloir du serveur, faut pas être pressé ;
- vous avez un département à l'écran, vous voulez zoomer sur une intercommunalité puis revenir à la vue d'ensemble : vain désir de fluidité ! Si vous êtes si curieux, prenez donc une loupe !
- vous voulez autre chose qu'un timbre-poste à l'écran : c'est possible, c'est juste 2 fois plus long...

Bref, sauf si bien sûr on part de photos ou de scans, tout est plus lourd et plus lent avec la carto bitmap

Eric Mauvière