Hi Hernán, It sounds like you fully understand the encoder, and as far as I can tell, all your conclusions are correct. Great work!
As you alluded, some more end-to-end testing is necessary to make sure that it does indeed work in a practical setting. There is some sample data offered on the issue page [1], so perhaps you can test against that. Thanks! [1] https://github.com/numenta/nupic/issues/1461 <https://github.com/numenta/nupic/issues/1461> - Chetan > On Dec 9, 2014, at 12:03 PM, Hernán Erasmo <[email protected]> wrote: > > 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 > <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 > > <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 > <http://www.apsalin.com/convert-geodetic-to-cartesian.aspx> > [4] http://www.colorado.edu/geography/gcraft/notes/datum/datum.html#LatLonHgt > <http://www.colorado.edu/geography/gcraft/notes/datum/datum.html#LatLonHgt> > [5] http://www.radartutorial.eu/18.explanations/ex26.en.html > <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 > > <http://www.usna.edu/Users/oceano/pguth/website/so432web/e-text/NIMA_datum/VERTICAL%20DATUMS.htm> >
