Special cases: Produce yearly reports for all sections

[why-not-try-calmer]

This PR:

• adds support for the option to generate yearly reports for all sections related to a single installation / count
• adds (a lot of) test data and a handful of tests to make sure yearly and default reports are exhaustive

[why-not-try-calmer]

@spch-GL Je cherche toujours à reproduire le problème en utilisant le jeu de données "EGAS".

Pour mon test j'ai besoin d'identifier la section concernée. Le champs place_name du modèle Installlation n'a aucune entrée sous Bevaix Ouest - RC5:

Installation

Résultats

Comment puis-je identifier la section concernée?

[why-not-try-calmer]

Ah autant pour moi j'ai retrouvé ton message qui spéficie installation id: 53309999

[spch-GL]

Cela concerne les 6 sections avec comptages ci-dessous:

C'est bien cette installation:

[spch-GL]

Voici l'extrait de la table lane correspondant
wkt_geom id number direction direction_desc id_installation id_section
NULL 17514 1 1 8768 00056200
NULL 17515 2 2 8768 00056200
NULL 17516 3 1 8768 00056202
NULL 17517 4 2 8768 00056202
NULL 17518 5 1 8768 53316875
NULL 17519 6 1 8768 53326880
NULL 17520 7 1 8768 53336885
NULL 17521 8 1 8768 53346890

[why-not-try-calmer]

@spch-GL Le problème "key error" qui survient ici et dans 1-2 autres Pull requests provient du fait qu'une certaine requête à la base de données retourne un résultat vide. Pour faire simple, est-ce que tu peux confirmer le postulat suivant (qui est fait dans les tests): S'il existe un comptage pour l'installation i référencée par les voies V référençant entre toutes les sections S, alors pour chaque section s parmi les S, il existe un détail de comptage (CountDetail) cd tel que cd correspond à s?

[why-not-try-calmer]

L'erreur exposée dans ce test suggère que ce posultat est faux (ou alors que j'ai moi-même commis une erreur).

[spch-GL]

Je pense effectivement que c'est faux. Si tu essayes sur l'installation EGAS (cas spécial) en 2021 cela fonctionne ?
Puisque, une des voies n'a vu aucun véhicule passer

[spch-GL]

Le lien étant réalisé dans la table lane, à quoi sert le postulat ?

[why-not-try-calmer]

Le lien étant réalisé dans la table lane, à quoi sert le postulat ?

C'est pour vérifier si j'ai compris la logique implicite du plugin. J'essaie de comprendre pourquoi les instructions suivantes renvoient parfois un résultat vide:

start = ...
end = ...
installation = ...
count = ..., installation, ...

# toutes et seules les sections dont les
# lanes sont observées par l'installation arbitraire
# définie plus haut et ont chacune un CountDetail
# correspondant au Count abritraire défini plus haut
sections = models.Section.objects.filter(
    lane__id_installation=installation.id,
    lane__countdetail__id_count=count.id
).distinct()

for section in sections:
    details = models.CountDetail.objects.filter(
        id_lane__id_section=section,
        id_category__isnull=False,
        timestamp__gte=start,
        timestamp__lt=end,
    )
    # ? `details` est vide ?
    # puis plus loin:
    # KeyError: 'date'

[spch-GL]

Un count se rapporte toujours à une seule installation, mais une installation peut concerner plusieurs count.
Une installation se réfère à une ou plusieurs lane, qui peuvent appartenir à plusieurs section (si c'est un cas spécial)

Dans l'interface, on doit sélectionner une section.
Gràce à elle, on peut trouver la première lane concernée, et donc l'installation. A partir de l'installation, on retrouve toutes les lane concernées et aussi tous les count concernés

Mais je ne comprends pas bien to code.
Pour mieux orienter ma réponse, j'aurais aimé un script SQL afin de déterminer tous les count_detail vide sur ma base de prod.

[why-not-try-calmer]

SELECT
    "count_detail"."import_status",
    DATE_TRUNC(
        'day',
        "count_detail"."timestamp" AT TIME ZONE 'Europe/Zurich'
    ) AS "date",
    EXTRACT(
        'hour'
        FROM
            "count_detail"."timestamp" AT TIME ZONE 'Europe/Zurich'
    ) AS "hour",
    SUM("count_detail"."times") AS "thm"
FROM
    "count_detail"
    INNER JOIN "lane" ON ("count_detail"."id_lane" = "lane"."id")
WHERE
    (
        "count_detail"."id_category" IS NOT NULL
        AND "lane"."id_section" = 53326880
        AND "count_detail"."timestamp" >= 2021 -01 -01 00 :00 :00 + 01 :00
        AND "count_detail"."timestamp" < 2022 -01 -01 00 :00 :00 + 01 :00
        AND "lane"."direction" = 2
    )
GROUP BY
    DATE_TRUNC(
        'day',
        "count_detail"."timestamp" AT TIME ZONE 'Europe/Zurich'
    ),
    EXTRACT(
        'hour'
        FROM
            "count_detail"."timestamp" AT TIME ZONE 'Europe/Zurich'
    ),
    "count_detail"."import_status"
ORDER BY
    "date" ASC,
    "hour" ASC

[spch-GL]

Afin qu'elle soit valide, j'ai dû modifier la clause WHERE ainsi:

WHERE
    (
        "count_detail"."id_category" IS NOT NULL
        AND "lane"."id_section" = '53326880'
        AND "count_detail"."timestamp" >= '2021-01-01 00:00:00 + 01:00'
        AND "count_detail"."timestamp" < '2022-01-01 00:00:00 + 01:00'
        AND "lane"."direction" = 2
    )

La requête ne retourne rien
Si je supprime le AND "lane"."direction" = 2, ou si je le mets à 1, alors je reçois 8481 enregistrements

[spch-GL]

Une remarque:

• thm = Traffic Horaire Moyen

Mais dans la requête il n'y a pas de calcul de moyenne, c'est le trafic horaire constaté

[spch-GL]

Encore une remarque:
La direction 1 est la direction principale pour un section, du coup lorsqu'il n'y a qu'une seule voie, il n'y a rien dans la direction 2

[why-not-try-calmer]

Afin qu'elle soit valide, j'ai dû modifier la clause WHERE ainsi:

WHERE
    (
        "count_detail"."id_category" IS NOT NULL
        AND "lane"."id_section" = '53326880'
        AND "count_detail"."timestamp" >= '2021-01-01 00:00:00 + 01:00'
        AND "count_detail"."timestamp" < '2022-01-01 00:00:00 + 01:00'
        AND "lane"."direction" = 2
    )

La requête ne retourne rien Si je supprime le AND "lane"."direction" = 2, ou si je le mets à 1, alors je reçois 8481 enregistrements

Ah voila qui est intéressant! Le code original, dans la fonction _data_day_yearly, ainsi que la plupart des fonctions du module statistics.py, présupposent que les deux directions existent. Apparemment cette présupposition n'a pas posé problème, donc je suis doublement surpris (surpris de faire une telle présupposition alors qu'elle est contredite par les données, surpris que ç'a ait marché jusqu'à présent).