I want to convert a wkt geography into a jts geometry.
I tried using jts wkt reader like this.
import com.vividsolutions.jts.geom.Geometry;
import com.vividsolutions.jts.io.WKTReader;
Geometry geometry = wktReader.read(wktString);
Here the problem is wkt is of the format (longitude latitude) . The geometry which gets created out of this is not the expected one.
If the input would have been of the format (latitude longitude), it would have solved the problem.
One way that I could think of is that , take the interior rings and the shell. For each ring swap the lat and long and create a new ring. After swapping for the rings , I will create a new geometry.
Is there any other way to convert the wkt from x,y to y,x before creating the geometry ?
You can cast it and then get geometry object:
JtsGeometry shape = (JtsGeometry) wkt(ctx, "POLYGON((0 0, 10 0, 5 5, 0 0))");
Then
shape.getGeom()
It will return the Geometry object that you can use for further operations like intersection etc:
shape.getGeom().intersection(otherGeometryShape);
JTS is completely agnostic when it comes to coordinate systems. It will read your data as you present it. This means there is no latitude or longitude, just x and y as in your WKT input.
See How to Swap Coordinates of jts.geom.Geometry object from Lat, Long to Long,Lat in JTS for some ideas to solve your problem.
Related
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.
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 having trouble understanding ST_GeomFromText. It looks like there are 3 sets of 2 numbers. Why is that? Wouldn't coordinates just consist of a latitude and longitude?
Here is an example from http://postgis.net/docs/ST_GeomFromText.html:
SELECT ST_GeomFromText('LINESTRING(-71.160281 42.258729,-71.160837 42.259113,-71.161144 42.25932)');
ST_GeomFromText() takes a WKT expression of a geometry object and
Constructs a PostGIS ST_Geometry object from the OGC Well-Known text representation.
The WKT expression in the example is a LINESTRING which is
a one-dimensional object representing a sequence of points and the line segments connecting them.
You might think a linestring would be two-dimensional, but it's not, because a line has no width or height. (Points are 0-dimensional, polygons are 2-dimensional).
So, by definition, that would have more than one set of coordinates. A pair of coordinates would be a POINT, not a linestring, and would look something like this, in conjunction with the function in question:
ST_GeomFromText('POINT (30 10)');
You may want to read up on some GIS fundamentals:
http://www.cise.ufl.edu/~mschneid/Service/Tutorials/TutorialSDT.pdf - excellent tutorial
http://www.opengeospatial.org/standards/orm - OGC Reference Model
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.
I have two sets of "lines" drawn using a mapping API in the form of (lat,long) pairs. Given 2 of these lines, how can I compute the (lat, long) of their intersection (assuming they intersect)?
Depends on what coordinate system you're in.
You'll need the geodesic along the surface of the model you're using for each line segment (you can choose any convenient altitude you want since you only care about lat and long). Then the point that's on both geodesics (if it exists) is your answer. Note also that one geodesic may be coincident with the other (superimposed).
Since you're using the Mercator projection, you can translate the lat and long to X and Y on your map, then solve for their intersection easily.