Doing small targeted mechanical edits like this sounds like a good workflow
to me.
My recommendation would be to structure the program in two steps:
1. The first script calculates all of the changes that it wants to make,
and writes it to CSV, with all of the details required for step 2.
2. The second script reads the CSV and prepares the edit.
The primary benefit is that you can inspect the proposed edits in Excel and
post them on a wiki page for others to see.
It is also a sensible architecture. You can write one simple script to find
`street` -> `Street`, etc. changes and confidently submit those edits with
a quick glance. And you can also write a fancy script that uses Overpass to
find the closest similarly named street or something like that, and inspect
the proposed changes much more closely, and simply delete all the
suspicious ones. It keeps the two independent tasks insulated from each
other with the CSV. It's a perfect example of a *modular* design.
Cheers,
Ben
On Mon, 21 Aug 2023 at 16:56, Warin <61sundow...@gmail.com> wrote:
> HI
>
> I have jumped thegun here.
>
> Now looking at the data in JOSM.
>
> Total 3,814 individual addresses but
>
> The streets are only 221 so many of these are simply repartitions in the
> same street - much easier to deal with.
>
> I may simply do these manually after all. It was only the initial
> individual item numbers that frightened me. But 221 is fine.
>
>
> Note: There are more of these 'errors' I am simply picking the ones I
> can fix without resorting to the wiki for detail. Once these are done
> I'll look at the other 'errors'. While the map maker reports these
> 'errors' some of them to my human eye look to be fine... so I am not
> 'correcting' them all.
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au
