Cannot use DXF with geographic coordinates
Opened this issue · 23 comments
Steps to reproduce
- Obtain ASC file from ELVIS for area of interest (in my case around -30.3151,139.3259, Arkaroola Village, or use the example file attached)
- Use QGIS to produce contours from the data. Export as DXF file (example attached)
- Import DXF file into a map in Mapper using either "Real" and "Position track at actual coordinates", Accept default symbol import settings.
- View -> "Show Whole Map"
Actual behaviour
Imported file appears as a tiny dot (that may be zoomed to fill the screen).
Expected behaviour
Imported data should appear as the set of contours contained in the DXF file.
Configuration
Mapper Version:
0.9.2 from Ubuntu 18.04 package.
Operating System:
$ uname -a
Linux F96NG92-L 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Well, we are prepared to handle DXF data in paper coordinates or projected coordinates, but not in geographic coordinates. DXF's origin is CAD, it is an abbreviation for "drawing interchange format". There is no georeferencing attached.
As a workaround, you may choose a true geospatial format such as OSM or SHP.
Just export the contours from QGIS in the GeoPackage-format. There the CRS information is included.
-> https://www.openorienteering.org/mapper-manual/pages/gdal.html
Okay, let me take a look, and thanks for the quick response.
Confirmed I have been able to select the contour layer in QGIS and export it in GeoPackage format, and then pull that into Mapper without problem.
Well, we are prepared to handle DXF data in paper coordinates or projected coordinates, but not in geographic coordinates. DXF's origin is CAD, it is an abbreviation for "drawing interchange format". There is no georeferencing attached.
It's worth a mention that although it's rare and impractical, it is not an invalid DXF file.
A DXF file actually can carry information about coordinate reference system, while this CRS naturally can be WGS84.
It's worth a mention that although it's rare and impractical, it is not an invalid DXF file.
Sure. That's why I wanted to point out what we do handle, and that I offer a workaround, not a solution ATM.
A DXF file actually can carry information about coordinate reference system, while this CRS naturally can be WGS84.
In the "Autodesk AutoCAD 2014" DXF Reference, I don't find a mention of WGS84, but I admit I find a "Geodata" chapter in the "OBJECTS Section" now.
OTOH, if you export DXF from QGIS, I suppose that QGIS uses GDAL, like Mapper does. The GDAL DXF Driver documents that it considers DXF files "to have no georeferencing information", https://gdal.org/drivers/vector/dxf.html. So the geospatial reference is lost already on export.
In the end, we don't have test data with CRS information, and we don't have a DXF driver which supports that CRS information.
Our DXF support works well with real AutoCAD drawings, such as a plan of a university campus.
OTOH, if you export DXF from QGIS, I suppose that QGIS uses GDAL, like Mapper does. The GDAL DXF Driver documents that it considers DXF files "to have no georeferencing information", https://gdal.org/drivers/vector/dxf.html. So the geospatial reference is lost already on export.
In the end, we don't have test data with CRS information, and we don't have a DXF driver which supports that CRS information.
Our DXF support works well with real AutoCAD drawings, such as a plan of a university campus.
Although I can provide a test DXF file with CRS definitions, I believe that Mapper should not reimplement the DXF driver for this reason and the geodata information handling should be upgraded on the GDAL side.
I believe that Mapper should not reimplement the DXF driver for this reason and the geodata information handling should be upgraded on the GDAL side.
Sure! If anyting at all, we would (and already do) contribute to GDAL. At the moment, there isn't even a feature request for DXF gereferencing:
https://github.com/OSGeo/gdal/issues?q=is%3Aissue+is%3Aopen+dxf
Should we throw in an issue over there?
Paul.
Should we throw in an issue over there?
Yes. However, I would insist that we do that as well prepared as possible:
- with a minimal DXF test file
- with an instruction how to verify a successful implementation by using GDAL tools only, e.g. by running a conversion or info tool with a particular expected outcome, like for another geospatial vector format which already implements georeferencing.
Ok. That's beyond my (current) experience with these things for the moment, so unfortunately I won't be able to help out (I'm just a volunteer trying to make Orienteering maps for the Arkaroola Wilderness Sanctuary, although I am a software developer as well in my other life).
That said, the zip I attached to the issue has the non-minimal DXF file that does it, so that might be a useful starting point to trim down from?
That said, the zip I attached to the issue has the non-minimal DXF file that does it, so that might be a useful starting point to trim down from?
When I looked at it, I didn't find georeferencing data, so it doesn't help for the GDAL part.
But I'm willing to add a solution on the Mapper side which lets you choose a CRS for vector data in a way similar to what is already implemented for raster data. This will be needed anyway.
I believe it is this first part of the file, on the basis that the numbers match the lat/long for the region.
Paul.
999
DXF created from QGIS
0
SECTION
2
HEADER
9
$ACADVER
1
AC1015
9
$EXTMIN
10
139.31486111152483431
20
-30.32708333346862517
30
0.0
9
$EXTMAX
10
139.36013888930295934
20
-30.29763888902395053
30
0.0
9
[Updated the last comment to reflect the line breaks.]
I believe it is this first part of the file, on the basis that the numbers match the lat/long for the region.
That's just a comment "DXF created from QGIS" and the extent of the coordinates in the file. Whether the coordinates are millimeters, inch, or degrees is undefined.
We would need GEODATA objects.
ah, gotcha. So the proposed solution you are describing would allow the user to effectively select the units/interpretation on import of such vector data formats, if I understand correctly?
BTW - Thanks heaps for making a really nice open-source tool for map making.
So the proposed solution you are describing would allow the user to effectively select the units/interpretation on import of such vector data formats, if I understand correctly?
Exactly.
Hi all,
I include here the @gardners 's DXF file enhanced with the GEODATA object. Created with AutoCAD Map 3D 2017. Just to see the difference.
I can prepare the minimal working example as well.
And for the implementation side, there is a nice Python library ezdxf which can both read and write GEODATA objects.
Here I attach three small DXF examples with just one polyline.
Three pairs of drawings -- one in WGS84 (EPSG:4326), one in S-JTSK (EPSG:5514) and one in UTM 33N (EPSG:32633).
The pairs should only differ in the GEODATA object.
@jmacura Thanks for the examples. I assume I can forward them to a GDAL issue I would create. Looking at the content it does seem a feasible effort in the context of the GDAL DXF driver. OTOH, GDAL claims to write AutoCAD 2004 format which may not allow this feature...
I just scanned this thread so I may have missed this point...
I've used QGIS for quite a while to pre-process input for OOM. I alway set the QGIS Project Coordinate Reference System to be the same one I use in OOM. I've never noticed an issue.
That being said, there probably should be an import dialog similar to the one used for templates.
That being said, there probably should be an import dialog similar to the one used for templates.
Sure. Proceeding slowly.
Thanks for the examples. I assume I can forward them to a GDAL issue I would create. Looking at the content it does seem a feasible effort in the context of the GDAL DXF driver. OTOH, GDAL claims to write AutoCAD 2004 format which may not allow this feature...
What about opening the aforementioned issue in OSGeo/GDAL? My knowledge of GDAL is very shallow, so I would prefer if you could do it @dg0yt ? Or is there anything else that should be investigated and added to the feature request?
Sorry for moving this once more.