AutoCAD Map 3D Forum
Welcome to Autodesk’s AutoCAD Map 3D Forums. Share your knowledge, ask questions, and explore popular AutoCAD Map 3D topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Civil 3D 2013 (Map 2013) Image Issue

37 REPLIES 37
Reply
Message 1 of 38
Cadguru42
8848 Views, 37 Replies

Civil 3D 2013 (Map 2013) Image Issue

We have color GeoTIFF aerials that we've been using for 4 years without any problems until now.  In Civil 3D 2013, when I use the MAPIINSERT command to bring in the TIFFs, they are being shifted way outside of the coordinate system that's been set up.  I can do the exact same steps in all previous versions all the way back to 2006 using the same template and the images come into the correct coordinates.  It's just 2013 that shifts the images.

 

The images were obtained from the State of Tennessee and our drawings are all in Tennessee State Plane Coordinates NAD83, US Survey Feet.  I have attached two screenshots of the MAPIINSERT dialog box for both 2012 and 2013.  The same image.

 

How can I get C3D 2013 or Map 2013 to insert the images correctly?  All my units are set to foot from every dialog that I know about.  The 2013 drawing used the exact same template as the 2012 one, but just saved as 2013.  

C3D 2022-2024
Windows 10 Pro
32GB RAM
37 REPLIES 37
Message 2 of 38
Cadguru42
in reply to: Cadguru42

It looks like it's being scaled exactly 3.280839857143.  For some reason, C3D (Map) is reading the file as meters when it's in feet.  What setting am I missing to tell it the image is in feet and not meters in 2013?

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 3 of 38
Cadguru42
in reply to: Cadguru42

Forgot to attach the images of the dialog box.

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 4 of 38
Cadguru42
in reply to: Cadguru42

I've got a support request going for this, but Autodesk seems to think the images are in meters.  Just to be sure, I downloaded FWTools2.4.7 and opened one of the images.  The file's header information states that the projection is NAD83 / Tennessee with the UNIT set to "US survey foot".  To double check what I was seeing, I asked our GIS department to take a look at one of the TIFFs and see what ArcGIS 10 says the metadata information says.  In ArcGIS, the image is listed as being in Tennessee state plane NAD83 and the linear unit set to US Survey foot.  The images fall into the correct space in any other GIS program and all previous versions of C3D and Map3D.

 

Even if the image was set to meters, if Map is reprojecting the image to my US Survey Foot drawing then why is it multiplying the X and Y coordinates in the file by 3.28 instead of by 0.3048?  None of this is making any sense.

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 5 of 38
Murph_Map
in reply to: Cadguru42

Well seeing your working in the Volunteer state coordinate system I'll provide some suggestions. First I'm not using 2013 so they may not be the issue, but look at the INSUNITS, INSUNITSDEFSOURCE, & INSUNITSDEFTARGET variables.

 

Murph
Supporting the troops daily.
Message 6 of 38
Cadguru42
in reply to: Murph_Map


@Anonymous wrote:

Well seeing your working in the Volunteer state coordinate system I'll provide some suggestions. First I'm not using 2013 so they may not be the issue, but look at the INSUNITS, INSUNITSDEFSOURCE, & INSUNITSDEFTARGET variables.

 


Not sure what those variables are supposed to be.  All of them are set to <2> currently. 

 

I downloaded Lizardtech's GeoViewer 5.5 and looked at the images metadata.  GeoViewer also says the units are US survey foot.  Below is one of the file's metadata.

 

Left: 3032503
Top: 741378
Right: 3046503
Bottom: 733378

X resolution: 1
Y resolution: -1

CRS name: NAD83 / Tennessee

WKT: PROJCS["NAD83 / Tennessee",
GEOGCS["NAD83",
DATUM["North_American_Datum_1983",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4269"]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["standard_parallel_1",36.41666666666666],
PARAMETER["standard_parallel_2",35.25],
PARAMETER["latitude_of_origin",34.33333333333334],
PARAMETER["central_meridian",-86],
PARAMETER["false_easting",1968500],
PARAMETER["false_northing",0],
UNIT["US survey foot",0.3048006096012192,
AUTHORITY["EPSG","9003"]]]

 

 

 It seems like 2013 is reading either the number after the unit or the pixel density instead of the actual unit text to determine what the image's unit is.  That number that's past the "US survey foot" text is the conversion from meters to feet. 

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 7 of 38
Cadguru42
in reply to: Cadguru42

So, my case is closed, but the issue isn't resolved.  It looks like all of the Raster Designs and Map 2013 ignore the file header information regarding the image's unit.  Instead, it reads one line about the coordinate system code that relates to the EPSG number.  That number is apparently incorrect in all 111 of our aerial images for our county and possibly all of the State of TN, although how it's incorrect I still cannot figure out.

 

No other program reads these files incorrectly except for Map (C3D) 2013 and Raster Design.  ArcGIS reads the units correctly and places the images in the correct spot.  Because all previous versions of Map didn't try to reproject images, the images came in correctly because Map just treated it like a world file using the drawing's units and the file's insertion point and scale.

 

The solution for now is to make the drawing have no coordinates or projection, insert the image, then turn the coordinates back on to TN83F.  I have a feeling that we will have to do this from now in every single version of Map (C3D) unless Autodesk makes Map and Raster Design read the UNIT field in the header information.  I doubt they'll ever do that, though.  

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 8 of 38
Murph_Map
in reply to: Cadguru42


@engrtech wrote:

 

The solution for now is to make the drawing have no coordinates or projection, insert the image, then turn the coordinates back on to TN83F.  I have a feeling that we will have to do this from now in every single version of Map (C3D) unless Autodesk makes Map and Raster Design read the UNIT field in the header information.  I doubt they'll ever do that, though.  



That sounds about right. 😞

Good luck.

 

 

Murph
Supporting the troops daily.
Message 9 of 38
rasterized
in reply to: Cadguru42

Thanks for the reply, this is painful Autodesk... fix please! In the meantime, did you see any documentation that might help us adjust the image header for several hundred tiles. Ughh. 

 

Message 10 of 38
cjneper
in reply to: rasterized

Not sure if this will help you but I wrote a lisp program to avoid using Mapiinsert because it was so unreliable.  The program takes the info from the image and world file and puts the image in the right place, regardless of coordinate system.  It uses TIF and TFW files, so if you use a different image type, you will need to edit the program.  Also the directories will need to be set to fit your data.

Message 11 of 38
corboto
in reply to: Cadguru42

Don't take this the wrong way, but I'm glad you're having this problem too because otherwise I thought I was going crazy.  I have a TON of local aerial images supplied by the county's GIS that are all being inserted incorrectly.   I was pulling my hair out trying to figure out the problem--but at least I know I can insert them "correctly" now by removing my DWG's coordinate system.  

 

Hopefully this will be resolved soon, but I wouldn't be surprised if it wasn't addressed until next year's version.  Thanks for the help though.  

Message 12 of 38
Cadguru42
in reply to: corboto


@corboto wrote:

Don't take this the wrong way, but I'm glad you're having this problem too because otherwise I thought I was going crazy.  I have a TON of local aerial images supplied by the county's GIS that are all being inserted incorrectly.   I was pulling my hair out trying to figure out the problem--but at least I know I can insert them "correctly" now by removing my DWG's coordinate system.  

 

Hopefully this will be resolved soon, but I wouldn't be surprised if it wasn't addressed until next year's version.  Thanks for the help though.  


This will most likely never be resolved.  In Autodesk's view, the problem is the image itself, not their software.  Nevermind the fact that their software ignores the unit field.

 

After looking into this again, the only thing I can see that Autodesk is doing is reading the actual text of the metadata for the projection coordinate system and using that to determine the units.  In my case, it's listed as PROJCS["NAD83 / Tennessee"] when it should probably read PROJCS["NAD83 / Tennessee (ftUS)"] as how spatialreference.org lists it.  This should be just a text field for a human to read and not relied upon to project an image.

 

The whole issue, though, is that Autodesk ignores everything else in the metadata in order to project an image.  That is just lazy and is the reason why no other GIS program nor any other geoimage viewer has any problems.  They actually bother themselves to read the other fields, such as unit, datum, spheroid, etc. in order to project an image.  

C3D 2022-2024
Windows 10 Pro
32GB RAM
Message 13 of 38
cedwards8511
in reply to: Cadguru42

I am also having the problem, had it a little with 2012 too.  The images that are causing be headaches have .tfw (World) files with them.  I have five years worth of aerial imagery and each year has about 80 tiles.

 

For some reason, my Map/Civil bring in images in the wrong units.  My drawing will be set to a coordinate system/projection in feet, but the image will be inserted as 12 or 3.28 time the scale (it thinks the image is in inches and needs to be scaled up 12 times, or it thinks the image is in meters and multiplies it by 3.28 to get it into feet).

 

Typically, I can insert the drawing and then SCALE by 1/12 or 0.3048 (foot/inch or foot/meter) at the origin (0,0) and it will correct it, but this is extra steps that I shouldn't have to take.

 

My ArcGIS reads is fine and if I insert an image into CAD with my Raster Design, it works fine too, but I am the only one in the office with it. 

 

I think part of the problem is with the .tfw reference file; all they have is resolution and x/y coordinates, there is no reference to the units.  For some reason CAD is trying to assume units when all it needs to do is us what's already in the drawing.  I am going to look into creating .prj files to see if it works better, but with about 400 images to do, I don't know if that's feasible.

Message 14 of 38
cedwards8511
in reply to: cedwards8511

After playing with it for a while, I have narrowed the problem down to dwg's with a set coordinate system.

 

If I open a blank dwg, or remove the coordinate system from an existing dwg, then images load in exactly where they should. 

 

If a dwg has a coordinate system assigned to it, then CAD takes the insertion information and multiplies it all by 3.28... (like converting meters to feet), so the image is way out in space somewhere.

 

 

Anyone know why setting a coordinate system would cause this to happen or how to go about fixing it?

Thanks.

Message 15 of 38
cjneper
in reply to: corboto

Try this:  In your options menu, user preferences tab, under Insertion Scale, setting both to "Unspecified - Unitless" solved a lot of insertion issues for me.

Message 16 of 38
cedwards8511
in reply to: cjneper

Sorry, it didn't work either.  You had me exited there for a minute, I thought that would work too.

Message 17 of 38
parkr4st
in reply to: Cadguru42

What is in the   . prj file? 

 

The reason I ask i went to Tenn Gsi and downloaded hamblen county photo.  I use data connect to raster and the coord system did not read.  i edited it to tn38f and it flew off towards indiana.  I read the prj and the cood sys is utm83-17n.  i edited the coordsystem in data and connect and the photo landed dead on.  I most always check the prj with photos to make sure it matches proeprly with the inser coord sytem.

 

PROJCS["NAD_1983_UTM_Zone_17N",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",-81],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]]

 

dave

Message 18 of 38
cedwards8511
in reply to: parkr4st

My problem is that the image files (.tif in my case) don't have .prj's, they have .tfw's.

 

I have thought about creating .prj files for my images, but it will take a lot of time (five years of aerial images broken down into about 75 tiles each).  If no other suggestion work out, I probably will do it.

Message 19 of 38
antoniovinci
in reply to: cedwards8511


cedwards wrote:

My problem is that the image files (.tif in my case) don't have .prj's, they have .tfw's.


It's all right, sir.

A .TIF raster image uses a .TFW as driving worldfile, while  a .PRJ is used by vector shapefiles. 

Message 20 of 38
jhohman5
in reply to: Cadguru42

I tried the lisp routine in civil 3d.  I enter insimage to start the command right?  And then there are dialog boxes so i copy my file pat and paste it into the command line.  All that works but then it places the image at 0,0.  I'm not sure what i'm doing wrong here.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost