TurfJS just fails to calculate intersections with highly-detailed geometries - internally, it will truncate the precision of the geometries' coordinates to about 6 decimal digits.
A bit of digging uncovers that there's some discussion about the issue at https://github.com/Turfjs/turf/issues/1118 . There are deeper concerns here because the underlying code ...
A variety of methods are used in this link below, you can choose different methods according to your actual situation.
It looks like you are working with data in a geodatabase. Multiprocessing doesn't work on feature classes in a geodatabase because each update acquires a lock.
According to https://www.esri.com/arcgis-blog/products/arcgis-desktop/analytics/multiprocessing-with-arcgis-approaches-and-considerations-part-1/:
...will not work with feature classes in a file ...
You're almost there! You can calculate the area of your new intersecting shapes, and then merge this back into your nc object:
# Calculate area and tidy up
intersect_pct <- st_intersection(nc, tr_buff) %>%
mutate(intersect_area = st_area(.)) %>% # create new column with shape area
dplyr::select(NAME, intersect_area) %>% # only select ...
First, a tip to increase the chance someone will help you out with your questions. Before submitting, try to debug it as far as possible yourself. Narrow down where things go wrong. Remove all code not needed to reproduce your problem, but make sure the code still is executable for someone else, if at all possible.
There are a couple of problems with the ...
If you want the result to be a raster as the intersection of buffer and the underlying raster, you can convert your buffers into raster with the same size of pixel of the underlying raster. Then you can compare values with cell statistics or raster calculator.
Convert your polygons to raster and reclassify the all values to 100 (Buffer raster)
It looks ...
I solved the problem, though I'm still unsure what caused it.
I was testing to see if there were any projection issues, and found that there were with the following code:
print(lochit.crs().isValid()) # True
print(lochit.crs().authid()) # -blank-
For every date beyond the first in the loop, the crs is found to be valid, but authid() has no output. ...
In my opinion you do not need any SRID because you are not working with ST_Length_Spheroid().
What @she_weeds is pointing on is indeed correct.
SELECT ws."Network", count(ws."Network"), sum(st_length(ws.geometry))
FROM "Water_Service_Area_Boundaries_Non_Cadastral" AS ws, "W_Mains_DSC_ExclAbandoned" AS wmain
WHERE ST_Intersects(ws.geometry, wmain.geometry)
An easy way to reproject a layer is to right-click it in the Layers panel and Export-> Save features as....
In the following dialogue you choose the CRS you would like to reproject to and the format and name of the output. The reprojected layer will be added to the Layers panel by default.
An equally easy alternative for reprojection is the Reproject layer ...
You could split your points into a list where each element is a group (A, B). Then you can use lapply to iterate over each group.
point_list <- split(pts, pts$id) # split points into list by id
res <- lapply(point_list, function(x)
length(unlist(st_intersects(x, sa_pa_data))) / nrow(x)
Thank you very much for the answer and the help.
I managed to solve it the following way (it requires several steps):
We had a large amount of collared animals so I had to divide the whole dataset per year.
I firstly did an intersection of the road layer with the movement line layer to get an approximation of which animals crossed the roads each year and ...
You can use array_agg to collect the line IDs at the intersection point.
The number of lines can be more then two, so they can be collected in an array ba array_agg function:
CREATE TABLE junctions as
ROW_NUMBER() OVER () AS junction_id,
array_agg(b.road_id) AS road_ids,
ST_Intersection(a.geom, b.geom) AS geom
FROM roads a
INNER JOIN ...
Yet another approach using the Field Calculator... this will work only if your GPS attribute table is sorted according to the recorded date/time.
A dummy GPS point data crossing Road (I've got road 'fid' = only '1').
Now please ope the GPS layer's attribute table and start the Field Calculator.
Give this expression:
Reuben, good day to you. I have solved problems like yours with the QGIS tool PointstoPaths (note the plural Paths). This is an extraordinarily useful tool. Sadly, it is only available at QGIS v. 2.X. If you don't have v. 2.X installed, download the latest version at:
For my Windows 10 machine, I use the install file QGIS-...
You have a good description of the problem. It is a nice logic question which can be dealt with by gis.
I would create a line feature between all the points. The attributes of each line would contain the average of time and somehow average of the gps readings.
Then intersect the road with your new line features. Potentially the intersection will give you ...