Topic: Survey ft vs Intl ft

[cadtag]

I'm not sure if this belongs here, or under the LISP forums.

Basically I'm wondering if the c3d setting for US Survey ft vs International ft is accessible through LISP.  I'm wondering if it's possible to run a routine in acaddoc.lsp that would flash a warning if the drwing being opened was set to Intl feet.

Anyone know? 

[Jeff_M]

Yes, you can get this information with vlisp.

Code: [Select]

  (setq prod (vlax-product-key))
  (setq prodStr (strcat "AeccXUiLand.AeccApplication"
(cond ((vl-string-search "\\R17.0\\" prod)
       ".4.0");;2007
      ((vl-string-search "\\R17.1\\" prod)
       ".5.0");;2008
      ((vl-string-search "\\R17.2\\" prod)
       ".6.0");;2009
      ((vl-string-search "\\R18.0\\" prod)
       ".7.0");;2010
      ((vl-string-search "\\R18.1\\" prod)
       ".8.0");;2011
      ((vl-string-search "\\R18.2\\" prod)
       ".9.0");;2012
      (t ""))))
           (setq *acad* (vlax-get-acad-object))
   (setq C3D (vla-getinterfaceobject *acad* prodStr))
   (setq C3Ddoc (vla-get-activedocument C3D))

      (setq C3Dsets (vlax-get-property C3Ddoc 'Settings))
      (setq docSets (vlax-get-property C3Dsets 'Drawingsettings))
      (setq unitsandzone (vlax-get-property docsets 'unitzonesettings))
      (setq footflag (vlax-get-property unitsandzone 'foottometerconversionflag))
      ;; international foot = 1, US Survey foot = 2


[BlackBox]

FWIW - 

Referenceing the AeccDbMgd.dll into a .NET solution for Civil 3D, will make accessible the Autodesk.Civil.Settings Namespace, which provides access to the Public Enum ImperialToMetricConversionType, and resultant InternationalFoot, and UsSurveyFoot Constants.

A (simple?) LispFunction Method will offer better performance than that of accessing the AeccXUiLand.AeccApplication's Interface Object via ACADDOC.lsp, and can still be called from your LISP application(s). I would code said LispFunction Method such that it may be called with no arguments, and return T or Nil... Pseudo code:

Code - Auto/Visual Lisp: [Select]

1. (prompt "\n** ")
2. (if (UsFoot-p)
3.         "US FOOT ** "
4.         "INTERNATIONAL FOOT ** "
5.         )

[Jeff_M]

RenderMan, I'd be curious to see the performance difference between the straight lisp vs combined lisp/.NET dll and (how I would do this if I needed such a thing) a pure .NET solution (look ma, no lisp! ). For something such as this, I suspect it will be negligible. And for the user who asked about a lisp solution, I didn't see a need to bring up .NET since they probably aren't familiar with it anyway.

Here's a quick test lisp that takes almost no time to run (I couldn't find my old benchmark lisp to give any hard numbers).

Code: [Select]


(defun c:getflag (/ *ACAD* C3D C3DDOC C3DSETS DOCSETS FOOTFLAG PROD PRODSTR UNITSANDZONE)
  (vl-load-com)
  (setq prod (vlax-product-key))
  (setq prodStr (strcat "AeccXUiLand.AeccApplication"
(cond ((vl-string-search "\\R17.0\\" prod)
       ".4.0");;2007
      ((vl-string-search "\\R17.1\\" prod)
       ".5.0");;2008
      ((vl-string-search "\\R17.2\\" prod)
       ".6.0");;2009
      ((vl-string-search "\\R18.0\\" prod)
       ".7.0");;2010
      ((vl-string-search "\\R18.1\\" prod)
       ".8.0");;2011
      ((vl-string-search "\\R18.2\\" prod)
       ".9.0");;2012
      (t ""))))
     
  (if (and (setq *acad* (vlax-get-acad-object))
   (setq C3D (vla-getinterfaceobject *acad* prodStr))
   (setq C3Ddoc (vla-get-activedocument C3D))
   )
    (progn
      (setq C3Dsets (vlax-get-property C3Ddoc 'Settings))
      (setq docSets (vlax-get-property C3Dsets 'Drawingsettings))
      (setq unitsandzone (vlax-get-property docsets 'unitzonesettings))
      (setq footflag (vlax-get-property unitsandzone 'foottometerconversionflag))
      ;; international foot = 1, US Survey foot = 2
      (princ (strcat "This drawing is set to use the "
     (if (= footflag 1)
       "International foot"
       "US Survey foot"
       )
     " option."))
      )
    (vlax-release-object C3D)
    )
  (princ)
  )


[mjfarrell]

I'm not sure if this belongs here, or under the LISP forums.

Basically I'm wondering if the c3d setting for US Survey ft vs International ft is accessible through LISP.  I'm wondering if it's possible to run a routine in acaddoc.lsp that would flash a warning if the drwing being opened was set to Intl feet.

Anyone know?

I'm wonderng why it would matter?
Given that the file was started in one unit or the other, what difference would it make, if you kept working in that same unit?

[BlackBox]

Jeff,

First to your point of potential or lack of performance difference... I failed to consider the difference between the internal database of Civil 3D as compared to the external database of Land Desktop. In the latter case, I've personally experienced the performance lag, albeit on a previous 32-Bit system. Now I have a Win7, 64-Bit combined with the internal database of Civil 3D.

I happen to know Cadtag outside of the forums, so I know a bit more of his situation.

As for my LispFunction suggestion to begin with; I'm a LISP-er who's relatively new to .NET development. :p

[cadtag]

]I'm wonderng why it would matter?
Given that the file was started in one unit or the other, what difference would it make, if you kept working in that same unit?

Will it matter?  generally not for work we've started, but most of my survey material is coming in from outside vendors/subs.  It would be nice to know if they've done something different than was expected.

[RANDOMXS]

'Will it matter?  '

How big is your project and what is your desired precision?

999,998 US Survey feet = 304,800 Meters
1,000,000 International ft = 304,800 Meters
or 2 parts per million.

1,000,000 ft = 189+ miles.

[caddcop]

For example, the state of Maryland is not one of the larger states. The origin of its Nad83 coordinate system is somewhere down in West Virginia.
By the time you get near the top, right corner, where PA and DE come together, the difference can be somewhere near 40'. So the size of the project is not the issue - its the size of your coordinate system.

[mjfarrell]

I think the last two posters misunderstood my question.

]I'm wondering why it would matter?
Given that the file was started in one unit or the other, what difference would it make, if you kept working in that same unit?

Taken out of context it would appear that I'm not aware of the difference in units of measure.
Placed back in context of my statement, it will not matter given that the drawing is set up on the right units from the start.

[caddcop]

As long as all files used with the project are also setup similarly, it should not. But when was the last time you had 100% control of all files used on a project.
In the Civil world, files need datums and units to ensure that multiple files line up correctly.

[Dent Cermak]

'Will it matter?  '

How big is your project and what is your desired precision?

999,998 US Survey feet = 304,800 Meters
1,000,000 International ft = 304,800 Meters
or 2 parts per million.

1,000,000 ft = 189+ miles.

While in one respect you are correct, surveyors using EDM’s can not measure a distance to a precision of 2ppm (or 0.002′ in 1000.00′), but that is not the issue. The REAL issue is when this 2ppm is applied to State Plane coordinates in the N2,000,000 and E6,000,000 range! This 2ppm literally moves a State Plane coordinate position 4 feet by 12 feet, using the coordinate values listed.

With more and more projects being based on State Plane coordinates, this issue is going to be more and more prevalent. Working on projects in many States, we are well aware of the problems presented when users mix Survey Foot and International Foot units. In nearly all cases it is simply user awareness, or a project that has not been setup correctly.

Imagine you complete a design in rural California, using State Plane coordinates based on International Foot units, which is subsequently passed on to a surveyor for staking. Surveyors are aware that California uses Survey Foot units.

Many survey software packages convert Foot units on the fly. Then imagine (or have a nightmare!) that your design is being constructed 4′ x 12′ out of position! You would quickly come to the realization that 2ppm matters!

In our practice, this is a HUGE issue, and I would find it hard to believe it has not affected others similarly. This topic is hot enough that, in my opinion, it deserves clarification.

[mjfarrell]

I am aware of the resulting positional error(s).
As stated earlier, my question about would it matter is considering that the file
or files were originally setup on whatever unit of measure the job was supposed to be conducted in there would be no issue.

Do I always have full control of the drawings?  No
Can I take a look at the drawing settings and verify the units and zone are set correctly in my file(s)?  Yes

Can I create and name templates that are named in a manner that allows users to easily select the correct template for the work at hand?  Yes

Do I know the difference between a Link, and a Rood?  Yes.

[Dent Cermak]

Such a positional error would make it very difficult to place the design on the ground if one was unaware of the error. Not being a surveyor, you are probably unaware that most state boards require the use og the US Foot on all work. All it takes is for one person to be on the wrong system to cause MAJOR problems. Especially when working on projects that have zero lot line setbacks.
This is generally a survey issue. Most Architects and Engineers do not understand the differances nor do they care. Design tolerances in architecture and general engineering, when it comes to positional tolerance, are no where near as tight as those the Surveyor is held to by state regulations.

Do I know the difference between a Link, and a Rood?  Yes.


Rood??  I know of links,inches, feet, yards, rods, miles, varas, chains, acres, hectares, poles, leagues, labors and perches, but "Rood" is a new one to me?

[BlackBox]

Do I know the difference between a Link, and a Rood?  Yes.


Rood??  I know of links,inches, feet, yards, rods, miles, varas, chains, acres, hectares, poles, leagues, labors and perches, but "Rood" is a new one to me?

For completeness: Rood

[mjfarrell]

Not being a surveyor.....Do I know the difference between a Link, and a Rood?  Yes.


Rood??  I know of links,inches, feet, yards, rods, miles, varas, chains, acres, hectares, poles, leagues, labors and perches, but "Rood" is a new one to me?

It's actually quite old, and I used to work in the field performing topographic as well as boundary survey duties.  I've also had several college level classes in Plane Surveying.

Am I a Surveyor?  No

Do I understand and consult with Surveyors on these matters?  Yes.

[BlackBox]

Does 'someone' like answering their own questions?  Yes.

  LoL

[Dent Cermak]

Rood....old english 1/4 acre. Hmm? A unit of area not a unit of measurement?
But if in your consultations with surveyors you are telling them that using International Feet on their work is just fine, you are doing a diservice that can get them sued.
True, all units being the same on a drawing is jusy fine.......UNTIL someone else goes to lay out the project on the ground using state plane control. Or when the State Board notes that the initial survey was performed using International Feet.
Best way to do a job is the right way the first time. By the book, by the state regs and as per standards.

[mjfarrell]

Rood....old english 1/4 acre. Hmm? A unit of area not a unit of measurement?
But if in your consultations with surveyors you are telling them that using International Feet on their work is just fine, you are doing a diservice that can get them sued.

Dent,

Please go back and notice I never advocated use of any particular unit of measure.

Point of fact the advice I give most often is to use State Plane coordinates.
With the exception that they should use the localized Low Distortion system if it is available.

Somehow the conversation went from "if my drawing is using a unit of measure how will I know?".
And twisted into; Higgs doesn't know his feet from his parsecs. And that simply isn't true nor the point of the discussion.

[Dent Cermak]

Is/Was   :ugly:

[sinc]

I'm wonderng why it would matter?
Given that the file was started in one unit or the other, what difference would it make, if you kept working in that same unit?

The big reason that it matters is that C3D does "automatic conversions" without warning you, if you have things set wrong.

This can be very problematic when multiple companies are involved, and one of them doesn't realize that they need to set their units to the right type of foot.  When doing LandXML import/export, you can end up with unwanted translations.

Another problem results when trying to work with people on Microstation.  I've gotten plan sets from the Army Corps that were converted from DGN to DWG, and some of the DWGs are converted using Survey Foot, while some are converted using International Foot.  All of these drawings are part of the same plan set, but something they do on the Microstation end of things can create different outcomes.  Combining two such mis-matched drawings results in linework that is offset, with one or the other being erroneous.

It's definitely important to know which foot you should be using, and to use it consistently.

[mjfarrell]

The conversion of DGN's to DWG's would not be an issue associated with the original question.
That was about how can I know what units my file is set up in?

And as others have pointed out, all members of the team need to know what unit the work will be done in.

I get that.  However I still can't see that as an issue; IF the file was set up on the correct units for the project from the start.

This isn't to be construed as " I don;t see units, or conversion between systems of measurement as an issue."
I do, and using NASA as an example also know that sometimes conversions are not done correctly and a
multimillion dollar space probe is lost in the process.

I'm back to the same place on this, IF the file was set up on the correct units for the project from the very start, how would knowing it's units be of any benefit?  Given one continued to work in the correct units.
Unless you are grabbing information from other files that might be on other systems.  In such instances it would
be suggested that one XREF the data in with a common origin to verify that the data was in the correct place in relation to the project PRIOR to actually attempting to import it into the working file.  And even if it was in the correct
location I would suggest it STILL remain in an XREF for other data management reasons.

[sinc]

I think your point may be too subtle for me to grasp...

However, I've dealt with "drawings from others" where the Foot type was set incorrectly.  We NEVER use International Feet in Colorado, yet I've gotten C3D drawings that were set to International Feet, basically because the person who created the drawing isn't very skilled at using Civil 3D.  I *know* this affected any LandXML transfers.  It seems like it also affected DREFs, but I'd have to go back an try a test to verify.  It also has the potential to affect any output to data collectors (such as via TrimbleLink).

As such, I can actually understand the desire for an "automatic warning" if a drawing is setup incorrectly.  And at least for any project here in Colorado, "International Feet" is ALWAYS wrong.

[mjfarrell]

As such, I can actually understand the desire for an "automatic warning" if a drawing is setup incorrectly.

Except that warning would probably not do the person(s) that didn't know any good to know what units the drawing is in. As you said yourself there are those that simply don't know the difference.
So imagine the impact of a dialog box popping up on their screen that reads:

Drawing is in US Survey Feet


They click OK to dismiss the box and still haven't a clue, despite now know 'knowing' what units the file is set up in.
This isn't the same as knowing what units the project's drawings should be in and knowing where and when to verify that said drawings for the project are actually in the right units.

It would appear that what the user really requires is a single TEMPLATE that is always set to the correct units.
And, or a routine that would set the drawing to the correct units based on some file in the project folder so that it would handle US Survey feet or Meters or whatever unit that particular project was supposed to executed in.

[sinc]

It would appear that what the user really requires is a single TEMPLATE that is always set to the correct units.
And, or a routine that would set the drawing to the correct units based on some file in the project folder so that it would handle US Survey feet or Meters or whatever unit that particular project was supposed to executed in.

This veers dangerously close to triggering my "Project Rant" again...   

[mjfarrell]

It would appear that what the user really requires is a single TEMPLATE that is always set to the correct units.
And, or a routine that would set the drawing to the correct units based on some file in the project folder so that it would handle US Survey feet or Meters or whatever unit that particular project was supposed to executed in.

This veers dangerously close to triggering my "Project Rant" again...   

You and me both.

[caddcop]

We are in the beginning phases of migrating from LD to Civil3D. We do both surveying and civil design, so getting our many descriptor keys ready has been a daunting task. So, I finally got a complete version and wanted to test regular points and survey points. I have a survey flle that plots a pair of points and eventually should plot lines between the linear items.
But I noticed a difference in the coordinates between my survey points and regular points. Turns out , my civil 3d template was still set to international feet, but the default setting for a new survey network is us survey feet.
When you review the coordinates in the panorama, they both list the coordinates from the survey file. But the survey points, when reviewed in graphics, are not at the listed coordinates.
Once I changed my file units to us feet, the points aligned. Bottom line, you better be aware of the units in use of all files used in all projects!

[mjfarrell]

We are in the beginning phases of migrating from LD to Civil3D. We do both surveying and civil design, so getting our many descriptor keys ready has been a daunting task. So, I finally got a complete version and wanted to test regular points and survey points. I have a survey flle that plots a pair of points and eventually should plot lines between the linear items.
But I noticed a difference in the coordinates between my survey points and regular points. Turns out , my civil 3d template was still set to international feet, but the default setting for a new survey network is us survey feet.
When you review the coordinates in the panorama, they both list the coordinates from the survey file. But the survey points, when reviewed in graphics, are not at the listed coordinates.
Once I changed my file units to us feet, the points aligned. Bottom line, you better be aware of the units in use of all files used in all projects!

Yes, except the survey setting is not the Drawing Settings, setting that the originator of this discussion was attempting to be alerted about.
So they would really need a tool that would list BOTH the drawing settings (Units) AND the Survey database settings. Or as you point out their efforts would still yield bad results.