Technical Note Fledermaus: Ensure BAG import/export consistency

Summary

Version 7.7.3 of the Fledermaus Suite, released January 23rd, 2017 includes a fix in the BAG import/export functionality for DTM and other surface type files.

What are the changes:

The Fledermaus BAG had a bug that resulted in offsets incorporated to the BAG, not completely honoring the bounds of the original data that generated them. The following is a guide as to how to ensure and review the BAG's previously generated, or generated by a 3erd party package.

The best to review and test that any BAG (written or read) is honoring data from an initial surface is by reviewing the raw BAG metadata. A BAG is usually created with an XML file that will contain is spatial reference information specified in the: <gmd:spatialRepresentationInfo> section. This information is used to geo-position the data that is made reference too in the file. If this data is not consistent with the formulation below then product readers or writers, have a small positioning problem. The key information given for a BAG as part of the XML metadata is the surface dimensions, cell sizes, and lower left cell center and upper right cell center.

Let llx and lly be the lower left cell center and urx and ury be the upper right cell center given in the XML file. QPS's understanding of the parameters is shown in the following diagram:

Figure 1. BAG spatial reference definitions

The blue box represents the edge to edge bounds of the overall BAG surface while the dashed red line represents the cell center to center bounds. It is the red box that the numbers in the XML corner point representation provides. i.e from the a BAG's XMl file (example):

CODE

<cornerPoints> 
	<gml:Point> 
	<gml:coordinates cs="," ts=" " decimal=".">392621.42,4675407.34 416466.42,4694052.34</gml:coordinates> 
	</gml:Point>
</cornerPoints>

Thus, the expectation is that:

ncols = ( (urx – llx) / xcellSize ) + 1
nrows = ( (ury – lly) /ycellSize ) + 1

The plus one is because the bounds are cell centers not cell edges. You would then compare the computed rows and columns above from those specified in the metadata and expect them to match. If so then all this key metadata is consistent as expected.

In Fledermaus, when you go to export data as a BAG file, in the dialog where you can enter ancillary text, check the "Review Metadata option" and when that dialog is presented scroll down and look at the georeferencing corner points and make sure they match the bounds noted into the bounds tab. This is valid for all Fledermaus data types with one exception: the PFM produced bags the bounds in the review panel are cell center bounds where as the bounds panel will be edge to edge so the cell center ones in the Review dialog should be a 1/2 cell smaller for each corner.

Any produced BAG's can be reimported into Fledermaus via the Import, Gridded Data option and should line perfectly with the originating data assuming that, you are in "Plates" mode for both the original SD object and the re-imported BAG file imported BAG data.

With these test you can fully verify Fledermaus is internally consistent with the export/import process. This tests allow to also verify consistentency with a 3erd party produced BAG file.

If the original data, BAG file you are testing, is not accompanied by its metadata XML file, you can use Fledermaus FMCommand to extract it from the BAG. The bagtoascii cmdop; will allow users to get the XML file:

CODE

cmdop bagtoascii -in myfile.bag -out myfile.bag.xyz -xml

This will produce two files:

myfile.bag.xyz (which is a ascii file of all the bag cell center values), and
myfile.bag.xml (with the XML metadata which you can look at in a text editor to see dimensions, cell size, and cell center corner points.)

Who does this impact:

You are impacted by this fix if your workflow includes the import and export of a BAG for delivery or production; or any use in Fledermaus.