<podcast:location tag definition is too specific

[kilobit]

With full consideration of The Guiding Principles and Goal #4 - the current definition for the location tag is too specific:

<podcast:location country="[Country Code]" (locality="[Locality]") (latlon="[latitude,longitude]") (osmid="[OSM type][OSM id]") />

Location is a very fuzzy (but important) property of the podcast. Having a set of recommended formats (country, locality, latlon etc) is great, but we know that there are many more ways to conceptualise location than we would want to go to the effort of considering.

Some that quickly come to mind; the 'geo' uri scheme (RFC5870), GeoJSON (RFC7946), GeoHash etc etc.

Don't forget Elon's first podcast from Mars... ;)

My suggestion would be something like:

<podcast:location type="[location type]" [ATTRS...]>[OPTIONAL TYPE VALUE]</podcast:location>

Where [location type] is from a predefined but not exhaustive list of location formats (e.g. country, latlon etc.)

('scheme' or 'format' may be a better attribute name, if you think 'type' could be confused to imply mime-type.)

The types that are defined in the spec can be considered like a SHOULD in terms of support and implementations could be directed to ignore location blocks where the format is unrecognised.

This would be a more robust, elegant and interoperable tag specification without too much complexity in the spec or for implementations.

Many thanks for the exciting work!

[jamescridland]

Hi, @kilobit - these are great points.

GeoURL

As I read RFC5870, it seems to be eminently usable here as an enhancement for latlon. It appears to be precisely that, plus an optional altitude element. Valid values are:

geo:13.4125,103.8667,560 - 560m above sea level at this latlon point

geo:13.4125,103.8667 - just this latlon point.

I'd be very happy to see latlon replaced with a geourl tag, since it appears to add little complexity, gives the flexibility of adding altitude detail, and aligns with an RFC spec. @daveajones ?

Other formats

We currently have an osmid, since that data is openly licenced, editable, and can be ingested. (It isn't 100% permanent, but nothing other than a GeoURL is going to be in this space).

GeoJSON polygons for many places is excessively large - here's the GeoJSON polygon for Columbus, OH which is 268Kbytes.

Do you think it be acceptable, instead, to get that data from OpenStreetMap - Columbus OH would be osmid="R182706" ? Is it easier to have one canonical place where this data comes from?

For other formats, we could have a geonamesid, which could use the placenames from geonames.org. Similarly, we could have a Google Maps ID, which is available for customers with a valid API key from Google. How would you ensure this is simple for developers to use?

locality is designed for human readability and not for programmatic use. My well-worn example is locality="Palace of Westminster" or locality="Houses of Parliament" - the official name is the former, but a podcast about Parliament may well like the latter. There's no reason why locality couldn't be "Dave's House" if that's what the podcaster wants to appear in the player. It would be a shame to lose it from the spec.

For Elon Musks's first podcast from Mars, world=[IAU abbreviation] would be a helpful addition to this specification when the time comes... ;)

[daveajones]

I like this a lot.

@jamescridland When you start sucking in this data on Podnews, what would you most want to see a tag like this look like?

<podcast:location type="osmid" locality="Mom's House in Columbus">R182706</podcast:location>

...something like that?

[jamescridland]

Well, let's answer that two ways.

What would I like for Podnews?

<podcast:location geo="geo:13.4125,103.8667,560" type="osmid" locality="Mom's House in Columbus">R182706</podcast:location>

This is because I have a ready-built component to put a little Podnews-coloured blob on a SVG map of the world, and I don't much want to do an OSM call for every podcast - that probably means I need to run my own OSM database.

Secondly, the geo/latlon is also a fallback in case OSM ID R182706 disappears one day - since a latlon is permanent, and an OSM ID (or any mapping ID) can never be since places aren't permanent.

I'd absolutely show the locality for Podnews. I think it's the wrong name, to be honest. description is probably more correct. It is a description, after all. "Mom's House in Columbus" isn't a locality.

BUT

I'm being lazy here. And this is really HARD. If the only thing I want you to know, as a podcaster, is that I'm in the USA, then a latlon is almost useless and is actually bad data. A latlon is also useless for a podcast about "Chicago" - if it's a podcast about the city, where does the latlon point to?

It does come back to my original proposal, which was simply to use OSM IDs for everything - the USA is R148838 ;)

One other thought - we should be clear what this is for. It's not yet clear enough to me whether this is a description of where the podcast is from; or a description of where the podcast is about.

Partially, I wonder whether this is a function of where in the RSS feed it is. If it's in the CHANNEL, it's likely that the description is about where the podcast is from. If it's in an EPISODE/ITEM, it's likely that it's related to the individual episode, not to the podcast as a whole. But I don't know whether that can be clarified.

Sigh. This is hard.

[kilobit]

[T]he geo/latlon is also a fallback in case OSM ID R182706 disappears one day - since a latlon is permanent, and an OSM ID (or any mapping ID) can never be since places aren't permanent.

Would this make sense as two <podcast:location... tags? The ingesting application could then take whichever it prefers?

Otherwise, an alternative approach would be to use priorities, something like the HTTP Accept header:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9

Here the q value is used to apply a priority (absent is the highest priority).

This would become something like:

<podcast:location geo="geo:13.4125,103.8667,560" type="osmid,locality;q=0.8" locality="Mom's House in Columbus">R182706</podcast:location>

I am not actually advocating this - only suggesting that it would be an option. I think it's more complicated than it's worth.

My suggestion would be to go with the two (or more) <podcast:location tags option.

Cheers!

[jamescridland]

I hope that the canonical value is the OSMID if present. That contains lots of data about a point/relationship/etc. I'm not sure about the benefit of priorities.

An OSMID may disappear - let's say it's a tent in the middle of the desert, which is a temporary structure for three months. That's to be expected, I think. OSMIDs are also merged, deleted and other things by editors, but very rarely.

A geo point will never disappear, so it's a good fallback if the OSMID isn't present, or has disappeared. But it's relatively dumb - no area covered, no real data other than a point on the planet. It's much less rich data.

I'd be super happy for this tag to only contain an OSMID. That was my original proposal. As long as we're comfortable that OSMIDs are not guaranteed to be permanent. Perhaps CastFeedValidator can check the OSMID still exists.

[daveajones]

I think I’ll have a go at rewriting this tag tomorrow based on the discussion here. Give us a new baseline to work from using the ‘type’ structure.

[jamescridland]

#138 is a rewrite, based on a number of discussions here. Specifically for here, the proposal:

a) works with geoURIs, which are extensible to Elon Musk's first podcast from Mars

b) outlines why we need both geoURIs (lat/lon) and OSM IDs, since the latter may relate to buildings which may not be permanent

I'm going to close this discussion, if only to keep discussions in one thread. I'm very keen to get this one nailed if we can.