Question on spatial join and buffer in geopandas - gis

I have two GeoDataFrames that I am attempting to join. Both have POINT geometry. I am using geopandas.buffer to create Points and polygon and then spatial join.
gpd1 with POLYGON geometry, gpd1['geometry'] = gpd1.geometry.buffer(2)
gpd2 with POINT geometry.
Spatial Join:
gpd1.sjoin(gpd2, how='left')
Question:
What happens where there are multiple points in gpd2 that are within the buffer / POLYGON geometry of gpd1?

Related

Map multiple geospatial polygons to their nearest lat/long point in a different table using GeoPandas or other Python tool

I've got a list of voting precinct geospatial polygons that need to join to a different table with just lat/long points for each zip code. How can I join each of the precinct polygons to its nearest zip code lat/long point?
This article has helped me to build this script which quickly maps each of my points to the coordinate polygon it fits inside of:
import pandas as pd
import geopandas as gpd
df_zip = pd.read_csv('zipdata.csv')
gdf_pts = gpd.GeoDataFrame(df_zip, geometry=gpd.points_from_xy(df_zip.Longitude, df_zip.Latitude))
precinct_file = 'precinctdata.geojson'
gdf_coord = gpd.read_file(precinct_file)
sjoined_listings = gpd.sjoin(gdf_pts, gdf_coord, op=”within”)
# where zipdata.csv includes a latitude and longitude column along w/ other zip code data
# and precinctdata.geojson is a geojson file that includes polygons for over 100k voting precincts
Now instead of mapping each zip point to the precinct polygon it belongs to, I want to map each polygon to its nearest point so that ALL precinct polygons will have a corresponding zip code point that is the nearest point to it. Many points will map up to multiple polygons as there's over 140k precincts and less than 42k zip codes in the dataset.
I've found some similar questions here and here but weren't able to fit it into my script -- I'm new to GIS but fixed on getting going with it.

Geocoding - get all records within a boundry

Lets say I have a database of locations (countries, regions, cities, towns) with their lat/long co-ordinates.
E.g. I have the co-ordinates for England 52.16045, -0.70312
Is there a way for me to return all locations within the bounds of England if all I have are lat/long?
Do I need to polygonise the location...if so how would I do that if all I have are lat/longs.
For the record the database is Mysql.
Some guidance would be appreciated.
If you have a polygon with the boundary of the state you could use a ST_CONTAINS feature of mysql geometry for find al the points inside the polygon
Assuming you have a table (points) the contain the points and polygons with polygon, and each polygon is based on a polygon.name
you could use
SELECT points.col1
FROM polygons
INNER points ON ST_CONTAINS(polygons.geom, Point(points.longitude, points.latitude))
AND polygons.name = 'Your_name';
the ST_CONTAING just check if a geometry is contained inside one other

What's the difference between LineString and Multipoint in GeoJSON

What's the difference between LineString and MultiPoint in GeoJSON?
To me the examples given are identical. http://geojson.org/geojson-spec.html#id3.
I'm planning some things in GeoJSON and if something as basic as this is confusing I'm in trouble.
A LineString is a Polyline or from Wikipedia "a curve specified by the sequence of points". So if you like to do a track or route based on latitude and longitude for a map application - use LineString.
MultiPoint is simply a collection of points without lines between them. Say a group of people. So the use cases are very different.
Specification of LineString requires at least two positions.
Other than that there is only a difference in intent. LineString defines a line through the points in given order. MultiPoint defines a finite collection of points.

How to convert wkt to jts geometry for a geography?

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.

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.