RFC: Physical Venue Map References

[deniz-blue]

Currently, PhysicalVenue#coordinates exists to provide latitude and longitude coordinates of a physical venue. This, by itself, is somewhat enough to create a link to open inside multiple maps applications.

Would it be a good idea to also store specific ID's/references to the venue in the maps databases? For Google Maps, it would be the Place ID; for OpenStreetMap it would be Node id.

@EmeraldSnorlax proposes that we should enforce a specific map vendor and we should model the metadata using URLs.

I was thinking about something like this however:

interface PhysicalVenue {
  maps?: {
    google: { placeId: string };
    osm: { nodeId: string };
    [vendor: string]: any;
  };
}

Rain has pointed out reasons as to why a vendor-lock in is a good idea:

• When creating events, its not good UX to show "choose a map vendor" and a mile long list
• Having the embed change depending on vendor is bad

[takipsizad]

1: i think it will lead to a way better ux experience
2: i disagree with a vendor lock-in because an event organizer might have some reason to (not) use a specific map provider
3: for embeds i think implementing just OSM and google maps might be enough

[EmeraldSnorlax]

i mean it kind of depends what context you see this being used in; is this meant to be a centralised directory or something closer to rss where people subscribe to certain publishers, or something for organisers to selfhost?

just OSM and google maps might be enough

google maps is the dominant mapping service in the west, and osm is patchy depending on location. (anecdotally, osm seems to have the best coverage in western europe where google maps is already the dominant service...) there are several major countries where both google maps and osm are either ass or literally unusable, e.g. south korea.

this is fundamentally a cursed problem to solve in the generic unless you have a specific usecase in mind as to who is using this software. you can't reallyyyyy have something that is generalisable everywhere and something that is programmatically easy to consume for location references. (this is also ignoring ambiguous addresses. "rhb 312" makes perfect sense to someone that goes to my university, and is the canonical way to reference this location but is completely incomprehensible or might mean something completely different to all non students. side note; no machine-readable location reference can correctly handle locations within a building unless it's just a string that contains the name.)

even hyperlocal, algorithmic addresses like plus.codes or w3w are wildly inconsistent in usage. i don't think i've ever seen anyone ever use a plus code outside of a few indian cities for places without formal addresses. w3w is probably the most "widely" used in the west, but it's also proprietary, not to mention has countless algorithmic flaws. (and neither of these can handle locations inside a building.)

you kinda have to make a compromise somewhere...

[EmeraldSnorlax]

Having the embed change depending on vendor is bad

i think this could be acceptable, as long as it's on a relatively clear boundary such as e.g. country and doesn't change from one event to another in the same city or whatever so it's at least internally consistent

[deniz-blue]

the scope of this issue is to define a standard way to put IDs of place objects in the databases of map vendors in the event format specification
we are not defining what applications or data consumers should do with the data or how they should/could construct this data
it should be extensible/agnostic of map vendors for forwards compatability and customization options

if you are asking about the general context of the project it is to define an open source, machine-readable, generalized, extensible events data format that can be used to represent event details in a decentralized way. it is not meant to be centralized
this repository also provides some basic tooling, libraries and applications around it but they are not the main focus

[EmeraldSnorlax]

yeah if it was just providing addresses this would be "simple" in that you "just" need An Location Reference but for "events" specifically the location can be extremely specific and not mapped by mapping services because it's out of scope for google maps to know about every single room on a campus for example

[deniz-blue]

Updated draft:

{
  $type: "directory.evnt.venue.physical";
  // ...
  maps: {
    "org.openstreetmap.way": string | string[];
    [vendorAndType: string]: string | string[];
  };
}

Keys now use NSID's that also include the type of entity. Values are string or string array (should be coerced into string array) with the actual identifiers of the entities. This allows us to encode multiple entities.

Also Google Place ID's are apparently not stable. Shouldn't be surprising...