Les formats de données
- Fonds Google
Google Maps met à disposition plusieurs fonds de plan utilisables par défaut. Ces fonds de carte sont créés par Google à partir de sources de données diverses telles que Télé Atlas, Navteq, IGN, Spot Image, etc.
La couverture des données n'est pas de la même précision partout sur le globe pour diverses raisons (manque d'intérêt, legislation, difficulté d'accès). Notez ci-dessous le contraste entre la Corée du Nord et la Corée du Sud.
Les fonds disponibles sont les suivants :
La couverture des données n'est pas de la même précision partout sur le globe pour diverses raisons (manque d'intérêt, legislation, difficulté d'accès). Notez ci-dessous le contraste entre la Corée du Nord et la Corée du Sud.
Les fonds disponibles sont les suivants :
- Plan : cartographie classique, le plus courant.
- Relief : carte topographique mettant en valeur le relief et l'occupation des sols.
- Satellite sans légende : vues satellites et photographies aériennes.
- Satellite : hybride entre les photographies aériennes et les informations du plan.
- Fonds personnalisés
Dans la dernière version de l'API Google Maps, il est possible de modifier l'ensemble des fonds de plan par défaut en changeant la visibilité et la couleur du contenu.
Il existe des outils pour styliser ses propres cartes et faciliter la création de nouveaux fonds de plan. Ci-dessous une comparaison avec les images précédentes.
Exemple dynamique avec modification de la voirie, de l'hydrologie et des zones urbaines :
Exemple dynamique avec modification de la voirie, de l'hydrologie et des zones urbaines :
- Fonds de plan externes
Moyennant l'utilisation de serveurs externes de tuilage, il est possible d'afficher toute sorte de fonds de plans. Ci-dessous un exemple de superposition
des fonds de carte provenant d'OpenStreetMap :
- Tableurs Excel, OpenOffice
Les données tableurs (Excel, LibreOffice, OpenOffice) peuvent contenir des informations de géolocalisation (colonnes latitude, longitude, x, y) ou des données d'adressage (ville, code_postal, voie, etc.).
Nous parlerons dans ce cas de géocodage (développé dans la rubrique "données").
Nous disposons d'outils permettant de lire ces fichiers (en direct, ou par import de données). Cela fonctionne de la même manière que des fichiers GPX ou que des données stockées en base de données.
Nous parlerons dans ce cas de géocodage (développé dans la rubrique "données").
Nous disposons d'outils permettant de lire ces fichiers (en direct, ou par import de données). Cela fonctionne de la même manière que des fichiers GPX ou que des données stockées en base de données.
- Relevés GPS
Les coordonnées GPS issues de recepteurs grand public type Garmin, Trimble, Magellan sont compatibles avec Google Maps.
Les notions de systèmes de coordonnées respectent les standards mondiaux et utilise le WGS84.
Nous sommes en mesure d'intégrer les relevés GPS dont le format standard est le GPX (basé sur un formalisme XML) et ainsi recréer les tracks ou waypoints avec des styles personnalisés (icones et couleurs).
Nous sommes en mesure d'intégrer les relevés GPS dont le format standard est le GPX (basé sur un formalisme XML) et ainsi recréer les tracks ou waypoints avec des styles personnalisés (icones et couleurs).
- Données SIG
Les données vecteurs SIG peuvent être de plusieurs formats (SHP, TAB, DXF/DWG, etc.). Ces formats ne sont pas lisibles par défaut avec les API Google, il faudra
donc les transformer en formats bases de données ou KMZ. Cependant il existe des outils permettant d'attaquer des données SIG natives mais qui nécessite la mise en place
de serveurs intermédiaires (Google n'étant que le client qui lit la donnée). On parlera dans ce cas de MapServer ou GeoServer qui peuvent s'interfacer avec Google Maps via des services WMS / WFS (détaillés ci-après).
- KML / KMZ
Les données fichiers de type KML / KMZ (KMZ étant un format zippé du KML) permettent le stockage de données géographiques au format lisible par Google.
Ils peuvent contenir l'ensemble des données vectorielles et attributaires qui leur sont rattachés sous forme d'infobulles avec un contenu varié (texte, HTML, images, vidéos, son, etc.)
Un de ses avantages est de pouvoir être compatible avec les logiciels bureautiques SIG courants (Quantum GIS, ArcGIS, MapInfo, etc.). Il est donc facilement intégrable dans les cartes Google. Par contre, il en résulte de nombreuses contraintes, il est difficilement manipulable et paramètrable une fois généré et a l'inconvénient de ralentir le temps de réponse.
Un de ses avantages est de pouvoir être compatible avec les logiciels bureautiques SIG courants (Quantum GIS, ArcGIS, MapInfo, etc.). Il est donc facilement intégrable dans les cartes Google. Par contre, il en résulte de nombreuses contraintes, il est difficilement manipulable et paramètrable une fois généré et a l'inconvénient de ralentir le temps de réponse.
- Bases de données (spatiales ou non)
Les données vectorielles (et attributaires associées) ajoutées à la carte peuvent provenir de bases de données, non nécessairement des bases de données spatiales.
Il est possible de charger des données issues de SGBD courants dans le monde du web tels que MySQL, PostgreSQL ou Oracle.
Les autres ne sont pas exclus mais on préfèrera des passerelles ou des exports.
On peut également attaquer des couches issues de bases de données spatiales type PostgreSQL/PostGIS superposées à des fonds Google, il faudra passer par des services WMS/WFS (détaillés un peu plus bas).
Exemple d'une application utilisant une base de données MySQL pour le stockages d'objets vectoriels :
On peut également attaquer des couches issues de bases de données spatiales type PostgreSQL/PostGIS superposées à des fonds Google, il faudra passer par des services WMS/WFS (détaillés un peu plus bas).
Exemple d'une application utilisant une base de données MySQL pour le stockages d'objets vectoriels :
- Flux WMS / WFS
Les services WMS / WFS (Web Map Service et Web Feature Service) sont des standards de partage et de lecture de données SIG sur le web. Il est possible d'utiliser ses standards avec les fonds Google Maps.
L'avantage de ces formats est de pouvoir lire n'importe quel type de données SIG en entrée (Base de données, KML, SHP, TAB) d'une seule et même manière, transparente pour l'utilisateur.
L'inconvénient est que son fonctionnement est plus lourd à mettre en place et nécessite un serveur web intermédiaire (même machine ou autre machine que celle hébergeant l'application).
Ce mode de fonctionnement permet également de faire de la représentation poussée qui ne peut être faite avec Google Maps (polygones hachurés, lignes pointillés, graphiques, etc.)
L'avantage de ces formats est de pouvoir lire n'importe quel type de données SIG en entrée (Base de données, KML, SHP, TAB) d'une seule et même manière, transparente pour l'utilisateur.
L'inconvénient est que son fonctionnement est plus lourd à mettre en place et nécessite un serveur web intermédiaire (même machine ou autre machine que celle hébergeant l'application).
Ce mode de fonctionnement permet également de faire de la représentation poussée qui ne peut être faite avec Google Maps (polygones hachurés, lignes pointillés, graphiques, etc.)
- Flux JSON / XML
Des possibilités sont données également de lire des flux provenant de sources diverses (serveurs externes, lecture de fichiers). Les KML ne sont ni plus ni moins que des fichiers XML formatés.
Le JSON est un formalisme javascript de stockage des données (on parle également de geoJSON), Google Maps peut lire nativement ce format de données.
Le JSON est un formalisme javascript de stockage des données (on parle également de geoJSON), Google Maps peut lire nativement ce format de données.