addy90
commented
2 years ago Hi @KrasnovPavel,
thank you for testing my tool thoroughly and for finding these bugs and problems!
I looked into it and think I could solve most issues.
Concerning the segmention fault: Unfortunately it is not easy to give a meaningful error message when the software is compiled for Release type with high compiler optimizations for this error as it is a memory access error that emits from the system. What I do is that I compile the software in Debug mode (CMAKE_RELEASE_TYPE) without any compiler optimizations and with debugging information. When I execute the software in this Debug mode, as soon as the segmention fault raises, the debugger halts execution directly at the line (breakpoint on errors) and with the stack trace being involved. As such, I immediately found the line of code that caused the problem, as you can see in my commit bbfecdf. I forgot a test for when no candidates are found. When you imported the wrong region with the given tracks, no candidates could be found for any track. In candidate adoption then this error raised because I forgot the mentioned test for when no candidates were found. I often only have the necessary tests for memory access patterns due to performance optimizations, for example I mostly don't use .at(index) but [index] for array access as I guarantee inbefore that access is allowed. Well except when I forget a necessary check as in this case. Problem solved, pushed and Docker images on DockerHub fixed, too! Thanks for finding this problem! Now the program runs and finds no result for all tracks, as it should be.
Second problem with your filtered.csv data, first thanks for providing the file and the command, this made it easy for me to review the setting!
The problem was that in your case you missed "" around the PROJ4 strings at network-transform-srs and tracks-srs setting, this way the parameter was not correctly parsed because of the spacebar inbetween. So you need the following command:
./map_matching_2 \
--network "/app/data/oberbayern-latest.osm.pbf" \
--network-transform-srs "+proj=utm +zone=32" \
--tracks "/app/data/filtered.csv" \
--tracks-srs "+proj=utm +zone=32" \
--delimiter " " \
--no-header --no-id --x 0 --y 1 \
--output "/app/data/f_matches.csv" \
--verboseYou got the segmention fault due to the same problem, no candidate was found which triggered the same error that I fixed above. Now with your old command the program runs but no result is given, as the projection was incorrect.
With the corrected command, I get the following result - the red track goes around multiple times unfortunately (by the way the orange policy arrows you get when you use --export-candidates option):
This is because the filtered.csv in fact is quite difficult to match and goes around that location several times, see here in blue the track that comes from the green points:
But nevertheless it works as you can see!
By the way, you don't need to filter spatially duplicate points, my tool does this automatically, see here in help.txt
Hope you can continue now with your setting! Concerning the orientation, maybe disabling the azimuth weight by setting it to 0.0 allows for this, without the azimuth into consideration but only lengths, direction changes (and distances maybe) it might work better in this case? Just an idea. I don't know if it really works.
Concerning the build under Windows. Unfortunately, as you have seen, it is not easily doable, which is the first reason. I have currently no plans for making the build under Windows natively possible. But you can build it with the Windows Subsystem for Linux (WSL). When you download for example the Ubuntu LTS Linux image, you can build the tool and run it from the WSL Shell with pointing to files under the mounted Windows folders. So it works under Windows over WSL. I tried this myself, which is the second reason why I currently have no plans for native Windows builds. Nevertheless thank you for informing me about vcpkg, maybe I will have time to look further into it.
In case you build it locally, you don't need -DINSTALL_ALL_SHARED_LIBS=ON in the cmake command. This is only for the Dockerfile because I use a build container and a run container that is smaller but misses the dependencies from the build container.
KrasnovPavel
Hello, again!
I took your first example from readme, launched it in docker:
and made mistake in it. I downloaded and used
oberbayern-latest.osm.pbfinstead ofoberfranken-latest.osm.pbf. So obviously it didn't work, but I expected some message like "Matches was not found" or something, but I've got just "Segmentation fault" message and exit.I fixed my mistake and everything worked correctly.
Now i want to test my data. I took track data from 4seasons dataset (it was collected near Munich) and add origin point (in UTM32) to all coordinates then rounded it to meters and exclude duplicates for faster matching. filtered.csv
I launched matcher:
I didn't expect good results since track is obviously wrong oriented but I again have segmentation fault message and don't know how to debug it. I checked with qgis that coordinates from
filtered.csvare laying insideoberbayern-latest.osm.pbf.Can you, please, make this message more informative? Thanks!
P.S. I tryed to compile your tool for windows and gave up. External dependencies just did not compile. Can you consider using vcpkg for managing them instead of cmake's fetch mechanism? At my expirience vcpkg works well enough for building windows, linux or crossplatform applications.