If you go to https://www.burgerking.pt/pt/store-locator you'll see the website making a request to https://www.burgerking.pt/api/whitelabel when loading the page, and that endpoint returns the data that contains the refs. In this particular case, there're actually two different refs in the response payload: `_id` and `id` fields (used in URLs, i.e. "https://www.burgerking.pt/pt/store-locator/store/<id>"), and `storeId` and `number` fields (which are the ones that I'm using here); I decided to use the latter as they're always numeric while the former ones come in two forms ("restaurant_XXX" and UUID); I obviously don't know which one is more stable, I guess time will tell.

And yes, since it's burgerking.pt it only applies to Portugal. For Morocco (which is what I assume you're interested in) going to e.g. https://morocco.burgerking.delivery/find-bk seems to make a request to https://api.solo.skylinedynamics.com/locations which returns refs that most probably can't be correlated with the ones from Portugal in any way; I'd love it if there was a global source though (from BK itself). Note that I don't actually know if that's the official website for Morocco :) Also note that sadly there might be legal restrictions on using the rest of the data (just the refs is probably fine?..)

Olá Rui! Was that a warning that you fixed about Decathlon? Where can I see it? Their website (https://www.decathlon.pt/store-view/loja-de-desporto-ovar-connect-0070284802848) says that it's and "Ovar Connect", there're photos on the internet (e.g. at https://www.airinformacao.pt/2021/12/04/decathlon-connect-ja-chegou-ao-vida-ovar/) that show "Decathlon Connect" spelled out, and there're videos (e.g. at https://www.instagram.com/p/DJttfLIPvzp/ or https://www.youtube.com/watch?v=trLIETN5D9c) that seem to imply that Connect is a separate type/concept of stores for them. How do you propose to tag this if you (and/or the validation tools you're using) are against putting it in the name?

https://www.aldi.pt/ website spells it as "ALDI", not "Aldi", hence that's what I chose when unifying the tagging. Do you want to discuss and/or change it (for all the stores, not just this one)?

Amended in osm.org/changeset/166800479. Feel free to update the addresses again once e.g. confirmed on the ground.

Hi PriceyPanda, please refer to osm.wiki/Google for this specific case, and osm.wiki/How_We_Map in general. There's if course much more information on the wiki you might find useful. Looking forward to your future contributions ;)

Hi PriceyPanda, and welcome to OSM! A few notes on your changes here:
* phones should be in international format, see osm.wiki/Key:phone
* specific website URLs should be preferred over homepages, https should be preferred over http, see osm.wiki/Key:website
* "Quinta do Moniz" is not a street name
* would be interesting to know your source for the Pingo Doce postal code, the one used previously was taken from their website

Would you please revise according to the above? I can do it for you (basically revert to the previous values) if you want.

Happy mapping ;)

Olá Rui! Percebo bem que isto vem de um survey? O website para osm.org/node/12444352488 diz que é Worten Mobile, qual é o correto? Temos de os informar sobre isso?

Wiki (osm.wiki/Tag:artwork_type%3Dbust) says that "If a bust represents a specific person, it is a memorial and should be mapped with historic=memorial + memorial=bust.".

Hi. You seem to be using outdated imagery from 2018, the roads have changed since then. Reverted in osm.org/changeset/160476691

Hi! You've changed amenity=parking_space to amenity=parking near the hospital. There was already a parking there, one that contained all the parking space areas (way 160504219); having parking areas inside parking area isn't right. Wiki (osm.wiki/Tag:amenity%3Dparking) says this: "Individual parking rows should not be mapped as separate parking areas. To get that level of detail, individual parking spaces can be mapped separately with amenity=parking_space."

Reverted the locations in osm.org/changeset/151474753. Thanks for the prompt reply ;)

As for the parkings, after a discussion in Telegram I'm currently tagging them with brand=Telpark + operator=Empark (see osm.wiki/User:Mikedld/Portugal/Estacionamento/Operadores/Empark). Could discuss more if there's uncertainty.

Positions of osm.org/node/8308985789 and osm.org/node/8308727705 are now also incorrect (or much less correct). Not sure if you care, let me know.

[At least] osm.org/node/8105019897 got moved in this changeset. Previous location was its true (or much closer to true) location underground, new location is instead somewhere near the one of the entrances and doesn't reflect its true location. Do you not want me to move underground chargers in the future?

Hi Paulo! Please check the definition for highway=secondary at osm.wiki/Pt:Tag:highway%3Dsecondary. What you have here is most likely highway=residential (osm.wiki/Pt:Tag:highway%3Dresidential) or highway=service (osm.wiki/Pt:Tag:highway%3Dservice). Same might apply to another recently mapped way at osm.org/way/221910668. I would appreciate you reviewing these cases and making corrections. Thanks!

Hi Spac3Rat and welcome to OpenStreetMap! You've (seemingly accidentally) changed the highway in this changeset while all you wanted to do is probably to remove the helipad. Please be careful and enjoy ;) I've already reverted the highway change in osm.org/changeset/146496927
---

Published using OSMCha: https://osmcha.org/changesets/146495681

Same applies to other changesets made today/yesterday.

Removing layer=* from the highway and tagging it as tunnel=building_passage should've been enough to resolve the issue, adding layer=1 to the building makes little sense to me: osm.wiki/Tag:tunnel%3Dbuilding_passage explicitly states that "The layer should be the same as the layer of the building ... if the building doesn't have a layer tag, the way should not have one either." Could you revise your change please?

Correction, it may not match the height but there's definitely nothing above of below it that is still counted as a building and not a pool. Is there even a building there though? I can't say if there is :-\

Making the pool an inner part of a building polygon implies to me that its height matches the building, i.e. there's a tall column of water there, which most probably isn't true. Could be adding `location=roof` to the pool instead is a better fix?
---

Published using OSMCha: https://osmcha.org/changesets/146138325

@PedroMTG13, FYI you've converted an elevator node 11231050537 into a building 229817547 here, and the node was previously a part of parking site relation 16405776 while the building now isn't. I'm going to fix it up as part of my work on parkings. Not sure if iD warns about such things (at least about removing a node that's part of a relation), not good if it doesn't...