3

I have two data frames with different coordinates reference systems, one in WGS 84 and the other is the British National Grid.

When I transform them into the same crs definition (WGS 84) one of the two always has more decimal digits, and that is the one that had the British National Grid crs.

How can I get the two to match in decimal precision after transformation? I can manage this when rasterising the two objects however, I lose some points.

Here's what I have tried:

#Convert XY coordinates into Shapefiles and transform to WGS 84
police <- sf.test %>% distinct(NAME, Longitude, Latitude) %>%
  group_by(NAME) %>%
  st_as_sf(coords = c("Longitude", "Latitude"), crs = 4326) %>%
  st_transform(crs = 4326) %>%
  nest(data=c(NAME, geometry))

#Then drop the geometry points and cast as a data frame
sf.test1 <- police$data[1] %>%
    bind_cols %>%
    st_cast(to = "POINT") %>%
    dplyr::mutate(
      X = sf::st_coordinates(geometry)[,1],
      Y = sf::st_coordinates(geometry)[,2]
    ) %>%
    sf::st_drop_geometry()

However, the coordinates still remain different which can be shown by the difference in Longitude and Latitude coordinates after using dput.

#first dataset already projected to crs 4326
Longitude = c(-0.679025, -2.516919, 
-2.512773, -2.514442, -2.515072), Latitude = c(50.781688, 51.423683, 
51.411751, 51.409343, 51.419357)

#second dataset after conversion
Longitude = c(`1` = -0.500616835380604, 
`2` = -0.500579742731822, `3` = -0.500562231052187, `4` = -0.500551492843239, 
`5` = -0.50060557136444), Latitude = c(`1` = 51.5996873520887, 
`2` = 51.5995448459169, `3` = 51.5994186801437, `4` = 51.5992603285579, 
`5` = 51.5988473256556))
6
  • Are we talking about length of coordinate-"string", or length of features? – Erik Jun 23 at 10:09
  • @Erik Sorry for I do not know the difference, could you provide an explanation of the two? I was thinking of reducing the coordinates to the same length, though I am not sure as to why one is of a greater length than the other after having the same CRS transformation? – Stackbeans Jun 23 at 10:49
  • Are you concerned that "-0.679025" has more numbers in it than "-0.500616835380604"? Is that the "length" you are talking about? – Spacedman Jun 23 at 10:52
  • @Spacedman I am interested in why "-0.500616835380604" has a greater length (16) compared to "-0.679025" (6), and whether its possible to get the same length? – Stackbeans Jun 23 at 11:12
  • That's what I asked. That one number has more numbers - more digits - in it. Or "it is higher precision". Or more "decimal places". – Spacedman Jun 23 at 11:14
4

Short answer: it doesn't matter. You get what you give.

Long answer:

Let's make a point in lat-long, and dput it:

> p1 = st_sfc(st_point(c(-0.679025, 50.781688)), crs=4326)
> dput(p1)
structure(list(structure(c(-0.679025, 50.781688), class = c("XY", 

we get back what we gave - six decimal points. Now let's convert to national grid:

> dput(st_transform(p1, 27700))
structure(list(structure(c(493224.004559529, 98843.9561831813

we get lots of decimal places, because the projection code tries to be as precise as possible.

If we try and go to national grid then back to lat-long, we get answers in high precision with lots of decimal places:

> dput(st_transform(st_transform(p1, 27700), 4326))
structure(list(structure(c(-0.679024988164096, 50.7816879948538

but not exactly the same as we started with:

structure(list(structure(c(-0.679025, 50.781688), class = c("XY", 

but these are identical to about seven decimal places, or a ten-millionth of a degree, which is about a centimetre. Which for 99.999% of cases is nothing to worry about.

So that's my answer. Don't worry about it.

Coordinate precision starts with the data you are given, and processing it can introduce more decimal points (simple example, saying the square root of 2 is 1.4 might not be good enough, 1.414214 is a lot better). Coordinate processing is not an exact mathematical process, and approximations are made in projection code which mean that inverting doesn't always get back the same number with the same decimal precision. But its usually good enough, and not something you need to worry about.

5
  • Many thanks for the hopeful explanation! My aim in understanding this was to match coordinates that were the same between the two however they had different lengths. Would it be a good idea to try and convert the short length into a longer length during the matching process? – Stackbeans Jun 23 at 11:34
  • 2
    Like entropy, coordinate precision is a one-way street. Unless you're using a scanning electron microscope to collect your geodata, it's lucky if it's accurate to five places, much less eight or sixteen. – Vince Jun 23 at 11:57
  • I see, much like what you would want to find as an 'error' in a Taylor series expansion. Though, I have managed to shorten the length of the longer coordinates, and yet it still has 1 more decimal digit than the data already with epsg: 4326 projection. It seems that It cannot get any lower, from length 7 to 6, any reason why it stops at this? – Stackbeans Jun 23 at 13:00
  • If your real question is to try and match points that are within a given small tolerance, perhaps to identify points that are supposed to be the same thing but because of coordinate projections might not be, that's a different question and you should maybe ask that... – Spacedman Jun 23 at 14:07
  • @Spacedman I am presuming the reason the coordinates for the first dataset have been rounded at some point relative to 6 decimal places, given that the errors as you have mentioned are VERY accurate. So rounding the coordinates from 7 decimals to 6, seems to workout well for my case. – Stackbeans Jun 23 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.