# Can GPS coordinates (latitude and longitude) be used as features in a linear model?

I have data sets that contain, among many features, GPS coordinates (latitude and longitude). I'd like to use these data sets to explore problems such as: (1) computing ETA to drive between start and end points; and (2) estimating the amount of crime for a specific point.

I'd like to use a linear regression model. However, can I use these GPS coordinates directly in a linear model?

Latitude and longitude do not have an ordinal property, such as with a person's age. For example, the two points (40.805996, -96.681473) and (41.226682, -95.986587) do not seem to have any meaningful ordering. They are just points in space. I was thinking of replacing them with categorical US zip codes and then doing one-hot encoding, but that would result in a lot of variables.

• Do you have to use them directly? Have you heard about zoning tools, such as the AZP algorithm by S. Openshaw? You could even manually delimit regions in a map to separate regions/zones, if the area is relatively consistent. Oct 9, 2017 at 21:24
• @Mephy: That would mean I'd convert lat / long to zones, right? But then I would have hundreds or thousands of categorical zones, just like with zip codes. I'd have to one-hot encode all of them. Oct 9, 2017 at 21:56
• Depends on how you cut the zones, of course. If you choose "south of the Equatorial line/north of the Equatorial line", then it's only two. Many zoning algorithms have some hyper-parameters to define quantities such as the number of zones or minimum zone size. Oct 9, 2017 at 22:21
• I have the same issue.I wanna predict a people's position. I have geohashed all the geolocation features in training data. After that,LabelDecoder is used to transform the categorical location feature. Finally,the result is terrible. Is there any good idea to deal with the spatial prediction? Jan 30, 2018 at 3:53

You cannot use them directly, as it is unlikely there is a true linear relationship unless you're looking to predict "how far east or north" someone is. As mentioned in the comments, you need to convert them into zones. If you wanted to keep it really simple, you could use a kNN clustering algorithm with a low number of potential clusters and then assign each instance a new feature with the cluster ID, and then one-hot encode that.

You may also want to read about how people interpolate coordinates to predict values across a whole map. The first example is with temperature stations, but you can also imagine it being "hot zones" for crime.

(DOCS)

You could do whatever your heart desire, but unless your model predicts the temperature or time-difference, I cannot come up with any other target variable that depends solely on the coordinates.

What you probably want to do, is use an external data source and enrich your data with Country / Zip code / climate / other geographic features that will help your model perform.

GPS coordinates can be directly converted to a geohash. Geohash divides the Earth into "buckets" of different size based on the number of digits (short Geohash codes create big areas and longer codes for smaller areas).

A geohash is a single number that can be used as a feature in a model.

Geohash applies only to the entire world, zipcodes do not.

• The output of a geohasher is a string, not a single number, right? And if the geohash is a string, then I'd have to one-hot encode it, which would result in a lot of variables, just like with a one-hot encoded zipcode. Oct 12, 2017 at 18:11
• A geohash is a single number, encoded in base 32. There is no reason to 1-hot encode. Pick the level of precision and use the relevant number of digits. Oct 16, 2017 at 21:11
• I have only seen string representations of geohashes. However, even if geohashes were represented as an long int, is there any linear relationship between them for use in a linear model? That's exactly the point of my original question. Oct 17, 2017 at 20:02
• The relationship between geohashes is slightly complex - en.wikipedia.org/wiki/Geohash#Design Oct 17, 2017 at 21:13
• There are many ways of feature engineering beyond linear and one-hot encoding. For example, the kernel trick or Helmert transformation. Oct 20, 2017 at 15:38