Inserting & Querying Aerial Imagery "Can't Transform Object" Error

[AlbrechtC]

I am trying to load aerial imagery from MassGIS into my CAD design file (using AutoCAD Map 2014). The aerial imagery is in MA83, and my CAD design file is in MA83F. Getting a "cannot transform object" error when I try to execute the query.

The steps I am taking:

1) New drawing, coordinate system set to MA83, using MAPIINSERT to bring in the aerial image (a jp2 file). Save and close.

2) Another new drawing, coordinate system set to MA83F, using "Define/Modify Drawing Set" dialog box to "Attach" my first drawing.

3) Then "Define Query", click "Location", and then set "Query Mode" to "Draw". Click "Execute Query" and that is where I get an error that says "Warning: Can't transform object". I've attached the message box with the warning/error message.

Not sure what I am doing wrong!

Thanks!

[Pointdump]

Hi @AlbrechtC,
You're not doing anything wrong.
That "cannot transform object" error just means that the Map Tools can't Query Civil 3D Objects like COGO Points, Surfaces, Alignments, etc...
For Civil 3D 2022 there's a new Coordinates Transformation Tool that will transform Civil 3D objects. It's in the Updates section of your account page.
Dave

[ChicagoLooper]

Hi @AlbrechtC 

Try this:

1. Open a brand new, clean metric template. Assign MA83 (MA State Plane, Mainland, NAD 83, meters) to the drawing.
2. Insert the jp2 image using MAPIINSERT command.
3. Turn on Bing aerial imagery.

Is Bing consistent with your inserted image?

If it doesn't match Bing, would it be possible to upload you image? It would be a lot easier to troubleshoot using the guilty image.

BTW, have you tried using a Data Connection? It's more efficient than a query.

[AlbrechtC]

@Pointdump

That is interesting that a seemingly simple aerial image contains certain objects that cannot be queried. Is there a way to remove those objects and still have the aerial image, or are they inherent to the aerial image itself? Also, unfortunately I only have AutoCAD Map 3D 2014 on my computer, without the chance any time soon to upgrade.

@ChicagoLooper 

I am not sure I know how to turn on Bing aerial imagery, or if that is even possible in the 2014 version I am using?

I have attached the jp2 file.

I do believe I tried using Data Connection and that seemed to have worked to at least transform the image into the correct coordinate system, but when I tried to xref it into my design drawing, it did not appear. That seems to have been related to the fact that the data connection turned the aerial image into an odd type of object that maybe could not be xrefed properly?

[Pointdump]

@AlbrechtC,
Thanks for posting your JP2 image.
The JP2 is in EPSG:6348 NAD83(2011)/UTM zone 19N Metric Coordinate System, and MAPIINSERT imports but does not Transform the image in an MA83F drawing. It ends up outside of the limits of MA83F. That is why the query fails. If you start off MAPIINSERT'ing that JP2 into a UTM83-19 drawing(close enough to EPSG:6348) then your steps will work.
Dave

[ChicagoLooper]

Do this:

1. Open a brand new, clean drawing. Assign UTM83-19 to modelspace.

Image-1

2. Use MAPIINSERT. It should look like this:

Image-2

3. Name this new drawing. Save and close the new drawing.

Open another brand new, clean drawing and assign MA83F.

'Attach' and perform your query.

ImGE-3Image-3

4. To turn on Bing Aerial Imagery, do this:

Image-4

[ChicagoLooper]

 Hello @AlbrechtC wrote

<<when I tried to xref it into my design drawing, it did not appear. >>

You don't need to Xref.

Use a DATA CONNECTION to insert the image directly into your design drawing.

[AlbrechtC]

@Pointdump @ChicagoLooper 

Thank you both. It looks like where I was going wrong was in the MAPIINSERT dialog box. I had always been keeping this at the default settings, which had the "Units for Insertion Point and Density" set to meters (my dialog box image attached). By setting this to feet, as @ChicagoLooper suggested, the query process worked. I am not sure I fully understand this though - I thought the MAPIINSERT command was to bring in the image in its existing units. The attach/query steps then transform that to the new coordinate system. If that is correct, I would think that the units for MAPIINSERT should match the units (in this case, meters) of the source file. Can you clarify why this is not the case?

[AlbrechtC]

@ChicagoLooper 

<<You don't need to Xref.

Use a DATA CONNECTION to insert the image directly into your design drawing.>>

Ah, I see how Data Connection works. I also just tried that method, and that worked as well!

[Pointdump]

"I would think that the units for MAPIINSERT should match the units (in this case, meters) of the source file."
I have no idea why it doesn't work like that. I couldn't MAPIINSERT that image into a Feet Drawing no matter what I tried or changed. I even tried changing Insertion in UNITS to Meters, Feet, and Unitless. Nothing I tried worked. Except starting in a Metric Drawing.
Dave

[ChicagoLooper]

@Pointdump wrote

<<Nothing I tried worked. Except starting in a Metric Drawing.>>

I agree 100%. The image won't insert accurately unless it's inserted into a drawing with a metric coordinate system. 

To get to the bottom of this problem requires a review of the procedure used when exporting the jp2 image. It would begin at the original format of the image, either when it was made or from where it was downloaded. Then the software used and parameters used to export the original image to jp2 format. The critical parameters would include

1. The native coordinate system of the image
2. The projection given to the image during export
3. The original image format
4. The target format of the exported image

Without analyzing the above we can only speculate. Here's my guess:

The original author exported an image to pj2 format. The author had many exporting paramaters at his fingertips, some were established well while others, not so much.

The author choose UTM Zone 19/NAD83_NSRS/meters aka NAD83 (NSRS2011) meters aka EPSG 6348. As @Pointdump has already alluded to, the author's target coordinate system is not in AutoCAD's CoordSys Library but using UTM83-19, which is in the library, is close enough and can be used. The author could've chose a well known CS but didn't.

The author choose (this is a guess, but an educated guess) units of feet instead of meters. He should've chose meters so the image units would be consistent with the units of the target projection. Because the software used to export the image gave him the flexibility to choose image units separately from the target projection units is where (again I'm guessing) the whackiness evolved.

It's not the end of the world, we can still substitute a well known CS for one that's not in the CS Library, we can still adjust the units of the image, we can still manipulate the modelspace environment so the image inserts properly, and we can still query to transform from one CS to another, but doing all that is more work than necessary.