How do I "export" multiple closed polyline and modify CSV and "import" it back into civil 3d?

[jeff.wangD95HG]

So I have a bunch of closed polyline and I am wondering if I could export it into CSV with coordinates on each vertices. Then I want to change the coordinates of the vertices in CSV and import it back into civil ?

How do I go about doing this?

I know you can extract data with dataextraction command but I am not sure how I can import it back into civil and maintain the polyline.

[Neilw_05]

While the math looks easy using the nominal coordinates in the example you gave, it will be difficult to determine which coordinates need to be adjusted when they are random, as will be the case when derived from the survey coordinates. How would you go about doing that?

[TerryDotson]

So I have a bunch of closed polyline and I am wondering ...

Little bit o' lisp just to keep me from forgetting how.  Test thoroughly before using on your actual drawings.  Be aware that the decimal precision is gone unless followed by an UNDO command. 

1. Before using save your drawing to a different name.
2. Use at your own risk.

(defun c:PlnSetPre ()
  (setq dec (getint "\nDecimal Precision: "))
  (setq sset (ssget '((0 . "LWPOLYLINE"))))
  (if sset
    (progn
      (setq num (sslength sset) itm 0)
      (while (< itm num)
        (princ (strcat "\rProcessing Object " (rtos (1+ itm) 2 0) " of " (rtos num 2 0)))
        (setq hnd (ssname sset itm))
        (setq ent (entget hnd))
        (foreach rec ent
          (cond
            ((= (car rec) 10)
              (setq eas (nth 1 rec))
              (setq nor (nth 2 rec))
	      (setq est (rtos eas 2 dec))
              (setq nst (rtos nor 2 dec))
              (setq evr (atof est))
              (setq nvr (atof nst))
      	      (setq new (list evr nvr))
 	      (setq ent (subst (cons 10 new) rec ent))
            )
          )
        )
        (entmod ent)
	(setq itm (1+ itm))
      )
    )
  )
  (princ)
)

[jeff.wangD95HG]

floor plan is derived from arch plan so no real world coordinates is needed which made things easier.

in other words everything can be done in local coordinates.

I am making the assumption that all vertices coordinates that lines up to each other within 0.01 in the x or y direction are orthogonal to each other and therefore should be the same value. As for how to make adjustments, I am thinking of averaging  then round   so for  x = 1.001, 1.002 , 1.002, 1.006  and y = 5.000 ,6.000, 8.000, 10.000.  for x the average is around 1.003 which mean it rounds to 1.00. I will get x= 1.00, 1.00 , 1.00, 1.00 and y = 5.00, 6.00 , 8.00 , 10.00.

I will hopefully be able to do this in excel.

I understand there will be edge cases but this is probably as good as it gets for the first iteration. 

[ChicagoLooper]

@jeff.wangD95HG 

OK, got it. You're drawing floorplans. Your use of rounding will likely lengthen or shorten the distance from-vertex-to-vertex.

In the case of a floor plan where two units are adjacent, how do you (or can you) manage each adjusted floorplan?

Same image as the one uploaded in post #11.

Using the image above, the two gray units may become wider when rounding UP making the floorplans overlap. Or, if rounding DOWN, the floorplans might become narrower leaving a gap at the wall they once shared. Either way, you, or someone else, will have to manage that condition.

Would you manually pull the floorplans apart when they overlap and push them together when there's a void?

Would your export to CSV and import back to C3D automate the Pull Apart/Push Together operation? 

Just curious....    

[jeff.wangD95HG]

So here is the plan. 

explode the polylines into lines and extract data out of each line

The CSV will be containing information like starting x, starting y, ending x, and ending y for each individual line

I am just going to explain using unique vertices coordinates because there are many vertices that share the exact same coordinate.

Using local coordinates (x,y) where (0,0) is at the bottom left corner

The top vertices are  (0,10.000), (6.015 ,10.000), (12.030,10.000)

bottom vertices are (0,0) ,  (2.005,0), (2.005,1.000), (4.010,1.000),  (4.010,0),  (6.015,0),  (8.020,0),  (8.020,1.000),  (10.025,1.000), (10.025,0), (12.030,0)

If I were to round all the coordinates to 2 decimal places you would notice that they close and are orthogonal 

and please double check my work.

The top vertices are  (0,10.00), (6.02 ,10.00), (12.03,10.00)

bottom vertices are (0,0) ,  (2.01,0), (2.01,1.00), (4.01,1.00),  (4.01,0),  (6.02,0),  (8.02,0),  (8.02,1.00),  (10.03,1.00), (10.03,0), (12.03,0)

once lines are drawn back I should be able to redraw polyline using boundary command

[ChicagoLooper]

@jeff.wangD95HG 

It appears you are taking a theoretical approach rather than a geometric approach. While your theory may look good on paper and sound good in discussion, it isn’t practical.

Your rounding method modifies the dimensions. It physically changes the geometry of the floor plan.

The image you uploaded in post #11 illustrates a weakness in the rounding method. The gray floor plan on right displays 3 decimal dimensions while the red on the left displays only 2 decimal dimensions. 

Rounding will change the circled dimensions on the right (Gray floor plan) to the squared dimensions on the left (Red floor plan). Mathematically speaking, the geometry yields this:

1. Total yellow circles = Total blue circles 
2. Total  yellow squares = Total blue squares

If these plans are accurate AND orthogonal, then condition 1 is true due to its 3 decimal

precision while condition 2 is not true due to rounding.

Also, if condition 2 is no longer true, what effect does that have on the length of the RED vertical lines? Do they become longer or shorter? Or do they remain the same?

While you may accomplish a decrease in precision of dimensions, you have unknowingly altered the existing floor plans by relocating the vertices and have corrupted the linework’s orthogonal properties. 

It would be interesting to know what effect the rounding method will have if your floor plan also had 45 degree angled walls. Given the Pythagorean theorem and your rounding, how would the wall lengths change?

 

[AllenJessup]

Just wanted to mention. If you extract both the starting and ending X,Y for each line. You'll have duplicate vertices in the resulting polyline.

[jeff.wangD95HG]

"unknowingly altered the existing floor plans by relocating the vertices and have corrupted the linework’s orthogonal properties"

relocating yes. Corrupting orthogonal properties no (you can double check my work). Area change yes, but I am expected to use the rounded area.

post#11 is what I use to demonstrate if you round the "length" of each line

but what I am proposing is that I round the "coordinate" of each vertices instead

Also I can't expect construction workers to work at 3 decimal place accuracy or so I have been told.

"It would be interesting to know what effect the rounding method will have if your floor plan also had 45 degree angled walls"

I will cross that bridge when I get to it, but most likely get swept under acceptable error range until someone complains.

@AllenJessup 

duplicate line of the same start end is fine. I can weed it out in excel or overkill or map clean. Overlapping line is also fine it makes labelling easier. Reconstruction of polyline is also fine if I use boundary command instead of join.

[ChicagoLooper]

@jeff.wangD95HG 

<<...Corrupting orthogonal properties no (you can double check my work)....>> 

I will gladly check your work. Upload your dwg file, the entire file, not just a portion of it. Or use 'Send Private Message' to share your file.

[jeff.wangD95HG]

you should be able to check for orthogonality by eyeballing it with the coordinates I have laid out in 

post #25 combining it with picture from post #11 as to which vertices connects to which

If you don't understand what I am getting at in post #25 please let me know.

[ChicagoLooper]

@jeff.wangD95HG  wrote 

<<but I am expected to use the rounded area.>>

If it's OK to use 'rounded area' and not the actual area then why bother to re-compute the coordinates? Why are you planning to redraw the footprint using boundary command? Rounding means NOT actual but close enough so it falls under acceptable error range until someone complains. Sound familiar? 

and also this

<<what I am proposing is that I round the "coordinate" of each vertices instead>>

If you are planning to round the "coordinate" of each vertices you won't gain any efficiencies. In fact, Excel is not AutoCAD can do the rounding for you.

Image-1

You can get rounded dimensions by by customizing the precision in your DIM STYLE and you can get the area from a FIELD. You can even specify two decimal precision when getting that field (refer to image-1). And you don't need to redraw.  

Using YOUR rounded coordinates, these are YOUR points. The points, the one you referred to as 'top coordinates' were inserted then connected with a line (green lines are underneath the red lines). There are two sets of dim styles: green dims measuring the green lines (3 decimal dim style) and red dims for red lines (2 decimal dim style).

Image-2

You can see the GREEN dims are accurate: 6.015+6.015=12.030 (refer to image-2). The RED dims, however, look flakey. Although 6.02+6.01=12.03 is correct, the adjacent properties boundaries are not symmetrical. The two properties can't be divided perfectly in half with only 2 decimals, you need 3. To get two identical lengths after rounding the coordinates, you have to modify one or both footprints, and that's too much work.

You could also choose to use unequal prop boundaries but why would you do that? What rational explanation would justify moving from already equal to modified unequal? And just to be ultra clear, the red dims are unequal because you chose to use Rounded Coordinates.

[jeff.wangD95HG]

 "why bother to re-compute the coordinates"

As I am being told,  assume only pdf is distributed. one should be able to derive and close the area base on the labelling alone with zero error.

"AutoCAD can do the rounding"

tried it, I can't get zero error when compared to calculation strictly derived from labels only. around 10% of the time it will be 0.1 off as expected. And my superior complained so that's not good enough.

"The two properties can't be divided perfectly in half with only 2 decimals, you need 3"

good enough, you can't expect construction worker to build with 3 decimal accuracy anyways as I have been told. strata plans strictly outlines to use 2 decimal for all house measurements so its all good.

"rounded dims are unequal because you chose to use Rounded Coordinates"

sounds good to me. Alternative is to go against the strata plan outline. Unless there are other alternatives I am missing. And realistically speaking if some of the room are obviously exactly the same while the labelling aren't then I would probably do some quick manual shift on other less obvious room to make the labelling the same.

Perhaps you can give me insights on how to fulfil the following rules all at once?

1. draw centerline of wall from arch plan

2. lines are orthogonal

3. label to measurements to 2 decimal place no more no less

4. assume only pdf is distributed. One should be able to close and derive each area with 0 error

5. area to 1 decimal place no more no less

[ChicagoLooper]

@jeff.wangD95HG 

<<…strata plans strictly outlines to use 2 decimal for all house measurements…>>

If this is true, then why do you need to recalculate coordinates? If only 2 decimals are required then round to 2 decimals without redrawing. 

<<good enough, you can't expect construction worker to build with 3 decimal accuracy>>

If good enough for construction workers why not good enough for you and your boss? Who will know, besides you and your boss, if you ‘rounded’ the coordinates or not?

<<…tried it, I can't get zero error when compared to calculation strictly derived from labels?…>>

Your post should be titled How to Dimension with Two Decimal Accuracy, not How do I “export”……You gave up too easily. Investing your energies here instead of developing a plan to recalculate coordinates would have paid off by now because the forum would’ve provided the answer (or maybe several viable options from which to consider).

Sorry, but it’s called AUTOcad, not Autodosomequickmanualshiftonotherlessobviousroomtomakethelabellingthesame.

[jeff.wangD95HG]

1. draw centerline of wall from arch plan

2. lines are orthogonal

3. label to measurements to 2 decimal place no more no less

4. assume only pdf is distributed. One should be able to close and derive each area with 0 error

5. area to 1 decimal place no more no less

"If only 2 decimals are required then round to 2 decimals without redrawing. "

this will violates rule 4 as demonstrated before

"Your post should be titled How to Dimension with Two Decimal Accuracy"

this will violate rule 4 as demonstrated before. notice if you are given only the red labels on a pdf you wouldn't be able to make that area close

Also applying  rule 5 to round area to 1 decimal place. In your calculation, you would label area to be 58.1. But if you are only given red labels on pdf you would get (let's ignore closure for now) 10*6.02 -1*2.01 = 58.19 = 58.2

therefore it violates rule 4.

[AllenJessup]

@ChicagoLooper 

I believe the problem @jeff.wangD95HG is having is that even if you round the dimensions to 2 decimal places. The area labeled from the polylines will not match the area if someone looks at the PDF and uses a calculator to find the area. We may think this isn't an issue but his boss does. 

[ChicagoLooper]

@jeff.wangD95HG 

If you are creating floor plans by drawing the 'centerline' of a wall, then there's no way around re-creating that kind of linework due to the varying wall thicknesses used to comply with both building code and structural requirements.

When re-creating room size  by drawing centerlines through walls, your floor area will always differ from the original architect's plans since your floor plan ignores wall thickness. How you determine area differs greatly from how others compute area (think carpet installer or property assessor or architect) so it's not likely to find existing drawings used by other trades and agencies with your specific requirements.

To get the area within your type of walls, you can use HATCH. Put the hatch on a dedicated layer so it can be frozen or thawed or set to No-Plot. You can also use a FIELD to calculate each room's area. When establishing a field, you can choose the decimal precision. You can use plain mtext as a prefix or suffix in combination with a field, e.g. 'Area' XX 'SqM' where XX is the field sandwiched in between the prefix Area and the suffix SqM. 

Since you're personally drawing your own walls, your room areas will be accurate. If all walls are the same thickness, you might be, or might not be, able to automate the wall creation procedure. Using coordinates and connecting the dots is error prone (it's silly) and requires too much QA/QC. Manual drawing will be much faster and  accurate. If you grab a hatch grip and increase or decrease the hatch coverage, the field will respond and update when you execute REA command (Regen All).

Alternatively, you can go old school and do everything manually.