Create new polygon from 2 lwpolylines

[csgohjmj]

Hi all;
I have two lwpolylines, for example and the lines start from left to right.
These 2 lwpolylines may intersect each other at multiple points along its path with each other. What I need here is to find out these intersecting coordinates and then construct a polygon starting from the left intersection point and goes along one of the lwpolyline to its next intersection point and then return back to the starting position via the second lwpolyline. The process repeats from the second intersection to the third intersection and so on until there is no more polygon to be formed at the end of the 2 lines.
Any help in writing the codes are much appreciated.
Thanks.

csgoh

[Tom Beauford]

Wouldn't it be easy enough to just use the boundary command, select the two polylines as a new boundary set, and then pick internal points for the polygons? What is this for? Why does it matter where the start point is?

[csgohjmj]

Dear Tom;
The main aim is to calculate whether the area within the two intersections are positive or negative area. It is to determine the area of the cross sections for cut and fill earth works which is used to calculate the volumes of earth material. As such, whether the polygon formed is clockwise or anticlockwise will determine whether it is a cut or a fill area. And by using bpoly, it only gives you an absolute area. And also, at times the polygon formed using bpoly is not the actual polygon especially if you have lines which are very very close to each other and this will not represent the true area. So, we have to form our own polygon which I am stuck and still working on it. I have roughly thought of the algorithm and it is something like this.
1) Get the first polyline and put the endpoints to an ogl-list
2) Get the 2nd polyline and put the endpoints to the asb-list
3) Calculate the intersection and put into an inter-list
4) Delete those points in ogl and asb-list which are less than the min x coordinate of the interlist and greater than the max x coordinate of the inter-list.
5)Form the polygon.

Thanks.

csgoh

[mjfarrell]

I'm curious why you are not using cross sections
from the Civil Design Tools in Land Desktop to
do these cross section calculations?
If you are getting earthwork volumes, I must imagine that
you are also performing other terrain modeling functions.
And based on that it would seem a good investment
to acquire that program.

Also, based on other post you have made to help with
lisp programming, you are creating functions that
already exist within the base Land Desktop/MAP
combination (Centroid issues). With Land and MAP
you would be getting the information you are after
straight out of the box.

[csgohjmj]

Basically, I am not doing any terrain modelling and it is also not cost effective fotr us to get the Land Desktop to calculate the volumes. The data we input are just chainage,dist and the reduced level and these are the info that I have. Getting the software would solve the problem but it is not cost effective according to my superiors. So I am still trying to solve this.
The problem that I am having is to create another list of coords which will form the polygons between the intersecting points. Also it has to check whether the intersecting points are very close to any existing points.
Any help would be much appreciated.

csgoh

[Tom Beauford]

I'm in the same situation as you having to do earthwork calculations while working for tightwads who wont buy the right software. Make sure you scale those coordinates first or you will get garbage results. Using a scale factor on the area will only work if the horizontal and vertical scales are the same. I usually create a new drawing, insert the cross-section drawing as a block adjusting the x and y scale to 1:1, then explode and label the areas with text dividing the origional x scale by the origional y scale for the text width. Then I insert the area text into the origional cross-section drawing the same way. Quicker than it sounds once you've done it a few times.

[csgohjmj]

Tom;
Getting the area should not be a problem even if the x and y scales are not 1:1. You just multiply it by the factor the cross section is plotted. However, if this polygons problem could be solved, the cut or fill area will be determined by its sign ie whether it is a clockwise or anticlockwise polygon and thus the total area for the chainage shall be determined.

csgoh

[David.Hoole]

We use 2 alternative products for this kind of modelling: PDS, & Key Terra-Firma
You might want to get your employers to look at these as they can be more cost effective than the Autodesk vertical products. See the following links:

http://www.ecl.uk.com/

http://www.keyterra-firma.com/

[mjfarrell]

Granted, the up-front cost of Land Desktop,
or any other product that is set up to do
Civil engineering related calculations
might seem cost prohibitive.

However (and note I am NOT an AutoDesk vendor)
when one factors in the time and effort required to
integrate some non-autodesk solution into AutoCAD,
to develop and program your own solution, test, debug
and refine said programming, the cost savings start to
evaporate pretty rapidly. Contrast that with being able
to open the box install the application and produce
the exact data and drawings of that data, there is some
real value in having the right tools for the task.
That being said, many of the persons and firms for whom
I provide training and support services do not get the full
value from the products they own, because they either
don't know the tools are there, or have had no success
in applying them based on using the help file, or poor
training through their local vendor. I agree the vertical
products are expensive, IF you use them 'just like AutoCAD.
However if you utilize the tools the price is in line with the
profits and productivity one can achieve through their use.

In this case the user is saying 'this is all we do' great, only
they probably do much more than that as we all do. It is
also possible that they miss the opportunity to do more
because of the limits of basic AutoCAD and their ability to
program it. I have been many places that try this justified by
cost of the solution, and then they have no accounting mechanism
to account for the actual cost of the programming efforts, and
lost revenue while the code guy isn't working.

It's pretty sure they had to invent some method of entering that
cross section data into regular AutoCAD. Contrast that with being
able to automatically import the digital job file and produce the
as surveyed sections in seconds, right out of the box.
And then automatically place and label those sections on drawing
sheets if required. No Land Desktop, or Civil 3D aren't perfect,
only the real cost of that solutions is easier to calculate.

[David.Hoole]

Hi Michael

I have to say you sound exactly like an Autodesk reseller!

The products I referred to are direct plug-ins to AutoCAD, designed by established 3rd party developers.
Any CAD product has defined protocols for the input of data. Autodesk products are no different. In fact, in my experience, Autodesk vertical products are notoriously sensitive to any divergence from their individual input protocols!

In a multi-disciplinary environment, most companies simply cannot afford to purchase every Autodesk vertical product which touches on any aspect of their business. In this environment it is often more economical to purchase a 3rd party product which may not offer the full range of the relevant Autodesk vertical product, but is adequate for the task.
Any company with a sensible attitude to software acquisition will satisfy itself of the adequacy of a product prior to purchase.

In my opinion, it is not sensible to close oneself off to the potential of the innumerable 3rd party CAD products available without even evaluating them, simply because they do not carry an Autodesk logo!

[mjfarrell]

David,

Please let's not start any rumor that I am and AutoDesk reseller.

Also I did not indicate that the user should not evaluate 3rd party applications.

<snip>Granted, the up-front cost of Land Desktop,
or any other product that is set up to do
Civil engineering related calculations
might seem cost prohibitive.<snip>

What I was saying is that companies lose sight of the actual cost of attempting
to program, with LISP or VBA what have you, when there is a solution 'off the shelf'.
Anyone that failed to looked at all available options before they attempt to build
their own wheel is entering into some murky accounting waters.