#1 Thu 14 August 2008 16:24
SIG embarqué
Bonjour,
Dans le cadre d'un mémoire ....
Je suis en train de rechercher des solutions pour fournir des données cartographiques à des utilisateurs ne connaissant rien en sig (admin communales, géomètre).
Le but étant de fournir à un utilisateur lambda, un logiciel gratuit et distribuable (de préférence open source) avec le kit de données afin qu'il puisse les visualiser.
Parmi les solutions que j'analyse:
1. - Le couple PostGIS + JGrass/Udig
2. - MapGuide Open Source (lecture de shape)
3 - MapGuide Open Source + PostGIS
1. Le couple PostGIS + JGrass semble bien fonctionner mais je n'arrive pas à créer la symbolique des layers imposée. Quelqu'un aurait-il une documentation à ce sujet.
2. MapGuide Open Source (lecture de shape)
L'application est fonctionnelle, mais très lente - les parties cliente et la serveur tournant en locale sur la même machine. Des solutions pour optimiser la vitesse ?
Y a t'il moyen de créer un layer composer de plusieurs shp (shp de même structures, mais correspondant à un découpage administratif par commune) sans devoir les fusionner préalablement.
3. MapGuide Open Source + PostGIS
J'ai essayer cette solution .. au cas où elle serait plus rapide que la précédente. mais elle ne semble pas fonctionner.
Les FDO sont installés correctement. dans MapGuide Studio (trial) et dans MapGuide Maestro je peut me connecter à la base de données PostGIS et même créer les layer sur base des données PostGIS, mais une fois que j'essaye de visualiser les données, rien ne s'affiche (lors que dans la même config mais avec une source en shp cela fonctionne)
L'un d'entre vous à t-il déjà eu ce type de problème ?.. des solutions?
4. D'autre idées de solution open source pour résoudre mon problème ... je suis preneur
Hors ligne
#2 Tue 02 September 2008 11:57
- poulet1212
- Participant actif
- Date d'inscription: 10 Apr 2007
- Messages: 74
Re: SIG embarqué
1.? pas d'expérience...
2. MapGuide Open Source (lecture de shape)
Que veut dire très lente? Avec quelle quantité de données? Avec FDO l'accès aux données non-gérées est performant. Cependant il est moins rapide que pour des données gérées (chargées en sdf sur le serveur). Ainsi, pour gagner en rapidité, il serait mieux de travailler avec des données gérées.
"Y a t'il moyen de créer un layer composer de plusieurs shp (shp de même structures, mais correspondant à un découpage administratif par commune) sans devoir les fusionner préalablement. "
Un layer se connecte à une source de donnée. Ceci vaut pour tous les SIG. Il faut faire un travail de prétraitement avant. Si tes données ont la même structure comme tu dis, alors c'est fait en passant.
3.? pas d'expérience...
4. mapfish, mapserver. Cela dépend si c'est pour une utilisation web. Faire des application SIG avec des données embarquées à l'intérieur n'a plus beaucoup de sens aujourd'hui. Il y a mieux à faire, au moins accéder aux données par géoservices. L'avantage avec Mapguide ou autre, il n'y a rien besoin d'installer sur le client. Maintenant avec un sig "light" JGrass/Udig il y a naturellement une installation à faire, et faut voir si c'est souhaitable. Pour la création et configuration de l'application, ainsi que la maintenance et l'aspect end-user, j'ai personnelement pas trouvé plus abouti que le projet Mapguide OS avec Mapguide Studio d'Autodesk.
Hors ligne
#3 Sun 07 September 2008 14:15
Re: SIG embarqué
En fait on fournis actuellement à des partenaires des CD avec des shapes. En fonction du partenaire, la zone concernée s'étend sur une commune (administration communale) ou sur une ou plusieurs provinces (partenaire géomètres).
Les données sont fournies suivant un découpage géographique plus petit correspondant aux anciennes feuilles de plan cadastraux.
Les utilisateurs consultent les données, feuilles par feuilles avec ArcReader. La solution est très loin d'être conviviale surtout que dans l'état des choses, il n'est pas possible de faire une recherche pour localiser la bonne feuille (il y en a quelques milliers).
Le but est de fournir les données accompagnée d'une solution que le client peut installer chez lui pour pouvoir consulter facilement les données et faire d'éventuelles recherches.
Je suis un peut déçu par la qualité des logiciels GIS open source... De toutes les solutions que j'ai testé, le seul logiciel qui soit vraiment abouti c'est MapGuide OS.
Dans la mesure ou il faut une installation conviviale et automatique des données (mise a jour chaque années), il ne semble pas possible d'utiliser la gestion des données interne au serveur.
L'installation en mode données non-gérées est mieux adaptée dans mon cas.
La taille de l'ensemble des Shp/dbf peut atteindre, en fonction des compilation, près de 9Go de données.
J'ai constaté que MGOS est beaucoup plus rapide si on lui fournis un fichier SDF reprenant l'ensemble des couches plutôt qu'un jeux de fichier de SHP
Le problème survient pour la génération de ce fichier SDF: Il y a bien OGR2OGR, mais il est difficilement utilisable et très lent pour la conversion (comparé aux autres solutions) et difficilement utilisable en ligne de commande.
J'ai également essayé avec PostGIS. L'importation des données SHP en postGIS est assez rapide, mais hélas, je n'ai pas réussi à faire afficher la moindre données dans MGOS. (Notez que MapGuide Maestro arrive a se connecter à la base de données)
C'est vraiment dommage car PostGIS me semblais être une base de données beaucoup plus fiable que MySQL.
J'ai également essayé avec MySQL. Cette solution me semble être actuellement la plus fonctionnelle mais l'application SHP2MYSQL est buggée (elle génère un script SQL avec des doublons au niveau de la clef primaire lors de l'assemblage des différentes fragments de la carte).
Je mettrais en ligne bientôt un tutoriel bien documenté pour l'utilisation de MapGuide avec différentes solutions que j'ai exploré
Un autre problème: L'un d'entre vous a t'il déjà créé des styles de ligne personnalisées et à les utiliser dans MapGuide OS?
Hors ligne
#4 Tue 09 September 2008 13:32
- poulet1212
- Participant actif
- Date d'inscription: 10 Apr 2007
- Messages: 74
Re: SIG embarqué
janhsh,
je pense sincèrment que tu devrais quitter un peu l'approche logicielle et reconsidérer l'approche conceptuelle du travail que tu veux accomplir. Visualiser des données est une chose, diffuser des données en est une autre. Est-ce vraiment la bonne solution de créer des cd données à insaller chez le client, avec toutes les contraintes que cela implique? (réinstallation, nouvel extrait chaque année, Organisation des données, découpage en fonction des clients, sécurité, etc, etc)... Très honnêtement et sans vouloir être intrusif, je laisserais cette méthode au placard. Ceci pour plusieurs raisons:
-Je vais gérer et structurer mes données de façon globale, indépendamment des clients auxquels je vais les fournir. Donc, pas de réplication avec des étendues plus petites parce que le client X n'a le droit que de voir cet étendue, etc...
-Je vais placer un service de diffusion interopérable sur ces données (WFS, WMS).
- je placerait ensuite entre ces services et le client, un proxy qui va gérer les aspects d'authentification du client, et en regard à cette authentification, le proxy filtrera les données du géoservice en fonction de ce que le client à le droit de voir (couches de données, étendue, filtres supplémentaires). (Proxy opensource pour faire cela: www.easysdi.org)
-ensuite, c'est ces services filtrés par le proxy que je mettrai comme source de données dans mon application (Mapguide opensource par exemple).
Cette combinaison geoservice+sécurisation par proxy permet de découpler la gestion de la publication des données de manière efficace.
Pourrais-tu envisager une telle piste?
Hors ligne
