Steak 'n Shake Bitcoin Tags

Communities United States
1

Hi all,

Nathan here from BTC Map.

I recently made this bulk edit to add the Bitcoin tags to all Steak 'n Shake locations as identified by their Wikidata code.

This was based on their public statement on the matter, which has since been verified by multiple customers.

I didn’t follow the automated editing guidance (which I’m rectifying here) and so @Kinsio reverted the change through this manual edit.

I wanted to start this thread to ensure we have properly engaged the community on this topic with a view to reinstating the Bitcoin tags for Steak 'n Shake locations as soon as we can gain consensus.

Currently, these locations are not showing on BTC Map (basically a filtered view of OSM), which is degrading the user experience of our US-based users and those traveling within the US.

Are there any objections to the change or suggestions?

Cheers,

Nathan

1 Like
2

Based on the bit of discussion in the OSM US Slack (anyone registered there can view the thread here), I think our main issue with the original was the lack of QA (as you yourself saw was an issue, with the subsequent fixes for matches that clearly weren’t appropriate).

Something I personally think would be an excellent way to do this, though admittedly it would broaden the scope of this from an automated edit to an import (and involve quite a bit more work and documentation, though if it feels a bit much for you alone then we could perhaps make a project of it; I think it would be well worth the effort), would be to replicate the methodology of the All the Places (ATP) US data import while also adding the Bitcoin payment tags as well. I’ve checked and while ATP does have a Steak 'n Shake spider, it also seems that Steak 'n Shake was not one of the fast food chains included in the ATP US import, so this would be two (or more) birds with one stone:

  • All the Places would be your QA (though as we saw with the few mistagged former Steak 'n Shakes that got caught, and the fact that the Beaumont, Texas location is still on Steak 'n Shake’s website despite having been closed for two years, there’s some further precautions worth taking as well, with careful query design and other measures);
  • This would extend the map improvements the original ATP import provided to Steak 'n Shake locations as well. (And for what it’s worth, Steak 'n Shake is hardly alone here in having locations listed on its website that shouldn’t be there anymore; I think the ATP import pushing non-matches to MapRoulette challenges was a very smart way of handling this and other possible oddities, and since with BTCMap you have a community actively interested in this data and already used to working on verifying merchants, you could mobilize them to help with the challenges.)

If you like this idea, @whammo, who carried out the ATP import I’m referring to, may be able to help you work out the details.

3

Yeah, there were 4 anomalies due to stale tags - and a JOSM user error my side as I thought I had removed these locations! Subsequently rectified in this changeset.

1 of those has already been addressed by a local mapper.

This Overpass Query still has 3 anomalies remaining, 1 of which there is a comment on by @jjyach saying that the brand tags are indeed stale. The modified query also accounts for disused tags,

I suggest we verify and update the remaining 3 anomalies (preferably by local mappers, but a quick online search confirms that these are no longer Steak 'n Steak outlets) and proceed with the update.

Whilst I think the wider verification of Steak 'n Shake locations and the potential import of locations from All The Places is a good idea, it is beyond the scope of our change. I think incrementally improving data quality is a better approach. I’d be happy to be involved in the wider changes and I do have contacts within Steak 'n Shake that we can query changes with, especially if they have stale data on their own website as you suggest. I’d prefer this activity to be led by an in-country mapper though.

In the meantime, if there are locations that no longer exist in the current OSM dataset, or new ones that are not present, then our users will help verify this via our existing verification channels (indeed this was already happening) and so this will help cleanse the data that already exists prior to a more extensive overhaul via ATP.

Does anyone have any suggested modifications to the main OP query?

4

I think the ATP stuff is confusing the situation.

Your goal seems to be adding Bitcoin tags to all “Steak 'n Shake” in the US, however OSM doesn’t have an accurate list of locations, we have a bunch of old locations. Bumping modified dates on bad POIs makes it harder for people to get a good understanding of how correct OSM is. And adding these tags to bad POIs actually ruins the quality of your own map.

FYI your query ignores nodes and relations, try:

area["ISO3166-1:alpha2"=US]->.searchArea;
nwr["brand:wikidata"=Q7605233][amenity~"^fast_food|restaurant$"](area.searchArea);
(._;>;); out meta;
1 Like
5

Yes, that was on purpose as many of the nodes are actually part of the ways and that was causing me issues in JOSM. I now see that would still be the case and would exclude valid nodes.

Is there a better way to exclude composite nodes in JOSM as they obviously shouldn’t be tagged.

6

It seems the dataset is generally in good shape, with a few exceptions as commented. As per the initial changeset, change_date: would be scoped to the XBT currency tag and so that would reduce any confusion, notwithstanding the last updated tag.

As I mentioned, the presence of the Bitcoin tags will help verify the existing OSM data as our users submit verification reports as they visit locations.

7

I don’t quite understand your workflow here. And I don’t want me talking specifics to give you the impression I support this edit. I don’t, at least not in this way. But once the data is in JOSM, you shouldn’t be applying tags to everything, just specific things, selecting multiple things while holding Ctrl or using Ctrl + F.

Both my examples seem to be closed, and not part of the the few already commented. OSM (thanks to NSI) is usually pretty consistent for brand tags, and the few examples do show it’s not always the case. But when I say OSM doesn’t have an accurate list, I mean closed locations.

This doesn’t take XBT, and it wasn’t checked on 2025-05-16 because it’s closed.

Thank you. I like fresh data a lot, and I appreciate a pulse showing POIs are still around.

3 Likes
8

Oh yeah, I didn’t even notice that the mass edit added check_date:* tags. That’s one thing I can say for sure should not be done in a mechanical edit like this. It implies a kind of review of that particular location that simply did not occur.

I still feel like comparing against ATP is the most logical way to verify the integrity of the OSM data, which I think is a level of care that’s entirely called for when editing this many POIs, but I do get that that greatly complicates things.

As far as making sure you’re only editing the right things in JOSM, you can always do a JOSM search of the data you loaded that basically replicates the way you selected it with the query in the first place.

By far the biggest concern you’re gonna see here is the one about touching stale POIs making the last modified date give the impression that individual POIs have been verified more recently than they actually have.

1 Like
9

My position was that the dataset overall was improved (perhaps for a niche use-case), but that some elements (as evidenced above) got worse (perhaps for everyone else). I understand that this might not be favorable for the majority of users.

We have temporarily met the needs of our users by including the S’nS locations by "brand:wikidata"="Q7605233" and not by "currency:XBT"="yes" and so we can now focus on data quality of the underlying location data.

Given that we already know there are anomalies within the location data from ATP (and indeed S’nS’ own website!), I suggest the following:

  1. I get an up-date-date list of locations (inc. other data) directly from S’nS.

  2. Someone from the US community (perhaps @Kinsio ?) uses this data for a more widespread update of the dataset (inc. addition of the relevant Bitcoin tags).

Does that sound like a reasonable way forward? If so, is there any specific data we would want from S’nS?

Cheers!

Nathan

10

Yeah, this is a great feature. Verifications along with comments enable us to highlight ‘active’ elements, whilst creating issues for locals to pay attention to ‘inactive’ ones.

2 Likes
11

I’ve started making this edit, but it’s taking a bit longer than I remember and I’m heading out so I’ll finish and upload later or tomorrow.

We have the data from there website, coords aren’t always great and I don’t trust the opening hours enough to add them. If you are in communication with them: a list of there closed locations would probably help us remove locations, at the moment I’m just flagging locations that are likely closed. Also I can probably provide them with OSM coords after, they may want to use them to improve there own website.

In my experience, finding the right person to talk to at a company is basically impossible, but if you’ve managed, well done.

1 Like
12

This would obviously be ideal if you feel like you can get it. The big thing with that would be to make sure you get a statement explicitly giving OSM permission to use the data. This wiki page should give you an idea of what to ask for.

1 Like
13

Steak 'n Shake vs OSM :upside_down_face:

Because of this, and a couple others like it, I’m not gonna add check_date=2025-05-24 to OSM :frowning: