I have a rails app that is using rgeo 0.3.19 with proj4 support connecting to a PostGIS 1.5 database with the rgeo-activerecord 0.4.5 gem.
My app has a model called Region which contains a geographic point, a radius, and a polygon shape. When a new region is about to save it uses the region's geofactory's buffer function to create a polygon using the radius and the geographic point.
Here is the geofactory that is being used for the region model
GEOFACTORY = RGeo::Geographic.projected_factory(:buffer_resolution => 8, :projection_proj4 => '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=#null +wktext +no_defs', :projection_srid => 3857)
The projection_srid I am using is that of Apple and Google maps mercator projection 3857.
The problem is that the buffer that is being created is not the same size as the one I am drawing in either apple maps or google maps. For example, if I use the built in MapKit function MKCircle
[MKCircle circleWithCenterCoordinate:self.coordinate radius:50];
The circle will draw and overlay like this.
But if I take the coordinates that were created form the buffer function that make up the polygon shape in the database and plot them on google maps I get this.
As you can see, the polygon that was created using the same projection system is smaller than it should be. This problem exponentially grows out of control based on the size of the radius defined. I have also tried to use the simple_mercator factory as defined in RGeo which yielded the same results.
Hopefully somebody has some insight into why, when a longitude,latitude projected point is buffered it creates an incorrectly sized polygon.
What you're observing here is Mercator distortion. A distance of "50" in a mercator projection doesn't correspond to 50 meters on the real planet surface, unless you're at the Equator.
The circle drawn by your iOS map is correct: that's the 50 meter radius. What I suspect you did to create your second image was to project the point into a Mercator projection (according to the Proj4 you provided). Then you proceeded to create a buffer with radius 50 in the projected coordinate system. However, 50 Mercator units at latitude 40.61 corresponds to only about 37.96 meters in surface of the earth distance. So when you project that polygon back into latitude and longitude and plot it, that's what you see: a 38-meter circle.
One way to visualize this is to look at the full world map on Google Maps. Draw a circle of radius 50 pixels at the equator. And then draw another circle of radius 50 pixels over Greenland. On the map (in Mercator coordinates), those circles are the same size. But, if you know your Mercator projection, you know it distorts Greenland because Greenland is far away from the Equator, so your circle over Greenland is actually much smaller in real life than your circle above the equator. At 40 degrees latitude, the distortion isn't as severe, but it still is there.
If you want to correct this, it's pretty easy. The size distortion caused by the Mercator projection is proportional to the secant of the latitude. That is, 50 mercator units on the equator equals 50 meters, but 50 mercator units at latitude x (in radians), corresponds to 50 / sec(x) meters. So if you want a radius of 50 meters, multiply 50 by sec(latitude), and use that number as the radius in mercator coordinates. In RGeo-speak:
p_lonlat = GEOFACTORY.point(40.610355377197266, -75.38220214843749)
p_proj = p_lonlat.projection
buf_proj = p_proj.buffer(50.0 * (1 / Math.cos(p_lonlat.y / 180.0 * Math::PI)))
buf_lonlat = GEOFACTORY.unproject(buf_proj)
Related
I want to understand all the steps involved in converting 2D coordinates to actual lat long on a zoomed mercator projection. The map is displayed in a 2D rectangle.
I know the center lat long and the latitude/longitude delta values of the rectangle. I also know the pixel length and height of the rectangle. If I know those values, what is the equation for converting x/y coordinates to latitude and longitude? Treat the Earth as a perfect sphere.
What is best strategy to recreate part of a street in iOS SceneKit using .osm XML data?
Please assume part of a street is offered in the OSM XML data and contains the necessary geopoints with latitude and longitude denoting the Nodes to describe the paths/footprints of 6 buildings (i.e. ground floor plans that line the side of a street).
Specifically, what's the best strategy to convert latitude and longitude Nodes in order to locate these building footprints/polygons on the ground floor in a scene within SceneKit iOS? (i.e. running through position 0,0,0)? Thank you.
Very roughly and briefly, based on my own experience with 3D map rendering:
Transform the XML data from lat/long to appropriate coordinates for a 2D map (that is, project it to a plane using a map projection, then apply a 2D affine transform to get it into screen pixel coordinates). Create a 2D map that's wider and taller than the actual screen, because of what's going to happen in step 2:
Using a 3D coordinate system with your map vertical (i.e., set all the Z coordinates to zero), rotate the map so that it reclines at an appropriate shallow angle, as if you're in an aeroplane looking down on it; the angle might be 30 degrees from horizontal. To rotate the map you'll need to create a 3D rotation matrix. The axis of rotation will be the X axis: that is, the horizontal line that is the bottom border of your 2D map. The rotation is exactly the same as what happens when you rotate your laptop screen away from you.
Supply the new 3D coordinates to your rendering system. I haven't used SceneKit but I had a quick look at the documentation and you can use any coordinate system you like, so you will be able to use one that is convenient for the process I have just described: something that uses units the size of a screen pixel at the viewing plane, with Y going upwards, X going right, and Z going away from the viewer.
One final caveat: if you want to add extrusions giving a rough approximation of the 3D building shapes (such data is available in OSM for some areas) note that my scheme requires the tops of buildings, and indeed anything above ground level, to have negative Z coordinates.
Pretty simple. First, convert Your CLLocationCoordinate2D to a MKMapPoint, which is exactly the same as a CGRect. Second, scale down the MKMapPoint by some arbitrary number so it fits in with how you want it on your scene graph, let's say by 200. Since scenekit's coordinate system is centered at (0,0), you'll need to make sure your location is correct. Then just create your scnvector3's with the x/y of he MKMapPoint, and you will be locked to coordinates.
I want to draw circles in an image canvas. I'm able to get pixel values from coordinate values by calling map.coordinateToPixel.
For radius, how can I map a coordinate distance to pixel length?
For instance, if my radius is 60 arc minutes, it goes from 50 degrees to 51 degrees. In a vector layer, the underlying framework manages the translation to pixels depending on the zoom level. However, for an ImageCanvas, I need to specify that myself. Is there a method to do that? I know I might have to dig into the code, but I was wondering if there's an inherent solution somebody already knows of.
An alternate option I've considered is:
Get the coordinate at pixel (0,0)
Get the coordinate at (radiusLogitude, 0)
Find the diff between the #2 - #1 on the Longitude and use that as my radius
Maybe this example can help you: http://acanimal.github.io/thebookofopenlayers3/chapter03_04_imagecanvas.html it draw a set of random pie charts (but without taking into account pixel ratio).
Note, the canvasFunction you use receives five parameters that can help you determine the pixel size: function(extent, resolution, pixelRatio, size, projection)
Here is my idea to track my sprayer coverage on the farm with an android app.
Use get??Location to provide GPS Coordinates
Use Coordinates to plug into polyline with Maps API v2
Set polyline width according to boom width. (conversion will require pixel to distance conversion at different zoom levels.
How would I display ground coverage with a polyline if the footage on the map will change with zoom level? Correct me if I'm wrong, but the polyline uses pixels for a defined width. My idea would require the user to input the width of the sprayer in feet and then the program would have to then calculate a polyline width based on the zoom/pixel ratio.
You should not draw a poly line, because your spray path forms a closed polygon.
So you must draw a polygon with line width = 0 (or minimum line width);
Fill the polygon.
For such precision farming usuallay better GPS devices are used with centimeter accuracy. (using RTK)
In my project my users can choose to be put in a random position inside a given, circular area.
I have the latitude and longitude of the center and the radius: how can I calculate the latitude and longitude of a random point inside the given area?
(I use PHP but examples in any language will fit anyway)
You need two randomly generated numbers.
Thinking about this using rectangular (Cartesian) (x,y) coordinates is somewhat unnatural for the problem space. Given a radius, it's somewhat difficult to think about how to directly compute an (Δx,Δy) delta that falls within the circle defined by the center and radius.
Better to use polar coordinates to analyze the problem - in which the dimensions are (r1, Θ). Compute one random distance, bounded by the radius. Compute a random angle, from 0 to 360 degrees. Then convert the (r,Θ) to Cartesian (Δx,Δy), where the Cartesian quantities are simply offsets from your circle center, using the simple trigonometry relations.
Δx = r * cos(Θ)
Δy = r * sin(Θ)
Then your new point is simply
xnew = x + Δx
ynew = y + Δy
This works for small r, in which case the geometry of the earth can be approximated by Euclidean (flat plane) geometry.
As r becomes larger, the curvature of the earth means that the Euclidean approximation does not match the reality of the situation. In that case you will need to use the formulas for geodesic distance, which take into account the 3d curvature of the earth. This begins to make sense, let's say, above distances of 100 km. Of course it depends on the degree of accuracy you need, but I'm assuming you have quite a bit of wiggle room.
In 3d-geometry, you once again need to compute 2 quantities - the angle and the distance. The distance is again bound by your r radius, except in this case the distance is measured on the surface of the earth, and is known as a "great circle distance". Randomly generate a number less than or equal to your r, for the first quantity.
The great-circle geometry relation
d = R Δσ
...states that d, a great-circle distance, is proportional to the radius of the sphere and the central angle subtended by two points on the surface of the sphere. "central angle" refers to an angle described by three points, with the center of the sphere at the vertex, and the other two points on the surface of the sphere.
In your problem, this d must be a random quantity bound by your original 'r'. Calculating a d then gives you the central angle, in other words Δσ , since the R for the earth is known (about 6371.01 km).
That gives you the absolute (random) distance along the great circle, away from your original lat/long. Now you need the direction, quantified by an angle, describing the N/S/E/W direction of travel from your original point. Again, use a 0-360 degree random number, where zero represents due east, if you like.
The change in latitude can be calculated by d sin(Θ) , the change in longitude by d cos(Θ). That gives the great-circle distance in the same dimensions as r (presumably km), but you want lat/long degrees, so you'll need to convert. To get from latitudinal distance to degrees is easy: it's about 111.32 km per degree regardless of latitude. The conversion from longitudinal distance to longitudinal degrees is more complicated, because the longitudinal lines are closer to each other nearer the poles. So you need to use some more complex formulae to compute the change in longitude corresponding to the selected d (great distance) and angle. Remember you may need to hop over the +/- 180° barrier. (The designers of the F22 Raptor warplane forgot this, and their airplanes nearly crashed when attempting to cross the 180th meridian.)
Because of the error that may accumulate in successive approximations, you will want to check that the new point fits your constraints. Use the formula
Δσ = arccos( cos(Δlat) - cos(lat1)*cos(lat2)*(1 - cos(Δlong) ) .
where Δlat is the change in latitude, etc.
This gives you Δσ , the central angle between the new and old lat/long points. Verify that the central angle you've calcuated here is the same as the central angle you randomly selected previously. In other words verify that the computed d (great-circle-distance) between the calculated points is the same as the great circle distance you randomly selected. If the computed d varies from your selected d, you can use numerical approximation to improve the accuracy, altering the latitude or longitude slightly until it meets your criterion.
This can simply be done by calculating a random bearing (between 0 and 2*pi) and a random distance between 0 and your desired maximum radius. Then compute the new (random) lat/lon using the random bearing/range from your given lat/lon center point. See the section 'Destination point given distance and bearing from start point' at this web site: http://www.movable-type.co.uk/scripts/latlong.html
Note: the formula given expects all angles as radians (including lat/lon). The resulting lat/lon with be in radians also so you will need to convert to degrees.