-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for GPX #14
Comments
I was playing with timbl's sed program. From this gpx example (taken from Wikipedia):
it generates this Turtle file:
If you want to try timbl's converter with other files, you need sed and you can run it with
One problem is that it is only converting track points and ignores other GPX contents. For example, if you try it with another example that contains only way points, it just generates the following:
|
Someone seems to already been working on the sed script, but I couldn't avoid to look into it. I've changed it a bit so it also processes waypoints, and on the way noticed several circumstances that look relevant for our purposes. First, the new script:
I made it so extensions are deleted and waypoints are processed similarly to trackpoints in the original version. Also, I removed the creation of temporary octothorpes as markers for new lines, since this only worked of a specific line distribution and identation. The original looked like designed for a specific formatting that would probably not work if the line distribution was different: it deletes all lines containing speed or course information, for example. My version does not solve this perfectly, either. Lines are very important to sed because of its nature of Stream EDitor. Also, the closing is substituted by a line containing a dot, probably for processing in Unix streams, so we might not want that either. Identation of the final text is probably not important for us if it will just be part of the processing of source .gpx files. Maybe too much information for a specific topic, but I would like to see discussion about whether to stick to sed to process input .gpx files, which would be trivial to set up on the host machines, or to start working on another approach. |
@InigoGutierrez I've been working with timbl's sed converter, and I found your new script very interesting. Nevertheless, I don't know if this is the best option we can follow to get the maximum information. To show you an example, as I explained in this issue, I have taken a GPX file downloaded from Strava, which allows their users to get the routes they make very easily. The GPX file (shortened) is this one:
With timbl's
Now, with your new sed converter:
My point is, with your proposed converter I obtain more information like the route's name, but I think there are more problems, especially regarding that Also, I think this new idea presented by Labra is actually a very good option, using a ShEx schema instead. |
There are several approaches to convert XML to RDF.
For the third approach, I have created a GPX2RDF converter using XSLT. It is available at viadeSpec/converters/gpx2rdf.xslt. The XSLT transformation could also be embedded and invoked from a high-level programming language using some XSLT libraries that are available or it can be invoked If you want to try it on the command line, you need an XSLT processor. Using xsltproc, for example, you can convert it as:
The result is in RDF/XML format which can easily be converted to Turtle or JSON-LD using RDFShape. |
What we need is a tool that parses an input file and generates another, instead of making arbitrary changes in the original text. These scripts take the second approach, and that's why some original lines are kept and a lot of minutia factors must be taken into account. XSLT looks better.
Don't we yet need a way of converting them? A ShEx Schema is just the specification of the target file we need to generate from the source GPX file. Either way, the actual conversion mechanism is not necessary to be defined by the specification. |
Yes, I didn't mean that we can use ShEx to do it. As you say, the conversion mechanism is not necessary for the specification. Anyway, I think the new approach that Labra has mentioned, of using his new GPX2RDF converter, is very promising. |
@timbl has suggested to include support for GPX as it is a popular format supported by lots of devices. In order to do that there are several possibilities to consider:
Create an RDF-based representation of the GPX format. I think the latest (1.1) specification is defined here. One possibility which doesn't seem difficult is to represent that spec using ShEx.
Another possibility could be to translate a subset of the GPX format to Turtle. That's the approach followd by this sed program.
Finally, another possibility could be to include the raw GPX file as the value in a Turtle file that represents the routes and increasingly add more metadata to it. The solution could be to start with something like:
The text was updated successfully, but these errors were encountered: