Quantity parser parses Bearing angle incorrectly in some cases.

[mathieu-fournier]

parsing an incomplete Bearing

Parsing an incomplete Bearing angle result in a wrong value. Example : When typing a bearing it usually goes like this. Step by step : S S4 S45 ... S45°00'00"E

When parsing the first two letters S4, which is an incomplete Bearing because we dont know the direction yet East or West, the Parser return a value that's wrong : North something...

I think the result should be an error.

parsing an bearing with lowercase letters

When parsing a bearing with lowercase letters, it also returns a wrong value. Ex: s45°00'00"e -> result : North something...

I think the result should be a valid bearing.

Thanks

[rschili]

I agree. In addition, I have seen several special formats which are considered valid Bearings, at least some people type it like this:

• N (stands for N00°E
• NE (stands for N45°E)
• NW (N45°W) I'm a bit conflicted how smart we make this, and if we live-parse the string several times while the user is typing, at certain points in the string, it may represent a valid bearing, while others are invalid. Are we good if we follow the rule "Once there is a number specified, it only is a valid value, if the suffix is there"?

Naron will be picking this up.

[naronchen]

Hey @mathieu-fournier

the existing code does return ParseError when parsing incomplete bearing string itwinjs-core/core/quantity/src/test/BearingAzimuth.test.ts at 46b679a54bd5447b6a2258cf7473eb2b32a843ee · iTwin/itwinjs-core · GitHub

i just tested putting in "S" and "S4" and it does return an ParseError of missing prefix or suffix.

Which api was it being used that returned North something...?

[mathieu-fournier]

After some reflection, I'm not sure that it returns North something. The AccuDraw input field displays North something tho.

[hl662]

Closing this, parsing bearing with lowercase letters was introduced in https://github.com/iTwin/platform-bentley-community/issues/121

Based on this comment in another issue, it seems like AccuDraw's input fields would ignore the error our parsing uses, and switches to a different value. If this issue is still pertinent, I would file a separate issue, to investigate AccuDraw's handling of core-quantity's parsing results