Is there a way to produce 'world' and 'projection files'?

I’m potentially wanting to use orthophotos that I have produced with WebODM in DJIFlightplanner instead of the default GoogleEarth imagery, which is often quite out of date.

To do that I need 2 extra files along with the .tif or .png orthos.
These are world files, .tfw and .pgw, and projection files .prj.

Is there some way to produce them in WebODM?

1 Like

You can also export a geotiff in QGis to another system if that helps.

2 Likes

found this

3 Likes

I have no trouble getting the images to appear correctly in Google Earth, but need those 2 other files for them to be imported into DJIFlightplanner, does QGIS produce them?
I don’t know what the world files look like, but this is stated for the .prj files:

The projection must be in geographic coordinate system. A sample .prj file is shown here-

GEOGCS[“Geographic Coordinate
System”,DATUM[“D_WGS84”,SPHEROID[“WGS84”,6378137,298.257223560493]],PRIME
M[“Greenwich”,0],UNIT[“Degree”,0.017453292519943295]]
Local grid and other coordinate systems are not supported. We recommend the
“Global Mapper” software to re-project imagery into geographic coordinate
system, or email us for more information

Unfortunately Global Mapper is very expensive, and well beyond my budget.

Try inserting those file ending as in the post I sent you and see what happens.

1 Like

If you are familiar with command line you can use the ODM console with the gdal_translate tool:

gdal_translate.exe -co "TFW=YES" input_file.tiff output_file.tiff

It will produce a duplicate of your tiff file along with a output_file.tfw

3 Likes

Tried QGis, it can make a tfw but not the others

1 Like

OK, in QGIS 3 I can get both, although the formatting may not be correct.

Execution completed in 0.03 seconds

Results:

{‘PRJ_FILE’: 'C:/Users/OTT Drones/Desktop/WebODM- ’
‘TEMP/4/task/d08913ef-b131-45d4-95fc-497eb16813cc/assets/odm_orthophoto/odm_orthophoto.prj’,
‘WORLD_FILE’: 'C:/Users/OTT Drones/Desktop/WebODM- ’
‘TEMP/4/task/d08913ef-b131-45d4-95fc-497eb16813cc/assets/odm_orthophoto/odm_orthophoto.wld’}

.wld instead of .tfw.

What the world file needs to look like

0.00000018037287919
0.00000000000000000
0.00000000000000000
-0.00000018037287919
151.05218314970296000
-31.33279825566962300

What the file output from QGIS looks like

0.01999592
0.00000000
0.00000000
-0.01999935
314683.91328410
6531876.31377295

I don’t know what any of the numbers represent, other than the long and lat in the correctly formatted file, perhaps the last 2 lines in the QGIS file are metres offset from some point?

I’m not very knowledgeable in GIS, but perhaps someone can suggest a way to convert to the correct format?

Thanks

1 Like

The difference is between an ESRI WorldFile (which uses its own pixel origin/coordinates) and a proper, ISO standards-compliant WorldFile like QGIS/GDAL make. Also, are you certain you used the exact same CRS to generate both WorldFiles? One appears to be decimal degrees (WGS 84?) and one appears to be meters, as you noted.

Any decent program should be able to read either version.

And you can always make QGIS write out a PRJ file by choosing Define Projection in the Processing Toolbox (only if you know the right CRS for certain).

The .prj file from QGIS works, I was able to prove that by copying the world file Simon from DJIFlightplanner sent me and using it with the QGIS .prj file to successfully display my image in DJPFP.
It’s the format of the QGIS World file that is the problem.

1 Like

You need to export to epsg:4326. Then the world file will be written in decimal degrees and all will be right.

2 Likes

I think I am already in EPSG:4326, files produced like this
Extract-projection1

Extract projection

Extract-projection

this is the content of the created .prj file

GEOGCS[“GCS_WGS_1984”,DATUM[“D_WGS_1984”,SPHEROID[“WGS_1984”,6378137.0,298.257223563]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]]
The above produces the .prj and the .wld files, but there is no option that I can see for a .tfw file export, in any format.

It’s only the world file that is the problem, and I see no options for exporting, just this
export

The Append georef info (embedded or via world file) doesn’t produce anything other than the .tif, so it must be embedded, which isn’t of use.

1 Like

It seems that the export TFW is always the source layer’s CRS, despite whatever flags you have. I think this is a bug/regression, filing an issue upstream.

Possible bug...

Translate (convert format)from the Processing Toolbox should do the trick with these settings:
image

You also need to make sure your ouput CRS is EPSG:4326 since that seems to be what DJIFlightPlanner expects.

You’ll want the Additional command-line parameters [optional]:
-co TFW=YES -a_srs EPSG:4326

2 Likes

OK, tried that, which produced OUTPUT.tfw, but it is essentially the same thing with a different file name, apart from a slight increase in precision. Still no decimal degrees though.

0.0199959189
0.0000000000
0.0000000000
-0.0199993497
314683.9132840995
6531876.3137729540

Yep, there appears to be a bug where the desired output CRS is being ignored and the TFW is being generated in the CRS of the input layer.

1 Like

You can manually create the file or modify an existent TFW file,

1: pixel size in the X direction
2: Y axis rotation
3: X axis rotation
4: pixel size in the Y direction
5: upper left corner X coordinate
6: Upper left corner Y coordinate

Tipically line 1 and 4 are the same or nearly the same. And for the northern hemisphere line 4 shows negative values.

2 Likes

Indeed you can, and line 4 is negative here in the southern hemisphere too. The question is, how to convert the metres in the QGIS output to decimal degrees.
Line 2 and 3 appear to be zero in all the examples I have seen.

I notice that DroneDeploy produce several .tfw files in different formats, they sent me 5 of them for a single job done under the free trial earlier this year.

        0.0999999978
        0.0000000000
        0.0000000000
       -0.1000000001
 16802865.3390742280
 -3656766.5924199023

        0.0000004297
        0.0000000000
        0.0000000000
       -0.0000004297
      150.9427072766
      -31.1848296357

        0.0491000004
        0.0000000000
        0.0000000000
       -0.0490999999
 16802865.3136242256
 -3656776.1215984379

        0.0000004304
        0.0000000000
        0.0000000000
       -0.0000004304
      150.9428789383
      -31.1851233486

        0.0491000004
        0.0000000000
        0.0000000000
       -0.0490999999
 16802884.4228812978
 -3656814.3401125832
2 Likes

Have not had a chance to test, but this seems like the proper workflow:

1 Like

I hadn’t thought about it but yes, you’re right.

3 Likes