ol3 - Ex1A - Create a first map with an OGC WMS layer
=== Balisage HTML et déclarations CSS ===
* Le bloc
var v1 = new ol.View({projection: "EPSG:4326"});
bbox = [-18, 38, 38, 55];
v1.fit(bbox, map.getSize());
console.log("Map extent for entire view: " + v1.calculateExtent(map.getSize()));
map.setView(v1);
showExtent(bbox);
Jouez avec la taille de la fenêtre en rafraîchissant le navigateur à chaque fois.
- Remplacer la configuration de la map view (v2) comme suit
var v2 = new ol.View({projection: "EPSG:4326"});
var cbox = [10, 46.5]; // NB: c'est le centre de bbox ci-dessus
v2.setCenter(cbox);
v2.setZoom(5);
map.setView(v2);
De même, jouez avec la taille de la fenêtre en rafraîchissant le navigateur à chaque fois. Quelle différence avec la map view (v1) ?
__TODO (III)__
- Revenir à la configuration de la map view (v0) en adaptant le système de projection avec la projection dite Mercator comme suit
var v0 = new ol.View({projection: "EPSG:3857"});
Comparez avec précédemment.
- Revenir à la configuration de la map view (v1) et ajouter le callback ci-dessous :
// Change, live, the view projection
$(document).keypress(function () {
if (map.getView().getProjection().getCode() === "EPSG:3857") {
v0 = new ol.View({projection: "EPSG:4326"});
var new_bbox = bbox;
} else {
v0 = new ol.View({projection: "EPSG:3857"});
var new_bbox = ol.proj.transformExtent(bbox, "EPSG:4326", "EPSG:3857");
}
v0.fit(new_bbox, map.getSize());
map.setView(v0);
showExtent(new_bbox);
});
__TODO (IV)__
- Supprimer le callback précédent et redéfinir la couche wmsLayer comme suit :
var wmsLayer = new ol.layer.Tile({
source: new ol.source.TileWMS({
url: blWMS,
params: {
VERSION: "1.0.0",
LAYERS: "ne_10m_admin_0_countries",
FORMAT: "image/png"
}
}),
})
Quelle différence en ajoutant une couche //Tile// plutôt que //Image//?
- Rechercher et tester d'autres couches de serveurs cartographiques WMS, comme par exemple celui de Swisstopo (voir config.js et http://spatialreference.org/ref/epsg/21781/)
===== 2. Cache de tuiles =====
Avec une source ol.source.TileWMS c'est le client qui contrôle une grille de tuiles et il peut la garder en cache. Néanmoins, à chaque requête initiale de tuile, tout le processus de rendu cartographique se fait. Mais puisqu'une couche de tuiles fait des requêtes d'images selon une grille régulière, il est possible pour le serveur de préparer un cache de ces images.
Le service cartographique WMS permet une grande flexibilité en terme de ce que le client peut demander. Côté serveur, cela rend difficile la mise en cache. A l'extrême opposé, un service peut aussi offrir des tuiles pour un ensemble prédéfini de niveaux de zoom et pour une grille régulière prédéfinie. On parle de couches de tuiles avec une source XYZ - avec X et Y indiquant la colonne et la rangée de la grille et Z le niveau de zoom. Il faut voir cela comme une [[http://georezo.net/wiki/_media/main/standards/tilematrixset.png|pyramide de tuiles]].
==== Ex2A : ol.source.OSM ====
ol3 - Ex2A - webmap with layer from tile server
__TODO__
- Modifier le centrage et le zoom de la carte comme suit :
//map.getView().fit(extent, map.getSize());
map.getView().setCenter(ol.proj.transform([6.15,46.2],"EPSG:4326","EPSG:3857"));
map.getView().setZoom(10);
- Insérer en fin de code du callback //ready// les logs ci-dessous :
console.log("LonLat Mercator: " + new ol.proj.transform([6.15,46.2],"EPSG:4326","EPSG:3857"));
console.log("LonLat Google: " + new ol.proj.transform([6.15,46.2],"EPSG:4326","EPSG:900913"));
- Remplacer la source de la couche comme suit :
source: new ol.source.OSM({
url:"http://api.tiles.mapbox.com/v3/oertz.map-i2ak2ozc/{z}/{x}/{y}.png",
attributions: [
new ol.Attribution({
html: "Based on OpenStreetMap / MapBox restyled by oertz :: HEIG-VD"
})
]
})et ajouter l'instruction CSS suivante :
.ol-attribution {
background-color: CornflowerBlue !important;
right: 10px;
left: initial;
bottom: initial;
top: 10px;
}
- Remplacer la source //[[http://openlayers.org/en/v3.19.1/apidoc/ol.source.OSM.html|ol.source.OSM]]// par une source //[[http://openlayers.org/en/v3.19.1/apidoc/ol.source.XYZ.html|ol.source.XYZ]]// comme suit :
source: new ol.source.XYZ({
url: "http://urbangene.heig-vd.ch/tilecache/{z}/{x}/{y}.png"
})
- Redéfinir la source ol.source.OSM par défaut et ajouter en fin du callback //ready// ce qui suit :
defView = [];
defView.push(new ol.View({projection: "EPSG:3857", center: new ol.proj.transform([6.865234, 45.832454], "EPSG:4326", "EPSG:3857"), zoom: 13}));
defView.push(new ol.View({projection: "EPSG:3857", center: new ol.proj.transform([7.658360, 45.976536], "EPSG:4326", "EPSG:3857"), zoom: 14}));
defView.push(new ol.View({projection: "EPSG:3857", center: new ol.proj.transform([86.9251707, 27.9878319], "EPSG:4326", "EPSG:3857"), zoom: 12}));
idxAlea = Math.floor(Math.random() * 3);
map.setView(defView[idxAlea]);
Rafraichissez le navigateur plusieurs fois. (a) Que se passe-t-il ? (b) Ajoutez votre(vos) vue(s) prédéfinie(s).
==== Ex2B : ol.source.BingMaps ====
L'utilisation d'un cache serveur de tuiles a largement été popularisé par des services propriétaires comme Bing Maps. OpenLayers étant indépendant de toute source de données, l'API offre également un type de couche pour dialoguer avec de tels services.
__TODO__
- Partir de l'état initial de l'exemple précédent en adaptant le code JavaScript comme suit :
map = new ol.Map({
target: 'map',
layers: [
new ol.layer.Tile({
source: new ol.source.BingMaps({
key: 'AqE05oJsq-bWa50FPOW2S0eQm9Oqqygc1VTi_WPhUIoKR_-jgA559CRbfndgWAIz',
imagerySet: 'AerialWithLabels'
})
})
]
});
map.getView().setCenter(ol.proj.transform([6.15,46.2],"EPSG:4326","EPSG:3857"));
map.getView().setZoom(10);
- Modifier le paramètre de type de couche selon la [[https://msdn.microsoft.com/en-us/library/ff701716.aspx|documentation Bing Maps]] (par exemple : 'OrdnanceSurvey'). Contrairement à un service WMS, le service de Bing Maps ne sait pas s'auto-décrire. Mais comme il n'y a qu'un seul service Bing Maps au monde, une documentation suffit.
- Pas de ol.source.GoogleMaps ? La réponse ici https://github.com/openlayers/ol3/issues/2205 et ici https://gist.github.com/elemoine/e82c7dd4b1d0ef45a9a4
==== Ex2C : OpenLayers.Layer.WMTS ====
Swisstopo offre un [[http://api3.geo.admin.ch/services/sdiservices.html#wmts|service de tuiles basé sur le standard WMTS]] et que l'on peut exploiter comme suit.
ol3 - Ex2C - webmap with Swisstopo WMTS
__TODO__
- Ajouter l'instruction suivante :
navigator.geolocation.getCurrentPosition(locationFixed, locationError);
ainsi que les deux fonctions callback qui vont avec :
function locationFixed(position) {
map.getView().setCenter(ol.proj.transform([position.coords.longitude, position.coords.latitude],"EPSG:4326","EPSG:21781"));
}
function locationError(e) {
console.log(e);
}
- Intéressant pour aider à démystifier le fonctionnement et l'utilisation de l'HTML5 Geolocation API :
- [[http://www.andygup.net/html5-geolocation-api-%E2%80%93-how-accurate-is-it-really|HTML5 Geolocation API – how accurate is it, really?]]
- [[http://www.alsacreations.com/tuto/lire/926-geolocalisation-geolocation-html5.html|Géolocalisation en HTML5]]
- [[http://www.mmaglobal.com/files/documents/location-data-accuracy-v3.pdf|MMA Demystifying Location Data Accuracy]]
- [[http://www.mmaglobal.com/files/whitepapers/MMA-Location-Terminology-Guide_FINAL.pdf|MMA Location Terminology Guide]]
- {{:geoinf16:ng-souriez.pdf|Souriez, vous êtes géolocalisés !}}
===== 3. Style de couche "image" =====
Pour le moment, c'est le serveur qui fait tourner son moteur cartographique pour créer une représentation image des données géographiques et ceci sur la base de styles prédéfinis. Voyons comment le client peut dire son mot et piloter le style "à distance".
==== Ex3A : Styling avec WMS ====
Le standard WMS offre beaucoup de libertés, parfois au détriment de la performance. Comme il permet de demander ce que l'on veut en termes d'enveloppe géographique (paramètre bbox) et de style parmis un ensemble de styles pré-configurer, il est aussi possible d'envoyer au serveur cartographique des instructions personnalisées de style.
ol3 - Ex3A - use of a custom SLD style
__TODO__
- Ajouter le paramètre SLD ci-dessous :
SLD: 'http://www.mediamaps.ch/oltuto/sld/pinkWorld.sld.xml'
- Avec Firefox RESTClient (ou autre équivalent), lancer la requête POST suivante sur le serveur WMS //mcWMS// https://eu1.mapcentia.com/wms/oertz/public :
public.world_simple
puis lancer
region
- Créer votre propre pinkWorld.sld.xml en y insérant l'instruction //Filter// suivante en début de //Rule// (:!: le serveur WMS doit pouvoir accéder à votre style personnalisé). Utiliser votre éditeur XML préféré type OxygenXML ou XMLSpy.
...
region
NorthAfrica
...
- Ajouter la Rule suivante après la première :
...
#DDDDDD
1.0
#000000
1
...
- Modifier le style pour que la Suisse soit représentée comme ci-dessous.
- voir la spécification [[http://portal.opengeospatial.org/files/?artifact_id=1188|Styled Layer Descriptor]]
- et le [[http://docs.geoserver.org/stable/en/user/styling/index.html|tutoriel SLD]]
{{ :ogo14:screenshot1.png?200 |}}
==== Ex3B : Custom tiling service with CartoCSS ====
* Introduction avec MapBox et exercices : {{:geoinf16:cartocss.pdf|}} avec [[https://www.mapbox.com/mapbox-studio-classic|MapBox Studio Classic]] et le [[https://www.mapbox.com/guides/style-manual/|Style guide]].
* Symbol drawing order : {{:geoinf15:symbol-rendering-order.png?linkonly|un schéma qui résume tout}} et la [[https://www.mapbox.com/tilemill/docs/guides/symbol-drawing-order/#symbol_drawing_order|documentation TileMill]] (même si dépréciée).
ol3 - Ex3B - webmap with your own MapBox basemap
__TODO__
- Suivre les exercices proposés en fin du document d'introduction à MapBox et CartoCSS de J.Freyre
- le shapefile pour l'exercice 3 est ici {{:geoinf15:g4cantons.zip|}}
- exemple de rendu pour l'exercice 4 {{:geoinf16:cartocss_ex4.png?200|}}
- Modifier le code nécessaire ci-dessus pour créer une application de webmapping utilisant votre style MapBox.
**Corrigés des exercices MapBox/CartoCSS**
* Ex1: Dans la sidebar Layers du studio on découvre qu'il y a effectivement une couche de géodonnées nommé building. Définissons un style pour représenter ses entités :
#building {
polygon-fill: #c1b0ad;
}
On voit que la couche landuse dispose d'une propriété class dont l'une des valeurs peut être 'parks'. Définissons un style ne représentant que ces parcs :
#landuse[class='parks'] {
polygon-fill: #6db569;
}
La couche poi_label a une propriété name qui sert d'étiquette :
#poi_label[zoom>=19] {
text-name: '[name]';
text-face-name: @sans_bold;
text-size: 14;
}
Ce sont les couches road, tunnel et bridge qui vous servir comme suit :
#road,
#bridge,
#tunnel {
[class='motorway'],[class='motorway_link'] {
line-color: #fc8;
line-width: 3px;
}
}
* Ex2: En utilisant les couches liés aux “thèmes” mapbox.mapbox-terrain-v1 et mapbox.mapbox-streets-v5, on ajoute aux layers de l'exercice 1 les couches hillshade, (?) et contour. On représente les courbes de niveaux de cette dernière comme suit :
#contour[zoom>=14] {
line-color: #b7b7b7;
line-width: 1;
text-name: '[ele]';
text-face-name: @sans;
text-fill: #838383;
text-size: 12;
text-placement: line;
[index=5],[index=10] {
line-width: 3;
}
}
* Ex3: Le chargement de la source de géodonnées “dans MapBox” démarre une phase de découpage des données en tuiles vectoriels selon un découpage en pyramide (appelé //gridset// par MapBox). Il ne reste donc plus qu'à habiller ces tuiles vectoriels avec un style pour produire la pyramide des tuiles images qui seront demandées à la volée par les clients cartographiques.
* Ex4: Après initialisation d'un nouveau style par la composition des couches des thèmes **mapbox.mapbox-streets-v5,oertz.4bf1beab**, on peut construire le style “by night” suivant : {{:geoinf16:mynightstyle.mss.zip|}}
===== 4. Composition de couches =====
==== Ex4A : Composition "server-side" ====
Dans la section précédente, la composition de couches est pilotée "une fois pour toute" côté serveur. Ci-dessous un pilotage de la composition "à la demande" côté client (et donc plus il y a de couches disponibles sur le serveur cartographique, plus il y a de combinaisons possibles).
ol3 - Ex4A - one WMS request for two layers
__TODO__
- Vérifier que la composition est bien faite côté serveur.
- Quel intérêt à utiliser cette technique ? Quels inconvénients ? Utilise-t-on tout le potentiel d'un client navigateur pour faciliter la composition "à la demande" par l'utilisateur ?
==== Ex4B : Composition "client-side" ====
Une application de cartographie en ligne se doit de permettre à l'utilisateur de personnaliser sa carte par ses choix pour la couche de référence (baselayer) et les couches à activer en superposition (overlays). Elle doit fournir la capacité de gérer la composition côté client.
ol3 - Ex4B - two WMS overlayed layers
__TODO__
- Apporter la preuve que l'assemblage s'est fait côté client.
- Analyser les paramètres WMS. Lequel représente l'indispensable capacité "server-side" pour permettre l'assemblage client-side par superposition ? Que constate-t-on aussi et plus généralement par rapport à ce paramètre ?
- Ajouter dans la table des couches les //ne_10m_admin_0_countries// et //ne_10m_lakes// du GeoServer de Boundless (//blWMS//) comme suit :
new ol.layer.Image({
title: "Countries",
source: new ol.source.ImageWMS({
url: blWMS,
params: {
VERSION: "1.0.0",
LAYERS: "ne_10m_admin_0_countries",
FORMAT: "image/png"
}
})
}),
new ol.layer.Image({
title: "Lakes",
source: new ol.source.ImageWMS({
url: blWMS,
params: {
VERSION: "1.0.0",
LAYERS: "ne_10m_lakes",
FORMAT: "image/png"
}
})
})
Visualiser le résultat. Qu'est-ce qui est "baselayer", qu'est-ce qui est "overlays" ?
- Remettre un peu d'ordre là où c'est possible.
==== Ex4C : Gestion de composition cartographique - LayerSwitcher ====
OL3 n'offre [[https://twitter.com/RemiBovard/status/525028570780139520|pour l'instant pas]] nativement de "UI manager" de composition cartographique. Néanmoins l'API offre ce qu'il faut pour concevoir son propre LayerSwitcher.
ol3 - Ex4C - MyLayerSwitcher
Choose baselayer:
Choose overlays:
__TODO__
- Analyser le code ci-dessus et identifier la principale capacité "client-side" de l'API sur laquelle repose ce LayerSwitcher.
- Adapter le code pour ajouter à l'équation la couche OSM suivante :
new ol.layer.Tile({
source: new ol.source.OSM()
})
- Ajouter la propriété ci-dessous à la couche des lacs
opacity: 0.5
==== Ex4D : Un contrôle LayerSwitcher plus souple ====
A partir des capacités offertes par l'API, la communauté de développeurs gravitant autour du core OL3 développe des //controls// parmi lesquels un LayerSwitcher un peu plus malin.
ol3 - Ex4D - A clever LayerSwitcher
__TODO__
- Comment fonctionne ce [[https://github.com/walkermatt/ol3-layerswitcher|ol3-layerswitcher]] ? (remarquez quelques nouvelles propriétés intéressantes sur ol.layer).
- Ajouter une baselayer sur un base Bing Maps comme vu à l'Ex2B (ex. Aerial)
- Ajouter un overlay basé sur la couche //ch.swisstopo.pixelkarte-pk25.metadata-kartenblatt// servie par le serveur WMS http://wms.geo.admin.ch de Swisstopo (//chWMS//, voir aussi la [[http://www.geo.admin.ch/internet/geoportal/fr/home/services/geoservices/display_services/services_wms.html|doc GeoAdmin]]) \\ \\ Illustration du résultat attendu : {{:geoinf16:screenshot2.png?200|}}
- Utiliser la couche WMS world_simple en overlay en ne visualisant que les frontières des pays (pas de remplissage des zones).
- Ajouter une baselayer MapBox comme celle avec le mapID //mapbox.pencil// (voir https://www.mapbox.com/developers/api/maps/#mapids)
- Ajouter un overlay basé sur une couche MapBox de votre cru notamment avec le 3e exercice du tutoriel MapBox/CartoCSS (voir Ex3B, avec votre couche g4cantons)
==== Ex4E : CartoCSS "à la demande" avec CartoDB ====
Jusqu'à présent, les styles CartoCSS devaient être préparés et chargés avec le Studio vers un compte MapBox. Sur le même principe que WMS/SLD, la suite montre une approche plus souple permettant de définir "à la demande" le style à appliquer sur une couche de géodonnées chargées sur un compte [[http://cartodb.com/|CartoDB]].
A partir de l'API CartoDB on peut construire une ol.layer.Tile ayant comme source la pyramide de tuiles construite par CartoDB sur la base des données de la couche des districts de Suisse https://ogo.cartodb.com/tables/g4districts98/public.
ol3 - Ex4E - On demand CartoCSS
__TODO__
- Adapter le style pour afficher les districts Vaudois différemment des autres
- Pour une solution encore plus découplée et flexible, adapter l'application pour que le style CartoCSS soit chargé asynchronnement depuis un fichier //g4districts.mss// (on proclame le suffixe mss pour Map Style Sheet).
===== 5. Couche "vector" =====
Dans les sections précédentes nous avons inséré des couches cartographiques sous la forme d'images construites par le serveur avec son moteur cartographique. Un serveur cartographique était donc nécessaire. A l'opposé, pour une couche ol.layer.Vector c'est le client qui joue le rôle de moteur cartographique pour créer la visualisation d'entités géographiques (Features en anglais).
* Télécharger l'archive {{:geoinf15:data.zip|}} et la déployer dans votre dossier de projet web.
==== Ex5A : Source de données OpenLayers.Format ====
Une couche [[http://openlayers.org/en/v3.19.1/apidoc/ol.layer.Vector.html?unstable=true|ol.layer.Vector]] peut être alimentée par une source de données au format [[http://openlayers.org/en/v3.19.1/apidoc/ol.format.GeoJSON.html?unstable=true|ol.source.GeoJSON]] (voir aussi http://geojson.org). Il existe de nombreux autres formats : [[http://openlayers.org/en/v3.19.1/apidoc/ol.format.GPX.html?unstable=true|ol.format.GPX]], [[http://openlayers.org/en/v3.19.1/apidoc/ol.format.TopoJSON.html?unstable=true|ol.format.TopoJSON]], [[http://openlayers.org/en/v3.19.1/apidoc/ol.format.KML.html?unstable=true|ol.format.KML]], ...)
ol3 - Ex5A - GeoJSON vector overlay
__TODO__
- Apporter la preuve que les données sont bien transformées en objets graphiques côté client !
- Qu'est-ce-que ce format GeoJSON http://geojson.org ? Remplacer l'URL source par
http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_day.geojson
en dézoomant un peu le cas échéant.
- Ajouter une interaction utilisateur (ex. bouton) qui affiche (ex. dans une div HTML) la liste des descriptions des séismes (propriété //title//). Ces informations sont bien sûr associées aux entités rattachées à la classe [[http://openlayers.org/en/v3.19.1/apidoc/ol.layer.Vector.html|ol.layer.Vector]]. \\ \\ Illustration du résultat attendu : {{:geoinf15:earthquakeinfo.png?nolink&300|}}\\ \\
- Enlever l'interaction et modifier l'url comme suit et modifier le type de source de données en conséquence:
url: 'http://www.visugpx.com/files/download.php?id=1416844831',
format: new ol.format.GPX()
en recentrant la carte par ici :
view: new ol.View({
center:[766225, 5908730],
zoom: 12
}),
Pourquoi cela ne fonctionne pas?
- Notons aussi le Geographic Markup Language ([[http://openlayers.org/en/v3.19.1/apidoc/ol.format.GML.html?unstable=true|ol.format.GML]]) de l'OGC qui "consiste en un ensemble de schémas XML qui permettent de construire des modèles de données spécifiques pour des domaines spécialisés, comme l'urbanisme, l'hydrologie, la géologie, et définissent un format ouvert pour l'échange de données géographiques" //(source Wikipedia)//. Voir l'exemple : ./data/fourCapitals.gml
==== Ex5B : ol.source.Vector sous la loupe ====
L'exemple ci-dessous décrit en détail ce qu'est une source de donnée [[http://openlayers.org/en/v3.19.1/apidoc/ol.source.Vector.html?unstable=true|ol.source.Vector]] pour une couche [[http://openlayers.org/en/v3.19.1/apidoc/ol.layer.Vector.html?unstable=true|ol.layer.Vector]] en montrant comment la créer et l'alimenter à partir d'un format de source de géodonnées "fait maison". En résumé, une source [[http://openlayers.org/en/v3.19.1/apidoc/ol.source.Vector.html?unstable=true|ol.source.Vector]] est composée d'entités géographiques ([[http://openlayers.org/en/v3.9.0/apidoc/ol.Feature.html?unstable=true|ol.Feature]]) chacune composée d'une géométrie ([[http://openlayers.org/en/v3.19.1/apidoc/ol.geom.html?unstable=true|ol.geom]]) et d'une liste d'attributs.
La source de données est un fichier texte formaté comme suit:
2.3332999999999999 48.866700000000002 Paris,7.4333 46.950000000000003 Bern,12.5 41.883299999999998 Rome,-3.71 40.409999999999997 Madrid
La structure de formatage est simple : c'est une suite de triplets "Longitude Latitude Nom" dont le séparateur interne est l'espace. Le séparateur entre triplets est la virgule. Chaque triplet correspond à une entité géographique. Le code ci-dessous déchiffre cette structure et transforme les triplets en ol.Feature.
ol3 - Ex5B - custom format for vector overlay
__TODO__
- Adapter le code pour une source de données similaire contenant un attribut de plus comme suit :2.3332999999999999 48.866700000000002 Paris France,7.4333 46.950000000000003 Bern Suisse,12.5 41.883299999999998 Rome Italy,-3.71 40.409999999999997 Madrid Spain
- Montrer que l'attribut a bien été pris en compte (par exemple en créant une interaction similaire à celle demandée dans l'Ex5A).
===== 6. Style "vector" =====
OpenLayers met à disposition un ensemble de classes [[http://openlayers.org/en/v3.19.1/apidoc/ol.style.html|ol.style]] permettant d'appliquer des styles aux features (entités géographiques) d'une couche [[http://openlayers.org/en/v3.19.1/apidoc/ol.layer.Vector.html|ol.vector]].
==== Ex6A : Style d'entité ====
Openlayers applique un style par défaut aux features, mais il est possible de redéfinir ce style (forme, couleur, etc.).
ol3 - Ex6A - One feature, one style
__TODO__
- Remplacer le style avec les propriétés suivantes :
var style = new ol.style.Style({
image: new ol.style.Icon({
src: "http://urbangene.heig-vd.ch/css/img/icones/marker_saved.png"
})
});
... c'est très joli, mais il semble qu'il y ait un problème ! Lequel ? Comment le résoudre ?
- Créer une entité de type //LineString// en remplaçant la propriété //geometry// comme suit :
geometry: new ol.geom.LineString([[738600, 5840171],[1938600, 6840171]])
et adapter un style adéquat utilisant l'option //lineDash// de [[http://openlayers.org/en/v3.9.0/apidoc/ol.style.Stroke.html|ol.style.Stroke]].
==== Ex6B : Style de couche ====
L'approche la plus répandue consiste à associer un style à une couche, c'est-à-dire qu'il s'applique automatiquement à toutes les entités de la couche.
ol3 - Ex6B - One layer, one style
__TODO__
- Ajouter une entité géographique de plus comme suit :
var feature2 = new ol.Feature({
geometry: new ol.geom.Point([1938600, 6840171]),
name: "The hobbits are far away...",
author: "Gandalf"
});
vecLayer.getSource().addFeature(feature2);
- Modifier la feature1 et la feature2 avec les deux //LineString// ci-dessous :
var feature1 = new ol.Feature({
geometry: new ol.geom.LineString([[738600, 6840171],[1938600, 6840171]])
});
var feature2 = new ol.Feature({
geometry: new ol.geom.LineString([[738600, 5840171],[1938600, 7840171]])
});
Adapter la représentation des lignes avec un style //highway// comme illustré ci-après :{{:geoinf15:highway.png?nolink|}}
==== Ex6C : Fonction de style ====
Plutôt que d'appliquer un style identique à toutes les entités d'une couche, il est possible d'appliquer un style différents basé sur les propriétés de chacune des entités. Pour cela, Openlayers propose de remplacer l'objet //ol.style.Style// par une fonction //ol.style.StyleFunction()//. Dans l'exemple ci-dessous on affiche une étiquette différente en fonction de la propriété "name" de chaque entité.
ol3 - Ex6C - Styling function
__TODO__
- Modifier ce qu'il faut pour visualiser des étiquettes comme suit __Gollum says: The precious is here!__ et __Gandalf says: The hobbits are far away...__
- Ajouter une couche vector utilisant le flux http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_day.geojson (cf Ex5A) et faire en sorte que les points séismes de l'hémisphère Nord apparaissent différemment de l'autre.
- Sur la base de ce même flux, proposer une représentation thématique des points séismes en exploitant leur propriété d'intensité/magnitude (voir l'attribut //mag//, voir aussi [[http://fr.wikipedia.org/wiki/Magnitude_d%27un_s%C3%A9isme#.C3.89chelle_de_Richter|Echelle de Richter]]).
{{:geoinf15:earthquakes.png?nolink|}}