Dear

FOSS4G 2016!

Let us step back for a moment and start to talk about

making geographic web maps machine readable.
 

Source Code: Leaflet.annotate, Download: v0.5

Pic: http://collections.lacma.org/node/239578

First, before i will discuss the exemplary LeafletJS plugin implementing my markup analysis advancing geographic web maps in HTML, please let me make eight points here so you get to know my perspective on this topic.

Secondly, i would like to have this talk being open and and interactive during this first part.

Thirdly, i am going to present an example along the Leaflet.annotate implementation and will be happy for detailed questions or just feedback in general.

1.

Why would we prefer loosing instead of fostering and sharing the knowledge map makers have in their head when creating and publishing geographic maps on the web?

We as free, libre and open source software (and possibly even open data) advocates should already have some answers to that question, right?

I mean, authoring of semantic markup is hard for us when we would need to do it by hand, writing HTML Elements with a pen but when we use domain specific applications like for example Carto or Mapbox it is not.

2.

Maps are not (up to my knowledge) made in a vacuum so why is the vocabulary (think of the categories behind icons or in cartographic: why are the signatures) not connected, does not reference (formal) languages other people use?

HTML is a living standard, a formal language we(TM) invented, slowly turning into a "third order hypertextsystem" (Riley) which allows us to express our own types of elements, attributes and links. Therefore we just need to implement some formalities, like for example the Microdata Syntax of Schema.rog

3.

Making maps still takes time and it often involves researching and aggregating information from various sources and types. We need to work through the details of our sources of information and then make lots of design decisions (like selecting this or highlighting that).

Why would we want to use tools which do not preserve our work, tools which do not envision our maps as long-lived and interoperable? Why wouldn't we want to enable other apps to look at our maps as an open list of distinguishable statements about things and concepts in the world?

4.

Doing research on web maps requires a degree of archiv- and reproducability. If we manage to publish important geographic web maps as machine readable, kind of self-containing documents, would make our research back in time based on maps much easier.

At least from in 10 years on, or so.
So, my agenda for these geographic web maps in 2025 is, lets make a significant percentate of our most important geographic web maps machine readable and thus searchable, interoperable and reproducible.

5.

Looking at web maps as compositions (systematic selection of information or otherwise independent resources) is, at least in a german or european copyright understanding of copyright, a creation on its own. In this sense a geographical web map is not much different of a dj's setlist.

But the document format we as web mappers use to exchange or publish geographical web maps clearly does not reflect this circumstance.

6.

The identification of traces certain geodata leaves through our web maps and how it evolves is currently not comprehensible. At least not easily for non-programming hackers as visitors and recipients of the geographical web maps we publish.

Map makers most probably always know where they have the geodata from, they just often do not share or include information on this in their maps. But such metadata is definitely (see research literature on "critical cartography") vital for visitors and all readers of a map.

7.

A geographic web map can containing semantic statemets becomes easily translatable. If its referenceing a vocab like wikidata the map even becomes multilingual without any further work, or so to say, by default. Which label the city of Berlin gets in the visualization is then to be determined by the users preference or browser.

Of course, interchangable/selectable at runtime too.

I often like to think that simply providing Options will make some users just about aware that there might be even other, potentially different representations of the very same information available and valid as well.

Wrapping things up.

Advanced accessibility of mapped information through having an alternate textual representation, following well defined standards as well as open and public vocabularies available implicitly within the document.

Contrast a very specific visual representation of statements about the world with search-, filter-, sort-, skimmable textual statements.

If not multilinguality by default, easily translatable.

You can check out the Source Code. We just build the first release (v0.5) and your feedback is very welcome.

Please download, give it to your users and help us to, by 2025, publish all important maps annotate and machine readable :)

Thank you for stopping by and reading!

PS:

And of course, let's realize this in OpenLayers3, too!

I therefore filed Issue 4972 but i am prertty sure we need some follow up tickets to reach that.

Cheers!