Add `ref:FR:SIRET` and `ref:FR:SIREN` syntax check

[cayenne17]

For JOSM in the France Specific Rules, i have add rules ref:FR:SIRET and ref:FR:SIREN.

https://forum.openstreetmap.fr/t/ajout-validateur-de-donnees-refsiret-et-refsiren-dans-osmose-josm/30904
https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules?action=diff&version=100

How to add osmose ?
@Jean-BaptisteC sent me this link : https://github.com/osm-fr/osmose-backend/blob/dev/plugins/Josm_FranceSpecificRules.py

[Famlam]

The rules have been synchronized today, but are not deployed yet.

Just wondering about some potential optimization: you use (^[0-9]{14}$)|^([0-9]{14};)*[0-9]{14}$. I think this is identical to just ^([0-9]{14};)*[0-9]{14}$, because the * means any number of matches, including 0 matches. (The same for the other rule).
Please correct me if I'm wrong.

[cayenne17]

Thanks for your comment @Famlam .
I just tested your regex (^([0-9]{14};)*[0-9]{14}$) and it works perfectly. It's better to use the shorter one.
https://regex101.com/r/bQD4CS/1

I just thought of something too. A SIRET number is unique, so the same SIRET number shouldn't be tagged on multiple objects in OSM. Is it possible to add a duplicate check for SIRET numbers ref:FR:SIRET as is already done for addresses?

[Famlam]

Thanks! Can you update the rules (in the .mapcss file) accordingly?

Regarding the duplicates: are there specific conditions under which you'd expect duplicates? (E.g. proximity, ...)
I think such a check might be quite computationally expensive, especially since the values can be ;-separated. Taginfo does however show 100 pages with 2+ uses of the same value, which is substantial already without considering the ;-separated ones

[cayenne17]

Thanks! Can you update the rules (in the .mapcss file) accordingly?

It's OK, it's up to date: : https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules?action=diff&version=101

As far as duplicate detection is concerned, it would be global. ref:FR:SIRET is unique. It must be on a single establishment. After that, there may be false positives when an establishment has several buildings, but in these cases, it seems to me that the best practice is to make a multi-polygon relationship and put the information on the relationship.

After that, if it's too demanding in terms of computing resources, forget it!

[Famlam]

It's OK, it's up to date: : https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules?action=diff&version=101

Thanks! It's now being deployed. The results are here

Note that it's mixed with the format code ref:FR:FANTOIR rules, because there's no unique number assigned.

You should probably add
-osmoseItemClassLevel: "9019/9019006/3";
and
-osmoseItemClassLevel: "9019/9019007/3";
to the two rules to separate them from the FANTOIR rules.

Can you make this change please?

As far as duplicate detection is concerned

Regarding the duplicate detection, can you make this a separate issue please?

[cayenne17]

Hello,

You should probably add
-osmoseItemClassLevel: "9019/9019006/3";
and
-osmoseItemClassLevel: "9019/9019007/3";
to the two rules to separate them from the FANTOIR rules.

Can you make this change please?

@Famlam : I've made the changes : https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules?action=diff&version=102

However, I don't think the numbers you gave me match your modifications: https://github.com/osm-fr/osmose-backend/pull/2455/files#diff-aaadd0ad75cbfcb63cb1763a178018db45839ffa662294044cff31b0f8394666R40-R41

Regarding the duplicate detection, can you make this a separate issue please?

I have just created a new issue: #2463

[Famlam]

Yes, I missed that I was overwriting an existing class. The new numbers are correct.

@frodrigo do you know whether it's intentional that item_map doesn't contain all classes (e.g. before my previous commit, 9019005 wasn't in item_map as validation rules Fantoir in France, which resulted in 9019005 becoming the first available class number for the new rules before they had -osmoseItemClassLevel)

[frodrigo]

it's intentional that item_map doesn't contain all classes

No. It should contains the items numbers to avoid this case.

[Famlam]

No. It should contains the items numbers to avoid this case.

I probably have a fix for this, will test it during the week

[Famlam]

Results with new numbers are now here:
https://osmose.openstreetmap.fr/nl/issues/open?item=9019&source=&class=9019006,9019007