forked from Maps4HTML/HTML-Map-Element-UseCases-Requirements
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
6037 lines (5601 loc) · 223 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset='utf-8'>
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Use Cases and Requirements for Standardizing Web Maps</title>
<style>
h5:not(.specificity-hack) {
margin-top: 2rem;
margin-bottom: 1rem;
}
a:empty::before {
content: attr(href);
}
[data-ucr-role="tag-dfn"]::after {
content: " (" attr(id) ")";
font-weight: normal;
font-style: italic;
margin-right: 0.3em;
}
dfn {
font-weight: bold;
font-style: inherit;
}
.tag-span {
display: inline-block;
font-style: normal;
font-weight: bold;
line-height: 1;
padding: 0.3em 0.5em;
border-radius: 0.5em;
background-color: #ccc;
}
.tag-span.tag-bad {
background-color: #f86;
}
.tag-span.tag-caution {
background-color: #ff8;
}
.tag-span.tag-good {
background-color: #8fa;
}
/* cancel out the fancy link styling on links
that will contain solid-colored tags */
.processed a[href][data-ucr-role='tag'],
.processed a[href][data-ucr-role='conclusion'] {
border-bottom: none;
background: none;
}
/* add link styling on the tags instead */
a[href] .tag-span {
color: black;
}
a[href]:hover .tag-span, a[href]:focus .tag-span {
text-decoration: underline;
}
.issue .discussion {
font-style: italic
}
.issue.discussion[data-number]::after {
content: " (#" attr(data-number) ")";
/* applies if ReSpec JS doesn't run */
}
[id^="use-case-"] figure img {
border-radius: 2px;
height: auto;
max-width: 100%;
margin: auto;
margin-bottom: .5rem;
}
.figno::after {
content: ":";
}
</style>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle: "",
// if you wish the publication date to be other than the last modification, set this
// publishDate: "1999-12-31",
copyrightStart: "2019",
github: "https://github.com/Maps4HTML/HTML-Map-Element-UseCases-Requirements",
// if there a publicly available Editor's Draft, this is the link
// (calculated automatically for GitHub pages)
// edDraftURI: "https://maps4html.org/HTML-Map-Element-UseCases-Requirements/",
// editors, add as many as you like
// only "name" is required
editors: [
{
name: "Amelia Bellamy-Royds",
mailto: "[email protected]"
}
],
authors: [
{
name: "Amelia Bellamy-Royds"
},
{
name: "Nic Chan"
},
{
name: "Nick Fitzsimons"
},
{
name: "Peter Rushforth"
},
],
// name of the WG
wg: "Maps For HTML Community Group",
// URI of the public WG page
wgURI: "https://www.w3.org/community/maps4html/",
// name (without the @w3c.org) of the public mailing to which comments are due
// wgPublicList: "public-maps4html", // don't use default comment request
xref: false,
localBiblio: {
"MapML" : {
title: "Map Markup Language",
href: "https://maps4html.github.io/MapML/spec/",
publisher: "Maps for HTML Community Group"
},
"HTML-map-element" : {
title: "The HTML map Element proposal",
href: "https://maps4html.github.io/HTML-Map-Element/spec/",
publisher: "Maps for HTML Community Group"
},
"webcomponents-design-guidelines" : {
title: "Guidelines for creating web platform compatible components",
href: "https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/",
publisher: "W3C TAG"
},
"WGS84" : {
title: "World Geodetic System 1984",
href: "http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf",
publisher: "US National Imagery and Mapping Agency"
},
"FAST" : {
title: "Framework for Accessible Specification of Technologies",
href: "https://w3c.github.io/apa/fast/",
publisher: "W3C Accessible Platform Architectures Working Group (APA WG)"
}
}
};
respecConfig.otherLinks = [
{
key: 'Join the Community Group',
data: [{value: respecConfig.wg, href: respecConfig.wgURI}]
}
]
</script>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
defer class='remove'></script>
</head>
<body>
<section id='abstract'>
<p>
This report outlines the use cases and requirements
for standardizing modern Web maps,
in a way that works
for map content authors, webpage authors, and website users.
The use cases and requirements were gathered in
consultation with the Maps for HTML Community Group and others.
</p>
<p>
Three aspects of web maps are reviewed:
map viewer widgets,
client-side mapping APIs,
and
map data formats.
For each, evidence is gathered from widely-used scripted JavaScript web map frameworks.
The common features and limitations of the current techniques
are the basis of the requirements for a standardized solution
that could be built in to HTML and web browsers.
</section>
<section id='sotd'>
<p>
Comments, corrections, and suggested additions should be made as
<a href="https://github.com/Maps4HTML/HTML-Map-Element-UseCases-Requirements/issues/">GitHub issues</a>.
If that is not possible, send an email comment to
<a href="mailto:[email protected]">[email protected]</a>.
</p>
</section>
<section id="introduction">
<h2>Introduction</h2>
<section id="intro-web-maps">
<h3>The current state of web maps</h3>
<p>
Web maps today are indispensable to billions of people,
for exploring and understanding the world around them.
Like paper maps before them,
web maps are used for planning, wayfinding, analysis, and more.
But the power of an interactive, hyperlinked medium
supports a richer experience than could have been imagined
by a cartographer from a previous century.
Online maps can be dynamically redrawn with new data,
or according to the user's preferences.
They can connect to other maps —
for adjacent areas, finer detail, or different geographical features —
and can link out to complex information about the places they represent.
</p>
<p>
But despite their ubiquity on the web,
maps have no native, semantic representation in HTML.
</p>
<p>
HTML has had “image maps” —
hyperlinked graphics, where selecting different parts of the graphic triggers a different URL —
<a href="https://tools.ietf.org/html/rfc1866#section-7.6">from its early days</a>.
These were quickly adopted to
<a href="https://web.archive.org/web/20110628194820/http://www2.parc.com/istl/projects/www94/mapviewer.html">represent simple cartographic maps</a>.
The <a href="https://html.spec.whatwg.org/multipage/image-maps.html#the-map-element"><code><MAP></code></a> element
sounds like it should be the basis of a web map,
but its basic functionality
(to define geometric areas on an image that represent distinct hyperlinks)
has not evolved to include many capabilities
that users today expect when interacting with maps on the web,
such as the ability to dynamically change the map view.
</p>
<p>
Web mapping technology has undergone a <a href="https://en.wikipedia.org/wiki/Web_mapping#History_of_web_mapping">long period of evolution.</a>
Today's web maps are usually sophisticated client-server applications,
dynamically combining many types of spatial data on demand for web users.
Implementations vary widely,
but some of the underlying techniques, software, semantics and formats have become
accepted patterns
(for example, <a href="https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames">the tile naming systems</a>),
or formal standards
(for example, the <a href="https://www.opengeospatial.org/standards">standards published by the Open Geospatial Consortium</a>,
some of which are also ISO standards).
</p>
<p>
Many sources of spatial data are available online,
from governments, commercial services, and non-profit projects.
But accessing and using the data is a specialized task;
most web developers or website content creators
rely on JavaScript frameworks
(or sometimes still Flash frameworks)
that can fetch the correct map image tiles or vector data,
draw them to the screen,
and handle the most common user interactions.
</p>
<p>
Many of these web map frameworks are tied to a specific commercial provider of map data,
making it difficult for website creators to integrate their own data,
or data from multiple sources.
Many of the web map frameworks do not work at all without JavaScript,
and require considerable resource downloads and processing.
The end user has limited control or customization over the map interface —
unless the website author happened to choose the web map provider
that matches the native mapping application on the end-user's device.
</p>
<p>
Web maps today may not be perfect,
but they have filled a clear need for website authors and users.
The multiple frameworks used to generate web maps
implement the same capabilities with different code —
code that needs to be downloaded and processed for each website with a map in it.
These core aspects of Web maps represent mature, ubiquitous user interface (UI)
and application programming interface (API) patterns.
It is now reasonable to consider standardizing these capabilities
for implementation by web browsers directly.
</p>
<p>
A key challenge is to do so in a way that is
compatible with the core values of the open web,
and integrated with other web platform technologies.
</p>
</section>
<section id="intro-maps4html-cg">
<h3>The Maps for HTML Community Group</h3>
<p>
The Maps For HTML Community Group (<a href="https://www.w3.org/community/maps4html/">Maps4HTML</a>)
arose as a result of face-to-face
<a href="https://www.w3.org/community/maps4html/wiki/LGD14BarCampNotes">discussions</a>
at the Linking Geospatial Data workshop 2014,
co-sponsored by the W3C and the Open Geospatial Consortium.
</p>
<p>
The group operates within the structure of a W3C community group,
with clear license terms for contributions of intellectual property.
The community group process
designed to support the eventual transition of the group's work to become open web standards.
The group attempts to follow the established best practices for web standard development,
as outlined in <a href="#principles">the guiding principles</a> for this report.
</p>
<p>
The initial requirements sketched out at LGD2014
were expanded into <a href="draft-2015.html">an initial use cases and requirements summary</a>.
That work was the basis of the draft [[[MapML]]] specification
and [[[HTML-map-element]]] proposal.
Although MapML has had notable support and development efforts
from within the geospatial community,
as of early 2019 it has not received significant support
from web browser developers or HTML standards teams.
For that reason, the current document rolls back the focus
to the discussion of mapping use cases and requirements.
The structure of this report is intended to more comprehensively explain
<em>why</em> native HTML web maps would be beneficial,
and <em>how</em> they should best be defined.
</p>
<div class="ednote">
<p>
This report is a work in progress!
Feedback and contributions are welcome.
Most sections of the report include links to a discussion issue on GitHub.
Use those issues to suggest corrections, additions,
or changes to the conclusions.
To suggest a new section (e.g., a new use case),
please start a new issue.
</p>
<p>
To make substantive contributions
(that is, anything that is bigger than typo corrections or formatting fixes),
you will need to first
<a href="https://www.w3.org/community/maps4html/">become a member of the community group</a>
and make the corresponding IP commitments.
</p>
</div>
</section>
<section id="intro-report-structure">
<h3>Structure of this report</h3>
<p>
The purpose of this report is to describe
(1) why and how the open web would benefit from having
web map features built in to web browsers,
and (2) what this native web mapping function should look like,
to website creators and to end users.
</p>
<p>
This report uses an empirical approach to identify required features of web maps,
by looking for the common features of web map frameworks used today.
However, we also recognize that web maps today have limitations.
A proposal for a native HTML web map, built in to web browsers,
needs to be assessed on the same merits as any other proposed web standard.
</p>
<p>
In <a href="#principles"></a>,
we outline the theoretical factors we use
for assessing whether a given feature should be included as a requirement.
</p>
<p>
In <a href="#use-cases"></a>,
we outline common goals for people interacting with web maps.
The use cases are defined in pragmatic terms,
describing a specific function or action.
Real-world, domain-specific applications of the use case
are summarized in an introductory description.
The use cases are divided according to whether they apply to
<a href="#content-author-use-cases">content creators</a>,
<a href="#visitor-use-cases">website visitors</a>,
or <a href="#application-use-cases">web application developers</a>.
(Of course, there is overlap between the audiences —
good developers want to create good user experiences!)
</p>
<p>
In <a href="#js-examples"></a>,
we introduce the web map frameworks that are used in the empirical review.
</p>
<p>
The review of potential requirements
is then divided into three parts:
</p>
<ul>
<li>
<a href="#map-viewers"></a>,
including the user interface
and all configuration that could be defined declaratively
in elements, attributes, and style properties.
</li>
<li>
<a href="#client-apis"></a>,
which would require additional DOM APIs
to enhance or complement the declarative elements.
</li>
<li>
<a href="#map-formats"></a>
that should be supported for representing spatial data
used by the map viewers.
</li>
</ul>
<p>
For each category, we list technological <dfn data-lt="capability">capabilities</dfn>:
features, which a web map might include, that could help solve the use cases.
Capabilities are potential requirements for a native HTML web map.
To assess whether the capability should be a requirement, we examine:
</p>
<dl>
<dt>Existing implementations</dt>
<dd>
How common is this capability in the reviewed JS web map frameworks?
Do they implement it with consistent, well-established patterns?
Are there any notable limitations of the current implementations,
when measured against the <a href="#principles">principles of the inclusive web</a>?
</dd>
<dt>Supported use cases</dt>
<dt>
Which use cases are enabled by this capability?
</dt>
<dt>Uses beyond mapping</dt>
<dd>
Is there a demand for this capability on the web,
beyond its use in web mapping?
</dd>
<dt>Related web specifications</dt>
<dd>
How is this capability related to existing web standards
or proposed specifications?
Can the web map implementation build on existing features?
</dd>
</dl>
<p>
For each capability, we conclude by summarizing its costs and potential benefits
(using tags defined in the next section)
for integration as a native HTML web map feature.
We assign it one of three possible conclusions:
</p>
<dl>
<dt><dfn id="requirement" data-ucr-role="conclusion-dfn" data-ucr-tag-type="good">requirement</dfn></dt>
<dd>
The capability is essential for a native HTML web map implementation.
</dd>
<dt><dfn id="enhancement" data-ucr-role="conclusion-dfn" data-ucr-tag-type="caution">enhancement</dfn></dt>
<dd>
The capability would be nice to have in native HTML web maps,
but isn't necessary for the initial specification.
</dd>
<dt><dfn id="impractical" data-ucr-role="conclusion-dfn" data-ucr-tag-type="bad">impractical</dfn></dt>
<dd>
The capability isn't currently realistic for inclusion in native HTML web maps.
</dd>
</dl>
<p>
If there is not yet enough evidence for a conclusion,
the capability will be marked
<dfn id="undecided" data-ucr-role="conclusion-dfn">undecided</dfn>.
</p>
</section>
<section id="intro-glossary">
<h3>Glossary of key terms</h3>
<p>
Web mapping and geospatial data have a rich vocabulary
that is not always clear to outsiders.
This report uses the following terms in the ways defined here,
unless another meaning is clearly specified:
</p>
<dl>
<dt><dfn>map</dfn></dt>
<dd>
A graphical representation of the features of and spatial relationships between places.
Unless otherwise specified,
maps referred to in this report are assumed to be <a>geographic maps</a>
with a two-dimensional representation.
</dd>
<dt><dfn>geographic map</dfn></dt>
<dd>
A map of part (or all) of the surface of Earth (or another planet),
with a defined mathematical relationship between
positions on the map and geographical positions on the planet.
</dd>
<dt><dfn>non-geographic map</dfn></dt>
<dd>
A map in which positions on the graphic are not defined
relative to positions on the Earth's surface.
</dd>
<dt><dfn>interactive map</dfn></dt>
<dt><dfn>slippy map</dfn></dt>
<dd>
A map rendered as part of an interactive computer application,
such that the user of the app can manipulate aspects of the map display.
In particular, a slippy map is one in which
the user can pan the displayed map to view a different region.
</dd>
<dt><dfn>web map</dfn></dt>
<dd>
An interactive map integrated into a web page.
</dd>
<dt><dfn data-lt="GIS|geographic information system">geographic information system (GIS)</dfn></dt>
<dd>
A database system for managing geographic data (or other spatial data),
often including software for displaying the data as interactive maps.
</dd>
<dt><dfn>map server</dfn></dt>
<dd>
An internet-connected GIS,
that provides processed geographic data or map images
on request from client software (such as web browsers).
Map servers used by web maps are normally built on HTTP,
but many formats are used for search requests and data responses.
Some of these are described by formal standards,
others are defined only by the documentation of a particular map server.
</dd>
<dt><dfn data-lt="OWS|OGC Web Services|Open Geospatial Consortium Web Services">OGC Web Services (OWS)</dfn></dt>
<dd>
A set of <a href="https://www.opengeospatial.org/standards/">standards developed by the Open Geospatial Consortium (OGC)</a>
that define communication protocols between map servers and client software.
OWS standard define a format for exposing the available capabilities of the map server,
and for structuring requests for map data for a certain region,
possibly restricted by other search parameters.
The format of the returned map data is defined separately.
OWS standards include:
<ul>
<li><dfn data-lt="Web Map Service|WMS">Web Map Service (WMS)</dfn>,
for accessing a custom processed map image
that directly represents the requested region and query parameters</li>
<li><dfn data-lt="Web Map Tile Service|WMTS">Web Map Tile Service (WMTS)</dfn>,
for accessing pre-processed map <a>tiles</a>,
which may only represent a <a>layer</a> of the final map</li>
<li><dfn data-lt="Web Feature Service|WFS">Web Feature Service (WFS)</dfn>,
for accessing <a>vector feature</a> data</li>
<li><dfn data-lt="Web Coverage Service|WCS">Web Coverage Service (WCS)</dfn>,
for accessing raw <a>coverage</a> data</li>
<li><dfn>OWS Context</dfn>,
for returning metadata with references to other map services</li>
</ul>
</dd>
<dt><dfn>(map) projection</dfn></dt>
<dd>
A method of converting positions on the surface of a sphere (the Earth)
into positions in a 2D rendering (display screen or paper map).
All map projections involve some distortion of the data,
but different projections are preferred for different use cases.
<em>TODO: Figure comparing common map projections</em>
</dd>
<dt><dfn>coordinates</dfn></dt>
<dt><dfn>coordinate pair</dfn> or <dfn>coordinate triple</dfn></dt>
<dd>
A mathematical description of a particular location,
on a map (<dfn>map coordinates</dfn>)
or in reality (<dfn>geographic coordinates</dfn>).
Coordinates are generally defined as a pair or triple of measurements,
depending on whether the location they defining is in two dimensions
(e.g., a location on the surface of the Earth or position on a map)
or three dimensions.
</dd>
<dt><dfn data-lt="CRS|coordinate reference system">coordinate reference system (CRS)</dfn></dt>
<dd>
A standard way of defining map or geographic coordinates,
so that locations can be precisely compared or aligned
between different maps, map layers, or spatial data sets.
Some CRS are based on geographic coordinates,
while others are based on map coordinates
and therefore incorporate a map projection into their calculation.
</dd>
<dt><dfn>latitude</dfn> and <dfn>longitude</dfn></dt>
<dd>
Coordinate system for describing positions on the surface of the Earth.
Latitude values represent North-South distance from the equator.
Longitude values represent East-West distance from a reference line
(the prime meridian) that connects the poles.
Both values are angles, usually degrees.
Latitude and longitude are used in multiple <a>coordinate reference systems</a>;
the exact CRS needs to be specified to define a location precisely.
<em>TODO: Figure of latitude/longitude</em>
</dd>
<dt><dfn>altitude</dfn></dt>
<dd>
A coordinate that represents the height of a point above or below a reference surface.
A <a>coordinate reference system</a> that uses altitude along with latitude and longitude can define geographic points in 3D space.
Altitude is measured in length units, such as meters or feet.
</dd>
<dt><dfn>feature</dfn></dt>
<dd>
Something of interest on the map.
Conceptually, the map feature includes the location or geographic shape
of this spatial thing, as well as additional information
describing what it is or why it is interesting.
This information may be conveyed on the map with text labels
or with icons, colors, or other cartographic symbols.
</dd>
<dt><dfn data-lt="vector|vector feature">vector feature</dfn></dt>
<dd>
A map feature that has a mathematically defined spatial geometry
based on coordinate data.
Different spatial data structures support different types of vector geometry,
but the basic 2D vector feature types are
<a>point</a>, <a>polyline</a>, and <a>polygon</a>.
<em>TODO: Figure of different types of feature geometries (point, multipoint, polyline, etc.)</em>
</dd>
<dt><dfn>coordinate point</dfn></dt>
<dt><dfn data-lt="point|point feature">point feature</dfn></dt>
<dd>
A spatial location defined by a single set (pair or triple) of coordinates.
A point has no shape or extent,
although in some data formats it may include a level of imprecision or uncertainty.
</dd>
<dt><dfn>polyline</dfn></dt>
<dd>
A vector feature defined as an ordered list of coordinate points,
and the straight lines connecting them.
(Where "straight" is relative to the geometry being described,
and might be across the surface of a sphere.)
</dd>
<dt><dfn>polygon</dfn></dt>
<dd>
A vector feature defined as a two-dimensional shape enclosed by a polyline,
where the last point on the polyline connects back to the first one.
In some data formats, a polygon includes a shape with holes (exclusions) in it,
where the hole is defined by a separate enclosed polyline.
</dd>
<dt><dfn>coverage</dfn></dt>
<dd>
Spatial data that conceptually represents a measurable value that varies across space.
In practice, coverage data is usually encoded as a grid of points
at a specified resolution, with the data value at each point.
This grid of values can often be represented as pixel colors in a <a>raster map layer</a>.
</dd>
<dt><dfn data-lt="layer|map layer">(map) layer</dfn></dt>
<dd>
A subset of the map's graphics which could be rendered independently
from other graphics for the same region.
Multiple map layers can be aligned based on their shared <a>coordinates</a>,
then composited together (drawn one on top of another) to create the final map view.
</dd>
<dt><dfn>base layer</dfn></dt>
<dd>
The map layer that provides the background/bottom layer in the compositing stack.
It is usually fully opaque.
</dd>
<dt><dfn>overlay</dfn></dt>
<dd>
A partially-transparent <a>map layer</a>,
designed to be positioned on top of a <a>base layer</a>.
</dd>
<dt><dfn data-lt="vector map|vector map layer">vector map layer</dfn></dt>
<dd>
A map layer defined using data structures that describe individual <a>vector features</a>
and their coordinates,
which is then used as input instructions to drawing code in the map rendering tool.
Vector formats can preserve the meaning of the different graphical marks on their page,
and allow them to by dynamically styled or altered by the map rendering software.
But, that flexibility requires more processing power in the rendering software,
and may require more data to represent very detailed graphics.
</dd>
<dt><dfn data-lt="raster|raster map|raster layer|raster map layer">raster map layer</dfn></dt>
<dd>
A map layer defined using raster image formats,
which specify the final colors at each position (pixel) in the rendered result.
Raster maps can be generated from vector data,
or they may be created from photographs or drawings.
</dd>
<dt><dfn data-lt="tile|tiled">tile</dfn></dt>
<dd>
A subset of a map layer that represents a particular region of the map,
usually a rectangle in a particular map projection.
Larger regions of the map can be drawn by rendering multiple tiles
side-by-side in a grid.
In a <a>slippy map</a>, tiles can be fetched from a server and rendered as needed
when the user moves the view to different parts of the map.
Tiles can be <a>raster</a> or <a>vector</a>,
although raster tiles are currently more common for web maps.
</dd>
<dt><dfn>tileset</dfn></dt>
<dd>
A set of map tiles which can be used as a map layer.
In simplest tilesets, the map tiles combine as a grid (<dfn>tile matrix</dfn>) to form a single map layer.
More complex tilesets include multiple tile matrices covering the same regions at different scales (zoom levels).
<em>TODO: Create/find figure explaining tileset pyramids.</em>
</dd>
</dl>
</section>
</section>
<section id="principles">
<h2>Guiding Principles</h2>
<p>
The structure of this review is inspired by many other projects
that have outlined best practices for web standards developments.
This section briefly outlines the principles behind our approach,
with links to further reading.
</p>
<section id="extensible-web">
<h3>The extensible web</h3>
<p>
The report uses an evidence-based approach,
defining requirements not based on hypothetical use cases
but on web map tools that are already in use.
We assume that
the common features of existing, widely-used web map frameworks
represent core functionality
that web users and website authors expect from native web maps.
</p>
<p>
This approach is inspired by [[[EXTENSIBLE]]]
which aims to
“tighten the feedback loop between the editors of web standards and web developers,”
establishing “a clear path for good ideas by web developers to become part of the infrastructure of the web”
[[EXTENSIBLE]].
</p>
<p>
Much of the manifesto focuses on making it easier
for developers to experiment with new features —
to expose web platform capabilities at a more granular level,
so that developers can remix and extend them to try out new ideas.
HTML custom elements and CSS custom properties
are just two of many examples of how web standards efforts since 2012
have focused on creating better building blocks for web developers.
</p>
<p>
But the implicit second step of the extensible web approach
is that, once a consensus has developed from real-world experience
with particular features or patterns on the web,
those features can be standardized with confidence.
</p>
<p>
Web maps are extremely complex user interfaces.
If that complexity is to be built-in to web browsers,
the extensible web mindset requires that it be exposed
to developers as individual capabilities that can be remixed and extended.
For that reason,
this review breaks web map functionality
into very low-level capabilities.
In addition to describing how each capability is used in mapping,
we discuss how the same building block could be used for other web content.
Focusing on these low-level capabilities also ensures
that we do not overlook important details,
such as the need to make individual interactions accessible to all users.
</p>
</section>
<section id="priorities">
<h3>Priorities for web standards</h3>
<p>
To decide whether a capability
should or shouldn't be considered a requirement for web maps,
we need to assess its benefits and costs.
But benefits and costs are subjective:
to calculate them, we need a set of values or principles
defining best practices for web standards.
Only then can we assess whether integrating a feature into web browsers
can bring the web closer to our ideals.
</p>
<p>
Benefits and costs are also different from different perspectives.
Integrating web maps into HTML means convincing
other web standard editors and web browser developers.
But once a web standard is adopted,
the number of website authors who use it will (hopefully)
be much larger than the number of people who worked on the initial standard;
the number of people who use those websites will be larger still.
The [[[html-design-principles]]]
rely on these numbers to establish a “priority of constituencies”:
</p>
<blockquote>
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
…
Of course, it is preferred to make things better for multiple constituencies at once.
[[html-design-principles]]
</blockquote>
<p>
This section introduces the categories by which we measure
costs and benefits to each of these constituencies.
</p>
<section id="principles-users">
<h4>Users</h4>
<p>
An inclusive web is available to everyone,
to connect and create in the ways most comfortable to them.
</p>
<p>
In this report,
the user-friendliness of a potential web map feature is assessed on these points:
</p>
<dl>
<dt>privacy & security</dt>
<dd>
<p>
Can this feature be implemented in a privacy-respecting manner?
Are there any other security concerns from this feature?
Would making it a built-in feature, standardized in web browsers,
improve privacy & security compared to current web practice?
</p>
<p>
Tags for the costs and benefits of potential requirements:
</p>
<ul>
<li>
<dfn id="privacy-potential"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Privacy: potential improvement</dfn>
indicates that a built-in browser implementation of this feature,
if done correctly,
could improve the protection of the end user's privacy,
compared to current practices on the web.
</li>
<li>
<dfn id="privacy-potential-origin"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Privacy: potential improvement for website origin isolation</dfn>
indicates that a built-in browser implementation of this capability,
if done correctly,
could make it easier for website authors to use web maps
without exposing confidential (user or corporate) data to third parties.
</li>
<li>
<dfn id="security-potential"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Security: potential improvement</dfn>
indicates that a built-in browser implementation of this capability,
if done correctly,
could improve the protection of the security of the browser environment, compared to current practices.
</li>
<li>
<dfn id="privacy-personal-data"
data-ucr-role="tag-dfn"
data-ucr-tag-type="caution">Privacy: involves personal data</dfn>
indicates that in order to fully implement this capability,
the browser would have access to sensitive or personally-identifying data about the user,
which would need to be protected.
</li>
<li>
<dfn id="privacy-fingerprinting"
data-ucr-role="tag-dfn"
data-ucr-tag-type="bad">Privacy: possible fingerprinting</dfn>
indicates that implementing this capability
would expose to website code user settings or data from device sensors,
which could make it easier for website trackers to generate a unique “fingerprint”
for identifying that user across many sites.
</li>
<li>
<dfn id="privacy-sensitive-data-revealed"
data-ucr-role="tag-dfn"
data-ucr-tag-type="bad">Privacy: reveals sensitive data</dfn>
indicates that fully implementing this capability
requires revealing sensitive or personally-identifying data to website code.
</li>
<li>
<dfn id="security-ui"
data-ucr-role="tag-dfn"
data-ucr-tag-type="bad">Security: user interface override</dfn>
indicates that this capability allows website code to alter the normal browser UI
in a way that could be used by a malicious code to mislead users.
</li>
<li>
<dfn id="security-risks"
data-ucr-role="tag-dfn"
data-ucr-tag-type="bad">Security: other risks</dfn>
indicates that this capability includes other aspects
that could make a secure implementation difficult.
</li>
</ul>
<p>
Further information:
</p>
<ul>
<li>
<a href="https://w3ctag.github.io/security-questionnaire/">W3C TAG's Security and Privacy Self-Review Questionnaire</a>
[[security-privacy-questionnaire]]
</li>
<li>
[[[GEOLOCATION-PRIVACY]]] [[GEOLOCATION-PRIVACY]]
</li>
</ul>
</dd>
<dt>accessibility</dt>
<dd>
<p>
Does including this capability in a web map standard
make it easier to ensure an accessible experience
(assuming an accessibility-focused browser implementation)?
</p>
<p>
Related tags:
</p>
<ul>
<li>
<dfn id="accessibility-potential"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Accessibility: potential improvement</dfn>
indicates that a built-in browser implementation of this feature,
if done correctly,
could improve the accessibility compared to current practices on the web.
</li>
<li>
<dfn id="accessibility-info-needed"
data-ucr-role="tag-dfn"
data-ucr-tag-type="caution">Accessibility: research needed</dfn>
indicates that there is not a clear best practice
for how to implement this capability accessibly.
</li>
<li>
<dfn id="accessibility-author-context"
data-ucr-role="tag-dfn"
data-ucr-tag-type="caution">Accessibility: needs author-provided context</dfn>
indicates that a good browser implementation is not enough
to make this capability fully accessible;
content author would always need to provide extra information
(e.g., alternative text or captions).
</li>
</ul>
<p>Further information:</p>
<ul>
<li>
[[[FAST]]]
and its
<a data-cite="FAST/checklist.html">checklist</a>
[[FAST]]
</li>
<li>
<a href="https://www.w3.org/TR/WCAG/">Web Content Accessibility Guidelines</a>
[[WCAG21]]
</li>
<li>
<a href="https://www.w3.org/WAI/standards-guidelines/atag/">Authoring Tool Accessibility Guidelines</a>
[[ATAG20]]
</li>
<li>
<a href="https://www.w3.org/WAI/standards-guidelines/uaag/">User Agent Accessibility Guidelines</a>
[[UAAG20]]
</li>
<li>
<a href="https://www.w3.org/WAI/RD/wiki/Accessible_Maps">Accessible Maps</a>,
a wiki page compiled by members of the Research and Development Working Group of the W3C Web Accessibility Initiative (WAI) focusing on non-visual map presentations
</li>
<li>
[[[media-accessibility-reqs]]],
particularly the system requirements about interactive controls and navigation
[[media-accessibility-reqs]]
</li>
<li>
<a href="https://www.w3.org/WAI/personalization/">WAI's personalization overview</a>,
and in particular the [[[personalization-semantics-requirements-1.0]]]
[[personalization-semantics-requirements-1.0]]
</li>
</ul>
</dd>
<dt>internationalization & localization</dt>
<dd>
<p>
Can this feature be implemented in a manner that works for all languages and regions?
Does building it into the browser increase the likelihood that internationalization is done correctly?
</p>
<p>
Related tags:
</p>
<ul>
<li>
<dfn id="i18n-potential-text"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Internationalization: potential improvement (languages)</dfn>
indicates that a native browser implementation,
if done correctly,
could improve the handling of text in many languages,
compared to current practices in web maps.
</li>
<li>
<dfn id="i18n-potential-geo"
data-ucr-role="tag-dfn"
data-ucr-tag-type="good">Internationalization: potential improvement (spatial data)</dfn>
indicates that a native browser implementation,
if done correctly,