Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in proj4string ... Geographical CRS given to non-conformant data #1

Open
Geoff99 opened this issue Jul 30, 2015 · 4 comments
Open

Comments

@Geoff99
Copy link

Geoff99 commented Jul 30, 2015

Hi there

First --- thanks for a really neat package.

I encountered a problem while running a variant of an example from http://vietletruc.com/tag/cartogram/. (on a Windows machine)

quick.carto fails with the following message.

d> world.carto <- quick.carto(world, world@data$Population, blur = 0)
Error in `proj4string<-`(`*tmp*`, value = <S4 object of class "CRS">) : 
  Geographical CRS given to non-conformant data: -189.000000 -192.188202  185.811798
Called from: stop(mess)

If I look at the world object which is a SpatialPolygonsDataFrame I find that it uses (as I expected) a longlat projection. And both the latitude and longitude values are all "legal".

d> world@proj4string
CRS arguments:
 +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 
d> range(coordinates(world)[, 1])
[1] -178.1269  179.2159
d> range(coordinates(world)[, 2])
[1] -80.50275  78.60600
d> 

However if I overwrite the proj4string, and then try quick.carto again, everything is fine.

d> world@proj4string <- CRS(as.character(NA))
d> world.carto <- quick.carto(world, world@data$Population, blur = 0)
d> 

I suspect (but have no evidence) that somewhere in the internals of quick.carto a new expanded copy of the SpatialPolygonsDataFrame is made including the surrounding "sea" as described in the Gastner Newman paper. And that the copy simply uses the same proj4string / CRS as the map being morphed. And that when the longlat values are expanded, they exceed the legal values for longitudes and latitudes. Or perhaps simply that at some stage during the morphing process the (warped) long lat values for the cartogram exceed the legal values for longitude and latitude. Hence this error message, which I think comes from a validity check during the creation of a (copy of) SpatialPolygonsDataFrame, when the CRS is longlat .

If I am correct, wiping out the proj4string / CRS in the way I have above is actually the correct thing to do I think --- since after morphing it would be fair to say that the coordinate reference system of the warped map is no longer any type of longitude latitude projection (nor indeed any other projection likely to be known to standard geography and supported in the CRS / proj4 universe).

Not sure what to do, but maybe this issue will help others who may experience a similar problem.

Once again, really like the package, thanks.

Geoff

@ghost
Copy link

ghost commented Mar 28, 2017

Hello!

Thank you very much for posting this issue! I'm having the same problem, but unfortunately I'm not having the same results as you.

I'm having the same error:

> cont.carto <- quick.carto(cont, cont$data, blur = 0)
  Error in `proj4string<-`(`*tmp*`, value = <S4 object of class "CRS">) : 
     Geographical CRS given to non-conformant data: -189.000000 -192.177435  185.822565

After applying your solution:

> cont@proj4string <- CRS(as.character(NA))
> cont.carto <- quick.carto(cont, cont$data, blur = 0)
     Error in .local(obj, ...) : NA values in coordinates

Any ideas what can this be?
Thank you very much!

@Geoff99
Copy link
Author

Geoff99 commented Mar 29, 2017

Hi.

It is quite a while since I last looked at this, so my memory of the details is really vague.

Have you tried looking at the actual values in the coordinates of cont (which I presume is your SpatialPolygonsDataFrame) using coordinates(cont)[,1] and coordinates(cont)[,2] ? I think the error message is saying that it is encountering NA values in there -- but I don't know whether that I happening because cont itself has NA values, or because at some stage one of the intermediate calculations that quick.carto does results in a NA.

Other than that, I don't think I have much advice I can offer. Hope that helps you track the problem down.

Good luck

Geoff

@ghost
Copy link

ghost commented Mar 30, 2017

Hi Geoff,

Thank you very much for your reply! I understand that it has been a while, so don't worry. In the end, I had some problems with the polygons of cont so after I made it a valid SpatialPolygonsDataFrame, quick.carto worked :)

Cheers and thanks,

Vanessa

@Geoff99
Copy link
Author

Geoff99 commented Mar 30, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant