Git Product home page Git Product logo

Comments (7)

richardbeare avatar richardbeare commented on June 24, 2024 1

Stroke count computation looks nicer.

I think we'll need comments on projections in the main text, with reference to st_distance.

from geospatialstroke.

mdsumner avatar mdsumner commented on June 24, 2024

Use read_sf rather than st_read to avoid factor creation from strings by default in https://github.com/SymbolixAU/GeospatialStroke/blob/ChoroplethMMC/mmc_surrounds.R#L44

#################
## --- 2) 
postcodeboundariesAUS <- sf::read_sf("ABSData/Boundaries/POA_2016_AUST.shp")

This avoids the downstream message from the right_join

basicDemographicsVIC <- right_join(postcodeboundariesAUS, basicDemographicsVIC, 
                                   by=c("POA_CODE" = "POA_CODE_2016"))
Warning message:
Column `POA_CODE`/`POA_CODE_2016` joining factor and character vector, coercing into character vector 

from geospatialstroke.

mdsumner avatar mdsumner commented on June 24, 2024

Consider plot of DistanceToMMC at https://github.com/SymbolixAU/GeospatialStroke/blob/ChoroplethMMC/mmc_surrounds.R#L93

#################
## --- 3) 
plot(basicDemographicsVIC["DistanceToMMC"])

Note that we didn't have to worry about the map projection, st_distance is correct as per great circle assumptions in longlat data.

This is where it needs to be said that crow-distance and transport-distance are obviously different.

from geospatialstroke.

richardbeare avatar richardbeare commented on June 24, 2024

I think you can merge your other suggestions into the code.

We'll cover crow-distance and transport-distance and transport time in a separate example.

from geospatialstroke.

richardbeare avatar richardbeare commented on June 24, 2024

@mdsumner - a query on crs. I'm experimenting with including osm geocoding (with tmap_tools, since we're using tmap anyway) to avoid the need for keys in this example. If I do:

MMCLocation <- tmaptools::geocode_OSM("Monash Medical Centre, Clayton, Victoria, Australia", as.sf=TRUE)
MMCLocation

Simple feature collection with 1 feature and 7 fields
geometry type:  POINT
dimension:      XY
bbox:           xmin: 145.1207 ymin: -37.92093 xmax: 145.1207 ymax: -37.92093
epsg (SRID):    4326
proj4string:    +proj=longlat +datum=WGS84 +no_defs
                                                query       lat      lon   lat_min   lat_max  lon_min  lon_max                   geometry
1 Monash Medical Centre, Clayton, Victoria, Australia -37.92093 145.1207 -37.92098 -37.92088 145.1207 145.1208 POINT (145.1207 -37.92093)

Whereas the census postcode data is:

postcodeboundariesAUS

Simple feature collection with 2670 features and 4 fields (with 2 geometries empty)
geometry type:  MULTIPOLYGON
dimension:      XY
bbox:           xmin: 96.81694 ymin: -43.74051 xmax: 167.998 ymax: -9.142176
epsg (SRID):    4283
proj4string:    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
# A tibble: 2,670 x 5
   POA_CODE POA_CODE16 POA_NAME  AREA_SQKM                                                                                geometry
   <chr>    <chr>      <chr>         <dbl>                                                                      <MULTIPOLYGON [°]>
 1 POA0800  0800       0800          3.17  (((130.8502 -12.45301, 130.8496 -12.45622, 130.8504 -12.45637, 130.8501 -12.45824, 1...
 2 POA0810  0810       0810         23.8   (((130.8715 -12.39532, 130.8708 -12.39539, 130.8628 -12.39544, 130.8609 -12.39645, 1...

What is the correct way of ensuring crs are consistent?

from geospatialstroke.

mdsumner avatar mdsumner commented on June 24, 2024

Strictly, the right way is to transform one to the other (you could use sf::st_crs(postcodeboundariesAUS) rather than prj, or you could enter 4283 directly):

prj <- "+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs"
 format(unclass(sf::st_geometry(sf::st_transform(MMCLocation, prj))), digits = 15)
[1] "145.1207033, -37.9209311"
> format(unclass(sf::st_geometry(MMCLocation)),  digits = 15)
[1] "145.1207033, -37.9209311"

But, as you can see they aren't different. I don't know exactly on this stuff, but the +towgs84=<all zeros> to me means that it's equivalent to WGS84 in 2D, ( if surveyor accuracy is required we'd be using GDA94 (the datum)and a real 3D transformation grid would be in use).

I'm not quite sure what the advice should be generally, use "+proj=longlat +datum=WGS84 +no_defs" ("+init=epsg:4326", or st_crs(4326)) unless you have source data that uses this locally specific one. I think probably we should use 4283 generally, but it never actually matters in my work these days.

Take home: keep the metadata strictly for use by the sf tools, and always check if you have to apply it or modify it manually.

from geospatialstroke.

richardbeare avatar richardbeare commented on June 24, 2024

Ah, I'll use st_transform to spread good practices.

Thanks

from geospatialstroke.

Related Issues (17)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.