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

Rencontres QGIS 2025

L'appel à participation est ouvert jusqu'au 19 janvier 2025!

#1 Fri 04 October 2002 17:24

Ludovic LESTRAT
Invité

1ere lecture du draft 0.2

page 4 : §1 il manque surement une definition de ce que sous-entend le
terme serveur carto . C'est souvent utilise pour l'ensemble Serveur
Web+appli carto (cas d'une architecture simple, qui peut se complexifier
par l'adjonction de serveurs dedies pour les moteurs carto). Ne
s'agit-il pas plutot de Sites carto ? Ce qui engloberait la partie
cliente (interface de navigation) et la partie serveur (serveur
web+interpreteurs ASP, PHP, moteurs de servlets, ActiveX, ..., serveurs
applicatifs carto, SGBD).

page 4 : §1.1 : le but d'un site carto n'est pas d'y retrouver toutes
les fonctionnalites d'un SIG bureautique car le public n'est pas le meme
(pb de formation, pb de lourdeur de certaines fonctions avancees, ...).
Personnellement je penche pour un partage au plus plus nombre d'une
information riche (car une carte est un media qui parle !).
Sur le serveur web il ne faut pas oublier une surcouche applicative pour
executer les scripts ASP, PHP, les servlets et autres types de code.
Les temps de reponse des donnees images mortes sont mediocres : propos
a nuancer car tout depend comment elles sont generees : en live ou en
avance de phase via une chaine de production automatisee ou des
applications de preparation.
fonctionnalites : il serait interessant de faire des stats sur les
fonctionnalites les lpus rencontres sur les sites cart sur internet, sur
intranet/extranet (surement + riches).

page 5: §1.2.1 : simplificite des outils (les utilisateurs n'ont pas
besoin d'etre aussi former que devant un SIG bureautique)

page 6 : § 1.3.1.a : ou mettre les solutions comme Actigis, IziMap,
SVG-Studio, e-Carto, ... qui ne sortent pas de grands editeurs, mais
ciblent specifiquement le secteur de la carto sur le web.

page 7 : § 1.3.1.b : inconvenients : peu de souplesse dans
l'enrichissement des fonctionnalites d'interaction entre la carte et
l'appli carto sur le serveur web (une API trop complexe est proposee).

page 8 : § 1.4.8 : il faut parfois installer un JDK+moteur de servlet
avant l'installation de l'appli carto (cas d'ArcIMS)
Les donnees ne sont pas obligatoirement sur le serveur web, mais peuvent
etre sur un serveur accessible depuis ce serveur web (fichiers plats),
ou stockes dans une base de donnees sur un autre serveur. Suivant le
niveau de securite requis il peut etre conseille d'installer des
systemes +/- lourds en amont (firewall, DMZ,...)

§ 1.4.3 : le travail du serveur est multiple et peut etre delegue a
d'autres serveurs, ou bien squizze par des systemes de cache, de
pre-calculs. Suivant les technologies, la mise en page de la carte est
faite a 100% sur le serveur carto ou se partage entre le serveur et le
client (notammant en SVG via les CSS, le serveur ne fait que donner la
geometrie des objets), c'est peut-etre ce qui est marque dans le 3eme
point ?

§ 1.5.1 : notion de nombre de processeurs a ajouter; il faut souvent
ajouter le cout d'une base de donnees ou du soft qui y rajoute la couche
spatiale (ex: ArcSDE)

page 9 : § 1.6.1 : suivants les solutions, il existe des assitants
simplifiant reellement la creation d'un site carto sans aucun
developpement (ArcIMS, IziMap, ...), donc peu de competences requises
(ce point est precise au § 1.7, mais c'est aussi pertinent de le mettre ici)

page 10 : §1.8 => IziMap, demos raster et SVG sur
http://www.izimap.fr.st (plan de ville interactif, deplacement temps
reel de mobiles, ...)

page 11 : § 2.1 : voir l'article sur le format SVG sur
http://www.izimap.fr.st dans la rubrique Technologies

page 12 : § 2.1.2 : il est possible de saisir de la geometrie en SVG
(voir exemples sur www.kevlindev.com ).
Ajouter JSP a cote de PHP/ASP

§ 2.2.1 : la base du reseau routier sur la France est volumineux !!

§ 2.2.3 : pour les cartes SVG tres simples (document morts), seul le
client travaille. Pour les cartes + evoluees, des interactions
regulieres sont effectuees en background avec le serveur web pour
recuperer des infos (fichiers tuilles, base de donnees, notions de
session si saisie ou mode authentifie, ...).

§ 2.3.b : IziMap permet de publier en SVG des donnees visualisees sur
ArcView. (cf http://www.izimap.fr.st)

page 13 : § 2.4 : editeur de texte reconnaissant HTML/JS/PHP, ... :
Allaire HomeSite (prix ??)

§ 2.5 : pas de connaissance en dev. internet requise car tout se fait
par des wizards.

§ 2.7.b : demos IziMap sur http://www.izimap.fr.st

page 16 : j'attends la liste des fonctionnalites pour indiquer celles
remplies par les differentes solutions de la gamme IziMap.

 

#2 Fri 04 October 2002 17:24

Ludovic LESTRAT
Invité

Re: 1ere lecture du draft 0.2

> page 4 : §1 il manque surement une definition de ce que sous-entend le
> terme serveur carto . C'est souvent utilise pour l'ensemble Serveur
...

Mes excuses aupres de l'auteur de ce courrier, je l'ai renvoye
sur la liste en oubliant l'effet sur l'expediteur. Donc ce
courrier provient de :
caillon.didier@texte-a-enlever.wanadoo.fr

Voila qui est rectifie, encore toutes mes excuses.

Cordialement
Ludovic

--
LESTRAT Ludovic, Geo-Hyd
386 rue du rond d'eau
45590 Saint Cyr en Val
bur : 02.38.64.01.94 (Direct)
mob : 06.63.36.37.46

 

Pied de page des forums

Powered by FluxBB