spatial_resolution not working correctly?

[ahermanski]

sao_gps <- gtfs2gps("sao_small.zip", progress = FALSE, parallel = FALSE, spatial_resolution = 250)

head(sao_gps)

Gives me this output which has a much higher spatial resolution than I specified but is different than what the standard setting is, so the parameter has to work at least partially.

   stop_sequence      dist    cumdist      speed  cumtime shape_id
1:             1  7.230445   7.230445  0.7601079 34.24462    51338
2:             2 18.369274  25.599720 24.6817359 36.92390    51338
3:            NA 69.011930  94.611650 24.6817359 46.98976    51338
4:            NA 72.957552 167.569201 24.6817359 57.63112    51338
5:            NA 28.558579 196.127780 24.6817359 61.79659    51338
6:            NA 70.219059 266.346839 24.6817359 72.03852    51338

[rafapereirabr]

Thanks for your comment, @ahermanski. Indeed, this is an issue we noticed before. We are still trying to fix this. I suspect this difference might be caused in part by the fact that the function currently calculates distances in projected shapes with lat log coordinates, so it's not 100% precise. I'm not sure we could improve this by using a utm projection inside the function, @pedro-andrade-inpe . What do you think?

In any case, mind you that the difference between spatial_resolution and the distance between id nodes will never come down to zero. This difference will occur when roads have curves with sharp angles.

[pedro-andrade-inpe]

Hello @ahermanski. In fact, the current version of the function does what is written in its documentation:

This function creates additional points in order to guarantee that two points in a same
trip  will have at most a given distance, indicated as a spatial resolution

It does not yet remove points, only adds. If the, let's say, resolution of the original data is already below spatial_resolution then it will return the same set of points. This was a somewhat strong assumption that we needed to take in order to guarantee processing speed and keep the corners. @rafapereirabr, this behaviour is due to the call to sf::st_segmentize().

@rafapereirabr, we have an older version of the algorithm that does something similar, but (i) it uses a temporal resolution, instead of a spatial resolution, (ii) it is slower (I dont' know how much), and (iii) it does not guarantee corners. We can also think in other solutions.

[rafapereirabr]

I believe this issue is clarified in the package documentation so we can close this issue.