Project

General

Profile

Improvement #6313

Additional Border Modes in u and v directions

Added by John Griffin 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Urgent
Category:
ALL-APIs
Target version:
Start date:
20.07.2017
Due date:
% Done:

0%


Description

I have a customer that uses openCRG extensively to represent a banked road surface (i.e., a race track). They would like to be able to specify different border modes for the -v/+v sides of the center line. I.e., they would like a flat section or 'hold' on the left (-v) side of the track and an option to linearly extrapolate on the right (+v) side of the track.

Therefore two things are required +/- specific border modes for v and a new option to linearly extrapolate.

History

#1 Updated by Marius Dupuis 3 months ago

  • Assignee set to Bernhard Bieder

How "urgent" is it? It's quite a substantial change and will need harmonization with a couple of parties.

#2 Updated by Skip Essma 3 months ago

This is TRD's highest priority item regarding OpenCRG implementation. Our simulation driver model can deviate from the prescribed path beyond the range of measured road data. The extrapolation would help us in many instances.

#3 Updated by Jochen Rauh 3 months ago

Could you please describe what linear extrapolation would be?
Linear extrapolation of measured data (gradient defined by the outmost two points) would result in not very useful surfaces in the extrapolated area.
Also handling of missing measurments represented by NaNs would rise further questions.
So I suggest to modify the crg files themselves according to your specific requirements.

#4 Updated by John Griffin 3 months ago

Jochen Rauh wrote:

Could you please describe what linear extrapolation would be?

Linear extrapolation of measured data (gradient defined by the outmost two points) would result in not very useful surfaces in the extrapolated area.

Linear extrapolation would be the last two points. And yes, with some data the linear extrapolation may not be useful. But, in other instances it would be useful and adequate to extend the surface beyond the provided data. In situations where the span/distance between two v points is much more than the change in z-height for those two points, linear extrapolation would work fine. In other cases, such as a belgium block road, linear extrapolation would result in 'not very useful surfaces'. But, the user has to take some responsibility. It also doesn't seem like it would be very difficult to produce a warning if the extrapolation results in a surface with a very steep slope.

Also handling of missing measurments represented by NaNs would rise further questions.

How are NaNs handled when you HOLD the last data point? Couldn't they be handled in a similar manner?

So I suggest to modify the crg files themselves according to your specific requirements.

Possibly. But, why not add some helper routines?

-- The most critical point of this ticket/request is additional border modes. The linear extrapolation is a lower priority, and more manageable.

Also available in: Atom PDF