Inaccurate Google Maps Elevation Service response when splitting a too large path

Question

This is a bit of a question with some level of detail to it, so let me first explain the situation, then my implementation and last the question so you understand best.

Answer 1

Concerns raised in the implementation part, side note and problems enumerated are all covered in Google Maps Elevation API. The complete documentation provides a simple interface to query locations on the earth for elevation data and will address all your encountered problems like elevation requests, parameter usage, specifying locations, paths and elevation responses.

For concern discussed in your Introduction, Google Maps Elevation API has standard and premium usage limits. These limits are enforced to prevent abuse of the Google Maps Elevation API. Google Maps Elevation API Usage Limits provides you details regarding usage limits and option to increase your quota.

Additional notes from the documentation which may address your concerns:

1. Note that elevation data becomes more coarse when multiple points are passed. To obtain the most accurate elevation value for a point, it should be queried independently.
2. In those cases where Google does not possess exact elevation measurements at the precise location you request, the service will interpolate and return an averaged value using the four nearest locations.
3. As with positional requests, the path parameter specifies a set of latitude and longitude values. Unlike a positional request, however, the path specifies an ordered set of vertices. Rather than return elevation data at the vertices, path requests are sampled along the length of the path, where each sample is equidistant from each other.
4. The Google Maps Elevation API returns data for single point queries of the highest accuracy possible. Batch queries involving multiple locations may return data with less accuracy.

Answer 2

The last remaining issue has also been solved with the help of this SO question: How to re-run a javascript promise when failed?. So if jfriend00 replies to this question I can award the bounty to him, since that's the trick that helped me out in the end.

To be sure the function resolves at status OK, retries at OVER_QUERY_LIMIT and reject at any other status I had to put the Promise logic within a function and call that function, like so:

function getRouteElevationChartDataBatchPromise(batch, batchSize) {
    return new Promise(function(resolve, reject) {
        function run(batch, batchSize) {
            var elevator = new google.maps.ElevationService();
            var thisBatchPath = [];

            for (var j = batch * batchSize; j < batch * batchSize + batchSize; j++) {
                if (j < directions.routes[0].overview_path.length) {
                    thisBatchPath.push(directions.routes[0].overview_path[j]);
                } else {
                    break;
                }
            }

            elevator.getElevationAlongPath({
                path: thisBatchPath,
                samples: 512
            }, function (elevations, status) {
                if(status == google.maps.ElevationStatus.OK) {
                    routeElevations = routeElevations.concat(elevations);
                    resolve();
                } else if (status == google.maps.ElevationStatus.OVER_QUERY_LIMIT) {                        
                    setTimeout(function () {
                        run(batch, batchSize);
                    }, 200);
                } else {
                    reject(status);
                }
            });
        }

        run(batch, batchSize);
    });
}

Answer 3

Mmmh, how many points do you have to handle. Can you publish the path, so maybe some other can test it in their own apps. Did you try to reduce the path points with Douglas-Peuker or comparable methods. Did you try other apps like the free "Routeconverter" (which works with HGT) to see if you get better results. Do you need the elevation points direct/on the fly? Would using other free elevation services be an option. Perhaps you have to read the elevation points back to your route points, so that you can sort out unwanted points.

Only some thinking, in bad English - I'm afraid. Good luck, Reinhard