I am going to generate isochrones using the Iso-Area algorithm of the QNEAT3 plugin. I have a CSV file including start point coordinates. I read this file as a layer in QGIS. Then I saved the features of this layer (Let's consider it A) as it is shown in the next picture:
A
I also downloaded the road network from http://download.geofabrik.de/ and added it as a layer to QGIS. Then I saved this layer (Let's consider it B) as it is shown in the following figure:
B
Finally, in the Iso-Area as polygon (from layer) parameters tab, I selected B as the input of vector layer representing network and A as the input of stat points. after running the algorithm I got this error:
File "C:/../AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\QNEAT3\algs\IsoAreaAsPolygonsFromLayer.py", line 229, in processAlgorithm
net = Qneat3Network(network, input_coordinates, strategy, directionFieldName, forwardValue, backwardValue, bothValue, defaultDirection, analysisCrs, speedFieldName, defaultSpeed, tolerance, feedback)
File "C:/.../AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\QNEAT3\Qneat3Framework.py", line 130, in init
self.list_tiedPoints = self.director.makeGraph(self.builder, self.list_input_points, self.feedback)
Exception: unknown
there is not any clear message regarding the error that happened. what could be a probable cause of this problem?
The network layer must be in a projected CRS with the LineString geometry type. The start points layer must be in a projected CRS with point geometry type. I downloaded another road network data set and applied the mentioned conversions, then the problem solved
Related
I am trying to map a geojson file (A map of Alaska precincts, downloaded from the division of elections and then converted online to geojson) onto a choropleth map using folium, the problem is the coordinates are in 7-digit numbers like this:
[ -16624764.227, 8465801.1497 ]
I read on a similar post that this was most likely a US coordinate system like UTM or State Plane, and recommended using an API to reproject it. Is it also possible to access the coordinates directly such as with geopandas and divide them by 100000?
The data is most likely in a specific cartographic projection. You don't just want to divide by 100k - the data will likely have nonlinear transformations which have a different effect on the position depending on the location. See the GeoPandas docs on working with projections.
If the CRS of the data is correctly encoded, you can re-project the dataframe into lat/lons (e.g. WGS84, which has the EPSG Code 4326) using geopandas.GeoDataFrame.to_crs, e.g.:
df_latlon = df.to_crs("epsg:4326")
I want to export a series of Landsat scenes in Africa (that natively have different UTM projections) and work on them in GIS software. To have the pixel boundaries at overlapping regions properly, I think I have to reproject my scenes to a common projection, for which I would like to use Africa_Albers_Equal_Area_Conic projection. I find this projection with authority ESRI:102022 on spatialreference.org, with below wkt definition:
PROJCS["Africa_Albers_Equal_Area_Conic",
GEOGCS["GCS_WGS_1984",
DATUM["WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Albers_Conic_Equal_Area"],
PARAMETER["False_Easting",0],
PARAMETER["False_Northing",0],
PARAMETER["longitude_of_center",25],
PARAMETER["Standard_Parallel_1",20],
PARAMETER["Standard_Parallel_2",-23],
PARAMETER["latitude_of_center",0],
UNIT["Meter",1],
AUTHORITY["EPSG","102022"]]
I put this as the argument of ee.Projection() function and do the export this way (imageA is the input image):
var EPSG102022 = ee.Projection('PROJCS["Africa_Albers_Equal_Area_Conic",...)
var imageA_2 = imageA.reproject({crs:EPSG102022, scale:30})
var projectionA_2 = imageA_2.projection().getInfo()
Export.image.toDrive({
image: imageA_2,
description: 'TEST_A_reprojectWscale',
crs: projectionA_2.wkt,
scale: 30,
region: ROI
});
But when I do the export and load the original and reprojected image on ArcGIS, I see the reprojected image being misplaced. When I look at the reprojected image spatial reference in ArcGIS, I see that there is no "longitude_of_center" parameter there, brt there is a parameter named "central meridian" which is set to zero. Also the authority is not shown and it only says the projection authority is "custom".
Then I renamed "longitude_of_center" in the wkt string to "central_meridian" and exported the image again. The image was still misplaced. When I looked at its spatial reference, I found that the central meridian parameter is still zero, although I set it to be 25 in the wkt definition.
Then I set the "central_meridian" parameter in wkt definition to zero and exported the images again. This time the image was correctly placed on the map.
I am completely confused. Why there are different names for the projection parameters in different wkt's and why different softwares name the projection definition parameters differently? This looks like a very poor standard. Also, why ArcGIS does not follow the definition that I put in the exported file (setting central meridian to 25)?
I have a relatively simple task to accomplish in R: I have two polygon layers, a "patches" layer containing 39 focal polygons and a "landcover" layer containing one multipolygon of the focal landcover type. I need to clip those two layers so that I keep only the extent of the focal landcover type within the focal polygons. Sometimes, this works fine with sf::st_intersection, sometimes this works fine using sf::st_differenceand a "negative" landcover layer (containing the extent of all non-focal landcover types) and sometimes none of both approaches work. At first, I thought that these different behaviors depend on the resulting topography complexitiy, but this does not seem to be the case.
The errors I get are of the form
Error in CPL_geos_op2(op, st_geometry(x), st_geometry(y)) :
Evaluation error: TopologyException: Input geom 1 is invalid: Ring Self-intersection at or near point
4372482.6526834015 5297568.4303682083 at 4372482.6526834015 5297568.4303682083.
so I checked for the land cover polygon and each of the focal polygons using sf:: st_is_simple ('patch') which in all cases yielded TRUE.
Consider these three cases:
The "simple" case, where sf::st_intersection works. An example (the
patch in blue, the land cover in green):
sf::st_intersection (focal_patch, focal_landcover):
The "intermediate" case, where sf::st_intersection does not work
but sf::st_difference can be used as a workaround when the focal
landcover is replaced by the non-focal land-cover. An example (the
patch in blue, the non-focal land cover in red:
sf::st_difference (patch, non-focal_landcover)
The "difficult" case where neither keeping the focal land cover (green) type using sf::st_intersection nor excluding the non-focal land cover type (red) using sf::st_difference work - I get similar errors for both approaches:
I was unable to make a reproducible example, so I hope that it is possible to figure out what happens here from the example images. I could not see any pattern in there so perhaps only someone with deep insights into st_intersection and st_difference can indiciate a solution to this...
The error you are describing is not random; ring self intersection means invalid geometry. You should be able to test for it via sf::st_is_valid().
This error is known to happen when using spatial objects originated in the realm of ESRI products, which use slightly different criteria for validity than OGC realm.
To overcome the issue you have several options:
filter the offending geometry out (via subsetting of your spatial object based on the result of sf::st_is_valid() = leaving only valid geometries in place)
try to correct the geometries via sf::st_make_valid() - note that this may result in altered geometry, and may require installation of {lwgeom} package
apply "magic dust" of a buffer of zero width on your invalid spatial object via sf::st_buffer(your_ object, 0). This hack will force creation of a new geometry, possibly overcoming the errors in the original one.
For more information consider the sf package documentation: https://r-spatial.github.io/sf/reference/valid.html
I'm trying to project some point data in ArcMap.
I created the point data in excel, then summarised it in R and exported it as a csv. Then added it through 'add XY data' tool in ArcMap, and exported it from an events file to a shapefile.
The points appear in the correct place, relative to each other, but when tried to overlay on the world imagery basemap, it simply sits down near Antarctica.
I've checked and re-checked the projections of the imported layer and the dataframe (I'd like to work in GDA_1994_MGA_Zone_56), but have also tried changing to a geographic coordinate system, which doesn't change anything.
In fact, when I try to change the projection to a gcs, using the 'project - data management' tool, this error comes up.
invalid extent for output coordinate system
Failed to execute (Project).
I can't for the life of me figure out what is going wrong, there's probably a simple explanation, but I'm at my wits end!
It helps to have them stored originally as numeric data, but since it's actually coming in as a CSV, I think they are importing as numeric -- as you note, they are correct relative to each other.
If your points are showing up on a map but in the wrong location, then their initial projection definition is incorrect. Looking at the Add XY Data dialog, you need to specify an initial coordinate system. If nothing is specified, ArcMap assumes that it is latitude/longitude decimal degrees.
Once it's imported as the wrong coordinate system, attempts to reproject will just continue the But you do not necessarily need to delete the points and start to re-import from scratch. Try using the Define Projection tool (which modifies the metadata to the desired projection) instead of Project (which mathematically recalculates coordinates from current projection to a new projection).
I have two .shp files whose .prj files are identical and whose extents are different. I'd like to set them to the same extent so they line up on the map.
In ArcGis I have tried:
Exporting both to a new coordinate system-defined feature dataset
Removing the .prj file and then re defining the projection of each file
"project"ing both to the same Coordinate system.
Setting the data frame Coordinate System, then reintroducing the shapefiles in hopes that they'll project "on the fly"
In QGIS I have tried:
Setting project CRS
Setting layer to project and project to layer
Saving the shapefiles in specific CRS.
It seems odd to me that this is an issue in the first place: why can't Arc or Q detect this asynchronicity and give the user the option to choose one over the other?
What am I missing here?
Should I look into creating a spatial reference for one of the files, that matches the other?
Any clues/ suggestions/ clarifications?
I know this is a popular issue, and I figure there must be some simple explanation for the above, but I'm not finding it anywhere despite spending hours puzzling over the situation. Perhaps I just don't have the right vocabulary to ask the question. Any help appreciated.
some information about the files:
Extents for shp1:
top: 672344.187336 ft
bottom: 629117.938976 ft
right:7660465.885171 ft
left: 7627858.786745 ft
Extents for shp2:
top: 5984.800593 ft
bottom: 4784.800593 ft
right: 4616.411043 ft
left: 3776.411043 ft
Layer Properties-Source for both shp1 and shp2:
Projected Coordinate System: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
Projection: Lambert_Conformal_Conic
False_Easting: 8202099.73753281
False_Northing: 0.00000000
Central_Meridian: -120.50000000
Standard_Parallel_1: 44.33333333
Standard_Parallel_2: 46.00000000
Latitude_Of_Origin: 43.66666667
Linear Unit: Foot
Geographic Coordinate System: GCS_North_American_1983_HARN
Datum: D_North_American_1983_HARN
Prime Meridian: Greenwich
Angular Unit: Degree
.prj data for both shp1 and shp2:
PROJCS["NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",8202099.737532808],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-120.5],PARAMETER["Standard_Parallel_1",44.33333333333334],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",43.66666666666666],UNIT["Foot",0.3048]]
For those who might have the same problem, in the course of answering this question (r/gis/reddit proved the most useful) I learned:
There are local coordinate systems which might not show up on Arc or Q. In this case, the data was derived from a CAD file, a DWG that I converted for a project.
One can change the data frame projected coordinate system within Arc trying to find a fit. In this case there was none, no matter how long or hard I tried
Some Coordinate systems are simply so local they aren't useful, or as a redditor put it, "garbage", so don't waste your time trying to make them fit.
4.The Spatial Adjust tool can be used to effectively georeference a dataset with an unknown coordinate system to one which is known. So in my case, I took the .shp and then used the spatial adjust toolset to "rubbersheet" it to some clearly defined data. Easy. Took a few minutes. Made it fit, defined projection, called it good.