Could you check the postcode you added to node/9215219185 in this changeset? SA1 1DY is located in Swansea over 50km away!

Thanks for adding those shops.

I see you've put the branch website in the source=* field on several of the shops. You should only put something in source=* if it's the source for all (or most) of the tagging information in OSM. If you're only using a source for some tags, then use source:*=* for each of the tags instead (e.g. source:opening_hours=* or source:addr=*). Or you can add a source=* to the changeset if there's a specific source for the overall set of changes. (I'd have thought that for most of those shops, the main source would be your ground survey.

Perhaps more importantly though, you mustn't use information from the websites of chains unless you have specific permission from them to use the information in OSM. In general, you can't use any copyrighted information in OSM without a compatible licence. It can be argued that facts aren't copyrightable, which means you can use factual information on the websites of individual independent stores. However, for chains of stores, database rights come into play, which means we can't copy the information.

Hi there! In this changeset, it looks like you've removed the Pizza Hut tags from way/199176826 but have left the brand:wikidata=Q191615 (which is the code for Pizza Hut) and amenity=restaurant tags in place.

If the Pizza Hut outlet has closed and it's no longer a functioning restaurant, it would be useful to remove the brand:wikidata tag and change the amenity tag to disused:amenity=restaurant. Also the fhrs:id is no longer current, so that could be removed too.

Thanks for checking the correct name on site. Looks like you've managed to re-tag it now. iD's "helpful" tag-upgrade suggestions don't always get it right, but if you look at the full set of raw tags you should be able to fix anything you need to. Sometimes there are other fields that need changing too to get rid of the suggestion, but they might not be the ones that iD is actually suggesting changing!

I don't recall the details of the location, or why I went for amenity=needle_exchange . I'm pretty sure it would just have been a sharps bin though for disposal, without any clear needles being available. (Elsewhere I'd tagged such a bin as amenity=waste_basket + waste=sharps, which is perhaps a better tagging option. There only a handful of uses of that worldwide: https://taginfo.openstreetmap.org/search?q=waste%3Dsharps .)

Whatever Royal Mail thinks it's doing, the address is clearly a property of the school as a whole, so I think in OSM it should be included in the tags for the school object.

Simple test: for schools with multiple buildings (including those with individual names) you don't typically get an individual Royal Mail address for each one. So even if Royal Mail defines a particular building (or a point on that building) as the delivery point for the school, the address is still for the whole school.

I don't any any data for the addition of address tags to school buildings, but on amenity=school objects in GB, 82% have an addr:postcode=* and 61% have addr:street=* from https://osm.mathmos.net/schools/osm-tag-keys.html .

Thanks. Are you sure what you've just changed is right though? There are now two adjacent shops tagged as "Headmasters":
relation/13152586
way/151170978/
Is this right, or should one of these actually be William Hill?

Hi there! In this changeset you edited the way way/151170978/history , which was previously for a William Hill betting shop.

You seem to have changed the name to "Headmasters Academy" and the shop type from bookmaker to hairdresser, but have left the william Hill Brand tags in place.

I see that the shop next door way/151170960 is also tagged as "Headmasters Academy" hairdresser, so I'm wondering if the changes to the William Hill shop were in error.

Hi there! In this changset you appear to have edited the node node/5648164590/history and changed shop=bookmaker into shop=vacant;bookmaker, but have left the name name and brand tags for a William Hill betting shop in place.

Can you remember (or determine) if you were trying to mark the shop as closed, or if the "vacant" tagging was just a mistake?

Thanks!

By the way, the remaining Gala Bingo sites in OSM that I couldn't find a Buzz FHRS entry for are listed at https://osm.mathmos.net/ghosts/gala-bingo/ .

Not automated; just a copy and past error. The previous URL is redirecting. I think I must have fat-fingered the ctrl+c to copy the new one, and so the previous clipboard contents was accidentally entered instead. Now fixed though - thanks for spotting it.

Oops. This wasn't from a survey. I think I would have been using iD's (often over-zealous) "upgrade tags" feature, to add missing brand tags to several outlets here. I'm usually pretty careful when using it, and check the individual changes it's about to make. I guess I missed the fact it was adding a shop=* to way/156856852 when it previously previously didn't have one. Oops.

The correct Survey Me Link is https://osm.mathmos.net/survey/#17/53.9914/-1.1049 . Yes, the "Chain Reaction" tool is flagging an "Unexpected Tesco Extra", because it's already matched the store to the Petrol Station shop.

Normally the shop=supermarket would be matched in preference to the shop=convenience, but in this case the petrol station shop had the right postcode, whereas the main store had the wrong one. But that wouldn't remove the "unexpected" object. To deal with that, I have a kludge that if both shops have the same website=* value, and that value matches a regex I've set for the chain, then the second object is ignored as a legitimate duplicate. That's the "Duplicate Matches" section at https://osm.mathmos.net/chains/Q25172225/ .

I've now put in the store websites for way/176079436 and way/23825461 and corrected the postcode of the latter. So things will hopefully fix themselves at the next update of "Chain Reaction" in a few days' time.

Could you check on node/8772664848 please?

The address tagged seems to correspond to the location of the node, but the postcode TF1 6ZY is located almost 4km away on Sandal Drive.

The website gives an address there, but it's not clear to me whether there is a physical shop customers can visit at either site. If there's no customer-facing shop, then you shouldn't use the shop=* tag.

In this changeset you appear to have moved the node node/6199365822 for Salix Therapies from osm.org/?mlat=52.56939&mlon=1.11630#map=18/52.56939/1.11630 to osm.org/?mlat=52.59902&mlon=1.18253#map=18/52.59902/1.18253 , but have left the old Avenue Road, Wymondham address in the tags.

Is this move correct? If so, then the address needs updating to match the new location. Could you take a look?

Many thanks,
Robert.

It looks like you've change the Eaton Park railway from railway=miniature to railway=narrow_gauge in this changeset. I think you've missed a few of the ways though: way/35266726 , way/35317784 and way/35266726 .

However, reading railway=narrow_gauge and railway=miniature , I'd say that in OSM terms, the Eaton Park railway would be better described as "miniature" rather than "narrow gauge" (and not just because of its name).

Thanks for correcting the address here. But you would need to alter the geographical location too. It's no good just leaving the node in the old location!

I've done my best to move it to the right place on Greens Lane, but it's only a guess based on some other nearby house numbers. Could you have a look at the new location of node/3404324594 and move it to the right building if necessary, or confirm it's correct if not?

Hi there. Can I ask where you got the postcode for the building and shop at way/961698031 and node/7198176936 from, which you added in this changeset?

According to Code-Point Open, NP19 7GR is located on a different road about 1km away. See https://osm.mathmos.net/addresses/pc-stats/NP/NP19/7/#7GR .

The bits I added were just from observations of newly installed signage on the ground. However, a quick Google has thrown up https://data.gov.uk/dataset/2cc04258-a5d4-4eea-823d-bf493aa31eef/england-coast-path-route , which might be usable.

Thanks -- now updated.