Refactor native #74
Refactor native #74
Conversation
It should now be much more easy to make changes, since less code repetition. However, understandability is worse now
There was a problem hiding this comment.
In general seeing all those parameters be passed around if it wouldn't be a good idea (dont know if you meant the same) that we had classes or at least a dictionary for the parametrization. eg SegmentationSettings (with patch_size, overlap, batch_size, reflection) and PostprocessSettings (with binarization_threshold, mask_erosion_size, min_object_size, use_quality_mask). But i know your philosophy of classes is different than mine... ;)
|
|
||
|
|
||
| """ | ||
| data_generator = _load_planet( |
There was a problem hiding this comment.
thats the datacube loader, isn't it? so no vrts and the parameters do not match.
|
|
||
|
|
||
| """ | ||
| data_generator = _load_s2( |
|
but apart from the slow data_loader function missing this is fine by me... :) |
|
@iona5 you are right, doing with classes is a way better method here. |
|
First Impression: Seems like a nice way of doing things. :) It feels like the level of modularity is "correct", but i agree one need to become familiar with the structure at first. I don't think it is too complicated though. Will have a further look tomorrow |
It should now be much more easy to make changes, since less code repetition. However, understandability is worse now