When I said “not typical” I mean that it’s relatively rare to have the culling distance of your mobile physics objects (ie: the ones managed by sim-eth) be the same as the culling distance for your level. Even in the case of a 2D top down view, there may be reasons you load larger parts of the level and/or a wider area for sim-eth. There are many good reasons that the radius or conditions will be different.
One approach, and the one I use for Mythruna static objects:
For your static Position components, include a calculated grid cell ID/number as one of the fields. When you setup the entity set that is watching for static objects, give it a filter on a set of cell IDs. If you update that filter whenever the view crosses a grid boundary then the entity set will automatically purge/add tiles as needed.
I mean, quite often, level geometry is not even handled at the same grid level as physical objects. You might have chunks that are already well-binned, or tiles that are much larger than what your physics ‘zones’ will be… or even an FPS where you load the whole level and then use PVS (potentially visible sets) to show/hide sections based on camera position… that has nothing to do with what you are sucking down from the client.
So the fact that you want your static level to be bound by the same filter as your dynamic objects is just a relatively rare coincidence.