Rely on Osmose analysis

[flacombe]

Hello

OpenStreetMap ecosystem is self-organized and it's fine to provide the community with such great tools.
By the way, quality control also relies on very specific software and bigger, more general ones.

Osmose-QA is part of them and already process phone numbers in many countries in the world to let contributor fix errors.
https://osmose.openstreetmap.fr/fr/map/#loc=13/45.90883/6.1179&level=1%2C2%2C3&item=3092
https://osmose.openstreetmap.fr/fr/issues/open?item=3092
52 236 errors are currently reported.

However the UX may not satisfy everyone, Osmose let third parties access the result of its tests tanks to API.
Would it be possible to consume, and potentially improve what already exists, regarding phone numbers please?
https://osmose.openstreetmap.fr/api/docs

Osmose processes the whole world, so it would be as easy to analyze every country as to document every phone number format.

Results would still be visible through you interface but the analysis would be consistent with what is seen elsewhere.
Osmose would be also glad to get a few more maintainers to deal with particular analyses.

Best regards

[confusedbuffalo]

I do see what you are saying and understand that having some centralised QA could be better than having many disparate tools. It would also be good to have this analysis for more areas/the whole world.

However, it would require a total rewrite and adding a huge amount more complexity to the existing plugin.

[flacombe]

However, it would require a total rewrite and adding a huge amount more complexity to the existing plugin.

Why should we rewrite this plugin?

Even in that case: collaborating to a more robust analysis covering more countries in the world is still less complicated than handling several distributed analyses with possible inconsistencies (since every of them should handle the same updating process of the osm db).
I'm not arguing about UX or websites, yours is definitely better and well designed. We should separate the process from the interface where the results are exposed.

Hadn't you had to write from scratch something similar to cover the countries you are focused on?

[confusedbuffalo]

Why should we rewrite this plugin?

Because the way I have done the analysis here is totally different to the way it is done in osmose at the moment.

Even in that case: collaborating to a more robust analysis covering more countries in the world is still less complicated than handling several distributed analyses with possible inconsistencies (since every of them should handle the same updating process of the osm db). I'm not arguing about UX or websites, yours is definitely better and well designed. We should separate the process from the interface where the results are exposed.

Hadn't you had to write from scratch something similar to cover the countries you are focused on?

I'm mainly leaning on the libphonenumbers library for the parsing of numbers, which deals with all the countries. I can add any other country and it should be 95% fine. There are a few edge cases for individual countries added to this.

I do see that perhaps it would be better if my project was basically an alternate front-end to osmose for phone numbers, but having done it like this it would then be a lot of work to change it to that. Yes, I did write this from scratch, and I have put too much time into it, but it would then need to be rewritten in python, and connecting to the osmose error type reporting. My code and tests for processing are some 3000 lines.

I won't close this, but I also don't see myself doing this, at least not any time soon.

[flacombe]

I'm mainly leaning on the libphonenumbers library for the parsing of numbers, which deals with all the countries. I can add any other country and it should be 95% fine. There are a few edge cases for individual countries added to this.

It's a collective loss, as it's not only about Osmose usage in third-party software but about common software maintenance as well.
Everyone spending time in more specific software won't contribute in more common projects as you rightly mention it's costly to launch and hard to merge afterwards.

[watmildon]

I personally find targeted QA tooling to be much more approachable and easier to grapple with. Showing new folks all of Osmose is a path to getting them to close a tab. Showing folks a clean list of very targeted improvements is often much higher value.

[flacombe]

I agree with you and that's not incompatible.

Showing new folks all of Osmose is a path to getting them to close a tab.

You mention the front end while I'm advocating to rely on the same backend to ensure its maintenance on the long run.
As said upside, analysis can be done somewhere and used in several software then, to encourage mappers in a friendly environment for the project they run (like this one for phone numbers).