To me there seem to be something strange in handling of location indicators. Or I just don't understand it right.
I think setting properties of UnitPropertyGroup or Airspace that are not present in the TAC message should not be in responsibility of the parser. Instead, unavailable properties could be made Optional in the model and subject for completion by the library client after parse. This is how similar case with Aerodrome property of AerodromeWeatherMessage is handled e.g. in TAF parser.
All the hardcoded Airspace and UnitPropertyGroup should be removed.
The parsing of airspace and other location indicators seems wrong to me. I'm not sure, but maybe all designators should be parsed as AERODROME_DESIGNATOR identity (ICAOCode lexeme class), and remove any other designator lexeme types?
Also the parsing of airspace name seems somewhat problematic. It also seems, that current tools in the library may not fully support this case, as we would need to parse one or more words followed by airspace type (e.g. FIR). Also, I would avoid naming lexeme classes and identities related to word FIR, but instead favor terms like ATS region (Air Traffic Services) or airspace or something.
To me there seem to be something strange in handling of location indicators. Or I just don't understand it right.
UnitPropertyGrouporAirspacethat are not present in the TAC message should not be in responsibility of the parser. Instead, unavailable properties could be madeOptionalin the model and subject for completion by the library client after parse. This is how similar case withAerodromeproperty ofAerodromeWeatherMessageis handled e.g. in TAF parser.AirspaceandUnitPropertyGroupshould be removed.AERODROME_DESIGNATORidentity (ICAOCodelexeme class), and remove any other designator lexeme types?_Originally posted by @petringo in https://github.com/fmidev/fmi-avi-messageconverter-tac/pull/117#discussion_r989808843_