SV_MEETING_TITLE -- 24 Oct 2018

<jtandy> Scribe: Jeremy Tandy

<jtandy> Scribenick: jtandy

Peter Rushforth presents his slides

Why do we need maps for HTML?

Peter: to lower the barriers to people wanting to write maps
... layers of standards - HTML, CSS and Javascript
... Web mapping is very popular on the Web
... examples: leaflet, openlayers
... very popular
... this demonstrates the need for maps
... but javascript?
... everything that can be written in JavaScript will be written in JavaScript
... but this is not particularly friendly for [many people]
... Looking at existing map providers - everything is siloed: apple maps, google maps etc.
... back on Leaflet - the developer of leaflet talked about simplicity taking over the Web
... SIMPLICITY WILL SAVE GIS
... the Maps4HTML CG want to [make web mapping] simple enough for everyone - not just Javascript experts

<Linda> https://www.w3.org/community/maps4html/

Peter: to keep things simple
... Maps4HTML wants to use the simplest language
... in this case, it’s HTML

[Peter talks about evolution of media types]

Peter: text, images, vector graphics, audio, video - and maps!
... each of these media types have their own HTML <element>
... we hope that the same happens with maps
... in the Maps4HTML CG we’ve created prototypes [for declarative HTML web maps]
... you can download the prototype from bower [see slides for details]

[peter shows example of a MapML document]

Peter: this example is simple, but the [user agent] presents controls to allow pan and zoom
... the notion is to allow one or layers to be added to the map model
... the key property of each layer is the source element
... the hyperlink for each layer points to MapML document
... MapML has it’s own media type
... [showing example] see here - this one uses leaflet controls
... also see the attribution control in the lower right corner
... attribution is important for open data
... so - let’s show a live demo

<Linda> Http://geogratis.gc.ca/mapml/en/cbmtile/cbmt

Peter: so we wrote a custom element that is running in these pages; downloading the leaflet and WebComponent and the Map
... you can see a map with map controls
... and you can ‘viewsource’ too
... enabling you to look at the MapML document
... MapML follows the HTML pattern - with a Head and Body section
... the <body> element has a number of <inputs> like for a Web form, and a new <tref> element
... <tref> element includes a URL template, with the template variables being supplied by the <input> forms
... the map itself is provided by a [normal] map tile server
... in this case, it’s ESRI ArcGIS
... when the user pans and zooms the map, new events are created
... the values populate the <input>
... and a query is sent to the Web map server
... to take this further
... you can drag more layers onto the map
... to start stacking map layers
... have been talking to a vendor / provider of a sophisticated Web mapping API
... am considering progressive enhancement
... where you have more sophisticated things you can do with maps
... Questions please!

TerrenceEden: this is fantastic
... very keen to help
... two questions
... (1) so if I already have a mapping App on my phone, can I use the native maps on the device?

Peter: the power of this is that I can use another mapping provider for the base map

TerrenceEden: specifically, if I have a mapping application on my phone - can I access the native mapping?

Peter: depends on the level of adoption
... would pretty simple for Google or others to support MapML [natively]
... I’ve been engaging Google - but they’re not coming very fast to this
... yesterday, a representative from Google said why don’t you license the Google Maps SDK
... which I thought was interesting

TerrenceEden: (2) if I am an existing mapping provider, is there much change required to adopt MapML?

Peter: MapML uses a similar model to, say, open street map
... this is based on OGC Simple Feature Profile
... we’re talking about vector data here
... see this new example

<Linda> http://geogratis.gc.ca/mapml/client/map-carte.html

Peter: with vector data from open street map\
... the idea is to allow vectors to be styled using CSS
... in MapML the vectors are [encoded] according to the OGC Simple Features Model
... now - if I inspect the source in this vector example
... geometries are like GeoJSON - but in markup
... I’m not hugely familiar with SVG, but you have to repeat geometries

<satakagi_> I agree that map elements that provide zooming, panning, and layering to graphics contents are good opinion. And I thought that this geospatial mapping field was important for 20 years.

<satakagi_> However, I'd like to apply such a user interface to entire graphic media with , rather than just only for the geospatial-map. Specifically, ultra high resolution graphics and technical drawings are one of the their use cases.

<satakagi_> I think that I would like to spread such a user interfaces over genericized versions of use cases other than geo.

<satakagi_> At this point, I have been confronted that the gap between geo community and web community. To me, geo community seems to want to adhere to geo exclusive data structure, system and functionality.

<satakagi_> I am interested in what people think about this about the people here.

Peter: showing the mapml document again, you see the geometries
... its not SVG
... it’s similar to GeoJSON- but in markup
... [because of the similarity] you could drag a GeoJSON object with a default transformation into MapML
... GeoJSON is pretty harsh on coordinate system choice

<satakagi_> Because I am shy :-), I will have a comment on IRC.

Peter: MapML supports a limited set of coordinate systems to make it easier to stack maps from multiple providers

[satakagi’s comments on IRC are read out]

Peter: I think the geo community and the web community are not that far apart
... and MapML is trying to bridge that gap
... between APIs for existing Web maps and mediatypes [and HTML] for the Web
... the industrial drawing use case is interesting
... [...] coordinate reference system needs to be built into the drawing
... leaflet, for example, support [CRS simple?]

<Linda> Scribe: Linda van den brink

Peter: Joan Maso - co-lead in the CG - suggested making the change to support this

<Linda> Scribenick: Linda

jtandy: about the gap between geo and web -
... geopeople have been doing mapping for ages - currently in javascript
... you said this is an impediment to other people
... this morning in the TAG session they were talking about doing domain specific languages using web components, as that allows you to keep the semantics
... easier to index, better than blobs of javascript
... mapml is another domain specific language, a declarative language
... so you have bridged the gap, because currently you have some js, packaged in a web components, so to do your demo, you don’t need javascript skills

Peter: that’s the right approach, but the path hasn’t been trodden much yet. what is the path for custom elements, web components, how do you standardise that?
... there’s still a mismatch between the communities

jtandy: we can agree that bringing maps into custom elements is a good idea. The benefit is to make it easier to do web mapping and to stack layers
... it’s more a question of doing either a custom element / extension or a native part of HTML

Peter: if it’s a native part the gap would go away. Otherwise silos will remain
... maps should be standardised

jtandy: If your spec is clearly written, anyone could make a web component.
... what is your prefered result of this breakout session?

Peter: to introduce it to people, both geo and web community
... I invite anyone here to join the Maps4HTML CM
... would also like input on questions like how to do progressive enhancement
... advise from web platform community on whether the API we’re developing is the right one

jtandy: anyone in the room able to comment on that? Who has interest in providing feedback offline?

[no answer]

jtandy: encourages everyone to talk to colleagues who might be interested and introduce them to Peter

[end]

- DRAFT -

SV_MEETING_TITLE

24 Oct 2018

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output