Feature request / idea: inter-project task dependencies

[nbolten]

Intro

Hello, first off I want to thank the HOTOSM team for making such a great tool, and the rest of your valuable work.

My group (OpenSidewalks) has used a self-hosted version of the tasking manager (version 2) to stage sidewalk and other pedestrian mapping efforts, either via a manual import or de novo mapping strategy.

The challenge

In our experience, many of our tasks are fairly complex, requiring mappers to add many tags and make several decisions about when to combine or not combine certain features, which would suggest we should break up the projects for different types of features. However, our features are connected - they can't be mapped entirely separately, e.g. we wouldn't want two people simultaneously editing the same task area for sidewalks and crosswalks, because they wouldn't be able to connect the sidewalks to the crossings.

Overall idea

One way to address this problem would be to have (unidirectional) dependencies between tasks in different projects. Here's an example that might improve our workflows, and hopefully has wider relevance for other groups:

1. A 'crosswalks' project where mappers add the pedestrian crossings for a single intersection.

2. A 'sidewalks' project where mappers add the pedestrian footways along streets, connecting them to 'crosswalks'.

3. Mapping sidewalks should happen after intersections, so they are connected to the street network and won't break routing: a sidewalk task does not become available until all touching intersection tasks are completed.

4. Mappers can view a sidewalk task and navigate to other-project tasks it depends on, making it easy to meet an objective of 'map the sidewalks in this area' without having to guess about dependencies.

Simpler / hacky implementation strategy

The simplest implementation option I can think of is to supplement the GeoJSON polygon task import option with a special key-object pair describing how each task depends on a 'foreign' project task, e.g.:

{
    (...),
    "properties": {
        "tm_depends_on": [{
            "project_id": 2003,
            "task_ids": [1, 6, 47]
        }, (...)
        ]
    }
}

I haven't dived into the db schema, but it would fit nicely in its own 'taskdependencies' table for relating projects, indexed to the 'reverse-dependent' project ID.

This strategy requires each 'upstream' project to exist prior to generating the GeoJSON, so it knows what IDs to reference. This is in some ways a feature: it prevents cyclic dependencies.

More user-friendly options

Our particular strategy will be based on a simple spatial intersection between project tasks, which is something that could be implemented in the tasking manager itself: if project A depends on project B, and the 'use task intersections' option is used, the "project_id" and "task_ids" data can be auto-generated. This option would also be responsive to 'task splitting', as the polygon intersections could be reliably recalculated as part of that operation.

Conclusion

Hopefully this all made sense and is also a new idea: I searched through the issues backlog here and for TM2 and didn't find anything. I'm curious about whether this sort of issue has come up before and if others would find it useful.

[althio]

Great idea. I am not sure it was ever discussed so precisely, but it is certainly also applicable to other workflows. There is added complexity for sure, but I think projects managers of "regular basemap" were sometimes trying such approaches, with manually defining separate projects for road network, residential areas, then buildings and more and more detailed mapping.

[ethan-nelson]

Hi @nbolten thanks for your suggestion!

Just trying to better understand this and wrap my head around it...is the main idea here a feature where grids can remain the same across multiple projects such that 1) the task grids cover the same area, 2) their geometries are synced (so a split in one project yields a split in the others), and 3) when a task is locked on one project, it is locked on all of them? As althio mentions, this isn't something that has come up before but could be a nice feature!

Best, Ethan

[nbolten]

Hey @ethan-nelson,

The idea is not that there would be any shared task geometries between projects, just something like an optional foreign key between tasks in different projects.

In my use case, the 'street intersection' and 'sidewalks around a block' tasks have very different task geometries, but would still massively benefit from sidewalk tasks depending on the completion of related intersection tasks. Example:

1) The intersection tasks would be centered at an intersection, and probably be the result of making Voronoi polygons of street intersections. In a stereotypical example where there's lots of sidewalks, most sidewalks would be roughly bisected by the polygons. All of the footways at an intersection need to be connected to one another (when it makes sense on the ground), so we wouldn't want to split the intersection up into more than one 'mark crosswalks' task.

2) The sidewalks tasks have the opposite geometrical logic: we absolutely do want to split at intersections, essentially making most tasks a single 'around the block' go for a stereotypical urban environment.

3) Because of (1) and (2), and the overall complexity of mapping all of these features at once, it would be less than ideal to put them in a single task - we'd have to map things that are supposed to be connected across task boundaries - so instead we'd use the separate tasks as described in (1) and (2).

4) Using different tasks for connected features raises a new challenge: what happens when people are simultaneously mapping sidewalk and intersection tasks that overlap / border one another? Sidewalks need to be connected to crossings as part of the main task objectives, but there would be no crossings yet, so the mapper would just leave disconnected sidewalks as part of their task. The person editing crossings would also not see sidewalks. Best-case scenario, one of them runs into a conflict and they re-download the area and fix it.

5) But if we let sidewalk tasks refer to the intersections tasks that should be done first, the tasking manager could do an admin-side lock on sidewalks tasks until all associated intersections tasks are done.

Hopefully this makes sense. The short version of it is that it often makes sense to split up a complex mapping project into separate 'map this feature' projects, but you don't want all tasks available at once: some should happen first, and the logic for when a task becomes unlocked is spatial + task status.

I can see there being a similar, but not identical use case for tasks that involve mapping anything connected, even if it doesn't make sense to split: preventing simultaneous mapping of neighboring tasks.

[willemarcel]

It's a bit out of our current scope, but it's a good idea to an external tool coupled to TM.