You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.zipSpecifically, 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 to0.000001
from0.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?
The text was updated successfully, but these errors were encountered: