Closed carlisle1 closed 5 years ago
Yes, you're absolutely right! Somehow, I only did that for routing, no idea why I didn't do it for isochrones.
It'll take a while though, since I'd have to do quite some refactoring before I implement new things. But it'll be solved by next release.
I've found a workaround in the meantime. The order of the isochrones in the created table matches the order of the points in the source table (when ordered by feature ID). If you're just creating one isochrone per point then the feature IDs will match and you can just run a join on that. If you're creating multiple isochrones per point then it is a little more complicated but can still be done with a virtual field and some maths as in an example where you have three isochrones per point; isochrones 0,1 and 2 correspond to point 0; 3,4 and 5 to point 1 and so on.
For me that workaround isn't working... The order of input points and isochrones doesn't match. I'm looking forward to a solution :)
Would it be possible for isochrones to have joined data from the points used to create the #isochrones?
For example, if you create isochrones around points in a layer containing many points then you get a table containing many isochrones but nothing to indicate which one applies to which point in the source table. The only way is to eyeball them but this makes additional analysis difficult if there are a large number of points and is difficult to tell which point the isochrone is for if you have a large isochrone that could be one of two points that are close together.