Décomptes différents entre stats géographiques et stats nationaux

[flacombe]

Les différents procédés qui nous permettent de calculer les stats nationaux vs les stats géographiques ne permettent pas de calculer les mêmes indicateurs.

Dans les stats nationales osmium nous permet de compter jour après jour les objets qui répondent effectivement au filtre du projet. Ainsi un objet existant depuis deux ans ne sera comptabilisé que lorsqu'il aura tous les tags nécessaires (cf #153)

Dans les stats géographiques, particulièrement dans la méthode proposée dans #185 Les périodes d’existence des objets connus au jour J sont établis entre les actions create et delete de la table pdm_changes. Les delete sont bien pris en compte, certaines courbes locales peuvent donc décroître. Ainsi nous ne savons pas si à la création de l'objet il dispose des attributs compatibles avec le filtre du projet. Pour l'instant, les variations dans les courbes des stats géographiques montrent les créations brutes d'objet et non les éditions qui en redent d'autres compatibles bien après leur création.

Je suggère donc d'améliorer la détermination du start_ts pour chaque objet et prendre en compte le filtre du projet. Pour l'utilisateur les chiffres affichés seront plus cohérents (en faisant la somme de toutes les régions on retrouve le national) et pour nous, on aura une connaissance plus fin des éditions et de leur qualité (en rapport avec #178).

Qu'en pensez-vous ?

[PanierAvide]

En soit on peut faire ça oui, comme dans pdm_changes qui sert de base de calcul pour les régions on a bien les tags embarqués. On pourrait filtrer dessus. Si on a des stats cohérentes entre national et local, on pourrait même se débarrasser des comptages Osmium pour le national, et dériver ça des régions.

[flacombe]

Excellente idée.

D'autant plus intéressante que ce genre de changeset : https://osmcha.org/changesets/100641353/ supprimant près de 4000 objets du périmètre du projet (retrait d'un attribut) se voit au niveau national grace à osmium mais ne se voit pas sur la région Auvergne Rhone Alpes.

On va avoir deux gros problèmes à résoudre :

• Confronter le filtre du projet aux tags affichés dans pdm_changes (je n'arrive pas à savoir si la colonne tags de cette table donne tous les tags de l'objet édité à la version concernée ou bien uniquement les tags modifiés)
• Les objets qui apparaissent / disparaissent plusieurs fois, parce que dans #185 dans pdm_features_boundary, on considère une seule plage temporelle start/end alors qu'il pourrait y en avoir plusieurs en réalité au gré des edit/reverts.

Ce serait peut-être bien d'ajouter la version dans pdm_features_boundary de #185. La version ayant systématiquement un start/end, on a plus besoin de déterminer si c'est un ajout/edit/suppression. La version est ou n'est pas conforme au filtre du projet.

Deux versions ne se recouvrant pas, on peut les dénombrer comme les objets. Donc un objet pourrait ainsi apparaitre ou disparaitre au gré de la conformité avec le filtre du projet.

[PanierAvide]

Dans pdm_changes, c'est bien tous les tags présents à date qui sont renseignés. Ça veut aussi dire qu'à la suppression (action=delete), la liste des tags est vide.

Je suis pas sûr de l'ordre par lequel on peut procéder pour tous les sujets (tuiles, stats communes, histoire des valeurs à 0...). Comment on priorise ?

[overflorian]

Je propose de prioriser ainsi :

1. on corrige les problèmes bloquants (comme les valeurs à 0)
2. on améliore/homégénise les stats (en se basant sur pdm_changes)
3. on améliore la présentation : l'interface avec les boutons et le fond de carte

De mon coté, je peux avancer seul sur le fond de carte en attendant que vous avanciez sur le reste. Banco ?

[flacombe]

Banco !

Merger #185 reste la priorité, il reste quelques points à voir mais c'est pas méchant

[flacombe]

J'ai commencé à travailler sur l'implémentation de cette convergence entre stats géographiques et décomptes nationnaux. Se pose le problème des géométries permettant d'assigner les versions aux limites administratives.

Un objet supprimé à la date t peut néanmoins compter dans les stats d'une zone à un moment donné antérieur. On ne connait néanmoins que les géométries des versions existant à la date t, pas les précédentes et c'est un problème.

On pourrait conserver au fil du temps un historique des correspondances versions/zones administratives mais ne serions pas en mesure de reconstituer cet historique lors d'un recalcul du projet, qui arrive ponctuellement et doit toujours être possible. Je bloque là dessus, je trouve que c'est dommage

[PanierAvide]

Peux-tu prendre un exemple concret (même fictif) pour détailler ce qui pose souci ? Je vois pas comme ça à quel niveau ça bloque.

[flacombe]

Oui, voici un chronogramme de 4 situations représentatives

Les features 1 et 2 posent des problème actuellement aux stats géographiques puisqu'elles ne sont pas comptées aux dates auxquelles elles existent au cours du projet. Elles le sont en revanche pour les stats nationales avec osmium.

La Feature 3 est le cas classique pour pdm

La feature 4 va potentiellement poser un problème si elle est déplacée entre la V1 et V2 en changeant de zone administrative.

[PanierAvide]

OK c'est beaucoup plus clair, merci. Le problème principal c'est donc que pdm_changes ne liste que les modifications durant la période du projet, là où il faudrait avoir une vue de toutes les modifications à travers les âges pour avoir un décompte exact. Je vois deux solutions :

• Garder l'existant (en soi le comptage tel quel fonctionne)
• Générer la liste des modifications sur les objets du projet depuis 2004 au lieu de depuis le début du projet du mois. Ça veut dire une table pdm_changes beaucoup plus conséquente, et probablement des goulots d'étranglement à la génération de cette liste de modifications

[flacombe]

Le problème principal c'est donc que pdm_changes ne liste que les modifications durant la période du projet

Non, la table pdm_change contient bien des changements bien en dehors de la plage du projet. Le problème est que nous n'avons que les géométries des versions actuelles. Ainsi il n'est pas possible d'associer les anciennes versions aux zones administratives pour calculer les stats géographiques. C'est particulièrement handicapant pour les objets supprimés qui pourraient compter à des dates antérieures (c'est le cas de feature2/V1 sur mon schéma, qui compte dans le 2 du T2). Ce sera aussi un problème pour feature1/V1.

Ici le ST_Intersect est fait sur la géométrie actuelle alors qu'il faudrait le faire sur la géométrie correspondant à la version. https://github.com/vdct/ProjetDuMois/blob/master/db/13_changes_boundary.sql#L6

Si on fait les dénombrement tous les jours sans jamais recharger la base complètement, on ne s'en apercevra pas. Le soucis se pose en cas de recalcul complet, ce qui doit toujours rester possible pour couvrir les ajouts de fonctionnalités en cours de route.

[flacombe]

Discussion en cours sur la mailing list dev.

Roland indique un soucis qui empêcherait de reconstituer la géométrie des ways en retrouvant les noeuds membres : certains diff passent en retard https://lists.openstreetmap.org/pipermail/dev/2021-March/031138.html

Du coup les deux solutions les plus probables, pas satisfaisantes de mon point de vue :

• Maintenir une database full permettant de retrouver toutes les géométries de toutes les version, mais bien plus lourd
• Utiliser les augmented diff de l'Overpass API, avec un potentiel risque sur la quantité de données à rapatrier. Les projets durent jusqu'à 3 ans pour Enedis. Pas sûr que ca marche.

Je suis encore en attente de réponse de leur part pour évaluer la faisabilité

[PanierAvide]

Si on travaille avec osmium, l'historique complet et des exports sur la base des identifiants de noeuds concernés (osmium get-id) on devrait pouvoir s'en sortir sans dépendance tierce ni remonter de base complète ?

[mmd-osm]

(apologies, I'm commenting in English, hope that's ok. You can answer in French though, if you like.)

Augmented diffs are generated by executing a query at two given points in time, and then comparing both results. As an example:

http://lz4.overpass-api.de/api/augmented_diff?id=4254509&debug=true

corresponds to the following query:

data=[adiff:"2020-10-14T19:24:00Z","2020-10-14T19:25:00Z"];(node(changed:"2020-10-14T19:24:00Z","2020-10-14T19:25:00Z");way(changed:"2020-10-14T19:24:00Z","2020-10-14T19:25:00Z");rel(changed:"2020-10-14T19:24:00Z","2020-10-14T19:25:00Z"););out meta geom;

I'm assuming you don't need global coverage, and more importantly, you could specify the exact tags you're interested in, rather than querying for any possible change in a given period of time, like in the case of augmented diffs.

[timeout:1000]
[adiff:"2021-01-10T00:00:00Z","2021-01-11T00:00:00Z"];
area[name="France"];
way[amenity=restaurant](area);
out geom meta;

Another option: you could extract all geometries at a given point in time in the past. In a next step load these Overpass results into a PostgreSQL db and match object geometries against your (previously loaded) 40k boundaries to extract your KPIs for one day.

Overpass attic is based on timestamps, rather than object versions. Still it could be an alternative to "maintenir une database full permettant de retrouver toutes les géométries de toutes les version,"

Most likely you would need your own Overpass instance, and then run many queries in parallel to backfill data over a larger period of time.

[date:"2021-01-10T00:00:00Z"];
area[name="France"];
(way[amenity=restaurant](area);>;);
out meta;

(bbox may be faster than area, some more testing/tuning will be needed).

Roland indique un soucis qui empêcherait de reconstituer la géométrie des ways en retrouvant les noeuds membres : certains diff passent en retard

That's not relevant for your use case, unless you're running near-realtime analysis.

[flacombe]

Hi Mmd and thank you to come here and provide us additional ellaboration about augmented diffs.

It sounds interesting to be used on our projects, particularly to reload past data while normal updates could run with usual imposm minute diffs.

Augmented diffs are generated by executing a query at two given points in time, and then comparing both results.

Will it return all changes between those two time points or will it return only currently existing objects created during the selected time period ? (i.e will I get deleted features with it?)

Will I be able to get all V1 of this chart with such a query? https://github.com/vdct/ProjetDuMois/issues/188#issuecomment-802221915

I'm assuming you don't need global coverage, and more importantly, you could specify the exact tags you're interested in

That's right and particularly efficient this way!

Another option: you could extract all geometries at a given point in time in the past.

That would be a least efficient way but nearer of the current architecture. I'll study it depending on your answers to my questions upside.

bbox may be faster than area, some more testing/tuning will be needed Got it thank you.

As we intend to link features to admin boundaries, it's easy to reject any feature that doesn't match any boundary.

unless you're running near-realtime analysis

No, indeed

To me, using augmented diffs sounds really interesting to fill the whole period of a given project with tag filtering. It's only a recovery feature, when database should be truncated for maintenance or improvements. Normal service will be ensured by incremental processing with imposm and minute diffs.

How do you feel about an augmented diff query covering ~11 million features over a 3 years span? I guess it will require a dedicated overpass API instance right?

Note that OSM France already maintain a local instance we could use as well

[mmd-osm]

Will it return all changes between those two time points or will it return only currently existing objects created during the selected time period ? (i.e will I get deleted features with it?)

It works more like a time machine. You travel to t_0, and determine all objects which existed at the point in time. Then you travel to t_1, and again check all objects which exist at the time. It might happen that an object has been created and deleted again somewhere between t_0 and t_1, and such an object would not be included in the augmented diff. That's a major difference to how osc files work, as they include every possible change in a given time internal.

Augmented diff by definition only compare two points in time, and you might miss such objects, which only existed for a very short amount of time. This may or may not be an issue for a long term statistical analysis. Most likely such effects will be negligible.

How do you feel about an augmented diff query covering ~11 million features over a 3 years span? I guess it will require a dedicated overpass API instance right?

Yes, definitely, you would need your own instance. It might be that you would also need a tuned Overpass version as well with more speed and less memory requirements. It's very hard to tell without some testing.

What kind of features do you plan to query? 11 million sound like quite a lot. I could check, how long this would take today to give you some idea.

Note that OSM France already maintain a local instance we could use as well

Well, you would need very fast SSD, use lz4 as database compression, and similar changes. I'm not sure, if this instance already fulfills these requirements.

[flacombe]

Thank you for extra details

The project I often refer to is the French power poles one: https://enedis.openstreetmap.fr/projects/2021-01_poteaux OpenStreetMap France entered in a 3 years partnership with national power distribution operator and we look for 11 million of power poles over whole French mainland. https://www.openstreetmap.org/user/InfosReseaux/diary/396044 That's the biggest project we yet have to achieve with ProjetDuMois, I intend to design things to deal with according amounts of features.

That's a major difference to how osc files work, as they include every possible change in a given time internal.

That's indeed a difference we should think about. In one hand, we could recover back at week scale instead of day scale to save time and database space. A week is enough for a 3 years project and we could adjust this scale for shorter projects. On the other hand it would prevent us to properly reward users that commit changes we don't see when querying at week scale.

If I got you correctly, on a longer time range like one week we could get some modify actions with objects changing from version 4 to 7 if they were edited 3 times during this week, right? With no possibility to get version 5 and 6.

If I update the chart upside with an a-diff going from T1 to T3, this would lead to miss feature1/V2 and feature2/V1 and don't change the T2 count, for wrong reasons though (counting feature1/V1 instead of feature2/V1). Features version matching the project filter are in black and other in grey.

As filtering while querying is a big plus, I still consider this opportunity to use augmented diffs.

According to you, what is the heaviest to maintain: an overpass api instance with augmented diffs or a full database covering metropolitan France only?

I'll discuss with the French tech team how they feel about upgrading our instance with appropriate lz4 database.

Thank you very much for your inputs

[mmd-osm]

If I got you correctly, on a longer time range like one week we could get some modify actions with objects changing from version 4 to 7 if they were edited 3 times during this week, right? With no possibility to get version 5 and 6.

Yes, that's correct, version 5 and 6 won't be included. However, based on the information returned by the query, you can find out, that those two versions are missing. Possible options include:

• you could request the full history for those objects and backfill your local database,
• trigger some additional queries to cover a smaller time range.

This could be a series of daily queries instead of one weekly query. The main question is, how frequently this happens, and if it is worth the effort. Daily queries would still run in a reasonable time. I measured a few minutes here for all power=* in France:

[timeout:1000]
[adiff:"2021-01-10T00:00:00Z","2021-01-11T00:00:00Z"];
area[name="France"];
(nwr[power](area)(changed:"2021-01-10T00:00:00Z","2021-01-11T00:00:00Z");>;);
out meta;

or

[timeout:1000]
[adiff:"2021-01-10T00:00:00Z","2021-01-11T00:00:00Z"];
area[name="France"];
nwr[power](area)(changed:"2021-01-10T00:00:00Z","2021-01-11T00:00:00Z");
out meta geom;

what is the heaviest to maintain: an overpass api instance with augmented diffs or a full database covering metropolitan France only?

This is a bit difficult to answer. Obviously, it's not feasible to run the original augmented diffs on a global scale with each augmented diff only covering a one minute interval. Also, I wouldn't start with a 2012-sep Overpass database, which includes 9 years of attic data (like the one you can clone from https://dev.overpass-api.de/clone/). As your project only starts now, you could save some space by starting with a more recent planet, and apply minutely diffs.

Unfortunately, I'm not familiar with the details of the "full database scenario". Would this be Postgis based, and how do you store the full history, including all geometry changes?

I'll discuss with the French tech team how they feel about upgrading our instance with appropriate lz4 database.

It may be easier to even consider a separate Overpass instance.