Improve feature parity with classic osm and embedded Rapid editor

[jlewin]

What would you like to see?

When loading area-based tasks with the classic osm editor, the area of interest is clearly conveyed and apparent. When switching to the embedded Rapid editor, the area of interest is ambiguous almost no certainty about the area being conveyed.

Why is this useful?

Either editor that the user selects should convey the same knowledge and functionality

Additional context

Sharing to prompt further discussion around the idea and to share inroads on a prototype as it evolves.

Comparison

[jlewin]

I have a working prototype that adapts the Rapid editor to support a maproulette-task parameter and subsequently requests and renders the task geometries in PixiLayerMapRoulette. Presumably this qs arg could be driven by maproulette and rendering could be refined to achieve any additional variance to produce similar results in the osm and rapid editors.

Interest in any thoughts or concerns.

[mvexel]

Hi @jlewin - thanks for your contributions to the project thus far! Excited to see new contributors.

It sounds like this would require coordination with the Rapid team to add this new parameter to a future release? We are not directly involved with them but have worked closely together in the past. Rapid is currently in minimal maintenance mode, so it's hard to say if we'd be able to make progress here, but I like the idea and it's worth a closer look. Tagging @bhousel and @Bonkles who were the main Rapid maintainers up until recently, just for visibility.

[jlewin]

Yeah, the depicted changes could only be used in the future if they were accepted and merged into Rapid. Before I pursued any additional effort, it made sense to gauge interest in the idea and discuss concerns and roadblocks I might not be aware of.

An alternative idea I hope to pursue would be to automate the driven Rapid instance and push the active task geometries into a runtime generated layer that might not require the Rapid side changes. This idea seems plausible but feels like a lot more effort and I've yet to dig in and evaluate.

[bhousel]

Thanks for the update and tag!
We did add a url param for WKT in this issue: facebook/Rapid#1386
Does that cover the usecase in the mean time?

We're not currently working on "official" Rapid, but there is community interest in seeing it continue in some form. If it is up to me, I'd happily support more MapRoulette improvements.

[jlewin]

At a quick glance, the wkt support looks great. I'll rework my efforts to take advantage of this functionality. Thanks for the insight and assistance!

Sad to hear the news about "official" Rapid development, as all the recent videos I'd watched seemed to suggest it was going full steam. Hopefully some solid path forward exists where it continues evolving and improving.

[jlewin]

Rendering the task geometry with the data/wtk param works and gets the task areas into in the rapid editor (jlewin@9093bf4). However, the shape's style and rendering order is hardcoded, with the osm data layer sitting higher than the injected geometry. In the cases I reviewed, the injected shape is often occluded with only some of its borders visible. If I turn off the osm data layer (the ideal case below), the continuity across views is evident, but not really a valid solution.

My high-level goal is to render the same "work in this area" boundary that's present in the osm view as I found it incredibly helpful. This remains a personal objective only, and I'm sharing investigation results and thoughts here for future reference. I believe the wtk shape could better match expected if the fill and stroke styles could be customized and if the custom data layer could have a higher rendering order, but I don't immediately see a path to that outcome and will continue research what's possible with this or altervative techniques.

Ideally

Actual