I have an image data whose reference is in WGS84 UTM ZONE 45N. So the unit extent of this file is in meter. I want to crop a polygon whose reference is in WGS84 UTM ZONE 45N and the extent unit is in decimal degree. I can not crop the polygon because of two different extent units. So how can I change the polygon extent to meters?
What you are saying is not possible. You cannot have a the WGS84 UTM ZONE 45N coordinate reference system (CRS) with degrees as unit. UTM is a planar CRS and the units are meter (sometimes other units are used, but they cannot be degrees). Also, you cannot simply change the extent from one unit to another. If the CRS of two datasets do not match you can transform one to the CRS of the other. In the case of vector and raster data you should normally transform the vector data. You can read about that here and in many other places.
But in your case, there is mistake earlier on that you need to fix.
Related
I need to produce the star map with constellations etc in the Mollweide projection (elliptical projection giving 360 view angle, used in plotting night sky). I found a recipe at https://kimnewzealand.github.io/2019/02/21/celestial-maps/ with the use of sf package and converting the default EPSG:4326 data of the sky objects into Mollweide projection.
At some stage the data is converted to the Mollweide projection using the command:
constellation_lines_sf_trans<- st_transform(constellation_lines_sf_trans, crs = "+proj=moll")
The resulting image, reproduced along the lines as described in the link, looks like:
It is fine, however, the coordinate system is equatorial, that is basically with the same rotation axis as all coordinate systems on the Earth, like WGS84 (North Pole upwards). For example, the Milky Way is shown on this plot, going at some angle 60 degrees. We need the so called galactic coordinates: this is the coordinate plane coinciding with the plane of our Galaxy. So, Milky way here would be just a horizontal line of the ellipse axis. For example, the solution found elsewhere, seems to use the same technique, but the code is not given there:
Here Milky Way is a horizontal line, and the North Pole is in the upper left corner (denoted as np; for example, here one can see the distorted recognizable constellations of Ursa Major/Minor around the North Pole). I would take this image, but there is a blind spot (showing the blind zone of an observatory which cannot reach this region in the sky), so I would like to reproduce this image: constellations + Mollweide projection + "galactic" orientation of the reference frame.
We are able to convert between variety of coordinate systems in R packages. It seems that most GIS tools use various flavors of Earth-related coordinate systems and projections, based to the rotation of the Earth (North Pole up), for majority of applications, needed for GIS. The question is whether it is possible to load and convert to a predefined galactic coordinate system (or, for example, to the ecliptic system), or to perform this conversion on the fly in the scripts with manual conversion of star data
EDIT: Actually, after further research, it appears that it all comes down to having your projection do a rotation. This also happens in the code on the interactive example I mention farther below. To make it center of the Galactic center, you need to rotate by [93.5949, 28.9362, -58.5988], which specify the [lambda, phi, gamma] rotation angles in degrees about each spherical axis. (when you rotate, there's no need to convert your ra or dec coordinates to galactic coordinates anymore.)
I don't know enough about mapping in R to be able to say if it's possible to specify a rotation on a projection, but here's an amazing example that shows this process with d3.js (and for those truly interested, shows where the angles come from). In case it's not possible, perhaps the route below would still be viable.
I was investigating the same thing, and I might've found something. I think that you first need to convert your equatorial ra (right ascension) and dec (declination) coordinates to galactic coordinates. And then apply a (Mollweide) projection. I'm not sure if that is completely correct since my case was slightly different, but at least this worked for me:
The dataset has rows of ra &dec in equatorial coordinates (given in degrees in my case)
Using the euler function of the astrolibR package, I calculate the Galactic longitude gl and latitude gb (ps: you can also use the glactc function):
data$gl <- euler(data$ra, data$dec, select=1)$ao
data$gb <- euler(data$ra, data$dec, select=1)$bo
Next, using these new coordinates I apply the Aitoff projection that is also part of the astrolibR package to get back x and y coordinates:
data$x <- -aitoff(data$gl, data$gb)$x
data$y <- aitoff(data$gl, data$gb)$y
which I can then plot
ggplot(data, aes(x, y)) + geom_point(shape=16, size = 0.1, alpha = 0.2) + coord_fixed()
(the image below is based on my own dataset of observations, the "darker line" follows the ecliptic line, and the two blobs in the lower right are the Large & Small Magellanic Clouds)
I found it useful to compare against this interactive map and setting the coordinates to "galactic", centering on 0,0 and then trying different kinds of projections.
Perhaps you can try applying the Mollweide projection with the gl and gb coordinates instead?
I am a bit new to the spatial packages of R. I have a hdf file from which I can get a data.frame with the latitude and longitude of the corners of the pixels, and the latitude and longitude of the centre of the pixel.
I have a specific point, and I would like to figure out which pixel covers that point.
Is there some function for this? what would be the best approach?
I work on a project building recognition system. I want to ask the experienced people in collecting GPS data from a map.
I want to partition the map into grids the area of each is 30 meter * 30 meter in each grid i want to store the center GPS coordinate (i.e point(15, 15)
What is the best way to do this?
Here's an image that demonstrates what I need.
This is not so easy:
There are two ways:
The professional solution:
Draw the grid 30x30 using the UTM coordinate system of that country / city.
UTM is measured in meters and is a flat cartesian coordinate system, while latitude / longitude are spehrical and not linear in x,y.
Align your grid such that it corresponds to integral UTM coordinates.
Then you need a method sto transform from latitude/longitude WGS84 to UTM (hopefully WGS84, but in some countries other ellipsoids are used)
The map display software should be apple to use UTM coordinate system.
And the simpler one:
stay using the lat long cooridnates and calculate the latitudinalGridWithDegrees measure in degrees wich corresponds to 30m (in the middle of the map/ city/ curch of city)
Since lat and lon do not use the same scale (1 degree of latitude differecne is not the same meters as one degree in longitude - only at the aequator), additionally calculate the longitudinalGridWithDegrees.
You will get two different values (they differ by a factor of cos(mapCenterLatitudeRadians).
To calculate this values either understand geo calculations or simply use a function which creates an offset point by given radius and direction from an start point. Use the center of the map as point to be offset (start point).
Create one point with offset 30m ,and heading = 0°, then measure the lat difference by subtracting and store in latitudinalGridWithDegrees
Do the same using heading = 90, and measure the longitudinal difference and store in longitudinalGridWithDegrees.
Now you are able two draw the grid using as lat and long steps the value of that both variables.
These then gives the corner points of such an square, and you always use latitude and longituide as interfcae to the mapping software.
If you are living in special countries/continents like Australia or Norwegen where the continent drift with up to 1m per year, it is more difficult.
Other continents drift only 1mm per year, which you and all other apps just ignore.
Advantages / Disadvantages of each solution
Simple Solution:
- grid is not square at corners of map, but probabyl not visisble for a city
- grid cell is exactly 30m only in the center of the map / reference point choosen for offset calc)
+ easier implementtaion
+ maping software interfcae simpler and always supported
Professional solution.
+ grid will match professional paper maps
+ grid cell is always exactly 30m
- needs geo transformation software or method
- unclear whether map display software provdes UTM (in most cases not)
However, maybe it is easier to assign road and house numbers to be measured, supported to match more ore less the grid.
EDIT: I have reworded the title question slightly, and adjusted the text to respond to the comment by #DWin.
Combining geographic layers that are projected and not projected can be challenging. Often, it seems, some transformation is necessary, as geographic layers come from different products and publishers.
I am aware that R has several tools to perform geographic transformations. For example:
For objects of class Spatial* in the sp package, the spTransform() function in the rgdal package can be used; and,
For objects of class Raster* in the raster package, the projectRaster() function can be used.
Here is a specific task that I would like to accomplish in R: Transform to UTM grid Zone 15N (Datum: NAD83) a polygons layer describing lakes in a UTM grid Zone 15N (Datum: NAD27) projection (this is in an ESRI shapefile format).
The useful thing here is the epsg database included in rgdal.
epsgs = make_EPSG()
subset(epsgs,grepl("15N",epsgs$note))
[etc]
code
2703 26715 # NAD27 / UTM zone 15N [etc]
2851 26915 # NAD83 / UTM zone 15N [etc]
[etc]
Those codes are what you need in spTransform. If your lakes are in a shapefile with that NAD27 projection, then:
require(maptools)
lakes = readShapeSpatial("lakes.shp")
proj4string(lakes)=CRS("+init=epsg:26715")
should give you the lakes as supplied (note I dont think readShapeSpatial will read a .prj file with a shapefile set, so I've set it here explicitly)
Now to convert to NAD83 datum version of UTM zone 15N:
lakes83 = spTransform(lakes,CRS("+init=epsg:26915"))
Rasters are a bit trickier since they generally involve a warp so that you end up with a regular grid in your projected coordinate system - you can't just transform the coordinates of the corners...
so i got three variables, my location, my target location and the compass heading.
how can i calculate where the target location should be represented on a virtual radar?
i guess i first must calculate the distance between the two gps points and the angle of them relative to north or so. and then there should be a formula with sin or cos to place that point on a coordinate system...?
ps: in javascript...
Start with simpler problems.
In 2D, try converting back and forth between cartesian and polar coordinates. References are available.
Do the same, but for the polar coordinates use an observer who measures angles from some ray that is not in the X direction.
The same, but using an origin for the polar coordinates that is not at {x=0,y=0}.
In 3D, go back and forth between cartesian and spherical coordinates.
Again, with spherical coordinates in an arbitrary orientation, using an arbitrary origin.
Now convert from GPS coordinates (which are spherical) to cartesian, then to radar-centered spherical.