brgm / hubeau Goto Github PK
View Code? Open in Web Editor NEWHub'Eau, la plateforme pour manipuler facilement les données ouvertes sur l'eau
Hub'Eau, la plateforme pour manipuler facilement les données ouvertes sur l'eau
Bonjour,
lorsqu'on appelle les informations d'une station Hydro à l'aide du endpoint 'hydrometrie/referentiel/stations', si jamais on choisit de n'inclure que certains champs dont les champs 'longitude_station' et 'latitude_station', ceux-ci sont null dans la réponse alors qu'ils sont bien initialisés si jamais on ne filtre pas les champs.
Les champs longitude_station et latitude_station sont null
Exemple sans filtre sur la même station : https://hubeau.eaufrance.fr/api/v1/hydrometrie/referentiel/stations?code_station=1011000101&en_service=true&fields=&format=json
Les champs longitude_station et latitude_station sont bien initialisés
Ce problème concerne peut-être d'autres champs, je n'ai pas testé toutes les permutations possibles
Nous utilisons ces API pour alimenter des piézomètres de contrôles pour certains clients. Seulement, certains sites n'ont pas de suivis réguliers. Des ruptures sont présentes dans les coures et de nombreux points initiaux sont créés. Cette information n'est pas présente dans les retours des API ce qui fausse complètement la valorisation des chroniques. Voici un exemple avec rupture: 03514X0081/PZ
https://ades.eaufrance.fr/Fiche/PtEau?code=03514X0081/PZ#mesures_graphiques
et l'appel sur Hubeau:
https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/chroniques?code_bss=03514X0081%2FPZ&size=20&sort=desc
Merci d'avance d'ajouter cette information dans les retours Json
Lors de l'interrogation de la méthode observations_tr.csv, les dates renvoyées sont au format aaaa-mm-jj (2018-07-19) alors que la version JSON de l'API renvoie 2018-07-19T11:30:00Z.
Il manque toute la partie hh:mm:ss dans la réponse CSV.
En lien avec l'issue précédente, préférer les dates au format 2018-07-19T13:30:00+02:00 (avec le fuseau horaire, comme ça pas d'ambigüité).
Bonjour,
Je souhaiterais générer un client Java à partir des spéfications Swagger.
Apparemment il y aurait une erreur dans le fichier xml de description des services :
http://hubeau.eaufrance.fr/api/vbeta/hydrometrie/api-docs
Julien
La requête présentée en exemple:
Recherche de tous les indices biologiques concernant les diatomées (dont le code SANDRE support = 13) :
https://hubeau.eaufrance.fr/api/vbeta/hydrobio/indices?size=10&code_support=13
Le résultat concerne
Bonjour,
serait il possible d'intégrer dans le requêtage de l'API observations_tr un notion de pas de temps de la données que nous souhaiterions télécharger?
En effet, les données peuvent être vite volumineuse au pas 5mn si le nb de code_station est important.
La limite de 20 000 est vite atteinte, surtout quand on récupère l'ensemble des stations ...
Mon étude est au pas 30mn donc il y a 6 fois trop de données dans mon JSON
Je pourrais être plus efficace dans mon appel à l'API et en diminuer le nombre de requêtes.
Merci et m'avoir lu !
Bonne journée
Mathieu (edf)
Bonjour,
nous utilisons l'API Qualité des cours d'eau et nous avons quelques retours d'utilisateurs quant aux données disponibles. Par exemple, les 2 stations 04146850 et 06750945 sont bien disponibles sur le Sandre:
http://www.sandre.eaufrance.fr/urn.php?urn=urn:sandre:donnees:StationMesureEauxSurface:FRA:code:06750945:::::html
http://www.sandre.eaufrance.fr/urn.php?urn=urn:sandre:donnees:StationMesureEauxSurface:FRA:code:04146850:::::html
Mais nous n'en trouvons qu'une sur Hubeau. La station n'est pas disponible:
https://hubeau.eaufrance.fr/api/v1/qualite_rivieres/station_pc?code_station=06750945&size=20&exact_count=true&format=json
Est ce qu'il y a une raison ?
Bonjour,
Pour information, il y a une erreur lors de la récupération de la documentation swagger à partir de cette adresse :
https://hubeau.eaufrance.fr/api/v1/hydrometrie/api-docs
L'accès via Swagger UI (https://petstore.swagger.io/) fonctionne, mais avec une petite erreur.
Bonne journée
Bonjour,
Est-ce que quelqu'un saurait quelle requête nous devons effectuer pour récupérer les données d'un poisson, par exemple l'Ablette, en donnant seulement son nom ?
Pour le moment je n'arrive que à récupérer cela en fonction du code_espece_poisson avec la requête suivante :
https://hubeau.eaufrance.fr/api/v0/etat_piscicole/poissons?code_espece_poisson=ABL&size=20
Merci par avance si vous arrivez à m'expliquer comment faire.
Cordialement
Justine Dugast
Bonjour,
En réalisant des tests sur l'API Hydro, il s'avère que le propriété next (lors de la pagination des appels) est remplie même si on arrive à la dernière page.
Bonne journée
Bonjour,
Nous développons actuellement une plateforme de prévision des étiages (projet PREMHYCE) et nous souhaiterions utiliser l'API Hydrométrie pour récupérer les observations de la dernière semaine écoulée au pas de temps journalier.
Ceci nous permettra de corriger les erreurs de nos modèles hydrologiques sur les derniers pas de temps en assimilant la donnée observée.
Dans le ticket #9, vous parlez du paramètre timestep qui permet d'introduire une notion de pas de temps dans les requêtes.
Comment ce paramètre fonctionne-t-il?
Si timestep = 60, ne retient-on qu'une valeur par heure ou fait-on une moyenne horaire à partir d'une donnée à pas de temps plus fin (5 min par exemple)?
Ce paramètre étant limité à 60, y a-t-il une routine permettant de passer d'un débit à pas de temps variable (ou fixe mais fin) à un débit journalier?
Si oui, quelle est la convention temporelle retenue dans ce cas pour le calcul du débit journalier?
Merci d'avance de vos réponses.
Bien cordialement
François
Actuellement, les données de l'API semblent moins complètes en nombre et en millésime que les données disponibles sur http://www.data.eaufrance.fr/jdd/e315633f-0930-41e8-a1c4-61fb2303039c
A titre d'exemple sur la région Pays de la Loire, on trouvera 6872 ouvrages avec l'API contre 8508 sur data.eaufrance.
Les millésimes de chroniques de l'API s'arrêtent à 2016 alors que l'AELB fournit des données de 2019.
Est-ce lié à la version bêta ou retrouvera-t-on vraiment une cohérence des données disponibles en téléchargement ?
Bonjour,
Il y a une station qui comporte 28865 analyses hors lorsque nous arrivons à cette URL dans l'attribut next :
https://hubeau.eaufrance.fr/api/v1/qualite_rivieres/analyse_pc?format=json&code_station=04180100&fields=code_station,libelle_station,code_support,libelle_support,code_fraction,libelle_fraction,code_methode_analyse,nom_methode_analyse,code_methode_extraction,nom_methode_extraction,code_accreditation,mnemo_accreditation,code_parametre,libelle_parametre,date_analyse,heure_analyse,date_prelevement,heure_prelevement,resultat,code_unite,symbole_unite,code_remarque,mnemo_remarque,code_insitu,libelle_insitu,code_difficulte_analyse,mnemo_difficulte_analyse,limite_detection,limite_quantification,limite_saturation,agrement,code_statut,mnemo_statut,code_qualification,libelle_qualification,commentaires_analyse,commentaires_resultat_analyse,code_reseau,nom_reseau,code_producteur,nom_producteur,code_preleveur,nom_preleveur,code_laboratoire,nom_laboratoire&page=41&size=500
une erreur apparait !
{ "code": "InvalidRequest", "message": "Invalid analysePc request", "field_errors": [ { "code": "ValidatePageDepth", "message": "Please refine your query. The multiplication of
page*
size parameters can not be more than 20000", "field": "page" } ] }
Comment peut-on résoudre ce problème ?
Merci d'avance
DEFAY Guillaume
Bonjour,
Il semble qu'il y ait un problème avec le retour de l'appel suivant (pour une station à une date donnée) :
https://hubeau.eaufrance.fr/api/v1/qualite_rivieres/condition_environnementale_pc?code_station=04057000&date_debut_prelevement=2015-09-17&date_fin_prelevement=2015-09-17&format=json
La première page contient 26999 items dans data, et les mêmes paramètres qui sont répétées plus de 1000 fois (exemple : "code_parametre":"1418") .
En outre, le count annonce 1274 résultats, là aussi cela semble incohérent, le nombre de paramètres mesurés est rarement supérieur à 30 pour les conditions environnementales.
Merci de bien vouloir corriger cela.
Cordialement.
Bonjour,
nous utilisons les API pour la récupération des chroniques et des chroniques temps réel et nous avons repéré un problème pour la récupération des informations de continuités. Voici un cas précis sur un piézo géré par la DR Bretagne: le 02465X0061/F.
Le 03/05/2012, il y a un point initial que l'on voit sur les chroniques ADES (image 1 - https://ades.eaufrance.fr/Fiche/PtEau?code=02465X0061/F#mesures_graphiques).
Nous avons récupéré les chroniques via Hubeau et nous n'avons pas retrouvé cette indication ce qui génère une continuité dans la chronique. (image 2).
De plus, en consultant le visualiseur en ligne, la continuité n'est pas présente (image 3 - https://hubeau.eaufrance.fr/sites/default/files/api/demo/piezo/piezo.htm?code_dpt=35&code_bss=03884X0021%2FTF1PR).
Pourriez vous regarder d'où vient le problème ?
Merci d'avance
L'API hydrobiologie ne semble pas interroger Naïade V0 qui contient les données hydrobiologie hors poisson.
ex https://hubeau.eaufrance.fr/api/vbeta/hydrobio/taxons?code_station_hydrobio=04004100
des données (brutes, formats d'échanges .csv et .xls) existent dans Naïade V0
http://naiadesv0.eaufrance.fr/donnees
mais sont absentes de la version en cours de Naïade
http://www.naiades.eaufrance.fr/acces-donnees#/hydrobiologie/resultats?debut=01-01-2001&fin=17-09-2020&stations=04004100
Bonjour,
sur l'api, lorsque je selectionne par exemple les A*, j'ai dans mes résultats des NA.
Ce sont de véritables ### NA et dans ce cas, je peux les ignorer et donc inutiles de les requêter ou est ce que ce sont des A* dont je n'ai pas l'identifiant et que je ne peux donc pas exploiter ?
merci et bonne journée
Mathieu
Bonjour,
Selon la documentation :
Les attributs prev et next (définis à null si il n'y a pas de page précédente et/ou suivante) sont
disponibles dans l'URL de la réponse pour éviter d'avoir à calculer les pages précédentes et/ou
suivantes.
Or, même quand l'attribut data
est vide l'URL next
est générée, voir par exemple :
http://hubeau.eaufrance.fr/api/v1/qualite_rivieres/analyse_pc?code_parametre=1340&date_debut_prelevement=2017-01-01&date_fin_prelevement=2017-02-20&page=1000&size=20
ou
Bonjour,
Les données remontées sur la hauteur du cours d'eau de la Loire à Nantes ne semblent s'actualiser que par "paquet". Si les données sont prises toutes les 10 minutes, leur actualisation n'a pas la même fréquence. Par exemple, il est 09:24 ce jour, et les données les plus récentes ne datent que de 9h (soit deux itérations de retard).
Ex: https://hubeau.eaufrance.fr/api/v1/hydrometrie/observations_tr?code_entite=M800001010&grandeur_hydro=H&size=2
Une capture d'écran de mauvaise qualité pour illustrer mon propos
Le site Vigicrues a lui aussi ce décalage: https://www.vigicrues.gouv.fr/niv3-station.php?CdEntVigiCru=9&CdStationHydro=M800001010&GrdSerie=H&ZoomInitial=3
Peut-on y faire quelque chose ?
Merci !
Bonjour,
Une question concernant le résultats des requêtes? est-il possible d'obtenir les [resltat_obs] Q et H dans deux colonnes distinctes (plutôt qu' une ligne sur deux)?
En vous remerciant
Bonjour
Pour certaines stations la valeur du count change quand la parametre size est modifié :
exemple :
https://hubeau.eaufrance.fr/api/v1/qualite_nappes/analyses?bss_id=06103X0018%2FF24&code_param=1340&size=3 indique un count à 13
et https://hubeau.eaufrance.fr/api/v1/qualite_nappes/analyses?bss_id=06103X0018%2FF24&code_param=1340&size=20 indique un size à 19
Le bug semble être le même en utilisant un code bss nouveau (BSSXXXXXX)
Bonjour,
Il semble qu'il manque ponctuellement des données dans les imports hubeau par rapport aux données présentes sur ADES. Par exemple, le points d'eau 00271X0002/P2 au 02/01/2019, présent sur ADES:
https://ades.eaufrance.fr/Fiche/PtEau?Code=00271X0002/P2#mesures_tab_donnees
et absent de hubeau:
https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/chroniques.csv?code_bss=00271X0002%2FP2&date_debut_mesure=2019-01-01&date_fin_mesure=2019-01-10&sort=desc
A moins que j'ai fait une erreur quelque part ?
Cordialement,
La spécification Swagger semble présenter quelques erreurs qui empêchent la génération
Il y a pas mal de propriétés "allowEmptyValues: false" présentes un peu partout dans la doc. Or ce paramètres ne semble pas en accord avec la spécification et génère une erreur. Un ticket a été ouvert sur le repo springfox/springfox#2204 et le problème semble reglé dans la version 2.9.0.
Il y a également deux erreurs de ce type dans l'api niveaux_nappes :
FATAL: System.Collections.Generic.KeyNotFoundException: The 'produces' of 'chroniques csv' requires that schema 'Chronique_pi_zom_trique' models a stream/binary data (e.g. 'type: string, format: binary'), however 'Chronique_pi_zom_trique' is an object schema (which would require 'produces' of 'application/json' or 'application/xml'). Please adjust either the 'produces' or the response schema to match your service's behavior.
On dirait que le endpoint chroniques.csv doit générer un csv mais qu'il fait référence à un modèle d'objet qui n'aurait peut-être pas lieu d'être
Enfin, le nom de certains objets génère un code assez douteux. Par exemple l'objet représentant les résultats d'une requête sur les chroniques s'appelle "Résultat d'une rêquete sur les chroniques" au lieu d'un nom plus approprié pour du code comme ResultatChronique par exemple.
Bonjour,
En faisant des test sur l'api température, j'ai trouvé des entrées avec une date en 2045/2046.
Il y a plus de 30 000 entrées incorrectes avec cet URL qui demande toutes les mesures après une date dans le futur:
https://hubeau.eaufrance.fr/api/v1/temperature/chronique?size=50&date_debut_mesure=2019-03-09%2019%3A30
Il semblerait que le problème viendrait de la station 03047445
Bonne journée
L'horodatage des observations ne distingue pas AM et PM. Voir par ex. http://hubeau.eaufrance.fr/api/v1/temperature/chronique.csv?code_station=04051125&size=2&date_debut_mesure=2010-05-01&date_fin_mesure=2010-09-30
Les données d'origine dans Naiades sont correctes : http://www.naiades.eaufrance.fr/acces-donnees#/temperature/resultats?debut=01-05-2010&fin=02-05-2010&stations=04051125
Bonjour,
nous utilisons l'API de piézométrie pour récupérer les historiques de chroniques en utilisant le nouveau code BSS. L'API "Chroniques" ne fonctionne pas avec le nouveau BSS. Une erreur est retournée: "code BSS ne peut pas être null". Dans chroniques_tr, il est possible d'utiliser bss_id comme variable mais pas dans chroniques.
Ex:
https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/chroniques?size=20000&bss_id=BSS001ZYYY KO
https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/chroniques?size=20000&code_bss=08466X0022/S2 OK
Est ce que vous avez prévu de l'implémenter ?
Merci d'avance
Bonjour,
en utilisant l'API Hubeau pour récupérer une liste de stations (https://hubeau.eaufrance.fr/api/v1/hydrometrie/referentiel/stations.csv?code_departement=19), nous récupérons une liste de stations avec un champ "code_sandre_reseau_station". Il contient bien une liste de codes séparés par des ,. Par exemple pour la station "L0010610", nous récupérons les réseaux "POH013,POH049,POH114,POH902". Seulement, nous ne trouvons pas la définition de ces réseaux sur http://www.sandre.eaufrance.fr/Rechercher-une-donnee-d-un-jeu
Ou peut on retrouver la définition des réseaux ?
Merci d'avance
bonjour,
nous utilisons l'API Qualité des eaux souterraines à la place du WS getData d'ADES qui est très lent et régulièrement en Timeout. Cependant, dans les attributs de sortie, nous ne trouvons par le laboratoire et le préleveur. De plus, nous ne trouvons pas le support de l'analyse. Est ce que ces champs sont prévus dans une évolution ou est ce que c'est voulu ?
Merci
Bonjour,
Merci pour les modifications faites à l'API Poissons.
L'interprétation des résultats de pêche électrique nécessite de pouvoir distinguer les protocoles de pêche. La BDMAP (publiée sur le site IMAGE http://www.image.eaufrance.fr/poisson/cours/p-ce-resultats.htm) permet de récupérer les champs "Méthode de prospection", "Moyen de Prospection" et "Nombre de passages", ces données sont-elles disponibles via l'API ?
Merci
Timothée BESSE
Bonjour,
Nous rencontrons un problème sur la récupération des ouvrages lorsque nous filtrons les "fields" de retour. Par exemple, cette URL fonctionne sans filtre : https://hubeau.eaufrance.fr/api/vbeta/prelevements/referentiel/ouvrages?format=json&size=200&code_ouvrage=OPR0000065205
Si nous rajoutons le filtre des fields, il nous manque des informations pourtant présentent dans le premier appel (ex: longitude, latitude)
Bon courage
Bonne journée
DEFAY Guillaume
Suite au Hackathon, AQUASYS a réalisé un tutoriel pour afficher des stations qualités dans QGIS. Vous pouvez y accéder à l'adresse suivante: https://youtu.be/vqD56x9XEK0 N'hésitez pas à le commenter ou à nous contacter pour tout renseignement complémentaire.
Bonjour,
Je fais appel à l'API hydro de manière automatique, en utilisant l'attribut next pour parcourir l'ensemble des données de la chronique, et finis par recevoir une erreur 500 au bout de quelques appels (nb variable, moins de 10 lors de mes derniers tests).
Est-ce une sécurité de votre côté ? Comment puis-je faire ?
Merci,
J. Wijting
Bonjour
Je réalise quelques tests sur l'API indicateur de services, mais le résultat est toujours vide
https://hubeau.eaufrance.fr/api/v0/indicateurs_services/indicateurs?size=20&code_indicateur=P101.1
ou https://hubeau.eaufrance.fr/api/v0/indicateurs_services/services?code_commune=17300&size=3&
Question plus large : les données sont elles semblables à ce qu'on peut récupérer sur http://www.services.eaufrance.fr/donnees/telechargement
ou http://www.data.eaufrance.fr/jdd/a8d7a630-b33d-4c0b-a865-ecbe20360de5
(sachant que la page www.services.eaufrance.fr/donnees/telechargement indique une mise à jour hebdomadaire)
Merci
Raphaël
L'opération chronique.csv ne retourne que les 10 premiers champs (de code_station à uri_cours_eau).
Les 9 champs suivants (de code_param à libelle_qualification) sont vides.
Par ex: http://hubeau.eaufrance.fr/api/vbeta/temperature/chronique.csv?code_commune=45287&size=2000
renvoie comme 1ere ligne :
"code_station";"libelle_station";"uri_station";"longitude";"latitude";"code_commune";"libelle_commune";"code_cours_eau";"libelle_cours_eau";"uri_cours_eau";"code_parametre";"libelle_parametre";"date_mesure_temp";"heure_mesure_temp";"resultat";"code_unite";"symbole_unite";"code_qualification";"libelle_qualification"
"03053310";"LA CLÉRY A SAINT-LOUP-DE-GONOIS 1";"http://id.eaufrance.fr/STQ/03053310";"2.9147619348576153";"48.058510048657496";"45287";"SAINT-LOUP-DE-GONOIS";"F4280600";"rivière la cléry";"http://id.eaufrance.fr/CEA/F4280600";"";"";"";"";"";"";"";"";""
alors que la même demande en JSON (http://hubeau.eaufrance.fr/api/vbeta/temperature/chronique?code_commune=45287&size=2000) renvoie correctement tous les champs :
{"count":58437,"first":"http://hubeau.eaufrance.fr/api/vbeta/temperature/chronique?code_commune=45287&page=1&size=2000","last":"http://hubeau.eaufrance.fr/api/vbeta/temperature/chronique?code_commune=45287&page=30&size=2000","prev":null,"next":"http://hubeau.eaufrance.fr/api/vbeta/temperature/chronique?code_commune=45287&page=2&size=2000","api_version":"beta","data":[{"code_station":"03053310","libelle_station":"LA CLÉRY A SAINT-LOUP-DE-GONOIS 1","uri_station":"http://id.eaufrance.fr/STQ/03053310","longitude":2.914761935,"latitude":48.058510049,"code_commune":"45287","libelle_commune":"SAINT-LOUP-DE-GONOIS","code_cours_eau":"F4280600","libelle_cours_eau":"rivière la cléry","uri_cours_eau":"http://id.eaufrance.fr/CEA/F4280600","code_parametre":"1301","libelle_parametre":"Température de l'Eau","date_mesure_temp":"0015-06-25","heure_mesure_temp":"01:00:00","resultat":15.437999725341797,"code_unite":"27","symbole_unite":"°C","code_qualification":"4","libelle_qualification":"Non qualifié"},
...
Bonjour,
je cherche à obtenir la liste des stations piézométriques sur une bbox en activité à deux dates différentes : le 21 juin 2020 et le 20 septembre 2020. La première requête me renvoi 311 résultats, la seconde 0. Pourquoi une telle différence à 3 mois d'écart ? Y a-t-il un délai de mise à jour de cette liste ?
Voici les deux requêtes :
1 : https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/stations?bbox=-0.53,44.55,4.66,48.42&date_recherche=2020-06-21&format=geojson&nb_mesures_piezo_min=5400&size=2000&srid=4326
2 : https://hubeau.eaufrance.fr/api/v1/niveaux_nappes/stations?bbox=-0.53,44.55,4.66,48.42&date_recherche=2020-09-19&format=geojson&nb_mesures_piezo_min=5400&size=2000&srid=4326
Merci pour vos explications,
Emilie
Afin de faciliter des jointures ultérieures, il serait utile d'avoir le code SIRET de l'établissement qui exploite l'ouvrage concerné.
Pensez-vous qu'il soit possible d'avoir le nom de l'ouvrage dans l'API des chroniques ? Pour le reste, je n'ai rencontré aucune difficulté. J'attends d'avoir les coordonnées afin de pouvoir faire une sélection géographique directement via l'API.
Merci,
Emilie
Bonjour,
Je rencontre un problème lors de l'interrogation de l'API Qualité des nappes d'eau souterraine, le nombre de résultats attendus (attribut count) varie constamment pour les mêmes paramètres, par exemple :
http://hubeau.eaufrance.fr/api/v1/qualite_nappes/analyses?code_param=1340&size=20&date_debut_prelevement=2017-01-01&date_fin_prelevement=2017-06-30
L'attribut count varie de 8831 à 8670.
Pouvez-vous résoudre le problème ou me dire comment le contourner ?
Merci par avance.
Bonjour,
Afin d'analyser l'évolution de la répartition d'une espèce à travers les données de la BDMAP, ce qui correspond à votre défi "Déplacement des populations de poissons", j'utilise le logiciel QGIS pour importer les résultats de pêche pour l'espèce au format GEOJSON. Je n'arrive cependant pas à identifier le format de la date. Par exemple pour l'opération 10090001494, la date au format json est "1988-09-07" (YYYY-MM-DD) et au format GEOJSON elle devient "589593600000". Est-ce un timestamp converti en entier ? Comment récupérer une date à partir de ce champ avec QGIS, afin d'en extraire ensuite l'année, etc... ?
Merci pour votre aide,
Timothée Besse
Le démonstrateur http://hubeau.eaufrance.fr/sites/default/files/api/demo/poissons.html ne fonctionne plus, peut-être suite à un changement dans l'API.
Bonjour
Serait-il possible d'ajouter la liaison aux masses d'eau (état des lieux et rapportage) à l'API Piézométrie de la même manière que sur l'API "qualité des nappes" ?
Actuellement, seule la liaison avec les entités BD LISA est disponible (la liaison entre BDLISA et masses d'eau n'étant a priori faisable qu'à partir de l'état des lieux 2019, pas encore disponible).
Dans l'attente, j'ai trouvé une liaison entre masses d'eau "rapportage" et piézomètres dans les bases de données waterbase quantity de l'EEA ; ce sont les données remontées par l'Etat français auprès de la commission européenne dans le cadre de la directive cadre sur l'eau.
Par exemple dans cette base de données :
SELECT WB.waterBodyIdentifier, WB.monitoringSiteIdentifier FROM MonitoringSite_DerivedData AS WB WHERE WB.waterBodyIdentifier IS 'FRAG015'
donne
waterBodyIdentifier monitoringSiteIdentifier
FRAG015 FR00143C0079-F1
FRAG015 FR00155C0017-F1
FRAG015 FR00143A0008-F1
ce qui permet ensuite d'accéder aux niveaux des piézomètres concernés.
Si l'on pouvait au moins intégrer cette table dans l'API, cela permettrait d'avoir un fonctionnement API "pur" pour lister et collecter les données recherchées.
Bien cordialement
Thomas Grandjean
Dreal HdF
Bonjour, on ne retrouve pas dans les résultats d'une interrogation OUVRAGE, le code_entite_hydrogeo normalement renseigné pour le type SOUT comme indiqué dans la documentation.
Exemple : https://hubeau.eaufrance.fr/api/vbeta/prelevements/referentiel/ouvrages?code_type_milieu=SOUT&code_departement=44
Par contre, on trouve dans les résultats d'un prélèvement une info dupliquée (?) code_zone_hydrogeo mais également le code_bss_point_eau. Cette dernière information ne pourrait-elle pas être remontée au niveau de l'ouvrage ?
Il faudrait donc que la doc https://hubeau.eaufrance.fr/page/api-prelevements-eau#/ et les résultats effectifs soient cohérents et que le code_bss_point_eau soit remonté au niveau de l'ouvrage plutôt que du point de prélèvement.
Merci
Bonjour,
Le champs "libelle_precision_coord" semble toujours valoir "null" pour l’opération /vbeta/prelevements/referentiel/points_prelevement malgré un code_precision_coord bien définit.
l’opération /vbeta/prelevements/referentiel/ouvrages n'a pas ce problème.
Merci
Bonjour,
Dans un premier temps, j'affiche des valeurs de hauteur sur un graphique highcharts en utilisant l'API hydrométrie.
Afin de limiter la taille du fichier j'utilise la requête suivante:
Lorsque j'utilise ce lien dans le navigateur j'obtiens une table avec les paramètre souhaités.Mais lorsque je l'utilise dans mon code (ci-dessous), j'obtiens une table complète avec tous les champs et de grande profondeur: bien trop gros pour mon graphique.
Pourquoi la requête PHP ne tient pas compte de mes paramètres dans ma requête hubeau?
$url='https://hubeau.eaufrance.fr/api/v1/hydrometrie/observations_tr.csv?code_entite=Y9000001&fields=code_site,code_station,grandeur_hydro,date_obs,resultat_obs&grandeur_hydro=H&page=3&size=200'; //table allégée
$locationfile= $_SERVER['DOCUMENT_ROOT'].'/graph/'; // dossier de destination
$hubeaufile=$locationfile.'hata.csv';//nom du fichier à sa localisation
$file=fopen($url,'rb');
if($file){
$newf= fopen($hubeaufile,'a'); //écrase le file existant
if ($newf)
while(!feof($file))
{
fwrite($newf, fread($file, 800000),800000);
}
}
if($file){
fclose($file);
}
if($newf){
fclose($newf);
}
ftp_close($conn_ftp);
En vous remerciant,
Bonjour,
existe t 'il un outil dans l'API pour récupérer à partir d'un code BSS, toutes les infos stockée dans un point BSS eau (code masse d'eau, nom de la masse d'eau ….. )
merci
Matthieu
Bonjour,
L'API poisson ne remonte pas de nom_cummun pour le code BLN
Elle remonte bien un nom_latin.
Le nom_commun semble être celui remonté par l'api (api/v0/etat_piscicole/poissons)
"code_espece_poisson" : "BLN",
"nom_poisson" : "\"\"",
Est-il possible de l'ajouter ?
Arnaud
[Méthode observations_tr]
La requête simple
http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&size=1&pretty&grandeur_hydro=H
(donc sans demander une liste de champs) renvoie des dates au format UTC:
{
"count" : 8328,
"first" : "http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&pretty&grandeur_hydro=H&cursor=&size=1",
"prev" : null,
"next" : "http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&pretty&grandeur_hydro=H&cursor=AoQIP4AAACpZMjUxMDAyMDAxcKy5k9nkAj8FYTBlMjg0MTItZDU3Yi00NThmLThmMWEtMjAxNWVlZWZkNWE0&size=1",
"api_version" : "beta",
"data" : [ {
"code_site" : null,
"code_station" : "Y251002001",
"grandeur_hydro" : "H",
"date_debut_serie" : "2018-07-19T00:05:01Z",
"date_fin_serie" : "2018-07-19T11:30:00Z",
"statut_serie" : 4,
"code_systeme_alti_serie" : 31,
"date_obs" : "2018-07-19T11:30:00Z",
"resultat_obs" : 8.0,
"code_methode_obs" : 0,
"libelle_methode_obs" : null,
"code_qualification_obs" : 16,
"libelle_qualification_obs" : null,
"continuite_obs_hydro" : true,
"longitude" : 3.15727754,
"latitude" : 43.616027429
} ]
}
La même requête en précisant une liste de champs :
http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&size=1&pretty&grandeur_hydro=H&fields=code_station,date_debut_serie,date_fin_serie,date_obs,resultat_obs,continuite_obs_hydro
renvoie des dates avec le fuseau horaire Paris :
{
"count" : 8328,
"first" : "http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&pretty&grandeur_hydro=H&fields=code_station,date_debut_serie,date_fin_serie,date_obs,resultat_obs,continuite_obs_hydro&cursor=&size=1",
"prev" : null,
"next" : "http://hubeau.brgm-rec.fr/api/vbeta/hydrometrie/observations_tr?code_entite=Y251002001&pretty&grandeur_hydro=H&fields=code_station,date_debut_serie,date_fin_serie,date_obs,resultat_obs,continuite_obs_hydro&cursor=AoQIP4AAACpZMjUxMDAyMDAxcLCUkdnkAj8FMDE3OTcxMjYtYWMxNi00NjAwLWIwOTgtM2JkOTJjYTU3ODUy&size=1",
"api_version" : "beta",
"data" : [ {
"code_station" : "Y251002001",
"date_debut_serie" : "2018-07-19T02:05:01+02:00",
"date_fin_serie" : "2018-07-19T13:30:00+02:00",
"date_obs" : "2018-07-19T13:30:00+02:00",
"resultat_obs" : 8.0,
"continuite_obs_hydro" : true
}]
}
Il faudrait harmoniser, le mieux serait d'avoir les dates dans le fuseau horaire Paris pour toutes les requêtes.
Bonjour,
Je découvre cette API, n'étant pas du métier j'aimerai connaître les unités concernant:
Pourriez-vous m'indiquer la documentation qui précise ces champs si elle existe?
Merci
Bonjour,
J'utilise le logiciel Tableau (version gratuite Tableau Public) pour visualiser mes bases de données géoréférencées et les publier sous forme de cartes interactives. - Site web : http://www.tableau.com/fr-fr -
Exemple d'utilisation pour les Tableaux de bord Migrateurs de Loire : https://public.tableau.com/views/Devalpomi/Devalpomi
J'ai utilisé l'API Hub'Eau pour afficher les données "poissons", en passant par un "connecteur de données web" pour importer les données JSON : - Explications : http://www.tableau.com/fr-fr/web-data-connector - Connecteur JSON : https://tableau.github.io/webdataconnector/Examples/jsonConnector.html (source du connecteur JSON https://github.com/tableau/webdataconnector/blob/master/Examples/jsonCon...)
Voici ce que ça donne pour un premier essai : https://public.tableau.com/views/HubEau/PrsenceduSilure
La contrainte de requête des stations par espèce et celle de requête des poissons par station rend l'outil moins intéressant : Les résultats d'une seule station peuvent être importés, ou les stations d'une seule espèce.
S'il était possible de distinguer les présences par opération (date de pêche) pour les "lieux de pêche" ou d'afficher l'ensemble des stations pour les "poissons" ainsi que leurs coordonnées, je pourrais visualiser par exemple l'évolution de la répartition et des effectifs de chaque espèce.
Requête : Effectifs et poids par espèce et par opération (Station X, Y, Date de pêche, Cours d'eau, protocole, code espèce, effectif, poids...)
J'ai remarqué que la carte des "lieux de pêche" indiquait de nombreuses stations mal géoréférencées pour l'anguille européenne (stations 4411022 à 4411033 notamment).
Cordialement
Timothée Besse
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.