How to map trial openings of features?

The wiki does not seem to guide this.

Basically, consider any WIP feature (e.g. a restaurant). Eventually, it will be near completion, and will be opened to the public. However, sometimes, this feature may enter some sort of “trial run”, “trial opening”, “trial services” (or other similar names) status, where de facto it is open to the public, but the owner/operator will designate another day as its “actual” opening date.

OSM has this start_date tag, but it doesn’t seem to clearly specify whether it describes the official opening date or the de facto opening date.

How should we deal with this situation?

I would map the de facto situation, in the spirit of Good practice - OpenStreetMap Wiki

The usual term here would be a soft opening or soft launch, as opposed to a grand opening. The point of a phased opening is to manage expectations while they work out the kinks, hire staff, or test their menu. As a customer, you’d be served as if the POI is fully open, maybe even with more of a personal touch.

Normally there’s no real need to distinguish between soft and grand openings in OSM. However, upon the grand opening, you may need to adjust the opening hours and contact information.

By the way, this is something we pay more attention to in OpenHistoricalMap. Ideally, we’d tag start_date=* on two different elements: one representing the feature under construction and the other representing the feature once it’s open and in service. Technically, the latter would have a start date based on its soft opening. Unfortunately, often we only know a single date without any qualification, so it can be either. If we know whether it’s a soft or grand opening, we can say so in start_event=*.

Either the amenity is open to the public or not. Like if I can go there and grab a pizza, it’s open. If I can’t get my pizza, it’s not open. You can add opening_date (wiki), to record the “official” opening date. After the “official” opening, change opening_date to start_date.

3 Likes

if you can buy a pizza to take away but the place (seating) only will open next week? Or there are already presentations in an events room, but the rest of the museum (exhibition) will only open a month from now?
There are lots of situations where the actual situation is more nuanced than the binary yes/no you suggest. In general we are not mapping this kind of detail (and it is ok IMHO), but pretending it doesn’t exist is a misrepresentation.

1 Like

amenity=fast_food + cuisine=pizza doesn’t require anything besides I can get a pizza. It can be only outdoor seating, indoor seating, no seating, only take out,… would believe for all of that we have a tag for. What in general we do not record is, that you can just get Coke, but no Sprite, or that pepperoni pizza is not available.

Same for the museum. Even there is just a few exhibits displayed in the first room, its a tourism=museum. Also here, such details can be tagged using the indoor-tagging.

2 Likes

I would go further, maybe you cannot even get “a pizza” (as a round pizza) but only slices of pizza. It is hard to tell because pizza tagging is not very developed so far. Some places I know sell sliced pizza at lunch and round pizza (entire pizza) at dinner. How could we tag it?
(FWIW, sliced pizza around here is sold by weight, while round pizza is sold by unit)

From my experience, I’d describe amenity=fast_food cuisine=pizza as a slice shop and amenity=restaurant cuisine=pizza as a pizza parlor. Both will sell you a slice or whole pie, but a slice shop is generally where you go for a slice and a pizza parlor is generally where you go for a whole pie. If they’re switching it up between lunch and dinner, then it’s kind of like when a white tablecloth restaurant offers a less formal lunch buffet: pick one.

While we’re pushing the boundaries of lifecycle tagging, what about a pizzeria that serves “Hawaiian pizza”? not:cuisine=hawaiian;pizza until they come clean, right?

1 Like

I was trying to be general, and only briefly hinted restaurants as a discussion primer. How come we are now discussing pineapple pizzas…

But to conclude, I can see we should use a combination of start_date and opening_date :

  • start_date is for when the feature de facto opens (e.g. soft opening)
  • opening_date is for when the feature de jure (aka “officially”) opens; usually this is some time after start_date

This I think is quite clean solution to the "soft opening mapping” problem I started with.

1 Like

No, both of them describing when the feature becomes/became active.
start_date describes when it became ative, like when the bridge was build. opening_date when it will be active in the future, like that the bridge will be ready in August 2026.

There is nothing like soft opening state in OSM. That’s what I tried to express with the pizza example. As soon as they serve/sell the first slice of pizza, it’s an active pizza place in terms of OSM.

3 Likes

For me this kind of things is not really verifiable later and should be out of scope for OpenStreetMap mapping.