-
Notifications
You must be signed in to change notification settings - Fork 273
Association of all provided GPXEntry to the corresponding EdgeMatch #64
Comments
I believe this is (technically) happening - the points not used for matching are not included. @karussel is the intention that all GPXEntries (even those that are not used for matching) be associated with an edges? @Vannav, the reason for the filtering you referred to is directly from the published algorithm - e.g. if the GPS accuracy is 10m, but you've recorded points only one meter apart in your GPX entries, then it's assumed OK to ignore most of them as they don't provide much additional information (but do slow down the process a lot), and (I think) can cause problems (e.g. if you're sitting stationary at the lights, it may looks like you're moving back and forward - due to GPS measurements fluctuating - etc.) |
@Vannav can you elaborate why you 'need the internalEdgeId for every GPXEntry I have inputed'?
We should make this somehow happening to make post processing easier, maybe doing the matching first with only a few candidates and then doing an 'association step' for all GPXEntries in the range. |
Agreed. Shouldn't be too hard ... |
Hi @karussell and @kodonnell my main goal is to associate every gps point inputed with the matched way segments in OSM data for other tracking purposes. With the My current approach is to convert the resulted polyline to a osm way segment by querying for osm nodes which are epsilon-near the nodes of the polyline. Greetings |
This is kind of duplicate of #23 |
OK... I had a similar issue that might be solved. Something like (untested code):
I know that this solution is not very fast, but is it what would solve this issue (or is it incorrect, to inaccurate??)? If it is what's needed I can also send a PR :-) |
Since the work on completing this task is delayed, is there a possibility to separate the GPX point filter threshold from the map matching logic? ie instead of measurementErrorSigma for both GPX point filtering as well as map matching algorithm, add a new parameter such as "gpsFilterDistance". I need to snap the original GPX points but am unable to do this accurately and in a performant way. I've branched off master and made this change locally. Thanks, |
I've got another vote for Trang's suggestion - I've got some data with variable accuracy, so if I use a high "GPS accuracy" value, lots of good points get deleted (often too many to perform map-matching at all) and inaccurate points are kept. Then the map-matching attempts to route via the bad points, leading to a really bad fit Cheers, |
Please use our forum in the first place. Issues should be specific to bugs and features. |
I've updated comments here: https://discuss.graphhopper.com/t/map-matchresult-to-gpxentry/977/9. Pete you can add additional comments to that thread. |
Discussion: https://discuss.graphhopper.com/t/map-matchresult-to-gpxentry/977
This doesn't work since the rework of the matching algorithm in
doWork(List<GPXEntry> gpxList)
from the pull-request #49
The main reason for this is the filtering of GPXEntries by a distance threshold
distance(previousGPX, currentGPX) > 2 * measurementErrorSigma
which are never considered again in the the following resolvation of
MostLikelySequence
toEdgeMatch
The text was updated successfully, but these errors were encountered: