Apologies for not replying sooner, it's not that I don't appreciate your input, far from it, but I was temporarily required to give all my attention to something else ...
On Jul 5, 2:34 am, William <[email protected]> wrote: > On Jul 4, 9:41 pm, JavaJive <[email protected]> wrote: > > > Yes. After I finished posting last night, I briefly tried the same > > test in Opera v9.64, and was surprised to find that the results were > > different! There, GESLimit = 5 worked fine! > > > Consequently, having known of Firebug changing behaviour before, I > > tried disabling it, using my own Debug.js which simply adds a textarea > > to receive console.log messages, but the behaviour in FF3 was just the > > same, 2 errors for GESLimit = 5. > > Regarding Firebug, I found there was a problem with timer accuracy on > Firefox using window.setTimeout. Isn't that just another manifestation of the following, compounded by the extra overhead of the processing that a debugger such as FB must do? > Also there's a problem with timer resolution on Windows, with around > 15 ms between ticks. Yes, by default the hardware timer only fires at approximately that sort of interval, but that is easily sufficient resolution here. > Taking the parameters of 1024 locations, with additional locations at > 128 per second, means the following delay between requests: > > L = total locations (eg 190x10=1900) > N = number of paths (eg 10) > > var interval = Math.ceil(1000*(S - 1024) / (128*(N-1))); > > I added 50ms to overcome any rounding issues with the timer > resolution. > > see the following example:http://www.william-map.com/20100703/1/rate.htm Thanks for your work and an interesting demo, which in time may well be useful, but I've not got that far yet. I'm still struggling to produce a system that recovers gracefully in different browsers if errors are generated. As previously explained, my system fetches up to GESLimit profiles at once. For the results below where I am trying to create a reliable system of recovery if an error is caused, GESLimit = 5, which according to your calculations, should be small enough to avoid the OVER_QUERY_LIMIT error. Sometimes it does, sometimes it does not, sometimes it generates another error entirely ... To take the example of my home postcode already mentioned, the terrain profiles for 7 transmitters must be fetched. In order of likely signal strength after stage 1, and therefore of fetching, they are: 0: Hannington 1: Crystal Palace 2: Oxford 3: Rowridge 4: Midhurst 5: Hemdean 6: Henley-On-Thames The profiles are requested as follows ... console.log( req.index + ": " + (req.userObject ? req.userObject.name : "") + ", [" + LLs[0] + "," + LLs[1] + "]" + ", " + samples ); GoogleES.getElevationAlongPath( {path:LLs, samples:samples}, new Function("path","status", "reqTerrainCB("+ index + ",path,status);") ); ... where index is the position in the queued requests array of the particular request object whose results are being returned, which in turn contains a reference to the transmitter to which it belongs, and where ... function reqTerrainCB( index, path, status ) { console.log( "getElevationAlongPath(): " + index + ", " + (__rqs[index] && __rqs[index].userObject ? __rqs[index].userObject.name : "undefined") + ", " + status ); if( __rqs[index] ) switch( status ) { case "OK": __rqs[index].wrapCallBack( path ); break; default: __rqs[index].destroy(); break; } } As you can see, if the status returned is not OK, then the request destroys itself, and this in turn causes a new request for that transmitter to be sent to the Elevation Service, next time the outstanding results are checked. The results for Opera 9.64 are the most bloody-minded ... 0: Hannington, <parameter dump> 1: Crystal Palace, <parameter dump> 2: Oxford, <parameter dump> 3: Rowridge, <parameter dump> 4: Midhurst, <parameter dump> getElevationAlongPath(): 0, Hannington, OK getElevationAlongPath(): 1, Crystal Palace, OK getElevationAlongPath(): 2, Oxford, OK getElevationAlongPath(): 3, Rowridge, OK 5: Hemdean, <parameter dump> 6: Henley-On-Thames, <parameter dump> getElevationAlongPath(): 4, Midhurst, UNKNOWN_ERROR 0: Midhurst, <parameter dump> getElevationAlongPath(): 5, Hemdean, OK getElevationAlongPath(): 6, Henley-On-Thames, OK getElevationAlongPath(): 4, undefined, OK getElevationAlongPath(): 0, Midhurst, UNKNOWN_ERROR 0: Midhurst, <parameter dump> getElevationAlongPath(): 0, Midhurst, OK getElevationAlongPath(): 0, undefined, UNKNOWN_ERROR As you can see, the requests are all sent to the server, but sometimes the last one or two returns UNKNOWN_ERROR. This seems to be more likely if the requests are sent immediately after the Google code has loaded. On the test page I use, the relevant option is only enabled, via the code load callback, once Google Maps API v3 has loaded. The sooner I click 'Find likeliest' after it has been enabled, the less likely it seems to be to complete successfully. If UNKNOWN_ERROR does happen, temporary chaos takes over, in that: A: A subsequent re-sending of the request is almost guaranteed to fail with the same error B: Request(s) that initially return UNKNOWN_ERROR later appear to return OK, but by then the record of which transmitter the results refer to have been lost when the request object destroyed itself after the initial error. So what happens if we introduce another case statement in the handler ... case "UNKNOWN_ERROR": break; ... so that the system waits for the ultimate return of the errored results with OK? Surely that will save unnecessary requests being resent after the first error, and will be more efficient? Not so, although in the results below this does indeed happen with Midhurst, sometimes, as with Rowridge, the OK is not returned after the initial error, and, now that there's no mechanism to re-request that profile for this particular circumstance, the routine times out waiting for failed results which never materialise ... 0: Hannington, <parameter dump> 1: Crystal Palace, <parameter dump> 2: Oxford, <parameter dump> 3: Rowridge, <parameter dump> 4: Midhurst, <parameter dump> getElevationAlongPath(): 0, Hannington, OK 0: Hemdean, <parameter dump> getElevationAlongPath(): 1, Crystal Palace, OK 1: Henley-On-Thames, <parameter dump> getElevationAlongPath(): 2, Oxford, OK getElevationAlongPath(): 3, Rowridge, UNKNOWN_ERROR getElevationAlongPath(): 4, Midhurst, UNKNOWN_ERROR getElevationAlongPath(): 4, Midhurst, OK getElevationAlongPath(): 0, Hemdean, OK getElevationAlongPath(): 1, Henley-On-Thames, OK It's a mess. As I have been saying all along, we are floundering around in the dark here. Google should publish a mechanism that is guaranteed to work for making successive requests, so that we can just follow it. We shouldn't be having to second guess or reverse engineer their code in order to get it to work. -- 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.
