I would like to simplify a GPS coordinate to a "TOP LEFT" position of a defined virtual grid (for example 100 kilometers).
If my GPS coordinate is in a cell of the grid, then we use the GPS position of the "TOP LEFT" of the cell.
The new coordinate is not intended to be displayed on a map but just to be communicated and manipulated.
This imaginary grid would have an editable distance (e.g. 1 kilometer or 100 kilometers).
I had imagined calculating the distance between two known points:
latitude = 0 / longitude = 0 (Null Island)
has GPS coordinate (ex: lat 48.858284648396626 lng 2.294501066207886)
we calculate distances for lat/lng (i use leaflet distanceTo function )
distance_latitude: 5432.79 km (?) : distanceTo( [0,0],[48.858284648396626,0])
distance_longitude: 255.14 km (?) : distanceTo( [0,0],[0,2.294501066207886])
var distance=100; // in kilometers
distance_latitude= Math.floor(distance_latitude/ distance) * distance;
= 5400
distance_longitude= Math.floor(distance_longitude / distance) * distance;
= 200
but after that... how to transform these kilometers (from Null Island) to a new coordinate? (so the top left of the current cell where the poi is)
(grid not in scale!)
Sometimes it's better to wait for a good night's sleep!
answer: just move nullIsland the distance between the poi and... nullIsland... simply! So all the dots (red) take the TopLeft position -blue marker- of the imaginary grid (in my screenshot: a 5Km grid).
Related
I'm trying to find a way to calculate zoom level given a radius in meters.
For example, I want to show 100km radius within point x,y, how do I calculate the proper zoom level for that point?
This will depend on:
the number of tiles of your map
the latitude of your view
The resolution (meters/pixel) of a web-Mercator map at zoom 0 (one tile for the whole map) is given by:
resolution = cos(latitude_rad) * earth circumference / tile width
with the latitude in radians, the earth circumference in meters (2 * pi * radius) and the map width given by:
map width = 256 as the tiles are 256 pixel wide.
At each zoom step, the width (in pixel) is doubled, so at zoom z:
map width = 256*2^zoom
so :
resolution=cos(latitude_rad) * 2*pi* 6371008 / (256*2^zoom)
but as you are using a certain number n of 256 pixel tiles:
widthmap = cos(latitude_rad) * 2*pi* 6371008*n / (2^zoom)
Now, to get the zoom from the distance:
with latitude in degrees, radius is your circle in meters, and n the number of tiles to display:
zoom = floor(log2 ((cos(latitude *pi/180) * 2*pi* 6371008*n)/radius))
(floor as you want an integer and to make sure your whole circle is on the map)
For example, at 45 degrees N/S, 100m and 1 tile will give you a zoom of 18.
I want to plot a latitude and longitude using matlab. Using that latitude and longitude as center of the circle, I want to plot a circle of radius 5 Nm.
r = 5/60;
nseg = 100;
x = 25.01;
y = 55.01;
theta = 0 : (2 * pi / nseg) : (2 * pi);
pline_x = r * cos(theta) + x;
pline_y = r * sin(theta) + y;
hold all
geoshow(pline_x, pline_y)
geoshow(x, y)
The circle does not look of what I expected.
Drawing a circle on earth is more complex that it looks like.
Drawing a line or a poly line is simple, because the vertices are defined.
Not so on circle.
a circle is defined by all points having the same distance from center (in meters! not in degrees!!!)
Unfortuantley lat and lon coordinates have not the same scale.
(The distance between two degrees of latidtude is always approx. 111.3 km, while for longitude this is only true at the equator. At the poles the distance between two longitudes approach zero. In Europe the factor is about 0.6. (cos(48deg))
There are two solution, the first is more universal, usefull for nearly all problems.
convert spherical coordinate (of circle center) to cartesian plane with unit = 1m, using a transformation (e.g equidistant transformation, also called equirectangular transf., this transformation works with the cos(centerLat) compensation factor)
calculate points (e.g circle points) in x,y plane using school mathematics.
transform all (x,y) points back to spherical (lat, lon) coordinates, using the inverse transformation of point 1.
Other solution
1. write a function which draws an ellipse in defined rectangle (all cartesian x,y)
2. define bounding of the circle to draw:
2a: calculate north-south diameter of circle/ in degrees: this a bit tricky: the distance is define in meters, you need a transformation to get the latitudeSpan: one degrees of lat is approx 111.3 km (eart circumence / 360.0): With this meters_per_degree value calc the N-S disatcne in degrees.
2b: calculate E-W span in degrees: now more tricky: calculate like 2a, but now divide by cos(centerLatitude) to compensate that E-W distances need more degrees when moving north to have the same meters.
Now draw ellipseInRectangle using N-S and E_W span for heigh and width.
But a circle on a sphere looks on the projected monitor display (or paper) only like a circle in the center of the projection. This shows:
Tissot's Error Ellipse
I'm working on a simple location-aware game where the current location of the user is shown on a game map, as well as the locations of other players around him. It's not using MKMapView but a custom game map with no streets.
How can I translate the other lat/long coordinates of other players into CGPoint values to represent them in the world scale game map with a fixed scale like 50 meters = 50 points in screen, and orient all the points such that the user can see in which direction he would have to go to reach another player?
The key goal is to generate CGPoint values for lat/long coordinates for a flat top-down view, but orient the points around the users current location similar to the orient map feature (the arrow) of Google Maps so you know where is what.
Are there frameworks which do the calculations?
first you have to transform lon/lat to cartesian x,y in meters.
next is the direction in degrees to your other players. the direction is dy/dx where dy = player2.y to me.y, same for dx. normalize dy and dx by this value by dividing by distance between playerv2 and me.
you receive
ny = dy / sqrt(dx*dx + dy*dy)
nx = dx / sqrt(dx*dx + dy*dy)
multipl with 50. now you have a point 50 m in direction of the player2:
comp2x = 50 * nx;
comp2y = 50 * ny;
now center the map on me.x/me.y. and apply the screen to meter scale
You want MKMapPointForCoordinate from MapKit. This converts from latitude-longitude pairs to a flat surface defined by an x and y. Take a look at the documentation for MKMapPoint which describes the projection. You can then scale and rotate those x,y pairs into CGPoints as needed for your display. (You'll have to experiment to see what scaling factors work for your game.)
To center the points around your user, just subtract the value of their x and y position (in MKMapPoints) from the points of all other objects. Something like:
MKMapPoint userPoint = MKMapPointForCoordinate(userCoordinate);
MKMapPoint otherObjectPoint = MKMapPointForCoordinate(otherCoordinate);
otherObjectPoint.x -= userPoint.x; // center around your user
otherObjectPoint.y -= userPoint.y;
CGPoint otherObjectCenter = CGPointMake(otherObjectPoint.x * 0.001, otherObjectPoint.y * 0.001);
// Using (50, 50) as an example for where your user view is placed.
userView.center = CGPointMake(50, 50);
otherView.center = CGPointMake(50 + otherObjectCenter.x, 50 + otherObjectCenter.y);
I am looking for a way to calculate the distance between 2 points on the globe. We've been told to use Haversine, which works fine to calculate the shortest distance between the 2 points.
Now, I'd like to calculate the "long distance" between to points. So suppose you have 2 cities, A in the west and B in the east. I want to know the distance from B to A if I would travel eastwards around the globe and then reach A coming from the west.
I've tried changing a couple of things in the haversine function, but doesn't seem to work.
Anyone know how I can simply do this using small adjustments to the haversine function?
This is what I'm using now:
lat1, lat2, lng1, lng2 are in radians
part1 = sin(lat2) * sin(lat1);
part2 = cos(lat2) * cos(lat1) * cos(lng1 - lng2);
distance = 6378.8 * acos(part1 + part2);
The way I see it is that you can draw a circle around the globe between the 2 cities. The long distance the the circumference of that circle minus the short distance. But in contrary of what was replied, the circle's length is not equal to the earth's circumference. This is only the case for 2 points on the equator.
Tnx
Jeroen
The circumference of the earth is approx 40,075KM, work out the short distance and subtract it from that.
I wanted to test the mapKit and wanted to make my own overlay to display the accuracy of my position.
If i have a zoom factor of for example .005 which radius does my circle around me has to have(If my accuracy is for example 500m)?
Would be great to get some help :)
Thanks a lot.
Look at the documentation for MKCoordinateSpan, which is part of the map's region property. One degree of latitude is always approx. 111 km, so converting the latitudeDelta to meters and then getting to the meters per pixel should be easy. For longitudinal values it is not quite so easy as the distance covered by one degree of longitude varies between 111 km (at the equator) and 0 km (at the poles).
My way to get meters per pixel:
MKMapView *mapView = ...;
CLLocationCoordinate2D coordinate = ...;
MKMapRect mapRect = mapView.visibleMapRect;
CLLocationDistance metersPerMapPoint = MKMetersPerMapPointAtLatitude(coordinate.latitude);
CGFloat metersPerPixel = metersPerMapPoint * mapRect.size.width / mapView.bounds.size.width;
To add to another answer, a difference of one minute of latitude corresponds to one nautical mile: that's how the nautical mile was defined. So, converting to statute miles, 1 nautical mile = 1.1508 statue miles, or 6076.1 ft. or 1852 meters.
When you go to longitude, the size of the longitude circles around the Earth shrink as latitude increases, as was noted on the previous answer. The correct factor is that
1 minute of longitude = (1852 meters)*cos(theta),
where theta is the latitude.
Of course, the Earth is not a perfect sphere, but the simple calculation above would never be off by more than 1%.