Use case: search within a set of map features

[AmeliaBR]

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

[bkardell]

if the analogy is ctrl+f, does that not already have well defined behahavior? Is there a way to find something in a canvas, for example? AFAIK ctrl+f doesn't search anything that is non-visible and itself in DOM (a canvas with text, for example or a video transcript wouldn't appear)

[cmhodgson]

In a typical GIS environment, searches would specify what fields to search in and allow for logical and/or combinations of filters. Even without going to that level, they are usually done when looking at a table view of the features and their values; if such a view is made available, then ctrl+f would already work with no changes. You also need such a table view in order to sort features (you can't sort them on the map). This sort of table view implies a vector/feature level mapml layer, as opposed to an image layer, which would require a server's involvement.

[AmeliaBR]

For just finding a matching label that's already in the DOM, a Ctrl+F search would work if the label is currently being rendered in SVG or HTML text, but it might need to pan into view instead of scroll into view, so that may or may not be automatic depending on how panning works. For labels that are only displayed at certain zoom levels, it might need to build on the virtual scroller idea, to be able to search text that isn't currently being rendered and then scroll/pan/zoom to the place that will trigger its rendering. Again, the details depend on how the content and UI are modelled at a lower level. In a way, this use case is about “don't break a basic feature of web pages”.

But the idea of searching fields other than simple text labels is interesting, too. Oftentimes, information on maps is expressed by iconography with a matching legend. A Ctrl-F search would only match the label in the legend. But what you want is to find all instances of the icon in the map. So that would be a very map-specific search interface.

I was also thinking about geography-aware search, like a search for the nearest match to a certain point. But maybe that's a whole other layer of complexity.

[cmhodgson]

I would say that it is relatively rare that a map feature's label would be displayed on the map directly using the DOM/SVG. It is very difficult to prevent label collisions, so such labeling is usually done on the server side where more care can be taken with the cartography. More typically, a feature would be displayed as an icon, line, or polygon, and when moused-over or clicked on, the name and/or other details are displayed in some way. This is implemented using a spatial query, either in the client or with a round trip to the server, to find the nearest feature to the point of the click (usually within a maximum tolerance). However, in the case where the features are in the MapML layer (ie. it is a MapML vector layer and not an image-based layer), then I suppose the data in the MapML would be in the DOM - just not displayed, until clicked on. So it could be searchable within the browser, but how would you display it? The icon for the feature would already be on the map, but the actual word you searched for is in the properties of the feature, which are rarely displayed directly on the map. Thus the need for a table view, IMHO, especially since it is surely needed for sorting. Or I guess it just does the same behaviour as if you had clicked on the feature as a query, popping up the feature's properties in some kind of dialog-like sub-window?

[prushforth]

I have nothing against tables, but I do think that Ctrl-F is one of the underrated features of the Web (if only you could use regex!). Ctrl-F could certainly work with features in the MapML/HTML DOM, and the map could pan, just as the HTML document scrolls, when you go from one hit to the next.

Anyway, usually we don't want to represent everything in a map using vectors, as Chris mentioned, because the rendering is quite intensive and is usually better done ahead of time, and with specialized software and on the server. The exception to this, I believe, is for accessibility: the browser, or a JavaScript extension of the browser at the very least, can calculate valuable information for the user based on the geometry of the feature: (distance from|some other useful derivative of location) (the user's phone, the user's pointer, another (set of) feature(s) selected by the user). So, vectors need to be represented in the DOM, but judiciously due to bandwidth, processing and not overwhelming the user with a good thing considerations.

However, vector tiles are becoming important, I believe mostly due to bandwidth reasons, but importantly for mobile, they can allow the client to re-orient the labels as the map is rotated, keeping them horizontal/readable. Anyway, vector tiles haven't hit the mainstream, but one day they certainly will. And at that time, we could think about how a DOM API could be provided for the vectors in the tile, perhaps on demand, like with a Ctrl-F hit, or a click/touch/pointer event, the feature could be extracted from the tile and presented on the map, and potentially with its properties intact (I don't know too much about vector tiles, but I gather they allow features to retain properties).