<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]
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) WARNING: No "Present: ... " found! You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy <amy> Present+ Found Scribe: Jeremy Tandy Found ScribeNick: jtandy Found Scribe: Linda van den brink Found ScribeNick: Linda Scribes: Jeremy Tandy, Linda van den brink ScribeNicks: jtandy, Linda WARNING: No "Topic:" lines found. WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]