Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Number of features on tasks should be approximately within range. #52

Closed
manjitapandey opened this issue Sep 16, 2024 · 1 comment
Closed

Comments

@manjitapandey
Copy link

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.

@spwoodcock
Copy link
Member

Thanks @manjitapandey !

You are absolutely right that we should use an iterative approach: I think that is how the splitter works currently 😄
#61

We could definitely do with some refinement of the steps though and have many things to work on to improve the consistency of the output.

I think this this specific issue might be a duplicate of #28
and it should be solved by #58 too 👍

(closing for now - please re-open if I'm wrong!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants