Hybrid parallel

[dexus]

Nice test @PGia, thanks!

For some reason I didnt consider closed polylines in the _checkOffset function, so I added an extra check there.

Should work as expected now:

 

Not sure about the short corner. The lines are so narrow the centerline is pushed back out of the point.

Seems to be logical to me but it does feel intuitive.

 

Narrow indents don't get much love from the centerline. So "inlets" don't have enough influence on the shape of the line.

What would the expected result be? Below makes sense since there is not enough space to go into the indent.

Or are you maybe something like this where the line splits and goes into the hole:

 

Edited December 4 by dexus

[dexus]

I did some more tests today and found that when the end segments were parallel, they didn't get added to the line.

So I added support for that. This one was easy because the _cornerOffset function already checks for parallel segments and I just had to add a flag to inform the offset loop. 

 

 

And I found another example which it has a hard time on with concentric arcs, attached below.

But that will be for another day since I have no more time for that this week.

 

AxisExple3.dxf

Edited December 5 by dexus

[PGia]

I think the real-world situation may be more complex than what we’ve seen here so far.

I took a look at the links that @SLW210 attached and decided to test the Lisp codes proposed up to this point.

I looked through my drawings for something that could serve as an example for this problem, but it was like looking for a needle in a haystack.
So, in the end, I decided to look for something in the real world that clearly corresponds to this issue — something like this:

 

So I drew those margins and tested all the codes that have appeared in this thread so far.
The result was… this!

 

In the drawing, you can see the ones that managed to reach the end.
However, the codes by BIGAL, GP_, GLAVCVS, and MarkoRibar couldn't even do that.

Here’s the drawing

AxisExple4.dwg

 

Edited Monday at 06:44 PM by PGia

[dexus]

Hi @PGia, wow, you managed to find another example that fails. Good stress testing!

 

The reason mine fails is because it ignores the offset lines that are split in two or more parts.

But some of the parts are still be usable and should be used.

I looked into fixing this and managed to add those lines, but this resulted in some other problems so I didn't update the code on the earlier post yet.

 

The zigzag problem is coming back on your example. The result below.

I really need to find a solution for that, but it looks like I might have to use a path finding algorithm which would slow down the code a lot. Sorting the points by distance on the offset line is not enough anymore.

[SLW210]

IIRC, those are tough to manage on GIS programs with Add-ons made with Python, .NET, etc.

 

Remember, real rivers/roads/ROWs have curves and organic shapes, not just straight lines.

 

I did see some information on how to tackle those, hopefully it can be worked out, but don't expect perfection.

 

As I mentioned, from what my daughter said and what I've seen in various related forums, the GIS pros are using whatever program and add-ons they can to get the bulk of it and cleaning up and filling in manually.

 

Most that are doing those shapes want the main channel center, if needed I would ignore the very wide sections and side pieces and get those as center lines running back to the main channel separately.

 

As your example shows, it would take separate polylines, so it will need to account for those sections and then ran again on the offshoots.

 

You still haven't answered all of the questions asked.

 

What type of work are you doing? What you have posted looks to be Civil and/or GIS work.

 

I'll try some more on this when I can, I have also looked at some different shortest path codes, the last example is way over my head in LISP, I'll concentrate on the previous examples then try to run just the main channel on the last example .dwg.

 

I have a full slate at work again today, but I'll try to jump back on this when I get some things out of the way.

 

Home time is limited, but I'll try to get back on this with QGIS solution, I may see if my daughter's coworkers want to take a shot at these.

[BIGAL]

I think with those big side offshoots you need to break the river into multiple plines so you would have two or more centrelines lines in that situation. As suggested by @SLW210 The problem will be how to work out the break offset shape..

 

 

Ps image dummied up.

Edited Tuesday at 11:04 PM by BIGAL

[PGia]

On 12/9/2025 at 1:37 PM, SLW210 said:

 

You still haven't answered all of the questions asked.

 

What type of work are you doing? What you have posted looks to be Civil and/or GIS work.

 

 

In general, we work with plans for projects of various kinds: engineering, cadastral mapping, and so on. Sometimes we submit proposals for public tenders, but so far without success.

@dexus, the performance of your code looks different in that last drawing compared to what I’m seeing on my end.

In any case, I think this topic has now entered the realm of a real challenge.
@BIGAL: I agree. I think that’s the correct way to draw the centerline in the inlets.

[GLAVCVS]

Obviously, this has now become something more than just the search for a solution to a single user’s problem.

First of all, I should say that I myself was also reluctant to accept the concept of equidistance advocated by @GP_ and @dexus
For the simple reason that applying this principle forced me to accept that the centerline should be the same in these two drawings.

Equidistance requires ignoring those areas of the margins that do not geometrically affect the axis.
This, which initially caused me some resistance, I eventually came to accept conceptually when I realized that it could serve as a criterion for defining what is a “recodo/inlet” and what is not.
So I have abandoned my previous approach and adapted it to this new situation.

Having made this clarification, I must say that this concept of equidistance makes the calculation of a centerline more feasible.

 

I’ve been running some tests with Dexus’s latest code, which is the best so far.
However, I’ve discovered some “holes” that I hadn’t noticed before.
I’m attaching a few images showing this.

In my view, these are conceptual errors rather than geometric limitations.
And what can we consider “geometric limitations”?
I believe that, in any case, every vertex of the centerline must be equidistant from both margins.
If this is not the case, the result is not correct.

However, the intermediate regions along each segment may be subject to geometric limitations depending on the desired precision.
Therefore, in bends or turns, the points taken within the adjustment or “problematic” segments may deviate (within a tolerance) from strict equidistance.

The goal, therefore (in my opinion), should be to achieve equidistance at every vertex and to remain within a tolerance in the intermediate zone of each segment.

After everything written here so far, some might wonder: is it really possible to obtain a centerline that meets these requirements?

As far as I’m concerned, I’m running some tests.

 

I’ll post something over the weekend