<podcast:location> startTime and duration attributes

[douglaskastle]

Based on the work seen for the the soundbite I was thinking that the location tag could actually benefit from marking points in a podcast that have location.

Idea being, the podcast itself is not locationally determined, but it may be covering some topic that has a location, and there may be more than one topic in more than one location. The addition of a time index and duration, like startTime and duration in the soundbite tag, as optional, would allow people to search podcast by location, but also to search for content within a audio file. There can be more than one of these tags per episode.

This idea extends out of an idea I have for a walking tour podcast. There could be chapters at different locations and you as the tourist might not access the tour linearly, but you can jump to the bits of the audio file/podcast, based on where you are currently. This would enable that.

A further extension of this idea is that a walking tour itself could have a full GPS track that matches every second of the audio file. At this point it becomes much to unwieldy for the RSS feed and suggests it becomes very similar to the transcript, deep data, an entry into the feed that points to a json file could be host that and is only downloaded if the user needs it that way.

[daveajones]

Well, I think this is a great idea. Got an example of how it would look in a real-world implementation? Just a rough sketch would suffice if you can post something. That way I'll be sure we're on the same page and I can write it into the spec.

[douglaskastle]

yes of course

There are two main ways I see this.

One is a basic travel or maybe a news magazine podcast. Where the location the podcaster is recording from is irrelevant, but the topics been covered are, and the fact that there may be more than one topic is important to consider. So minimally the RSS feed would contain the latlon of the the location that the item topic is located, the startTime within the audio feed and maybe a duration of the item, a bit like soundbites, consumer of the podcast might only be interested in that one item only and have no interest in subsequent items (philistines I know). The podcast itself may or may not have a location tag of its own (without startTime), if it does well it is if the podcast hosts location is somehow important, but is separately from the topics.

Ultimately for search, a given podcast might feature in 2 or more different locations if it contains portions located in different places.

Second case is more like a walking tour. A few years back I had friends visiting me in Dublin/Ireland from Australia. I met them in Temple Bar (Latitude: 53° 20' 26.40" N Longitude: -6° 15' 27.60" W) and we walked from there to the Guinness Hop Store (Latitude: 53° 20' 18.00" N Longitude: -6° 17' 7.80" W) via Christchurch (Latitude: 53° 20' 21.00" N Longitude: -6° 16' 10.20" W), I talked the whole way giving them the spiel about the area. I was thinking that the whole thing could have been recorded (I do love the sound of my own voice to be fair). But it would only work going one way, the same way. So even as we walked the reverse of the same route it would not have worked, even though we are in the exact same areas.

However if certain areas of interest within the audio file were marked (chapters effectively with a geo location, but duration here is probably more important), some one walking the reverse route would be able to navigate relevant sections of the audio when they were at the locations of interest. Obviously the audio app would have to support that ability, but have the geo tag chapters support would be amazing.

Again some one who is not physically in the area could also just access the specific elements of audio for bits of the audio they were interested in from the luxury of their own homes.

Adding a GPS feed like a subtitle/transcription JSON, while possible, I don't think it the requirement of this issues, but i comment on it here. I am unsure for the JSON transcription if the aggregators are meant to be parsing them to assist with search. But if they are for transcriptions, which is meant to bump up the hallowed SEO, I don't see why they couldn't for GPS track (they may not, but that is separate )

[benjaminbellamy]

This would be great to make podcasts geographic search so powerful.
I would add this to the json chapter file:

{
  "version": "1.0.0",
  "chapters":
  [
    {
      "startTime": 0,
      "title": "Intro"
    },
    {
      "startTime": 168,
      "title": "Travel to Europe",
      "img": "https://en.wikipedia.org/wiki/Europe#/media/File:Map_of_populous_Europe_(physical,_political,_population)_with_legend.jpg",
      location{ 
            "localname":"Europe",
            "osm_type":"N",
            "osm_id":25871341,
            "category":"place",
            "type":"continent",
            "lon": 51.0000000,
            "lat": 10.0000000
      }
    },
    {
      "startTime": 410,
      "title": "The Eiffel Tower",
      "img": "https://en.wikipedia.org/wiki/Eiffel_Tower#/media/File:Tour_Eiffel_Wikimedia_Commons.jpg",
      "url": "https://en.wikipedia.org/wiki/Eiffel_Tower",
      location {
            "localname":"Eiffel Tower",
            "category":"tourism",
            "type": "attraction",
            "osm_type":"W",
            "osm_id":5013364,
            "lon":48.8576248,
            "lat":2.2942817
      }
    },
…

[daveajones]

I like this idea a lot. Once we finalize the location tag, let's make this match and look at a JSON chapters version bump.

[npruzaniec]

Agreed, makes more sense as a part of chapters. Seems like a very niche use-case though. Is this too niche to include at this point or are there a lot of travel/sightseeing podcasts out there. Seems like just including an Open Street Map/Google/Apple Maps url to a location could be a simpler way to facilitate this.

[benjaminbellamy]

Having geolocation in chapters files makes sense only for search engines.
But it does not cost much and it’d be really powerful.
Imagine, wherever you are, click "search local soundbite" and you instantly get a part of a podcast related to where you are.

Regarding URL, since longitude/latitude (GPS WGS84) are recognized by all systems, creating the URL from lon/lat is really very easy:
https://maps.google.com/maps/search/48.8576248,2.2942817
https://www.openstreetmap.org/search?query=48.8576248,2.2942817
https://maps.apple.com/?q=48.8576248,2.2942817

[douglaskastle]

Ok it is starting to get muddy. All this is requesting in adding the option for a startTime and duration to the location tag, which is the one that physically appears in the RSS feed. This will allow search to understand what the places the episodes are referring to.

One could also add GPS to chapters, but that feels like a separate requirement.

Is this the same as soundbite? and enhancement? or are the two separate beasts that just look similar, I am not sure, but having the options availble doesn't limit anybody from doing what ever they want to do.

As to-

Is this too niche to include at this point or are there a lot of travel/sightseeing podcasts out there

Maybe or maybe no one has been able to do anything like this because the hooks were never there. I have been toying with the idea of a geopodcast for 10 years, getting the ball rolling is the toughest bit. Worst case, no one uses it.

[jamescridland]

#138 may be useful here as a suggestion for the "location" tag.

I'd be keen that chapter-specific location data is held within chapters - that seems a great place for it.

maps.fm is good prior art of location-based podcasts.

[jamescridland]

To help us all, if you don't mind, I will close this thread to keep conversations about the location tag in one place. I hope that's OK with everyone. See you over at #138