SearchBox enhancements

[zbycz]

Few ideas - each one should be one PR

Features

• add coordinates search – parse all coordinate types + plus codes (Add support for Open Location Codes? #834)
• add search history -> if I searched for San Francisco, it should be offered to me
• when coordinates are out of BBox, show an arrow like this
• allow users to share search -> add search term to URL after 2 seconds eg /?q=op:node["shop"] #119

Fixes:

• fix matching presets by name – searching for building p should offer Building Part on the first place (SearchBox: Change to the Dice-Sørensen coefficient #605)

Explorations

• find what is practical limit for overpass query size, eg if user asks for op:nwr, it can freeze their browser.

Completed

• fix broken flyTo on mobile – search for anything with bbox, eg Bexhill-on-Sea - it can't be clicked (SearchBox: Fix broken flyTo on mobile #574)
• filter through favourites points while typing (SearchBox: Refactoring and searchable stars #552)
• add type osmId – parse shortId, apiId or URL with some of these ids. (SearchBox: Add support for openstreetmap ids #587)

[Dlurak]

fix broken flyTo on mobile – search for anything with bbox, eg Bexhill-on-Sea - it can't be clicked

On my iOS device it works, but only with a double click.

[amenk]

allow users to share search -> add search term to URL after 2 seconds eg /?q=op:node["shop"]

depends on #119

add type coordinates – parse all coordinate types

see also #510

[Dlurak]

How about also adding types to the options?
Even though it's internal, I believe this would greatly simplify future enhancements to the search box and make it easier to maintain!

[zbycz]

 How about also adding types to the options?

@Dlurak – yes, please! There is a TODO in code already, though we would need to completely refactor the types. Typescript can't discriminate among the different options based on our current shape. It need explicit type field with enum

// from
{
  star: { ... }
}
// to
{
  type: "star",    // enum "star" | "geocoder" | "preset" | "overpass" | "coordinates" | "osmId" | "loader"
  ...
}

I will review your #552 today, and then you can add the types. If you decided to do that, please, create one PR only for the refactoring, and second PR (based on first) with the additional types with adding new functionality. Otherwise the code review is a headache 😃

//edit @Dlurak - wow, I am reviewing the #552 and I am very pleasantly surprised! You already added the type: "x" all by yourself! Good job!!

[Dlurak]

How about also adding search support for the name suggestion index. While the tagging presets have real categories like supermarket or school the name suggestion index has companies, like supermarket companies...

https://nsi.guide/

[zbycz]

Interesting idea. 👍 One issue is that the nsi.json is 11 MB alone, so it is too big to load it the same way we load presets. We needed presets anyway for displaying the feature types and showing the FeaturePanel, so even though preset.json is 0.6 MB, it is an exception.

The way we could execute this is implementing our own /api endpoint. The server can load the file from node_modules and look up the info - we should test how many miliseconds it takes, if it is too much (>50ms?), we would need to load it in postgre first.

Also the UI would have to be rethinked a little, because firing two requests could result in jumpy UI, or even worse displaying nothing when one of the request fails.