Closed slackline closed 4 years ago
Unfortunately, this is not possible at the moment.
BTW, Why do you need this? 2020-01-05T07:11:05Z
is a perfectly valid name even without CNAME
.
@tkrajina thanks for taking the time to look at this.
I'm trying to convert tcx files dumped by endomondo.com to gpx for importing to OpenTracks.
I exported a gpx from OpenTracks to check what fields are included and it had...
<metadata>
<name><![CDATA[2019-12-24 08:36]]></name>
<desc><![CDATA[]]></desc>
</metadata>
<trk>
<name><![CDATA[2019-12-24 08:36]]></name>
<desc><![CDATA[]]></desc>
<type><![CDATA[biking]]></type>
<extensions><topografix:color>c0c0c0</topografix:color></extensions>
<trkseg>
...so I was trying to output the tcx in the exact same format.
I hadn't checked whether I had to have the fields exactly but have now tried importing a converted tcx file with the fields as text rather than CDATA
and can successfully import a converted gpx.
I've another issue with writing an .extensions
field but thats minor (it just dictates the colour the track is plotted when opened on a map), but it basically works now which I'm happy about.
My very crude package is here, still need to write some tests for it (can not get my head around Test Driven Development!).
Thanks again for your time.
I'm trying to convert tcx files to gpx and have found
gpxpy
incredibly useful, however I've encountered a problem when trying to write CDATA. I'm not entirely sure whether its an issue withgpxpy
or not, but thought I'd report it here in case it is.A self-contained example is...
Which results in...
I was expecting the following to be written...
I had originally tried writing the CDATA explicitly as in...
...but when printing this results in...
I found the suggestion of using
lxml.etree.CDATA()
here, is this the wrong approach to be taking perhaps?I'm using...