Comment créer (ou plutôt détourner) un SIG ?

[Géo Trouvetout]

Bonjour à tous, et j'espère être dans le bon forum, sinon n'hésitez pas à me le dire.


Je souhaite créer une sorte de SIG, qui n'aura rien de géographique, mais le but est d'utiliser les outils des SIG pour afficher des schémas (par exemple, schémas électriques "draps de lit") sous forme "slippy map".

Ce que j'espère, c'est pouvoir faire cela sans trop de programmation. Installer et configurer un serveur apache, cela ne me fait pas peur, mais du développement en C++, je ne suis pas cap !


Je vous donne déjà le contexte et les contraintes :

- projet d'envergure "PME",
- 10 à 50 utilisateurs instantanés,
- la "carte", au niveau de zoom maximum ferait de l'ordre de 50 tuiles de large sur 30 de haut (je parle en tuiles de 256x256),
- j'imagine 4 niveaux de zoom,
- la "carte" est en 2D, et j'ai la chance que mon schéma soit plan, et non une projection de sphère, donc pas de Mercator dans l'équation !
- l'idée est aussi d'afficher des méta-données, dont certaines seraient issues d'une base commune (par exemple, tous les matériels en panne sont entourés en rouge), d'autres seraient propres à chaque utilisateur (par exemple, un utilisateur met un marqueur sur tous les matériels sur lesquels il travaille),
- les méta-données sont affichées, ou non, au gré des utilisateurs sur le principe des calques.


Ensuite ce que je connais des SIG, depuis [rien-la-semaine-dernière] jusqu'à aujourd'hui :

1) Il faut des tuiles,
2) Il faut un serveur de tuiles,
3) Il faut un [machin] qui fait le "rendu",
4) Il faut un outil intégré au browser, qui sait demander ce qu'il faut au serveur quand on tourne la molette pour zoomer, ou qu'on fait glisser la petite main pour déplacer la carte,
5) Il faut aussi [quelque chose] capable d'afficher les marqueurs et autres métadonnées au bon endroit,
6) Il faut encore [un truc] qui affiche les calques à la demande.


Alors bien sûr, je ne me rends sans doute pas compte de l'énormité de la tâche (et c'est bien mieux comme ça !), mais voilà ce que j'imagine, et dites-moi si je me trompe.

- Pour (1), soit prendre un png de mon schéma global, et le couper en tuiles de 256x256, soit faire des tuiles vectorielles en svg, ce qui semble être mieux dans mon cas.

- (2) n'a pas l'air très compliqué, et compte tenu du temps de réponse attendu divisé par le nombre d'utilisateurs, cela pourrait même être un simple serveur de fichiers. En effet, selon le principe du stockage http://.../zoom/ligne/colonne.png, je pense qu'on pourrait le remplacer par une ressource réseau Windows du genre R:\\...\zoom\ligne\colonne.png

- Pour (3), j'ai un peu de mal à synthétiser tout ce que j'ai trouvé sur le web. J'ai beaucoup tourné autour d'OSM et je n'ai pas bien compris le rôle de Mapnik et du SGBD relationnel PostgrSQL. Dans mon cas, les mises à jour sont rares et les tuiles peu nombreuses, donc je subodore que beaucoup de contraintes des SIG "mondiaux" disparaissent d'un coup. Est-il possible d'imaginer que (4) communique directement avec (2) qui renvoie "bêtement" les tuiles demandées ?

- Pour (4), c'est là que je compte sur la puissance d'adaptation des outils existants. J'ai beaucoup vu de références à OpenLayers et à Leaflet, et je suppose que ces outils sont déjà installés/accessibles sans qu'on s'en rende compte, puisque tout utilisateur est actuellement capable de naviguer sur google maps et OSM.org sans comprendre ce qu'il y a derrière. Donc je suppose qu'en modifiant la configuration de quelque chose, on sera capable de connecter l'utilisateur à mon serveur de tuiles.

- (5) et (6) ne font peut-être qu'un ? Là encore, est-ce Openlayers (ou Leaflet) qui permet d'effectuer ce travail ? D'autre part, comment sont stockées les méta-données communes (SGBD ?) et comment sont stockées les méta-données personnelles ? Mystère !


Alors voilà, évidemment je ne demande pas à être "pris par la main" du début à la fin (déjà si vous êtes arrivés au bout de ce texte, vous avez du courage !), mais si vous pouvez me donner quelques pistes de recherche, des directions à suivre, des conseils de base qui m'évitent de perdre du temps bêtement, cela m'évitera d'aller dans des impasses. Notamment sur les outils, il me faut du "simple", du "licence libre", et du "vivant", que je n'aille pas perdre mon temps avec une technologie en voie de disparition...


Merci d'avance pour votre aide !

[_-Slash-_]

Bonjour,

Avant de parler technologies, il faut plutôt définir clairement le projet. Qu'est-ce qui est souhaité ? Gérer des schémas électriques ?
Dans quel but ? avoir une liste de ces schémas ? réaliser des liens entre eux ? faire de la simulation ? l'afficher quand on clique par ex. sur une armoire géocodée sur une carte quelconque ?

Une bonne définition du projet permettra de se orienter vers les bons outils.

En l'état, oui, un stockage des données sous forme de SGBDR peut être intéressante avec un affiche sur une page web via une brique type OpenLayers, Leaflet, etc.

[Lud]

Avant de parler technologies, il faut plutôt définir clairement le projet. Qu'est-ce qui est souhaité ? Gérer des schémas électriques ?
Dans quel but ? avoir une liste de ces schémas ? réaliser des liens entre eux ? faire de la simulation ? l'afficher quand on clique par ex. sur une armoire géocodée sur une carte quelconque ?

Une bonne définition du projet permettra de se orienter vers les bons outils.

Je ne peux qu'être d'accord avec tout ça, d'autant plus car cela rendra plus clair ta demande, cela évitera des problèmes de vocabulaire dans ta demande (ce qui est logique quand on ne connaît pas le domaine) et les problèmes qui n'en sont probablement pas, par exemple ton soucis de tuiles (combien, leur taille, etc, ne sont à priori pas des soucis ou alors lorsque tu t'intéresseras éventuellement à l'optimisation de ton appli si cela arrive un jour)

[tevrard]

Bonjour,

Avant de parler technologies, il faut plutôt définir clairement le projet. Qu'est-ce qui est souhaité ? Gérer des schémas électriques ?
Dans quel but ? avoir une liste de ces schémas ? réaliser des liens entre eux ? faire de la simulation ? l'afficher quand on clique par ex. sur une armoire géocodée sur une carte quelconque ?

Une bonne définition du projet permettra de se orienter vers les bons outils.

En l'état, oui, un stockage des données sous forme de SGBDR peut être intéressante avec un affiche sur une page web via une brique type OpenLayers, Leaflet, etc.

Une question à ajouter :
Quelles sont les différentes données dont tu disposes aujourd'hui, et sous quelles formes? seulement une image? une image et des informations a coté?
=> question importante bien qu'une réponse se trouve partiellement dans le post original

[Géo Trouvetout]

Bonjour,


Pour répondre à vos questions, voici quelques précisions sur le projet. "Au départ était le Verbe", et surtout le coup de crayon, le calque et l'encre de chine, sur des plans de tailles variables, du A3 au A1 en passant par des formats exotiques (1m de long sur 30 cm de haut par exemple). Plans représentant les installations électriques et mécaniques de l'usine dans laquelle je travaille.

Puis sont venus les outils informatiques, qui ont l'avantage de permettre des recherches rapides (je veux visualiser le moteur référencé X452, et l'outil m'ouvre le schéma à la bonne page), mais qui ont l'inconvénient de tout devoir formaliser, dont les dimensions. Donc exit les formats exotiques, tout est désormais découpé et organisé en schémas taille A3, qu'on peut visualiser ou imprimer.

Évidemment, le "drap de lit" d'un mètre de long étant découpé en 4, fait qu'il y a des renvois d'un schéma à l'autre. Un renvoi est une flèche avec les références de la page suivante et les coordonnées du renvoi correspondant. C'est donc compréhensible à l'oeil nu, et de plus, l'outil informatique est capable d'afficher le schéma connexe quand on clique sur un renvoi.

C'est déjà pas mal ! Mais je veux mieux : au lieu d'une base de schémas A3 qui s'affichent les uns par-dessus les autres, je veux un schéma global, complet, que je scrute sur mon écran comme dans Google Maps. Les avantages sont que la navigation est plus simple et plus intuitive, les différents niveaux de zoom (4 pour moi) permettent de répondre à des besoins différents de différents utilisateurs, et surtout, c'est d'ajouter de l'information sur le plan, comme dans l'exemple que je donnais : chacun peut mettre des marqueurs où ça l'intéresse.



Concernant les données d'origine, je n'envisage pas de transformer les schémas natifs (c'est un logiciel propriétaire dont je n'aurai pas les spécifications), ni de faire des mises à jour en ligne. Je partirai donc d'un dessin png global, que je vais vectoriser pour pouvoir ensuite établir les 4 niveaux de zoom. Et les rares fois où l'on fera des mises à jour, on fera un nouveau jeu de tuiles hors ligne, on arrêtera le serveur et on fera la mise à jour des fichiers.

C'est pourquoi la problématique de production des tuiles me semble accessoire, c'est juste des dizaines d'heures de travail et cela ne nécessite pas d'outils spécifiques aux SIG. Ce qui m'intéresse pour savoir si le projet est réalisable, c'est l'architecture qui part du serveur de tuiles et qui arrive juqu'au browser de l'utilisateur.

Y a-t-il d'autres points obscurs dans ma demande ?

Merci d'avance !

[Lud]

peux tu conserver la police par défaut s'il te plait ?

[SkåL]

Un serveur cartographique pourrai y répondre.

Il y a d'autres pistes logicielles également : http://hyperimage.ws/en/idea/
en allant beaucoup plus loin puisque l'on peut détailler des parties, ajouter des commentaires, etc.

Un exemple : http://kjc-sv013.kjc.uni-heidelberg.de/hachiman/#O42320/

[Géo Trouvetout]

Un exemple : http://kjc-sv013.kjc.uni-heidelberg.de/hachiman/#O42320/

Hyperimage paraît pas mal, notamment dans la navigation et dans les annotations, par contre j'y vois un inconvénient majeur : il ne semble y avoir qu'un niveau de zoom. Du coup, le zoom arrière qui donne l'image globale est illisible. Pour mon application, il est important que le schéma global soit simplifié pour continuer d'être lisible au zoom arrière maximum.


~~~
Lud, je n'ai pas changé la police ; c'est la couleur bleue qui te gêne ?

[SkåL]

Dans l'exemple que j'ai donnée, en haut à droite, il y a 4 outil : Zoom +, Zoom -, afficher à l'écran toute l'image, meilleure résolution.
Je pense que ces outils en plus de l'aperçu / barre de navigation tout en bas permettent de s'y retrouver simplement (je précise, je n'ai aucune action dans ce logiciel).

Sinon, sans parler de coordonnées, de système de projection, de serveur cartographique, un simple navigateur Openlayers avec une image statique suffit :
http://openlayers.org/en/v3.2.0/exam...tic-image.html

(après, le rendu n'est pas tuilé, mais y a-t-il vraiment le besoin ?)

[Géo Trouvetout]

Oui, c'est sympa comme système, on va même dire que c'est l'idéal, à deux questions près :

1) Le tuilage n'est pas une fin en soi, mais par contre je tiens à pouvoir zoomer et arriver sur une autre image plus détaillée (ou moins). Avec ce système, j'aurais donc 4 images statiques, non-tuilées, de 4 dimensions différentes avec chacune son niveau de détail, et quand je zoome, il faut passer d'une image à l'autre en visant les coordonnées adéquates. Cela est-il possible avec les images statiques ?

2) Il faut pouvoir ajouter des calques avec des données externes (mais si c'est comme son nom l'indique, je suppose que "OpenLayers" est fait pour cela, non ?).


Ce qui renvoie encore vers la question du "rendu", processus que je n'ai pas très bien compris. Prenons un exemple avec OSM : si je vais sur leur serveur chercher une tuile au hasard (par exemple : https://a.tile.openstreetmap.org/18/135458/91948.png qui est au centre de Besançon), il y a les bâtiments et les noms des rues, ainsi que des symboles marron pour un café, un restau et une banque.

Dois-je comprendre que la "vraie" tuile (le vrai fichier 91948.png situé dans l'arborescence du serveur) ne contient que le fond de carte, et que c'est le processus de "rendu" qui a ajouté les symboles marron avant de me renvoyer la tuile "améliorée" ?

[SkåL]

Avec un serveur cartographique, tu peux prendre l'image et la tuiler à différentes échelles (c'est ce que l'on appelle des pyramides de zoom). Ce qui permet un accès en dur (pour le serveur) à des images pour un zoom précis.
Ça fonctionne très bien si tes images n'ont pas de mise à jour.

L'autre méthode demande plus de ressources au serveur : il a en entrée des données vectorielles (rues, bâtiments, etc.) et matricielles (images), le tout géoréférencé, et il va générer à la demande une image, tuilée ou non, sur l'emprise de la requête. Mais au moins, la donnée affichée est toujours la bonne.

D'où l'identification du besoin car tu n'as peut-être pas besoin d'un tuilage.
Openlayers ouvre une image et l'affiche, même avec des formats exotiques.

Mais là, le seul avantage à faire ça, est d'avoir les images centralisées sur un serveur (donc toujours à jour) et de mettre à disposition un visualisateur d'image léger (web) sur lequel on peut naviguer pour visualiser l'image comme sur une page google Maps.

Après, pour l'ajout de marqueurs, là, ça commence à être plus technique car il faut une base de données (je pense) qui enregistre les informations.

[Lud]

Lud, je n'ai pas changé la police ; c'est la couleur bleue qui te gêne ?

Oui, quand je dis police, ça comprend l'ensemble, type, taille, couleur, etc, c'est pour éviter que le forum ne ressemble à un sapin de noel ;-), merci en tout cas

[SkåL]

Hyperimage paraît pas mal, notamment dans la navigation et dans les annotations, par contre j'y vois un inconvénient majeur : il ne semble y avoir qu'un niveau de zoom. Du coup, le zoom arrière qui donne l'image globale est illisible. Pour mon application, il est important que le schéma global soit simplifié pour continuer d'être lisible au zoom arrière maximum.

Je viens de peut-être comprendre quelque chose ...
Est-ce que tu souhaites que ton image soit dynamique, que la largeur des traits de ton schéma soit tout le temps le même peu importe l'échelle de zoom ?
Un peu comme les routes dans une application cartographique web type googlemaps, geoportail, etc. ?

Si la réponse est oui, alors il faudra avoir la donnée vectorielle de ces schémas (svg, dxf, etc.).

[Géo Trouvetout]

Je viens de peut-être comprendre quelque chose ...
Est-ce que tu souhaites que ton image soit dynamique, que la largeur des traits de ton schéma soit tout le temps le même peu importe l'échelle de zoom ?
Un peu comme les routes dans une application cartographique web type googlemaps, geoportail, etc. ?

Si la réponse est oui, alors il faudra avoir la donnée vectorielle de ces schémas (svg, dxf, etc.).

Alors la réponse est oui a priori... et non éventuellement. Je m'explique :

- oui parce que ce ne sont ni des bâtiments ni des forêts, mais des lignes abstraites représentant des câbles ou des tuyaux. Donc à n'importe quel niveau de zoom un trait gras représente une tuyauterie principale, et un trait fin une tuyauterie secondaire, par exemple. Selon ce principe, le format vectoriel parait incontournable...

- ...mais pas forcément parce qu'avec seulement 4 niveaux de zoom, je peux très bien envisager de créer 4 fichiers png statiques, chacun à son propre niveau de zoom, du moment que le client léger sache zapper d'un png à l'autre quand je tourne la molette de la souris.

La deuxième méthode me paraît plus facile à implémenter, mais je dis cela sans expérience...


Pour en revenir à la question du tuilage, je pense que l'intérêt est surtout d'éviter d'avoir à charger un énorme fichier sur le client puisqu'il ne charge que la partie en cours de visualisation, plus j'imagine quelques tuiles périphériques pour améliorer la vitesse. Dans mon cas, j'ai scanné un A1 qui correspond à environ 1/4 de l'ensemble, et cela me donne un fichier de 11000 x 8000 points (10 Mo). L'ensemble ferait donc autour de 5000 tuiles de 256x256, donc je pense que la solution "tuilage" est rentable, puisque le client ne chargerait que 40 ou 50 tuiles à chaque fois, plutôt qu'un gros fichier de 40 Mo...


~~~
Dommage, c'est joli les sapins de noël ! Alors que du gris sur fond blanc c'est un peu lugubre, justement !

[SkåL]

Donc pour l'affichage, il te faut un client cartographique léger type Openlayers, ses options permettent tout à fait de bloquer les seuils de zoom à des niveaux spécifiques.
Pour les câbles et tuyaux, je confirme pour le format vectoriel, j'ajouterai qu'il faudrait que ces données soient géoréférencées dans un système de coordonnées plan.
Ensuite, il y a des outils en ligne de commande pour générer les tuiles à partir d'une image.

Mais ... il te faudra générer une image par niveau de zoom, et ça, il faudra passer par un SIG (d'après moi) pour gérer la symbologie et exporter l'image voulue.

En plus lourd, avec ces mêmes données vectorielles géoréférencées, un serveur cartographique peut très bien faire tout ça. S'il y a mise à jour des données vectorielles, le serveur cartographique fera directement tout le travail (sous conditions de configuration).

Mais là, ce n'est que pour l'affichage.
Pour ce qui est de l'ajout de marqueurs avec peut-être des commentaires, des données attributaires, là, à ma connaissance, c'est obligatoire de passer par un serveur cartographique avec un flux WFS-T.

Du plus simple, toujours à ma connaissance et c'est du Made In France, un client web Lizmap qui permet l'affichage d'un projet QGIS (logiciel SIG libre).
Dans ce projet QGIS, tu peux ajouter 4 fois la même couche de données vectorielle et mettre des seuils de zoom différents avec une représentation figée.
La représentation d'une couche se substituera automatiquement à une autre lors de zooms.

Après, dans Lizmap, je ne sais pas si les seuils de zoom sont configurables comme pour OpenLayers, à creuser.