I have used the GRASS v.to.rast and r.surf.contour functions in the processing toolbox of QGIS 3.10.13 to generate DTM raster layers from some vector contour layers. However, the DTM layers are flagged as "Temporary layer only!", and QGIS warns that they "will be discarded after closing QGIS". How do I save them as permanent layers in the current project? I'm new to QGIS so it's possible I've missed something obvious, but I've looked everywhere in the software, along with Google and stackoverflow, with no luck so far. Thanks!
I'm an infrequent QGIS user (usually heavy user of ArcGIS Pro). Needed Lidar DEM merged. (Raster|Misc|Merge). had to export as geotiff with a new name. didn't realize this created a new layer until struggling for a bit with how to make the merged layer permanent. wound up deleting the "Merged" layer and the two original tiles. New layer seems to be working fine as I just changed the symbology to hillshade successfully. A bit of a workaround but now am able to save without a reminder to save the temporary layer.
Related
At the outset, let me just add that I am using Anylogic for the first time, please be understanding.
I have strange problem with conversion GIS .shp file to road network.
I follow the directions in the documentation (I'm trying to do exactly the same as in the documentation example):
https://anylogic.help/markup/converting-roads.html
My GIS map before conversion:
My GIS map after conversion:
As you can see, Anylogic generated a lot of road networks for me. It should all be in one road network. For this reason, there are no intersections and this is the biggest problem. It does not generate intersections at all, but joints these roads somehow artificially ...
Can anyone tell me what I am doing wrong? Why no intersections are generated and everything is thrown into separate road networks?
In the example from the documentation, the intersections have been generated.
I am using Anylogic Professional 30 days trial. Previously I was using the Personal Learning Edition version and there was exactly the same problem.
You are not doing anything wrong. It is caused by the shape file structure. AnyLogic can only interpret what it gets and if the data is not formatted correctly, i.e. road paths are not actually connected in the .shp file, it will create separate networks.
So either adjust the shape file or manually combine the networks, there is no other way, afaik.
I have two layers, first one is the ROAD layer and second one is the PARCEL layer as shown in Figure 1. I can get the data both in dxf and shp formats.
My task is to compute the area of intersection between ROAD and PARCEL layer, this is the easy part. I can compute intersection using QGIS or Geopandas easily. However, the difficult part is creating maps for each of the parcel. Sometimes, I have to create more then a hundred maps for each project. For mapping, there is a template that I have to use, which is similiar to Figure 2. Also, some attribute data should be included in the map, such as owner of the parcel.
These maps should be in both pdf and dxf format. Each map should be in A3 size. To be able to produce such maps, what libraries or programming languages should I use? I have experience in geopandas library but I am not sure if it is enough for this task.
Shoud I try QGIS plugin development or ArcPY? Could you please share your experiences and ideas about this problem?
I am looking forward to hearing from you,
Any help and suggestion is appreciated.
Thanks in advance
I've been playing with Mapbox's blog post about converting heat maps to contour lines, and I'm stuck at the extraction part of this process.
I used the CSV plugin to create a vector layer of points, then a heat map raster layer based on that, but I can't seem to be able to see the contour lines based on that raster layer after that. When I looked at the properties and selected categorized, it didn't seem to have any symbols listed.
I'm guessing this is probably some kind of type error since I had to create the raster layer based off of map units and not meters, but I don't know how to correct it. What am I missing?
Okey dokey. After the holiday weekend I figured it out.
It was basically a type error with the CRS. Although it's not explicitly stated, I got in touch with MapBox and found out they were working in Google Mercator. It's also a perfectly acceptable CRS to use when you eventually have to import the .shp file into MapBox/Tile Mill.
I am working on creating a tool to select a place via Google Maps API. This part is simple and I have no problems with it, but it is too specific. I want to do something similar to this, but need to accommodate the entire world, not just zip codes.
I would think the same effect should be able to be achieved by the highlighting an administrative level. Does this require KML file, and if so can anyone through a provider that might have this level of detail?
You can get administrative boundaries for the world here http://www.gadm.org/ or here http://www.unsalb.org/. You will not be able to achieve this with a single KML file though, as this would be one big file (I am talking about at least four hundred MB and there is a 4MB limit for KML files on Maps).
You will need to store the data in the db and pull out only relevant boundaries and draw them as polygons on the map. In other words it sounds like you might need a GIS server(open or ArcGis). Although you could build it from scratch using any geo-enabled db such as mySQL or MSSQL.
I am trying to take a shapefile of subdivisions within a county that I have created and line it up with another shapefile that was given to me by the County Appraisal District (parcel data). When I try to get them to line up then my streets shapefiles is not aligned with everything else. They are all on the same coordinate system and I do not want to have to recreate the shapefile for the subdivisions. Any thoughts?
This is a question with answers that may be simple or may be very complex, depending on your situation. As a GIS developer, I've most commonly seen this as a symptom of an incorrectly defined coordinate system. However, whether this is the case or not, and what the solution is strongly depends on your environment. From here on, I'll assume that you're working in an ESRI package...
I agree with the other posters that your problem is one of mismatching projections and/or datum definitions.
The most important thing to understand as regards projections in ESRI software is this:
Manually setting the projection of a dataset (shapefile, geodatabase feature class, etc) in ArcCatalog does NOT reproject that dataset!!!
In order to reproject your data, you must EXPORT the data from an ArcMap session in which you've been working and where the data is obviously lined up correctly. During the EXPORT, you are given the choice of saving your data with the coordinate system of the underlying map or that of the original dataset.
Your best bet is to follow these steps to create a new dataset with the correct projection and then extrapolate what you need to do to fix your specific problem:
Create a new ArcMap session and set its coordinate system:
Do this in a fresh ArcMap session with NO OTHER DATA. Be sure to explicitly set the coordinate system of the ArcMap mapview to your desired coordinate system (I recommend the one that matches the data you're trying to overlay, or one from another well-established dataset).
Add one other dataset with a known good coordinate system.
Create your new dataset in this ArcMap session. Give your new data the same coordinate system as the ArcMap mapview and the one other dataset in the map. Set the XY domain of the new data to exceed the area defined by your other dataset, but don't go beyond the size that will reduce your desired spatial resolution.
Create your data. It can be any data at this point. Some lines, some polygons, etc. Save your work.
Export your new dataset. When prompted, choose to save with the coordinate system of the underlying mapview.
Create a new ArcMap session and add your new dataset. Then add your parcel dataset. They should now occupy the same space in your map window.
Edit your new data to your heart's content.
Some probable issues if this doesn't help:
You didn't follow these steps correctly - check the ESRI documentation; this is a well documented issue.
The parcel data you're trying to match doesn't have properly defined coordinate system. It's always possible that the keepers of this data don't know what they're doing and have munged it up. I've seen this problem more times that I care to admit.
You've matched the projection but have mis-matched the datum. Many municipalities are still using data in NAD27, which is way out of date. Some have moved to the modern NAD83. The difference can be up to 300 meters, depending on where in the country you are. Also, data that originates from surveying or GPS equipment is usually collected in WGS84 (the typical default for satellite surveying), which is for all practical purposes the same as NAD83, at least at mapping scale resolutions.
Try researching these issues and see how it goes. I'll say it again:
Manually setting the projection does NOT actually project that data!!
Good luck!
Your problem is probably one of projection
| projection: character string that names a map projection to use. See
| 'mapproject' (in the 'mapproj' library). The default is to
| use a rectangular projection with the aspect ratio chosen so
| that longitude and latitude scales are equivalent at the
| center of the picture.
`-----
Agree that your problem is projection. Is there a .prj file extension associated with either of your files? If not key first is finding out what projects you have. I would guess State Plane of some sort if you are dealing with U.S. centric local data from a local government.
Cadastral tools (surveyer tools) usually let you specify a handful of control points and will then "warp" the data to fit to your control points. This can be anything from a simple shift to something more complex. If everything is shifted by a few feet, you can also just use your "editor" to select all shapefiles and then move them however many feet necessary.
If you've verified that both shapefiles are using the same coordinate system, then projection is less likely to be the problem. It's fairly common for parcel data to be "offset" from other data sources (such as roads). This comes from inconsistent collection methods and points of reference.
Another source of error can be that one of the shapefiles has the wrong coordinate system specified. For example, if the roads were actually WGS 1984, but it's prj is set to NAD1983, you will see some significant errors. This usually happens if you had to manually set the coodinate system for a shapefile (i.e. it didn't include a PRJ and you created one).