Did anyone use the placekey identifier as a feature to deep-learning?

Questions & Help
1

Hi,
Did anyone use the placekey identifier as a feature to deep-learning?
Can a network learn proximity from placekey?

2

Hi @Eli_Safra_Ph.D_Technion, while the WHAT portion of the placekey is probably not going to provide any value as a feature, the WHERE certainly has some potential.

  1. The WHAT component (before the “@“) is a contextless identifier for a specific address and point of interest. It provides no information about the POI. Its only purpose is to allow for data joins by uniquely identifying a single address/POI that exists in the area specified by the WHERE component.
  2. The WHERE component corresponds to a hexagonal area on the globe. It is built on Uber’s H3 (https://eng.uber.com/h3/). H3’s docs briefly mention clustering
    —not necessarily in the context of machine learning, but I can imagine it being useful. If you’re just looking for proximity from a placekey, the WHERE component can be used without the need for any deep learning. H3’s library has functions like h3ToGeo() or geoToH3() that would come in handy.
3

Thanks, Ryan,
I didn’t phrase it correctly.
The mission is not to infer the proximity from Placekey but to use it to infer other information like Weather or crime rate.

4

I see. You’re welcome!

I think the best way to think about it is that Placekey should help to enable those kinds of connections. For example, given a crime rate dataset and a weather dataset, adding placekeys to both will allow for easy joining. I’d imagine those kinds of datasets would have placekeys with only the WHERE component (no address or POI involved), so they could be joined with each other in a pretty straightforward way (WHERE-to-WHERE).

If you wanted to include weather in a model predicting various POI foot traffic, the process will be similar but perhaps one extra step. The POIs’ placekeys will be of the form what@where while the weather placekeys will only be @where. In this case, you could create a new column to give each POI a WHERE-only placekey, which could then be joined with the weather dataset.

Another consideration might be the resolution of the proximity (weather/crime rate) data. If the proximity-based data has lower resolution than the WHERE component (based on H3), then some of the POI-based data might not have a match in the proximity-based data. There are probably a number of ways to handle that if it comes up.

5

I should also note for any future readers, if your proximity-based dataset (weather/crime rate) is already on the same terms as your POI-based data (perhaps by Census Block Group or Zip Code) then Placekey is likely not needed to make that connection.

6

^^ Or you can map all geospatial data to the H3 WHERE key and then join them on that key.