problem with continous polyline! It needs to break and put vertexes on top of each other

[t_pladet]

Hello everyone,

as you guys maybe can see the Land surveyer made mistakes with measuring the lines for a project that is glassfibre. It is a continous Polyline (on many places) which should not be the case. it should be broken and on the intersection points all the lines should be snapped on top of each other. so that it becomes 1 polyline

So my question is, is there maybe a lisp that will put the vertexes that are on a continous polyline together that they will form 1 polyline? I assume if they are within 1m would be sufficient that they can snap together.

Video and pictures attached also a example drawing will be in the comments! upload of 3 files max

Thanks in advance!

[t_pladet]

Example drawing included for experimenting! the whole drawing should be done with the LISP if possible. 🙂

[Sea-Haven]

This question has been asked before whilst automation is possible with a Tolerance, the only issue is which point to use as the control point ? You have a few different situations 2 parallel lines, should be one, a "T" with one leg or maybe 2 not joining at 1 point.

It has been answered before. I am sure the posters of the solutions will respond.

The reason I comment is that you need to talk to who created the dwg and how they went about it, there should not be those mistakes in it, just setting osnap to END only would make a big difference, if its manually entering Brg & Dist then a check is there a point nearby should be carried out before drawing a line. Survey allotment plans have a tolerance in there distance and the misclose can be very small if large a decision needs to be made.

I worked with surveyors doing field work and they carried a crayon with them and would mark a point on the ground as surveyed so would not get 2 points in the field data. The other thing is the sequence of field survey they would always keep check of there stringing again no 2 points. The field code allowed for double coding so would get a intersection pt 123, 01-23 meaning string 23 joins to string 1 at this point. They had a little pad and just wrote down string numbers. 

[CADaSchtroumpf]

A start with this?

(defun c:test ( / ss acadObj AcDoc Space n ent dxf_ent dxf_10)
  (setq ss (ssget '((0 . "LWPOLYLINE"))))
  (cond
    (ss
      (setq
        acadObj (vlax-get-acad-object)
        AcDoc (vla-get-ActiveDocument acadObj)
        Space
        (if (eq (getvar "CVPORT") 1)
          (vla-get-PaperSpace AcDoc)
          (vla-get-ModelSpace AcDoc)
        )
      )
      (vla-StartUndoMark AcDoc)
      (repeat (setq n (sslength ss))
        (setq
          ent (ssname ss (setq n (1- n)))
          dxf_ent (entget ent)
          dxf_10 (mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) dxf_ent))
        )
        (mapcar
          '(lambda (x)
            (mapcar
              '(lambda (y)
                (if (and (equal x y 1.0) (not (equal x y)))
                  (setq dxf_10 (subst (mapcar '* (mapcar '+ x y) '(0.5 0.5)) y dxf_10))
                )
              )
              dxf_10
            )
          )
          dxf_10
        )
        (entdel ent)
        (vlax-invoke Space 'AddLightWeightPolyline (apply 'append dxf_10))
      )
      (vla-EndUndoMark AcDoc)
    )
  )
  (prin1)
)

[Kent1Cooper]

I have a routine >here< to force all positional aspects of things [Polyline vertices, Line endpoints, Circle centers, Block or Text/Mtext insertion points, etc.] to fall on grid locations at whatever grid increment you choose.  It fixes many of your situations, but depending on the quantization value specified, and exactly where initial vertex locations lie in relation to the grid, it can take some of them farther from each other instead of making them coincide -- for example, with a quantization value of 1 [the white dots are a 1-unit grid], it changes this:

to this:

because those are the closest 1-unit-increment locations to those two vertices' original locations

And anything that rounds off the positions of all vertices, as that routine does, will move a lot of vertices that don't need to be moved for your purposes.  Not that I have a better idea....  The determination of vertices in the same Polyline that are close to each other, but are not adjacent vertices within the Polyline, seems like a big challenge.  Would it be fair to assume that the ones you want fixed are always two vertices apart, that is, they have one and only one other vertex between them?  If that can be assumed, it certainly would make the determination easier.

And once identified, would it matter which vertex gets moved to coincide with the other, or should they both be moved to halfway between them, or...?

[john.uhden]

@t_pladet ,

I have some questions...

1. Were the surveyors from your company or was the work outsourced?
2. Did all the intersections come in to the drawing as collected point data?
3. Who drafted the linework to connect the points (your company or the surveyor)?
4. When you say glassfibre do you mean fiberoptic?
5. Are there manhole structures at each group of intersections?
6. Was the fiber trench open or already backfilled?
7. If backfilled, then how were the points located?
8. I can't tell from the images, and I have only ACAD2002 here at home, but it looks like the main run has obtuse deflections and the others coming in from the sides may be service connections as their angles are more acute to the main.  Is that correct?
9. Is the linework all lines, or all plines, or some of both?

I think my approach might be to have you pick a beginning section of any main and then look for its intersections with any nearby endpoints and select the one that forms the smallest deflection as being the next leg of the main.  All others would be the service connections, depending on your answer to #8.

Wherever this discussion leads, I hope you can derive a better way of collecting and drafting the survey data.

[Kent1Cooper]

---

@Kent1Cooper wrote:

....  Would it be fair to assume that the ones you want fixed are always two vertices apart, that is, they have one and only one other vertex between them?  If that can be assumed, it certainly would make the determination easier. .....

---

While such an assumption could take care of a lot of the situations, what I have in mind would not fix this:

because though what you see is all part of the same Polyline, there isn't a second vertex close to the one with the grip showing.  I'm not sure it's possible to determine whether a vertex is within a certain distance of some non-vertex other place on the same Polyline.

Nor would it fix this:

because while those are two vertices in the same Polyline that are close enough to each other that you would want them fixed, in this case they have four other vertices in between.  By far most vertices that have that many others in between are far beyond needing to be made to coincide.

Nor would it fix this:

because those are parts of different Polylines.

But would it be useful for you to have something that fixes most of the situations?

[john.uhden]

@t_pladet ,

Could you please post a typical DWG in ACAD2000 format?  Thanks.