maps4html / html-map-element-usecases-requirements Goto Github PK

This issue is for discussion of the reference tool "D3 Geographies APIs".

D3 is a popular API for manipulating custom maps. It doesn't provide a built-in "viewer", but it could be relevant when talking about data formats & APIs.

D3-geo docs

We are on our second full iteration of (something like) this process, give or take the WHATWG involvement. It may be worthwhile adding them to this pass.

Another idea that has come up in the recent discussions about process is an early TAG review. Maybe we should include that in our current efforts.

Maybe we should pay them to contribute, that might be the shortest path to success.

This issue is for discussion of the use case “Access additional information about a point on the map”, its examples & list of required capabilities.

GIS commonly has the ability to "identify" features as you click on them. This is also built into the img@ismap functionality, which is a bit out of date now and due for an update :-).

This issue is for discussion of the use case “Reposition or scale a map to find more context for the displayed locations”, its examples & list of required capabilities.

This is the most basic user-focused use case: the website author has displayed a map of a certain area, but the user wants to pan or zoom.

I am including in the same use case all the accessibility requirements. I think it's important that we don't talk about "panning and zooming with the keyboard" as a separate feature/requirement from "panning and zooming with the mouse (or touch gestures)". One should never be implemented without the other.

Maps4HTML/MapML#36

This issue is for discussion of the reference tool "TomTom Maps SDK for Web".

Does this align closer to with @NickFitz is doing with the API services?

Links:

• Documentation for their Map API product (e.g., HTTP formats for raster & vector tile servers)
• Documentation for the TomTom Maps SDK for Web (the JS library)
• Tutorial for displaying basic map

This issue is for discussion of the use case “Customize the color scheme (light/dark or high contrast)”, its examples & list of required capabilities.

This is a user-focused use case: the ability to see the map in their preferred color scheme, maybe with the map tiles selected automatically based on their browser preferences.

The review aims to be empirical, arguing that certain patterns should be standardized because they are already commonly used in the web.

Which means, we need data on the frequency of use of the different JS tools.
https://trends.builtwith.com/mapping/ has numbers, but no methodology. @briankardell was going to try to get some numbers from HTTP archive searches, but any other sources would be a help.

Relevant section: https://maps4html.github.io/HTML-Map-Element-UseCases-Requirements/#js-examples

I'd like to include pages of working demos to show how the various reference JS map widgets can (or can't) be used to address the different use cases, and to explore the details of their particular capabilities (e.g., the accessibility of their interfaces). The example page for “Display a specific location on a map” shows the start of the idea.

Problem: Many of the mapping libraries require an API key linked to a credit card, even if they allow some usage for free.

Options:

• only include free products in the examples
• ask organizations involved in the community group to donate API keys

Note: I don't expect the actual page view counts on the examples to ever get very high. We could probably cap usage of most or all the APIs to their free tiers without worrying about hitting the limits. But, the links would still break eventually if no one renews the accounts they are associated with.

This issue is for discussion of the use case “Display a specific location on an interactive map”, its examples & list of required capabilities.

This is currently the first use case listed, because I think it is the simplest/most common use case on the web.

The report is currently organized by use cases, with capabilities (technological features that could potentially be requirements) listed as subsections of each use case:

• use case A
  • capability 1
  • capability 2
• use case B
  • capability 3

Of course, many of the basic low-level capabilities will affect many use cases, but I guess I assumed that we could organize the use cases in a logical order, so each new capability builds on what comes before.

In discussions about the report with @bkardell (Brian Kardell), he mentioned:

Maybe one way to handle this would be to list features in the fashion you have and then have a separate section that discusses the breakdowns in a way that they can refer back to which things they solve so that it is more graph than tree?

The more I think about it, the more I agree. Trying to associate each capability with a single use case does a disservice. I'm leaning towards re-arranging to have a list of use cases followed by a list of capabilities, and then within each of those sections have a set of cross references

• Use Cases
  • use case A
    • requires capabilities 1,2
  • use case B
    • requires capabilities 1,3
• Capabilities
  • capability 1
    • used by use cases A, B
  • capability 2
    • used by use case A
  • capability 3
    • used by use case B

Before I make the edits, does anyone else have any thoughts or alternative suggestions?

This issue is for discussion of the map viewer capability "Reproject map tile data into a new projection or globe view".

Globes work around some of the limitations of planar map projections, by portraying spatial information on a rendered spheroid. This technique is becoming commonplace, and serves Web mapping quite well in that it allows specific areas of the Earth to be portrayed without necessarily developing custom projections for them, especially polar areas.

Furthermore, globes are an appropriate abstraction for rendering and perhaps more importantly, analysis of global phenomena such as climate change. As such it would be excellent to enable globes as a "projection" within the proposed solution(s).

This issue is for discussion of the map viewer capability "Apply custom styling to map markers and vector features".

It's important that map authors be able to share the standards of the Web, without necessary extensions and pre-processors. The CSS model of styling should be used for styling map content.

This issue is for discussion of the map viewer use case “Display map coverages or other custom tile data”, its examples & list of required capabilities.

I've combined these two use cases — data coverages and custom tiles, including aerial/satellite imagery — because they are technologically equivalent; the required capabilities are the same.

But maybe it would be helpful to separate them out for the examples?

When talking about coverages separate from custom tiles, though, the examples will often cross into the multiple layers use case. So maybe the data coverage examples can be part of that use case, and this one can focus on custom imagery or coverages that have been server-rendered onto a base map?

This issue is for discussion of the reference tool "Mapbox GL JS API and Mapbox Studio embed".

Mapbox, in addition to providing map tiles, have lots of APIs for building applications with them.

Examples and API reference for the MapBox JS framework

This issue is discussing an aspect of the new Use Cases and Requirements for Web Mapping (which is a great initiative and hopefully something that can be collaboratively developed by the Web standards and Web mapping standards communities. Those who show up write the standards!).

I have been thinking about whether having a default map provider should be part of the use cases / requirements. Video is a pretty close analogy to maps in many ways. I'm concerned that it will end up being a bit like having a browser-default video provider: not something that most users would want, but certainly something a browser vendor with a video service would like to have. This was also a question at TPAC last year.

Default map provider is something which certain web components already do (as noted), and that is a standard at a level that I don't believe is where maps should be standardized i.e they bury / don't provide the URL. I think having maps which support URLs for content retrieval goes a long way to obviating the need for having a default map provider (see Manual and/or Automated Map Creation and Layers - Add Using Standard URLs slightly below that).

It's incumbent on us (the mapping / map provider community) to make it easy to find target(s) for those URLs, which we're currently trying to do by getting support for MapML built into as many existing map servers as possible. If OpenStreetMap (say, to pick a non-commercial example, but not wanting to limit examples to non-commercial services, could also be open data/government providers) was to support MapML instead of iframe embeds, then they could provide valid MapML document so their maps would be available for embedding at a source URL.

In sum, I believe that instead of requiring (or even allowing!) default map provider, we should require URLs for maps / map content. Thanks for sharing your thoughts!

This issue is for discussion of the map viewer use case “Display custom web content describing map features”, its examples & list of required capabilities.

This section is currently a placeholder. It may be worth splitting it in two: one for pop-up/tooltip annotations, and one for annotations (legends, data figures, ???) displayed directly in the map layer. Or we can consider this one use case, but multiple capabilities/technological approaches to fulfill it.

There is some overlap with #2, although I'm still not quite certain about how to frame that idea.

This issue is for discussion of the reference tool "Bing Maps embeds and Bing Maps Control API".

I included Bing maps in my initial list in the interest of fairness, as a counterpart against Google. It doesn't look like they have many unique features, but that's kind of the point: these are the standard, expected features of a web map widget.

I'd also thought that it used the same map tile servers as the native Windows Maps app, but I'm no longer certain that's the case. The feature data is probably shared, but the map tiles are different, and may be generated on the client for the app.

There are perhaps many possible models of feature geometry that could be adopted, but if we go by the HTML Design Princples, we should pave the cowpaths / not re-invent the wheel etc. etc.

To that end, I suggest that we leverage (to the extent possible and practical) the most successful OGC standard, that of the Simple Features. This standard is broadly and deeply implemented in mapping software, standards and formats, for example shapefiles, GeoJSON, KML, PostGIS and many many others.

Having a sound theoretical and practical base for the Web is important.

The current introduction only has a short summary of the history & state of web maps. I didn't want to go too deep into the theory & practice of cartography on the web. But, as I write out the use cases & capabilities, I realize that I can't avoid some jargon. So I'm planning to add a glossary.

Anyone have good references for web dev-friendly definitions of web mapping terms?

Initial list of terms

• map
• slippy map
• map layer
• feature
• coverage
• polygon and polyline
• projection
• GIS
• WMS, WMTS, WMFS, etc.

This issue is for general discussions of the "Client-side Mapping API Capabilities".

This issue is for discussion of the reference tool "Google Maps embeds and Google Maps Platform API".

Google hasn't joined this CG, so I don't think its wise to use their api as an example of anything, good or bad regarding maps. It would be great to have their contributions, but I've tried to avoid presuming that they want to contribute. I have invited them on many occasions; so many that their not being present can only mean that they don't want to participate.

I guess the same goes for other things like blogs that I may have mentioned elsewhere, which I will fix.

This issue is for discussion of the map viewer capability "Toggle whether default controls are displayed".

Using the <video> element as an example, the browser renderer is capable of rendering video content on demand of the author using something as simple as

<video controls width="250">

    <source src="/media/examples/flower.webm"
            type="video/webm">

    <source src="/media/examples/flower.mp4"
            type="video/mp4">

    Sorry, your browser doesn't support embedded videos.
</video>

The video player rendered by that has default controls, styled according to the particular browser implementation. Yet, and I am not an expert, but I believe you can shut the controls off (by omitting the controls attribute) and provide your own controls (if you wish) which respond to events (handled by script).

Maps should follow a similar approach: if you don't want default controls, don't ask for them. Then, use events emitted by the map 'player' to bind your own self-created controls to the map, with script.

This issue is for discussion of the use case “Bookmark a location”, its examples & list of required capabilities.

This is a placeholder. There will likely be a couple related user-focused use cases for exporting or extracting map data. I'm not sure how much we want to combine them versus call them out individually. Examples:

• bookmark a view/location so you can come back to it the next time you visit the webpage
• export a location (e.g., marker point) for use in another mapping app (e.g., to get directions)
• save an image of the current map view
• print the current map view

This is not really an issue, but if you're watching issues on this repo then this is relevant to your interests!

I'm Amelia, the current editor of the Use Cases and Requirements for Standardizing Web Maps report.

I'd like to get this report complete & polished. But I haven't been able to put as many hours in as I'd like, given the scope & complexity of “maps on the web”!

Therefore, I'm looking to hire one or more part-time contributors to help with the research, writing, and code. My work is paid for under a contract with Natural Resources Canada's Geomatics group, under the supervision of @prushforth. But to be clear: you'd be contracting to me, not NRCan.

Job description below. Leave a comment on this issue if you have any general questions that would be of interest to other applicants. If you have specific questions, or to apply, please send me an email directly, to [email protected]

Tasks

These are the tasks I need help with. You do not have to be able to do all of them, we can delegate different tasks to different people based on skills & time available.

• Draft text summarizing the various use cases & capabilities. Think of new ones.

• Create example pages showing how the reference JS tools can be used to meet the various use cases in the report.

• Summarize the support level & limitations of each of tool's implementation of each capability.

• Compile information about related web standards & how they are similar to / different from the web mapping use cases.

• Discuss potential conclusions for each section, in particular how the different technological capabilities intersect with the various guiding principles for web standards.

• Respond to and help organize issue reports.

• Complete the pre-processing scripts to generate support tables and summaries of conclusions from the tagged markup in each section.

Other tasks may arise over the course of the contract.

Expected skills & aptitudes

• Able to communicate in basic written English. Don't worry if you're not perfectly fluent; other people can edit the text if you can contribute the information.

• Able to work without supervision & manage your own time, but also able to recognize when to ask for help or consult with colleagues.

• Good attention to detail & able to make organized notes.

• Able to break down complex problems into independent concepts, and to identify shared building blocks across different applications.

• Familiar with semantic HTML (enough to write the report in HTML markup).

• Familiar with git & GitHub (enough to make logical commits, use branches and PRs, and work with issues).

• Familiar with front-end JavaScript (enough to work with the reference JS tools & maybe help with the report pre-processing script).

Additional skills that are strong assets

• Previous experience with web map tools & frameworks.

• Familiarity with geographic data servers (GIS) and map data formats.

• Experience with web accessibility testing.

• Experience with web standards processes, web platform testing, or web browser teams.

Terms of the contract

• All work for this project is on an on-demand basis, subject to agreement by both parties (myself as the purchaser & you as the contractor) on individual tasks. An agreement to complete a task will include an agreement on its deadlines and the maximum hours that should be billed (both of which can be changed by later agreement).

• There is no guarantee about how much work will be required. The contractor hired does not need to guarantee availability. Both sides agree to notify the other as soon as possible if there is a change in the expected work requirements or work availability.

• The work will be invoiced on an hourly basis, at a rate of 95 CAD (Canadian dollars) per hour.

• Invoices should be sent monthly, by the 5th day of the month for the previous month's work, and will be paid (by electronic transfer method to be determined based on the contractor's country & preferences) within 45 days.

• The contractor agrees to keep records of time spent on each task & to provide them to the purchaser & to Natural Resources Canada if requested.

• The contractor must be able to join the Maps for HTML community group and agree to the W3C Community Contributor License Agreement (CLA) as an individual, or as a representative of a group that does not prohibit this type of freelance contracting.

• The contractor must have or be able to create a GitHub account.

• The contractor will submit work via GitHub issues and pull requests where appropriate, or by email otherwise. Discussion of the work will happen by these methods or by teleconference/video conference as needed.

• All intellectual property created under the contract will belong to Natural Resources Canada (NRCan), but with the understanding that it will be contributed to the Maps for HTML community group or other web standards groups, under the terms of the Open Government Licence - Canada. The contractor agrees to keep copies of all their work & to submit it as requested, according to the IP conditions on the NRCan contract.

• Other general conditions apply to the purchaser's contract with Natural Resources Canada; the contractor in this sub-contract must agree to meet those requirements where applicable. Specifically, please mention in your application if any of these situations apply:

  • You are a resident or citizen of a country against which Canada has economic sanctions. Note: most of those sanctions only apply to military contracts, but we'll need to follow up and make sure there are no problems.
  • You are a non-Canadian in Canada; you'll need a work visa or a student visa that allows part-time contract work.
  • You are a former Canadian public servant who is receiving a pension or who received a severance payment.

Say we have a map, for which we provide a feature drawing API. The canvas on which that drawing occurs should be on the client, but it should be 'recoverable' as marked up features or even just plain GeoJSON, via a client API. To me, this suggests something like the following as a way to request user input:

<input type="location" subtype="point" (for example)>

Such an input would generate content on the map canvas with the assistance of the user. It might or might not be submitted, but the content could be recovered as georeferenced feature geometry content at least, perhaps via an API call on the map canvas, and perhaps also as an event from the input when user input was completed.

This issue is for discussion of the reference tool "OpenLayers API".

overview and docs

Another reference example that can be as complicated as you make it, but also has very simple examples that will be used as the basis for the reference.

Pictures are worth a thousand words, but they're also very useful for breaking up thousands of words & grabbing attention. And this report is going to have a lot of words…

I've started building example pages with working examples of the reference tools. I don't want to embed all those examples in the main page, because of the web performance hit (and the cost, depending on how we handle #24 ). But maybe we could add some screenshot figures from each? And then continue to link to the live examples on a separate page.

This issue is for discussion of the reference tool "OpenStreetMap embeds".

OpenStreetMap allows you to create iframe embeds from their website using the Share → HTML option or by generating the URL.

I don't think they have any other direct API for web developers, although their data and generated tiles are of course integrated in many other APIs. But I'm not an expert, and their help pages are more focused on contributing to the project than on extracting data from it!

This issue is for discussion of the API capability "Create, initialise, and display a map".

This issue is for discussion of the use case “Show/hide layers of map tile data or features”, its examples & list of required capabilities.

This is an end-user use case, focusing on the interactivity. In contrast, #11 focuses on the ability of authors to present a composite map from different layer sources.

This issue is for discussion of the map viewer capability (potential requirement) “Display a basic map without JavaScript”.

From the 2015 use cases report's list of limitations of current tools:

Reliance on script
All of the above Web map techniques depend on JavaScript, and so Web maps, considered as a feature of the Web, require a scripted environment to even exist. JavaScript on the Web embodies the 'code-on-demand' optional constraint of the Web. Thus a feature such as Web maps depends on an optional feature of the Web itself. When the option is not available or fails, the Web itself fails, or does not possess this feature. The fact that a sophisticated, not to say important, feature such as Web maps can be enabled by virtue of an optional feature of the Web is however, a testament to the magical qualities of the Web. Nevertheless, dependence on this facet of the Web has lead to a situation where there are no inherent map semantics in HTML, or on the Web.

Turning this around, a capability of a web map viewer is its ability to provide at least basic function when JS is disabled or fails for other reasons.

This issue is for discussion of the reference tool "MapKit JS (Apple Maps) API".

overview page and docs. The docs leave something to be desired, but the basics are all there.

The report uses ReSpec, plus some custom scripts, to enhance the source HTML file into the final content.

The benefit of ReSpec is that the raw document is still a functional HTML file, but most of the repetitive code is automated.

The downside is that every time you load the report, it takes a few seconds to get ready. The longer the report gets, with more features like auto-embedding GitHub issues, the slower the start up becomes.

One option is to use two branches on GitHub: source code on a master branch, and then a gh-pages branch which has the final processed HTML file generated by ReSpec. This is what the ARIA specs do, using Travis CI to update the gh-pages branch every time a commit is made to master. E.g., this is the config for SVG AAM. It may also be possible now to do this with GitHub Actions.

This issue is for discussion of the reference tool "Leaflet.js API".

overview and docs

Placeholder for discussing issues about Leaflet as an example in the review. One issue with leaflet is that it is very open-ended. I'm planning to focus on the simplest examples / capabilities that you get out of the box.

The MapML link here is broken.

@bkardell fixed link, thanks.

This is a stub. I add it because of the suggestion to rename this repository, which I would support (seems straightforward to do, although we would need to find links that point here and update them).

In any case, we need to talk about what the fallback scenarios and recommended approach will be for future web maps in HTML, no matter what the name(s) of the elements. Enhancing existing semantics seems like the right approach. I think <picture> may have demonstrated some good markup design / fallback behaviour worth copying/ using as a pattern.

This issue is for discussion of the map viewer use case “Mashup multiple layers of map tile data or features in a map”, its examples & list of required capabilities.

The ability to add and remove layers to yhe map is a fundamental use case, common to most Web map libraries. OTOH, most map libraries don't use URLs to refer to layers, because there is no commonly understood layer representation.

"""but its basic functionality (to define geometric areas on an image that represent distinct hyperlinks) has not evolved to include what users today consider a standard web map (such as those provided by Google, Bing, or OpenStreetMap"""

Minor prose nit probably but this reads on further reading like it has a slightly oddly specific turn.. would it make sense to say something more specifically about capability evolution more broadly here? Like.. Defining geometric links over a single image was the common generalized use case and sort of state of things. Today, many of the things that provided those generalized use cases: maps (all kinds, not just strictly geo coord), technical drawings, diagrams, charting and so, on all now include many additional common modern features like the ability to pan and zoom and somehow progressively load and layer these relationships?

It should be possible to geo-reference HTML content at an appropriate scale without the need to display a map on the page, and following the principle of least power.

Let's say you wanted to describe a statue in a park, but you didn't want to include a visual map, just the location of the statue and a picture of it. You could encode the location of enclosed HTML content like so:

<map zoom=17 lat=45.397778 lon=-75.705278>
  <h2>The Man With Two Hats</h2>
  <img src="http://www.veterans.gc.ca/images/remembrance/memorials/national-inventory-canadian-memorials/mem/35059-173a.jpg" alt="Statue">
  <p>Unveiled on 11 May 2002, this monument pays tribute to the crucial role played by Canadian soldiers in the liberation of the Netherlands during the Second World War.</p>
  <p>The Ottawa Man with Two Hats monument is a replica of the statue found in the Dutch city of Apeldoorn named De man met de twee hoeden. The twin statues exemplify the strong ties between the Netherlands and Canada. The friendship that bonds the two countries grew during the Second World War, when Canadian soldiers played an important role in the Liberation of the Netherlands.</p>
  <p>The bronze monument, a gift to Canada from the Netherlands, was created by Dutch artist Henk Visch. The 4.6 meter structure was unveiled by Her Royal Highness Princess Margriet of the Netherlands in Ottawa in May 2002. The Princess had also dedicated the original Apeldoorn statue two years earlier in May 2000, during the 55th Anniversary of the Liberation of the Netherlands, in front of a large group of Canadian Veterans.</p>
</map>

The above content is highly geolocated, not only due to its coordinates, but also due to the zoom level. As such, the map bounds in the real world would give the map content an extent that could be indexed. The centre point of the map (@lat @lon) itself could be used as (point feature) in a visual/map-based 'summary' of the content. In this way, HTML documents can themselves be visualized on a map if necessary, for example as search results.

On the other hand, it should also be possible to geo-reference HTML/SVG as visible map content, by embedding that content in <layer> content, either inline or by URL reference. This latter idea is perhaps it's own (separate) use case.

If we're proposing a markup-based map widget, it would be nice to have examples of existing tools that use an element and attribute API for embedding and customizing maps.

There is of course the community group's own custom element proposal, but it's circular logic to use it as an example!

I've found a few custom elements that are wrappers for the various major maps APIs, but not sure which ones would make a good reference:

• official Google google-map component; looks like it was comprehensive (child elements for markers & so on) but the demos are all broken
• simpler good-map that uses Google
• leaflet-map, another basic map
• mapbox-gl looks fairly comprehensive

This issue is for discussion of the use case “Display a region of map data as a static image”, its examples & list of required capabilities.

Ironically, sometimes an HTML author wants to provide a simple static map that provides some other mappiness (a pushpin or two, for example). It would be good to be able to 'freeze' a map at a location, perhaps using a CSS property, or possibly, though not preferably, an attribute. Being a map, it would still be "georeferenced" for crawlers' sake only, perhaps. But it could use back-end services like WMS or tile caches to provide visual and non-visual semantic context.

HTML-Map-Element-UseCases-Requirements is a very long name, and makes all URLs to the spec or to issues very long. It's also not entirely accurate, since the report is about use cases/requirements in an abstract sense, not about a <map> element (which is only one possible proposal for implementing the requirements).

But… renaming a repository is a bit of a pain. GitHub handles redirects for the repository itself, but we'd need to create dummy files in the website repo with meta-tag redirects for the actual report.

So, it might not be worth it at this point. But I thought I'd bring it up for discussion.

This issue is for discussion of the map viewer capability "Display map tiles defined in various common coordinate systems".

This is related to #3. While Web Mercator is a widely used projection, it is recognised as a very low-quality CRS because of the poorly chosen parameters It would be ideal to permit (some) different projections, so as to at least have the chance of getting participation in this initiative from government mapping authorities. Where the profusion of different map projections reduces interoperability, we should be able to support a globe as the base perspective, perhaps.

It seems to me that globes and planar projections are two 'rendering modes'. When the perspective is that of globe, coordinates have to be transformed onto the sphere and then rendered; when viewing a planar projection map, the coordinates are rendered using a simpler transformation.

Not sure if this is a use case, but use cases arise from it, e.g. mashups require the data to share coordinate systems, either beforehand or by client processing. The latter gets into performance issues and is why GIS is going to remain important.

This issue is for discussion of the use case “Display drawings or schematics without geographic coordinates”, its examples & list of required capabilities.

Per discussions with @satakagi at TPAC, an important level of progressive enhancement of the <map> element could be "deep zooming" of non-georeferenced technical drawings, such as schematics of microprocessors etc.

Recently the "WGS84" projection in MapML was extended to support tile resolutions at different zoom levels. Is this projection adequate for this use case?

This issue is for discussion of the use case “Display multiple point locations on a single map”, its examples & list of required capabilities.

This use case is currently just a placeholder (a heading in the draft, but no text). I'm not 100% sure it's necessary. An alternative is to merge it in to the single location case (#33) or the use case involving more complex vector features.

If we're going to keep it as its own use case, it's probably worth describing it in a way that involves different marker symbols (which are more important when you have more than one marker).

The original design of the Web and perhaps still its core strength, is to permit, but not require, federation of resources via links (the <a href> element, mostly but def not exclusively).

Similarly, maps should allow links between map providers who choose to link to one another. Such links should enable a variety of use cases, ranging from opening another web site to popup/sidebar content, to completely replacing the current map provider in the map and layer control with a new map provider. Such links should be customizable but recognizable in their affordance-ness. Similar to how you can style <a href> but the blue text is often associated.

Maybe we should enable <a href> in maps, which would re-use existing coded logic, perhaps.

This issue is for discussion of the use case “Search or sort within a set of geographic features”, its examples & list of required capabilities.

I'm including this as an end-user use case, although it's of course of benefit to authors if they don't have to implement their own search function! But, I'm specifically thinking of searching within the map data available on the client, like a Ctrl+F word search of an HTML document. Sending a search query to the server would be separate

This issue is for discussion of the map viewer use case “Display routes/paths or regions”, its examples & list of required capabilities.

This section is currently just a placeholder. But it generally refers to polyline/polygon features. See also #34 about map marker features, and #20, which is focused on features from the perspective of the underlying data structures.