Get more structured about 'locations'

[lukegb]

There are a few cases where it might be useful to be more structured about 'things at a place'. Maybe we should make this more structured (and have a reference to a single location table rather than putting coordinates everywhere?)

To some extent it might be nice to be able to cross-reference things from the map postgis...

[lukegb]

For the record, I was thinking about this mostly in the context of locations for #1814. I actually quite liked the Semantic Mediawiki integration at WHY in terms of being able to click on things and get more information about them (in theory).

[jellybob]

I’d be very in favour of this having had to work around it in several contexts over the years. Off the top of the head I can think of various representations of a physical place including venues content can be scheduled, villages, places volunteers are needed, and the upcoming places that need some form of maintenance. I’m sure there are more I’m not thinking of.

[russss]

I don't really see what having a single location table would gain us - it's not like there are two different objects at exactly the same location. From a GIS database perspective it makes sense for the location field to live in the table it relates to. So I'm not entirely sure what we're trying to solve here.

One of the issues here is in populating these locations, particularly for stages which I believe get auto-created with some 6-year-old positions. But I'm not sure there's an especially easy solution to that.

[lukegb]

I think the main thing is that sometimes we refer to the same thing in several contexts - for instance for workshop villages they are:

• A content venue which can have stuff scheduled in (for which we generate a map pin URL for the schedule)
• A place which might have problems reported (Location-based problem reporting #1814, map pin URLs are useful for identifying 'which place' a problem has been reported in) - using the content venue doesn't make sense since that doesn't include DKs, toilets, etc.
• A place that needs volunteers (for which again, it's useful to be able to generate a map pin URL) - using the content venue doesn't make sense since it isn't just content venues that need volunteers
• A village (for which we need a location since we populate the map with villages from it) - there are non-content villages; for workshop villages we could just ignore whatever the village table says and always refer to the content venue since I think we do have a relationship here at the moment

We're not referring to two different objects, we're referring to the same object.

That said, this is kinda going backwards from 5dbb0f7 which removed the generic MapObject gubbins.