Country Code filter on NSI website

[boothym]

I was looking to see which fitness centre brands had already been added for the UK, so I looked at https://nsi.guide/index.html?k=leisure&v=fitness_centre and typed "GB" into the Country Code box.

My expectation of the Country Code filter box is that it would show all brands which which were available to use for that country in iD. However, it didn't show those brands with a LocationSet of 001 - meaning a number of worldwide brands in use in the UK were not shown.

I think either the functionality of the CC box should be changed or there should be a checkbox which gives the option of also including all brands with a 001 locationset.

[bhousel]

Yes, good catch, I still need to update the nsi.guide site to handle the region codes.

[peternewman]

I was going to have a little go at this, but it's more complicated than just cc=cc or cc=001, given a locationSet can include anything here: https://github.com/osmlab/name-suggestion-index/blob/main/CONTRIBUTING.md#locationset

Plus if e.g. #4256/#4257 go in ideally you want to be able to enter a location and see if it's really in a locationSet so is Italy in Southern Europe etc.

It looks like this should do it: https://github.com/ideditor/country-coder#isIn , but I guess that needs to be run on each element of the set.

[kjonosm]

When filtering you should also prevent custom codes to populate different country lists, see e.g. WMATA Metrorail for a US network not present in Germany.

[peternewman]

When filtering you should also prevent custom codes to populate different country lists, see e.g. WMATA Metrorail for a US network not present in Germany.

Ah you're talking about matching a full entry only. Perhaps it wants an exact checkbox? Personally being able to e.g. see the ones using any local geojson: https://nsi.guide/index.html?t=transit&k=route&v=bus&cc=.geojson

Or localised to part of the UK: https://nsi.guide/index.html?t=transit&k=route&v=subway&cc=gb-

Seems quite handy to me.

It also shouldn't highlight the "de" of "include" in that search!

Also via the URL I can enter gb- or gb-sct but not via the form on the webpage: https://nsi.guide/index.html?t=transit&k=route&v=subway&cc=gb-

[michaelblyons]

The geojson files were recently sorted into country-code folders. If the path in the JSON were relative to the old root (us/foo.geojson), it would just work, right?

[peternewman]

Not in this case @michaelblyons . It's matching giant_de_md_va.geojson, in this case the de is Delaware. You could make it match ^de, but then you'd have to know what your sub-region is prefixed with (in the case of my gb-sct) or the random way a geojson is named. It would also stop my search for all the geojson's.

[jnicho02]

I know that it is more complicated than just including 001....but wouldn't it just be a quick win to do so, and raise the complications as a further refinement later? Just saying.

[mnalis]

in https://github.com/osmlab/name-suggestion-index/issues/5180#issuecomment-1642228904, @bhousel wrote:

Yeah, I'm playing around with nsi.guide toady and thinking of ways to improve the country code search field. I'd need to index all the geometries in order to search them properly, but that might be doable without too much trouble.

Have you perhaps come to conclusion how hard that would be?

Actually being able to see e.g. brands/operators for some amenity for one's country would be very useful, and current solution (which silently ignores worldwide and other entries) is quite misleading and confusing to end users (as evidenced by number of comments and duplicate tickets)

[bhousel]

Have you perhaps come to conclusion how hard that would be?

Actually being able to see e.g. brands/operators for some amenity for one's country would be very useful, and current solution (which silently ignores worldwide and other entries) is quite misleading and confusing to end users (as evidenced by number of comments and duplicate tickets)

It's kind of a solved problem because I do it in Rapid and iD, but I'd need to copy that code over to the nsi.guide site and there would be a second or two added to the startup time.

[mnalis]

It's kind of a solved problem because I do it in Rapid and iD, but I'd need to copy that code over to the nsi.guide site and there would be a second or two added to the startup time.

That is great news that is should not be much work; I think it would really help users!

Optimization idea: perhaps that "second or two of initial startup time" could be delayed until the first time user tries to filter by country? That way, users who are not interested in country filtering would not bear the penalty (and those who do, would certainly prefer the country filtering to actually work, even if first click was slightly slower)