gpx attributes lost after map matching #23
Comments
|
Do you have example(s) to reproduce this? |
|
Yes e.g. my input files is looking something like this: and my output file is missing all properties expect the updated lat, lon, and time |
|
If I have something reproducable in a unit test or the full file where you really see the problem, chances are higher that I can faster fix it :) |
|
Just going to post my input gpx and output gpx, i'm going to add some details on how to reproduce later. (Actually i did just follow the instructions in the readme) Input gpx (=before.gpx) Output (=before.gpx.res.gpx) |
|
Ah, okay. Yes, this would be nice to have and should not be hard to implement - maybe you give it a try? |
|
This is not an easy problem since multiple input points might be processed to produce a single output point or no input points at all have been used to produce a single output point. So you need to make a decision which input point meta information you want to reuse on a single output point. Perhaps a generic approach should be to provide some kind of configurable hook, that allows to reattach meta-information. |
|
There is already the concept of 'EdgeMatch' where one can set a list of GPXExtensions where one of them is a GPXEntry and a queryResult but others could be added there as well if one has the input data. Surely we should provide such a simple hook. |
|
Is there any progress on this issue? |
We do not work on this yet.
See the duplicate/related issue #64 |
|
Similarly this would be nice if such a relationship is created for the new path details feature |
|
Will you solve this issue? I encounter the same problem, I want to keep timestamp in output gpx files, at least for those origin points. |
|
Okay, let's do this. Problem 1 (data processing): Problem 2 (semantics): Input: Track (sequence of (x,y,t))
a) it could work differently. I'm not sure any notion of snapping is definitive for map-matching. Especially b) I'm not sure how to deal with.
As @leoroos was saying, how would we "embed" the "snapped" input points there? In the So we would have to mix snapped original points and extra points. But then there's a new problem: The Route that we calculate has its own idea of how fast it is, and we currently put that information in the output. If we would, say, keep the timestamps of the input points and insert time-less extra points in between, that information would be gone. (It would still be in the Maybe that's the solution to that part of the problem: We make the *) In the GPX API. The library function underneath, and the alternative output formats, work somewhat differently. |
That, at least, is fixed. |
This information does not show for me in the output, is there a way to enable this? Thank you (I'm using commit 8e0cd26c88bdca96428f015a0e6daf33f72a3e5c ) |
After running the map matching algorithm on an input gpx file, the output gpx file is missing all other attributes such as
<desc></desc>or<link></link>The text was updated successfully, but these errors were encountered: