Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Suite à un problème technique intervenu entre le 22 et le 23 mars, nous avons du procéder dans la soirée du 25 mars, à la restauration de la base de données du 24 mars (matinée).

En clair, nous avons perdu vos contributions et inscriptions du dimanche 24 et du lundi 25 mars.
Nous vous prions de nous excuser.

#1 Thu 07 September 2006 08:01

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

SVG : Adobe se retire du jeu

Bonjour à tous,

Je suis tombé sur cette info sur un forum :
Principal initiateur du format SVG, Adobe a informé les développeurs ne plus vouloir faire évoluer son lecteur SVG :

http://tech.groups.yahoo.com/group/svg- … sage/56704

Concrètement, le lecteur SVG d'Adobe, celui qui a été le plus utilisé, n'est pas garanti fonctionner avec les prochaines versions de Windows.
Il ne sera plus en téléchargement après le 1er janvier 2008.

cf. http://www.adobe.com/svg/pdfs/ASV_EOL_FAQ.pdf

Eric Mauvière


Éric Mauvière - icem7

Hors ligne

 

#2 Thu 07 September 2006 09:01

Beaufreton
Participant occasionnel
Date d'inscription: 24 Jul 2006
Messages: 26

Re: SVG : Adobe se retire du jeu

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!

Hors ligne

 

#3 Fri 08 September 2006 17:03

NETAGIS44
Participant occasionnel
Lieu: LA CHAPELLE SUR ERDRE
Date d'inscription: 6 Sep 2005
Messages: 39
Site web

Re: SVG : Adobe se retire du jeu

Bonjour,

Je ne suis pas un expert de la langue anglaise, mais il ne me semble pas que le message d'Adobe auquel il est fait référence dans votre mail permette une conclusion hative sur l'avenir du SVG.
Au contraire, il semble bien que ce message indique qu'Adobe ne fera plus évoluer son plug-in car celui-ci est de plus en plus répandu. J'y vois donc plutôt une bonne nouvelle...

Ce que je peux également vous dire, c'est qu'une société comme la nôtre qui appuie une  partie de ses solutions sur SVG, ne se limite pas à une seule technologie. Flash et MapServer sont aussi utilisés; tout dépend de ce que l'on veut faire dans une application de web mapping.

Chaque technologie a ses atouts et bien sûr défaut :
- Flash s'adapte bien aux applications simples, n'ayant pas besoin de supporter une volume de données vectorielles important,
- MapServer supporte des volumes de données importants, la qualité de l'image n'est pas forcément son point fort,
- SVG supporte également des volumes de données importants, avec une très bonne qualité d'affichage et il permet surtout de créer des fonctions de saisies/mises à jour de données cartographiques en ligne très avancée. Idéal pour des applications métiers comme la gestion en ligne des plans de réseaux, de la voirie... Son défaut : les plug-in, les compatibilités tous navigateurs !
Bien sûr, tout çà n'est pas exhaustif et évolue en permanence.

Par contre, je me permets juste de déplorer les propos un peu rapides sur SVG (et aussi FLASH) que je vois aujourd'hui sur le forum.

Bonne fin de journée et bon WE
Cordialement,

P. JULIEN

Hors ligne

 

#4 Fri 08 September 2006 17:28

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

Re: SVG : Adobe se retire du jeu

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


Éric Mauvière - icem7

Hors ligne

 

#5 Sat 30 September 2006 17:59

Alain CHRISTIAN
Juste Inscrit !
Date d'inscription: 30 Sep 2006
Messages: 7

Re: SVG : Adobe se retire du jeu

Bonjour,

Pour compléter le sujet, j'ai trouvé cet article :

http://www.strasslab.net/blog/index.php?Weboscope

Alain

Hors ligne

 

#6 Mon 02 October 2006 14:52

strass
Juste Inscrit !
Date d'inscription: 2 Oct 2006
Messages: 2
Site web

Re: SVG : Adobe se retire du jeu

Bonjour à tous,

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

Hors ligne

 

#7 Mon 02 October 2006 18:52

Pierre Menu
Invité

Re: SVG : Adobe se retire du jeu

Bonjour,

Editeur du serveur cartographique DynMap fonctionnant en mode full raster et/ou SVG, je souhaitais réagir sur l'annonce faite par Adobe et la reprise de cette info par certains flashistes réputés ! (Amitiés à toi Eric )

Adobe déclare ne plus faire évoluer son plugin. Ne perdons pas de vue qu'il n'a de toute façon pas évolué depuis 2003
et que cela correspond tout a fait  a ce que nous attendons d'une norme (qu'elle n'évolue pas trop!)

Le navigateur Firefox implémente maintenant SVG de manière correcte, getURL étant remplacée par Ajax mais permettant aussi la mise a jour dynamique...démontrant bien que  SVG est une norme du W3C et n'appartient pas à Adobe.

Nous faisons régulièrement des tests de performance entre Flash et SVG, en utilisant différentes techniques et , je suis désolé, mais SVG demeure la seule solution vectorielle utilisable en SIG dès que l'on commence a traiter des jeux de données conséquents.

A titre d'exemple, afficher à la volée 2000 parcelles sélectionnées géographiquement sur une base de plus d' un million de parcelles (Cadastre départemental) est impossible en flash.  La ou SVG affiche la carte en environ 3 secondes, Flash nécessite 25 secondes (en utilisant des movie-clip) ce qui est indéfendable coté utilisateur.


Je recherche d'ailleurs un responsable SIG utilisant un serveur Flash capable d'afficher des cartes contenant plus de 5000 objets "à la volée" (c'est à dire des objets sélectionnés parmis un nombre beaucoup plus important , en fonction de l'échelle et de la localisation géographique)... Plein de goodies SIMALIS à gagner !! Stylos et organizers


Bien qu'implémentant aussi un mode de rendu Full Raster utilisant actuellement la technologie Mapserver (et peut etre demain mapguide ?) je reste convaincu que seul le vectoriel sur le poste client peut permettre de faire réellement du WEB SIG, c'est à dire "Remplacer le logiciel SIG dans 80% des utilisations les plus courantes" et ramener le logiciel SIG uniquement sur le poste de spécialistes (Toutes marques confondues)

Dans tous les cas, n'oublions pas que le changement de technologie vectorielle ne nécessite pas la réécriture de toute l'application et que, dans le cas de DynMap, l'ajout d'un nouveau moteur vectoriel est estimé entre  1 et 2 mois / homme environ de développement, ce qui n'est pas énorme pour un produit qui frise le million de ligne de code et totalise environ 6 années / homme de développement.

En vous remerciant

Cordialement

Pierre MENU

 

#8 Mon 02 October 2006 21:11

NETAGIS44
Participant occasionnel
Lieu: LA CHAPELLE SUR ERDRE
Date d'inscription: 6 Sep 2005
Messages: 39
Site web

Re: SVG : Adobe se retire du jeu

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

Hors ligne

 

#9 Tue 03 October 2006 08:58

Yves
Membre du bureau
Lieu: Aix-les-Bains
Date d'inscription: 22 Mar 2006
Messages: 9853
Site web

Re: SVG : Adobe se retire du jeu

NETAGIS44 a écrit:

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.


Bonjour,

Pouvez-vous préciser ce que vous pensez par "En tout cas, c'est pas avec MapServer qu'on arrivera à faire du SIG en ligne." ? Il existe des outils qui le permettent, certe un peu jeune. Vous parlez plutôt de SIG en ligne avec du SVG ?

Merci pour votre réponse.

Y.


Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !!  - GeoRezo vous aide ? Aidez GeoRezo !

Hors ligne

 

#10 Tue 03 October 2006 11:30

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

Re: SVG : Adobe se retire du jeu

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.

Pierre Menu a écrit :
Je recherche d'ailleurs un responsable SIG utilisant un serveur Flash
capable d'afficher des cartes contenant plus de 5000 objets "à la volée"
(c'est à dire des objets sélectionnés parmis un nombre beaucoup plus
important , en fonction de l'échelle et de la localisation
géographique)... Plein de goodies SIMALIS à gagner !! Stylos et organizers


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


Éric Mauvière - icem7

Hors ligne

 

#11 Tue 03 October 2006 14:42

NETAGIS44
Participant occasionnel
Lieu: LA CHAPELLE SUR ERDRE
Date d'inscription: 6 Sep 2005
Messages: 39
Site web

Re: SVG : Adobe se retire du jeu

yjacolin a écrit:

Bonjour,

Pouvez-vous préciser ce que vous pensez par "En tout cas, c'est pas avec MapServer qu'on arrivera à faire du SIG en ligne." ? Il existe des outils qui le permettent, certe un peu jeune. Vous parlez plutôt de SIG en ligne avec du SVG ?

Merci pour votre réponse.

Y.


Bonjour,

C'est vrai que SIG en ligne veut dire beaucoup de choses en terme de fonctionnalités attendues. Je parlais dans mon message davantage des fonctionnalités permettant la mise à jour en ligne de données graphiques, et notamment la possibilité d'utiliser des fonctions d'accroches ou des fonctions de saisies topologiques. A ma connaissance, MapServer ne le permet pas aujourd'hui alors que l'utilisation du SVG permet d'aller très loin dans ce type de fonctionnalités. Par contre, je suis preneur d'infos si vous avez des exemples pour me montrer que c'est possible si je me trompe.

En espérant vous avoir apporté la précision attendue,

Cordialement,

Patrick JULIEN

Hors ligne

 

#12 Tue 03 October 2006 15:01

NETAGIS44
Participant occasionnel
Lieu: LA CHAPELLE SUR ERDRE
Date d'inscription: 6 Sep 2005
Messages: 39
Site web

Re: SVG : Adobe se retire du jeu

mauviere a écrit:

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.


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

Hors ligne

 

#13 Tue 03 October 2006 15:17

Yves
Membre du bureau
Lieu: Aix-les-Bains
Date d'inscription: 22 Mar 2006
Messages: 9853
Site web

Re: SVG : Adobe se retire du jeu

NETAGIS44 a écrit:

Bonjour,

C'est vrai que SIG en ligne veut dire beaucoup de choses en terme de fonctionnalités attendues. Je parlais dans mon message davantage des fonctionnalités permettant la mise à jour en ligne de données graphiques, et notamment la possibilité d'utiliser des fonctions d'accroches ou des fonctions de saisies topologiques. A ma connaissance, MapServer ne le permet pas aujourd'hui alors que l'utilisation du SVG permet d'aller très loin dans ce type de fonctionnalités. Par contre, je suis preneur d'infos si vous avez des exemples pour me montrer que c'est possible si je me trompe.

En espérant vous avoir apporté la précision attendue,

Cordialement,

Patrick JULIEN


Bonjour,
Merci pour ces précisions. En fait que ce soit par SVG ou par mapserver, ce genre de chose est géré par l'interface graphique (je me trompre peut être pour SVG). CartoWeb propose une option de snapping mais il doit être possible de coder d'autres fonctionnalités. PostGIS, dans une prochaine version, devrait gérer la topologie. Concernant MapServer, je n'ai malheureusement aucune idée, aucunes RFC sur la topologie n'a été à ce jour diffusé, me semble t-il.

Y.


Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !!  - GeoRezo vous aide ? Aidez GeoRezo !

Hors ligne

 

#14 Tue 03 October 2006 15:49

beloe
Participant occasionnel
Lieu: Suisse
Date d'inscription: 13 Sep 2005
Messages: 10
Site web

Re: SVG : Adobe se retire du jeu

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,

Hors ligne

 

#15 Tue 03 October 2006 16:06

geomaticien
Participant occasionnel
Lieu: Savoie Technolac
Date d'inscription: 22 Feb 2006
Messages: 22
Site web

Re: SVG : Adobe se retire du jeu

Bonjour à tous,

Je voudrais réagir aux différents messages consécutifs au retrait d'Adobe du SVG. Comme d'autres l'ont dit, je pense que SVG continuera à se développer avec ou sans Adobe, parce que c'est une spec w3c, et parce que Firefox est désormais plus qu'un browser: c'est une plateforme.

Et bien que chacun ici me connaisse pour mon implication dans le libre, je ne voue pas flash aux gémonies: il en existe une spec. ouverte, openswf.
Je ne m'inscrit donc pas dans les "guerres de chapelles" entre flash et svg, entre les solutions côté client et celles côté serveur. Voici pourquoi:
1) On n'enverra jamais des téras de données au client par le net: il faut donc des serveurs carto efficaces.
2) Le fait de pouvoir zoomer côté client (ce que permettent svg et flash) n'empêche pas de devoir appeller le serveur très régulièrement, dès que le zooming nécessite de télécharger plus de détails. Le zoom côté client n'est donc pas un avantage significatif (rien ne sert de télécharger plus que la résolution affichée simplement pour pouvoir zoomer sans rappeller le serveur)

Donc à mon avis, les bonnes solutions sont celles qui offrent de la fluidité dans la navigation, de l'ergonomie. Un bon exemple, bien connu, est Google Earth. Les technologies type Ajax, le "tiling", et l'évolution vers un web 2.0 où la notion même de page web s'efface devant celle de GUI me semblent donc être l'avenir.

Or ce type d'interface a déjà été réalisée par certains, tant en flash qu'en svg. Ce qui fait la supériorité de certaines solutions, c'est l'appel au serveur le plus fluide et le plus "transparent" possible.

On ne parvient à de bons résultats qu'en mixant intelligement PLUSIEURS technologies, par exemple avec un serveur carto respectant les specs OGC WMS et WFS, et des clients "ajaxifiés" 100% compatibles.

Je ne crois plus à l'avenir de solutions "fermées" autour de protocoles client-serveur non normalisés.

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

Hors ligne

 

#16 Fri 06 October 2006 11:28

helbakkali
Juste Inscrit !
Date d'inscription: 6 Oct 2006
Messages: 2

Re: SVG : Adobe se retire du jeu

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.

Hors ligne

 

#17 Fri 06 October 2006 11:38

strass
Juste Inscrit !
Date d'inscription: 2 Oct 2006
Messages: 2
Site web

Re: SVG : Adobe se retire du jeu

Je ne vais pas copier/coller le contenu de la page wikipedia suivante, il y a tout ce qu'il faut là-bas :
http://en.wikipedia.org/wiki/SWF
Ce qu'il faut bien noter, c'est que la licence de Flash interdit la création de "player" flash. Mais vu qu'Adobe ne se bouge pas trop pour sortir des players sur des plateformes autres que Windows, on a vu apparaître un certain nombre d'initiatives (timides) pour construire un player Flash autre que celui d'Adobe.
D'autre part, j'ai déjà travaillé avec Mtasc (cité dans l'article) qui permet de compiler du code ActionScript pour en faire une applet Flash.

Hors ligne

 

#18 Fri 06 October 2006 12:02

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

Re: SVG : Adobe se retire du jeu

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


Éric Mauvière - icem7

Hors ligne

 

#19 Fri 06 October 2006 12:04

helbakkali
Juste Inscrit !
Date d'inscription: 6 Oct 2006
Messages: 2

Re: SVG : Adobe se retire du jeu

Merci pour la réponse.
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.
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 ?

Merci pour votre éclaircissement.

Hors ligne

 

#20 Fri 06 October 2006 12:47

André M. Winter
Participant actif
Lieu: Götzen, Tyrol, Autriche
Date d'inscription: 6 Sep 2005
Messages: 60
Site web

Re: SVG : Adobe se retire du jeu

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/

Hors ligne

 

#21 Fri 06 October 2006 15:59

Pierre Menu
Invité

Re: SVG : Adobe se retire du jeu

Il existe aussi des plateformes prêtes à l'emploi MAIS adaptables (via API et/ou accès direct en base) qu'il est intéressant d'évaluer à mon avis avant de se lancer dans de tels projets vu le temps que certains y ont passé.

Je parle notamment pour ma paroisse et pour d'autres dans le SudOuest par exemple.   :-)

 

#22 Sat 07 October 2006 12:20

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

Re: SVG : Adobe se retire du jeu

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


Éric Mauvière - icem7

Hors ligne

 

#23 Mon 09 October 2006 12:54

benoist
Participant actif
Lieu: Genève
Date d'inscription: 6 Sep 2005
Messages: 82
Site web

Re: SVG : Adobe se retire du jeu

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

Pour compléter, je dirai qu'en fait, la plus grande difficulté est d'integrer dans l'appli client non pas seulement la geometrie des objets provenant d'une source (shp, tab, dgn, dxf, dwf, ... ou encore WKT/WKB dans PostGis ou MySQL4.11) mais aussi des évènements Javascripts qui vont donner le PLUS d'une cartographie DYNAMIQUE par rapport à une appli web de type Web
Map Server où les cartes envoyées sur le navigateur web sont des Images...

Pour réaliser ceci, il faut ecrire du code (j'utilise PHP coté serveur).


Pascal BENOIST
pascal.benoist11@texte-a-enlever.wanadoo.fr
Mob: +33 (0)6 12 61 68 02
Fixe: +33 (0)4 50 75 17 74


Pascal BENOIST- PictureComputer
http://www.picturecomputer.ch

Hors ligne

 

#24 Mon 09 October 2006 14:02

Yves
Membre du bureau
Lieu: Aix-les-Bains
Date d'inscription: 22 Mar 2006
Messages: 9853
Site web

Re: SVG : Adobe se retire du jeu

benoist a écrit:

une appli web de type Web
Map Server où les cartes envoyées sur le navigateur web sont des Images...


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.


Yves Jacolin, bénévole de l'association GeoRezo.net, agit au nom et pour le compte de l'association - Partageons ce qui nous départage !!  - GeoRezo vous aide ? Aidez GeoRezo !

Hors ligne

 

#25 Mon 09 October 2006 15:53

benoist
Participant actif
Lieu: Genève
Date d'inscription: 6 Sep 2005
Messages: 82
Site web

Re: SVG : Adobe se retire du jeu

Pour faire une 'Map' autour d'une donnée vectorielle de topology LINE, c'est plus difficile...

Pascal BENOIST
pascal.benoist11@texte-a-enlever.wanadoo.fr
Mob: +33 (0)6 12 61 68 02
Fixe: +33 (0)4 50 75 17 74


Pascal BENOIST- PictureComputer
http://www.picturecomputer.ch

Hors ligne

 

#26 Mon 09 October 2006 16:44

geomaticien
Participant occasionnel
Lieu: Savoie Technolac
Date d'inscription: 22 Feb 2006
Messages: 22
Site web

Re: SVG : Adobe se retire du jeu

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

Hors ligne

 

#27 Mon 09 October 2006 17:39

André M. Winter
Participant actif
Lieu: Götzen, Tyrol, Autriche
Date d'inscription: 6 Sep 2005
Messages: 60
Site web

Re: SVG : Adobe se retire du jeu

bonjour,

> 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.

c'est bien joli. mais ca ne sert a rien si c'est pour générer à nouveau chaque extrait comme une tuile sans profiter du fait qu'une partie de l'information vectorielle se trouve déjà côté client et qu'il pourrait zoomer, interperter, interroger, etc. ces données sans de nouveau demander au serveur quelle info se cache sous clicX/clicY...

quand on passe de raster à vecteur, il faut que la logique côte machine client suive. je sais que ce n'est pas facile à gérer et qu'il n'y a pas encore de vrai exemples de ca en ligne, mais un mapserver qui fait du SWF n'apporte rien à l'ergonomie d'une application web carto par sa simple existence.

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/

Hors ligne

 

#28 Tue 10 October 2006 08:25

geomaticien
Participant occasionnel
Lieu: Savoie Technolac
Date d'inscription: 22 Feb 2006
Messages: 22
Site web

Re: SVG : Adobe se retire du jeu

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

Hors ligne

 

#29 Tue 10 October 2006 11:44

André M. Winter
Participant actif
Lieu: Götzen, Tyrol, Autriche
Date d'inscription: 6 Sep 2005
Messages: 60
Site web

Re: SVG : Adobe se retire du jeu

bonjour,
> Je ne suis pas d'accord à 100% avec ce point de vue.

je suis bien conscient qu'il y a une part de théorie là dedans. ma critique porte surtout sur les éditeurs de serveurs cartos (tous
confoncus) qui ne prennent pas le problème par les cornes alors qu'on pourrait s'en occuper depuis les années 1970 si on recherche bien dans la littérature (du côté de l'université de Boulder au Colorado notamment). et le plus amusant est qu'ils se font tous doubler par une technique asynchrone qui rend un serveur carto obsolète: Google Maps et co.

> 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 !

ca c'est sûr, mais augmenter une vue d'un niveau de zoom x à x*1.2 dans une carte topo reviendrait sans doute à ajouter quelques symboles ponctuels ou une ou deux routes supplémentaires. le gros paquet des courbes de niveau, polygones forestiers, les couches contenant maisons et autres infrastructures, tout ca ne changera ni de géometrie, ni du point de vue des attributs. ce sont quand même des économies, non?

> 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.

l'idée est d'avoir une info résumé disponible par défaut et on retourne sur le serveur avec une requête asynchrone pour aller chercher une information détaillée sur un objet précis sélectionné par l'utilisateur. ces requêtes tiennent en une ligne de 40 caractères so on s'applique...

quant à interroger sérieusement des raster côté interface client, faut me monter ca, svp. (les image maps je connais...)

peut-être faut-il aussi écarter une idée fausse: une application cartographique en ligne N'est PAS un "SIG web". en général il n'y pas besoin d'avoir tout disponible de suite.

> 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.

gérer l'envoi des données. là est la clé de la technique. le clou est d'anticiper sur l'utilisateur et ce dans le cadre de ce que supporte la connexion...


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/

Hors ligne

 

#30 Tue 10 October 2006 13:17

mauviere
Participant occasionnel
Lieu: Toulouse
Date d'inscription: 19 Oct 2005
Messages: 44
Site web

Re: SVG : Adobe se retire du jeu

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


Éric Mauvière - icem7

Hors ligne

 

Pied de page des forums

Powered by FluxBB