Your question warrants a dive into surveying principles like map projections, scale factors, and grid vs. ground coordinates. It’s a discussion that is probably outside the scope of this thread, but might make for some good reading.
Thanks for the introductory search terms. 
I always enjoy getting to learn about new stuff as the community grows.
1 Like
I think part of the point is being missed. The coordinates are big because that’s how the UTM coordinate system works. While the actual area of interest is small. Much smaller than any where the curvature of the earth matters.
My specific example involves a pipeline segment just 1.6km long. I’m trying to ‘thicken’ or ‘offset’ some survey points that follow a linear path adjacent to the pipeline so that I can built a narrow surface with a width that extends a few metres to the other side of the pipeline alignment.
The point is actually to apply some ‘depth of cover’ values to the pipeline, where the survey data is not actually directly on the pipeline polyline (don’t ask Why, it’s not relevant). I’m using the Civil3D nodes to drape the vertices of my pipeline on Topo and on my Depth of Cover surface so I can subtract one from the other and put the top of my pipeline at it’s actual proposed elevation below topo.
As part of this, I import the Depth of Cover survey data. It’s UTM coordinates, XYZ, 3 decimals.
I make a PolyCurve from that data.
PolyCurve.ByPoints demands that I use the Extra Large scaling for this Or It Will Not Run. However, with the Extra Large scaling, It Will Not Run - Giving the PolyCurves may be Branching warning.
Whether or not you think this is actually running or not is semantics when the output of the node is Null.
Alternatively, to avoid the problem with PolyCurves, I can use the survey data to make a 3D Polyline in Civil3D with Polyline3D.ByPoints, and then suck that into Dynamo using Object.Geometry … where again I get the PolyCurves may be Branching error. Despite it most definitely being one single non-branching polyline.
Either way, in the Dynamo background, you can see gaps between some of the vertices of the resulting PolyCurve.
If Dynamo for Civil3D is going to make us fake (shift) all our datasets just to make the nodes function, or so we can be sure the nodes are actually doing what we expect without rounding off significant digits, it’s going to make Dynamo much less useful.
2 Likes
One method may be to scale your geometry down at the beginning of your graph (say by a factor or 10 or 100), perform your operations, and then scale it back up by the same factor before committing your changes back to Civil3D.
1 Like
Hi - I am trying to understand if the node is not executing at all or executing and failing, because the “demand” that you are suggesting is raised should not be a demand, and instead the node should run and should not return null (in most cases, even if the numbers are large) - but I think the situation you are encountering is that you have coordinates very far away (large numbers) AND you are trying to operate on a small section of the model, as you described, and in this case, yes this geometry scaling function will not help you at all.
For now I would scale your subset of geometry down manually before the operations you must perform or translate it, and back - then you can decide which scale factor to use. Automatically doing either of these is possible, but theres no roadmap for that feature at this time.
1 Like
ok, so apologies for not replying sooner, and thanks for the replies. I did eventually get my script to work after changing a fundamental step in how I attacked my problem. I thought that the script wasn’t working when the geometry scaling warning appeared, but it was something else. I just had to grit my teeth and ignore the geometry scaling warnings.
1 Like