-
Notifications
You must be signed in to change notification settings - Fork 3
Add aggregated power per socket type #15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C'est pour pouvoir mettre les socket:typee:output
et compagnie dans OSM je suppose ?
J'ai pas trop de compétences pour challenger la pertinence du retraitement, donc si t'es sur de toi, ça me va.
Est-ce que ça marche toujours si on a des stations de recharge pour vélo électrique ou pour camion qui finissent dans le fichier ?
Oui
|
pourquoi supprime-t-on ceux qui ont des coordonnées invalides ? on pourrait quand même faire le match avec la ref. c'est passé à 0 cas parce que tous les cas était un problème d'espace perturbateur ? pourquoi supprime.-t-on ceux qui ont une ref invalides ? on pourrait quand même faire le match avec la proximité géographique (le même match que propose osmose pour ajouter justement la ref... sauf qu'on peux ajouter le reste sans la ref, c'est mieux que rien) plusieurs infos d'accessibilité PMR (accessibilite_pmr) pour une même station : pas nécessairement une erreur, il pourrait y avoir une borne accessible PMR (je pense surtout à la hauteur du terminal) et les autres pas (un peu comme un parking peux avoir des places PMR et d'autres pas) que va-t-on faire de la stat sur les puissances ? constater les puissances max par prise par réseau ? suggestion : compter le nombre d'erreur par fournisseur de données, histoire de connaitre les réseaux à traiter avec prudence et/ou à signaler prioritairement (mais pq etalab ne fait pas cela ?) |
Pour les coordonnées, bien que cette PR ne change rien à ce sujet, elles sont relativement bien validées dans la consolidation Etalab pour s'assurer qu'elles tombent dans l'hexagone. Tout à fait d'accord pour les refs invalides et accessibilité. Pour les puissances, dont cette PR est le premier jet, j'ai mis des stats sommaires pour juger "rapidement" des combinaisons qui sortent et si oui ou non on peut s'y fier. A première vue, je ne vois rien d'anormal. Je ne sais pas si une analyse plus poussée est à faire ici ou en retour d'Osmose. Je peux ajouter des levées d'erreur par type de prise. ça me semble correct ici avant de laisser passer l'info downstream. Pour ce que j'ai appelé puissance incohérente, c'est plus par rapport au cas où l'unité ne serait pas en kW. Mais manifestement toutes les entrées sont correctes. En ce qui concerne l'association des erreurs au fournisseur, je pense que c'est le sujet d'une autre PR à laquelle je pense, qui consisterait à :
|
si j'ouvre le fichier json de l'opendata dans josm, il y pourtant 14 bornes hors France (7 en Europe, 7 dans l'océan) très loin des frontières, par ex |
Ah oui je me suis mal exprimé, la validation faite par Etalab consiste à tester si une coordonnée hors de France tombe en France après inversion lat/lon. ça élimine la majorité des pbs. Si après inversion c'est toujours hors de France, ils ne peuvent rien faire de plus. Et je ne sais pas trop ce qu'on peut faire non plus. La discussion qui en parle sur data.gouv : https://www.data.gouv.fr/fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques/#/discussions/6621138f70f5dd5c85619152 Au final dans la version actuelle du script (ce repo), rien n'est bloquant au sujet des coordonnées, il y a bien un test pour vérifier que le type de valeur est un float mais rien de plus. Un ticket pour garder ça en tête peut être utile, mais à mon sens pas prioritaire vu le pourcentage de cas (et le fait que ce sera forcément à gérer au cas par cas car erreur de frappe du producteur). |
Je voudrais clarifier ce que fait le code de cette PR, parce que pour moi (et je pense la plupart des utilisateurs de véhicules électriques) ces données sont cruciales. Je m'explique : Autre point important : je n'utilise pas les bornes de charge près de mon lieu d'habitation (je charge à la maison, moins cher) ce qui signifie que je n'ai pas l'occasion de saisir l'info d'un chargeur manquant à moins que je l'aie au préalable découvert (donc en dehors d'OSM) et utilisé. Or les données utiles sont dans openData, mais bloquées ici. Donc pour revenir au sujet :) tout ce que fait cette PR, c'est prendre la puissance nominale déclarée, et l'associer au types de prises déclarées en limitant à la puissance maximale autorisée pour chaque type de prise, car le Schema de l'IRVE demande au fournisseur d'inscrire la puissance maximale sans tenir compte des prises (au final ça correspond à ce qui est marqué en gros sur les chargeurs). La partie qui est "guessed", c'est toujours pour qualifier la puissance associée à une prise qui ne correspond pas à la puissance max du chargeur. Exemple :
Est-ce que vous pensez qu'il faudrait dans ce cas ne rien mettre pour Chademo ?
C'est la différence (pour moi encore) entre un chargeur trouvable ou pas. Et dernier point, ce critère de recharge est comme je le disais utilisé pour catégoriser les chargeurs dans les apps de navigation. Les catégories sont généralement :
Les erreurs possibles ne vont que très rarement changer la catégorie du chargeur, d'autant plus que la majorité des véhicules sont en CCS et cette valeur n'est jamais altérée. Désolé pour ce long post, mais (comme ça doit se sentir) j'aimerai vraiment voir ces infos dans OSM. |
Hello ! En tout cas, dans l'idée ça me parait pas mal. Il faudra être suffisamment clair sur le front Osmose pour éviter que des valeurs valides soient écrasées par ce résultat. |
je suis aussi conducteur de VE et je partage ton avis tant sur le côté indispensable de la puissance en ComboCSS que sur le côté "on utilise surtout des bornes à plus de 200km de chez soi" donc plus difficile à renseigner soi-même (sauf que je fait régulièrement un arrêt volontaire à une borne qui manque d'info si c'est sur le trajet.. et évidement chacun peux maper les bornes proche de chez soi pour les autres et renseigner dans osm les bornes utilisée grâce à un planificateur utilisant une autre base, par ex ABRP)
|
Merci pour ces précisions, ma source d'info Chademo n'était manifestement pas très fiable (je suis en CCS perso). Je suis pour l'idée d'y aller progressivement pour rassurer la communauté (et @nlehuby en particulier 😜) Donc je propose une phase 1 à zero risque consistant à :
Z'en pensez quoi ? |
Pour info, j'ai posté également sur le forum fr pour récolter des avis : |
Oui, ça me parait plus prudent. T'as bien fait gaffe au fait que la puissance est un attribut du point de charge et pas de la station ? |
Hélas ce n'est pas toujours le cas. Ionity par exemple ne donne qu'une entrée par station. |
Nouvelle proposition disponible. J'ai ajouté des tests unitaires pour clarifier. |
pour info je viens d'en voir une sur le terrain, ce n'est donc pas nécessairement une erreur |
c'est quoi la prise la plus puissance ? combocss > chademo > type2 ?
cad ? dans le log `? si oui, cela me parait ok |
Ajoute ces colonnes au fichier de sortie:
['power_ef_grouped', 'power_t2_grouped', 'power_chademo_grouped', 'power_ccs_grouped']
Ajoute un type d'erreur:
"puissance nominale déclarée suspecte"
Ajoute 3 warnings (1 pour chaque prise EF, T2, Chademo, mais pas CCS):
"puissance nominale déclarée pour prise {} supérieure à la norme (valeur retenue: {})"
Ajoute de "brèves" statistiques de puissance en STDOUT. Optionnel.
Exemple sortie stdout d'un run: