Thanks for the very clear answer. On a slightly related issue, can the geometry library be loaded asynchronously on demand? The documentation http://code.google.com/apis/maps/documentation/javascript/basics.html#Async shows how to load the entire API asynchronously, but it might be useful to load the main part of the API all the time, with the geometry library loaded only when needed.
My attempts to do this by building a script dynamically (like the loadScript function in the documentation, but without the callback to initialize) have not worked. For what it is worth, the geometry library seems to load pretty quickly anyway, but better minds than mine thought it useful to place it in a separate library to improve performance. - Jeff On Jan 17, 12:04 am, Ben Appleton <[email protected]> wrote: > Hi Jeff, > > It seems you've hit your browser's URL length limit. We send the > (compressed) path and the number of samples to the server for subsampling. > In your case it sounds like the path is too long even after compression. > > You'll need to simplify, subsample or split your path as you suggest. You > may find the google.maps.geometry library useful for this. > > Good luck! > Ben > On Jan 17, 2011 9:19 AM, "JKurtock" <[email protected]> wrote: > > > > > > > > > In using this call to elevation Service: > > > elevationService.getElevationAlongPath({ > > path: elevation_path, > > samples: 256 > > }, plotElevation); > > > plotElevation is called with status=UNKNOWN_ERROR when the > > elevation_path (an array of LatLngs) has more than about 450 elements. > > (and works successfully with fewer). Also, the call to plotElevation > > seems to be delayed by about 5 seconds, as if "UNKNOWN_ERROR" were > > actually responding to a time-out of some sort. > > > getElevationAlongPath is actually computing the elevation at (here) > > 256 equally-spaced points along the path, so the problem might be > > related to path length rather than the number of elements in the > > array. I have not tested that specifically. (The test above has a > > path length of about 30 miles.) > > > Has anyone else seen this? > > > What would be an effective work-around? Breaking the elevation_path > > into pieces wouldn't work well, as getElevationAlongPath breaks that > > path into equally spaced intervals, and if I were to submit two pieces > > the intervals would not be the same size. Unless I first measured the > > length of each path-segment, and adjusted the samples to fit. > > Decimating the elevation_path (to get the number of elements below > > ~450) would introduce (potentially) a lot of error. The decimated > > points would all correctly be on the path, but when > > getElevationAlongPath breaks that path into equally spaced intervals > > it would be interpolating the decimated points. In hilly terrain (the > > only place one really cares about elevation) the interpolated points > > could have a significantly 'wrong' elevation. > > > Thx. > > > - Jeff > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Maps JavaScript API v3" group.> To post to this group, send email to > > [email protected].> To unsubscribe from this group, send > email to > > [email protected]<google-maps-js-api-v3%2B > [email protected]> > .> For more options, visit this group at > > http://groups.google.com/group/google-maps-js-api-v3?hl=en. > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
