retrieve geographic coordinates of patches Netlogo - gis

I have a couple of rasters projected in Lambert Azimuthal Equal Area. I have integrated them into NetLogo as follows:
gis:set-world-envelope-ds (gis:envelope-union-of (gis:envelope-of raster1)
(gis:envelope-of raster2))
Is there any way to retrieve the actual geographic coordinates from a turtle position instead of the NetLogo coordinates? When I use pxcor and pxcor I get the pixel coordinates from the NetLogo system starting from (0, 0) at the low left corner.
Thank you for your help

Related

Netlogo doesen't recognize the GIS coordinates in the defined envelope of the world, it treats them as netologo world coordinates

I want to import some polygons from shapefile and create turtles with specific coordinates (a set of points that will be put in specific polygons). I successfully imported the polygons, set the envelope of the world... However, when I tried to add turtles and put them on a specific place (setxy), it added them at the same point (like those two points have the same coordinates, and they have not). And I chose coordinates of the points for which I know they belong spatially to the different imported polygons. I changed the pixel size (though that may be the problem), but nothing. I realized that NetLogo interpreters those coordinates as its' local coordinates, instead of GIS. But shouldn't Netlogo recognize the GIS coordinates in the defined envelope of the world?
Can someone help me with this and tell me what I am doing wrong.
My setup procedure:
to setup
set paldrino gis:load-dataset "paldrino.shp"
let world ( gis:envelope-of paldrino )
gis:set-world-envelope (world)
;; Make them visible
foreach gis:feature-list-of paldrino [ ;for each polygon
polygon ->
ask patches gis:intersecting polygon [
set pcolor pink
]]
create-turtles 1[
set color blue
set size 15
setxy 34.6255826 48.2408635 ;; here's the problem, netlogo treats this as the network coordinates of the world, not as GIS coordinates
]
create-turtles 1[
set color green
set size 15
setxy 34.8056851 48.1885275 ;; here's the problem, netlogo treats this as the network coordinates of the world, not as GIS coordinates
end
I have found the alternative solution. Certainly is not the best one, but for now is the only I have.
I created an additional procedure that rescale GIS coordinates to the NetLogo coordinates.
to-report nl-x [#x]
let world gis:envelope-of paldrino
let minx item 0 world
let maxx item 1 world
report ((#x - minx) / (maxx - minx)) * (max-pxcor - min-pxcor) + min-pxcor
end
to-report nl-y [#y]
let world gis:envelope-of paldrino
let miny item 2 world
let maxy item 3 world
report ((#y - miny) / (maxy - miny)) * (max-pycor - min-pycor) + min-pycor
end
And when I want to set a turtle's coordinates I call the procedure in the following way:
setxy nl-x(34.6255826) nl-y(48.2408635)
If someone has the better computational solution and can me explain why my code in the question is no working, please do. I will accept that answer instead of this.

How can I find the shortest distance from a point to a path over the surface of the earth

I have a list of lat/long points which form a path on the surface of the earth.
I have another point on the surface of the earth and I want to find the shortest distance from that point to a point that falls on the path.
While I could approximate the surface of the earth as a plane, accuracy is important.
The distance between points on the path could be anywhere from 1-1000m. The distance to the point not on the path is from 1-50m. The maximum acceptable error is 0.1m.
Any method of calculating this is acceptable, whether assuming a plane, sphere, or the real shape of the earth as long as the error would not exceed 0.1m for any point on land.
This question is marked language agnostic to encourage answers from people not familiar with the language used. The implementation will be in Dart.
It sounds like you need to calculate the Great Circle Distance across the surface of the earth. A Great Circle calculation permits the calculation of distance along the earth's surface between two arbitrary latitudes and longitudes.
A trivial example of a Great Circle calculation would be to migrate along the Earth's surface along the line of equator (zero degrees latitude). Each degree of longitude of migration along that line (for instance from [0 deg N, 90 deg W] to [0 deg N to 91 deg W]) equates to 1/360th of 40,070km, or 111.306km. Moving between two latitudes and two longitudes requires transformation of coordinates and is outside the scope of this quick note.
Summary and equations found here:
https://en.wikipedia.org/wiki/Great-circle_distance
The accuracy you are seeking of 0.1m requires further refinement; using a sphere to approximate the shape of the Earth will limit the accuracy to perhaps 0.5% (see paragraph from Wikipedia, below). Put another way, a 0.5% error of two points 1000 km apart would be 5000 m.
A more formal and precise calculation will use the true shape of the earth, known as a geoid. This is determined by gravitational measurements and is updated from time to time by the geodesic community.
It is possible to determine one's absolute position on Earth to +/- 0.1m (or better) with advanced GPS surveying techniques, such as RTK or satellite correction services (e.g. Omnistar), but determining the path distance to that accuracy is not the same thing. A survey-quality receiver has corrections built into it for current geoids so that it can translate the lat/long/height calculation it makes using GPS signals to the current reference geoid used by the surveying / geodesic community.
You may not actually require 0.1m accuracy for your application; very few applications require 0.1m absolute accuracy over any distance except (for example) geographic determinations of movement in the Earth's surface. Relative accuracy is more important; e.g. measuring the same point at different times. It is more important to know how much a seismic fault moved relative to its position yesterday or last week, or whether a critical point on a pipeline has moved 2 cm to the north in the past year.
I hope this helps.
Cheers
GP
Per Wikipedia:
So long as a spherical Earth is assumed, any single formula for distance on the Earth is only guaranteed correct within 0.5% (though better accuracy is possible if the formula is only intended to apply to a limited area). [7]

Converting degrees to other units of measurement

I am storing a point as latitude and longitude in a Mysql server. They are both float(10,6). Given a radius, say 100 yards or 100 meters, how can I calculate points around the center. I was thinking of using GIS but I heard it is incomplete or very limited in functionality.
1) Tranform the lat/lon to a cartesian based coordinate system of units meter,
the tranformed point is now at (x,y)
2) Use school mathemathics (polar coordinates) to calculate the points:
2a) create points on circle at (0,0) with polar coordinates (r* sin (phi), r* cos(phi)), r in meters, phi in radians
2b) add (x,y) to all that resulting points, to move the circle points from center (0,0) to (x,y)
3) tranform all points back to lat/lon

2D Open Street Map Data Representation in Meters

I am in the process of converting OSM data into an open source Minecraft port (written in javascript - voxel.js). The javascript rendition is written such that each voxel (arbitrarily defined as a cubic meter) is created as a relation from a single point of origin (x,y,z)(0,0,0).
As an example, if one wanted to create a cubic chunk of voxels, one would simply generate voxels as a relation to the origin (0,0,0) : [(0,0,0),(1,0,0), (0,1,0)...].
My question is this: I've exported OSM data, and the standard XML output (.osm) plots nodes in latitude and longitude. My initial thought is that I can create a map by calculating the distance of each node from an arbitrary point of origin (0,0,0) = (37.77559, -122.41392) using the Haversine formula, convert the distance to meters, find the bearing, and plot it as a relation to (0,0,0).
I've noticed, however, that there are a number of other export formats available: (.osm.pbf, .osm2pgsql, .imposm). I'm assuming they plot nodes in a similar fashion (lat, lng), but some of them have the ability to import directly into a database (e.g. PostgreSQL).
I've heard of people using PG add-ons like PostGIS, but (as this is my first dive into GIS) I'm unfamiliar with their capabilities and whether something like PostGIS would help me in plotting OSM data into a 2D voxel grid.
Are there functions within add-ons like PostGIS that would enable me to dynamically calculate the distance between two Lat/Lng points, and plot them in an x,y fashion?
I guess, fundamentally, my question is: if I create a script that plots OSM data into an x,y grid would I be reinventing the wheel, or is there a more efficient way to do this?
You need to transform from the spherical coordinates (LatLon, using WGS84) to cartesian coordinates, like googles spherical mercator.
In pseudo code
transform(double lat, double lon) {
double wgs84radius = 6378137;
double shift = PI * wgs84radius;
double x = lon * shift / 180;
double y = log(tan((90+lat)*PI/360)/ (PI/180);
return {x,y}
}
This is the simplest way. Keep in mind that Lat/Lon are angles, while x and y are distances from (0/0)
The OSM data is by default in the WGS84 (EPSG:4326) projection which is based on an ellipsoidal Earth and measures latitude and longitude in degrees.
Most map tiles are generated in the EPSG:900913 "Google" spherical mercator projection. This projection is based on a spherical Earth and latitude and longitude are measured in metres from the origin.
It really seems like the 900913 projection will fit quite nicely with your requirements.
Here is some code for converting between the two.
You might like to consider using osm2psql. During the import process all of the OSM map data is converted to the 900913 projection. What you are left with is a database of all the nodes, lines and polygons of the OSM map data in an easy to access Postgres database.
I was initially intimidated by this process but it is really quite straightforward and will give you lots of flexibility when it comes to using the OSM data.

Why is this lat lng coordinate is split into 2 halfs?

I have this file from tsp.gatech but the lat lng coordinate is divide into two half. Why is this?
COMMENT: Created July 7, 2012, www.tsp.gatech.edu/data/usa/
1 33613.158800 86118.306100
2 33100.954000 85529.675300
3 31571.835200 85250.489300
For example the first coordinate should be 33.613158800 86.118306100.
Update: I searched for New York City and I found it lat lng coordinate to be similar.
Update 2: I think it's incorrect formated see this image of points: http://www.tsp.gatech.edu/data/usa/img/usa115475_large.jpg. I get the points from a file from this website: http://www.tsp.gatech.edu/data/usa/index.html. The site is about a challenge and the file I downloaded is usa115475.tsp.
Euclidean Distance would tend to suggest the values are X,Y distances from a reference point (in feet, meters, kilometers, miles, ...). But this is normally reserved for small scale mapping where the effects of the curvature of the earth can be considered minor.
If the data seems to correspond to decimal degrees that are incorrectly formatted, there could be an error in whatever system is returning the data. But its better to review your own processes before pointing the finger. What query/process/code are you doing to obtain this data?