Field shows different coordinates than actual point

[cadtag]

>>you will say that the origin that point is referencing can be found by drawing a line from the point using negative coordinates such as -5,-10

If you use negative 'relative' coordinates, you would get back to 0,0 (5 -5 = 0, 10 -10=0)

using negative 'absolute' coordinates would put you 5' to the left of 0,0, & 20' below 0,0.. note that all your lines pass through 0,0 - the origin of the
UCS ( and the datum location for FL NAD 83 East Ft state plane)


Re setting UCSIcon at origin. doesn't work out in civil, when the origin (0,0,0) is tens of thousand of feet away from the drawing area. I'd need a much much much bigger monitor.

Special caveat RE: Bing imagery. I've found many locations in Fl where the Bing 'georeferenced' imagery was substantially off. Naples was out by 20 miles IIRC, & Dade City several miles. 20 to 200 ft is not uncommon.... 2015 does appear to be better, but if you're in Florida, FDOT has much more reliable aerial imagery available. Remember that Bing was originally developed for GPS turn by turn driving.

[cadtag]

I think your pro-tip applies to many types of work - or just any cad work overall. I usually like to have the UCS at the origin.

The file is in Feet. And does land properly on the "world" based on its geo-coordinate system.

I am have to say that I am not a civil engineer - nor do I play one of tv. I am actually an Architect trying to understand how civil files are created to make sure that when I coodinate with project with my consultants our files coincide.

And speaking as a Civil nerd... Thank you!!!

[crullier]

I see what you are saying about the relative and absolute coordinate.
I have run into another software discrepancy. In plain Autocad I can use the "maps" to apply a coordinate systems to a car file. Well guess what, autocad sets the "pin" location as the 0,0 in that file. Now if you take a blank file in civil 3d and you apply the same coordinate systems and file A, and you xred file A into the Civil 3d file, you are way off unless you check "Locate using Geographic Data" .. why can't Autodesk just make it easy.

The problem here is that my exported CAD drawing from Revit will fall into place in CAD file A, but will not in the Civil 3d file.

[cadtag]

yeah, the geomaps feature is really messed up in vanilla. Basically it's mapping an arbitrary xy point in the drawing to a lat-long. so has zero relationship coordinate-wise to every other possible mapping that used professionally. The 'locate using geographic data' is a work-around to the inability to assign a real coordinate system outside of Map3d or Civil3d.

[crullier]

yeah, the geomaps feature is really messed up in vanilla. Basically it's mapping an arbitrary xy point in the drawing to a lat-long. so has zero relationship coordinate-wise to every other possible mapping that used professionally. The 'locate using geographic data' is a work-around to the inability to assign a real coordinate system outside of Map3d or Civil3d.

Yes, at least it works to get a drawing back to the correct place on the Civil cad environment.

On a civil 3d cad file, is it save to say the drawings origin becomes the originating point for all the coordinates of point on the site depending on the different coordinate system use?

[BlackBox]

And speaking as a Civil nerd... Thank you!!!

1+

The world (and my work specifically ) would be better off, if there were more Architects like crullier.

Cheers

[crullier]

thanks.

Gentleman correct me if I am wrong, Is the reason why then I drew lines from the points on my sites back to the origin, (using relative negative values) is because the CAD enviroment is a flat projection and therefore depending on where the site point is, it seems that the datum is in a different place but in "reality" if you look at the earth, all those origins are in the same place?

I am trying to make sense out of what is going on on one of my earlier posts.

[BlackBox]

Don't confuse two separate systems - datum (elevation), and coordinate system (horizontal) - it's the two combined that place your project into "real" space, on the Earth.

So for example, and each locale is different because of their particular magnetic North, geodetic calculations, etc., we primarily use NGVD 29 datum, with a coordinate system of FL83-WF (or Florida State Plane, West Zone, US Foot)... This helps me to consume available resources, such as County GIS (not as accurate as formal survey, mind you), Aerials, Lidar, Benchmarks, etc., within the confines of a given project's boundary.

[Edit] - This may help: Civil 3D - Specifying Units and Zone Settings

[crullier]

Don't confuse two separate systems - datum (elevation), and coordinate system (horizontal) - it's the two combined that place your project into "real" space, on the Earth.

So for example, and each locale is different because of their particular magnetic North, geodetic calculations, etc., we primarily use NGVD 29 datum, with a coordinate system of FL83-WF (or Florida State Plane, West Zone, US Foot)... This helps me to consume available resources, such as County GIS (not as accurate as formal survey, mind you), Aerials, Lidar, Benchmarks, etc., within the confines of a given project's boundary.

[Edit] - This may help: Civil 3D - Specifying Units and Zone Settings

I did not realize the difference in nomenclature. Now I know not to mix Datum with Coordinates.
Please forgive me ignorance, the way I understood the civil coordinates (Nothings and Eastings) or X,Y coordinates of a point on my civil Georeferenced file was that those point were relative to a point somewhere within the state plane "plane". Let's say there is imaginary point somewhere within one other counties FL83-WF encompasses to where all those coordinates tie back into (0,0). Again, no one thought me this, so my logic while good for mathematics may be good, it may be way off in reality.

This is why when I had a point at the coordinates of 893231.xx , 530335.xx I thought that by drawing a line from that point back using the negative valuves -893231.xx , -530335.xx I would find the origin of my coordinate system.
But it appears that I do not. All the point from 3 different site I xrefed in (I check all units and coordinates) to not end in the same point. They rather intersect on autocad's 0,0. See my 3rd post I believe.

[BlackBox]

I did not realize the difference in nomenclature. Now I know not to mix Datum with Coordinates.

We all start somewhere, and I'm sure that even I have a great deal to still learn.

... the way I understood the civil coordinates (Nothings and Eastings) or X,Y coordinates of a point on my civil Georeferenced file was that those point were relative to a point somewhere within the state plane "plane". Let's say there is imaginary point somewhere within one other counties FL83-WF encompasses to where all those coordinates tie back into (0,0). Again, no one thought me this, so my logic while good for mathematics may be good, it may be way off in reality.

This is why when I had a point at the coordinates of 893231.xx , 530335.xx I thought that by drawing a line from that point back using the negative valuves -893231.xx , -530335.xx I would find the origin of my coordinate system.
But it appears that I do not. All the point from 3 different site I xrefed in (I check all units and coordinates) to not end in the same point. They rather intersect on autocad's 0,0. See my 3rd post I believe.

When it comes to understanding Civil engineering, simple, and complex are not necessarily mutually exclusive.

Generally speaking, the origin of any given coordinate system (in CAD, not the real world), is 0,0... It is when you have three drawings, in three different coordinate systems, that this introduces complexity, and the implicit task of correlating them about common/known points.

For example, I frequently receive record/survey drawings that are accurate within themselves, but based upon an arbitrary coordinate system, and do not necessarily line up with my accepted boundary survey in State Plane. I then need to account for an architect's drawing's scale/units (generally inches-->feet), and likely correlate that about a right-of-way line, an easement, or if worst case scenario a utility pole & aerial! Haha