405 lines
19 KiB
Markdown
405 lines
19 KiB
Markdown
|
!!! abstract "Ce que nous allons apprendre"
|
|||
|
|
|
|||
|
|
- Créer un calque qui utilise des données distantes
|
|||
|
|
- Produire une carte de chaleur (heatmap)
|
|||
|
|
- Afficher des calques en fonction du niveau de zoom
|
|||
|
|
- Afficher des données qui évoluent en temps réel
|
|||
|
|
- Utiliser un portail *open data*
|
|||
|
|
- Créditer la source des données pour respecter la licence
|
|||
|
|
|
|||
|
|
## Procédons par étapes
|
|||
|
|
|
|||
|
|
Jusqu’ici toutes les cartes que nous avons créées montrent des données
|
|||
|
|
gérées par uMap. Même lorsque nous avons utilisé les données d’un
|
|||
|
|
tableur dans le tutoriel précédent, ces données ont été *importées* sur
|
|||
|
|
le serveur uMap, où elles sont *stockées*. Si ces données sont
|
|||
|
|
modifiées, nous devons de nouveau les importer pour mettre à jour la
|
|||
|
|
carte.
|
|||
|
|
|
|||
|
|
Dans ce tutoriel nous allons apprendre comment créer une carte qui
|
|||
|
|
utilise des **données distantes**, c’est-à-dire stockées sur un autre
|
|||
|
|
serveur que le serveur uMap.
|
|||
|
|
|
|||
|
|
### 1. J’utilise des données distantes
|
|||
|
|
|
|||
|
|
Nous prenons pour ce tutoriel le thème des stations de vélo-partage à
|
|||
|
|
Paris, les fameux Vélib’, dont les données sont disponibles en open
|
|||
|
|
data.
|
|||
|
|
|
|||
|
|
#### Utiliser un portail open data
|
|||
|
|
|
|||
|
|
Commençons par observer le jeu de données « Vélib’ - Localisation et
|
|||
|
|
caractéristique des stations », disponible sur le portail open data de
|
|||
|
|
la ville de Paris :
|
|||
|
|
<https://opendata.paris.fr/explore/dataset/velib-emplacement-des-stations/>.
|
|||
|
|
|
|||
|
|
L’onglet **Informations** explique que les données « sont actualisées
|
|||
|
|
chaque minute selon la norme GBFS 1.0 ». Cette norme décrit plusieurs
|
|||
|
|
fichiers, accessibles avec l’API décrite dans l’onglet **API**, dont le
|
|||
|
|
format n’est pas compris par uMap.
|
|||
|
|
|
|||
|
|
L’onglet **Tableau** montre les données : chaque station a un nom et une
|
|||
|
|
capacité (nombre d’emplacements), ainsi qu’une position géographique.
|
|||
|
|
|
|||
|
|
L’onglet **Export** propose plusieurs formats, dont les formats
|
|||
|
|
**GeoJSON**, **KML** et **GPX**, tous trois compris par uMap. Nous
|
|||
|
|
choisissons le [format GeoJSON](https://fr.wikipedia.org/wiki/GeoJSON),
|
|||
|
|
qui permet d’exploiter tous les attributs présents dans les données.
|
|||
|
|
|
|||
|
|
Une possibilité serait de télécharger le fichier puis de l’importer dans
|
|||
|
|
uMap, comme nous l’avons fait dans le tuto précédent avec un fichier au
|
|||
|
|
format CSV. Outre les manipulations, cela impliquerait de mettre à jour
|
|||
|
|
ces données régulièrement. Nous allons plutôt configurer notre carte
|
|||
|
|
pour accéder directement aux données mises à disposition par le portail
|
|||
|
|
open data. Pour cela nous copions le lien vers le fichier : un clic
|
|||
|
|
droit ouvre un menu contextuel qui permet de **copier le lien** vers le
|
|||
|
|
fichier :
|
|||
|
|
|
|||
|
|
https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-emplacement-des-stations/exports/geojson?lang=fr&timezone=Europe%2FBerlin
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### Configurer les données distantes
|
|||
|
|
|
|||
|
|
Voyons maintenant comment utiliser ce lien dans uMap. Pour cela nous
|
|||
|
|
créons un nouveau calque et ouvrons, dans les Propriétés du calque,
|
|||
|
|
l’onglet **Données distantes**. Les informations à fournir sont les
|
|||
|
|
suivantes :
|
|||
|
|
|
|||
|
|
- **URL** : nous collons ici le lien vers le fichier copié
|
|||
|
|
précédemment.
|
|||
|
|
- **Format** : nous devons sélectionner le format, ici **geojson**
|
|||
|
|
- **Licence** : ODbL comme indiqué sur la page d’export du portail
|
|||
|
|
open data
|
|||
|
|
|
|||
|
|
Le bouton **Vérifier l’URL** permet de tester l’accès au fichier depuis
|
|||
|
|
uMap, et de vérifier que le format choisi correspond bien aux données.
|
|||
|
|
Les données sont alors affichées sur la carte.
|
|||
|
|
|
|||
|
|
#### Proxy ou pas proxy ?
|
|||
|
|
|
|||
|
|
Si cela ne fonctionne pas (uMap affiche un bandeau qui indique «
|
|||
|
|
Problème dans la réponse du serveur »), il est probable que le serveur
|
|||
|
|
sur lequel le fichier est stocké n’autorise pas l’accès au fichier
|
|||
|
|
depuis un service tiers.
|
|||
|
|
|
|||
|
|
!!! note
|
|||
|
|
|
|||
|
|
Il s’agit du mécanisme CORS, décrit dans l’article
|
|||
|
|
Wikipédia [Cross-origin ressource
|
|||
|
|
sharing](https://fr.wikipedia.org/wiki/Cross-origin_resource_sharing).
|
|||
|
|
|
|||
|
|
uMap permet de contourner cette contrainte en faisant transiter le
|
|||
|
|
fichier par le serveur uMap, grâce à l’option **Avec proxy** qu’il
|
|||
|
|
convient alors d’activer. Cette option est associée au menu déroulant
|
|||
|
|
**Cacher la requête avec proxy**, qui permet au serveur uMap de
|
|||
|
|
conserver le fichier afin de ne pas le récupérer à chaque affichage de
|
|||
|
|
la carte. La durée la plus longue (1 jour) serait ici adaptée.
|
|||
|
|
|
|||
|
|
#### Au sujet de la licence
|
|||
|
|
|
|||
|
|
Le fichier des emplacements de stations Vélib’ est publié sous la
|
|||
|
|
[licence ODbL](https://opendatacommons.org/licenses/odbl/). Celle-ci
|
|||
|
|
exige que le producteur des données soit crédité lors de leur
|
|||
|
|
utilisation. Les informations sur le portail open data indique que ce
|
|||
|
|
producteur est « Autolib Velib Métropole ». Il convient donc de le citer
|
|||
|
|
dans les **Crédits** de la carte, un onglet du menu *Propriétés de la
|
|||
|
|
carte*.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### Afficher le nom et la capacité des stations
|
|||
|
|
|
|||
|
|
Afin d’afficher le nom et la capacité de chaque station dans une
|
|||
|
|
infobulle, nous devons déterminer les clefs permettant d’accéder à ces
|
|||
|
|
informations. Pour cela il nous faut observer le fichier GeoJSON.
|
|||
|
|
|
|||
|
|
Nous téléchargeons ce fichier depuis l’onglet Export du portail open
|
|||
|
|
data, ou collons le lien copié précédemment dans la barre de navigation
|
|||
|
|
du navigateur. Soit le fichier est directement affiché dans le
|
|||
|
|
navigateur, soit il est téléchargé : une possibilité consiste alors à
|
|||
|
|
l’ouvrir dans un éditeur de texte, ou à le déposer dans la fenêtre du
|
|||
|
|
navigateur.
|
|||
|
|
|
|||
|
|
Dans le bloc `properties` de chaque élément, nous observons plusieurs
|
|||
|
|
associations clef-valeur : la propriété **name** contient le nom de la
|
|||
|
|
station, **capacity** contient le nombre d’emplacements. Ces propriétés
|
|||
|
|
correspondent à nos entêtes de colonnes d’un fichier CSV (cf. tuto
|
|||
|
|
précédent).
|
|||
|
|
|
|||
|
|
Nous pouvons alors configurer le **Gabarit de la popup** pour afficher
|
|||
|
|
ces informations dans l’infobulle de chaque station, comme nous l’avons
|
|||
|
|
vu dans le [tuto précédent](9-map-from-spreadsheet.md).
|
|||
|
|
|
|||
|
|
Par exemple :
|
|||
|
|
|
|||
|
|
# {name}
|
|||
|
|
{capacity} emplacements
|
|||
|
|
|
|||
|
|
### 2. Je combine deux calques pour les mêmes données
|
|||
|
|
|
|||
|
|
Il y a beaucoup de stations Vélib’ et la carte est un peu dense à
|
|||
|
|
l’échelle de Paris. À cette échelle il serait plus intéressant d’avoir
|
|||
|
|
une vue d’ensemble de la répartition de l’offre Vélib’ sur la capitale
|
|||
|
|
et les communes voisines.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### Produire une carte de chaleur ou « Heatmap »
|
|||
|
|
|
|||
|
|
uMap permet de présenter les données d’un calque sous plusieurs formes,
|
|||
|
|
avec le menu déroulant **Type de calque** dans le menu *Propriétés du
|
|||
|
|
calque*. Les différents types de calques sont :
|
|||
|
|
|
|||
|
|
- **Par défaut** : chaque donnée est affichée individuellement.
|
|||
|
|
- **Avec cluster** : les points proches sont regroupés en un seul
|
|||
|
|
cercle.
|
|||
|
|
- **Heatmap** : les données sont représentées sous forme de *carte de
|
|||
|
|
chaleur*.
|
|||
|
|
- **Cloroplèthe** : cet affichage est adapté aux polygones, et permet
|
|||
|
|
de graduer leur couleur.
|
|||
|
|
|
|||
|
|
Les types *Avec cluster* et *Heatmap* sont plutôt adaptés aux calques
|
|||
|
|
contenant uniquement des points. Lorsqu’on choisit un de ces modes, un
|
|||
|
|
onglet de configuration apparaît. Pour le type *Heatmap*, l’onglet
|
|||
|
|
**Heatmap: paramètres** permet d’ajuster l’intensité – ou *chaleur* – de
|
|||
|
|
la carte (du bleu glacial au rouge brûlant), et de sélectionner une
|
|||
|
|
propriété pour évaluer cette *chaleur*. Celle-ci doit correspondre à une
|
|||
|
|
propriété de nos données contenant des valeurs numériques. Si aucune
|
|||
|
|
propriété n’est définie, chaque point a la même valeur et seule la
|
|||
|
|
densité géographique des points influe sur la *heatmap*.
|
|||
|
|
|
|||
|
|
Notre fichier de stations contient justement la propriété `capacity`,
|
|||
|
|
qui correspond au nombre d’emplacements de chaque station – un bon
|
|||
|
|
critère pour représenter l’offre de vélos en libre-service. Quant au
|
|||
|
|
**Rayon de heatmap**, un curseur permet de l’ajuster avec effet immédiat
|
|||
|
|
sur la carte. Il est judicieux de tester ce rayon à différents niveaux
|
|||
|
|
de zoom de la carte, afin que la carte révèle bien les données.
|
|||
|
|
|
|||
|
|
#### Dupliquer le calque
|
|||
|
|
|
|||
|
|
Le type d’affichage d’un calque s’applique quel que soit le niveau de
|
|||
|
|
zoom. Or aux niveaux de zooms élevés, à l’échelle du quartier, il est
|
|||
|
|
plus intéressant de montrer les stations individuelles que la carte de
|
|||
|
|
chaleur. Nous allons combiner les 2 représentations en créant 2 calques
|
|||
|
|
qui utilisent les mêmes données, l’un affichant les stations
|
|||
|
|
individuelles, l’autre sous forme de Heatmap. L’astuce consiste ensuite
|
|||
|
|
à activer ou désactiver chaque calque en fonction du niveau de zoom.
|
|||
|
|
|
|||
|
|
Procédons par étapes :
|
|||
|
|
|
|||
|
|
1. Dupliquons notre calque avec l’opération **Cloner** disponible dans
|
|||
|
|
l’onglet **Opérations avancées** du panneau Propriétés du calque.
|
|||
|
|
2. Le panneau Propriétés du nouveau calque est alors affiché :
|
|||
|
|
renommons ce calque, par exemple « Heatmap stations Vélib’ ».
|
|||
|
|
3. Changeons le type de calque pour **Heatmap**, l’onglet **Heatmap:
|
|||
|
|
paramètres** apparaît.
|
|||
|
|
4. Dans cet onglet, saisissons le nom de la propriété – `capacity` – et
|
|||
|
|
ajustons le **rayon de heatmap** (une valeur autour de 30 fonctionne
|
|||
|
|
bien pour ce jeu de données)
|
|||
|
|
5. Dans l’onglet **Données distantes**, configurons le calque pour
|
|||
|
|
qu’il s’affiche **jusqu’au zoom** 15.
|
|||
|
|
6. De la même manière, configurons le calque initial pour qu’il
|
|||
|
|
s’affiche **à partir du zoom** 15.
|
|||
|
|
|
|||
|
|
Nous faisons ici le choix de superposer, au zoom 15, la heatmap aux
|
|||
|
|
stations individuelles. Cela produit une transition entre les 2 modes de
|
|||
|
|
représentation, et permet de repérer les stations avec un grand nombre
|
|||
|
|
d’emplacements.
|
|||
|
|
|
|||
|
|
Notez que nous n’avons pas eu besoin de préciser l’URL des données
|
|||
|
|
distantes et leur format : ces paramètres ont été conservés lors de la
|
|||
|
|
duplication du calque.
|
|||
|
|
|
|||
|
|
### 3. J’utilise des données dynamiques
|
|||
|
|
|
|||
|
|
Un autre jeu de données du portail open data s’intitule « Vélib - Vélos
|
|||
|
|
et bornes - Disponibilité temps réel » :
|
|||
|
|
<https://opendata.paris.fr/explore/dataset/velib-disponibilite-en-temps-reel/>.
|
|||
|
|
|
|||
|
|
Nous pouvons utiliser ces données *en temps réel* – en réalité avec un
|
|||
|
|
léger différé – pour alimenter notre carte uMap, et afficher le nombre
|
|||
|
|
de places et de vélos disponibles. La procédure est la même que
|
|||
|
|
ci-dessus, à une nuance près : l’option **Dynamique** de l’onglet
|
|||
|
|
**Données distantes** doit être activée. Elle indique à uMap de
|
|||
|
|
récupérer les données à chaque affichage de la carte, c’est-à-dire à
|
|||
|
|
chaque fois que la carte est déplacée, zoomée ou dézoomée. Pour autant,
|
|||
|
|
ces données ne seront pas automatiquement mises à jour par uMap à un
|
|||
|
|
intervalle de temps régulier : c’est à l’utilisateur de rafraîchir la
|
|||
|
|
page web ou de déplacer la carte.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Il reste à
|
|||
|
|
modifier notre gabarit de popup pour afficher les disponibilités en
|
|||
|
|
temps réel. Pour identifier le nom des propriétés, nous pouvons utiliser
|
|||
|
|
l’onglet **API** sur le portail open data : le panneau **Résultats**
|
|||
|
|
montre un extrait des données avec toutes leurs propriétés. Ces
|
|||
|
|
propriétés sont les mêmes que pour l’export GeoJSON. Voici un exemple
|
|||
|
|
possible de gabarit de popup :
|
|||
|
|
|
|||
|
|
# {name}
|
|||
|
|
{capacity} emplacements dont {numdocksavailable} libres
|
|||
|
|
{numbikesavailable} vélos disponibles dont {ebike} VAE
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### Filtrer les données à la source
|
|||
|
|
|
|||
|
|
Le panneau Résultats dans l’onglet **API** nous montre l’existence de la
|
|||
|
|
propriété `is_installed`. Celle-ci permet de détecter des stations qui
|
|||
|
|
ne sont pas en service, que nous ne souhaitons pas afficher sur notre
|
|||
|
|
carte.
|
|||
|
|
|
|||
|
|
Le panneau **Requête pour l’appel API** permet de générer une requête,
|
|||
|
|
affichée sous ce panneau (**URL de l’appel API**), et de visualiser les
|
|||
|
|
données produites par cette requête dans le panneau **Résultats**. Il
|
|||
|
|
permet également d’ajouter des paramètres à la requête, pour filtrer les
|
|||
|
|
données produites. Le paramètre **refine** permet de filtrer les données
|
|||
|
|
en fonction de la valeur d’une ou plusieurs propriétés. Si nous
|
|||
|
|
indiquons `is_installed` pour le nom de la propriété et `NON` pour la
|
|||
|
|
valeur, nous pouvons voir le nombre de stations qui ne sont pas en
|
|||
|
|
service, et que nous ne voulons pas intégrer à notre carte.
|
|||
|
|
|
|||
|
|
Les données produites à l’aide cet onglet **API** sont au format GBFS,
|
|||
|
|
qui n’est pas connu de uMap. Les requêtes d’export au format GeoJSON
|
|||
|
|
acceptent les mêmes paramètres. Pour produire les données filtrées au
|
|||
|
|
format GeoJSON, nous devons donc éditer la requête *à la main*.
|
|||
|
|
Procédons par étapes *un peu geek* :
|
|||
|
|
|
|||
|
|
1. Saisir `is_installed` et `OUI` dans le champ **refine**
|
|||
|
|
2. Supprimer la valeur du champ `limit`, car nous ne voulons pas
|
|||
|
|
*limiter* la réponse de la requête à 20 stations.
|
|||
|
|
3. Observons la requête générée :
|
|||
|
|
`/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/records?refine=is_installed%3AOUI`,
|
|||
|
|
elle se compose de 3 sections :
|
|||
|
|
- l’URL de base, jusqu’au dernier caractère **`/`**
|
|||
|
|
- le **endpoint** `records` suivi du caractère **`?`**
|
|||
|
|
- le paramètre `refine=is_installed%3AOUI` (`%3A` est l’*encodage*
|
|||
|
|
du caractère **`:`**)
|
|||
|
|
4. Prenons la requête générée pour l’export GeoJSON :
|
|||
|
|
`https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/geojson?lang=fr&timezone=Europe%2FBerlin`,
|
|||
|
|
elle se compose des mêmes sections :
|
|||
|
|
- l’URL de base :
|
|||
|
|
`https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/`
|
|||
|
|
- le endpoint `geojson?`
|
|||
|
|
- la liste de paramètres `lang=fr&timezone=Europe%2FBerlin` (`%2F`
|
|||
|
|
est l’encodage du caractère **`&`** qui permet de séparer
|
|||
|
|
plusieurs paramètres)
|
|||
|
|
5. Nous pouvons combiner l’URL et le endpoint de la requête GeoJSON,
|
|||
|
|
suivi du paramètre `refine=is_installed%3AOUI` (les paramètres
|
|||
|
|
`lang` et `timezone` ne sont ici pas utiles) :
|
|||
|
|
|
|||
|
|
|
|||
|
|
`https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/geojson?refine=is_installed%3AOUI`
|
|||
|
|
|
|||
|
|
Utiliser cette requête comme URL des données distantes de notre calque
|
|||
|
|
**Stations Vélib’** permet de n’afficher que les stations en service.
|
|||
|
|
|
|||
|
|
Notez que pouvons aussi utiliser le paramètre `exclude` pour exclure les
|
|||
|
|
stations dont la propriété `is_installed` a la valeur `NON`. Nous
|
|||
|
|
pouvons utiliser ce même mécanisme pour exclure les stations qui n’ont
|
|||
|
|
aucun vélo disponible :
|
|||
|
|
|
|||
|
|
https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/geojson?exclude=is_installed%3ANON&exclude=numbikesavailable%3A0
|
|||
|
|
|
|||
|
|
### 4. J’injecte des paramètres dans la requête
|
|||
|
|
|
|||
|
|
uMap permet d’injecter dans une requête des paramètres, avec la syntaxe
|
|||
|
|
`{paramX}`. Ces paramètres dépendent de l’état de la carte au moment de
|
|||
|
|
l’envoi de la requête :
|
|||
|
|
|
|||
|
|
- les coordonnées du centre de la carte : {lat} et {lng}
|
|||
|
|
- la *bounding_box* de la carte : {bbox} ou {west}, {south}, {east} et
|
|||
|
|
{north}
|
|||
|
|
- le niveau de zoom : {zoom}
|
|||
|
|
|
|||
|
|
Le portail open data peut prendre en compte certains de ces paramètres
|
|||
|
|
pour affiner la requête. Notre objectif est ici de récupérer la
|
|||
|
|
disponibilité des stations se trouvant **dans la partie visible de la
|
|||
|
|
carte**, c’est-à-dire dans la *bounding_box*. Cela permet de réduire le
|
|||
|
|
volume de données transférées, et de les afficher plus rapidement.
|
|||
|
|
|
|||
|
|
#### J’utilise la console d’API de la plateforme open data
|
|||
|
|
|
|||
|
|
L’onglet API du jeu de données permet d’accéder à la **console d’API
|
|||
|
|
complète**. Nous choisissons, dans la section Dataset, le *endpoint*
|
|||
|
|
**Export a dataset**.
|
|||
|
|
|
|||
|
|
|
|||
|
|
Apparaît alors un formulaire où nous pouvons renseigner les différents
|
|||
|
|
paramètres :
|
|||
|
|
|
|||
|
|
- **dataset_id** est l’identifiant du jeu de données :
|
|||
|
|
`velib-disponibilite-en-temps-reel`
|
|||
|
|
- pour le **format** nous sélectionnons `geojson`
|
|||
|
|
- nous pouvons à nouveau filtrer les stations en service avec le
|
|||
|
|
paramètre **refine** : `is_installed:OUI`
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Définissons le paramètre **where** avec la fonction `in_bbox()` (voir la
|
|||
|
|
[documentation
|
|||
|
|
OpenDataSoft](https://help.opendatasoft.com/apis/ods-explore-v2/#section/ODSQL-predicates/in_bbox()))
|
|||
|
|
et – pour l’instant – des latitudes et longitudes fixes (quelque part à
|
|||
|
|
Paris) :
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
**coordonnees_geo** est le nom du champ contenant la géométrie dans les
|
|||
|
|
données d’origine, que l’on peut trouver en les exportant dans un format
|
|||
|
|
autre que GeoJSON.
|
|||
|
|
|
|||
|
|
Testons maintenant que la requête fonctionne en cliquant sur **Execute**
|
|||
|
|
: le code de réponse 200 indique que la requête a fonctionné, et il est
|
|||
|
|
possible de télécharger le fichier résultant.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### Je dynamise la requête
|
|||
|
|
|
|||
|
|
Modifions maintenant notre requête *statique* (tous les paramètres sont
|
|||
|
|
fixes) pour la rendre *dynamique*, en remplaçant les coordonnées de la
|
|||
|
|
bounding_box par les paramètres qui seront injectés par uMap. Nous
|
|||
|
|
n’utilisons pas ici le paramètre `{bbox}`, car l’ordre des valeurs ne
|
|||
|
|
correspond pas à celui attendu par l’API open data. La fonction s’écrit
|
|||
|
|
alors :
|
|||
|
|
|
|||
|
|
in_bbox(coordonnees_geo,{south},{west},{north},{east})
|
|||
|
|
|
|||
|
|
ce qui donne avec l’encodage :
|
|||
|
|
|
|||
|
|
in_bbox%28coordonnees_geo%2C{south}%2C{west}%2C{north}9%2C{east}%29
|
|||
|
|
|
|||
|
|
La requête encodée complète est donc :
|
|||
|
|
|
|||
|
|
https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/geojson?where=in_bbox%28coordonnees_geo%2C{south}%2C{west}%2C{north}9%2C{east}%29&limit=-1&refine=is_installed%3AOUI
|
|||
|
|
|
|||
|
|
Il ne reste plus qu’à utiliser cette requête comme URL pour nos données
|
|||
|
|
distantes.
|
|||
|
|
|
|||
|
|
Notez qu’il n’est pas nécessaire d’utiliser la forme encodée, car uMap
|
|||
|
|
procédera à l’encodage. L’URL peut donc être plus lisible :
|
|||
|
|
|
|||
|
|
https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/velib-disponibilite-en-temps-reel/exports/geojson?where=in_bbox(coordonnees_geo,{south},{west},{north},{east})&limit=-1&refine=is_installed:OUI
|
|||
|
|
|
|||
|
|
## Faisons le point
|
|||
|
|
|
|||
|
|
La carte produite pour ce tuto est visible ici :
|
|||
|
|
<http://u.osmfr.org/m/1051915/>
|
|||
|
|
|
|||
|
|
Nous avons vu comment **exploiter des données open data** sans les
|
|||
|
|
télécharger, ce qui permet que notre carte reste à jour (à condition
|
|||
|
|
bien sûr que les données soient actualisées par leur producteur). Nous
|
|||
|
|
avons également vu comment **optimiser la requête** en injectant la
|
|||
|
|
*bounding box* de la partie visible de la carte.
|
|||
|
|
|
|||
|
|
D’autres sites mettent à disposition des données via une API, l’enjeu
|
|||
|
|
est alors de s’approprier la syntaxe des requêtes en lisant la
|
|||
|
|
documentation et testant les requêtes.
|
|||
|
|
|
|||
|
|
|
|||
|
|
??? info "Licence"
|
|||
|
|
|
|||
|
|
Travail initié par Antoine Riche sur [Carto’Cité](https://wiki.cartocite.fr/doku.php?id=umap:10_-_j_integre_des_donnees_distantes) sous licence [CC-BY-SA 4](https://creativecommons.org/licenses/by-sa/4.0/deed.fr).
|