Possible to improve results by modifying geoJSON?

[PeterDolanNOLA]

I'm working on a project where I'm creating routes based on the city's geoJSON bike lane data. So far it works pretty well, except sometimes small loops are created. I'd assumed this was because of the distance between each of the points in the data set. I've been experimenting with ways that I can improve results by modifying the data set, but have begun to question my understanding of the pathfinding algorithm because that has produced even stranger results.

I'm working on the assumption that the denser the coordinates the better. Is this a misconception? I iterated through my dataset and added a midpoint between each coordinate using the Turf midpoint helper function, but the results actually seem worse. I also seem to get a different path each time for the same destination. I think the primary issue is that the bike lane system is pretty sparse, so I'm trying to strategize ways to modify the dataset to optimize results.
Thanks!

[perliedman]

Hi!

It depends on what you mean by dense and sparse - the module works by snapping coordinates close to each other, so if you have multiple vertices that are very close , the results might be confusing (the default tolerance is 1e-5 which in practice means something like a couple of meters IIRC).

An important point is also that two crossing segments must share a common vertice (coordinates must be within the tolerance), otherwise you can't turn from one segment to the other.

It is hard to say what the problem might be without seeing the results, though.

The path finding itself is a common Dijkstra's shortest path, so not much interesting going on there, as long as the network itself is properly setup.

[PeterDolanNOLA]

Thanks for the thoughtful reply! I suppose by making it more dense I mean increasing the frequency of coordinates within each LineString to make it so the points from two LineStrings are close enough together to be considered an intersection. I'm considering a different approach using the Turf lineIntersect function to find the intersection coordinates and make sure each LineString includes those exact points.

This is a pretty extreme example of what I'm talking about where the path goes in the wrong direction then turns around. One thing that may be of note is that there is a separate LineString for each side of the street.

Probably the easiest way to show what I'm working with data-wise is to link to the dataset which includes a visualization of the network: https://portal-nolagis.opendata.arcgis.com/datasets/d05f7edde0fe4319b2f0f2eba258a767_0

I also realized part of the issue was that some of these LineStrings do not actually intersect and some of them are even floating off on their own unconnected to anything, so I'm creating connecting routes for those areas.

I'm thinking that I may be able to avoid the parts where it goes off in the wrong direction by adding to the weight function to make it more akin to the A* algorithm. But truth be told, this is uncharted territory for me, so I may be drawing some off base conclusions. Anyways, thanks for your help!

Peter

[lmdc45]

Personally I add to 'densify' the linestrings geojson by adding points every 2.5 meters. This works well then with default tolerance, however makes a pretty big file for the browser to work with