simBrief ignoring navaid type/mismatch when validating route

[Rodeo314]

For example,

DNMM […] BUT ATS32 IRO ATS17 KIMKO […] HUEN passes SB validation even though it’s not actually valid.

BUT ATS32 IRO is valid (IRO NDB here)

IRO ATS17 KIMKO is valid (IRO VOR there)

BUT ATS32 IRO ATS17 KIMKO is invalid, because the two airways do not actually share the same IRO navaid

I guess it’s not necessarily an easy fix, but it’s pretty annoying, as the error then happens later in e.g. custom aircraft with a more robust route parser, whereas it would be much more useful to catch the error earlier, at the simBrief stage.

Regards,

Tim

[SimBrief]

Hi Tim,

Thanks for the report. This will be a bit complicated to fix so it might take a while, but I’ve added it to the to-do list.

Best regards,

[Rodeo314]

In the meantime, that route is still being offered; is there any chance you could programmatically remove from your database all routes containing ATS32 IRO ATS17 specifically since we know it’s not actually valid?

Regards,

Tim

[SimBrief]

@Rodeo314

In the meantime, that route is still being offered; is there any chance you could programmatically remove from your database all routes containing ATS32 IRO ATS17 specifically since we know it’s not actually valid?

Done. Still haven’t looked at the route validator, will do so when time permits.

Cheers,

[Rodeo314]

I am currently checking all my old topics and marking them as solved when applicable.

This issue still exists, however.

I’ve noticed it also exists in Navigraph Charts, which also happily accepts and draws:

DNMM DCT BUT ATS32 IRO ATS17 KIMKO DCT HUEN

…but the map depiction shows it’s not actually following ATS32 (it’s a “direct” instead, so to speak):

Regards,

Tim

[SimBrief]

Hi Tim, this should be fixed in SimBrief now.

Not sure yet on a timeline for fixing it in Charts however.

Best regards,

[Rodeo314]

Fix appears working on my end. Thanks!

Should I file a separate topic for the Navigraph Charts issue?

Regards,

Tim

[SimBrief]

That might be better actually, since it’s an entirely different API and different team that works on it. Creating a separate topic might increase visibility rather than simply moving this one.

Best regards,