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