Unable to perform python fmm_test.py on Win10 Home (64bit) with cygwin environment

[lolbus]

Note
This issue is based on the latest repo

Describe the bug
I followed the entire installation procedure based on this page:
https://fmm-wiki.github.io/docs/installation/windows.html

Took me awhile to setup everything.
Was able to run fmm in the cygwin terminal:

However when I run on python fmm_test.py to perform verify python binding:

Traceback (most recent call last): File "/home/guang/fmm6128/fmm/example/python/fmm_test.py", line 1, in <module> from fmm import Network,NetworkGraph,STMATCH,STMATCHConfig File "/usr/lib/python3.9/site-packages/fmm.py", line 15, in <module> import _fmm ImportError: dynamic module does not define module export function (PyInit__fmm)

Also notice the example test python script has some python syntax error which should be print():
print type(result)
print "Opath ",list(result.opath)
print "Cpath ",list(result.cpath)

Installation guide mentioned:

It(The make install process) will also create a folder python under the build path, which contains fmm bindings (fmm.py and _fmm.so) that are installed into Python site-packages location (e.g., /usr/lib/python2.7/dist-packages).

However for my case my _fmm.so is missing both in the build python folder and my python site packages location. My python site-packages location is also different, at

C:\cygwin64\lib\python3.9\site-packages

Expected behavior
All the above should not be present and I should be able to run my map matching by now.

Work on this as one of my official school assignment, deadline end nov 22..
Really appreciate your help soon.

TQ!

[lolbus]

In another variation of issue while trying to verify python binding:

I setup with the above using a different python interpreter (2.7)
and got this error:

what exactly is proj.db? Is it a missing file? Can anyone provide it

I was able to run the code but has other error. I realise that the original fmm_test code requires me to input a data edges file, so i extract the one provided by the latest repo in osmnx_example\stockholm. Doesnt work. But this time I get different error commenting on the fields of the data:

What causes the error?
Is my python binding unsuccessful or is it because those data files (network graph) from the stockholm folder isnt the correct input.
Pls help

[lolbus]

Also are the provided data input really GPS produced WGS84 data? The one provided by the test code given below
wkt = "LINESTRING(0.200812146892656 2.14088983050848,1.44262005649717 2.14879943502825,3.06408898305084 2.16066384180791,3.06408898305084 2.7103813559322,3.70872175141242 2.97930790960452,4.11606638418078 2.62337570621469)"

What are these X and Y points referring to? documentation mentioned they are x, y (longitude / latitude)

Searching for these points at the google map ends up being some where in the middle of the sea near Africa ..

[cyang-kth]

• The proj.db is some file distributed with gdal. You may have to provide the path to GDAL directory to find that file. You can google for the solutions.
• The example XY coordinates are dummy values just for illustration of the problem.
• The cygwin environment on win may encounter lots of issues especially if you want to also use the python API. It is strongly recommended to test the program in Unix environment such as Ubuntu.

[lolbus]

Hi,

Thanks so much for clarification!

So far I have managed to run map matching by ignoring the proj.db error in cygwin environment.
Will that affect my map matching output?

It appears that the only persisting problem right now is that generating an UBODT precomputation file takes very long time. (About 5 hours for a network graph of 50000 nodes and 70000 edges)
Is that normal? In the paper, you mentioned that it only took a few seconds to generate an UBODT of millows of rows with a slightly smaller road network graph.

Should I rerun everything with C++ fmm commands in the terminal?

Thanks!

[cyang-kth]

There should be little difference in terms of cpp or python call.

Check this link for unit problem

• Summary of common issues about fmm #138 (comment)

[lolbus]

Hi thanks so much for quick response!

Yes I have check the unit problem. Im indeed using longitude latitude based WSG84 data points and network. The spatial points are described in degrees.

This is the code I ran with

from fmm import FastMapMatch,Network,NetworkGraph,UBODTGenAlgorithm,UBODT,FastMapMatchConfig
network_name = "porto_whole1"
Dir = "C:/cygwin64_3/home/guang/fmm/fmm/example/osmnx_example/" + network_name + "/"
network = Network(Dir+"edges.shp","fid","u","v")
print "Nodes {} edges {}".format(network.get_node_count(),network.get_edge_count())
graph = NetworkGraph(network)



# Can be skipped if you already generated an ubodt file
ubodt_gen = UBODTGenAlgorithm(network,graph)
status = ubodt_gen.generate_ubodt(Dir+"ubodt.txt", 0.03, binary=False, use_omp=True)
print status

### Read UBODT
ubodt = UBODT.read_ubodt_csv(Dir+"ubodt.txt")
### Create FMM model
fmm_model = FastMapMatch(network,graph,ubodt)


k = 8
radius = 0.003
gps_error = 0.0005
fmm_config = FastMapMatchConfig(k,radius,gps_error)


#RUN MAP MATCH

wkt = "LINESTRING(-8.618643 41.141412,-8.618499 41.141376,-8.620326 41.14251,-8.622153 41.143815,-8.623953 41.144373,-8.62668 41.144778,-8.627373 41.144697,-8.630226 41.14521,-8.632746 41.14692,-8.631738 41.148225,-8.629938 41.150385,-8.62911 41.151213,-8.629128 41.15124,-8.628786 41.152203,-8.628687 41.152374,-8.628759 41.152518,-8.630838 41.15268,-8.632323 41.153022,-8.631144 41.154489,-8.630829 41.154507,-8.630829 41.154516,-8.630829 41.154498,-8.630838 41.154489)"
result = fmm_model.match_wkt(wkt,fmm_config)

### Print map matching result
print "Opath ",list(result.opath)
print "Cpath ",list(result.cpath)
print "WKT ",result.mgeom.export_wkt()

from fmm import GPSConfig,ResultConfig

# Define input data configuration
input_config = GPSConfig()
input_config.file = Dir+"trips_time.txt"
input_config.id = "id"
input_config.GPS_point = True
print input_config.to_string()

# Define output configuration
result_config = ResultConfig()
result_config.file = Dir+ network_name + "_output.txt"
result_config.output_config.write_opath = True
print result_config.to_string()

status = fmm_model.match_gps_file(input_config, result_config, fmm_config, use_omp = True)
print status

`

Following the installation guide provided,
I believe all the units are setup correctly as my map matching duration was acceptable. (About 1 hour to handle 1000 GPS trajectory data)

Were you really able to produce an UBODT file within couple seconds for the entire network graph?

[cyang-kth]

I am not sure if the performance degrade could be the win environment. You can try to reduce delta to 0.01 to check or try the stmatch model which does not require the UBODT precomputation (the stmatch could be slower than FMM in map matching but it does not need precomputation).

[lolbus]

I think it might be due to the fact I'm using cygwin environment. Its good to know it is possible to confirm the precomputation of UBODT is indeed a few seconds task if every thing is done correctly. I kept thinking its the flaws of the FMM algorithm. In the future if I have a related assignment that involves using the tool kit, I'd definitely prepare a ubuntu system beforehand.

Anyway I have managed to the run the mapmatching successfully, just need to be a little patience generating ubodt. I'm test running now as we speak. Cant confirm why, but seems like its running well.

Anyway really appreciate your advice

[lolbus]

I am not sure if the performance degrade could be the win environment. You can try to reduce delta to 0.01 to check or try the stmatch model which does not require the UBODT precomputation (the stmatch could be slower than FMM in map matching but it does not need precomputation).

I can confirm that the Window's cygwin environment taught by the installation page, heavily limits the computing resource and there dont seems to be any proper way to lift the restriction.

Using an Ubuntu system fix all the problems I mentioned earlier.

I'd suggest the Windows installation page to be updated and/or discouraged for use