distinct isochrones for multiple points

[noerw]

When requesting isochrones of more than one center point, they may overlap. Most notably, areas with a low timecost may be "shadowed" by areas with a higher cost from a different point. This makes the data unusable for further analysis.

To solve this I manually ran the following process, but it would be better if this was automated and enabled by default:

• split the layer into multiple layers grouped by AA_MIN column
• calculate geometric difference between each resulting layer, resulting in non-overlapping polygons
• dissolve each resulting layer to merge adjacent polygons
• merge those layers back into one

edit: I believe this is what was requested in #26 as well.

[nilsnolde]

Hi,

thanks for the enhancement suggestion! I'll have to reproduce what you're suggesting, then I'll give some more feedback. There's options in ORS even in the backend for handling overlapping areas. It's not very nicely implemented though to handle it in post-processing.

I'll get back to this.

[nilsnolde]

Now I'm finally at a stage with QGIS v3 plugin where the last version left off.. And looking at current issues.

I'm still wondering about this issue. I actually just tried to recreate your workflow, but I don't get much sense out of it... When I exactly do what you describe, I end up with a bunch of donut polygons coming from the furthest isochrones. Are you trying to use the geometric difference between subsequent isochrones (i.e. what's the area between an isochrone for 10 mins and one for 15 mins for each point)? Because that's what I get. While I can imagine a bunch of use cases for that, I don't think that it's really common ones.

If you explain a bit more in detail what you're after (and the benefits), I can take a look how to implement this.

Or actually, if you wish, you can contribute to this project from next week on. That's when the current version will be at production state. I'd really like someone to collaborate with, it's a ton of work.

[noerw]

I will see if I can come up with a model performing these steps in QGIS2 in a reproducible manner, so its clearer what I am aiming for

[noerw]

I implemented this in #46 for the processing algorithm, with an option to disable the feature

[nilsnolde]

I had a quick read, really interests me what you were after. Looks like it's exactly how I understood it initially (and how you described it initially), calculating geometric difference on grouped isochrones (grouped by metric). I once had a button for isochrones to dissolve on metrics, but took it out again (no idea anymore why really..). BTW, simplify is a bit misleading, as simplifying a geometry commonly refers to reduce the amount of vertices.

Care to describe your particular use case? Maybe it's more common than I'd think...

[noerw]

Now that you say it, dissolve by range is more to the point than simplify!

My usecase: I am querying for a set of POIs and calculating reach (by time cost) from those POIs with different ranges via isochrones. Additional attributes per range value are attached to the isochrones. The goal is to check for each point of another dataset, in which isochrone they are located, and transfer the added attributes to those points.

dissolve by range is not strictly required for this, but makes things easier as..

• there is only one polygon per range to attach attributes to, making things faster and cleaner
• there is only one polygon where point.within(isochrone) == True
• the isochrones look prettier ;)

[nilsnolde]

Yep, got it. That actually makes a lot of sense.

Also your pull request makes a lot of sense. I added the POI API, which @TimMcCauley developed, in another branch and I can't get past dividing GUI and processing on API level, to access QgsRubberBands properly.. Which annoys me to no end. I just refactored the whole thing and looks like I have to do it all over again.. I'll leave it for a few weeks, I feel too weak to dive into it yet again;) BTW, come to Heidelberg to visit!

[nilsnolde]

won't fix unless someone else looks at it