Migrate obstacle CSV to the new format
*Created by: svoop*
The Obstacle CSV is now [specified as part of OFMX here](https://github.com/openflightmaps/ofmx/wiki/Obstacle-CSV). However, there are a few minor differences in comparison to the rather informal CSV used up to now.
In summary, the breaking changes are:
* CSV must adhere to [RFC 4180 and OFMX standards](https://github.com/openflightmaps/ofmx/wiki/OFMX-CSV): Review how `,` and `"` which are part of the payload (not the CSV structure) are escaped, the backslash `\` (ASCII code 92) is *no longer* used as escape character!
* New header record and updated field order
* New field `txtRmk` for free-text remarks
### Header Record
The first line must contain the header record exactly as [specified here](https://github.com/openflightmaps/ofmx/wiki/Obstacle-CSV).
### Data Records
All subsequent lines have to be migrated according to the following map. The ordinals describe the position of the corresponding field.
| Old Format | New Format | Translation
|------|----|------------
| *nonexistent* | 1. `codeId` | new field: integer ID unique within the context of this CSV (e.g. "line number - 1")
| 5. `type` | 2. `codeType` | assure valid value: either `ANTENNA`, `BUILDING`, `CHIMNEY`, `CRANE`, `MAST`, `TOWER`, `TREE`, `WINDTURBINE` *or* `OTHER` (specify in remarks)
| 3. `name` | 3. `txtName`
| 6. `lighted` | 4. `codeLgt` | convert: *true* => `Y` (yes, obstacle is lighted), *false* => `N` (obstacle is not lighted) *or* empty (unknown)
| *nonexistent* | 5. `codeMarking` | new field: `Y` (yes, obstacle has markings), `N` (no, obstacle has no markings) *or* empty (unknown)
| *nonexistent* | 6. `txtDescrLgt` | new field: description of the lighting (e.g. color)
| 7. `markingDescription` | 7. `txtDescrMarking`
| 11. `latutide` | 8. `geoLat` | use [OFMX notation](https://github.com/openflightmaps/ofmx/wiki/Coordinates) with postfix `N`/`S` instead of positive/negative numbers
| 12. `longitude` | 9. `geoLong` | use [OFMX notation](https://github.com/openflightmaps/ofmx/wiki/Coordinates) with postfix `E`/`W` instead of positive/negative numbers
| 15. `lateralPrecision` | 10. `valGeoAccuracy`
| *nonexistent* | 11. `uomGeoAccuracy` | new field: use `M` (meters)
| 10. `elevationValue` | 12. `valElev` | convert to unit specified in `uomDistVer`
| 14. `verticalPrecision` | 13. `valElevAccuracy` | convert to unit specified in `uomDistVer`
| 9. `heightValue` | 14. `valHgt`
| 13. `defaultHeightFlag` | 15. `codeHgtAccuracy` | convert: *true* => `N`, *false* => `Y` :warning: boolean reversed!
| 8. `heightUnit` | 16. `uomDistVer` | assure valid value: either `FT` (feet) *or* `M` (meters)
| 17. `obstacleRadius` | 17. `valRadius` | convert to unit specified in `uomRadius`
| 16. `obstacleRadiusUnit` | 18. `uomRadius` | assure valid value: `FT` (feet), `KM` (kilometers), `M` (meters) *or* `NM` (nautical miles)
| 1. `codeGroup` | 19. `codeGroupId` |
| 4. `groupDescription` | 20. `txtGroupName` |
| *nonexistent* | 21. `codeLinkedToId` | new field: `codeId` of another obstacle this obstacle is physically linked with (replaces the old `groupInternalId` / `linkedToGroupInternalId` mechanism)
| 19. `linkType` | 22. `codeLinkType` | assure valid value: `CABLE` (e.g. power line or cableway), `SOLID` (e.g. concrete or wood) *or* `OTHER` (specify in remarks)
| 21. `EffectiveFrom` | 23. `datetimeValidWef` | use [OFMX datetime notation](https://github.com/openflightmaps/ofmx/wiki/Dates-and-Times#datetime)
| 20. `ValidUntil` | 24. `datetimeValidTil` | use [OFMX datetime notation](https://github.com/openflightmaps/ofmx/wiki/Dates-and-Times#datetime)
| | 25. `txtRmk` | new field: free-text remarks
| 22. `origin` | 26. `source` | use [OFMX source notation](https://github.com/openflightmaps/ofmx/wiki/Features%2C-Components-and-Properties#source)
issue