search

root676 / QNEAT3

QNEAT3 - Qgis Network Analysis Toolbox 3
GNU General Public License v3.0
63 stars 12 forks source link

OD Matrix miscalculates time cost if network CRS does not use linear units of meters #36

Closed josephholler closed 1 year ago

josephholler commented 4 years ago

QNEAT3 does not correctly apply a unit conversion if the network layer uses a CRS with linear units other than meters for time-optimization. For example, one speed cost was calculated as 36 seconds in a network layer using meters, but once projected to a coordinate system using feet, the cost was calculated at 118 seconds -- incorrect by the same factor as the conversion from feet to meters.

It seems like the QGIS network builder is automatically converting linear units into meters using self.meter_to_unit_factor , so calling the speed strategy function with a speed conversion factor of unit_to_meter_factor * 1000.0 / 3600.0 is negating the unit conversion that has already been applied to distance. I'm making an educated guess here, since I can't find the code in the QGIS algorithms where the linear unit conversion happens, but clearly it happening for distance strategy and I assume that it must also be doing the same for speed strategy. In either cases, revising unit_to_meter_factor * 1000.0 / 3600.0 to 1000.0 / 3600.0 is fixing the bug.

josephholler commented 4 years ago

Correction/Addition: it seems like all linear units for distance or time calculations are calculated as meters for the network cost because the defaults in the QGIS network builder are to calculate distance with the WGS84 ellipsoid and the QNEAT3 plugin is using that default setting.

Entry and Exit costs are treated differently: there is currently an option to use planar or ellipsoidal calculations, and neither method ensures that linear units are calculated in meters if the input network layer CRS and/or project CRS use different linear units. This leads to inconsistent distance calculations between the network cost and entry/exit costs and incorrect calculations for CRSs using units other than meters.

It would be straightforward to force all entry/exit costs to use the same qgsDistanceArea calculator technique as the network graph to calculate distance in meters with WGS84 ellipsoidal calculations. I suggest removing the ellipsoidal/planar option from the algorithms because the network cost is already defaulting in all cases to WGS84 ellipsoidal distance in meters. Working on a pull request for this now...

tomrod commented 2 years ago

I can confirm I am having this issue as well. To reproduce:

I have a network that I run routemapping on the attached file of routes (geometry and id only provided here).

Details

Search at points:

Point Latitude Longitude
A -84.399238 34.009124
B -84.378275 34.033410

Items

Item Version
QGIS version 3.22.2-Białowieża
QNEAT3 version 1.04
Qt version 5.15.2
Python version 3.10.0
GDAL/OGR version 3.3.2
PROJ version 8.2.0
EPSG Registry database version v10.038 (2021-10-21)
GEOS version 3.9.2-CAPI-1.14.3
SQLite version 3.36.0
PDAL version 2.3.0
quick_map_services 0.19.27
LoadQSS 1.4.2
mmqgis 2021.9.10
ORStools 1.5.0
simplesvg 3.0.1
processing 2.12.99
db_manager 0.1.20
sagaprovider 2.12.99
MetaSearch 0.3.5
grassprovider 2.12.99

Distance appears correct (5820 m), used this site to confirm distances in meters.

Base parameters (not accounting for speed changes, testing 111 km/1 degree):

{ 'DEFAULT_DIRECTION' : 2, 'DEFAULT_SPEED' : 555, 'DIRECTION_FIELD' : '', 
'END_POINT' : '-84.378275,34.033410\n', 
'ENTRY_COST_CALCULATION_METHOD' : 0, 
'INPUT' : 'bug_lines.geojson', 
'OUTPUT' : 'TEMPORARY_OUTPUT', 'SPEED_FIELD' : '', 'START_POINT' : '-84.399238,34.009124\n', 'STRATEGY' : 1, 
'TOLERANCE' : 0, 'VALUE_BACKWARD' : '', 'VALUE_BOTH' : '', 'VALUE_FORWARD' : '' }

Distance: 5820.1376886 m

Default speeds tested Hours travel time Seconds travel time
5 0.0377 135.76
5*111 0.000546 1.967
5/111 4.178 15,042
5.820 0.0323 116.42

I tested the last (should be equal to 1) with powers of 10 applied to the speed to confirm the issue is linear. The value appears to be off by 30.9213 x power of 10, consistently.

Note: this only confirmed how far off this is between these points. I did not test alternate points (yet).

Image of path

image

tomrod commented 2 years ago

I checked a few other points and can confirm that the factor is approximately 30.92 off.

josephholler commented 2 years ago

It's true. You can find a resolution in this pull request: https://github.com/root676/QNEAT3/pull/37

root676 commented 1 year ago

Implemented in 1.0.5