@carlos_m_gil_p wrote:
....
Modify the line that you indicated to me.
The result is 28 vertices in this example....
I think that must be because of the segments in the original Polyline that are very short compared to the overall length. It give the correct number of vertices for me on a Polyline that does not have such short segments, and it works without making that correction. I have not explored it in great detail, and I am not acquainted with some of the functions it uses, but I think this is what it does:
1) Finds the overall length of the Polyline.
2) Divides that by the number of segments it will have with the requested number of vertices, to find the average length of a segment in the end result.
3) Calculates how many of those fit into each initial segment, rounding to the nearest integer, to determine how many new segments that initial segment should be divided into in the end result. [For any initial segments that are very short, it will be 1, meaning don't add any vertices within that segment.]
4) Adds vertices within each segment that's long enough to need it, to get that many smaller segments within it.
What I think it needs to do before step 4) above is:
3A) Add up the total number of new segments it calculated for each initial segment. Those that are too short add 1 to this, even though they do not add vertices -- that is where I think the problem is.
3B) If that total is more than the end result should have, reduce the number of segments somewhere, for the correct total. The too-short segments mean that the average new segment length, within segments that do get subdivided, needs to be longer than the length calculated by dividing the overall length into the right number of segments.
In your example, it would obviously be the longest segment that should be divided into fewer segments than the original calculation for it. But in some cases, it may be better to adjust the subdivision of more than one initial segment. It may not be easy to find a way to do that, or to decide whether that should be done.
I think I will leave it to @marko_ribar to further alter his code, since he understands better than I do how it works. It could be that the calculation that results in 0 for a short segment, which I suggested a correction to, needs to be kept with its zero result for purposes of adding up how many new segments each initial segment gets divided into, with a separate variable of some kind used in a different calculation to avoid the divide-by-zero error.
Or maybe all initial segments should be evaluated for length first, and only the lengths of those that are long enough to need new vertices within them should be included in the calculation of the overall length to be divided, and therefore of the average new segment length to divide them into.
Kent Cooper, AIA