I have a points with coordinates EPSG Projection 3059 - LKS92 / Latvia TM. I need to compute the distance in meters between two points.
It is easy to compute euclidean distance between two points, but I am not sure if the resulting distance is expressed in meters?
PROJCS["LKS92 / Latvia TM",
UNIT["metre",1,
PARAMETER["scale_factor",0.9996],
The unit is 1 meter, but should the scale factor taken into account? Maybe 1 unit in this system is not 1m but 0.9996 meters?
No, the scale factor in a map projection is integrated in the projection calculations. The purpose of the factor is to minimise overall distortion as the easting from the central meridian (24°E) increases. 0.9996 is a common factor when transverse mercator (TM) is involved.
Once projected, the resultant coordinate is in metres (in this case), no further scaling is needed, and you can use a simple Pythagorean hypotenuse calculation to determine a distance.
Related
Say, I got a dataset of intensity for each wavelength from these curves in the picture and performed curve fitting with the gaussian function for each curve to extract its parameters like peak amplitude, center, and FWHM.
)
I want to apply the AI method to predict the Imax (maximum Intensity), center, and FWHM for another curve in different temperatures. Say I want to predict Imax, center, and FWHM at 1 Celcius, is it possible to do so? which method should I try and how should I format the input feature and its labels? thank you.
i am not sure to have understood why the elbow method is an approximate right way to determine a value of epsilon for DBSCAN algorithm. For instance, in the example below:
I considered the distance from the 5-th nearest neighbors and the points are arranged from the one with the minimum 5th-neighbor distance to the one that is at most distance from the 5th-neighbor.
I considered euclidean distane for the plot.
So i know that point 0-20, for instance, are the ones that are the most close to their 5-th nearest neighbor, then the points in the elbow are the one at intermediate distance from their 5-th nearest neighbor, and so they have a medium density. Then we reach point of very low density, far from their 5-th closest neighbor.
But I can't understand why it is reasonable to choose as the value of epsilon the distance between the k-th closest neigbor of points in the elbow.
Thanks for the help.
From the paper dbscan: Fast Density-Based Clustering with R (page 11)
To find a suitable value for eps, we can plot the points’ kNN
distances (i.e., the distance of each point to its k-th nearest
neighbor) in decreasing order and look for a knee in the plot. The
idea behind this heuristic is that points located inside of clusters
will have a small k-nearest neighbor distance, because they are close
to other points in the same cluster, while noise points are more
isolated and will have a rather large kNN distance.
We need a cutoff to decide what k-NN distance is considered "small" and what is "large." The knee heuristic identifies such a cutoff for epsilon as the k-NN distance where the distance starts to increase rapidly.
The range of longitude and latitude of Earth sphere are [-180, 180] and [-90, 90] respectively. I want to get equal area grids by 0.5 deg * 0.5 deg (area around the equator).
As the distortion increased when approaching the polar points. The grid should have the same latitude range but different longitude range.
How should I do?
First, what you ask got, if interpreted literally, is impossible for three reasons. One, the area of the surface of a perfect sphere is about 82506.97413 times the area of a portion 30' (thirty seconds, or half a degree) by 30' at the equator. Since that is not an integer, you cannot partition the surface into a whole number of regions of that size. Two, if you constrain the latitude span to be equal, then the rings at different latitudes must have different numbers of segments, so you cannot make a grid. The edges of segments in different rings cannot coincide. Three, the Earth is not a perfect sphere, and regions of equal area on a sphere will not map to equal areas on the Earth. Imperfections in the Earth would prevent us from knowing the area of each region (and those areas would change as the surface changes).
Supposing that what you actually want is an approximate solution that is not a grid, I suggest you examine the Google search results for “partition sphere into equal areas“. One of the top results is this paper, in which Figure 1.1 appears to show a sphere that has been partitioned into regions of similar, possibly equal, latitude span but different longitude spans. Another result is this page, which is a Matlab package for exploring sphere partitioning.
You are trying to put equal area tiles on the earth's surface with fixed extent like the mirrors on a disco ball.
So if you start at the Equator with a 0.5deg*0.5deg tile, your next tile to the north or south would have a longitude extent of 0.5deg/cos(0.5deg) to have the same area, so slightly above 0.5deg.
With that tile you cannot fill the full circle with an integer number of tiles.
Ending at the pole your tile longitude extent would be 0.5deg/cos(89.5deg) = 59,29..deg which also does not fit exactly into 360degs.
If you decrease the size of your tiles you might have an acceptable small error but yet no real "grid" because coming to the poles there will always be less tiles than at the Equator..
Maybe something like "equal area map projection" might help? http://en.wikipedia.org/wiki/Map_projection#Equal-area
Two possible solutions here (formulas in R):
lat<-seq(-89.75,89.75,by=0.5)
Formula 1, based on the area of a grid point in the equator (111.11km2).
r<-(111*10^3*0.5)*(111*10^3*0.5)*cos(lat*pi/180)
Formula 2, based on the radius of the Earth.
ER<-6371*1000
r2<-(ER^2)*(0.5*pi/180)^2*cos(lat*pi/180)
This question already has an answer here:
Closed 11 years ago.
How do i convert a given distance (in metres) into geographic coordinates.
What I need is to draw a polygon on the map (a regular polygon, like a circle), however, it's radius is given in meters, how do I calculate the radius in degrees or radians?
I'll probally code it in c
Oh man, geographic coordinates can be a pain in the behind. First of all, I'm assuming that by geographic coordinates, you're talking about geodetic coordinates (lat/lon).
Second of all, you can't find a "radius" in radians or degrees. Why, you ask? Well, one degree of longitude at the equator is WAY longer than one degree of longitude close to the north or south pole. The arc of one degree latitude also changes based on your location on the earth since the earth is not a perfect sphere. It's usually modeled as an ellipsoid.
That being said, here are two ways to map the coordinates of a polygon onto lat-lon coordinates:
1) If you're feeling like a complete badass, you can do the math in lat-lon. Lots of trig, easy to make mistakes... DON'T DO IT. I'm just including this option here to let you know that it is possible.
2) Convert your geodetic coordinates to UTM. Then, you can do whatever you need to do in meters (i.e. find the vertices of a polygon), and then convert the resulting UTM back to geodetic. Personally, I think this is the way to go.
Well, consider that at the equator (0 degrees latitude) one degree of longitude is equal to appximately 60 nautical miles. At either pole (90 degrees latitude) a single degree of longitude equals 0 nautical miles. As I remember the cosine of the latitude times 60 will give you the approximate distance in nautical miles at that latitude of a single degree of longitude.
However, how accurate you would be would have to account for the map projection you're using. For aeronautical maps, they use the Lambert Conformal Conic projection, which means distances are only exactly accurate along the two latitudes that the cone cuts the sphere of the earth. But if an approximation is good enough, you may not need the accuracy.
For conversion, one nautical mile equals 1.852 km. If I did the arithmetic properly (no guarantee, I'm in my 70s), that means that a meter equals (except as you get really close to the poles) 0.0000009 degrees latitude. It also equals 0.0000009 degrees longitude on the equator. If you're not at the equator, divide the 0.0000009 by the cosine of the latitude to get the degrees of longitude.
So, a 1000 meter radius circle at 45 degrees latitude would mean a radius of 0.0009 degrees latitude and 0.0009/0.707 degrees longitude. Approximately of course.
All this is from memory, so take it with a grain of salt. If you really want to get involved, Google geographic equations or some such.
Check out http://trac.osgeo.org/proj/wiki/GeodesicCalculations. Depending on the accuracy you need, this can get pretty complicated, so you're probably best off starting from some existing code.
Does Postgres' Spatial plugin, or any Spatial package for that manner, factor in the altitude when calculating the distance between 2 points?
I know the Spatial packages factor in the approximate curvature of the earth but if one location is at the top of a mountain and the other location is close to the sea - it seems like the calculated difference between those two points would greatly vary if the difference in altitude was not factored into account.
Also keep in mind that if I have 2 points are at the same ocean altitude but a mountain exists between the 2 points - the distance package should account for this.
Those factors are not being counted at all. Why? The software only knows about the two features (the two points you are getting the distance, the sphere/spheroid and a datum/projection factor).
For that to happen you need to probably use a developed linestring, in which you will connect your point with n vertices, each of them being Z aware.
Imagine this (loose WKT): LINESTRING((0,1,2),(0,2,3),(0,3,4),(0,10,15),(0,11,-1)).
Asking the software to calculate the distance between each vertex and summing it up, will consider the variations of terrain. But without something like that, it is impossible to map for irregularities in terrain.
All GIS softwares cannot tell, by themselves, what are those irregularities in terrain, and therefore, not take them in account.
You can create such linestrings (automatically) with softwares like ArcGIS (and others), using a line (between two points), and a surface file, such as the ones provided freely by NASA (SRTM project). These files come in a raster format, and each pixel has a X Y and Z value, in meters. Traversing the line you want, coupled with that terrain profile, you can achieve the calculation you want to achieve. If you need to have super extra precise calculations, you need a precise surface, and precise Z values in each vertex of this profile line.
That cleared up?
If the distance formula you're using does not take the altitude of the two points as parameters (in addition to the Latitudes and Longitudes of the two points), then it does not factor in altitude to the distance calculation. In any event, altitude difference does not have a very significant effect on calculated distance.
As usual with GPS, the difference in distance calculations that altitude would make is probably smaller than the error in most commercial GPS devices anyway, so in most applications altitude can be safely dispensed with (altitude measurements themselves are pretty inaccurate with commercial GPS devices, although survey data on altitudes is quite accurate).
PostgreSQL does not factor in altitude when calculating distances. It is all done in a planar surface.
Most of database spatial packages will not take this into account, altought, if your point is 3d, i.e., has a Z coordinate that might happend.
I don´t have PostgreSQL in this machine, but try this.
SELECT ST_DISTANCE(ST_POINT(0,0,10),ST_POINT(0,0,0));
It´s fairly easy to know if it is taking into account your Z value, since the return should be > 0; If that turns out to be true, just create Z aware features, and you will be successfull.
What SQL SERVER 2008, for example, takes into account when calculating distances, is the position of a Geography feature in a sphere. Geometry features in SQL SERVER will always use planar calculations.
EDIT: checked this in PostGIS manual
For Z aware points you must use the ST_MakePoint function. It takes up to 4 arguments (X Y Z and M). St_POINT only takes two (X Y)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance.html
ST_DISTANCE = 2D calculations
ST_DISTANCE_SPHERE documentation (takes in account a fixed sphere for calculations - aka not planar)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance_Sphere.html
ST_DISTANCE_SPHEROID documentation (takes into account a choosen spheroid for your calculations)
http://postgis.refractions.net/documentation/manual-1.4/ST_Distance_Spheroid.html
ST_POINT documentation
http://postgis.refractions.net/documentation/manual-1.4/ST_Point.html