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?
Related
I saw this figure in Leland Wilkinson's book the Grammar of Graphics and was wondering how I could go about creating something similar in R.
I am suspicious this could be done using rgl, persp3d, but there's a couple aspects that are unclear to me like how to create the conformal mapping shown in the coordinates of the XY plane, as well as how to create the 2D color map in a 3D context.
Any advice would be much appreciated. Thanks!
That should be possible with rgl, but there might be some snags in the details. Here's the outline:
The green surface does not appear to have a rectangular base,
so you'll pass matrices for all of x, y and z coordinates to surface3d() to draw it.
I can't tell if the map is on a flat surface with curved edges, or if it's a curved surface. In either case, you plot the surface with a 2D texture showing the map and the contours.
a. To produce that 2D texture, use whatever mapping software you've got, and output the image to a PNG file.
b. To put it on the surface, use surface3d() with arguments texture = <filename>, texture_s = ..., texture_t = ...) where texture_s and texture_t are set to coordinates in the image (bottom left = (0,0), top right = (1,1)) corresponding to each x and y location. The z value is
either constant or varying depending on whether you want it flat
or curved.
The axes will be drawn with axis3d.
I have a map of a mountainous landscape, http://skimap.org/data/989/60/1218033025.jpg. It contains a number of known points, the lat-longs of which can be easily found out using Google maps. I wish to be able to pin any latitude longitude coordinate on the map, of course within the bounds of the landscape.
For this, I tried an approach that seems to be largely failing. I assumed the map to be equivalent to an aerial photograph of the Swiss landscape, without any info about the altitude or other coordinates of the camera. So, I assumed the plane perpendicular to the camera lens normal to be Ax+By+Cz-d=0.
I attempt to find the plane constants, using the known points. I fix my origin at a point, with z=0 at the sea level. I take two known points in the landscape, and using the equation for a line in 3D, I find the length of the projection of this line segment joining the two known points, on the plane. I multiply it by another constant K to account for the resizing of this length on a static 2d representation of this 3D image. The length between the two points on a 2d static representation of this image on this screen can be easily found in pixels, and the actual length of the line joining the two points, can be easily found, since I can calculate the distance between the two points with their lat-longs, and their heights above sea level.
So, I end up with an equation directly relating the distance between the two points on the screen 2d representation, lets call it Ls, and the actual length in the landscape, L. I have many other known points, so plugging them into the equation should give me values of the 4 constants. For this, I needed 8 known points (known parameters being their name, lat-long, and heights above sea level), one being my orogin, and the second being a fixed reference point. The rest 6 points generate a system of 6 linear equations in A^2, B^2, C^2, AB, BC and CA. Solving the system using a online tool, I get the result that the system has a unique solution with all 6 constants being 0.
So, it seems that the assumption that the map is equivalent to an aerial photograph taken from an aircraft, is faulty. Can someone please give me some pointers or any other ideas to get this to work? Do open street maps have a Mercator projection?
I would say that this impossible to do in an automatic way. The skimap should be considered as an image rather than a map, a map is an projection of the real world into one plane, since this doesn't fit skimaps very well they are drawn instead.
The best way is probably to manually define a lot of points in the skimap with known or estimated coordinates and use them to estimate the points betwween. To get an acceptable result you probably have to assign coordinates to each pixel in the skimap.
You could do something like the following: http://magazin.unic.com/en/2012/02/16/making-of-interactive-mobile-piste-map-by-laax/
I am solving the exact same issue. It is pretty hard and lots of maths. Taking me a few weeks to solve it. Interpolation is the key as well with lots of manual mapping. I would say that for a ski mountain it will take at least 1000/1500 points to be able to get the very basic. So, not a trivial task unless you can automate the collection of these points (what I am doing!) ;)
I am in charge of a program that is used to create a set of nodes and paths for consumption by an autonomous ground vehicle. The program keeps track of the locations of all items in its map by indicating the item's position as being x meters north and y meters east of an origin point of 0,0. In the real world, the vehicle knows the location of the origin's lat and long, as it is determined by a dgps system and is accurate down to a couple centimeters. My program is ignorant of any lat long coordinates.
It is one of my goals to modify the program to keep track of lat long coords of items in addition to an origin point and items' x,y position in relation to that origin. At first blush, it seems that I am going to modify the program to allow the lat long coords of the origin to be passed in, and after that I desire that the program will automatically calculate the lat long of every item currently in a map. From what I've researched so far, I believe that I will need to figure out the math behind converting to lat long coords from a UTM like projection where I specify the origin points and meridians etc as opposed to whatever is defined already for UTM.
I've come to ask of you GIS programmers, am I on the right track? It seems to me like there is so much to wrap ones head around, and I'm not sure if the answer isn't something as simple as, "oh yea theres a conversion from meters to lat long, here"
Currently, due to the nature of DGPS, the system really doesn't need to care about locations more than oh, what... 40 km? radius away from the origin. Given this, and the fact that I need to make sure that the error on my coordinates is not greater than .5 meters, do I need anything more complex than a simple lat/long to meters conversion constant?
I'm knee deep in materials here. I could use some pointers about what concepts to research.
Thanks much!
Given a start point in lat/long and a distance and bearing, finding the end point is a geodesic calculation. There's a great summary of geodesic calculations and errors on the proj.4 website. They come to the conclusion that using a spherical model can get results for distance between points with at most 0.51% error. That, combined with a formula to translate between WGS-84 and ECEF (see the "LLA to ECEF" and "ECEF to LLA" sections, seems like it gets you what you need.
If you want to really get the errors nailed down by inverse projecting your flat map to WGS-84, proj.4 is a projection software package. It has source code, and comes with three command line utilities - proj, which converts to/from cartographic projection and cartesian data; cs2cs, which converts between different cartographic projections; and geod, which calculates geodesic relationships.
The USGS publishes a very comprehensive treatment of map projections.
I'd do a full-up calculation if you can. That way you'll always be as accurate as you can be.
If you happen to be using C++ the GDAL is a very good library.
For a range of 40km, you may find that approximating the world to a 2D flat surface may work, although a UTM transform would be the ideal way to go - in any case, I'd advocate using the actual WGS84 co-ordinates & ellipsoid for calculations such as great circle distance, or calculating bearings.
If you get bored, you could go down a similar line to something I've been working on, that can be used as a base class for differing datums such as OSGB36 or WGS84...
It's been a while since my math in university, and now I've come to need it like I never thought i would.
So, this is what I want to achieve:
Having a set of 3D points (geographical points, latitude and longitude, altitude doesn't matter), I want to display them on a screen, considering the direction I want to take into account.
This is going to be used along with a camera and a compass , so when I point the camera to the North, I want to display on my computer the points that the camera should "see". It's a kind of Augmented Reality.
Basically what (i think) i need is a way of transforming the 3D points viewed from above (like viewing the points on google maps) into a set of 3d Points viewed from a side.
The conversion of Latitude and longitude to 3-D cartesian (x,y,z) coordinates can be accomplished with the following (Java) code snippet. Hopefully it's easily converted to your language of choice. lat and lng are initially the latitude and longitude in degrees:
lat*=Math.PI/180.0;
lng*=Math.PI/180.0;
z=Math.sin(-lat);
x=Math.cos(lat)*Math.sin(-lng);
y=Math.cos(lat)*Math.cos(-lng);
The vector (x,y,z) will always lie on a sphere of radius 1 (i.e. the Earth's radius has been scaled to 1).
From there, a 3D perspective projection is required to convert the (x,y,z) into (X,Y) screen coordinates, given a camera position and angle. See, for example, http://en.wikipedia.org/wiki/3D_projection
It really depends on the degree of precision you require. If you're working on a high-precision, close-in view of points anywhere on the globe you will need to take the ellipsoidal shape of the earth into account. This is usually done using an algorithm similar to the one descibed here, on page 38 under 'Conversion between Geographical and Cartesian Coordinates':
http://www.icsm.gov.au/gda/gdatm/gdav2.3.pdf
If you don't need high precision the techniques mentioned above work just fine.
could anyone explain me exactly what these params mean ?
I've tried and the results where very weird so i guess i am missunderstanding some of the params for the perspective projection
* {a}_{x,y,z} - the point in 3D space that is to be projected.
* {c}_{x,y,z} - the location of the camera.
* {\theta}_{x,y,z} - The rotation of the camera. When {c}_{x,y,z}=<0,0,0>, and {\theta}_{x,y,z}=<0,0,0>, the 3D vector <1,2,0> is projected to the 2D vector <1,2>.
* {e}_{x,y,z} - the viewer's position relative to the display surface. [1]
Well, you'll want some 3D vector arithmetic to move your origin, and probably some quaternion-based rotation functions to rotate the vectors to match your direction. There are any number of good tutorials on using quaternions to rotate 3D vectors (since they're used a lot for rendering and such), and the 3D vector stuff is pretty simple if you can remember how vectors are represented.
well, just a pice ov advice, you can plot this points into a 3d space (you can do easily this using openGL).
You have to transforrm the lat/long into another system for example polar or cartesian.
So starting from lat/longyou put the origin of your space into the center of the heart, than you have to transform your data in cartesian coord:
z= R * sin(long)
x= R * cos(long) * sin(lat)
y= R * cos(long) * cos(lat)
R is the radius of the world, you can put it at 1 if you need only to cath the direction between yoour point of view anthe points you need "to see"
than put the Virtual camera in a point of the space you've created, and link data from your real camera (simply a vector) to the data of the virtual one.
The next stemp to gain what you want to do is to try to plot timages for your camera overlapped with your "virtual space", definitevly you should have a real camera that is a control to move the virtual one in a virtual space.
I'm writing a mapping application that I am writing in python and I need to get the lat/lon centroid of N points.
Say I have two locations
a.lat = 101
a.lon = 230
b.lat = 146
b.lon = 200
Getting the center of two points is fairly easy using a euclidean formula. I would like
to be able to do it for more then two points.
Fundamentally I'm looking to do something like http://a.placebetween.us/ where one can enter multiple addresses and find a the spot that is equidistant for everyone.
Have a look at the pdf document linked below. It explains how to apply the plane figure algorithm that Bill the Lizard mentions, but on the surface of a sphere.
poster thumbnail and some details http://img51.imageshack.us/img51/4093/centroidspostersummary.jpg
Source: http://www.jennessent.com/arcgis/shapes_poster.htm
There is also a 25 MB full-size PDF available for download.
Credit goes to mixdev for finding the link to the original source, and of course to Jenness Enterprises for making the information available. Note: I am in no way affiliated with the author of this material.
Adding to Andrew Rollings' answer.
You will also need to make sure that if you have points on either side of the 0/360 longitude line that you are measuring in the "right direction"
Is the center of (0,359) and (0, 1) at (0,0) or (0,180)?
If you are averaging angles and have to deal with them crossing the 0/360 then it is safer to sum the sin and cos of each value and then Average = atan2(sum of sines,sum of cosines)
(be careful of the argument order in your atan2 function)
The math is pretty simple if the points form a plane figure. There's no guarantee, however, that a set of latitudes and longitudes are that simple, so it may first be necessary to find the convex hull of the points.
EDIT: As eJames points out, you have to make corrections for the surface of a sphere. My fault for assuming (without thinking) that this was understood. +1 to him.
The below PDF has a bit more detail than the poster from Jenness Enterprises. It also handles conversion in both directions and for a spheroid (such as the Earth) rather than a perfect sphere.
Converting between 3-D Cartesian and ellipsoidal latitude, longitude and height coordinates
Separately average the latitudes and longitudes.