flyin solo, post: 406434, member: 8089 wrote: not suggesting they should- just saying that IF there is some problem with communication between the two formats (which to me sounds like a whole lot of nothing), it doesn't strike me that it would be incumbent upon carlson or its users to solve it. as would seem to be a subtext of the "carlson is inferior" argument.
A lot of it comes down to perspective.
The dynamic nature of Civil3D is both a draw and a detractor. The possible work flows are all but infinite. If you have integrated feature lines into your flow it will be difficult to work without them. If you have gotten used to using the survey database you will see many of your tools stripped away when you import 3rd party.
And there is the second part of the rub. After decades of dominance, any newcomer is just that. Autodesk is too busy moving or deleting my favorite commands for the next mandatory update to worry about newcomers.
Don't get me wrong. I've used Carlson and it's great. You do lose some functionality when you xmlout and in. As the new kid on the block Carlson will be the one seen as deficient, even if it's a better tool for many Survey work flows.
Then there are the specs. Many RFQ's are specific in the type and version of software to be used. If you don't have several seats of the latest brand x you will never score high enough to be considered for the jobs. Not a problem if you aren't feeding large engineering groups but a death sentence if you are...
Again- a main reason why I got out. Gonna spend the next few years reviewing surveys and slowly building a bar tab plying Mr. McMillan for the opportunity to sneak in on his sweet workload whenever that day comes when he should decide to focus solely on his art.
Mark Mayer, post: 406430, member: 424 wrote: Transfer of surfaces between CAD platforms using xml is about 99.9% accurate. There will be the occasional triangle that isn't flipped the right way in the transferred DTM. You just have to hope that that 0.1% doesn't happen in a critical area. Murphy's Law says it will.
We will not use XML surfaces and will not export them for use by others without a statement saying the end user of the XML is responsible for its use. We have had a few instances early on in our LandXML exporting experiences that forced us to go this route. In our experience it is much higher than .1%, more like 5%. We don't want to 'own' 5% of our projects. LandXML is good, but since it does not transfer the surface exactly as it's created it's more dangerous than good IMO.
Trundle, post: 406426, member: 12120 wrote:
Carlson is great for those doing lot surveys and Boundaries, and not much else.
What a load of nonsense. The not much else bit.
To answer one of your questions, C3D does have least squares. I've never seriously tried to get it to work. I think it would be possible but who knows. For example, we wrote down the steps to balance a traverse. One of the steps we wrote "C3D will crash at this point". It always does at this step. The last time I tried it I got the traverse in but when I went to balance it, it crashed over and over and wouldn't do it. That will be the last time I waste my time on it.
Other than the gererally complicated nature of C3D, it really does do everything else I want. I know I find the steps to contour a project much easier in C3D.
WA-ID Surveyor, post: 406448, member: 6294 wrote: We will not use XML surfaces and will not export them for use by others without a statement saying the end user of the XML is responsible for its use. We have had a few instances early on in our LandXML exporting experiences that forced us to go this route. In our experience it is much higher than .1%, more like 5%. We don't want to 'own' 5% of our projects. LandXML is good, but since it does not transfer the surface exactly as it's created it's more dangerous than good IMO.
Just for the heck of it, I imported a LandXML surface that I just sent to an engineer into a dummy project and then compared it to the original. It was 100% accurate.
We recently exported a LandXML surface created in Civil3D to a client who uses MicroStation. They worked with it for several weeks before sending me a screenshot along with the question "Is this what the site looks like?" The screenshot showed a disaster, with contours all over the place, crossing each other, missing in places, etc. I exported it again and they had the same problem. I have no confidence in LandXML now...
Wouldn't including the surface in the drawing file in the form of 3DFACEs be easier and more certain than using XML? I would think that C3D could turn a layer's worth of 3DFACEs into its proprietary surface format with a single command.
Jim in AZ, post: 406497, member: 249 wrote: I have no confidence in LandXML now...
[SARCASM]Maybe Autodesk had the same programmers who wrote the Civil3D Survey Tools write the LandXML import/export routines.[/SARCASM]
Jim in AZ, post: 406497, member: 249 wrote: We recently exported a LandXML surface created in Civil3D to a client who uses MicroStation. They worked with it for several weeks before sending me a screenshot along with the question "Is this what the site looks like?" The screenshot showed a disaster, with contours all over the place, crossing each other, missing in places, etc. I exported it again and they had the same problem. I have no confidence in LandXML now...
I spent 3 years running the survey department in a civil firm. I used Carlson, they ran C3D. I delivered at least a topo a week to them over that period, all through xml. Never once was there a problem (evidenced by a standard check of generating a surface from xml then xreffing my cad file in solid red to spot any variation in contours, spots, faces, and lines). I don't know where these supposed snafus everyone talks about are coming from (actually I suspect I do know but I doubt too many people want to hear "operator error"), but I do know that if careful, repeated procedures are followed that I've seen it work flawlessly over 100 times. I have complete confidence in it.
Seems like the only solution many are suggesting is that everyone switch to C3D. Well, that ain't happening.
Jim Frame, post: 406502, member: 10 wrote: Wouldn't including the surface in the drawing file in the form of 3DFACEs be easier and more certain than using XML? I would think that C3D could turn a layer's worth of 3DFACEs into its proprietary surface format with a single command.
That's how I do it in Carlson when I am merging two (or more) existing surfaces. I guarantees your original surfaces don't change.
Bow Tie Surveyor, post: 406492, member: 6939 wrote: Just for the heck of it, I imported a LandXML surface that I just sent to an engineer into a dummy project and then compared it to the original. It was 100% accurate.
It would be between like programs. The trouble occurs when you xml out of one program, like say your Carlson, and import into another, like say my Civil3d. The xml protocols used by the various programs, and various iterations of those programs are not exactly compatable.
Jim in AZ, post: 406497, member: 249 wrote: We recently exported a LandXML surface created in Civil3D to a client who uses MicroStation. They worked with it for several weeks before sending me a screenshot along with the question "Is this what the site looks like?" The screenshot showed a disaster, with contours all over the place, crossing each other, missing in places, etc. I exported it again and they had the same problem. I have no confidence in LandXML now...
In my humble opinion, LandXML is not the problem... LandXML is merely a format for data and the LandXML data structure(s) is (are) well documented and publicly available and have been for years. In fact, there is even a LandXML File Validator that allows anyone to check if the LandXML file they've produced (or have been given) conforms to the LandXML specification. If you're producing a LandXML file that validates properly but isn't showing the expected results in a receiving application, I'd say it is highly likely the receiving application is not parsing the data correctly. On the flip-side, if you're producing a LandXML file that doesn't validate, you'd want to contact your technology provider and make them aware of the problem(s). My å¢2...
Jim in AZ, post: 406497, member: 249 wrote: We recently exported a LandXML surface created in Civil3D to a client who uses MicroStation. They worked with it for several weeks before sending me a screenshot along with the question "Is this what the site looks like?" The screenshot showed a disaster, with contours all over the place, crossing each other, missing in places, etc. I exported it again and they had the same problem. I have no confidence in LandXML now...
It is my understanding that DTMs exported from C3D via XML do not include break lines. I have seen problems with bringing them into Inroads. My solution is to export the TIN in 3D lines which I then utilize to create the DTM in PowerSurvey. This only works because I have both software. To be honest, if you are going to be a consultant, you need the provide the client with the product they request.
John Putnam, post: 406535, member: 1188 wrote: It is my understanding that DTMs exported from C3D via XML do not include break lines.
The breaklines are just used to help build the surface. Once the surface is built, why do you need the breaklines?
John Putnam, post: 406535, member: 1188 wrote: It is my understanding that DTMs exported from C3D via XML do not include break lines.
The breaklines are just used to help build the surface. Once the surface is built, why do you need the breaklines?
Bow Tie Surveyor, post: 406546, member: 6939 wrote: The breaklines are just used to help build the surface. Once the surface is built, why do you need the breaklines?
I can see why someone would want everything that created the surface, along with the surface itself. So xmlout, and include the tin lines with the dwg that you give them.
Most of what I'm reading here on incompatibility between the two programs sounds more like personal preferences than actual incompatibility issues.
Ladd Nelson, post: 406521, member: 307 wrote: In my humble opinion, LandXML is not the problem... LandXML is merely a format for data and the LandXML data structure(s) is (are) well documented and publicly available and have been for years. In fact, there is even a LandXML File Validator that allows anyone to check if the LandXML file they've produced (or have been given) conforms to the LandXML specification. If you're producing a LandXML file that validates properly but isn't showing the expected results in a receiving application, I'd say it is highly likely the receiving application is not parsing the data correctly. On the flip-side, if you're producing a LandXML file that doesn't validate, you'd want to contact your technology provider and make them aware of the problem(s). My å¢2...
"...I'd say it is highly likely the receiving application is not parsing the data correctly."
In the case I refer to that would be MicroStation...
Ladd Nelson, post: 406521, member: 307 wrote: LandXML is not the problem
Still, there is no question that the conversion is sometimes imperfect. As you say, the problem may be with how the receiving application parses the incoming xml. That will be cold comfort when the stuff hits the fan.
As John said, if you are going to be a consultant it is appropriate to deliver product in your clients preferred format. I can see a scenario where a survey department uses Carlson, but has one copy of C3d to run it's deliverables through for a final check. One outfit I was with produced mapping in LDD, then ran the finished product through Microstation/Inroads to generate a final deliverable that was transparently MS to the DOT client. This process, which I have detailed here before, was not a simple Saveas. But it was more efficient for us than running the whole project in MS.
Bow Tie Surveyor, post: 406546, member: 6939 wrote: The breaklines are just used to help build the surface. Once the surface is built, why do you need the breaklines?
I'm not sure LandXML defines the DTM but I know that the triangles are not always the same as the original which is a problem.
