I want to store in table places defined by coordinate (41.67102,72.917482) and radius 100 metes. How can I convert 100 metes in same measure as coordinates because 1 latitude != 1 longitude. Or I should use postgis somehow?
In postgis, the circle would be calculated with something like:
update PLACES set the_circle = (ST_Buffer((place_geom)::geography, 100 ))::geometry) ;
Related
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).
I'm having trouble understanding what precisely the output of meshgrat means and how this relates to the lat and lon parameters of pcolorm(lat,lon,Z). I have a grid of global data, I'll call Z, at a 1.5 degree latitude x 1.5 degree longitude spatial resolution. Thus I have a matrix that's 120 x 240 (180 degrees of latitude / 1.5 = 120, 360 degrees of longitude / 1.5 = 240). Row 1 is 90 N and column 1 is 180 W (-180).
If I follow the MATLAB documentation, I can use meshgrat to produce the lat and lon arguments that I need to supply to pcolorm as follows.
latlim = [-90 90];
lonlim = [-180 180];
[lat,lon] = meshgrat(latlim,lonlim,[120 240]);
However, I don't understand why the spacing of the output is the way it is. For example, the first five values of lat are [-90.0000, -88.4874, -86.9748,-85.4622,-83.9496...]. The lon values follow the same spacing. The spacing is very close to 1.5 degrees, but it isn't. Why is there a discrepancy? The documentation claims that the paired lat and lon values are the location of the graticule vertices. In that case, these values make some sense, since there will always be one more vertex than actual grid cells. To test this, I made the following adjustment to the meshgrat code by adding one extra row and column:
latlim2 = [-90 90];
lonlim2 = [-180 180];
[lat2,lon2] = meshgrat(latlim2,lonlim2,[121 241]);
This did, indeed, produce the expected output, with the spacing now exactly at 1.5 degrees (i.e [-90.0000, -88.5000, -87.0000, -85.5000, -84.0000...]). Again, this is logical if these are viewed as vertices. But under this scenario lat and lon no longer match Z in size, which goes against how the documentation says to treat lat and lon in this case.
There seems to be a mismatch here: either the spacing in the lat lon grids are not accurate, or the girds are not the same size as the data, which would be fine in my mind as long as MATLAB knows how to interpret them accordingly, but the documentation does not seem to suggest using it this way. I have no detailed knowledge of how the MATLAB functions work at a finer level. Can someone explain to me what I'm missing?
Thus I have a matrix that's 120 x 240 (180 degrees of latitude / 1.5 = 120, 360 degrees of longitude / 1.5 = 240).
180/1.5 is indeed 120. But you also have an element at 0deg (presumably). That's 121.
How can I check if polygon in one table intersect with point and radius from second table ?
first table we have field (name: area) ,type geometry which contains polygon.
second table we have 2 fields:
field (name: pt) ,type: geometry which contains point
field (name: radius) ,type: int
The geometry values in WKB format
I want to check if the polygon intersect with the circle (point + radius).
How can I do it ?
You can use the ST_Distance function to find the distance between the polygon and the point. If the distance between them is less than the radius, then the polygon would intersect with a circle around the point with that radius.
Example query:
SELECT *
FROM polygon_table, circle_table
WHERE ST_Distance(polygon_table.area, circle_table.pt) <= circle_table.radius;
Use ST_Contains to check if the point is inside of the polygon and then calculate the buffer around your point and see if they intersect, with ST_Buffer and ST_Intersects respectively. Something like:
SELECT *
FROM polygon_table t1, circle_table t2
WHERE
ST_Contains(t1.area, t2.pt) AND
ST_Intersects(ST_Buffer(t2.pt,t2.radius),t1.area)
Note: the buffer will be created using the unit of your SRS. For instance, if you're using WGS84 it will be in degrees. If you want it in metres instead, use geography instead of geometry or simply cast it in real time, e.g. t1.area::geography.
I have markers that were plotted in a legacy system on a EPSG4326 map with a bounds of -180 to 180 latitude and -180 to 180 longitude. I'm now trying to plot these onto a EPSG4326 map that has a bounds of -90 to 90 latitude and -180 to 180 longitude. How can I convert the original coordinate to the new coordinate system so it appears on the new map at the same location? I'm trying to tackle this within a JavaScript application using the Leaflet mapping library. Any pointers or insight would be greatly appreciated.
As an example, the location of London on the source map that represents latitude in -180 to 180 range is approximately (Lat: 61.8750, Lon: 0.1278) and on destination map where latitude is -90 to 90 it would be about (Lat: 51.5074, Lon: 0.1278).
I figured it out!
newlat = (180.0/Math.PI*(2.0*Math.atan(Math.exp(oldlat*Math.PI/180.0))-Math.PI/2.0))
Thus if oldlat = 61.8750, newlat = 52.482780222078226 which is what I needed and solves my problem perfectly, converting a latitude with different extents into the new extents.
The reverse (if needing to reconvert) formula is:
oldlat = ((180.0/Math.PI)*Math.log(Math.tan((90.0+newlat)*Math.PI/360.0)))
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%.