Même sans API OSM pour le faire, il y a moyen de développer des outils qui vont fouiller les évolutions "tag par tag" pour voir ce qui est réellement changé : la valeur du tag (modification, ajout ou suppression) ou la géométrie.
De tels outils peuvent se spécialiser par domaine (liste thématique des tags surveillés). Bref un outil de veille qualité comparable à Osmose, mais allant fouiller dans les dates des changesets, et utilisant des recherches de listes d'objets surveillés avec des requêtes façon Overpass (si nécessaire sur sa propre base locale importée et alimentée avec les diffs), pour ensuite alimenter sa base séparée de suivi thématique de ces objets (cette base thématique peut se réduire à uniquement ces objets). Un tel outil permettrait des statistiques thématiques pour savoir "où on en est" et mesurer zone par zone le degré de couverture et de fraîcheur pour ces objets, pourrait réalimenter automatiquement une tâche de type "maproulette" pour le passage en révision au delà d'un délai passé (ajustable en fonction des priorités, les plus anciens en premier) et un rendu des objets trouvés sur une carte comme le fait Osmose. Il commencerait au départ sur une thématique réduite (et dans une zone géographique limitée), ensuite si la base locale de suivi le permet, ajouter de nouvelles thématiques de suivi et étendre la zone géographique. Cette fonctionnalité au final pourrait aussi être ajoutée à Osmose, indépendamment de ses autres analyses de qualité existantes, qui pour l'instant ne visent pas à évaluer la fraicheur (ni réellement le degré de couverture sauf sur les sources de données externes "à intégrer"). Le sam. 25 avr. 2020 à 15:49, Marc M. <[email protected]> a écrit : > Bonjour Stuart, > > Je suis bien conscient que c'est totalement insuffisant. > mais je suis partisan de la politique des petits pas : > sans admin osm.org, même avec notre "accord" sur l'utilité > d'une metadata par tag, cela n'aura pas lieu à court terme > non seulement parce que api v0.7 n'est pas pour demain mais > surtout qu'il y a une résistance à l'envisager. > > Du coup je pense que le meilleur moyen pour que cela aboutise > un jour, c'est d'utilise ce qu'on a (les metadata par objet et > survey:date), montrer que c'est utile et qu'il y a une utilité > à aller + loin. > > donc je vise petit. si ta fontaine est aussi veille que > https://www.openstreetmap.org/way/46627516 > cela ne sert a rien de se poser la question de quand date > la dernier vérif du panneau "eau potable". > Par contre on peux facilement rajouter dans la liste > "eau potable : vérif toute les... 3 ans ?" > (valeur arbitraire, chaque utilisateur choisit ses priorités, > qui varient sûrement en fonction de la densité de point d'eau > dans les environs). > > Cordialement, > Marc > > Le 21.04.20 à 16:31, European Water Project a écrit : > > Bonjour Marc, > > > > De regarder la date de dernière change set d'un objet ou le tag > > survey:date d'un objet est certe beaucoup mieux que rien, mais me semble > > peu ambitieux par rapport à une solution avec du meta data au niveau > > clef. Par exemple, quelqu'un qui vérifie dans un survey, l'existence > > d'une fontaine, ne vérifiera pas systématiquement la potabilité de l'eau > > ou si l'eau coule. .. qq chose qui devrait être fait tous les x années > > selon le pays et la région. > > > > > https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap > > > > > > > > > > > > > A bientôt, > > > > > > > > > > > > Stuart > > > > > > > > On Tue, 21 Apr 2020 at 15:24, Marc M. <[email protected] > > <mailto:[email protected]>> wrote: > > > > Bonjour, > > > > Merci Stuart d'avoir relancé le sujet ici. > > > > Le 21.04.20 à 14:09, European Water Project a écrit : > > > Est-ce qu'OSMdevrait réfléchir à une durée de vie, si pas vérifiés, > > > pour certains tags ? > > > > je pense que oui, j'ai dans l'idée que nous pourrions construire > > communautairement une liste de catégorie, un peu comme celle de ta > page. > > l'important dans un premier temps n'est pas tant de mettre une durée > de > > vie sur des données mais de les classer relativement entre elle. > > > > exemple et ordre de grandeur qui me vient en tête : > > batiment en construction : vérif mensuel > > borne véhicule électrique : 6 mois > > commerce : vérif annuelle > > borne incendie : 2 ans > > caractéristiques des batiments existant : 10 ans > > > > les valeurs exacte importe peu (chacun devrait pouvoir choisir > > un multiple de celle-ci pour cibler d'abord le "pire" en terme > > de fraicheur) > > Mais un ordre de grandeur permet de faire des apps du genre : > > - si un objet importé n'a jamais été vu (au sens source=survey), > > proposer à quelqu'un de le valider (et donc améliorer souvent > > sa position et rajouter d'autre info. > > (c'est le sens de Geocropping) > > - si une zone en construction a + de X mois, > > demander au contributeur si c'est toujours en cours (il me semble > > que StreetComplete de déjà ce genre de chose) > > - si un commerce n'a plus été modifié depuis X temps, > > proposer de le vérifier. > > - si tu modifies un de ces poi avec source=survey, mettre > > à jour l'info fraicheur. > > - si tu modifies un objet avec une source (par ex image sat) + veille > > que la dernière vue sur le terrain, signaler/demander confirmation > > > > Cordialement, > > Marc > > > > _______________________________________________ > > Talk-fr mailing list > > [email protected] <mailto:[email protected]> > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > _______________________________________________ > > Talk-fr mailing list > > [email protected] > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
