RE: Seeking report/summary from Linking Geospatial Data workshop

Hi Arthur,

> Hi All - if the "report" from the Linking Geospatial Data workshop is
> available, I would appreciate it if someone would please send me the
> resource. Regardless, if there are other summaries, comments, etc.
> available, I would also appreciate the link(s) to those.

Unfortunately, the notes I took were not posted to the LGD 14 Day 2 summary; I may have submitted them too late.

I include them below.  I intend to post them to a wiki page for the group once a wiki is made available (request in the queue).

Cheers,
Peter
<notes>
Bar Camp notes for #lgd14 #maps4html discussion and summary:

* Concept of a (new) <map> element for html

* acknowledged that <map> already exists in html, but does not have the appropriate meaning.
* With the introduction of Web Components, it should be possible to prototype a <geo-map> custom element implemented in js which supports the target functionality.  Such a prototype could be eventually standardized as (for example) <m> or <geomap> actual html element.
* primary use case is to allow html authors to create simple mashups without resort to proprietary APIs and/or javascript
* Syntax would have to be simple so that markup complexity would not be a barrier to use.   For example, inspired by the audio, video (and other) html elements:

e.g. <geomap id="aMap" width="250" height="250" cenx="..." ceny="...">
            <source src="http://maps.example.org/foo/barcamp" type="application/map;..."/>
            <source src="http://another.example.org/bar/foocamp" type="application/map;..."/>
        </geomap>

Clients (browsers) would not be required to understand specific services (i.e. no URL construction required), only the media type with embedded links.

* The media type referenced by the source@type attribute would need to be a custom hypermedia type for maps and would incorporate lessons learned from HTML, Atom , KML, GeoJSON, GML and others.
* Map 'furniture' (i.e. pan/zoom/scalebar etc) could be provided by the client, and could be a point of distinction / differentiation between implementations.
* State transitions specific to maps could be represented by link relations i.e. east, west, north, south, northeast, northwest, southeast, southwest, zoomin, zoomout, zoomto (etc)
* because of the declarative nature, web pages with <geomap> linking to geospatial data and/or maps could be crawled by search engines and other agents, allowing geolocation of web pages/ geosearch.
* The experience / history of KML was discussed briefly, and it was noted that KML integrates presentation and content and that this was perhaps not an optimal solution.  CSS or "CSS Lite" (uncertain of reference) was mentioned as a desirable technology to apply to the problem of map feature styling, due to its compatibility with mainstream Web technology.
* Regarding the choice of JSON or XML as the base encoding for the proposed media type, it was acknowledged that JSON is ascendant, however it was also pointed out / postulated that the DOM underlies many of the modern APIs presented by the browser to javascript programmers, and so perhaps MicroXML (namespaceless, UTF-8 XML, more akin to modern HTML than to XML) was a suitable candidate encoding.  
* Discussion of issues of Cross Origin Resource Sharing.  Further discussion required.
* Browsers could provide APIs for javascript programmatic access to features for operations such as identify.
* URI fragment scheme defined by the media type could be used on the client side.
* To be further discussed on email, if the discussion participants create a W3C Community Group "#maps4html".
</notes>

Received on Thursday, 27 March 2014 13:53:46 UTC