-
Notifications
You must be signed in to change notification settings - Fork 117
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
[WIP] analyse merge sirene #338
Conversation
analysers/analyser_merge_shop_FR.py
Outdated
@@ -62,18 +65,18 @@ def __init__(self, config, error_file, logger, classs, title, selectTags, genera | |||
select = Select( | |||
types = ['nodes', 'ways'], | |||
tags = selectTags), | |||
osmRef = "ref:FR:SIRET", | |||
#osmRef = "ref:FR:SIRET", |
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.
Please rebase. It's was already disabled.
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.
ok
Oui c'est assez mitigé. C'est pour ça que ça n'a pas encore était activé. cc @cquest |
only keep those who are missing from OSM
idées fonctionnelles (=sans avoir passé des heures à lire le code) : dans un premier temps matcher ceux dont le nom par exemple correspond ou est très approchant ou lorsque siret est présent, pouvoir ajouter siren ou inversement parce que dans un 2ieme temps, je vois bien l'intérêt d'avoir un outil qui dit "tel poi n'a de nom dans osm, voici une liste des possibles selon sirene" : cela évite sur le terrain d'avoir à écrire (avec le risque de typo) une info disponible dont il ne faut que confirmer quel match est bon ou pas. (c'est je supose le but de ce PR) cela permet après dans un 3ieme temps de détecter (même si sirene est "lent") que tel magasin est probablement fermé ou a déménagé |
Je refais une petite passe sur SIRENE... je suis en plein dedans depuis plusieurs semaines en dehors d'OSM ;) On a aussi depuis cet automne de nouvelles données disponibles: la partie historique de SIRENE (entreprises et établissements fermés), qui permet de régler certains problèmes. SIRENE peut servir à plusieurs niveaux:
Ce qui est "lent" dans SIRENE:
Ce qui n'est pas forcément fiable:
Je commencerai pas des choses simples: les commerces.
On peut s'appuyer sur la version que je géocode chaque mois, ça évite de refaire ce gros boulot ! Je pensais aussi à une analyse plus "meta" du genre comparer le nombre de boulangeries dans SIRENE et OSM sur le territoire d'une commune... un peu comme ce que je faisais avec "etat-commune" et signaler par commune là où on a un écart.
|
Merci Christian pour ce retour intéressant. Puis, en attendant de se faire un outil dédié plus spécifique, on peut se prévoir plus tard
|
oui ce serrait agréable d'activer au moins une partie |
Ok, I cherry-picked the commit. |
C'est activé que dans le Vaucluse ? |
Oui |
Require to switch data source to http://data.cquest.org/geo_sirene/v2019/last/dep/ |
Utilisation du geo sirene avec mise à jour automatique en place. |
* frodrigo/master: Use remote data source for analyser_merge_heritage_FR_merimee Refactoring of Geocoding with Addok Make more and generic analyser_merge_shop_FR #338 config: Move merge_shop_FR to Vaucluse
* frodrigo/master: Fix config of country in Name_UpperCase Ignore camp_type/lamp_type in analyser_osmosis_tag_typo #534 Ignore Inventaire in analyser_merge_heritage_FR_merimee #517 Better select in analyser_merge_shop_FR & move mapping to json #338 Fuzzy geocoding results at municipality level in analyser_merge_power_plant_FR #510 Fix bbox size in Analyser_Merge #523 Fix logger param in Analyser_Merge / Analyser_Merge_Mapillary
Les données sont à jour avec le dernier code. Il ne reste plus beaucoup de chose, mais ça semble assez bon. Prochaines étapes :
|
Hello,
§ peut-être que quand on aura bossé sérieusement sur FINESS avec @vinber, les analyses de Sirène sur les établissements de santé/social (hébergements) pourront aller ailleurs ?
Je ne sais pas si c'est le type d'avis que tu attendais, mais c'est le mien ;) |
J'ai vaguement regardé dans le Vaucluse (mais c'est trop loin pour que je fasse du contrôle qualité valable ^^) : dans les presets, pas de SIREN/SIRET/NAF, c'est voulu, le suppose ? |
* frodrigo/master: Update mapcss parser to support new operators Clean unussed split in analyser_osmosis_highway_floating_islands Revert to full linestring to avoid false positive in analyser_osmosis_highway_floating_islands #541 Clean code in analysers/analyser_osmosis_highway_floating_islands Also support natural=water + water=fjord|harbour in analyser_osmosis_water #448 Restrict analyser_osmosis_soundex to latin script #525 Generalize merge_shop_FR in France #338 Include construction in factorized table highway #514 #506 Support area in factorized osmosis table highway #518 Merge shop within 20m #338
Mise à jour en cours sur toute la France, DOM compris, sauf Paris. Dernière remarques de @deuzeffe non prise en compte. |
@deuzeffe c'était pas tout à fait ça, mais pas loin ;-). On rajoutera plus de classes quand on saura que ça marche. Pareil pour les SIRET. Avec la généralisation à tous les départements ça va être plus simple. C'est surtout les faux positifs qu'il faut remonter, mauvais tags, ou en doublon dans OSM car utilisé d'autres tags. Pour 8210 et 8211 et 8330 et 8331, ce n'est pas des doublons, c'est une autre analyse qui apporte d’autres chose. Par contre dans la réorganisation pour opendata.osmose.osm.fr ça va aller dans le même item. |
Oui, d'accord avec toi que le tag n'est peut-être pas bon dans OSM. Du coup, (grosse) question pour Osmose : |
Non la conflation d'Osmose ne se fait que sur une suele jointure, ici le tag. En plus pour le nom il peut y avoir des variantes. |
J'ai une erreur 404 en cliquant sur le lien ref:FR:SIRET de l'infobulle. |
Oui, je l'ai dis dans mon message plus haut, il faut trouver une autre URL. |
tag2link mis à jour, patch également proposé à JOSM JOSM/josm-plugins#13 |
|
TODO
|
* frodrigo/master: With list loc_ref and lock_ref in analyser_osmosis_tag_typo #581 Add name as subtile in Name_Initials #580 With list static_caravans and static_caravan in analyser_osmosis_tag_typo #574 Add mot tags to match in shop_FR.mapping.json #338 Avoid issues on relation less geom into analyser_osmosis_boundary_relation
Dernière modif en place:
|
merci, j'ai effacé mon précédent message car je ne suis tombé que sur des POI qui n'avaient pas de nom, mais je viens de tomber sur certains qui avaient des name, donc il doit y avoir de nombreux commerces sans nom en fait ! |
Des entreprises unipersonnelles en nom propre. |
Bonjour, |
Je ne sais pas, regarde dans le fichier source ce qu'il y a. Peut être une histoire de Lyon n'est pas dans le département... |
J'ai essayé:
J'ai trouvé un magasin par edemple:
|
Osmose utlise bien la bonne relation pour les limites du département. L'analyse ignore la manque de SIRET, c'est juste proposé lors de l'ajout. |
Sur Lyon ça semble du au fait que les geo_score est toujours inférieur à 0.9. Tu aurais une idée pourquoi ? |
C'est un score pour s'assurer de la bonne qualité de la position. Le fait que la ville a des arrondissements doit faire baisser le score. Il faudrait voir ça avec @cquest qui géocode le fichier. |
J'ai fait quelques tests en baissant à 0,5 sur une instance locale et ça confirme effectivement que c'est le problème. J'ai jeté un coup d'oeil à addok pour essayer de comprendre d'où ça vient mais là ça devient un peu trop obscure pour moi ;) |
Tu peux regarder à combien sont les valuers ? On peut peut-être baisser à 0.85, mais il fat aller plus bas que 0.8 ou 0.7. |
J'ai sorti les stats pour le Rhone. |
Ok merci. C'est problématique, il faut voir du coté du géocodage. |
Bonjour,
j'ai fait cet été quelques tests d'intégration de la base SIRENE en repartant de l'analyse non activée déjà existante.
J'ai désactivé la conflation sur le numéro SIRET : en effet, il est difficile à contribuer sur le terrain (pas facile à obtenir pour un contributeur, pas présent dans les applications de contribution, etc) et très peu renseigné aujourd'hui.
En conséquence, j'ai limité l'analyse merge pour ne rechercher que des éléments manquants dans OSM mais qui, d'après la base SIRENE, existent (ce qui me semble être déjà un incrément fonctionnel acceptable).
Les résultats obtenus sont très mitigés :
J'ai pu identifier avec cette analyse des zones où des POIs étaient effectivement manquants dans OSM 👍
Mais souvent, la qualité de la base SIRENE (qui n'est pas vraiment une base géolocalisée et pas vraiment non plus une base de POI) fait défaut et de très nombreux faux positifs remontent :
j'ai trouvé des commerces dans la base SIRENE à plus de 200 mètres de leur position réelle, et d'autres qui ne me semblent correspondre à rien d'existant sur le terrain.
Je ne sais pas trop quelle suite donner à cela, mais je me suis dit que le retour d'expérience pouvait peut-être être utile 😉