You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, when I use the splitting algorithm with an average of 40 features per task, some tasks end up with very low feature counts, often fewer than 5 or 8. After analysis, I’ve found that this issue isn't only due to linear features being used for task splitting but also because factors like task area are being considered.
Describe the solution you'd like
To address this, we can implement an iterative task-splitting approach. The first step would involve splitting based on major linear features, such as highways or waterways, that should be prioritized for task boundaries. For the remaining areas, tasks would be split based on both area and feature count. - like the present behavior.
Additional steps
If some tasks still end up with fewer features than the average, we could introduce a validation step where the number of features in each task should not fall below half of the user-provided average.
For example, if the user specifies an average of 40 features per task, we calculate a range: 40 ± 50%, which gives a range of 20 to 60 features per task. If a task has fewer than 20 features, it can be merged with an adjacent task that has the highest feature density. Conversely, if a task exceeds the upper limit, it should be split into two smaller tasks.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This may increase the splitting time of algorithm but if the tasks are splitted as end user expected, may be little increase in time should be considerable.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, when I use the splitting algorithm with an average of 40 features per task, some tasks end up with very low feature counts, often fewer than 5 or 8. After analysis, I’ve found that this issue isn't only due to linear features being used for task splitting but also because factors like task area are being considered.
Describe the solution you'd like
To address this, we can implement an iterative task-splitting approach. The first step would involve splitting based on major linear features, such as highways or waterways, that should be prioritized for task boundaries. For the remaining areas, tasks would be split based on both area and feature count. - like the present behavior.
Additional steps
If some tasks still end up with fewer features than the average, we could introduce a validation step where the number of features in each task should not fall below half of the user-provided average.
For example, if the user specifies an average of 40 features per task, we calculate a range: 40 ± 50%, which gives a range of 20 to 60 features per task. If a task has fewer than 20 features, it can be merged with an adjacent task that has the highest feature density. Conversely, if a task exceeds the upper limit, it should be split into two smaller tasks.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This may increase the splitting time of algorithm but if the tasks are splitted as end user expected, may be little increase in time should be considerable.
The text was updated successfully, but these errors were encountered: