Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default topology tolerance to 0.000001 #34

Open
josephholler opened this issue Jul 6, 2020 · 1 comment
Open

Change default topology tolerance to 0.000001 #34

josephholler opened this issue Jul 6, 2020 · 1 comment

Comments

@josephholler
Copy link

josephholler commented Jul 6, 2020

I'm attaching a very simple example geopackage with a layer, roads to be used as a network and another layer, parks to be used as start points for creating Iso-Areas. qneat3test.zip
Specifically, I'm running Iso-Area as Pointcloud (From Layer) with distance optimization of just 500 meters to test. I originally digitized this data with snapping enabled and densified the line geometries such that some start points are exactly coincident with vertices in the road network-- or at least coincident within the margin of error of precision with which the coordinates are stored.
The crazy thing is that without modelling one-way travel, the park with ParkName FC only has an iso-area going one direction on the road. However, if I change the topology tolerance to 0.000001 from 0.000000, it works just fine. That's just a fraction of a millimeter, so I'm confused as to why this makes a difference.
I can only guess that something is going awry in adding a start point to the network if the start point is coincident with an existing vertex. The same thing happens with the QGIS algorithm Service Area (From Layer), so the root of the problem is probably in the QGIS code.
I can't attribute this to an error with the network data, because the startpoint in question is in the middle of a line feature. In other words, it's clearly not a failure of one line to connect to another in the network due to digitizing errors.
Either way, an extremely small tolerance of less than 1 millimeter apparently fixes the problem, so could this be the default?

@root676
Copy link
Owner

root676 commented Jul 11, 2020

I have never encountered this problem but I am glad you found a way around - we can definitely change the default value of the tolerance parameter as you proposed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants