Bonsoir journal,
je te partage ce soir mon expérience sur un petit projet de démerdification de l'accès aux données de prévision météo (« la vraie » hein, pas juste « soleil » ou « nuage »; plutôt la position et déplacement des fronts pour la prévision à quelques jours; les images radar et carte des vents pour les heures à venir, voire le 1/4h à venir). La motivation était une activité de plein air itinérante avec besoin de prévoir la météo, depuis un terminal mobile qui n'est plus tout jeune et un forfait données très limité.
En rêvant un peu, ce serait bien de pouvoir rassembler sur une page des infos de 3 sites différents, complémentaires. Un premier site qui a des bonnes cartes mais ne les fournit seulement sous forme d'une image HD de 5 Mo. OK, un coup de wget et convert ça va le faire. Un second sur lequel c'est des quelques infos texte précises noyées dans une page énorme qui m'intéressent. J'ai des restes de PHP, en parsant la page, identifiant le bon XPath (voir plus bas), ça ne doit pas être trop compliqué. Et le 3e ? Ça se gâte !
Ce téléphone, ayant pourtant moins de 10 ans, souffre gravement lorsqu'on accède à des sites qui contiennent des infos pourtant très utiles : fonctionnellement une carte avec différents calques animés en JS ça consomme un peu coté client, mais quand en plus ces sites sont bourrés de popup d'acceptation des cookies, vidéos, autres animations JS dans tous les sens… chaque consultation consomme des dizaines de Mo, rame (voire freeze) et fait chauffer le téléphone furieusement… alors qu'en pratique, j'aurais besoin seulement d'une 20aines d'images de 600px pour faire mon analyse.
Ni une ni deux, je regarde comment faire en sorte que mon serveur fasse le sale boulot de se connecter à ce 3e site, et me mette à disposition seulement ce dont j'ai besoin.
Je découvre donc puppeteer qui permet précisément faire tourner sur un serveur un navigateur et de contrôler celui (dans notre cas, cliquer sur des boutons et exporter le rendu du site dans une image).
Tout ça fonctionne en Javascript / node, pas trop ma tasse de thé au départ, mais au final ça fait bien le boulot sans avoir à plonger trop les mains dans le cambouis. Voici les grandes lignes pour un serveur tournant sous Debian 12 :
Installer
node-puppeteer: le paquet n'étant dispo que dans Unstable, il faut télécharger le paquet à la main et l'installer viaapt install ./node-puppeteer_13.4.1+dfsg-2_all.deb. Y'a du lourd dans les dépendances (espace disque requis ~600 Mo). Par défaut c'est chromium qui est utilisé, j'ai cru voir que c'était possible avec Firefox mais pas creusé cette option.Si pas déjà fait, installer et configurer un serveur graphique via
apt-get install xvfb xorg xvfb gtk2-engines-pixbuf dbus-x11 xfonts-base xfonts-100dpi xfonts-75dpi xfonts-scalable imagemagick x11-apps. Configurer viaXvfb -ac :99 -screen 0 1280x1024x16 & export DISPLAY=:99.Un exemple de base pour illustrer : charger https://linuxfr.org et exporter dans une image PNG : mettre dans
test_linuxfr.js
const puppeteer = require('puppeteer-core');
(async () => {
const browser = await puppeteer.launch({
executablePath: '/usr/bin/chromium',
headless: false
});
const page = await browser.newPage();
await page.goto('https://linuxfr.org');
await page.screenshot({path: 'example.png'});
await browser.close();
})();puis en tant qu'utilisateur il suffit de lancer le bouzin avec :
DISPLAY=:99 node test_linuxfr.js
et après un petit pic de CPU, on récupère une jolie grosse image example.png.
-
Préciser ce qu'on veut exporter
- en pratique, il est souvent inutile d'exporter toute la page mais seulement une partie
- on peut avoir à interagir (cliquer sur des boutons) après le chargement pour afficher ce qui nous intéresse vraiment : typiquement boutons +/-1h, modifier le fond de carte, etc.
Pour ces 2 problématiques, le mode Deboggage de Firefox (accessible via F12, onglet Inspection) permet de localiser dans le code les boutons utiles. Une fois identifié la portion du code correspondant au bouton qui vont intéresse, il faut récupérer son XPath (clic droit sur la portion du code, Copier > XPath).
Par exemple, /html/body/div/div[2]/div[1]/div[2]/div/a[2].
Alors il suffit d'ajouter, éventuellement après une petite tempo pour être sur que la page soit finie de chargée, l'action correspondante au clic sur ce XPath via :
await page.waitForTimeout(2000);
const elements = await page.$x('//html/body/div/div[2]/div[1]/div[2]/div/a[2]')
await elements[0].click()
await page.waitForTimeout(2000);
await page.screenshot({path: SITE_PATH + 'precipitations_1.webp'});Automatisation
Une fois satisfait du résultat, une petite ligne cron permet d'automatiser cette génération, dans mon cas matin, midi et soir :
10 07,12,19 * * * bash -c "DISPLAY=:99 node /var/www/my_webapp/meteo_proxy/scripts/meteo.js"Interface
Pour consulter les images générées, un simple morceau de HTML statique pointant vers les images est alors suffisant.
A noter, par défaut mon navigateur mobile met en cache les images, souvent c'est pratique, parfois ça induit en erreur ! On doit pouvoir forcer à rafraîchir le cache quand la source change (?) mais je n'ai pas creusé cette piste. En attendant, j'utilise un onglet de navigation privée quand on veut absolument éviter le cache.Le cas des images à réduire (site 1)
Quand l'image est déjà disponible, un simple script utilisant l'excellent ImageMagick fait l'affaire:
wget https://sitemeteo/avec/des/images/pas/optimisees/du_tout.png -O /tmp/prevision_europe.png
convert /tmp/prevision_europe.png -resize 600 $MODE "$SITE_PATH""prevision_europe.webp"Le cas des infos textes à extraire (site 2)
Une extraction du texte venant d'une balise (à identifier via le XPath comme vu plus haut) via un bout de PHP :
<?php
if (ob_get_level() == 0) ob_start();
$context = stream_context_create(
array(
"http" => array(
"header" => "User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML,>
)
)
);
//liste des stations
$stations = array(
"code1" => "Station 1",
"code2" => "Station 2",
"code3" => "Station 3"
);
echo "<table>";
foreach ($stations as $k => $v) {
echo "<tr><td>".$v." (".$k."):</td>\n";
$html = file_get_contents("https://sitemeteo/n3/".$k, false, $context);
$doc = new DomDocument();
$doc->loadHtml($html);
$xpath = new DomXPath($doc);
foreach ($xpath->query('/html/body/div[2]/div/div/div[4]/div[2]/div[2]/code') as $node) {
echo "<td>", $node->nodeValue, "</td>";
}
...Pour le fun
Les prévisions 3x par jour c'est généralement suffisant, mais à l'automne quand le temps change rapidement ça peut être utile de forcer un rafraîchissement à un autre moment sans avoir à sortir SSH avec mes gros doigts sur mon petit téléphone. En PHP il suffit d'un :
exec('bash -c "DISPLAY=:99 node /var/www/my_webapp/meteo_proxy/scripts/meteo.js"', $output, $retval);
ça c'est juste parce que c'est rigolo via du PHP de faire tourner du Javascript sur un serveur (en tout cas l'occasion d'une première pour moi).-
Quelques considérations a posteriori
- En passant quelques heures de dev j'ai pu générer une interface rassemblant les infos utiles issues de 3 sites, pesant quelques centaines de ko contre des dizaines de Mo, très rapidement actualisables et sans exploser mon téléphone.
- C'était une utilisation pas très critique, surtout une bonne occasion de bidouiller du web :) je m'attendais à ce qu'en plein milieu de la brousse mes images ne soient plus rafraîchies, que mon serveur s'envoie un CPU en l'air, … mais au final ça tourne rond sans exception (au moins tant que les sites ne modifient pas leurs chemins).
- La génération des images via pupperteer consomme beaucoup coté serveur (on ne fait que déplacer la cochonerie en amont ;) au moins 600Mo de RAM à l'exécution, CPU à fond pendant ~2-3min pour générer une 30aine d'images), donc ça n'a du sens que dans certains cas d'usage (terminal avec capacités limitées, données très limitées, plusieurs utilisateurs utilisant les même images).
- Malgré plusieurs articles vu ici je n'avais pas encore eu l'occasion de comparer moi-même, l'export des images au format webp permet bien d'économiser ~30% de données par rapport au jpeg, vraiment bon à prendre pour ce cas d'application !
Voilà c'est un petit journal rapide, pour garder une trace des grandes lignes et peut-être vous donner envie de tester ou au moins savoir ce qui est faisable :) (une recherche rapide semble indiquer que Puppeteer n'a pas souvent été évoqué ici !)
# firefox
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
Tu peux aussi utiliser firefox avec puppeteer, ça évite d'augmenter encore plus celles de chrome/chromium.
Il y a aussi playwright dans le même genre.
[^] # Re: firefox
Posté par Alecto . Évalué à 1 (+1/-0).
Ah oui playwright très bon outil, je l'utilise pour extraire des informations depuis divers sites.
L'outil a une API compatible plusieurs langages (ts, js, python…) et s’exécute bien dans une CI type Gitlab avec Docker.
Couplé à l'hébergement de site statique (type gitlab-pages), ça permet de tout traiter tout au même endroit sans avoir besoin de gérer un serveur.
# démerdification
Posté par Marotte ⛧ . Évalué à 5 (+3/-1).
Je ne sais pas si j’avais déjà lu/entendu ce terme auparavant mais je sens qu’il est promis à un bel avenir. Promis à un futur hautement démerdifié et en même temps facilement démerdable.
# je hijack le commentaire
Posté par octane . Évalué à 9 (+7/-0).
Ce journal m'a fait penser à un truc. On connaît le temps actuel (suffit d'ouvrir la fenêtre), le temps futur (suffit d'ouvrir ce journal), mais comment connaître le temps passé? (suffit d'ouvrir sa mémoire, mais en fait non).
Le problème que j'ai des fois, c'est de connaitre le temps qu'il faisait hier (et avant hier) ailleurs. Je veux me balader en forêt (loin de chez moi), si les trois derniers jours il a plu, vaut mieux prendre mes bottes, et je n'ai pas forcément noté la météo depuis trois jours.
Ca existe des sites météo qui ont un historique?
[^] # Re: je hijack le commentaire
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
Sur meteo60.fr on trouve des cartes de précipitations passées à 2, 6, 12, 24, 36, 48, 72, 96 heures, etc.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: je hijack le commentaire
Posté par jpglinuxfr . Évalué à 3 (+3/-0).
Perso, j'utilise https://www.drops.live/fr-fr/city/7342#selectedLayer=precipitationAccumulation
[^] # Re: je hijack le commentaire
Posté par Donk . Évalué à 5 (+3/-0).
Il y a meteociel.fr
https://www.meteociel.fr/temps-reel/obs_villes.php?code2=7103&jour2=24&mois2=9&annee2=2024
[^] # Re: je hijack le commentaire
Posté par remico . Évalué à 3 (+2/-0).
Sur meteociel.fr effectivement il y a vraiment plein d'info, en plus de cette page sur les observations, la page de prévisions par ville et code postal avec pleins de modèles de prévisions différents, AROME, etc .., il y a aussi les diagrammes de précipitations ou températures prévues, direction et force du vent (j'ai mis Brest), résumé ou heure par heure :
https://www.meteociel.fr/previsions/9478/brest.htm
Sur météociel aussi :
-le radar précipitation qui est très utile pour une activité en plein air à court terme lorsque le temps est instable, et m'a très souvent permis de passer entre deux averses, en décalant l'heure de départ d'un trajet en vélo.
- les cartes satellite à plus grande échelle pour voir ce qui va arriver au-delà du radar précipitation.
[^] # Re: je hijack le commentaire
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Le site infoclimat est vraiment bien pour ça. Après, ça dépend de où tu vas. Tu cliques sur la carte et ça te permet d'accéder à un historique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: je hijack le commentaire
Posté par remico . Évalué à 4 (+3/-0).
Il y a aussi les prévisions à sept jours par ville (ou village) + code postal sur infoclimat :
https://www.infoclimat.fr/previsions-meteo-par-ville.html
Les deux infoclimat et meteociel sont complémentaires, avec une préférence pour meteociel.
J'ai mis les deux dans la barre des favoris, avec mon code postal, j'y accède à quand c'est nécessaire en un clic. Si j'utilisais un smartphone je les mettrais aussi en favori.
Sur meteociel il y a aussi le logiciel GFS qui marche sur windows (GFS en bas de page), peut-être aussi avec wine, je n'ai pas trouvé d'appli androïd ou de soft linux similaires permettant de récupérer ces cartes. Il doit y en avoir ce sont des datas publiques.
GFS permet d'avoir les prévisions jusqu'à 15j, température, précipitations, nébulosité, vents etc .. et donc le samedi 9 novembre à 6h il fera 12° environ, nébulosité 92,4% précipitation 0mm, vent 12,8km/h dans une grande partie de la France selon les prévision de Wetterzentrale avec une certaine incertitude pour les prévisions à 15j.
Elles sont là les cartes de wetterzentrale pour le modèle gfs, il y a d'autres modèles, mais je pige rien à l'allemand:
https://www.wetterzentrale.de/de/topkarten.php?model=gfs&time=6&lid=OP
[^] # Re: je hijack le commentaire
Posté par Luc-Skywalker . Évalué à 6 (+4/-0). Dernière modification le 25 octobre 2024 à 15:59.
Wetterzentrale c'est ze référence depuis pas loin de 20 ans je dirais pour récupérer les sorties des grands modèles.
Je m'occupais d'un site à une époque ou la mise en page à base tableaux était la norme. Avec encore des tableaux pour sortir des vues synthétiques des prévisions avec dans chaque cellule du PHP (version 4 je crois) pour fabriquer à coup d'echo le lien vers wetterzentrale.
Ce journal m'a rappelé cet art de la hache.
Sinon j'abonde pour meteociel et infoclimat avec la même préférence que toi.
Mais dans les deux cas c'est d'excellente facture.
J'en profite pour féliciter et remercier les personnes qui font tourner ces services si elles devaient passer par ici.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: je hijack le commentaire
Posté par Epy . Évalué à 6 (+4/-0).
Il y a aussi https://openweathermap.org/ avec une super API :)
[^] # Re: je hijack le commentaire
Posté par anubis . Évalué à 5 (+4/-0).
Les données du passé sont (au moins pour la France) en open data depuis peu (voir https://linuxfr.org/users/gbetous/liens/la-meteo-de-meteo-france-en-open-data#comment-1944847), ça permet un accès beaucoup plus propre que ce que j'ai du faire ici pour les prévisions.
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: je hijack le commentaire
Posté par remico . Évalué à 3 (+2/-0).
Il y a les données historiques de météo-france mais aussi les prévisions dans différents modèles :
https://meteo.data.gouv.fr/
En cliquant sur Donnée de prévision numérique du temps (quel jargon!) c'est des fichiers assez lourds plusieurs centaines de Mo , il y a divers modèles arpege ou arome, différentes régions antilles etc .. ou encore les hauteurs de vague. Le fichier pnt date d'il y a six jours. Les fichiers arome ou arpège eux sont bien actualisés. Ils sont en .grib2, format dédié je suppose d'après les résultats de google.
Les prévisions par code postal sur meteociel.fr me suffisent je n'ai pas l'utilité de prévisions pour toute la France. J'ai souvent observé des différences suivant les modèles, mais je clique rarement sur les autres modèles que celui proposé par défaut GFS. J'ai aussi souvent observé des différences avec les prévisions de Miss Météo, à l'avantage de metociel.
# Même problème qu'avec Weboob?
Posté par arnaudus . Évalué à 10 (+8/-0).
Il me semble que ce genre de projets, tout bien intentionné qu'il soit, ne peut pas réellement sortir du script qui se partage sous le manteau, avec une petite communauté.
Déja, tu as le problème de la maintenance. La structure des sites cibles change, et comme il n'y a pas de collaboration, tu vas t'apercevoir que le site a changé quand le script ne marche plus. Du coup, il va falloir être réactif pour publier un correctif, et pendant ce temps, du point de vue des utilisateurs, ton truc est planté. Ça, ça ne peut pas marcher auprès d'un public qui ne serait pas au courant des aspects techniques; par exemple, si tu publies une "appli" pour smartphone, tu vas recevoir des centaines de "1 étoile, Sa marche pas, poubelle".
L'autre problème encore plus majeur, c'est évidemment que tu ne respectes pas les conditions générales d'utilisation des sites. L'objectif de ces sites est en général d'attirer les lecteurs avec du contenu un peu difficile à trouver pour leur servir un max de pubs et leur laisser un max de cookies. Les visites de robots et de scripts qui ne regardent pas les pubs, c'est de la bande passante perdue pour eux. Pire, en cas de succès, ça va même détourner les visiteurs. Tant que que tu passes sous les radars, pas de problème, personne ne verra rien. Mais dès que tu acquières une petite notoriété (style webboob), certains sites vont commencer à chercher à te bloquer, plus ou moins subtilement. Tu es donc condamné à la clandestinité. Et, même si le risque est limité, tu peux te prendre des mises en demeure. Et les miroirs qui hébergeraient ton application aussi. C'est pas très serein comme ambiance pour développer et diffuser un logiciel…
[^] # Re: Même problème qu'avec Weboob?
Posté par eingousef . Évalué à 6 (+4/-0). Dernière modification le 25 octobre 2024 à 18:02.
J'allais répondre que Météo-France est un service public mais en fait leur site a des conditions d'utilisation tout aussi merdiques qu'un service commercial.
Par contre pour l'Europe je suis tombé sur : https://www.ecmwf.int/en/forecasts/accessing-forecasts
Il y a l'air d'y avoir des données brutes accessibles en CC By 4.0: https://www.ecmwf.int/en/forecasts/datasets/wmo-essential , https://www.ecmwf.int/en/forecasts/datasets/open-data . Je ne sais pas comment ça s'exploite mais il y a l'air d'y avoir de la doc. En dehors de données brutes il n'y a pas grand chose sauf si on veut jouer avec des trucs comme https://charts.ecmwf.int/products/medium-clouds?base_time=202410250000&projection=opencharts_europe&valid_time=202410261800 (exemple pour la couverture nuageuse).
Il y a l'air d'y avoir déjà des sites qui présentent ces données d'une manière un peu plus user friendly: https://open-meteo.com/en/docs/ecmwf-api
*splash!*
[^] # Re: Même problème qu'avec Weboob?
Posté par arnaudus . Évalué à 5 (+2/-0). Dernière modification le 25 octobre 2024 à 18:51.
Météo-France est un établissement public, mais la dotation de l'État baisse et son fonctionnement repose sur des ressources propres (vente de prévisions, etc). L'Open Data c'est pas trop à la mode en France…
Ceci dit, ça ne serait pas trop logique de trouver les données brutes sur le www de Météo-France. Si API il y avait, elle serait certainement sur un serveur dédié, avec éventuellement une gestion des droits d'accès, et des conditions spécifiques différentes de celles de la consultation du site web.
[^] # Re: Même problème qu'avec Weboob?
Posté par anubis . Évalué à 4 (+3/-0). Dernière modification le 25 octobre 2024 à 18:30.
C'est clairement un projet personnel, je n'ai pas l'intention de diffuser ici les sites ni l'integralité du code (codé à la râche®) qui me sont utile, je partage ici seulement l'idée et les grandes lignes techniques; c'est destiné à des bricoleurs, comme il en traîne quelques uns par ici ;)
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: Même problème qu'avec Weboob?
Posté par arnaudus . Évalué à 4 (+1/-0).
Bah c'est quand même un peu dommage sur un site dédié aux logiciels libres de ne pas viser un travail collaboratif… Si tu as eu un problème à régler, il est possible que d'autres aient le même problème, non?
Du coup, l'objectif du journal c'est de partager des "trucs" pour le scrapping?
Je reste sur l'idée que pour ce genre de données, il doit exister des API…
[^] # Re: Même problème qu'avec Weboob?
Posté par moules . Évalué à 3 (+1/-0). Dernière modification le 26 octobre 2024 à 11:15.
Alors il y a deux types de scraping : la récupération de données publiques, et la récupération de données personnelle.
Le cadre d'utilisation de w[eb]oob est davantage de l'ordre de la donnée personnelle (c'est principalement utilisé pour extraire les données bancaires, même si pas mal d'autres use-cases existent mais sont utilisés de manière plus marginale).
Or dans le cadre de l'accès à la donnée personnelle, on peut assez légitimement s'appuyer sur le GDPR et la notion de portabilité, pour justifier l'automatisation de l'extraction.
Concernant le bancaire, c'est un peu différent car au final la directive européenne PSD2 a donné un cadre à cette activité (en obligeant les banques à fournir des API, mais contraignant les consommateurs de ces API à l'obtention d'une licence d'établissement de paiement, donc ça ne va pas trop dans le sens du logiciel libre).
Pour revenir sur le sujet de la maintenance, oui c'est un véritable problème, et cela dépend de la communauté que tu as. yt-dl marche plutôt bien il me semble car il y a beaucoup de contributeurs. Pour woob, powens, la boîte que j'ai montée, est (était) un gros contributeur sur la maintenance des connecteurs bancaires.
Et ce dernier point est aussi une illustration de comment résoudre ce problème : si tu veux bénéficier d'une maintenance réactive tu peux… payer un service qui te garanti des SLA. Alors ce ne sont pas les particuliers qui sont clients de powens, mais tout le monde peut en bénéficier indirectement en utilisant un logiciel ou service client de powens.
Parce que oui un logiciel libre ne donne aucune garantie, et sur le scraping encore moins, ce qui marche aujourd'hui ne marchera pas forcément demain, mais ça se résout soit par une communauté bénévole active, soit par des contributeurs qui en font un usage commercial.
[^] # Re: Même problème qu'avec Weboob?
Posté par Stun43 . Évalué à 0 (+0/-0).
On est d'accord que Power et woob, à 99,999% la rupture est consommée…
[^] # Re: Même problème qu'avec Weboob?
Posté par arnaudus . Évalué à 3 (+0/-0).
Ça me semblerait à la fois plus pratique, plus légal, et plus fiable d'exiger l'extraction d'une archive complète contenant ses données personnelles. Ensuite tu analyses ton archive en local comme tu veux, mais balancer des requêtes à un site destiné à interagir avec un utilisateur humain semble largement sous-optimal.
Dans le cas de w[ebb]oob, de toutes manières, je ne vois pas du tout de distinction technique entre les deux. Il suffirait de trouver un jeu de mots graveleux avec "météo", et hop, tu peux utiliser un cadre de développement un peu plus abouti que des scripts qui trainent…
Je ne suis pas en train de dire que le scraping c'est bien ou c'est mal, ça dépend qui et quoi. Mais c'est quand même la pire solution, que ce soit pour le développement lui-même (c'est quand même 99% de bricolage crade et de reverse-engineering), la maintenance, et la sécurité juridique. Et même pour le site cible, puisque même s'il est de bonne foi et qu'il encourage la récupération de données, il ne va pas pouvoir changer son architecture sans pêter les outils de scaping, ce qui risque quand même d'empêcher son évolution.
[^] # Re: Même problème qu'avec Weboob?
Posté par moules . Évalué à 2 (+0/-0).
Eh bien justement, le « slogan » de weboob au début était « dans un monde parfait, il ne devrait pas exister ».
Après, même si mon avis est évidement biaisé, ce qui distingue woob d'un script de scraping, c'est le système de capabilities et de standardisation des données (cf https://woob.dev).
# brique ou marteau
Posté par steph1978 . Évalué à 5 (+3/-0).
Merci pour ce journal qui m'évoque de bons souvenirs ; crois moi que tu as bien fait de ne pas citer explicitement les sites que tu tentes de démerdifier.
Puppeteer est lourd car il lance un navigateur complet, qu'il pilote. Mais nécessaire quand il faut exécuter le javacript pour construire le DOM. Cependant, le DOM est bien reconstitué à partir de données et souvent, c'est par une requête à un document JSON. Et dans ce cas il suffit de parser le JSON. On démerdifie un max.
D'ailleurs Puppeteer, à la base, n'est pas conçu pour faire du scraping - l'outil de la démerdification - mais pour faire des tests d'UI.
Pour ma part, je m'en suis presque toujours sorti avec
curl url/to/json | jq '.path'oucurl utl/to/html | pup 'selector'ou une combinaison des deux. Pour quelques cas, j'avoue, l'enchaînement de requêtes est tellement compliqué que les reconstituer dans un script serait ingérable et là un puppeteer peut sauver le coup.Je ne peux pas dire si cela suffirait dans ton cas car tu cites pas les sites à démerdifier et tu as bien raison.
# MeteoFrance et ses services dédiés
Posté par azerttyu (site web personnel) . Évalué à 4 (+3/-0).
Hello
MeteoFrance fournit des services dédiés aussi.
Par exemple https://aviation.meteo.fr/ c'est assez brut, mais on y trouver les informations locales dont les fronts, l'évolution du temps significatif, le radar, …
Celui ci étant orienté air, tu as les informations locales TAF et METAR donc par forcément adapté à ton cas d'usage.
De mémoire il existe également des équivalents pour le maritime et la montagne (c'est qu'utilise entre autre les office de tourisme).
[^] # Re: MeteoFrance et ses services dédiés
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
Oui, AEROWEB, c'est pas le mieux qu'on puisse faire en la matière.
Dans le même genre, il y avait OLIVIA pour la préparation et le dépôt de plan de vol (austère, fouillis et obscur), mais à présent SOFIA a pris sa place. Je viens de regarder et c'est 1000X mieux.
https://sofia-briefing.aviation-civile.gouv.fr/sofia/pages/prepavol.html
La météo marine de Météo France est plutôt bien je trouve.
Plage
https://meteofrance.com/meteo-marine/port-de-bouc/570247
Côtière
https://meteofrance.com/meteo-marine/frontiere-belge-baie-de-somme/BMSCOTE-01-01
Large
https://meteofrance.com/meteo-marine/large/finisterre/BMSLARGE-01-07
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: MeteoFrance et ses services dédiés
Posté par azerttyu (site web personnel) . Évalué à 2 (+1/-0).
Hello
Sofia ne répond pas au même besoin.Comme tu le dis c'est pour la préparation de vol avec la possibilité de déposer un plan de vol et avoir les notam à jour.
La partie méteo de sofia est un renvoi vers les temsi de aeroweb. Et il manque certaines information utile comme la carte de front.
Mon propos tournait plutôt sur le fait que meteofrance reste une source fiable et de qualité et peut fournir des services spécialisés pour certains usages.
Sachant que la prévision météo est parfois plus un art qu'autre chose. Malgré de ce que j'ai suivi avec la réduction de leur effectif cela reste la meilleure expertise sur ces questions.
Autrement J'aime bien windy qui présente la méto dynamiquement mais cela vient en complément d'autres sources. Ce n'est pas à mon sens une source dîte fiable.
# ahhhhhhh...
Posté par tkr . Évalué à -3 (+1/-5). Dernière modification le 26 octobre 2024 à 10:24.
.."mais vous pouvez pas vous contenter d'un smartphone gafamisé, comme tout le monde?" ;-)
[^] # Re: ahhhhhhh...
Posté par Marotte ⛧ . Évalué à 0 (+0/-3).
Il dit précisément que non et explique pourquoi. Par ailleurs on peut être content de ce qu’offre les GAFAM, mais ne pas se contenter d’être seulement content. :)
Ça a toujours été une éternité une décennie en matière d’informatique, d’électronique en général. Je trouve personnellement c’est un minimum pour une durée de vie d’un terminal informatique ou appareil électronique, vraiment un minimum, mais les chantres du consumérisme associés aux obsédés du bit considèrent à priori que supporter entièrement un terminal qui a cinq ans ça relève de l’écologie radicale. Ils visent plus volontiers à jouir de ce qu’offre la matériel dernier cri sorti depuis le dernier salon CES, car ce sont pas des mormons !
# Et euh t'as envoyé tout ça sur quel genre de terminal ?
Posté par Thomas Douillard . Évalué à 8 (+5/-0).
J'ai un type sur Apple II
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.