I want to add a z field to my shapefile. Z value is the elevation of the center of the basin. I wonder how should I acomplish that. x and y values of the centroids are in the table. I have the dem of the region.
You'll have to convert those xy coordinates to a point feature class and then you can use the 'Point sampling tool' plugin to assign the value of your basin raster/polygon to each point (similar to the 'Extract Values to Points' tool in ArcGIS).
You can query the raster directly in Field Calculator. Create a new field and populate with:
raster_value('Raster', 1, make_point( x(centroid($geometry)), y(centroid($geometry))))
'Raster' is the raster layer, 1 is the band in the raster layer to use, and the make_point() function generates the centroid.
Related
The plot I am referring to can be found here. It is reproduced by calling the calc_feature_statistics function.
It is clear to me what the blue and orange curve (mean target and mean prediction) represent.
What is the red line(predictions for different feature values) ?
from the link:
To calculate it, the value of the feature is successively changed to fall into every bucket for every input object. The value for a bucket on the graph is calculated as the average for all objects when their feature values are changed to fall into this bucket.
As far as I understand these words the explanation is as next:
for example you've got categorical feature with three possible values: 'Moscow', 'London', 'New York'. Then:
Let's set all values of this feature in train data as 'Moscow' and
calculate average prediction among all of the data with the model we
trained earlier. This will be the dot of red line for bucket
'Moscow'
Repeat previous step with value 'London' --> this will be dot of red line for bucket 'London'
Same for New York.
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...).
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.
Given a dataset of samples in a multi dimensional space (in my case a 4D space) where the samples are present on all the corners of the 4D cube and a substantial amount of samples within this cube but not in a neatly grid. Each sample has an output value next to it's 4D coordinate. The cube has coordinates [0,0,0,0]..[1,1,1,1].
Given a new coordinate (4D) how can I come up with the best interpolated value given these samples? Eg how do I choose the samples to start with, how to interpolate.
As a first guess I would guess that this can be done with a two step process:
find the smallest convex pentachoron (4D equivalent of the 3D tetrahedron / the 2D triangle) around the coordinate we need to interpolate.
interpolate within this tetrahedron.
Especially step 1 seems quite complex and slow.
Here's the first approach I'd try.
Step 1
Find the point's 4 nearest neighbors by Euclidean distance. It's important that these 4 points are linearly independent because next they're used to create a Barycentric coordinate system. Those 4 points become the vertices of your pentachoron (aka 4-simplex).
If nearest-neighbor checks are too slow, try structuring your data into a spatial lookup tree that works in 4D.
Step 2
Now we need to associate a value with the interpolation point X. Start by deriving X's representation in this new Barycentric coordinate system. This Barycentric coordinate consists of 4 numbers, which collectively describe the relative distance between the interpolation point and each of the 4-simplex's vertices.
Normalize the Barycentric coordinate so its components sum to 1.
Each of those 4 simplex vertices are data points and have an output value. Combine those 4 output values into a vector.
Finally, interpolate by calculating the dot product of the normalized coordinate with the vector of output values.
Source: This idea is really just a 4D extension of this gem in middle of the Barycentric coordinate system page on Wikipedia.
My question is somewhat related to this similar one, which links to a pretty complex solution - but what I want to understand is the result of this:
Using a Mysql Geometry field to store a small polygon I duly ran
select AREA(myPolygon) where id =1
over it, and got an value like 2.345. So can anyone tell me, just what does that number represent seeing as the stored values were long/lat sets describing the polygon?
FYI, the areas I am working on are relatively small (car parks and the like) and the area does not have to be exact - I will not be concerned about the curvature of the earth.
2.345 of what? Thanks, this is bugging me.
The short answer is that the units for your area calculation are basically meaningless ([deg lat diff] * [deg lon diff]). Even though the curvature of the earth wouldn't come into play for the area calculation (since your areas are "small"), it does come into play for the calculation of distance between the lat/lon polygon coordinates.
Since a degree of longitude is different based on the distance from the equator (http://en.wikipedia.org/wiki/Longitude#Degree_length), there really is no direct conversion of your area into m^2 or km^2. It is dependent on the distance north/south of the equator.
If you always have rectangular polygons, you could just store the opposite corner coordinates and calculate area using something like this: PHP Library: Calculate a bounding box for a given lat/lng location
The most "correct" thing to do would be to store your polygons using X-Y (meters) coordinates (perhaps UTM using the WGS-84 ellipsoid), which can be calculated from lat/lon using various libraries like the following for Java: Java, convert lat/lon to UTM. You could then continue to use the MySQL AREA() function.