ForHosting KIT · Sciences

Demande en eau

Dix mille personnes consommant 150 litres chacune demandent 1 500 000 litres par jour et 547 500 000 litres par an. Indiquez la population et la consommation par habitant pour dimensionner un réseau ou comparer une commune à une référence. Gratuit dans votre navigateur.

  • Gratuit
  • Fonctionne dans votre navigateur
  • Sans inscription
  • Vos données restent sur votre appareil
Utilisez-le depuis WebAPIE-mailTelegramApp bientôt
Si vous saisissez
Population
10 000
Litres par habitant
150
Vous obtenez
Litres par jour
1 500 000
Litres par an
547 500 000
Jours de l'année
365

La demande municipale et communautaire en eau est le volume qu'une zone de desserte prélèvera si l'on sait combien de personnes y vivent et combien de litres chacune utilise par jour. Les services d'eau, les urbanistes, les consultants environnementaux et les étudiants en ressources en eau ont besoin de ce produit comme total quotidien et comme total annuel pour dimensionner des usines de traitement, comparer une ville à un référentiel publié de litres par personne et par jour, et placer une année de prélèvements à côté du budget d'un réservoir. Ce calculateur de demande en eau accepte une taille de population et une consommation quotidienne par habitant en litres, les multiplie pour la demande quotidienne, puis multiplie le total quotidien par 365 pour la demande annuelle, les deux en litres. Zéro est admis et renvoie zéro litre, car une zone vide ou un scénario de consommation nulle ne demande vraiment rien.

Comment la demande en eau se calcule à partir de la population et du LPCD

Au premier ordre, la demande communautaire en eau n'est ni un modèle météorologique ni une simulation de réseau de canalisations : c'est le produit de deux grandeurs qu'un planificateur possède déjà ou peut supposer. La population est le nombre de personnes desservies — un décompte de recensement, une projection d'horizon de conception, l'occupation d'un camp de réfugiés ou les résidents d'un lotissement. La consommation quotidienne par habitant est le nombre de litres que chacune de ces personnes utilise en un jour, noté LPCD dans les tables d'ingénierie de l'eau.

Les chiffres publiés vont typiquement d'environ cinquante litres par personne et par jour dans une desserte rurale rationnée, à cent à deux cents dans de nombreux réseaux urbains, jusqu'à trois cents ou plus lorsque l'irrigation extérieure et les fuites de distribution dominent. La demande quotidienne en litres égale la population fois ce chiffre par habitant. La demande annuelle égale le total quotidien fois 365, le décompte civil de jours utilisé pour les budgets annuels de réservoir et d'usine.

Dix mille personnes à cent cinquante litres chacune demandent donc un million cinq cent mille litres en un jour et cinq cent quarante-sept millions cinq cent mille litres en un an. Un quart de million de personnes à cent quatre-vingts virgule cinq litres chacune demandent quarante-cinq millions cent vingt-cinq mille litres par jour.

La méthode n'ajoute pas l'eau non comptabilisée, les charges industrielles en bloc, les facteurs de pointe saisonniers ni les réserves de débit incendie ; cela appartient à un modèle complet de schéma directeur que vous pouvez superposer après avoir cette base. Changez l'une ou l'autre entrée et les deux totaux bougent de concert.

Cette page n'est pas un calculateur d'apport personnel en eau potable, une page de capacité de citerne ni une page de gaspillage d'un robinet qui goutte : celles-là répondent à ce qu'un corps doit boire, à ce qu'un récipient contient ou à ce qu'une fuite a déjà perdu — non à ce qu'une population prélèvera sur le réseau.

Ce qu'il faut saisir : habitants et litres par personne

Une population fractionnaire est admise pour qu'une estimation de milieu d'année telle que 12500.5 n'ait pas à être arrondie d'abord, et un LPCD fractionnaire est admis pour qu'un 137.4 litres par personne et par jour mesuré soit envoyé tel quel. Les champs manquants, chaînes vides, booléens, objets et jetons qui ne sont pas des décimaux simples ou une notation scientifique échouent de la même façon. Zéro est accepté et renvoie zéro litre, parce qu'une zone vide ou un scénario de consommation nulle ne demande vraiment pas d'eau.

Les nombres sont arrondis à douze décimales afin que goldens et clients comparent octet par octet entre exécutions. Si le produit déborde vers Infinity, la tâche échoue plutôt que de renvoyer un volume non fini. L'année est l'année civile exacte de 365 jours utilisée en demande de criblage, non 365.25 et non un calendrier bissextile, de sorte qu'un total annuel est reproductible à partir des mêmes entrées sur chaque machine.

Qui planifie avec la demande en eau d'une commune

Les services d'eau et les ingénieurs municipaux utilisent un calculateur déterministe de demande en eau pour transformer une population de recensement et un LPCD publié ou mesuré en litres quotidiens et annuels à placer à côté de la capacité d'une usine, au lieu de citer un slogan sur ce qu'une ville consomme.

Les campagnes climat et conservation qui demandent de comparer leur ville à une cible de cent litres de LPCD peuvent envoyer les deux mêmes nombres que le visiteur a déjà saisis et afficher le prélèvement annuel sans inventer un taux de consommation. Une validation échouée ne consomme pas le solde. Gardez les requêtes petites, figez les champs arrondis dans les tests, et vous obtenez un produit de demande reproductible sans dresser votre propre intégration de facturation.

Si vous avez ensuite besoin d'un coût en monnaie, multipliez les litres par votre tarif local ; ce point d'accès s'arrête exprès au volume.

Demande préliminaire municipale

Transformez une population de recensement et un LPCD publié en litres quotidiens et annuels à placer à côté de la capacité d'une usine ou du budget d'un réservoir.

Comment calcule-t-on la demande en eau d'une population ?

La demande quotidienne en litres égale la population fois la consommation quotidienne par habitant en litres. La demande annuelle égale ce total quotidien fois 365. Dix mille personnes à 150 litres chacune donnent 1,500,000 litres par jour et 547,500,000 litres par an.

Quelle valeur de LPCD devez-vous utiliser ?

Utilisez un chiffre mesuré ou publié de litres par personne et par jour pour la zone de desserte. Les valeurs typiques de criblage se situent près de 50 L dans une desserte rurale rationnée, 100–200 L dans de nombreux réseaux urbains, et 300 L ou plus lorsque l'irrigation et les fuites dominent. Le calculateur ne devine pas le LPCD.

Pourquoi l'année compte-t-elle 365 jours et non 365.25 ?

La demande de criblage utilise l'année civile de 365 jours pour que le total annuel soit reproductible et corresponde aux budgets annuels des services d'eau. Les ajustements d'année bissextile et d'année moyenne 365.25 appartiennent à un modèle de calendrier, pas à ce produit.

Que se passe-t-il si la population ou les litres par habitant sont négatifs ?

Une population négative ou un taux par habitant négatif n'est pas une demande physique. Zéro est admis et renvoie zéro litre. Une entrée invalide n'est pas facturée.

Est-ce la même chose que l'apport personnel en eau, et quel est le coût ?

Non. Cette page estime ce qu'une population prélèvera, non ce qu'une personne doit boire. L'outil du navigateur est gratuit.

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

POSThttps://api.kit.forhosting.com/eco/water-demand

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

curl -X POST https://api.kit.forhosting.com/eco/water-demand \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"population":10000,"per_capita_liters":150}'
{
  "population": 10000,
  "per_capita_liters": 150
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "eco.water_demand",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

HTTPCodeSignification
401unauthorizedClé API absente ou invalide : vérifiez l’en-tête Authorization.
402insufficient_balanceSolde insuffisant : rechargez votre compte pour lancer cette tâche.
404unknown_typeType de tâche inconnu : vérifiez le champ type de votre requête.
429rate_limitedTrop de requêtes : ralentissez la cadence, puis réessayez.

Une population négative ou un usage par habitant négatif échoue avec invalid_input au lieu d'inventer un prélèvement.

Entrées, unités, alias et comportement d'erreur

Envoyez un objet JSON avec deux nombres finis obligatoires : population, le nombre de personnes de la zone de desserte ; et per_capita_liters, la consommation quotidienne de chaque personne en litres. Chaque champ accepte aussi une chaîne numérique et une courte liste d'alias (pop, people, inhabitants, n, lpcd, liters_per_capita, daily_per_capita, consumption, per_capita) afin que tableurs et formulaires n'aient pas à renommer les colonnes. Toute valeur négative est rejetée : une population négative ou un taux par habitant négatif n'est pas une demande physique, donc la tâche échoue avec invalid_input qui nomme le champ. En cas de succès, la réponse répète population et per_capita_liters résolus, puis indique daily_liters comme population fois LPCD, annual_liters comme daily_liters fois 365, days_in_year toujours égal à 365, une chaîne de formule compacte et l'étiquette de méthode population_times_lpcd_times_365. Il n'y a ni consultation réseau, ni tirage aléatoire, ni dépendance à la date du jour ou aux calendriers bissextiles : les deux mêmes nombres produisent toujours le même JSON.

Où une API de demande en eau justifie son existence

Les consultants qui consignent déjà les populations de zone de desserte peuvent envoyer une tâche par communauté et stocker daily_liters et annual_liters à côté de l'identifiant de la zone sans ouvrir un tableur de facteurs de 365 jours. Parce que l'implémentation est du parse pur de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant. Si vous avez ensuite besoin de la demande d'heure de pointe ou de jour maximal, appliquez votre propre facteur de pointe à daily_liters ; le produit de base reste auditable et inchangé.

Lots de zone de desserte du consultant

Envoyez une tâche par communauté avec la population consignée et les litres par habitant, puis stockez daily_liters et annual_liters à côté de l'identifiant de la zone.

Widgets de classe et de campagne

Laissez les visiteurs saisir une population et une cible de LPCD et voir la demande quotidienne et annuelle sur un outil en direct qui coïncide avec l'API octet par octet.

Consulter la documentation complète du KIT →