5

I am using the QNEAT plugin to calculate catchment are/travel reach over a street network. The network is valid and projected correctly. I have tried changing the cell size and topology tolerance without it making any difference. Running QGIS 3.10 on Mac.

My problem is that the interpolation process simplifies the output to such an extent it is not usable. The picture shows the network and the output polygon. As you can see the polygon fills up gaps in the network in a way that it should not. In this case, the polygon extends far out in the sea where no network is present. Am I doing something wrong or do I not understand the functionality of the tool?

ISO-AREA problem

4

I would not consider this a bug as the plugin runs excatly the way it is intended to. The very concept of Iso-areas implies that whole surfaces and not just networks (lines) are covered, thus even areas that do not line on the network. This in itself, conceptually, does not represent reality 100% as we all know from our everyday experience. Technically, if you run a network analysis, you can only reach points lying on the network lines, everything else, beside the network, is just interpolated. So you should rather set a clear critearia what means "reachable" in a Iso-area network analysis: how far away from the network (lines) is still "reachable"?

Consider a real street network in a city: you can't reach all areas that lie outside the street itself: private courtyards, a closed compound of a factory etc. The same is true for a lake, river, a cliff etc.

So rather than consider this a bug or malfunction, it's more convenient to critically reflect the very concept of Iso areas. They are a model that does not necessarily correspond to an actual reality - in some cases yes:parks are areas perfectly reachable, in other cases no: the compound of a prison is not (normally) accessible, even if it is surrounded by a network of streets that is reachable.

The plugin has no way how to differentiate areas reachable and areas not reachable. If you want such an output, you should create another polygon layer that covers areas reachable and areas not reachable (or a raster layer to differentiate different steps of "reachability", like from 1-perfectly reachable to 0 - not reachable at all). Than you can overlay this with the output of your Iso-area analysis to get a more suitable result - like clipping the Iso-area with a polygon representing the water surface.

5
  • Thank you for a great answer! I see your points and now have a better understanding of the functionality of the tool. For this case I will use secondary layers to limit reachability as suggested.
    – Snakob
    Jan 15 at 9:48
  • I don't agree with this assessment and that's also not how the vast majority of isochrone implementations work. The plugin should have very well means to differentiate between this sort of unreachable area: there is no street network. Some fancy implementations even go as far as giving back donut polygons, but that's rather unusual. Yeah, polygon overlay is one option to deal with this clear bug. The whole thing looks VERY simplified to me: the SW corner should for sure not be a straight line..
    – nnolde
    Jan 15 at 10:08
  • @nnolde: How should the plugin differentiate between areas reachable and areas not reachable without providing that information? Where should the plugin know from that there is a water surface? As long as the input to a network analysis is a line, perfectly reachable are points on the line only - everything elso is guesswork. Would be interested if you could elaborate that or provide an example of such an analysis.
    – Babel
    Jan 15 at 10:17
  • 1
    @nnolde: I guess parts of the reason wy the SW corner is a straight line is due to the missing links in the network in that area. By calculating a greater distance than I need and using one of the intervals as my greatest distance helped a bit, but that might be due to just running the process again. For some reason the output result varies to some extent between runs, even if a keep the setting and the network exactly the same. Any thought on this? And du you know of any other isochrone tools for QGIS that would handle this better? I need to be able to specify my own network..
    – Snakob
    Jan 15 at 10:51
  • @nnolde your comment and the associated discussion made me refine my inital answer. To be precise it is not a bug rather than missing functionality that currently cannot be provided by the underlying QGIS API. But this is an open source project - so feel free to contribute and implement the missing functionality to better reflect your definition of isochrones with QNEAT3. I would be happy to assist if someone wants to improve QNEAT3.
    – root676
    Jan 15 at 15:41
4

The problem you are experiencing is due to a missing functionality in QNEAT3 which cannot be provided using the current QGIS API. Currently, QNEAT3 is not capable of accounting for waterways/lakes (which seems to be the case in your example). The interpolation method for the isochrones therefore spans the iso-polygons in this areas too. Other than that, the isochrone seems pretty reasonable to me, given the network errors (disconnected links in the south west of the isochrone).

1
  • 1
    Thank you for a very swift reply and a good link to further reading. I will use a masking layer for now to hide the areas not reachable.
    – Snakob
    Jan 15 at 8:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.