Data quality checks before upgrading to V6.0
Invalid / space coordinates
| How To |
|---|
|
{{#if:Space coordinates | |}}{{#if:MGRS coordinates | |}}{{#if:Coordinate display rules | |}}{{#if:Point ID Length | |}}{{#if:Missing approval information | |}}{{#if:Missing Date of Information | |}}{{#if:|
|
It was not possible to upgrade to V5.08.04 if there are invalid coordinates in the database. Please run this SQL query anyhow because importing may overrun application rules. If you get any rows here, you have more SQL queries that will identify which object has the invalid coordinates in “Invalid_coordinates_ver2.doc” on PI.
MGRS coordinates
In V5.xxx it was possible to enter MGRS with wrong format. The first query checks for coordinates written with lower-case letters e.g. 4qfj12345678 and the second query checks for blanks e.g. 4 QFJ 1234 5678.
Coordinates display rules
In IMSMA NG there are 3 rules on how to handle and display coordinates, based on how they were entered;
- MGRS,
- Distance/Bearing
- X and Y.
When data has been migrated or imported it is possible that the column userinputformat in the table geopoint, which controls coordinate display, has not been set correctly. When the display field is set correctly the columns are high-lighted with yellow. If the user tries to edit a row which does not have one of the rules set, the coordinates will not be populated in the Point window. This issue only affects the edit of Auxiliary data coordinates and Data Entry Forms in the Workbench.
Length of Point ID
Point (local) ID should be unique and clearly identify single and polygon points. But it is possible to type blanks instead of characters/numbers. If spaces have been used it is not possible for the users to see difference when entering/editing the points. If you get length 0, 1 or 2 I recommend to look into the values of Point ID.
Missing approval information
Due to changed behaviour of migration/import scripts in version 5.08.02 and a bug in 5.08.04 approval information may be missing.