Re: MapML encoding of video features

Peter,

1. Your tutorial page is clearly laid out and looks like a great start. Extending this with more examples would be very helpful.

3. I agree that a polygon is a workaround, but a simple circle is a useful tool, e.g. to indicate proximity. Web map APIs generally support circles, e.g. Google, OpenLayers and Leaflet, and I’ve already identified a need for them in my video use cases. It’s interesting that the OpenLayers ol.geom interface has a design very similar to GeoJSON’s structure, with the notable addition of circles: http://openlayers.org/en/latest/apidoc/ol.geom.html <http://openlayers.org/en/latest/apidoc/ol.geom.html>. I’ll post something suitable to Maps For HTML CG as you suggest.

4. WebVTT offers an established mechanism to add timing cues to an HTML element for a video file, with CSS styles, etc. My proposal is to replace its marked-up subtitles with marked-up map controls, which borrow the timing aspects of its syntax and add a similarly-lightweight protocol.

My understanding is that MapML is designed as an HTML element-based solution to provide comprehensive access to the Maps APIs, which is an admirable goal but means it is (by definition) not lightweight. I believe it’s possible to create a slimline protocol to address my focussed use case requirements, and include an extension element which can be used to support additional content beyond the original scope, akin to GPX’s extension element. I think MapML may be a good fit to cater for those extended needs, as I’m sure there will be future use cases I’ve not yet considered. 

Retaining video-map timing details in a separate file also makes them accessible to the wider video community, in a similar fashion to VTT files for subtitles, which is a key consideration in engaging the user community and encouraging uptake. It also allows them to be easily recorded on capture devices, e.g. mobile phones, and shared online with videos, e.g. YouTube, to help build an online user community with global reach.

My tech demo is similar to your ‘finally’ use case, and consists of two equally-sized HTML elements for the map and video respectively. I took inspiration from a user’s experience of walking with a paper map, looking up to see their surroundings (top panel: video) and looking down to see the map (bottom panel: map). In the mountain rescue use case, the operator needs to see both the video and map clearly and concurrently to correctly identify their target’s location, and using an aerial image instead of a cartographic map allows better precision, as it shows unmapped features such as individual trees which also appear on the video.

Many thanks for your feedback, and good luck with MapML.

Rob Smith

Away Team
www.awayteam.co.uk <http://www.awayteam.co.uk/>
> On 15 Jan 2018, at 19:51, Rushforth, Peter (NRCan/RNCan) <peter.rushforth@canada.ca> wrote:
> 
> Hi Rob,
> 
>> 1. ... It might help others to more easily understand these features if you made a sequence of simple examples, e.g. how to add a marker with a label, how to draw a path, how to draw basic shapes, etc. 
> 
> Yes, that would be ideal.  I started writing tutorials with "how to make a map with MapML":  http://www.nrcan.gc.ca/earth-sciences/geography/topographic-information/free-data-geogratis/geogratis-web-services/18875 and I intend to extend it as time and resources allow.  I was thinking that since vector MapML is more experimental at this point, that after Testbed 14 is done will be a good opportunity to extend the documentation.  I would like to get other contributors involved, and I hope that I can bring the client code base closer to compatibility with the just-released Leaflet 1.3.0, in the further hope that we can find some common opportunities with the Leaflet.js core contributors.
> 
>> 3. Is it possible to draw a circle in non-CSS pixel units with MapML? For example, how can I draw a 10-metre radius circle around the Greenwich Observatory at 51.48N, 0.00E?
> 
> The intent of MapML vectors is to rely on OGC Simple Features for the geometry model.  As such, I believe (anyone with better knowledge than this please correct me) that a circle is easily represented by a Polygon with the vertexes arranged approximately in a circle. So, in order to enable simple client-side creation of circles as features using WGS84, we would have to either extend the standard or do it imperatively, via a attribute/property/ API method on the <layer> element, or something similar.  Certainly worth discussing!  Maybe you could join the Maps for HTML cg and we can design something through email over there.
> 
>> 4. The HTML5 video element already supports metadata tracks, so I propose:
> <div>
> <h1>Search and Rescue Drone flight path 2018-12-22</h1>
> <video width="640" height="360">
>    <source src="flight-2018-12-22.webm” type=“video/webm”>
>    <track src=“flight-2018-12-22.meta” kind=“metadata">
>    Your browser does not support HTML5 video.
> </video>
> </div>
> 
> where the flight-2018-12-22.meta file contains the associated map annotation details, e.g. draw a line using a list of path co-ordinates at given times, in a suitable standard format.
> 
> Yes, I think that would be ideal. I see that tracks can contain structured info, including html markup or json objects. (Why not MapML?). The important thing for such tracks would be to relate sequences from the video / audio to locations on a map. The task then is to define a reliable way to do that.  If the video/audio element is (part of) a property of a MapML feature, that is a predefined scope for the relationship, no? That is to say, that a video in an HTML document, despite that it might be have a track that contains coordinates of a path, how(why?) would you create an API to access that info if maps weren't part of HTML?  OTOH, if maps are built-in to HTML, you could associate the video/audio track to maps in different ways, I think.  I think this is fertile ground.
> 
>> I’m unclear about the aim of your ‘balloon’ example. Which problem is it trying to address? Firstly, the video-related feature does not link the path co-ordinates to any timing information in the video. I presume that the ‘balloon’ is equivalent to a Leaflet Popup: http://leafletjs.com/reference-1.3.0.html#popup, i.e. an HTML display container floating over the map and associated with a location marker. 
> Yes I used 'balloon' to mean what is described as 'popup' by leaflet.
> 
>> Assuming I’ve understood correctly so far, the video and map elements will be competing for the same display space, as a significant part of the map will be obscured by the video near the point of interest, which seems counterproductive.
>> Firstly, the video-related feature does not link the path co-ordinates to any timing information in the video.
> 
> I guess there are different modes in which to manage the relationship between video and map.  One is as a balloon/popup.  In that case the balloon hides some of the map, yes. But it has the advantage of pointing to a spot.  Maybe the track metadata could guide where it points to as the video/audio plays. Another is like we see in the Leaflet documentation, where a video is treated like an image overlay feature (static).  I don't know if there's any value in georeferenced track info  /metadata in that use case.  What do you think? Finally, maybe you could control the map via its api using track location information as the video/audio plays. I think this is more of a scripting use case, but you could probably figure out how to do it declaratively too.
> 
> Interesting discussion!
> 
> Thanks,
> Peter
> 
> 
> Peter Rushforth
> 
> Technology Advisor
> Canada Centre for Mapping and Earth Observation / Earth Sciences Sector
> Natural Resources Canada / Government of Canada
> mailto:peter.rushforth@canada.ca / Tel: 613-759-7915
> 
> Conseiller technique
> Centre canadien de cartographie et d’observation de la Terre / Secteur des sciences de la Terre
> Ressources naturelles Canada / Gouvernement du Canada
> mailto:peter.rushforth@canada.ca / Tél: 613-759-7915