Closed flacombe closed 3 years ago
flacombe
commented
3 years ago A bien réfléchir, je me suis peut-être perdu dans le besoin exact.
Un truc bien plus simple pour ne pas tout chambouler serait de pouvoir simplement ajouter une nouvelle source. Elle permettrait d'afficher des tuiles vectorielles venant d'une source tierce avec des points équivalents à ceux produits dans le tuilage actuel.
Charge ensuite à chaque projet (ici Enedis) de leur donner le sens qu'il souhaite.
PanierAvide
commented
3 years ago Salut,
Quelques remarques / commentaires en vrac, pas sûr que ça fasse avancer le schmilblick mais sait-on jamais ?
Au final si on voulait résoudre la plupart des problèmes cités, il faudrait ne pas filtrer sur l'operator en entrée : prendre tous les poteaux / postes, quelque soit la valeur. C'est ce que l'on fait sur les autres configurations (ex recharge de véhicules électriques, on les prends tous, police on prend tout que ce soit police nationale/municipale/gendarmerie...). Ça résoudrait les problèmes de visibilité, mais le problème serait la surévaluation du nombre de poteaux enedis dans les stats ?
Est-ce qu'on a pas envie de travailler sur un affichage de stats qui prendrait mieux en compte les enseignes / opérateurs ? Genre à la diagramme camembert en plus dans les stats qui vient préciser la répartition du tag brand/operator/network... selon le projet (configurable du coup). Tu penses que ça pourrait suffire pour résoudre ça ?
Dans cette veine là, la couche osm-compare pourrait être adaptée (ou dupliquée en partie) pour gérer les potentiels erreurs de tags à la base. Genre "osm-fixable", avec une logique d'édition différente (au lieu de créer un nouvel objet avec tags en partie préremplis, ça vient écraser les tags problématiques).
Après en solution alternative / complémentaire, le fait d'avoir des couches vectorielles bonus pourrait être utile, de la même manière que la couche mapillary ou les couches raster.
flacombe
commented
3 years ago Merci pour ton retour, en effet je pense qu'il faut rester simple.
Toucher au filtre qui défini vraiment le projet, pour prendre tous les opérator dans mon cas amènerait trop de problème en aval.
Je vais déjà faire l'ajout de couches vectorielles en plus, ca sera plus utile pour tout le monde L'idée de osm-fixable est bonne aussi, après réflexion il faut passer par osmose pour ça en fait, ca permet de ne pas dupliquer la logique de correction.
PanierAvide
commented
3 years ago OK pour le vectoriel, ce sera clairement plus de souplesse.
C'est sûr que passer par Osmose ça simplifie encore davantage, c'est plus qu'une histoire de config à renseigner dans le fichier JSON :grin:
flacombe
commented
3 years ago Avec la merge de ce matin, je clos ce ticket. Les deux sources ont été intégrées de la façon suivante :
osm-extra
Hello
Le projet Enedis pose actuellement une problématique pas évidente. Je pense avoir à gérer deux nouvelles catégories d'objets OSM qui jusque là n'ont pas été nécessaires dans les autres projets du mois :
operator). Jusqu'à maintenant ils étaient tout simplement masqués par le filtre imposm. Ils n'apparaissent pas dans l'éditeur intégré et du coup certains contributeurs pensent devoir les ajouter, en doublon de ce qui existe déjà dans OSM.Ces objets à intégrer ne sont pas des notes, ils n'iraient pas dans la couche des notes. Ils ne me semblent pas convenir à la couche osm-compare, sauf erreur. Les exclus ne vont dans aucune couche existante.
Ils doivent tous deux apparaître dans l'éditeur intégré, les exclus pour ne pas tenter les contributeurs d'un ajout en doublon et les incomplets pour inciter les contributeurs à les compléter.
Deux solutions techniques me semblent intéressantes :
Preneur de vos commentaires