R versus python about geospatialstroke HOT 7 CLOSED

Snap - I've just been looking at the same thing. The issue is that different sets of postcodes get selected - check the displays in the existing documents. There's a very different set in the vicinity of Casey. In python the 10km radius is to the centroid, while the R version appears to be to the nearest point of the postcode. Either is fine, but lets go with the version that is easier to reproduce on both systems.

from geospatialstroke.

Oh yeah, they really are quite different. I'll incorporate that difference as well and update the code.

EDIT: Bingo! That's the origin of the difference. Code push impending ...

from geospatialstroke.

hmm... that commit reduced the load to Casey to the desired 13% or so, but also reduced the load to Dandenong so that Kingston is then around 60%. That means there are still other differences at play here.

from geospatialstroke.

The postcodes in the 2 sets weren't quite exactly matched, so the above commit fixed that. Results still don't agree too strongly, something like

I suppose that's not too bad, but it would still be nice to have them somewhat closer ...

from geospatialstroke.

So the python code of @gboeing first estimates the stroke incidence per postcode based on the basic demographic data, which the R code does not do. The latest commit modifies the sampling scheme so that numbers of cases are scaled to the estimate incidence rates per postcode, resulting in ...

from geospatialstroke.

That commit gets it to something like:

Those values for R come from:

1. Using an unweighted street network retaining only components useable for vehicular routing;
2. Sampling a fixed number of random points directly from this network, and allocating those to postcode areas;
3. Weighting the final case load by per-postcode estimates of stroke incidence.

The error estimates come from the code at the end of the README. Importantly, these error estimates themselves are not very reproducible, indicating that some portion of the R-vs-py differences must be presumed to arise from sampling effects alone. Because the python code was based on 1,000 random points in total, while the R code used that number per postcode (and there are 57 of those), the latter must be presumed more accurate here.

In contrast to the above values, a more realistic estimate from the R code is likely to come from using the weighted street network, and sampling addresses within each postcode, which corresponds to these values:

from geospatialstroke.

Future ref for @gboeing: I'll dig more deeply in osmnx-vs-osmdata - something I've been wanting to do for a while. Thanks @richardbeare for the incentive here.

from geospatialstroke.