Highest value in flow layer for Accra seems to be on isolated road

[Robinlovelace]

See below, any ideas @mpadge ?

[Robinlovelace]

Reproducible example below showing that many of the highest values are far from the city centre:

piggyback::pb_download(file = "net-accra.Rds", "atfutures/upthat", dest = ".")
#> downloading net-accra.Rds ...
#> 
  |                                                                            
  |                                                                      |   0%

  |                                                                            
  |======================================================================| 100%
net = readRDS("net-accra.Rds")
mapview::mapview(net[net$flow > 2000, ])

^{Created on 2019-11-25 by the reprex package (v0.3.0)}

[mpadge]

Yeah, I have to simply remove that from the network at the outset and regenerate the layer. That's just a minor thing that I'll get on to this week. Please keep this issue open until I've addressed that. More important in the meantime is me structuring the currently quite messy code I've used to generate these layers, and dumping it all in revised flowlayers package.

[mpadge]

Okay, done in latest data upload to upthat. That was way more laborious that i had expected - the problem was some trotro stops that extended beyond the official city limits, which mean that they lay beyond the street network. This in turn meant that they were the origins of massive flows, because they could only head straight into the boundary of the official network. I finally managed to chop both those off, and a couple more bus stops along another route to the north. The only effect you'll note is that maximal flows have now been considerably reduced. I'll leave this issue open as a ping to self to ensure that nothing odd has happened there, but other than that it's ready to close

[Robinlovelace]

Great work @mpadge, I've just downloaded the releases onto the server...

[Robinlovelace]

Looking at the new data, I'm sorry to say I think this issue persists so leaving open for now. Please try to reproduce @mpadge and let me know your thoughts on solutions. Happy to help but currently I'm not sure how to reproduce the network calculations...

piggyback::pb_download(file = "net-accra.Rds", "atfutures/upthat", dest = ".", show_progress = FALSE)
net = readRDS("net-accra.Rds")
mapview::mapview(net[net$flow > 2000, ])

^{Created on 2019-11-26 by the reprex package (v0.3.0)}

[mpadge]

That seems okay, and what should be expected - the full image of those upper two regions looks like this:

The bit on the right is centred around Nima market, and looks a bit like this:

• :heavy_check_mark: Very high flows there in our model, and very high flows in that image.

The second bit is North Kaneshi, which looks like this on google maps:

With similarly detailed and dense centres of activity on OSM. So they seem reasonable and good, i'd say.

There is nevertheless on problem section left, which is this, on the George Bush Motorway in Awoshie:

This seems again to be due to some trotro stops extending beyond the network itself, so i'll have to clean those up too. The difficulty is there is no "conventional" spatial way to do such cleaning, because it requires a convex hull. I've worked all that stuff out in mapscanner, in which I've bundled the mapbox convex hull algorithm which works perfectly, along with the clipper library which is a blindingly fast point-in-polygon algorithm. But i've not exposed those for general usage yet, so i just have to do that, and we'll have a general spatial means to do point-in-convex-polygon analyses. For the moment, i'll do the marginally faster approach of a bit more manual cleaning ... rest assured it is at least full reproducible, because it just involves identifying the OSM ID values of the offending segments and removing them from the dodgr network.

[Robinlovelace]

Yes there do seem to be a few isolated segments with very high flows that don't seem to join onto the rest of the network. If you can add code that fixes that issue that would be great. Probably not a priority, I would say health outputs and health integration in upthat, e.g. with a table output next to the main map with tableOutput() is the top priority as per https://github.com/ATFutures/who3/issues/16

[mpadge]

Data updated to this:

The exposure layer now has a lot more detail in it too, which is nice. It was all caused by a total of 4 isolated street segments that had to be identified and removed from the network. All is now good.

[Robinlovelace]

Looks way better. How did you generate such an awesome route network layer? Numbers look more realistic also, although I'd still expect them to go way above 5k in Central Accra.

[mpadge]

yeah, i know what you mean about highest values of only 5k, but that's the numbers that come straight from the NYC calibration and fed in to what we know about Accra walking behaviour. We've only got that to on for the moment, so have to accept it, but also note that

net <- readRDS ("./inst/net-accra.Rds")
format (sum (net$flow), big.mark = ",")
#> [1] "11,961,067"

^{Created on 2019-11-27 by the reprex package (v0.3.0)}

That seems initially to be a fair number for a city of 2.5 million, wouldn't you say?

[Robinlovelace]

I don't think it's the total that's important as different cities have different numbers of segments.

[Robinlovelace]

Assuming each route has more than 10 segments, I'd say that looks low, unless I'm missing something.

[mpadge]

I agree that it seems low, but that layer is generated such that the above sum should equal the total numbers seen on the network within a 24 hour period. It is probably still low, but for a first cut, I suggest that we accept it as is. The primary purpose of it in immediately moving forward is to inform the health calculations, which are independent of the absolute scale of that layer, because they end up pegged to the total city population.

[Robinlovelace]

Sounds reasonable :+1: