C Spatial notebook

C.1 Transforming lat/lon data to the MP14 coordinates system

We load the planning areas shapefile.

## Reading layer `MP14_PLNG_AREA_NO_SEA_PL' from data source `/Users/barnabe/Documents/Research/Teaching/Computation Urban Design/lecturenotes/data/MP14_PLNG_AREA_NO_SEA_PL.shp' using driver `ESRI Shapefile'
## Simple feature collection with 55 features and 12 fields
## geometry type:  MULTIPOLYGON
## dimension:      XY
## bbox:           xmin: 2667.538 ymin: 15748.72 xmax: 56396.44 ymax: 50256.33
## epsg (SRID):    NA
## proj4string:    +proj=tmerc +lat_0=1.366666666666667 +lon_0=103.8333333333333 +k=1 +x_0=28001.642 +y_0=38744.572 +datum=WGS84 +units=m +no_defs

Note the projection used to transform the data. When you load the shapefile, the points are already expressed in this coordinates system. This returns a CRS object (“Coordinate Reference System”).

## Coordinate Reference System:
##   No EPSG code
##   proj4string: "+proj=tmerc +lat_0=1.366666666666667 +lon_0=103.8333333333333 +k=1 +x_0=28001.642 +y_0=38744.572 +datum=WGS84 +units=m +no_defs"

We create a dataframe with one single point expressed as lat/lon.

Set its coordinates system to use lon/lat (longitude comes first in sp/sf objects).

Note that pts is now a SpatialPointsDataFrame object (an “sp” object then). We will do the following steps:

  • Cast pts to an sf object first (st_as_sf)
  • Set its coordinate system to the one that we implicitly used with lat/lon. That coordinates system is called “WGS84” (st_set_crs).
  • Transform the point to the coordinates system used by the Singapore shapefile.

Open pts_transform and notice that the coordinates of the point have changed. They are now comparable with the coordinates used in planning_areas. Note also that pts can hold an arbitrary number of lat/lon points and the code is the same to transform it to an sf object in the coordinates system of planning_areas.

C.2 OpenStreetMap (OSM) tips

Let’s assume that we have a list of addresses we want to know the location of:

We can build a request to OSM using their Overpass API query builder in R, returning an sf object.

We only really care about the polygons, and for each polygon, the number, street name and geometry of the polygon.

Sometimes though, our query returns nothing (or more precisely, returns an sf object with no polygon).

## [1] 0

Our goal is to run many queries to find the (lat/lon) locations of a list of addresses. We need to check whether the query returned something, otherwise subsetting the columns fails. This is the function we will use (you will see why we use dat %>% pluck(1) later).

Now we’ll use purrr to run the requests many times using map. map needs a list of addresses, with each address a list itself. Fortunately, purrr is used to such manipulations, so provides a neat transpose method to go from the addr tibble to a list of lists. This is why we use pluck in query_osm by the way.

Now that we have a list, we can call map.

Open the queries object. You will observe that this is a list of two elements: one query that returned something (for 85 Jalan Sultan) and one that didn’t (for 260 Jalan Sultan). sf objects are collections: you can accumulate many geometries together in the same sf object. For instance, to union two different sf objects, you can use rbind, like you might for dataframes (or bind_rows if you want the dplyr equivalent). Once again, purrr is helpful: we can use its reduce method to bind all the objects our queries returned.

This works for an arbitrarily long list of addresses, but note that OSM might limit your rate and this can take some time. My advice is to subset your queries and send them progressively, e.g., if you have a big list of addresses, run first

adrs_list <- transpose(
  list(adrs$nb[1:100], adrs$street[1:100])
queries <- map(adrs_list, query_osm)
queries_sf <- queries %>%

Then run

adrs_list <- transpose(
  list(adrs$nb[101:200], adrs$street[101:200])
queries <- map(adrs_list, query_osm)
queries <- queries %>%
queries_sf <- queries_sf %>% rbind(queries)

etc etc.