embedding gmap4

[Joseph Elfelt]

https://maps.google.com/maps?q=http:%2F ... 8&t=h&z=20

the lat/lon of the center of all the gifs is identical.

Thanks for the Google Maps link!
Very interesting.

It looks like Google has two different KML parsers (aka rendering engines).
One parser is used by Google Maps and by API apps like Gmap4. That parser shows an exaggerated 'height' for 'spikes' (i.e. outliers) in the data. The other KML parser is used by Google Earth and does not exhibit this behavior.

I will include this additional info in the bug report I am going to file with Google. They have actually fixed some things in response to prior bug reports I filed. Hey - it's possible to move the mountain - whadayaknow.

[kepPNW]

Yep, them's the ones. And the same KML doesn't do that in Google Earth. Different rendering engines; that's gotta be it. Glad we're in sync again!

The funny part is that Google is telling us API developers that they want stuff to look the same in both GE and API apps. I am going to file a bug report with Google on this. We will see what response I get - if any.

Good luck with that! (I can't even get them to move the label for Beacon Rock across the river from where it now sits - atop Nesmith Point!) Feel free to subset the data, extracting just enough to help eliminate the sorts of confusion we had here.

[kepPNW]

Joseph, do you mean by the "height of the spikes" vertical excursions in altitude in the GPS recorded data?

No. I used a poor choice of words.

By 'height' I meant the perpendicular horizontal distance from the track at that location.

Here's an illustration that might help. It's the Warren Lake area on the Defiance loop...

Click for fullsize.

I owe you an apology, too, Joseph. The more I explore the data, you were very right about something I didn't want to believe at first. The large spikes I was seeing were, so far as I can now tell, all originating at those spider-on-acid-webs Garmin creates when one pauses along the trail. They're simply not noticeable at the same small scales in GE as they are in GM! (The above image is enlarged 150% from how Google presented it originally.) Each of the three major spiky areas around the lake are places I stopped and/or moved off-trail, to take photos.

[retired jerry]

But, it's not a Google error it's a GPS error

There's an error each time the GPS takes a position reading

The same error occurs as you're walking along but it's not so obvious

It would be difficult to filter out. It looks the same as a trail that wanders around a little, like switchbacks.

[Joseph Elfelt]

In addition to "pauses along the trail" sometimes a GPS will record 1 (or a few) bad track points. They all do this. Some more than others. Maybe for a few seconds your GPS did not have a good sat lock.

These bad track points can also cause 'spikes' when viewing your track on a map.

[kepPNW]

But, it's not a Google error it's a GPS error

It's a bit of both, Jerry. Pissy recording, yeah. But pissy rendering in GM (as opposed to GE), too. The recording error is accentuated in GM.

In addition to "pauses along the trail" sometimes a GPS will record 1 (or a few) bad track points. They all do this. Some more than others. Maybe for a few seconds your GPS did not have a good sat lock.

I haven't seen examples of that causing the same sorts of spikes, but at this point I'll believe you.

I know that I've seen the darn thing say I swam across the Columbia on the way up a ridge!

[retired jerry]

But how can you screw up plotting X-Y coordinates on a grid?

[Joseph Elfelt]

Just filed this bug report.

http://code.google.com/p/gmaps-api-issu ... il?id=4776

Anyone can sign in with their google account and then click the yellow star (along left edge) to help make this wheel squeak.

[raven]

To me as interesting as the horizontal spikes, which seem to be smoothed by an averaging algorithm while moving in relatively constant direction, are the unseen vertical spikes. All the spikes are added to the distance traveled as recorded by the GPS, but because the triangulation algorithm is less accurate vertically than horizontally, the climbing-without-pain exercise is much greater than the ants-in-my-pants exercise when stopped.

That averaging algorithm must be inaccurate at switchback turns and when recording positions along the switchbacks. The algorithm may, for example, take the computed starting position at a change of direction and smooth from that point onward. Makes me wonder when to trust trails as marked on USGS quads versus recorded GPS tracks. Also whether a stop at a switchback on a long climb would lead to the track adjusting the location of the track on the ridge from that point forward.

How much may the Secret Sauces of the GPS companies differ?

[kepPNW]

But how can you screw up plotting X-Y coordinates on a grid?

They're not screwing up the X/Y's. It's how the lines are joined. Here's a diagram of the three main ways you can make lines (fatter than 1 pixel!) "look nicer" in ESRI products:


ESRI CartographicLineSymbol Documentation

Google is probably doing the rounded or beveled join in GE and a mitered join in GM. Now, imagine what happens to that miter as the angle between the two lines decreases. As the angle approaches 0°, the miter will approach infinity, eh? It's a good (computation sparse) algorithm with reasonable angles between line segments, but really makes a mess in cases of extremely acute angles.