Add Search Control

[AliyanH]

Experimental Feature
Allows users to search for remote content, if the map is provided with a layer which is searchable.
Current Logic, Hybrid implementation of the OpenSearch format and <map-extent>:

<layer-label="Search Layer"checked> // Regular <layer-> element
<map-extentunits="CBMTILE"> // Regular <map-extent> element
<map-inputname="s"type="search"></map-input> // new `type` (search) for <map-input><map-linkrel="search"tref="https://geogratis.gc.ca/mapml/en/cbmtile/{s}/"></map-link> // new `rel` (search) for <map-link> which allows this map-link to be used as the search link, which expects mapml data
<map-linkrel="searchSuggestion"query="place_id"desc="display_name"tref="https://nominatim.openstreetmap.org/search.php?q={s}&format=jsonv2"></map-link> /* new `rel` (searchSuggestion) for <map-link> which allows this map-link to be used as the suggestion link to suggest results,
this link, helps populate a datalist which is displayed as users are searching.
The expected object for from this link is a JSON, which requires 2 json properties which map to the 'query' and 'desc' attributes.
'query' attribute contains the property which will be used to fill in the searchbox
'desc' attributes contains the property which will provide a readable label/description for the layer
`query` and `desc` can be provided the same property.*/
</map-extent></layer->

• Search control is only displayed when a searchable layer is present.
• Update/Finalize Logic
• Make Search control look pretty
• tests, web-map, etc...

try searching for : 'onshore', 'kNN_Genus_Pseu', etc. (from the geogratis site) on this branch to see how the searchbar functions.

[prushforth]

This looks interesting! I would not hide the search box behind a hover icon, I would put a big texty hard-to-miss text entry up a the top of the map, like this one: https://www.openstreetmap.org/ maybe to the right of the zoom control or top dead center.

Some noodling:

Using <map-extent> is a really interesting choice. A <map-extent> is meant to be able to include variables that can reference the key extremities of the viewport (e.g. top-left etc). The result is meant to be a component of a map layer, i.e. a layer can have > 1 <map-extent>. So having a searchable map extent makes sense on the one hand, but we also currently expect the content of a <map-extent> (tiles, features) to fetch / update /render as the map moves (as long as it's mapml content, at least). How does this relate to search results?? We need to think about that. Does the search re-run many times as the map moves?

Right now your code Knows that what is returned is a <mapml-> document. We would have to generalize it to support features and geojson etc. In general I like the idea of integrating search with <map-extent>, good initiative. Just want to ensure it's unobtrusive and pretty simple to manage for users, accessible etc.

I would make it <link rel=suggestions> , and support the use of application/json in response. Not sure what the ideal format of the json is, but, tbd.

[prushforth]

I think you need to associate the search suggestion link to the search link. I think you should consider that there could be multiple map-link rel=search links, so they need to be associated unambiguously, perhaps using the for attribute. I think the query and desc attributes are a good way to provide the format metadata; but maybe they need to be namespaced to the rel=search in some way : data-query, data-desc (data- is a "userland" prefix to allow custom attributes, not 100% certain it's the right thing here, because they're not intended to be custom attributes, but standard ones); maybe search- would work tbd)