Le SIG travaille avec des données commerciales ainsi qu’à l’aide d’échanges avec des partenaires. Chronologiquement nous avons tout abord acquis des données commerciales tout en commençant les discussions avec les partenaires pour les échanges.

L’appel d’offre concernant les données commerciales a été édité en 2003.
Les données existantes à l’origine étaient très disparates. Seules les agglomérations de LILLE, de DOUAI et de DUNKERQUE étaient à peu près correctement pourvues. Le choix s’est donc porté sur l’achat de données commerciales pour l’ensemble du département et sur la zone de défense.

Afin de ne pas défavoriser l’Institut Géographique National français (IGN) nous avons découpé l’appel d’offre en trois lots.

Le premier, le plus complet, portait sur le département du Nord. Ce dernier visait à obtenir des données routières vectorielles sous forme de réseau afin de pouvoir répondre tant à des besoins de cartographie classiques qu’à des analyses telles que les calculs d’isochrones ou les calculs d’itinéraires. De la cartographie de type raster et des photographies aériennes étaient également souhaitées.


Le deuxième lot couvrait le reste de la zone de défense (le Pas de Calais et les départements de la région picarde ainsi que le département des Ardennes). Nous souhaitions des données de type vecteur et de la cartographie raster. Bien entendu, l’exhaustivité demandée était moindre.


Le troisième lot enfin, couvrait le Royaume de Belgique sur une bande de cinquante kilomètres à l’est de la frontière franco-belge. Les types de données souhaitées étaient les mêmes que pour les deux premiers lots.


Après analyse des dossiers nous avons choisi les offres de la société CARTOSPHERE (filiale d’ESRI France) et de la société GEOSIGNAL.
Ces offres nous proposaient le produit MULTINET NAVIGATION de TELEATLAS ainsi que de la cartographie raster issue de ce dernier. Les photographies aériennes quant à elles, provenaient de photographie IGN, elles offrent un pixel terrain de 1 mètre.
Le choix s’est porté sur les données vecteurs de TELEATLAS car elles représentaient le graphe existant de toutes les voies figurant sur la cartographie de base au 1:25 000 éme de l’IGN. Il est clair, en revanche, que la saisie attributaire n’était de qualité que  sur les zones de forte urbanisation. Ce qui représente une quantité non négligeable sur notre département. Les produits de l’IGN n’étaient de meilleures qualités graphiques et attributaires que sur les agglomérations importantes, mais relativement pauvres sur les zones plus rurales. Ceci explique notre choix, le coût de saisie d’un tronçon complet (attributs et graphique) étant plus important que son simple renseignement d’attributs.
Les données raster nous ont servi de cartographie de circonstance dans l’attente de production plus adaptée.


En parallèle de ces sources d’informations, qui ne peuvent de par leur nature couvrir tous les besoins du SDIS, nous avons mis en place des échanges de données.

Nous avons également à l’origine travaillé avec les données issues de la communauté urbaine de LILLE. Ces données au format propre au logiciel APACS développé par cette dernière sont principalement axées sur les plans cadastraux. Une première version de plans parcellaires, fondée sur ces données, a été éditée à l’aide des outils de la communauté urbaine du temps où les sapeurs-pompiers y étaient rattachés.
Dans l’attente des plans définitifs les deux groupements de l’arrondissement de LILLE continuent d’utiliser l’interface FRUIT leur permettant d’effectuer les travaux de cartographie tels que les plans pour les établissements répertoriés.
Le groupement 1 (Flandres) utilise quant à lui certaines données cadastrales de la communauté urbaine de DUNKERQUE.
Ces données sont petit à petit remplacées par celles issues du cadastre numérisé fourni par le département.

Pour l’ensemble du département nous allons progressivement vers l’utilisation exclusive des données cadastrales de la DGI. Celles-ci nous sont fournies par le Conseil Général du Nord avec lequel nous avons passé une convention d’échange. Ainsi nous fournissons en retour notre base voie à ce dernier.

La connaissance du positionnement d’un point dépend du SIG qui le saisi dans sa base. Le renseignement des caractéristiques d’un point est du ressort de la Direction Prévision ainsi que la vérification de l’exhaustivité des points recensés.
La Direction Informatique a développé une interface de saisie des caractéristiques des points d’eau (de même pour les établissements répertoriés et les édifices), une jointure sur l’identifiant de l’objet est ensuite faite ce qui permet d’associer les attributs de l’objet à des fins de cartographie.
Pour ce qui concerne les points, lorsque les données sont numérisées, nous travaillons avec les fichiers informatiques concernés.
Pour quelques communes nous sommes allés saisir le positionnement des objets.

Dernièrement la mise en place de la PPIGE nous a permis de bénéficier de nombreuses données qui présentent l’intérêt d’être communes à l’ensemble des partenaires publics de la Région Nord-Pas-De-Calais.
Les données fournies par le biais de ce protocole sont :

    ·  La version navigation de MULTINET actualisée.
    ·  Une photographie aérienne d’un détail terrain de 50 cm.
    ·  La BD Carto IGN.
    ·  Le SCAN Départemental IGN.
    ·  Le SCAN 100 IGN.
    ·  Le SCAN 25 IGN.
    ·  Un modèle numérique de terrain.
Ces données sont libres de droits d’utilisations en interne pour chaque ayant droit.
Ce protocole initie une base commune et favorisera ainsi les échanges entre les partenaires de la région.
Le SDIS 59 ayant fortement avancé dans la mise à jour en interne de ses données, notamment pour la partie base de données routières, les données issues de la plate-forme sont principalement utilisées à des fins de complètement des données existantes.

Afin de répondre aux différents besoins, le SDIS s’est équipé de produits de la gamme ArcGIS.
Les besoins ont été définis en trois parties, qui correspondaient à autant de lots. Ceci dans le but d’ouvrir le marché le plus possible. La décomposition se déclinait comme suit :

Le noyau du SIG qualifié de gestionnaire, doit permettre à la cellule de mise à jour de gérer d’important volume de données et permettre les importations des principaux formats du marché. Rappelons que cette cellule est chargée :
D’intégrer les données provenant des différents partenaires et des différents prestataires.
De mettre à jour les données de cette base et de fournir aux utilisateurs internes les données actualisées.
D’extraire les différents produits nécessaires aux utilisateurs internes.
De retourner les informations actualisées vers nos partenaires.
En raison des gros volumes de données (la totalité du département du Nord) à traiter et du caractère hétérogène des sources, les critères de choix prépondérants se sont fondés sur la capacité à gérer un grand nombre d’objets ainsi que des images de gros volume, et la capacité à intégrer de nombreux formats d’échange. Un jeu test a été constitué à cet effet..
Des outils de développement ont également été souhaités.Tout d’abord afin de programmer  le SIG en tant que tel afin d’améliorer et de personnaliser les traitements. Ensuite, il fallait développer des applications autonomes notamment pour le CTA (ce point sera développé dans le paragraphe le concernant).
La connexion avec le SGBD ORACLE était demandée.

Par autres SIG, nous souhaitions avoir un niveau de complexité inférieur au précédent et qui se rapproche plus des SIG dits de bureautique.

Un logiciel permettant la diffusion de données géographiques (pour consultation) par un INTRANET, était demandé sous forme optionnelle.
Le client pourra grâce à ce logiciel consulter des données vecteur ou image et personnaliser leur affichage. Le client pourra effectuer des analyses thématiques simples et imprimer les cartes ainsi créées (jusqu’au format A3.) Ces éditions papier seront assorties d’éléments annexes : légende, échelle, titre, paramétrables par l’utilisateur.
Il intégrera des viewers pour les clients.

Dans le but de procéder à des tests d’utilisation de cartographie nomade.

Cette chaîne pouvait être composée de logiciels différents, un des critères de choix principaux étant la facilité d’utilisation et la rapidité de traitement.


Elle pouvait être un élément intégré de la suite SIG décrit plus haut.


Cette chaîne doit permettre la production de documents de qualité cartographique, ceci de l’intégration des données à la production de sorties graphiques grand format (jusqu’au format A0) et, éventuellement de films.

Huit propositions nous sont parvenues. Nous avons souhaité faire des tests approfondis ainsi que demander aux prestataires intéressés de nous présenter leurs produits. Deux ont désistés alors.

Sans dévoiler les entreprises qui y ont participé, nous pouvons indiquer que ces tests et cette présentation ont été essentiels. En effet, certaines carences sont apparues qui ont laissé planer des doutes sur la capacité de certains de continuer la mise en œuvre du projet dans de bonnes conditions. Citons pêle-mêle la non connexion à la base de données ORACLE pour les tests, des tests (qui pouvaient être réalisés en amont) effectués de façon désinvolte, voire des “mensonges” sur les résultats réels. Par ailleurs la composition de certaines équipes (en nombre de personnes) nous a semblé trop faible, ainsi que la volonté de poursuivre l’activité SIG à moyen terme pour un prestataire en particulier. Pour ce dernier l’activité SIG n’était pas bien entendu son activité principale. La suite nous a donné raison.


Le choix s’est porté sur la société ESRI France qui s’appuyait sur la gamme ArcGIS et dont les résultats aux tests et la prestation lors de la présentation était de loin la meilleure. De plus, DDSI qui était à l’époque indépendant d’ESRI France s’était associé à cette dernière. Une solution gérée par un interlocuteur unique nous a également semblé présenter un meilleur choix.

L’architecture initiale de notre logiciel SIG était donc la suivante :

Les sites secondaires correspondent aux dessinateurs des groupements. Ces derniers sont équipés de licences ILLUSTRATOR et finalisent les plans.


Les évolutions technologiques d’ArcGIS, en particulier l’intégration des technologies issues de Maplex et de DataDraw, nous ont amenés à acquérir des licences supplémentaires d’Arc Editor afin de permettre une véritable interactivité entre la base de données et les documents cartographiques. Ainsi, si nous possédons toujours Illustrator, la production de plans parcellaires se fera à l’aide de Maplex comme décrit ci-dessous.


De même nous utilisons désormais ArcGISSever en lieu et place d’ArcIMS.

Etat des lieux avant la départementalisation : des documents cartographiques hétérogènes en fonction des moyens de structures communales et intercommunales qui gèrent les secours.

Améliorer les conditions de travail des sapeurs pompiers du Nord en leur fournissant des outils cartographiques standardisés, adaptés et à jour.
 
La production cartographique du SDIS du nord s’articule autour de deux axes majeurs :


  1. la cartographie thématique standardisée
  2. la cartographie à façon

L’objectif était de créer une couverture cartographique départementale à partir de documents standardisés de repérage et d’intervention
  
Trois familles de documents suivant un jeu d’échelles
    -  plans de repérages départementaux et d’arrondissements
    -  650 plans de repérages communaux dits « plans urbains » basés sur le filaire Multinet mis à jour grâce à une vaste campagne de terrain opérée par les personnels d’intervention
    -  10000 plans parcellaires basés sur les données cadastrales mises à jour à partir d’ArcGIS 9.1 et sur les données métiers sapeurs – pompiers (Etare, Edifices, verdeau) saisies à distance à partir d’applications intranet (ArcGIS server)

   · Plan de manifestions sportives, d’évènements divers pour aider au déploiement des secours

   · Plans de secours et de gestion de crises (inondations, tornade d’Hautmont Maubeuge…)

   · Plans d’aide à la décision et d’aide à la gestion : profils topographiques : étude de faisceaux de transmission, isochrones et étude d’impact d’implantation de nouveaux Centres de Secours…

Cartographie gérée prochainement par commande intranet (téléchargement de cartes)

Réalisés à partir d’une base de données multinet stockée sous ORACLE en connection directe. Utilisation de datadraw SI pour l’application de la charte graphique, développement des batchs pour le placements d’odonymes, sens de circulation, placement de symboles. Exports sous Illustrator 10 pour la finition par une équipe de 5 dessinateurs.

Pour automatiser la production au niveau départemental, un lanceur de batch a été réalisé en Visual Basic.
 

Un autre programme de tri automatique des exports par unité territoriale (Groupement) a également été réalisé.

Programme VB sous arcgis 8.3 permettant l’extraction et le formatage (abréviations, liaisons, carroyages) de fichiers .txt. Mise en forme sous excel grâce à un développement en VBA

Saisie des parcelles, linéaires

Parcelles

Il s’agit donc d’une famille de documents cartographiques allant du 1/2 500° au 1/5 000. L’atlas parcellaire doit être le document cartographique le plus précis possible. Il facilitera à terme la mise en œuvre des moyens opérationnels sur le terrain.


Des couches cadastrales sont ici utilisées et doivent être adaptées à la réalité terrain.


A partir des orthos photo aériennes issues de la PPIGE, l’équipe de production complète et modifie la couche de parcelles afin de la faire correspondre à la réalité. Il est donc nécessaire de créer, couper et supprimer certaines parcelles ou parties de parcelles à l’aide des barres d’outils d’édition et d’édition avancée en ArcEditor 9.1

Linéaires
On y trouve les bordures de trottoir et certains éléments comme des terrains de sport qui permettent de donner un aspect « abouti » aux plans. L’objectif est donc de compléter cette couche et d’y appliquer une typologie permettant d’individualiser les différentes composantes.


Typologie :


    -   Voie bordurée correspond aux bordures (surtout le long des grands axes et dans les centres des communes)
    -   Voie non bordurée uniquement hors des centres de communes pour délimiter l’axe de circulation (cas des fossés…)
    -   Chemin : uniquement les plus larges et visibles
    -   Franchissement : ponts, passerelles
    -   Franchissement chemin de fer : uniquement lorsque la voie ferrées est dessous
    -   Ecluse
    -   Eléments autoroutiers, saisie indispensable
    -   Terrain foot, ne pas percer les parcelles
    -   Terrain de sport, ne pas percer les parcelles
    -   Terrain tennis, ne pas percer les parcelles
    -   Séparation bâti : parfois le bâti est séparé par des éléments linéaires
    -   Rempart
    -   Autre.

Chaque dessinateur passe en mode Editeur « Annotation » afin de résoudre l’ensemble des conflits de positionnement d’étiquettes.
La sélection, l’export et l’impression des plans s’effectuent à l’aide de l’atlas V9
Un développement est cours pour le placement et la rotation automatique des numéros de planches voisines

L’expérience des plans urbains nous a montré que les exports successifs alourdissent les processus, rallongent considérablement les délais et sont généralement synonymes d’erreurs. Les liens avec la base de données ont été rompus ce qui a rendu obligatoire la double saisie graphique (Illustrator) et SIG (Arc Gis)

La solution préconisée précédemment pour les plans parcellaires présente alors de nombreux avantages :

 . L’utilisation d’une seule interface pour la production ce qui réduit les délais et les erreurs


 . Les potentialités du système d’information conservées. La mise à jour est immédiatement répercutée dans les plans. Il est néanmoins nécessaire de mettre en place un système d’alerte MAJ pour la réédition des plans qui ont connu des mises à jour.


 . Les liens préservés sur les étiquettes grâce à l’édition d’annotations. Les textes ne sont plus des graphiques sous Illustrator mais sont stockés dans la base de données et sont mis à jour pratiquement automatiquement dans Arc map.


Avec ces fonctionnalités Arc map rivalise avec les fonctionnalités d’Illustator

Ils sont de divers types plus ou moins complexes de la simple impression d’une photo-aérienne à l’étude d’implantation d’un CIS ou d’un faisceau hertzien. La cartographie est dans ce cas souvent un outil d’aide à la décision

Profils topographiques

Des tests ont été effectués pour développer l’utilisation de la cartographie à travers l’intranet. Deux types d’utilisation ont été testés, il s’agit d’applications de consultation des informations cartographiques et de mise à jour des données par les sapeurs pompiers de la sous direction prévision.

Le serveur web cartographique est un PC équipé de windows serveur 2003 et IIS sur lequel a été installé ArcGIS serveur 9.2 (version .Net).
 
Les applications ont été développées avec Microsoft Visual Studio 2005 et sont basées sur le modèle de site web fourni par ESRI.
 
Les données sont stockées dans une base SDE workgroup.

Pour ces deux applications, le fond de carte (regroupant les couches communes, parcelles, bâtiments, routes, voies d’eau et bois\espaces verts) correspond à un service qui a été mis en cache aux échelles 1/1 000, 1/2 500, 1/5 000 et 1/20 000 afin d’accélérer l’affichage.

Cette application a pour but de permettre aux utilisateurs du service juridique d’accéder aux informations concernant les propriétaires des parcelles cadastrales.

Les données

Une couche affichant uniquement les numéros de parcelle a été ajoutée en tant que service.


Une table de données attributaires contenant les informations sur les propriétaires est également utilisée mais est accédée directement par une connexion à la base de données SQLExpress.

soit un numéro de parcelle, soit un nom de rue.
Si un objet est trouvé, la carte se centre alors sur celui-ci.

Outil d’interrogation
Une tâche personnalisée (sous-classe de « FloatingPanelTask ») a été mise en place pour permettre à l’utilisateur de cliquer sur une parcelle pour afficher les informations concernant celle-ci et son propriétaire.

En orange apparaît la rue recherchée et en violet la parcelle sélectionnée dont les informations sont affichées à gauche.

Outil d’impression
Une tâche permettant l’impression de la carte et des données cadastrales associées a été développée. Celle-ci est basée sur l’exemple « Common PrintTask » fournit par l’EDN.
Cette tâche crée une page web convenable pour l’impression.

Cette application a pour but de valider la mise à jour des ETARE (Etablissements répertoriés) et leur association avec les données métier (en particulier l’activité, pour connaître le type de risque correspondant) par les sapeurs pompiers. Ceci afin de permettre de maintenir à jour les informations pour les rééditions de plans parcellaires.
 
Les données

Les ETARE sont de deux types, soit des bâtiments (déjà présent sur la couche de fond), soit des points qui sont dans une couche superposée au fond. Ces derniers représentent les ETARE qui ne correspondent pas à des bâtiments apparaissant au cadastre comme les parkings souterrains par exemple.

L’application

L’ouverture de la carte se fait à partir d’une application métier utilisée pour répertorier les ETARE.


Après en avoir sélectionné un, l’utilisateur peut ouvrir la carte qui sera centrée dans la rue où se situe cet établissement.


Les informations nécessaires à ce positionnement sont fournies par l’intermédiaire des paramètres de l’URL.

Les outils d’association

Deux outils permettent de sélectionner des bâtiments pour le premier et des ETARE ponctuels pour le second. Ils apparaissent alors en violet sur la carte et sont ajoutés à une liste qui sera associée à l’ETARE à partir duquel la carte a été ouverte.

Les bâtiments sélectionnés apparaissent en violet.


 Les outils de mise à jour

Une tâche basée sur l’exemple « Common Custom EditorTask » de l’EDN a été ajoutée afin de permettre aux sapeurs pompiers de créer, modifier ou supprimer les ETARE ponctuels.

La tâche a été modifiée afin d’être la plus simple possible et de ne présenter à l’utilisateur que les outils et les champs nécessaires pour cette mise à jour, d’autres champs étant mis à jour automatiquement et de façon totalement transparente.

Ces applications s’adressent à des utilisateurs ayant pour certain des connaissances de base en informatique et aucunes connaissances cartographiques.


Il était donc primordial de pouvoir proposer des applications simples et intuitives.


Les retours positifs des différents utilisateurs ayant participés aux tests ont donc permis de valider l’ergonomie et la facilité d’utilisation de celles-ci.