POI returned as both type 'Food' and type 'Pizza'

[codergrl]

I filtered the data to only show Bar or Pub and it seems the only data we have is in Central America. That doesn't seem right, could we look at the data? Is there a definition query on it maybe? And if that is what the data shows, then should we remove that category altogether?

@mikewilburn do you have access to the Android version of the app? Can we look at that and see what it's using and if this category shows a different result.

[codergrl]

Now I'm quite confused. See screenshots below please.

There's a brewpub in Portland that falls under the Bar or Pub category that shows up on the map with the correct symbol.

If I go to the Filters and remove the Food filter...

The pub changes into a pizza place.

And no, there aren't two Silver Dollar Pizza features on top of each other. It's just one, and it changes category based on the filters selected.

I'm not familiar with the data so maybe there are some conditional filters running in the background?

[odoe]

I see the same thing in this area. I think the POI data must have it listed multiple times. One time I searched for it and it was Type: Brewpub, second time it was Type: Pizza. So I think it's a data issue. I don't know why limiting to only Bar or Pub returns results in South America, regardless of where I'm searching from.

I think I should remove it, since it behaves oddly.

[mikewilburn]

I'm even finding that when filtering out Bar or Pub, "Silver Dollar Pizza" (with the bar icon) still shows up in the list.

[mikewilburn]

There are lots of oddities going on with the filtering. For instance, filtering only for food still causes coffee shops to show up.

I think we might want to try to understand this behavior as opposed to simply removing categories. It's not only with bars and pubs.

Note: this is the map display even after the below filtering has been applied.

[odoe]

Here is how I check the types. https://github.com/ArcGIS/nearby-javascript/blob/master/src/utils/iconType.ts

It's based on the Type attribute of the returned result. The Geocode service does not provide the category that was asked for in the result, you get the sub-categeory name in the Type field, so it's a bit of a guessing game in many cases. If I ask for food, but the location also falls under bar, it will still get the Bar icon. I even had to add a check for fondue.

[odoe]

You can see the returned Type field in the popup for each feature on the map.

[odoe]

Part of the issue could be that Food is a category level 2, but Bar or Pub, Coffee Shop, Pizza are category level 3, so they are still included in the Food category, but could have a Type that maps to something else.

https://developers.arcgis.com/rest/geocode/api-reference/geocoding-category-filtering.htm

[codergrl]

even had to add a check for fondue.

An app to direct me to the nearest fondue place, now that's a useful app!

I'm confused as to the filters you have here. https://github.com/ArcGIS/nearby-javascript/blob/master/src/utils/iconType.ts Why are you not using the categories as types? Hard coding specific values doesn't seem like a good practice

[mikewilburn]

@odoe you beat me to it! I just found that link myself. Does the response always indicate the most granular level of the category available?

Mara also pointed out to me that category level 3: Steak House doesn't get the iconography of Food.

Might we need a more extensive list to food? i.e. tl.includes("steak") ||? Although this seem iffy to me to try to derive our own categories not knowing whether we've captured all of them.

@codergrl's idea - can we just use exclusion instead?

[esreli]

Perhaps we consider filtering by level 2 categories? This way, any level 3 category can be contained by it's level 2 search? We could change the filters to:

• Food
• Night Life
• Travel & Transport

With corresponding iconography.

[mikewilburn]

@esreli It would be neat to preserve filtering against some level 3 categories since it presents a realistic use case of our World Geocoding Service. We might see the Food icon used too broadly compared to icons showing up somewhat sporadicly for those less common level 2 categories.

Google's material design icons also has lots of icons that can be used for this purpose: https://material.io/tools/icons/?style=baseline

[esreli]

It would be neat to preserve filtering against some level 3 categories since it presents a realistic use case of our World Geocoding Service.

Sure, sounds good. Then, I will advocate for a more thorough icon-map from results.

[odoe]

Part of the issue is that for every new icon I add, I need to copy into the app as well. The WebGL in 4x doesn't support external fonts, so I need to use the svg to display map icons. https://github.com/ArcGIS/nearby-javascript/blob/master/src/utils/symbols.ts

I don't think I can realistically do them all, but I could add a few more.

[codergrl]

After some further investigation, this doesn't seem to be a data issue but potentially a bug in the filtering logic. The Android app that uses the same dataset doesn't have this issue. @odoe I think a better approach to the categories and sub categories would be to use an if else construct. Something along the lines of

  if (
    tl.includes("coffee") ||
    tl.includes("cafe")
  ) {
    return "local_cafe";
  }
  else if (
    tl.includes("bar") ||
    tl.includes("drinks") ||
    tl.includes("pub")
  ) {
    return "local_bar";
}
  else if (tl.includes("pizza")) {
    return "local_pizza";
  }
else
{
    return "local_dining";
}

I'm sure I messed up some curly braces in the process of editing that but you get the gist. This way we are not limited to having to list every category that would qualify under Food.

[odoe]

I've updated the logic to mimic the Android app, which was kind enough to provide a list of Food categories.

[odoe]

added client side filtering of results in https://github.com/ArcGIS/nearby-javascript/commit/c204f441cda2a66e524b262167114f8a4ca9c54c This should guarantee that if Pizza or Coffee Shop is removed from filter, but still searching for Food, user will not see Pizza or Coffee Shop results even if they are returned in the request.

This is now live.

[codergrl]

@odoe this doesn't seem to be resolved. If I turn off Pizza, I can still see those places, but now they're under food.

[mikewilburn]

Likewise, I still see coffee shops appear on the map and in the list, even when I've only filtered to look for the Food category.

[odoe]

I'm not seeing this. This could happen if the same location is being returned with the Type as Food instead of Pizza in the Food request. In these cases, I can't filter it out.

[codergrl]

@odoe the Silver Dollar Pizza example that I mentioned when I created the issue is the one I'm referring to.

[odoe]

This is data issue of how we are using the Locator.

It looks like this:

Food
   - Bewpub
   - Mexican Food
   - Pizza
   ...

We can exclude Pizza from the search, but we are still searching for Food, so we can still get Pizza results. Now, if they Type field of the result is Pizza, I can still honor the application filter. But this is not always the case. The Silver Dollar Pizza appears to be categorized as Brewpub and not Pizza. It may also show up as Pizza if I search for that, but not in this case.

Here is the result I see when I search in that area.

There's not really anything I can do mitigate this.

[mikewilburn]

If you filter for just Pizza POIs, do you also see that you can Silver Dollar Pizza is returned? This is the problem.

Is there a way to see if the geocoder is returning two separate (and unique) results in this case, or if the issue is on our side?

[odoe]

This is a data issue. I don't know the internals of the geocoder, but it's returning that location with different types depending on the search.

[mikewilburn]

@odoe Okay, I captured it as such. Let's close this issue then.