If the output type is a kind of height, then the target height is not needed by the custom code, since the output heights represent the viewshed bottom surface, and whether the target is higher is determined by the calling TargetLineOfSightOperator.

If the output type is Other, your Prepare method does need to figure out the target height, and there are alternatives. To do it in the usual way for TargetLineOfSightOperator, the method must assume that the z coordinate of the target feature gives the altitude above sea level. But if it is more convenient, the Prepare method could use a different convention, like assuming that some target attribute gives the target height above ground (as is done in the custom propagation sample). So there is a tradeoff: sticking to the usual way could make the custom propagation object easier to understand for a configurator, while another way can be more practical if the configurator is aware of it.

All update attributes used by the custom code should be documented, so that the application developer can write code that ensures that a new value for any of them will trigger a call to Operator.FlushCache on the operator.

Or, the custom code can refrain from using any update attributes, because the application developer can emulate similar behavior:

• Instead of a global update attribute, the application developer can use an observer attribute that has the same value for all observers, a value that is changed uniformly for all observers when necessary. Remember that a MemoryDataSet must be locked by a Guard before its features are modified.

• Or, instead of modifying all observer features, an AttributeOperator can be used to copy a global update attribute to a new feature attribute. If the observer features are needed by both a LineOfSightOperator and a TargetLineOfSightOperator, one can let their observer inputs be references to a SplitOperator left of the AttributeOperator. With this design, the application can modify a relevant update attribute without doing anything else.

If the output type is a kind of height, then the target height is not needed by the custom code, since the output heights represent the viewshed bottom surface, and whether the target is higher is determined by the calling TargetLineOfSightOperator.

If the output type is Other, your prepare method does need to figure out the target height, and there are alternatives. To do it in the usual way for TargetLineOfSightOperator, the method must assume that the z coordinate of the target feature gives the altitude above sea level. But if it is more convenient, the prepare method could use a different convention, like assuming that some target attribute gives the target height above ground (as is done in the custom propagation sample). So there is a tradeoff: sticking to the usual way could make the custom propagation object easier to understand for a configurator, while another way can be more practical if the configurator is aware of it.

All update attributes used by the custom code should be documented, so that the application developer can write code that ensures that a new value for any of them will trigger a call to Operator::flushCache on the operator.

Or, the custom code can refrain from using any update attributes, because the application developer can emulate similar behavior:

• Instead of a global update attribute, the application developer can use an observer attribute that has the same value for all observers, a value that is changed uniformly for all observers when necessary. Remember that a MemoryDataSet must be locked by a Guard before its features are modified.

• Or, instead of modifying all observer features, an AttributeOperator can be used to copy a global update attribute to a new feature attribute. If the observer features are needed by both a LineOfSightOperator and a TargetLineOfSightOperator, one can let their observer inputs be references to a SplitOperator left of the AttributeOperator. With this design, the application can modify a relevant update attribute without doing anything else.

If the output type is a kind of height, then the target height is not needed by the custom code, since the output heights represent the viewshed bottom surface, and whether the target is higher is determined by the calling TargetLineOfSightOperator.

If the output type is Other, your prepare method does need to figure out the target height, and there are alternatives. To do it in the usual way for TargetLineOfSightOperator, the method must assume that the z coordinate of the target feature gives the altitude above sea level. But if it is more convenient, the prepare method could use a different convention, like assuming that some target attribute gives the target height above ground (as is done in the custom propagation sample). So there is a tradeoff: sticking to the usual way could make the custom propagation object easier to understand for a configurator, while another way can be more practical if the configurator is aware of it.

All update attributes used by the custom code should be documented, so that the application developer can write code that ensures that a new value for any of them will trigger a call to Operator.flushCache on the operator.

Or, the custom code can refrain from using any update attributes, because the application developer can emulate similar behavior:

• Instead of a global update attribute, the application developer can use an observer attribute that has the same value for all observers, a value that is changed uniformly for all observers when necessary. Remember that a MemoryDataSet must be locked by a Guard before its features are modified.

• Or, instead of modifying all observer features, an AttributeOperator can be used to copy a global update attribute to a new feature attribute. If the observer features are needed by both a LineOfSightOperator and a TargetLineOfSightOperator, one can let their observer inputs be references to a SplitOperator left of the AttributeOperator. With this design, the application can modify a relevant update attribute without doing anything else.