1

I am trying to overlay points on a polygon, but identicalCRS complains the reference system is not the same. It actually is the same:

> polygon@proj4string
CRS arguments:
 +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 
> points@proj4string
CRS arguments:
 +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0 
> 
> identicalCRS(polygon@proj4string, points@proj4string)
Error in (function (classes, fdef, mtable)  : 
  unable to find an inherited method for function ‘proj4string’ for signature ‘"CRS"’
> identicalCRS(polygon, points)
[1] FALSE

Bug or feature? Any workaround?

Improve this question
1
  • The strings are not the same but the difference is irrelevant. As such, just pipe one string into the other to make them match: proj4string(x) <- proj4string(y) On a side note, you should not be using R internals in your object names (eg., there are functions called points and polygon) as this can cause very bizarre behavior in R.
    – Jeffrey Evans
    Commented Mar 29, 2018 at 15:10

1 Answer 1

Reset to default
-1

They're obviously not identical; one CRS has the parameter +no_defs and one doesn't. The function is supposed to pick up on that and report it to you.

The no_defs parameter is mentioned in the proj4 documentation here - and explained further here, although I confess I'm not sure what the practical implications are in this case - suspect minimal. There's some commentary in this other question that leads one ultimately to (I think) this part of the proj4 repo, which is tragically full of non-OCR'd PDF files. I can't see much mention of +no_defs in there, so I'd be interested to hear from anyone who can expand on what the 'surprising problems' from using the defaults file might be.

Edit in response to comments: If you View() the source code, sp:::identicalCRS1 is in use, which splits the input proj strings into their component args and then runs setequal to check whether the same set of args exists in both strings. As such, its a string comparison function that can handle the proj args being in different orders. It will report a difference because of +no_defs being present in one string.

It remains unclear whether that 'matters', since the CRSs are 'identical' but reprojecting to match is apparently not ok.

Improve this answer
4
  • 1
    They are identical, the +no_defs parameters has no impact in this CRS, that has no cartographic projection. The question is whether the identicalCRS is trying an actual Geodesic/Cartographic identity or something else, e.g. string comparison. In the former case the output for the example above is in error.
    – Luís de Sousa
    Commented Mar 29, 2018 at 13:42
  • Your recommendation to reproject the data is quite incorrect and could cause serious issues with the resulting data. Following the above comment, the no_defs parameter means absolutely nothing in this regard.
    – Jeffrey Evans
    Commented Mar 29, 2018 at 15:06
  • Ok, can you explain why please @JeffreyEvans? The docs are not enlightening, and I'd like to avoid mistakes in my own work as much as OP.
    – obrl_soil
    Commented Mar 29, 2018 at 23:26
  • Because you are performing a transformation on data that already has that geometry. Sometime try projecting UTM to the same UTM definition, it causes the data to become geographically microscopic.
    – Jeffrey Evans
    Commented Mar 30, 2018 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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