Slope calculation error about qgep HOT 7 CLOSED

So this is the suggestion for the new defintion of _slope_per_mill:
CASE WHEN rp_from.level > 0 AND rp_to.level > 0 THEN round((rp_from.level - rp_to.level)/ST_Length(progression_geometry)*1000,1) ELSE NULL END AS _slope_per_mill

• Does this work if progression _geometry is 2D
• Does this work if progression_geometry is 3D
• Is _slope_per_mill used elsewhere and how could this change influence it?

Any objections to this solution?

I added this topic to the agenda of the next technical meeting in December.
@spch-GL if you want to join please contact @ponceta for an invitation.

from qgep.

Thank you for this proposal, but I think that at least Denis Rouzaud can answer your questions about _slope_per_mill. And as I'm not really envolved in QGEP, I prefer not to participate

from qgep.

Your contribution is welcome.

Using actual 3D length should never result in higher slopes since 3D length can only be longer than the 2D length.

Could then be the length_effective calculation wrong?

WHEN rp_from.level > 0 AND rp_to.level > 0 THEN round((rp_from.level - rp_to.level)/re.length_effective*1000,1)

@spch-GL Denis does not take part to the technical group, but @olivierdalang can maybe bring the subject on your behalf?

from qgep.

Yes, 3D length can only be longer than 2D length. Thus, the slope resulting of its use is lower.

Yes, I'm sure @olivierdalang can do that

from qgep.

note: also look at #773 at the same time which also involves _slope_per_mill calculation

from qgep.

https://github.com/QGEP/datamodel/search?q=_slope_per_mill

• _slope_per_mill is actually used only in vw_qgep_reach
• work if progression _geometry is 2D
• work if progression_geometry is 3D

from qgep.

Fixed by QGEP/datamodel#195

from qgep.