Should WorldPartitionNavigationDataBuilder initial IterativeWorldBounds using NavigationBounds instead of EditorBounds?

I found a variable IterativeWorldBounds in UWorldPartitionBuilder, when call UWorldPartitionBuilder::Run function, by default, it will use WorldPartition->GetEditorWorldBounds() as CellInfo.EditorBounds. While IterativeWorldBounds is Valid, it will use IterativeWorldBounds as CellInfo.EditorBounds.

I have seen only UWorldPartitionMiniMapBuilder override the variable IterativeWorldBounds in PreRun function, it use WorldMiniMap->GetMiniMapWorldBounds() instead of EditorBounds to calculate CellInfo.EditorBounds.

if we generate navigation in a very big world, and the world bounds is huge, but our navigation bounds is small than the world. So if i generate navigation in this world,it will iterate many times for nonavigation and useless place.

In this situation, I think it will be better to use navigation bounds as IterativeWorldBounds not editor bounds in UWorldPartitionNavigationDataBuilder. So i want to know if engine has considered to do this for optimizing navigation build in big world.

I personaly add this code in UWorldPartitionNavigationDataBuilder::PreRun, it seems to be working fine for generating navigation.

the code is

// World bounds to process  
UNavigationSystemBase* NavSystem = World->GetNavigationSystem();  
if (NavSystem == nullptr)  
{  
UE_LOG(LogWorldPartitionNavigationDataBuilder, Verbose, TEXT("No navigation system to generate navigation data."));  
return false;  
}  
IterativeWorldBounds = NavSystem->GetNavigableWorldBounds();

but I don’t know if it is right way to optimize navigation building