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

[josephholler]

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]

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]

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

[tomrod]

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

[josephholler]

It's true. You can find a resolution in this pull request: #37

[root676]

Implemented in 1.0.5