[Proposal] Adding `website` tags to existing restaurant POIs across ~27 US states

Communities United States
,
1

Hello,

I work at Yumo (https://yumoeats.com), an online ordering platform used by
approximately 130 independent restaurants spread across 27 US states. The largest
concentrations are in California (~25), New Jersey (~13), Colorado (~10), Texas,
Florida, New York and Oregon (~8-9 each); the remainder are scattered one or two per
state.

I am posting here rather than to a single local community because the businesses are
not concentrated in one metro area. If any regional community would prefer to review
the subset in their area separately, please say so and I will follow up there.

Before touching anything, I would like to describe a change we are considering and
get feedback.

What we would like to do

For restaurants that are our customers and that already exist as POIs in OSM, we
would like to add a single missing tag:

  • website — the restaurant’s own site, which we build and host for them

That is the entire scope of the first batch. Nothing else.

What we would explicitly NOT do

  • No new POIs. We would only touch objects that already exist.
  • No overwriting. If a POI already has website or contact:website, we skip it
    entirely, even when the existing value differs from ours. Conflicts go to a human
    review queue and are never resolved automatically.
  • No changes to name, addr:*, or geometry. These are the fields most likely to
    be actively maintained by local mappers, and we have no reason to touch them.
  • No phone, opening_hours, or cuisine in this batch. See the licensing
    section below — we cannot yet prove the provenance of those fields, so they are
    excluded by code, not just by policy.

Data source and licensing

This is the part I want to be most explicit about.

The website values point to sites we operate for each restaurant under our own
domain. They are our own data — not derived from Google Maps, Google Business
Profile, Yelp, or any other proprietary source. This is ODbL-compatible.

Our internal database does contain fields that were backfilled from Google
snapshots (notably phone numbers). Those fields are excluded from OSM submission in
code, and will stay excluded until we can establish per-restaurant that a value came
from the restaurant itself. I would rather ship one tag with clean provenance than
four tags with a licensing question mark.

How we match restaurants to OSM objects

We do not do name-based global search. For each restaurant we query Overpass for
food-related POIs (amenity=restaurant|fast_food|cafe|bar|pub) within 250 m of the
restaurant’s coordinates, then score candidates on independent signals:

  • matching phone number (weight 8)
  • matching house number + street (weight 6)
  • matching name (weight 5)
  • matching website host (weight 10)

A match is only put forward when it has at least two independent signals, clears a
score threshold, and has no close-scoring runner-up. Anything ambiguous — dense
blocks with several similar restaurants, in particular — is dropped rather than
guessed. Every match is then reviewed by a person before any edit is made.

How the edits would be made

  • A dedicated OSM account (YumoEats_Listings), not a personal one
  • Small batches, at a manual pace — not a bot run
  • Every changeset tagged with comment, source, bot=no, and a link to
    Automated edits/YumoEats Listings - OpenStreetMap Wiki documenting
    this discussion
  • We will document the process on the wiki before starting

The obvious objection, stated up front

Someone will reasonably ask: are these really the restaurants’ official websites, or
are they your marketing pages?

Fair question, and I want to give you the full picture rather than the flattering
version.

These are sites we build and host on behalf of each restaurant, on a subdomain of
ours. Most of these restaurants do not run an independent website of their own.

Full disclosure on one point: some of these restaurants also have a site on an older
platform domain that we operate. Those domains are staying online and will redirect to
the current site, so any of them already present in OSM will keep working. We are not
proposing to touch those entries — if a POI already has a website or
contact:website value of any kind, ours or anyone else’s, our tooling skips it and
flags it for human review rather than replacing it. The scope here is strictly POIs
with no website tag at all.

If your view is that a platform-hosted site does not belong in website at all, I
would rather hear that now and reduce the scope — or drop the proposal — than find out
via a revert. I am genuinely asking, not seeking rubber-stamp approval.

Feedback

I will not start any edits for at least two weeks, and not until the questions raised
here have been answered. If the response is that this is unwelcome, we will not do it.

Contact: osm@yumoeats.com

Thanks for reading.

4 Likes
Proposal to add :robot: as a reaction to AI content
2

Hi thanks for the super thorough plan and post. I’d personally welcome this kind of holistic edit to the website of these points of interest. I like to add business information with everydoor but adding websites are tedious as they aren’t typically posted on the door and are annoying to type out.

2 Likes
3

I don’t think we’d prohibit hosted restaurant sites. It’s none of our business which CMS, Web host, or ordering platform a business chooses to use. The issue is only that, in the past, some of us have noticed that other platforms have tried to co-opt independent restaurants’ own official websites, seemingly to siphon off direct customers. I appreciate that you’re reaching out to us ahead of time and planning to steer clear of existing website=* tags for now. When you do get around to manual review, what will be the process for resolving the conflicts?

California’s 25 restaurants are a small enough batch for us to review ahead of time. Maybe we could start with a list of them to get a better idea of what the edits will look like?

2 Likes
4

just to confirm: is it the main restaurant website, with restaurant not having own one? Created and hosted with their knowledge and agreement? If not all of this conditions are fulfilled I would be against such edits (automated or not)

asking as

1 Like
5

Thank you all — this is exactly the kind of feedback we hoped to receive before making any edits.

ElliottPlack, thank you for the welcome and for reviewing the plan.

@Minh_Nguyen, for conflicts, our process will be more conservative than simply choosing between two URLs. Any OSM object that already has either website=* or contact:website=* remains completely outside this proposed batch. The human review queue is not authorization to overwrite the existing value; it only records that there is a conflict.

If an existing URL appears outdated, broken, or unrelated to the restaurant, any possible correction would be handled separately as an individual manual edit, based on evidence specific to that restaurant. We would not replace it merely because we operate another site.

We will prepare the California subset for community review before making any edits there. The list will include the restaurant name and location, the proposed URL, the matching OSM object, the matching signals, and the result of the website eligibility checks described below. The actual number may be lower than 25 because restaurants without a sufficiently confident OSM match, or those that fail any eligibility check, will be excluded.

@Mateusz_Konieczny, your questions identify an important condition that we should make explicit. We build and host these sites for restaurants that are current customers, but that fact alone is not sufficient to make a blanket claim about every site.

Before including any restaurant, we will verify individually that:

  1. the restaurant knows about and agrees to the site being used as its official customer-facing website;
  2. the proposed URL is the restaurant’s current primary website, not merely a generic platform listing or marketing page; and
  3. the restaurant does not have a separate primary official website that should be used instead.

If any of those points cannot be verified, that restaurant will be excluded from the edit set.

This makes the eligible scope narrower than the original upper-bound count, which is fine. We would rather exclude uncertain cases than add an inappropriate website value.

We will post the California review list here before beginning any edits and will continue to wait for the discussion to be resolved.

1 Like
Proposal to add :robot: as a reaction to AI content
6

Where do you source the coordinates for your POIs? How did you land on 250m as your margin of error?

1 Like
7

@SherbetS Thank you — that is an important question, and I should have explained it more clearly.

The coordinates come from the address records in our own restaurant-management system. A restaurant manager can enter them manually, and some addresses may also have been resolved through Google Places autocomplete. For that reason, these coordinates are not data that we would submit to OSM, and they are not sufficient evidence that an OSM object is the same restaurant. They are only a starting point for a local Overpass query.

I chose 250 m as a deliberately broad candidate-search radius, not as an accepted positional margin of error. It is intended to avoid missing an existing POI where an internal pin is on a parcel/street centroid or a large multi-tenant building. Distance alone cannot identify a POI in our process: it contributes only +3 points at 50 m or less, +1 at 120 m or less, and no points beyond that. A candidate must still have at least two independent non-distance signals, meet the score threshold, have no close-scoring runner-up, and then be reviewed by a person.

Your question also made me recheck the prototype’s inputs. It currently has a phone-match signal, but some phone values in our database were historically backfilled from Google. That is too weak for the provenance standard we stated here. Before any OSM work, we will disable that signal for this workflow unless the particular number can be shown to come from the restaurant itself. Likewise, if the restaurant-confirmed street address and the OSM object cannot be independently reconciled, we will exclude the candidate rather than rely on the coordinate.

For the California review subset, we will include the restaurant-confirmed address, the candidate OSM object, the non-Google signals used, and the reason for any exclusion. We will not begin edits until that review and the community discussion are complete.

Thanks again for raising this.

2 Likes