Question about the project domain in `cartesian_point_inside_projection_domain`

[GilgameshD]

Hi,

I am using this package to convert cartesian coordinates to curvilinear coordinates. However, I am a little confused about the definition of the project domain. I randomly sample points in cartesian and use cartesian_point_inside_projection_domain to check if it belong to the project domain. I got the following result.

The black line is my reference line and the red points are in the project domain. It seems the domain is not symmetric to the reference line. Could you elaborate more about the definition of the project domain?

Thanks.

[geraldfw]

Hi @GilgameshD ,

thanks for your post and excuse the late reply; I missed the posts here recently.
The projection domain is the area which can be uniquely transformed from Cartesian to Curvilinear and vice-verse. For instance, a curve with a tight bend (as in your example) may lead to regions which can not be transformed uniquely if they exceed the radius of the oscullating circle. That's why, in your case, the domain is limited on the inner side of the curve.

However, in our current version, the projection domain check leads to problems sometimes. We are currently working on a revised version of the curvilinear coordinate system (which will be an own package and not part of the commonroad-drivbaility-checker anymore). In this version we have made some improvements, and also allow the user to deactivate the projection domain check. We will probably publish it on Github within the next week, I will notify you again.

Best,
Gerald

[GilgameshD]

Hi @geraldfw,

Thanks for your reply! My observation is that even though the reference line is straight, the region is still limited to one side of the line. But I am looking forward to the new package! It would be very useful to have a standalone package of curvilinear system instead of installing the entire commonroad package.

Best,

[geraldfw]

Hi @GilgameshD ,

hm, that's strange. I could imagine that there is perhaps an issue with the reference path itself. Some issues which come to my mind:

1. Duplicate vertices in the reference path
   -> Fix: np.unique(ref_path, axis=0)

2. points in the polyline are not ordered correctly: Figuratively speaking, there are points in between where the reference path "reverses" its direction, but one can't see that visually. This can lead to high changes of the orientation angle and thus to downstream problems of the curvilinear frame. You could plot the orientation (see e.g., here) and check if the orientation angle changes its sign very suddenly
   -> Fix: remove wrong points which produce a wrong ordering

3. high curvature values: if the straight line is sampled very densely, minor deviations of the points (due to numerical inaccuracies) can lead to high values of the discrete curvature. You could plot the curvature (like to here) and check if the curvature is very "noisy".
   -> Fix: Smooth the reference path e.g., using cubic splines or other methods (-> let me know if I should send you some code for that)

In the new package, we have added multiple methods to pre-process the reference path, since we noticed that these problems occur frequently, so I hope this would solve some issues then :)

Best, Gerald

[GilgameshD]

That makes sense. I guess the reason is that points are too dense and the curvature is high. I observed that with some reference lines the domain is almost correct and with others, it is totally on one side of the line.