emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Advice needed. Use links or blocks?


From: David Maus
Subject: Re: [Orgmode] Advice needed. Use links or blocks?
Date: Sun, 12 Sep 2010 13:23:55 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.8 Emacs/23.2 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Sebastian Rose wrote:
>Nick Dokos <address@hidden> writes:
>> Sebastian Rose <address@hidden> 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.... address@hidden
Email..... address@hidden

Attachment: pgpLixIHFVLZC.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]