Imported BRouter tracks have reset timestamp

Good day Libor,

because of three possible methods, how to get BRouter tracks into Locus, what exactly you mean? If you mean internal "call" ( like directly over "Navigate to" function ) of Locus to BRouter app, I may check it on my side. Otherwise may you please attach some exported GPX file? Thank you!

Hi Menion,

I have implictly thought that mentioning explicit GPX file exclude direct navigation via API call. I have mean GPX file generation by launching Brouter, selection of profiles and From and To point that the BRouter extracts from Locus waypoint. I suppose it will be the same ( but not checked ), if Brouter is called from Locus as an external application, after defining quick points "from" and "to". As the Brouter procedure should be the same, finally storing brouter0.gpx in Locus Mapitems folder.

I attached the zipped GPX, but it is quite big ( 11 min for experimental long distance car routing, 1500 km route length with nav hints ). I have additionally pasted a stripped file content, with left just the first and the last waypoints and trackpoints.

1. <?xml version="1.0" encoding="UTF-8"?>
2. <!-- track-length = 1517846 filtered ascend = 8331 plain-ascend = 593 cost=2259811 -->
3. <gpx
4. xmlns="http://www.topografix.com/GPX/1/1";
5. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
6. xmlns:locus="http://www.locusmap.eu";
7. xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd";
8. creator="BRouter-1.4.1" version="1.1">
9. <wpt lon="7.388143" lat="47.871812"><name>keep right</name><extensions><locus:rteDistance>515.0</locus:rteDistance><locus:rtePointAction>10</locus:rtePointAction></extensions></wpt>
10. <wpt lon="-5.578394" lat="42.596183"><name>Take exit 5</name><extensions><locus:rteDistance>260.0</locus:rteDistance><locus:rtePointAction>31</locus:rtePointAction></extensions></wpt>
11. <trk>
12. <name>brouter_Car-test-Template_0</name>
13. <extensions><locus:rteSimpleRoundabouts>1</locus:rteSimpleRoundabouts></extensions>
14. <trkseg>
15. <trkpt lon="7.396965" lat="47.777524"><ele>233.25</ele></trkpt>
16. <trkpt lon="-5.579106" lat="42.596109"><ele>826.25</ele></trkpt>
17. </trkseg>
18. </trk>
19. </gpx>

Poutnik, be reasonable - something smaller - just few km through the city.

Thank you, this helped. Issue was generally in import of track, that has absolutely no time anywhere. By default, Locus set current time as "created time" when such track is imported, so issue fixed. Thanks

Hmmm, but was not better the file modified time then import time ? Because if the track is inspected by Locus in MapItems, it does provide the timestamp.

As it may happen the file is created long time before the import, depending on the file origin. E.g. if one has an archive of GPX files, or if file is downloaded.

Or I have got you wrong...

To be true, from my point of view, only correct time in this case is "no time" as we really do not know correct time when track was created. Anyway Locus needs some time to be set for now, so because of this, I rather used time when you import track into Locus database from whatever place - file, email, remote Url - this all gives same results - current time when track was imported, so it's consistent.

If you want improve just these tracks from BRouter, I suggest to request this tiny improvement on BRouter Google Group as it's few lines of code to insert current timestamp when file is generated.

Well, the real time of file creation is modified time, or time sonner. If modified time is wrong, current time is wrong even more :-D

But I agree it is just a minor nitpicking from me, current solution is much better than status before. I am fine with current solution.

I agree about the Brouter forum - I did so now.

I have just had in mind general case. Timeless files can come from other origins as well.