Sebastian Rose wrote: >Nick Dokos writes: >> Sebastian Rose wrote: >> >> >>> the attached file fetches background tiles from openstreetmap.org for >>> me, and produces SVG images of tracks I ran. Unfortunately, I cannot >>> find a good way to use that code in an automated way. >>> >>> What I'd like to do, is to have the coords in my training diary, and >>> produce the images on demand. When I publish the diary to HTML, I want >>> the coords to be replaced with a link to the image. >>> >>> Here is an example of the coords (just two), as I save them in my diary: >>> >>> '((9.707136154065665 52.3705158282501)(9.711406230817374 52.37525815071791)) >>> >>> >>> And this is, how the function to produce the images is used: >>> >>> (osm-draw-track >>> ;; Fantasy-track in Brisbane: >>> '((152.968 -27.533) (152.968 -27.546) (152.974 -27.537)) >>> "Track_in_Brisbane" >>> 8) >>> >>> >>> >>> Should I go for a special link type: >>> >>> [[track:((152.968 -27.533) (152.968 -27.546))][2010-09-03 in Brisbane]] >>> >>> ?? >>> >>> >>> Right now, I produce a lisp file, that produces all those images using >>> `osm-draw-tracks' and add simple links. But this is inconvenient and >>> prone to error (forgotten tracks)... >>> >> >> Very cool indeed. I am certainly not an expert but I thought I'd remind you >> of a vaguely similar idea that Julien Danjou implemented with his >> org-location-google-maps.el: he stores the location in the LOCATION property >> of an entry. >> >> Maybe a TRACK property, possibly accompanied by an ID that will link to >> the SVG as an attachment and act as a cache? And other fields can be added >> at will (name, date, completion time, amount of water drunk :-) etc.) >I have those kind of properties. Start-time, pace, etc. >But I was hoping to make it usefull for other purposes, too. One could >have more than just one track in a section. E.g. one for the warm-up, >one for the competition. >Actually, I'd like to click somewhere and see the track in an extra >frame. In Emacs and in my Browser. That's why I was thinking about >links. >As I look into `C-h f org-add-link-type' I guess links are indeed the >way to go. Yes, but the link type [[track:((152.968 -27.533) (152.968 -27.546))][2010-09-03 in Brisbane]] has the problem that it is not a proper URI. While this might be no problem internally, I would prefer a link syntax that matches the URI specs (RFC3986[1]). Just took a look on the list of the registered URI schemes[2] and there is a (recent) link type for geo information: RFC5870[3]. It might be somewhat expensive to (fully) implement the geo: URI scheme in Org, but I think it would be worth it. If my quick glance on the specs is right a geo: URI identifies a point, hence a geo-track: link could be somewhat like: geo-track:GEO[/GEO] Where GEO is a path conforming with the geo: URI spec. Best, -- David [1] http://www.rfc-editor.org/rfc/rfc3986.txt [2] http://www.iana.org/assignments/uri-schemes.html [3] http://www.rfc-editor.org/rfc/rfc5870.txt -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmjena@jabber.org Email..... dmaus@ictsoc.de