[Feature Request] Improved Categories for Radar Places

[noahtallen]

Currently, when looking at a place's categories, you see a list like this: travel-transportation, transportation-terminal, airport, train-station (this is for the Portland International Airport, Radar ID: 59c28b488be4c5ce940ba105).

In our app, we basically try to determine the "most relevant" category for a place, and then match that category to certain game content. This allows users to play our travel game. One thing that's challenging with these categories is that there isn't a clear way to discover which category is the most important. For instance, in the above example, I would expect airport to be the most relevant category to a user.

The pattern I've noticed with the categories is basically top of the hierarchy to bottom of the hierarchy. So, this example follows this pattern: 1, 2, 3, 3. Airport and train-station are on the same level of the category hierarchy. What works a lot of the time is choosing the last category which is at deeper level than the next category. in this case, that would be "train-station", and for a pattern like 1, 2, 1, 2, 3, that would be the first occurring 2. This works okay for a lot of cases.

What would be really nice is to see a "primary" category for a place - for instance the primary category for the Portland Airport would be "airport". While testing our app with Foursquare's location data, this worked really well, since their category list includes a boolean "primary" key which indicates which category we should use as the most relevant category to a place.

That's the first part of this request, the second being better linking to Facebook categories (or whichever provider we choose). The main reason for this is our "nearby places" feature, where the user can see which nearby places they can go to earn points in the game. Since Radar doesn't have this feature built into the SDK, we do a request to Facebook Graph API to search for places near our coordinates. The facebook place category list looks like this (Flow type format):

  category_list: Array<{
    id: string,
    name: string
  }>

There are a couple of differences from the Radar place category list here.

1. It seems to be sorted with the "most relevant" category first.
2. There isn't an easy way to link the facebook category back to the Radar category ID. I basically take the name, make it all lowercase, and replace the whitespace with dashes. So "Fast Food" would become "fast-food". Then I link that category "ID" back to the Radar category IDs and match it to our game content.

These approaches seem to work alright, but they aren't quite ideal for our use case. If you could give us some guidance on this, it would be much appreciated! I'm sure one part of it might be the possibility of future place providers. Finally, thanks for developing this awesome tool and for all the hard-work you guys put into the project! :)

[nickpatrick]

Hey @ntomallen, thanks so much for the thoughtful note. This is something we've been thinking about recently, too.

If we changed the categories array sort order so that the most relevant categories came first, and if we exposed a facebookCategories array with Facebook category IDs in the same order, would that solve this case for you?

Can you explain why having the Facebook category IDs mapped to the Radar category IDs is useful to you?

/cc @coolbrow

[noahtallen]

Absolutely! Our app is a location game where users can earn points and badges for visiting different locations. In general, we don't have very many restrictions on places users can visit. The way we match a place to points in Radar is through the categories.

Basically our process is:

1. An admin creates a "subcategory" which covers a group of related places. This subcategory includes a primary "Zonder" category (we have 8 of them), the number of points a user can earn, and a list of Radar categories the user can visit.
2. When the user visits a place, we find the "most specific category" (as outlined above), and see if any subcategories include it. If a subcategory does include the place's category, then we can award the relevant game content to the user.

Basically all of the matching to game content happens through the category of places. For instance, a coffee shop will count for 10 points in the Food category, but we only know that a place is a coffee shop through a place's categories.

Hopefully that makes sense so far! At this point, having Facebook categories is not important since Radar provides everything necessary.

But, another feature we are adding is the ability for a user to see a list of nearby places they could visit to earn points. To show that list, we need to use a Facebook graph API call (since Radar doesn't have a build-in method for it), and we also need to match the Facebook places to the same game content that a Radar place matches to. That way, a user can see "oh, there is a coffee shop over there worth 10 points, I should visit!" This only works if we can match the categories, though, since that's how we figure out how much a Radar place is "worth".

Ideally, we would be able to get several nearby places from Radar with the same category format and data model as normal Radar places, so we can re-use our code more! We don't want to manually input facebook place categories on top of Radar categories, as it introduces a lot of room for error. The only reason the Facebook category IDs are useful is to match a Facebook place from the Graph API call with the same internal data that we match Radar places to.

While we're talking about it, it would also be very convenient to have an API endpoint for viewing all Radar categories for admins to select from. I know Facebook and Foursquare both have an endpoint that does that. To get around that, I may have done a little web scrapping so we can select from the categories in our own admin portal. ;)

Does that all make sense? let me know if you have any more questions.

P.S. that alternative sorting does sound very nice to me!

[nickpatrick]

Closing as duplicate of #45.