Hi,
> On 25 Mar 2026, at 11:22, Frederik Ramm <[email protected]> wrote:
>
> Hi,
>
> On 3/25/26 11:24, Dave F via Talk-GB wrote:
>> As actions of both yourself & Shaun prevent data consumers from retrieving
>> accurate counts of businesses (such as Tesco)
>
> I believe that is not true; the actions that you criticise would require a
> more complex analysis of OSM data to retrieve these counts, they would not
> make these counts impossible.
>
> In general, OSM prioritises - and should prioritise! - ease and clarity of
> mapping, not ease of use. If one person who wants to count shops is required
> to write a few more lines of code, then that is preferable over mappers
> having to go out of their way to satisfy some shop counting script.
My understanding is that DaveF would like to track the number of contractors
doing catering work in schools, care homes, churches., etc. This generally
isn’t verifiable on the ground (unless you happen to have some special access),
and is only available in the FHRS data. Combining OSM with other sources is
often needed to do analysis or routing or other things to get the best system.
>
> As a general remark, just because something is published under an "open
> something license" it doesn't mean that you can use it in OSM; you have to
> read the attribution terms to check if OSM can satisfy them.
In this case the OGL allows the use, however it’s more a question of whether we
can see some of these things on the ground to verify them, or if we should
simply link them to another thing such as a school or care home. There is
support for having multiple semi colon separated ids on the same object in a
variety of OSM tools, and these have existed for several years now.
>
> You write "if it's physical & doesn't move, you can map it" - are these FHRS
> IDs you are talking about actually on physical signs, or are you not *really*
> talking about mapping something physical here?
The FHRS IDs can’t be found on the ground. The open data is a really useful
source of addresses, postcodes, finding areas that need to be mapped on the
ground, and when the FHRS id disappears discovering that a place either has had
an inspection thus new ID or has closed or moved, and thus needs to be mapped
again. I’ve never seen the FHRS data as needing to get every item into the OSM
data as is. It needs curation. Some things need merged, some potentially match
multiple things in OSM. The data is too poor to do automated matching to OSM,
hence why adding the FHRS id has been the preferred option.
Hopefully with more coverage we’ll find areas that need more on the ground
mapping, I’ve already found some!
https://osm.mathmos.net/survey/#5/55.500/-4.000 and
https://gregrs.dev.openstreetmap.org/fhodot/ are both useful for finding
changes or differences that need mapping by comparing to other data. As a
couple of examples with the FHRS data disappearing I’ve found a restaurant
close which I was able to pop out and check on the ground, and another time a
fast food take away having moved to the next street, again using a survey to
update the data. There will be some of the FHRS data that doesn’t match
something that we normally map in OSM, hence why we don’t automatically import
it into OSM, and instead do some human curation. It’s also hard to match as
addresses are often missing in OSM, and poorly formatted in some regions in the
FHRS data.
>
> Please try to avoid statements like "You seem confused" or "you appear to be
> scrabbling" - I could apply them both to your writing because of the
> inaccuracies pointed out above but would that get us anywhere?
Agreed. Also as per one of Dave’s changeset comments I’m not lazy, rather
fundamentally disagree with mapping a contractor to a school as craft=caterer.
I’ll happily fix my errors that are nicely pointed out where I agree with them.
I’ve also seen some of DaveH’s other comments and reversions of data. I suspect
some of those issues may be stemming from editor validators potentially
highlighting changes in tagging style over time or there my be aspects that the
validations aren’t taking into account, so may be too strict in some areas. I’d
rather try and find out the why something is happening or at least assume
something might have been an accident. I’ve had a few conversations about my
changes with other people recently and they’ve all been positive interactions.
In one case I’d accidentally added a FHRS id for the old cafe to the new cafe
which had moved a few doors down the street. The other person got in touch with
the local authority and the FHRS data was updated as they’d got the two
locations mixed up. So accidentally adding the wrong data and making a mistake
can cause a ball to roll and overall better data not just in OSM, but also at
the local authority and therefore the FHRS data. This highlights that there are
better ways to deal with unexpected changes.
I’ve had one person comment that if they were spoken to in the way that DaveF
has written about what I’ve been doing, they’d be in tears as it’s so terse and
inconsiderate.
Shaun
_______________________________________________
Talk-GB mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-gb
