Introduction: Glossary of standard mapping terms about html-map-element-usecases-requirements HOT 16 OPEN

@AmeliaBR

With the addition of static maps, I believe the definition of "web map" should be changed from:

web map
An interactive map integrated into a web page.

to: "An interactive or static map integrated into a web page", while also adding a definition for "Static map".

I suppose the current definition of a Static map per the discussion would be something along the line of "a map integrated into a web page that is neither pannable nor zoomable.".

from html-map-element-usecases-requirements.

More:

• coordinates
• coordinate system
• latitude, longitude, altitude

from html-map-element-usecases-requirements.

From @cmhodgson on #82 and #92:

In my quick perusal of the "Use Cases and Requirements for Standardizing Web Maps" doc, it seems to be lacking in the definition department. To me, there should be a section near the beginning that defines terms like Map, layer, feature, image, tile, etc. so that they are clear when we use them. To me, a Map layer is a logical collection of map features or map images/tiles which are grouped together for the purposes of combined control over styling and/or display. Typically there is one "background" layer, and zero to many overlay layers. Overlay layers are either images/tiles with transparent areas to allow the background to show through, or vector feature layers that are rendered on the client.

With vector layers, the styling is separate from the data, so switching styles or color themes (eg. dark vs light) is clearly separate from switching data layers. However, with raster based layers, some systems would allow you to change the style of a layer (WMS uses &style=) but only if so configured; more commonly, the different styles are implemented as different layers. For example, changing from dark to light street maps is done using the same parameter as changing from street maps to satellite view in every mapping system I'm familiar with, Google, Bing, MapBox, etc. So I think we need to talk separately about "styleable layers" and "non-styleable layers" in some cases.

Perhaps we have some definitions in another doc? I think these terms need to be clearly defined, we can't write a meaningful spec without well defined semantics.

I really think there needs to be a definition of a map as a collection of layers, layers which can be various types, eg. tile, image, vector, which are arranged in a stack using z-order, with the lowest layer being the "base layer", and other layers being overlays... this level of abstraction prevents you from duplicating the requirements for the "map" (ie. base layer) and the "features" (ie. overlays), as they are all just layers, and therefore should be able to do all the things that layers do (turn on and off, change style, pan/zoom together, etc).

Maybe I'm too biased by my experience with existing web map tools, but they all work this way for a reason, you need to be able to group "things shown on the map" together in order to manage them because there are typically to many "things on the map" to manage them individually. Thus, the layer concept.

from html-map-element-usecases-requirements.

I'm starting to sketch out an initial glossary. Anyone have opinions on whether it should be alphabetical or ordered thematically?

from html-map-element-usecases-requirements.

I've pushed my initial set of glossary terms: https://maps4html.github.io/HTML-Map-Element-UseCases-Requirements/#intro-glossary

Feedback requested! (Especially from @cmhodgson, since you had pointed out the need for standard definitions!)

My goals for the definitions:

• accurate & consistent with accepted terminology in the geospatial community
• understandable by people who don't have a geospatial background
• not specific to any particular technology

Comment here if you think any of the definitions can be improved, or to recommend additional terms to define.

from html-map-element-usecases-requirements.

Looks great Amelia. One issue, I think the term "map" is being "overloaded" in the context of this document, and while your definition works well for the general concept, we could benefit from a more specific definition in terms of how we expect a map to function technically. You touch on this in your description of layer/base layer/overlay, but the connection between them is sort of one-way (a layer says it is part of a map, but a map is just graphical display of geography).

Maybe we need a two-part definition for map, or we need another, more specific term, for the "map component"(?) of an HTML page - which is defined as the composition of layers, controls, etc. I'm not sure how often in the document that "map" is used in the general sense, but I think it is often used in the sense of its meaning as a element in an HTML page and how that should work.

I'd also like to see some mention about layers being groups of features for purposes of control, styling, source, type, etc., not just for "rendering" which I guess kind of encompasses those details but I don't feel it is quite clear enough.

One other note is that the key to a map being "slippy" is this: when the map view is panned, the existing layers are "slid" over and the portion of them that is still within in the viewport remains visible to the user while panning. The newly revealed portions of the map are loaded dynamically and put in place without requiring a reload of the page or the map view image, often utilizing a tiled data scheme which allows for progressive loading of the map as well as caching of the tiles by the browser. Prior to slippy maps, all rendering and compositing was typically done on the server side, which required an entire new image to be created and downloaded to replace the previous map view, after any pan or other modification to the map view.

You're welcome to any of my text here in the github issues if you feel it's worth incorporating into the doc itself.

On the topic of order, of course alphabetical is traditional but ctrl-f does a better job of finding your term than searching through an alphabetical listing, so I like your sort of top-down conceptual ordering with the big concepts first and smaller technical details last.

from html-map-element-usecases-requirements.

Maybe we need a two-part definition for map, or we need another, more specific term, for the "map component"(?) of an HTML page…

The rest of the document mostly uses "map viewer"for this, it should be added to the definition list.

I'd also like to see some mention about layers being groups of features for purposes of control, styling, source, type, etc.,

Good points, I can add some more details to that definition to cover layers from a more conceptual perspective.

the key to a map being "slippy"

Interesting. I hadn't thought of the name that way. I might want to split this definition from the more general "interactive map", then, to get more into the details of the different types of interaction.

On the topic of order, … ctrl-f does a better job of finding your term

That was pretty much my conclusion, in the end. If you're looking for a specific definition, you'll either follow a link or search for it. So I went with the order that makes the most sense (I hope) if you're reading the list end-to-end.

Thanks for the review!

from html-map-element-usecases-requirements.

Following discussion in #79, I think "control" within an interactive map viewer is also something worth defining.

from html-map-element-usecases-requirements.

Note to self: link to the exhaustive OGC glossary in the section introduction, as a further reference.

from html-map-element-usecases-requirements.

Term to add: "bearing"

from html-map-element-usecases-requirements.

To do: add an entry for vector tiles, as distinct from vector feature sets.

from html-map-element-usecases-requirements.

Term to add: "Gazeteer" as typed out in the spec, or is the correct spelling Gazetteer?

from html-map-element-usecases-requirements.

Term to add: "Gazeteer" as typed out in the spec, or is the correct spelling Gazetteer?

Thanks for the catch. Definitely need to fix the spelling error. I'm not sure whether it makes sense to add it to the glossary or if we can just define it in place. Depends on whether we end up using it elsewhere in the discussion.

from html-map-element-usecases-requirements.

@AmeliaBR I wonder whether the glossary needs the term "Datum". Many end users successfully use maps without knowledge of them, but they are key to understanding many geospatial concerns, and as expecttions of accuracy increase, they becme increasingly important. A defnition along the line of: "A Datum fixes the coordinate system of a Coordinate Reference System to a real world object, usually the Earth." Examples are:

1. A mark on a rock at Newlyn, Cornwall, England used to be used for measuring altitude;
2. Longitude used to be fixed with respect to a brass marker on the ground at the Greenwich Observatory, London, England;
3. A local plan or map maybe constructed with respect to a corner of a building;
4. An image based map may have its fixed point on the imaging satellite.

If you think this too esoteric, i'm happy to leave it out, though personally I think the OGC Glossary is too geeocentric!

from html-map-element-usecases-requirements.

Interesting. I was not familiar with "datum" in that sense. So the datum object would be an essential part of a particular CRS? Maps are defined relative to those survey markers, so to convert to a global mathematical coordinate system you need to know the datum object's position in the second coordinate system.

It think it would be definitely worth at least mentioning that type of CRS — and complications arising from converting between local and global coordinate systems when the ground itself shifts over time!

Whether we need a separate glossary entry for "datum" would probably depend on whether we're actually using the term in any use case / capability discussions.

from html-map-element-usecases-requirements.

@AmeliaBR You are spot on. CRS=Coodinate System+Datum. Geospatial specialists spend quite a bit of time transforming between two coordinate systems where only the datum differs. This is needed for the high accuracy applications.

The datum may not be just a single point, but could also be a surface, such as a theoretical sphere centred at the Earth's centre-of-gravity, but putting your finger on that location or surface is problematic too!

I think mentioning tectonic shift is a good idea, and the examples of Europe and North America recedng from each other by about 2 or 3 cm per year (1 inch!) whereas Australia is galloping 30 cm (1 foot) per year northwards towards China.

from html-map-element-usecases-requirements.