Catchment basins about geospatialstroke HOT 8 CLOSED

Excellent - need to move quickly now.

from geospatialstroke.

Having a quick look now - I think we need to have a "basic" version of all examples that works without needing keys. Any extra setup is going to stop people getting started. Fancier tools requiring keys will follow in a separate section.

from geospatialstroke.

So far, having some problems:

I installed dodgr as follows, not sure if it is the right version:

devtools::install_github("ATFutures/dodgr")

I get the following errors:

system.time (
+ dandenong_streets <- dodgr_streetnet (bounding_polygon, expand = 0, quiet = FALSE)
+ )
Issuing query to Overpass API ...
Rate limit: 2
Query complete!
Error in check_for_error(doc) : General overpass server error; returned:
OSM3S ResponseThe data included in this document is from www.openstreetmap.org. The data is made available under ODbL.Error: line 3: static error: For the attribute "s" of the element "bbox-query" the only allowed values are floats between -90.0 and 90.0. Error: line 3: static error: The value of attribute "n" of the element "bbox-query" must always be greater or equal than the value of attribute "s". Error: line 4: static error: For the attribute "s" of the element "bbox-query" the only allowed values are floats between -90.0 and 90.0. Error: line 4: static error: The value of attribute "n" of the element "bbox-query" must always be greater or equal than the value of attribute "s". Error: line 5: static error: For the attribute "s" of the element "bbox-query" the only allowed values are floats between -90.0 and 90.0. Error: line 5: static error: The value of attribute "n" of the element "bbox-query" must always be greater or equal tha
Timing stopped at: 0.484 0 1.892

Attempting other comments in code...

from geospatialstroke.

@richardbeare I think you also need the dev version of osmdata too - reference: 00bc6ec#commitcomment-31438218

from geospatialstroke.

Ah - thought I remembered something about that, but couldn't find it.

from geospatialstroke.

OK, @mpadge @SymbolixAU
I've run through and we're off to a good start.

1. I've sent a PR with some examples of tidy style column selection

2. We need to get onto the final steps. Who has a neat way of doing this? The aim is to get a representation of catchment areas that lets us compute various things like catchment area (not useful but shows that there's a geospatial representation), number of people per catchment (derived from our sampling of postcodes) and the postcode demographics) and the average travel time for each catchment and the proportion of people who can reach the destination within a certain time frame.

3. Last time I did this by computing a voronoi tesselation of the random addresses. This collection could be merged into regions based on nearest destination. Counts were based on the proportion of each postcode's samples that were predicted to travel to each destination. e.g. if 30% of our 500 samples from a postcode were predicted to travel to hospital A, then 30% of the cases from that postcode are assumed to go to the hospital.

4. Consolidate what we do with display. Clearly mapdeck handles large numbers of points more gracefully, but (for me at least) it doesn't show up in Rstudio. The window needs to be popped into the browser. This will confuse people. Also, we need to be very explicit about when keys need to be set up and have a way of running everything possible without keys. Extended examples will use keys. We need to be thinking about how to structure this.

5. Structure documents for knitting - currently this one fails in rstudio due to saving the dodgr output in the local folder. We should also think of a standard way we are going to be recommending people run these examples - i.e run from the subfolders and use relative paths vs run from anywhere and use absolute paths via here::here().

6. Structure the Rmd files with chunking - i.e separate code files that get imported.

7. Finally - I'm not happy with the geocoding of the rehab hospitals. I played around to get something that worked, but the addresses aren't super convincing. Any improvements there will be good.

from geospatialstroke.

A few brief comments until I find time to address the points:

2. ... final steps ... aim to get a representation of catchment areas that lets us compute various things like catchment area (not useful but shows that there's a geospatial representation), number of people per catchment (derived from our sampling of postcodes) and the postcode demographics) and the average travel time for each catchment and the proportion of people who can reach the destination within a certain time frame.

I have that one firmly on my radar, just didn't have time yet to finish it off. Unless anyone else particularly wants to, I'm happy to tackle that, and will do it early next week at latest (first Dec week).

3. Last time I did this by computing a voronoi tesselation of the random addresses. This collection could be merged into regions based on nearest destination. Counts were based on the proportion of each postcode's samples that were predicted to travel to each destination.

Sounds good. There's also the alphahull package for calculating non-convex hulls, as used for example here. I'll try out a few approaches.

4. Consolidate what we do with display. Clearly mapdeck handles large numbers of points more gracefully, but (for me at least) it doesn't show up in Rstudio. The window needs to be popped into the browser. This will confuse people. Also, we need to be very explicit about when keys need to be set up and have a way of running everything possible without keys. Extended examples will use keys. We need to be thinking about how to structure this.

No worries, all the code I did can easily just switch to keyless mapview for initial runs.

5. Structure documents for knitting - currently this one fails in rstudio due to saving the dodgr output in the local folder.

Just my laziness there. I'll change that so that the script creates the local folder and data on initial run, then just uses that from then on.

5. (cont) We should also think of a standard way we are going to be recommending people run these examples - i.e run from the subfolders and use relative paths vs run from anywhere and use absolute paths via here::here().

My only firm plea: file.path(here::here(), "subsubdir", "subdir", "filename"). It's the only approach that is robust on all OS'es.

7. Finally - I'm not happy with the geocoding of the rehab hospitals. I played around to get something that worked, but the addresses aren't super convincing. Any improvements there will be good.

If you can explain what you mean, we should be able to address it. I've checked out the OSM data for MMC at least, and the full building details are there, along with the 2 main entrance roads (emergency and public entrances). Can easily use one or the other of those, or both, or do something else with building geometry.

from geospatialstroke.

I found that the OSM search for the Kingston hospital was a problem. Using the street address (as reported by google) did not give the correct location. Hopefully there's a better way.

On paths - do relative paths not work robustly? I'd have thought that here() requires the R working directory to be appropriately set, so something like file.path("..", subdir, filename) should work. Are there problems with that on other platforms? I thought ".." worked everywhere...

from geospatialstroke.