What about a marker (simple boolean) to show, if a event is open air or not?
I can imagine that it can be at the event entity or the place. What do you think?
You can link the event to a place, it’s the place that should show this open air info, IMO, rather than repeat it on all event for this place.
The type of place already kind of tell this info, no? Stadium, hall, studio, etc.
1 Like
What about when the main stage is in the open, but some of the smaller stages are under canvas?
I would say some place types do indicate if it is open air or not. But some are unclear about this or do not tell anything at all. Festival stage for example can be open air, in a tent or indoor.
And I think you are right, it should be located in the place, not the event. I think a place can not be open air sometimes and indoor at another time, or?
1 Like
There is always an exception…
Sometimes indoor halls hold events outdoors.
De La Warr Pavilion, Bexhill on Sea.
They hold plenty of concerts indoors in the winter. Last summer that event above was scheduled for outside in the grounds. Then a storm was scheduled and they moved the whole event inside at two days notice. Aircon could not really keep up so you could see why outside was preferred.
But maybe then it is better to have sub places for the venue? Like we have the festival stages as separate places with part of rel.
And when there is a change in place one have to edit anyways.
1 Like
Yeah, the sub-places makes sense to have inside\outside flag attached. These already exist with the main MB Places. I’ve not gone into Events much, but do plenty of adding bootlegs to the main MB.
So a marquee tent is inside due to the roof even though it doesn’t have walls?
And a performance at Cardiff Castle would be outside as it has walls, but no roof.
A simple definition - do I get wet when watching?
1 Like
Some stadiums have closeable roofs too. Not sure how much it matters at that level though, since I’m not quite sure what the usefulness is really of open-air vs not. Is it about the acoustics, or about getting wet if it rains? 
2 Likes
I think closable locations are a rare edge case we don’t have to handle. And the open or close during an event seems even more rare.
So should I create a ticket or is it not important enough?
Btw. I can imagine more fields I would like to use. But I think they are too niche. Maybe there is another way to save that information?
I am talking about
- sold out
- sold out date
- approximate entry price
- approximate people capacity for places
and so on.
Maybe Annotations? But the single information is not machine readable because it is just plain text. Maybe we can use some kind of convention like key value pairs with a specific syntax. Then a client can parse that information.
1 Like
These two I find interesting personally
re. sold out data, I find it a bit tricky data-wise and personally not so interesting, but it’s so obviously helpful for third-party event tools/apps that it might be worth adding anyway? A question that arises in that case is if the data is too granular and time-sensitive for editors to add reliably (e.g. too many fields, not enough event editors), is it worth having at all? If it’s okay for it to be sometimes accurate, sometimes not, then it might be worth adding.
1 Like
I mean an editor is not forced to enter that. For the numbers I would be very vague. I have something in mind like the count of dollars, that show the price. Facebook does that, right?
Free
$ = <50
$$ = < 100
and so on.
Same for capacity.
The dataata would be interesting if available and no problem if not.
For sould out I can show a badge in FestivalGuide. If it is not present the user does not know if sold out but no data or not sold out. But if it is there, they know, that it IS sold out.
I think we can be precise re. entry cost/s.
vgmdb stores the cost of releases which is more wild (imo)!
How to figure out currencies might require some stuff to be noodled out, and how to handle multiple ticket pricing tiers, but this seems like the kind of weeds that MB likes to get into.
I would make a ticket/s. Whether there are devs available to pick it up any time soon is another story, as I’m sure you’re aware
Entry costs could be confusing. Are you talking standard tickets, VIP tickets, weekend tickets, day tickets, standing, sitting, limited view, including camping, including parking, “early bird” buy early tickets, gold, silver, bronze…
Some Festivals have multiple layers of pricing. I’ve seen all of the above.
I’ve even bought a concert ticket which had an option to include a half time bottle of champagne. That was Hawkwind playing in a fancy theatre that was clearly more used to a posh crowd.
A count of dollars don’t make sense as you have inflation changing over the decades.
To me it’s interesting to know if an event in 1880 was 2 pennies, even if it doesn’t line up with today!
1 Like
Me too. I remember gigs being a fiver. What I meant was the suggested scale of $<50 or $$<100 as that will not work over the decades. Much better to put an actual price down with a local currency symbol.
2 Likes
In thought of the many tiers for tickets I came up with the range idea. I mean I just want to differentiate between in example Wacken ~400, Reload Festival ~200 and free/non profit local events. And for Concerts we have also ranges like Rolling Stones with hundreds of dollars, Rammstein ~100, I would say normal sized artists ~50 and newcomers ~30.
Examples above apply to Germany/Europe.
But I see the problems coming with currency and inflation. I like the Idea to have the local currency.
As you speak of camping and stuff, for festivals I also like data like
- “Has special camping” like prepared tents or caravans, also with prices maybe.
- “Allows camping near the car”
- “Has special caravan camping”
- “Camping included”
No matter what I think we should collect a list of possible data points to get a feeling if structured data or key value pairs or whatever fit best.
And yes, I’m aware that this will be far at the bottom of priorities for the devs. It is even for me. But sometimes I lake to input that data and maybe we could start with key value pairs in annotations or something because it does not require any dev resources. I we get structured data later, we may run a bot to migrate to it. But even if we start with key val, we should think of possible fields to get as much consistency as we can.
I think @sanojjonas will also have some ideas.
You are over thinking it. A range of tickets will always be misleading. It fails to give you a real price. Some of the top tier tickets are a far away from standard tickets. Keep it simple. If you do ticket prices then just allow space for multiple prices to be added with a type. Especially as years after an event you are likely to only have the one ticket in your hand and may not know what the others were priced at.
1 Like
for starter the open air thingy. (what this thread is all about)
cant we just add some extra place types? so that next to venue and club and stuff we have open air stage, tent stage, open roof arena, …
i think that doesn’t require any changes to the data structures, just some extra options.
then for the pricing, i think you should always need to be able to enter the value in the local currency. i don’t see it useful for mee to have to enter a price in dollars for gigs that are in Europe.
but i do think it would be nice if you could add a preferred currency as a user setting. so it can show you what it would cost in your currency (for example if i look at a gig in America it would show me how much it would cost in €)
for the venue size, i think this can be a handy property. this gives you an indication on how big a show can be. is it a small venue that does some smaller cosy gigs where you are right at the stage. or is it an arena where 100.000 people can go. this should always be the max amount of people that can enter the venue according to the fire safety guide. since this should be te max allowed people in a venue, this can change from time to time. so i suggest it has a start and end date
the camping part is in my opinion very niche. i like the idea of it mainly for the pricing, if we add pricing for events then it also feels logical to add pricing for camping aswell.
about the extra features about the camping, i think i would prefer to know more about accessibility stuff of the event (like is there a wheelchair stage, is there an induction loop for people with bad hearing,… ) that has more to do with the experience of live music and can be very information for people wanting to go to concerts with disabilities. but i understand the camping stuff aswel.
ideally these kinds of information comes directly from the venues themself and not just entered by random users.