According to documentation, you need not assume a fixed 3-dimensional space, so XY should be totally reasonable. Regardless of dimensionality, you do need to specify a radius
, which GeoSpatialCoordinateEncoder
maps “speed” onto. GeoSpatialCoordinateEncoder
is a subclass of CoordinateEncoder
and is designed to work with latlong data.
I’m confused, however, in trying to put together a quick-and-dirty example and am running into what appears to be a bug. For example, this code snippet:
from nupic.encoders import CoordinateEncoder
import numpy
coords = numpy.array([1.0, 2.0, 3.0])
radius = 3.0
enc = CoordinateEncoder()
enc.encode((coords, radius))
Produces this error:
Traceback (most recent call last):
File "coord.py", line 7, in <module>
enc.encode((coords, radius))
File "/Users/amarshall/nta/nupic/src/nupic/encoders/base.py", line 133, in encode
self.encodeIntoArray(inputData, output)
File "/Users/amarshall/nta/nupic/src/nupic/encoders/coordinate.py", line 109, in encodeIntoArray
neighbors = self._neighbors(coordinate, radius)
File "/Users/amarshall/nta/nupic/src/nupic/encoders/coordinate.py", line 130, in _neighbors
ranges = [range(n-radius, n+radius+1) for n in coordinate.tolist()]
TypeError: range() integer end argument expected, got float.
Casting radius to int doesn’t help, either because of this detail in the implementation of CoordinateEncoder._neighbors()
:
ranges = [range(n-radius, n+radius+1) for n in coordinate.tolist()]
i.e. coordinates are floats, so n+radius+1
results in a float
, which is an invalid value for the second argument to range()
.
Sticking to int
works (see below), but that requirement is inconsistent with the documentation and (I think) most people’s expectations.
These [1-3]-dimensional one-liner examples work fine:
print CoordinateEncoder().encode((numpy.array([1]), 3))
print CoordinateEncoder().encode((numpy.array([1, 2]), 3))
print CoordinateEncoder().encode((numpy.array([1, 2, 3]), 3))
Expect a proper github issue/bug report to follow.