algorithmic modeling for Rhino
Just developed a plugin which can generate landscape automatically with elevation data from Google Map.
Just input Location(Latitude and Longitude) and area (m2) and the component can generate a squared landscape centered with the input location.
Output are the landscape surface and points (you can manipulate and then loft to landscape surface yourself)
The aware of the limitation as also mention the in ghowl http://code.google.com/apis/maps/documentation/elevation/#Limits
A example is attached, compare it with location(-8.2168,115.357394) in google earch.
Finally got it working after playing around with the maths I am most afraid of. This is a 3 by 3 definition in which you just need to input the cooordinates for the centre. Not sure how to stitch the result landscape pieces together though, I think they might not be perfectly aligned. Any improvements welcome.
Thank you for this- I am really having fun with it.
Any plans to connect additional databases? Google Earth is nice for Architects, but having geological surveys would be much better for Engineers.
Also, having the ability to generate stitched topographies within the component would be amazing. I guess you are using Rhino 5 (which I do not have) for the stitching definition? I look forward to future improvements.
Thank you again!!!!
Actually there is another plug-in called Elk (here) which has the ability to generate topography over a much bigger area with data from NASA, but the resolution might not be as high or as accurate as google's data (please correct if I'm wrong):
"SRTM1 data is sampled at one arcsecond (about 30 meters) and SRTM3 data is sampled at three arcseconds (about 90 meters). The higher resolution SRTM1 data is available for most of the US and the lower res SRTM3 data is available for most of the world."
The 3x3 stitching definition above is done in Rhino 4 but it doesn't actually "stitch together" or merge the surfaces into one. I had to do it manually in Rhino with the merge surfaces command. Which I think does a better job than grasshopper.
Also I think the calculations within it (distance of one degree change in lat/lng) won't be accurate enough (or high enough in resolution) even though they are correct so I cannot guarantee the 3x3 pieces are perfectly neighbouring sets of data (they might contain very very tiny strips of overlapped/missed topography data). However this error is really insignificant next to the limited resolution of the generated topography so it is neglectable if you're not a perfectionist like me.
Edit: For bigger areas Elk is much easier, but for smaller areas where you want to specify the area size Xiaoming's component is more convenient I think.
Thanks, this is immensely useful.
Edit: The data from Google and NASA have bigger differences than I thought, interesting.
Very useful component, any ambition in open-sourcing this?
Sorry for the late reply. I have not use it for a long time. I diged out the code as replied below.
Very cool, thanks! You made it because it was useful for you one time, but not anymore? Just wondering why this faded out a little bit.
I am mainly interested how you are doing the XY-geo coord conversion and how you batch the google requests. But it seems no batching occurs? I'm asking because it seems to be a very limiting factor in the elevation API, the resolution decreases with the number of points per request, but the number of requests per 24-h is very limited. Trying to maximize the resolution I can get for an area by batching the points.
Source code attached.
© 2023 Created by Scott Davidson. Powered by