La traduction française de cette plateforme a été créée avec l’aide de l’IA. Si vous remarquez des erreurs, les contributions de la communauté pour l’améliorer sont les bienvenues ; veuillez nous envoyer un e-mail à platform@digitizetheplanet.org.

Commencer

Découvrez comment intégrer API v2 pour les flux de travail de données en zone protégée.

Ce guide vous aide à mettre en œuvre le cas d'utilisation principal du Digitize API : importer des données sur les aires protégées et les maintenir à jour.

Importation initiale des zones protégées concernées

Pour commencer, récupérez la liste des zones protégées. Si vous souhaitez utiliser notre ensemble de données complet, vous pouvez le récupérer via :

GET /api/v2/protected-areas

Ce point de terminaison renvoie un ensemble par défaut de champs et de données paginées. Si cette réponse par défaut inclut tout ce dont vous avez besoin, vous êtes prêt. Si vous avez besoin de plus de détails, vous avez deux options :

  1. Étendez la réponse via le paramètre 'fields'. Voir le documentation interactive pour plus d'informations.
  2. Réduisez la requête initiale pour récupérer uniquement les UUID (à l'aide de « fields=uuid »), puis récupérez tous les détails à l'aide du point de terminaison individuel : GET /api/v2/protected-areas/{uuid}
    Ce point de terminaison prend également en charge le paramètre « fields » pour personnaliser la réponse.

Si vous n'avez besoin que d'un sous-ensemble spécifique de données, vous pouvez appliquer des filtres, par exemple pour récupérer uniquement les parcs nationaux d'Allemagne. Pour ce faire, récupérez d'abord les ID de filtre pertinents :

  1. Obtenez le category_id pour les parcs nationaux (par exemple, 1) : GET /api/v2/protected-area-categories
  2. Obtenez le country_id pour l'Allemagne (par exemple, 1) : GET /api/v2/countries
  3. Utilisez les deux filtres pour obtenir l'ensemble de données ciblé : GET /api/v2/protected-areas?category_id=1&country_id=1

Vérification des mises à jour pour les zones nouvelles, modifiées et supprimées

Données nouvelles et mises à jour

Pour maintenir vos données à jour, utilisez le updated_after paramètre : GET /api/v2/protected-areas?updated_after=YYYY-MM-DD

Cela renverra uniquement les zones qui ont été mises à jour depuis la date indiquée.

Ce paramètre est également pris en charge sur les points de terminaison pour les données sur la faune et les organisations.

Données supprimées

Pour suivre les suppressions, utilisez notre point de terminaison dédié : GET /api/v2/protected-areas/deleted
Vous pouvez filtrer par date spécifique en utilisant : GET /api/v2/protected-areas/deleted?date=YYYY-MM-DD (renvoie les suppressions après la date indiquée ; utilisez le jour précédent pour inclure les suppressions à partir de cette date).

Détails de la synchronisation des fermetures et des avis

Pour GET /api/v2/closures-and-notices, commencez par une récupération unique de tous les enregistrements pertinents pour votre application. Utilisez le paramètre fields pour contrôler les champs inclus dans la réponse et réduire la taille de la charge utile.

Le point de terminaison de la liste renvoie par défaut les enregistrements actuels et à venir. Si votre synchronisation initiale doit également inclure des enregistrements expirés, ajoutez des filtres de date ou de statut correspondants.

GET /api/v2/closures-and-notices?fields=uuid,name,type,reason_id,start_on,end_on,daytime_start,daytime_end,activity_ids,source_id

Pour les synchronisations incrémentielles ultérieures, les enregistrements de demande ont été modifiés depuis votre dernière synchronisation réussie. Utilisez le paramètre updated_after pour cela : GET /api/v2/closures-and-notices?updated_after=YYYY-MM-DD

Si vous stockez des enregistrements localement, vous devez calculer vous-même le statut actuel, à venir ou expiré à partir de start_on, end_on, daytime_start et daytime_end. Respectez la date et l’heure locales pertinentes.

Important :

Les enregistrements peuvent expirer avec le temps, même si l'enregistrement lui-même n'a pas été mis à jour. Les clients qui s'appuient sur updated_after doivent réévaluer localement les enregistrements stockés par rapport à la date et à l'heure actuelles.

Les consommateurs qui ne souhaitent pas calculer eux-mêmes l'état peuvent utiliser des filtres côté serveur tels que active_on, status, les filtres de plage de dates starts_after, starts_before, ends_after et ends_before, ainsi que bbox, type, source_id, source_kind, status0 et status1.

Conseils supplémentaires

  • Utilisez le filtrage de champs (par exemple, ?fields=id,name,geometry pour réduire les charges utiles et améliorer les performances.
  • Soyez attentif à l'utilisation équitable : même si nous n'imposons pas de limites de débit strictes, nous demandons à tous les utilisateurs de faire des demandes de manière responsable et d'éviter toute utilisation excessive ou abusive.
  • Abonnez-vous à notre journal des modifications pour les modifications de schéma et les mises à jour de version.

Si vous avez des questions ou avez besoin d'aide, n'hésitez pas à nous contacter à tout moment.