In this changeset you made two changes to node/13674845202 , neither of which are correct: https://osmcha.org/changesets/180437117

(1) You changed the brand:wikidata tag from the correct value of "Q80963064" to the incorrect form of a web address https://www.wikidata.org/wiki/Q80963064 .

(2) You reverted a change I had just made to correct the web address for the branch from https://www.gsfcarparts.com/branches/SheffieldNorth to https://www.gsfcarparts.com/branches/sheffieldnorth .

For the latter, while both URL's work, it is the lowercase version that is listed in the website's sitemap and the lowercase version that results users end up at if they go the website and search for that branch. So that is the lowercase URL we should use in OSM.

I've now reverted this changeset.

I'm not sure exactly what RightChoice.ai is, but the edits here seem rather suspect. Can you confirm how it is deciding on changes, and that that there is human validation of anything that is being suggested before it is actioned?

Can you check the location of the node node/13674845202 that you added in this changeset please?

It's currently positioned in the middle of a road. I doubt a real car parts shop would be located here.

Out of interest, how did you set the position here? Aerial imagery is clear that it's in the middle of a road here, so did you get the coordinates from some other source and then not check the imagery/map before placing it?

Can you check the location of node/13674861101 that you added in this changeset? From the address given, I assume that it should be somewhere around osm.org/?mlat=53.273776&mlon=-1.452631#map=18/53.273777/-1.452631 rather than in the middle of a roundabout. Thanks!

Are you sure node/13675065101 is a duplicate location? I don't see another GSF Car Parts object nearby in OSM.

Perhaps more importantly, I would say that the presence of contradictory signs would generally make any stricter conditions imposed by the legislation unenforceable. So in practical terms here, the signage on the ground wins.

Ah, thanks for the tip. I hadn't come across customers=* before. I agree that would be better here. Feel free to change the tagging if I don't get there first.

Hi Chris,

In this changeset you disused shop to River Island, but this leaves two River Island shops next door but one to each other:

* way/296726615
* way/296726623

That's not out of the question, but would be a bit unusual. Do you know whether the two River Island shops currently mapped here are both open?

You've also got the same with two waterstones stores next-but-one to each other:

* way/296726607
* way/296726594

Are both of these actually present on the ground?

Best wishes,
Robert.

Hi Riley,

In this changeset you added an AED: node/13441701101

You specified it as being outdoors (indoor=no) but you placed the node inside a building. Could you check if one of the location or tagging needs correcting?

Also, it would be helpful if you could provide a bit more detail in the location description. Can you say exactly where the AED is to be found at Bromley Cross station? Can you write a description that would send someone straight to the right place on the station in an emergency?

Hi Riley,

In this changeset, you added a Defibrillator node/13441700701 with the location description "Bromley Cross Train Station". However, the location you placed it at on the map is in a nearby housing estate about 500m away by foot.

Can you check whether the location you added this AED and/or its location description is correct?

(I see that you also added another AED at the station in node node/13441701101 .)

Hi Philip,

Could you check exactly what you've done in this changeset? It looks to me as if you may have added postcodes to quite a few non-addressable objects, which don't actually have addresses or postcodes. More-over if they did have postcodes, some of the ones you've added aren't correct.

I assume this is because you're adding postcodes assigned to each URPN in the ONS data. But the allocation of postcodes in the ONS data is not that straightforward. If the UPRN has an address then that postcode is used. But if it doesn't, then the nearest postcode is allocated instead. I don't think we want to add these "nearest postcodes for non-address objects" to OSM, not least because they're sometimes wrong.

In particular could you have a look at the objects with postcodes SO45 1TX, SO45 1DP and SO45 1FY.

* https://overpass-turbo.eu/?w=%22addr:postcode%22=%22SO45%201TX%22+global&R
* https://overpass-turbo.eu/?w=%22addr:postcode%22=%22SO45%201DP%22+global&R
* https://overpass-turbo.eu/?w=%22addr:postcode%22=%22SO45%201FY%22+global&R

From https://osm.mathmos.net/addresses/pc-stats/SO/SO45/1/#1FY and https://osm.mathmos.net/addresses/uprn/SO45-1DP and https://osm.mathmos.net/addresses/uprn/SO45-1FY you can see that the first of these is probably the postcode for the whole oil refinery, while the latter two are postcodes for properties in nearby streets. The latter two shouldn't be assigned to anything in the oil refinery.

A useful flag to be more careful when adding postcodes would be if there are more than 100 UPRNs with a given postcode - since Royal Mail rules mean there's never more than 100 properties within each postcode unit.

Best wishes,

Robert.

PS: In the source tag, it would probably be better to use either osn_uprn_directory or ons_uprn_lookup (to be more specific) for the postcodes and os_open_uprn if you've used that too.

Hi LYNX4546,

In this changeset you added a Defibrillator (AED) at a location that seems to be in the middle of nowhere: node/13430586701#map=14/53.14690/-3.24989

This seems to be an unlikely location to me, so could I check that this is what you intended to do? If it is correct, could you add a description of the location in the defibrillator:location=* tag to help other mappers and data users understand where it is?

Many thanks,

Robert.

I agree having the destinations in the key isn't great. I'm not sure your suggestion works though as distance=* is already defined for a different purpose with highway=milestone: highway=milestone

I can't actually find anything documenting either approach on the wiki. I think I just adopted the distance:*=* having seen it used by someone else.

Perhaps something like destination;=** + destination:distance;=** might work. It would be better in any case for there to be a stronger connection between the two keys if they're intended to line up 1-to-1.

Hi,

Could you check the location where you placed the AED node/13362246001 in this changeset?

You've given it the description "AED , at Royal Oak, Laxfield , IP13 8DH", but you positioned the node outside the King's Head pub on the other side of the churchyard.

Could you also add a bit more detail to the description, e.g. is the AED inside or outside the pub, is it on a wall and if so which one?

Yes I agree, but it wasn't my change that added the AED while leaving the amenity=telephone in place.

I think there are some AEDs in still-in-use phone boxes, so I wouldn't recommend automatically re-tagging these as disused:amenity=telephone.

The "old phone box" in the defibrillator:location tag in this case is suggestive, but it would probably be better to check with the editor who added the AED. ("old" could mean "old-fashioned" rather than "disused".)

This isn't an isolated issue though, as you can see from the list that my AED tool produces at https://osm.mathmos.net/defib/osm-amenity.html

Yes, Tag:shop=trade + trade=building_supplies is equivalent here. I've updated the tags.

Hi Phoebe,

Many thanks for adding an AED to the map at node/13333614301

Is there any chance you could provide a better location description though? I assume that the "bn124ee" is supposed to be the postcode "BN12 4EE", but it would be better if you could add a human readable description of where the AED is located, to help someone standing nearby know how to find it.

Many thanks!

Hi ,

Could you check the location that you've given to the AED node node/13341548901 ? At the moment it's placed inside a house. Is it really located there? Also, could you give a better location description than "41 priory road", perhaps saying where in/on/near that house it's located?

Many thanks!

Hi Emma,

In this changeset you added the defibrillator node/13301610801 , and gave it the location description "Sa726qx". This looks like it might be the Postcode "SA72 6QX". If it is a postcode, then it shouldn't be in the location field. (The location field is for a human-readable description telling someone on the ground where to find the AED.) But this postcode doesn't match the location of the AED. So I'm wondering if something else is wrong here too.

I would have been just going by the previous mapper who changed disused=doityourself to disused:shop=doityourself indicating that it has closed. I then just tidied up the rest of the tags that they'd missed.

Yes, but arguably the hospice covers the grounds as well. And if you want to know the address of the hospice you need to tag the address on the hospice object. If you want to tag a delivery point, then we probably need a separate object for that.

What do you do for e.g. a large University campus? You wouldn't just put the address on the post room / good in (for deliveries) or the main reception (for visitors) ? But it would be good if you could somehow indicate that that's the place to deliver things or turn up to in person for that address.