[Nepomuk] GPX metadata

Vishesh Handa me at vhanda.in
Mon Sep 24 22:25:32 UTC 2012


Okay, it has been 8 days. I expected someone to reply!

On Mon, Sep 17, 2012 at 3:59 PM, Anders Lund <anders at alweb.dk> wrote:

> Hi list,
> I would like to enhance KDE with the ability to show metadata for GPX
> files.
> GPsExchange files contains things like routes, tracks and waypoints, along
> with
> some metadata.
> GPX files can be opened by Marble, or moved to your gps device for
> utilisation
> there, or manipulated using gpsbabel, for example.
> The interresting part for me, would be to see something like
> myfile.gpx:
> 3 tracks, x km, from dates x/x/x - x/x/x
> 33 waypoints of types t, t, t
> 1 route, x km
> source: appname
> bounding box: point, point
> Extracting these data is a question of looking at a XML stream and
> reading/counting elements + reading a few attributes, and calculating the
> length of routes and tracks.
> The question is how to store the data in nepomuk, and where the code should
> be, and what it should be based on.
> I would also like to have a preview, a map that would show the data in a
> simplified form, including indicating the global location, but that maybe
> more
> interresting in some other forum.

Alright, the way I look at it there are 3 parts to this -

1. Reading the files - As you mentioned it is simple XML, so reading it
should be fairly simple.

2. Storing the data - The problematic part is storing the data. We need to
know exactly what you're storing. As far as I know, we don't have the
ontologies to store location data.

We do have pimo:Location and some similar stuff, but nothing for what you
want to store. (Don't worry if you don't understand what "pimo:Location",
don't worry. It's boring internal stuff).

Here is what I think we need to do - List down exactly what we want to
store. You have been a little ambiguous right now, so I don't really get
the entire picture. Nepomuk stores the data in terms of objects. This is
very similiar to OOP. Each object has properties which have types and so
on. We just need to know what all we're storing so that we can model it

3. Data Visualization -

This should ideally be completely independent of the gpx files. It should
be based on how we store location data. This is done so that there is no
direct correlation between GPX files and the data visualization.

Fortunately, for us, virtuoso (our database backend) supports geo location
natively. So we should be able to do quite elaborate queries.

I think we'll only get to this once we have figured out how to store the

> Thanks in advance for helping :)
> Anders
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk

Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120925/9be3ccd2/attachment.html>

More information about the Nepomuk mailing list