I am trying to visualize slope for an elevation raster using QGIS terain analysis tool. The results are no what I would expect.
Elevation raster is from NASA's SRTM program. I picked a relatively mountainous region to run a test N39W121.
elevation model looks like this
but resulting slope raster only has two values 0 and 89.9 .
I used default setting's in QGIS' DEM tool, set to slope mode. Can anyone help me firgure out what I'm doing wrong. Is it a problem with the original data, or is it settings? I am at a loss. Calculating hillshade and ruggedness index with the same tool produced results as expected
By default, SRTM's map horizaontal units are in degrees (WGS84), where the vertical units for SRTM is in meters. This either needs to be compensated for in QGIS's DEM analysis settings or the SRTM raster needs to be converted to a projection that uses meters for its map units.
Related
Healpix is a very useful software to do spherical analysis on a sphere. For example, we can use map2alm to analyze a Healpix RING ordered map and return spherical harmonics. Here the argument of map should be an array with $Npix = 12*Nside^2$. If I only want to do analysis on a patch, but not on a full-sky. Some ring-weights can be used to mask the map in Healpix. But if Npix is very big, actually the array of map will too big to be allocated in memory. Thus, how can I do the spherical harmonics transform on a sky-patch?
Unfortunately in healpy and HEALPix, spherical transforms are always executed full-sky.
If you are working on a small patch of sky you could use rectangular pixelization instead, see the pixell package at https://github.com/simonsobs/pixell, then you can use FFT transforms instead of spherical harmonics.
You can also checkout the CMB Analysis Summer School notebooks: https://github.com/jeffmcm1977/CMBAnalysis_SummerSchool/blob/master/CMB_School_Part_04.ipynb
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]
I have fields where location data is in X- and Y columns in WGS84 meter-format. How can I convert these fields or create new fields with decimal degrees? Vector->Geometry Tools-> Export/Add geometry columns creates duplicate fields with the same meter-format. Similarly using field calculator with $x- and $y functions creates also fields with meter-formats.
I may be misinterpreting the question, but WGS84 is a geographic coordinate system, utilizing the WGS84 ellipsoid, its coordinate space is measured as lat long pairs and not meters. See unit of measurement here or here. As such WGS 84 is not represented as meters, see discussion here, here or here (comments). In short, WGS84 uses angular measurements to represent the locations within a three dimensional space, as a metered grid doesn't envelope the earth very well. WGS84 is always projected when displayed in GIS software (without changing the underlying data), it is projected to convert it from a 3 dimensional representation of the earth to a 2 dimensional.
Your data, if measured in meters, is projected. The WGS84 ellipsoid may be used as part of the basis of a projection, such as with UTM or WGS84 Antarctic Polar Stereographic. The projection you have and its parameters are critical to understanding how you determine the position of a point in degrees, as a point will essentially have to be unprojected to get its latitude and longitude.
Luckily this is relatively easy in GIS software.
In QGis you can change the coordinate reference system of your layer to WGS 84 (EPSG:4326) - which it could be already with the data coming from a different source or previous CRS - and then use the field calculator to calculate the geometry that you are looking for (assuming that your fields in meters represent something that can be calculated by the field calculator). This also requires your existing data to have a defined projection. If needed you can convert back after you have added the new data.
In Arc, the process is largely the same, using the "project" tool to reproject/unproject the data.
If your data layer does not have a defined projection, you will need to find it. If your data layer fields that are already in meters are not something easily calculated from the field calculator in qGIS, then it might get a little more involved (creating a layer from those fields, changing the CRS of that layer, calculating the fields in degrees...).
Bit of a challenge here which I've been grappling with for some time. I'll explain my full work flow so you can reproduce if needed.
I'm creating virtual landscapes in Google SketchUp which I ultimately would like to use in Netlogo to examine how turtles interact with them.
My problem is that by the time I get the landscapes into Netlogo the units don't seem to relate to the original 3D model.
Step 1: Create simple hill on a 50m by 50m square in Sketchup using the Toposhaper extension.
Step 2: Export to .dae file and import into Meshlab, ensure the Meshlab model has the same dimensions as the Sketchup model by adjusting the units with the assistance of the measuring tool. Export from meshlab as .xyz file.
Step 3: Import .xyz file into QGis as points by adding a new layer from delimited file. Selecting field_1 and field_2 as X and Y fields.
Step 4: Create raster of points using Raster > Interpolation > Interpolation. Add field_3 as interpolation attribute, set number of columns to 50 by 50 (to correspond to the 50m x 50m 3D model), adjust cell size X and Y to match to ensure Netlogo will read the resulting .asc file.
Step 5: Finally, I setup a model in Netlogo to receive the raster. Firstly, in model settings I set the the min and max pxor and pycor to 0 and 50. Then, using the Gis Extension, I import the raster apply the z-value to a patch variable called elevation:
to load-gis
set elevation gis:load-dataset "cone_50.asc"
gis:set-world-envelope-ds gis:envelope-of elevation
gis:apply-raster elevation target-elev
end
Now, each patch of my 50 by 50 Netlogo world should have an elevation value taken from my 50 by 50 raster. In theory, adding all the elevation values together should (roughly) give me the total volume of the raised area of the hill? The figure I get is higher however and the problem gets worse with larger volumes.
Can anyone help?
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.