I've found myself with a lot of free time in my hands last weekend (a long
weekend here) and I spent some of it (most of the sober part) learning a
little bit more about how the GeospatialCoordinateEncoder(GCE) works.
I've submitted a pull request (which you can find in [0]). Perhaps I
underestimating this issue, and think that this solution is correct when in
fact it doesn't solve anything. I'll try to explain here what I've been
doing:
Right now, the GCE only uses latitude and longitude to generate a
coordinate based on the Spherical Mercator Projection. I believe that
Chetan said in his video on how the GCE works that this is the projection
Google uses for Google Maps. Well, besides that, I can't find another
reason to use specifically that projection. It's not that I think that's
wrong, but it's just that I don't see why it has to be THAT one.
Anyway, I see that nupic uses pyproj to convert latitude and longitude to
spherical mercator coordinates (x and y) and I tried to find examples of
pyproj where 3d coordinates were used. The documentation of pyproj turned
out not to be that much helpful, since the only reference to a third
coordinate is in the description of the 'transform' method [1] and even
there there's not an example where a third coordinate for altitude is used.
I did find an example on this question in GIS.stackexchange [2]. The answer
provides an example of using the pyproj.transform() method to convert from
latitude and longitude to a 3D geocentric coordinate system.
This is the part where I make a big assumption (and probably an innacurate
one, where I think I could be wrong) and say that that the Coordinate
Encoder doesn't really care about the transformation (datum, reference
system or whatever) we use for going from latitude and longitude to x,y (or
x,y,z when using altitude), since the part that encodes the coordinates is
not bound by its dimensions number (this last part about dimensions number
is pretty much what Chetan says around min. 25:10 of his GCE video)
So the solution I propose is very basic, and it's limited to the GCE only:
- If no altitude is given, then continue to use the spherical mercator
projection to calculate x and y coordinates from latitude and longitude
- If altitude is given, then calculate the spherical mercator
projection and transform the x and y values to geocentric 3d coordinates
using WGS84 datum and the given altitude.
I believe that's the core of the change.
As for the "If necesary, update the radius calculation to work for the 3D
case as well" part of the to-do list, I don't think it is. Since radius
calculation doesn't depend on the values of x,y or x,y,z. Different
coordinates will produce different results, whether they're 2d or 3d.
And then there's testing. I made a couple of unit tests resembling the ones
that check the coordinates that are generated using the spherical mercator
projection, but they just check the output of the 3d coordinate projection.
This is not a bulletproof demonstration of correctnes, but I get the same
results using the converter in this online converter [3]
I guess that's all I can think of right now. I'm going to see if I can come
up with other ways to test this feature, but I'd like to hear your opinions
(and/or corrections).
For more information about specific terms, like datum, geodetic altitude,
coordinate system... these links explain everything in a very clear way:
[4], [5], [6]
Cheers!
[0]
https://github.com/numenta/nuhttps://github.com/numenta/nupic/pull/1606pic/pull/1606
<https://github.com/numenta/nupic/pull/1606>
[1] http://pyproj.googlecode.com/svn/trunk/docs/pyproj-module.html#transform
[2]
http://gis.stackexchange.com/questions/73728/how-do-i-convert-longitude-latitude-to-a-3d-geocentric-x-y-z-coordinate
[3] http://www.apsalin.com/convert-geodetic-to-cartesian.aspx
[4]
http://www.colorado.edu/geography/gcraft/notes/datum/datum.html#LatLonHgt
[5] http://www.radartutorial.eu/18.explanations/ex26.en.html
[6]
http://www.usna.edu/Users/oceano/pguth/website/so432web/e-text/NIMA_datum/VERTICAL%20DATUMS.htm
