Cha-ching: integrate EGeoXML js lib for elevation profiles

[jamesob]

The library we've been searching for is right here: http://econym.org.uk/gmap/egeoxml.htm

Apparently we may have to bring it up to V3 spec, but that may not be a big deal.

[mike-zorn]

It seems like we can use the newer version of EGeoXML to parse kml into an array of locations which we then feed into the Elevation API. The issue here is that since we use javascript to parse the kml data, we do all the parsing clientside and on every pageview could slow things down considering that after parsing the kml, it'll need to send that data to the Elevation API and then parse the data it returns and send it to the Chart API and the display the chart.

[jamesob]

I had the same concern about client-side load, not to mention the fact that we'd be hitting Google tens of times for each user, which seems wasteful. One option I was considering is to use the Static Maps API, which basically has you parameterize the route within a URL which returns an image. Another option for us would be to cache KML parsing server-side; though, of course, this is impossible using only gh-pages.

[mike-zorn]

Yet another option would be to make a python (or something else) script which preprocesses our posts by parsing the map given in the post, getting the elevation data, parsing that and then using the chart api or matplotlib to make a chart which it then puts in the post.

[mike-zorn]

I'm working on the preprocessor now. I think I'll have a prototype pretty soon that will parse the route kml and hopefully other things.

[jamesob]

Excellent. I think wrt to the maps, the best thing to do is server-side caching. I think we should use a Python script that we poll via jQuery+Ajax (see here). The Python script can maintain an index of kml/map-image pairs (or something similar) and if we request a map not within the cache, it'll pull it down from GMaps for us and do all the storage boilerplate.

[mike-zorn]

There is now a Python script which will parse kml, do some stuff and make a nice picture of the elevation profile see bf4a1deebda659e2639f8400db79f12476078e24. I even added the picture to the route page.

To be honest, I don't really see the point of using the static maps API over the javascript one especially if it prevents us from using gh-pages. I was primarily worried about doing parsing and profile generation client-side.

[mike-zorn]

I actually read the first page of the static map API, and I now see the advantage.

Since the map will never change after we post, I think we should just add this to the preprocessor. This way there will still be no server-side code and we can still use github pages.

[jamesob]

Yep, sounds good. My only other concern was API limitation. I think elevation is limited to 2,500 requests per day. I seriously doubt we'll ever get that much traffic, but I guess it's possible.

[mike-zorn]

It won't even be an issue since the preprocessor will do all that at post time. We will have exactly one call to the elevation API per post. Everything on the page will be either text or an image. The only Javascript will be the twitter/flicker stuff.

[jamesob]

Closing it out; you've got the preprocessor cooking and so we needn't use any external JS libraries AFAIK.