Previously, I had tried several times to export a map image for import into Avenza maps. Additionally, I have been having problems with dxf exports locating in the correct location in AutoCAD. I have been pasting property boundaries into layers for export so that our drafters have a way to relocate and resize the imported layers. Being in the USA and still tied to Imperial Units, all of my work is projected as Washington State Plane North or Washington State Plane South, NAD83.

Manifold dutifully creates xml files with projection information. I opened one that I created today and noticed that the false easting in the xml is not the same as what Manifold 8 shows using Assign Projection (see attached figures).

Could Manifold be changing the false easting to meters despite the layer being projected in feet?

Attachments:
Screenshot Projection by Manifold 8.png
Screenshot xml file from Manifold 8.png

Do you mean Release 9 vs Release 8? I think it highly unlikely 9 would change feet to meters, but if you suspect that is happening, the way to analyze the matter is to carefully set up an apples to apples comparison where all details on starting and ending data and workflow used are known.

For example, create a project with the original image, carefully document each step you do (including every parameter, option, etc., specified in that process), and save the project with both the original image and the reprojected image. If a discrepancy is suspected in some exported files, provide those as well with carefully documented workflow of how they were created. Do that for both 9 and 8 if you suspect a difference, trying for an exactly equivalent re-projection in both cases. Usually, the process of very carefully noting each and every step and option reveals a difference in workflow that is the cause of a discrepancy.

Bugs happen, of course, but usually you can't surface those without first very carefully noting all details of what is being done, to eliminate an unexpected variation in workflow as the cause of a discrepancy.

Thank you, Dimitri.

This is all in Manifold 8. I haven't looked at Manifold 9's projection files yet. I am still getting comfortable with how Manifold 9 is set up, which means I can provide information in the form of PDFs much faster in Manifold 8. I have attached a dropbox link to a map file that uses a portion of an existing, larger map file. This is the information where I first noticed the discrepancy between how the layer is projected in the map file and the xml that is created on export. I have also included a dxf export with its associated xml file.

Step 1: I create a map file by importing existing GIS information from government sources. These layers are usually projected as Washington State Plane North or South, depending on which county I am working in. Some layers may come in as Lambert Conformal Conic or UTM 10N. I will project those to the map. Having Manifold 8 project these layers on the fly can cause a performance hit, especially with large image files.

Step 2: I select the layers I wish to export (either vector or raster). As stated for Step 1, these have all been re-projected to the map's projection. I almost always use the Assign Projection function to specify the imported layer's projection without changing any parameters, then use the Project to Map command from the layer's tab in a map.

Step 3: I use the export command in the File tab, occasionally using the export command by right-clicking the layer itself.

If I am exporting to dxf, the layer imported into a CAD file will not load in the correct location (when the CAD file is using real world coordinates). I have resorted to pasting parcel line work onto the export files so our drafter's can move it to the correct location and proper scale. I previously mentioned the same issue when exporting projected imagery.

https://www.dropbox.com/scl/fi/gjfiw5owtawsbsmfvjw8s/Projection-in-Manifold-8.map?rlkey=ocm3fv3mc52vtieegw67ctyrp&dl=0

Attachments:
Unavoidable Buffer Impacts for Export.dxf
Unavoidable Buffer Impacts for Export.xml

Sorry for the late reply. I have been travelling and struggling with really poor Internet. I switched to 9 so long ago that I don't remember the details of 8 for projections very well, so I can't help you much with this (other people on this forum no doubt could advise you better).

Keeping that limitation in mind, my gut feel is that your problem has to so with some small detail not being done right in the workflow, either in how the initial re-projection was done in 8 (try different options, like Preserve local values), or having to do with documented or undocumented details as to how the CAD system you're using imports projected info, etc. One reason I have that impression because you're describing not one specific instance but several problems (since you mention both raster and vector), and it's highly unlikely that a common bug is popping up in such radically different workflow. But it's very routine that issues in workflow cause coordinate system interchange problems between GIS and CAD packages.

Usually, the quickest way to find the correct workflow is by focusing on specific details for a specific example.

Start with a specific vector layer that is imported from a specific, original file. Keep a detailed log of your workflow for that layer, every dialog and every setting in every dialog from beginning to end, from the original file you downloaded all the way through to the specific file created for export. Next, keep a detailed log of your workflow for that exported file into your CAD program. If something isn't the way you want in your CAD program, repeat the entire process starting from the original file but making just one change in the workflow, for example, like changing one option / checkbox when you assign the projection, reproject, or whatever. Focus on getting that one file correctly into your CAD program and then you'll have a basic workflow example that will be easier to adapt to other vector or raster layers. I'd start with a vector layer since interchange to a CAD system can be a lot more complicated with rasters.

I couldn't follow in your description what, precisely, was done for a specific file as you refer to both vectors and rasters. In the example project, I don't know which of the layers in the Map are the troublesome ones.

It's also important to stick to a single package, to try to debug one workflow at a time. For example, if you export something from Release 8 and then re-import the exported file back into Release 8 and it doesn't show up in the same spot, that's something that's actionable entirely within the 8 universe and within the collective expertise of this forum. But if you export a file from Release 8 into myCAD Plus and in myCAD Plus it doesn't appear where you expect, well, then you're also debugging workflow in myCAD Plus. That could be two separate workflows to debug, with this community unable to help with myCAD Plus.

Especially with CAD systems (which are notoriously troublesome when it comes to projected data) there are all sorts of details involved in getting them to display projected information correctly. Pretty much every online forum for every GIS package has posts complaining about interchanging projected vectors or rasters with some CAD system (with posters dissing the CAD system...), and pretty much every CAD forum has threads about all the problems importing data from some wretched GIS system (with posters dissing the GIS system...).

A practical problem is that most CAD systems have no capability to import projection-aware formats like GPKG for vectors or GeoTIFF for rasters, so they have to use sidecar files as hacks. GIS systems usually can work with variations in coordinate systems that are basically equivalent, like using local offsets or scales, while CAD systems usually cannot handle such equivalencies. Hacks like using XML sidecars to convey projection information are not always a sufficient to tell the CAD system what it must do in such cases. You might have to use 8 or 9 to cast the layer into a form that is not just georeferenced in Manifold, but which also is in an equivalent form that the CAD system can understand.

When Release 8 exports a projected drawing to a DXF, it exports a sidecar .xml file. When 9 exports a projected drawing to a DXF it exports a .prj. You might try using 9 for your DXF exports to see if the CAD system you're using understands the .prj better. For example, the XML uses scientific notation, as in

<centerLat>4.700000000000000000000000e+01</centerLat>

... which might confuse a CAD system. PRJs arose as a tradition during the times of primitive GIS packages so they use simpler words, like one does when talking to a child:

PARAMETER["Standard_Parallel_1", 47.5]

... the CAD system might be able to handle that better. Most CAD systems that claim to be able to read projected info are better at understanding .prj, since that is a very old convention.

All fair points. I should have lead with the vector issue first. Please be patient since it may be a day or two before I can circle back around to this issue. The confounding part to me is that "it worked before, why is it not working now." It could easily be that AutoCAD made an "improvement" to their import routine. Something I have considered, but since I am not a "CAD jockey," I have no way of troubleshooting from that end.

I will try to export to DXF from 9 to see if that solves the issue.

The confounding part to me is that "it worked before, why is it not working now." It could easily be that AutoCAD made an "improvement" to their import routine.

Could be. But more likely it is something different about the workflow now, such as checking or not checking an option box.

I'm circling back to my issue. Here is my workflow for exporting to DXF from Manifold 8.

1. Select drawing crated in Manifold 8 to export to DXF. The drawing's location has been confirmed on the map and was generated from LiDAR data that has been assigned the map's coordinate system (Washington State Plain North, NAD83). I make no changes to the projection (Figure 1 and 1a).
2. I import the DXF into DWG Viewer 2024 (I do not have a license for a version of AutoCAD) (Figure 2). Figure 3 is a screen capture of the master project CAD file created by professional surveyors.

I make no changes to the projection of the drawing. The file is exported using the File/Export command. Right-clicking and choosing Export does not result in a different result.

Here is the workflow for exporting to DXF from Manifold 9.

1. Select drawing created in Manifold 9 to export to DXF. The drawing's location has been confirmed on the map and was generated using LiDAR data that has been assigned to the map's coordinate system (Washington State Plain North, NAD83). As with Manifold 8, I make no changes to the projection (Figure 4).
2. I import the DXF into DWG Viewer (Figure 5).

There are no boxes to check or uncheck when exporting files from Manifold 8 or 9. Manifold 8 will create Z values from "Height" when exporting topographic lines to DXF. This would be the only box that gets checked.

The workflow and figures I have provided relate only to exporting Manifold data to DXF format. I still have not successfully resolved importing map images created with Manifold (8 or 9) to Avenza maps. Images created with either version of Manifold export with a false easting that does not correspond with the drawing layer's projection. That said, I would like to get the DXF export issue resolved first since it does affect what our drafters do.

Guessing that your post didn't have the images (figures).

Any chance you can post data?

Well, that's embarrassing. I added a Dropbox link to my previous message but it seems to have been stripped. I compiled a series of screenshots and attached them to this post. I used default settings in all cases of export and import to and from Manifold 8 and 9. I also posted the dxf files that were created to show how exports from Manifold 8 or 9 do not align correctly to an AutoCAD file where the layers use real world coordinates. I will need to try to attach another Dropbox link because the dxf files are too large to post.

https://www.dropbox.com/scl/fi/5xjh1442u6viov0sav3al/Projection-Issues.pdf?rlkey=30u0dpbevt3qqcggdcz7farf3&dl=0

Attachments:
Projection Issues.pdf

Seems like your units got crosswired. figure 1: shows the 1.6bill number as an offset. I notice that your units are set to US Survey feet. And that your local scale shows pixel size of 3.010, which is effectively a yard by your units. However if you divide not 3.010 into 1.6bill number, but the 3.28 (ft/meters) you land right close to 500000 a typical offset for a meters based projection. Since these are contours, they likely would have inherited the raster source's projections. When applying the StatePlane projection, couldn't they have gotten incorrectly adjusted, like the adjust for units when not needed. I have had some foul ups with stored favorites and crosswired parameter. This was the first I looked at.

That is a better articulation of what I think is going on. That said, when I do these exports, I do not make any changes to the projection information.

The issue with the topographic information is that the LiDAR imagery imports into Manifold with the 3.010 scaling factor. Manifold 8 initially needs to have its projection information re-blessed using the LiDAR data provided by Washington State. After that, I do not touch the projection information. All layers and images that use the LiDAR file will be based on the projection correction I assign to the data (based, of course, on the metadata file for the LiDAR flight).

I do make sure that all the layers in a Map have the same projection. Manifold 8 can project on the fly, but the cost in time for the re-projection can be enormous, especially when several layers have projections that do not match the Map's projection.

What I am confused about is why Manifold would take a layer showing a certain false easting and export it with a different false easting, or why when I import from Manifold 8 to Manifold 9 or from 9 to 8, the layer ends up in a completely different part of the continent. Sometimes I can fix the issue, other times it seems as if the data are unrecoverable.

I like Manifold in that it does not require extensive knowledge of GIS to get a usable product (especially with Manifold 8). I know enough to get usable data and have taken on-line courses to get more knowledgeable. However, when the "point-n-click" doesn't work as expected, I end up spending too much time determining where the issue lies.