-
Notifications
You must be signed in to change notification settings - Fork 2
Home
This is a wiki set up to ask questions and post answers regarding the technical challenges associated with using open-source geographic information systems.
Go into editing mode using the edit button at the top-right. Then scroll the end of the document and add a new line, starting with h3, or three hash-tags. Type a short title to your question. Then start a new line and add more information.
First, make sure your new projection is really in the spatial_ref_sys
table, and that all the parameters are correct.
Second, make sure your geometry column is registered in the geometry_columns
table, and that it's registered to the new SRID you're trying to project to.
Third, make sure the geometry you're translating from really exists, and has data. Check this with the astext()
function and check it's registration in the geometry_columns
table.
Finally, make sure the geometry you're translating from has all the same SRID's as the column it is registered to. Check this with the srid()
function (similar to 'astext()', but it tells you the SRID for each record in the geometry column).
This is probably caused by the field being recognized as a data type other than a number. Double check the fields in the layer's properties to make sure it's the right data type. Then double check the column's data type in the database. Remember to specify the data type when you create a new column in the database by adding REAL
or INTEGER
to the ALTER TABLE ... ADD COLUMN ...
statement.
If you have calculated a numeric field on the fly in a SELECT
query and added the results to the QGIS map canvas, the data type might be registered as TEXT
, making it impossible to use for mapping numerical data. In this case, you're better off adding a new column in DB Manager with the correct data type and using UPDATE
to make a permanent record of the calculation. See Pre Lab 3, where we calculated DistJoin based on information selected from another table.
If you first add a table to QGIS from DB Manager and then you change the schema of that table in DB Manager by adding a table, the new column does not show up in the QGIS attribute table. It doesn't seem to matter if you re-connect the database or add new versions of the layer, or even disconnect the database, close QGIS, start a new QGIS project, and re-connect the database. This problem even persisted through making a new copy of the database! This observation led me to believe there must be some metadata about the table stored in the database itself... and there is, in the geometry_columns_field_infos
and geometry_columns_statistics
metadata tables.
You can update these with a SpatiaLite function: SELECT UpdateLayerStatistics('table-name')
. For example, if I need to update columns/fields for a table named Districts
, you can use SELECT UpdateLayerStatistics('Districts')
to update all the metadata for that table. The next time you add Districts
to the map, it will have all of its columns.
If you're wondering why SpatiaLite wasn't programmed to update these statistics automatically, read the programmers' discussion about this issue here.
Believe it or not, similar issues crop up in ArcGIS as well-- sometimes you have to use a calculate statistics
tool to update the statistics for a raster dataset before the dataset can be displayed or used in analysis.
SpatiaLite creates a primary key column for each table it imports, and tries to name it pk
by default. However, if your shapefile was previously exported from SpatiaLite, then it already has a pk
column, and the conflict causes DB Manager to crash. There are two solutions to this:
- delete the
pk
column from the shapefile before you import it. -or- - while using the import layer tool in DB Manager, specify the primary key to use
cat
as a primary key, since it is of typeinteger
and all the values are unique.
This question could come from observing that the custom projection will not display in QGIS or from observing that a new column with the custom projection is not properly storing transformed coordinates. The most common solutions I've seen are:
- Make sure you haven't accidentally switched latitude and longitude.
- Make sure you have included one and only one datum, either in the form of
+datum
, or a combination of+ellps
and+towgs84
. Also note that these seem to be case-sensitive, i.e.wgs84
is not the same asWGS84
.
- If you're really stuck on this lab, please take some time away from the computer to do the readings.
- The general idea is to find & choose the best way to deal with the SLC-off gaps before running any kind of classification tool. Between patching any combination of granules, closing gaps, or closing gaps with spline, choose the best option.
- It looks like "clustering for grids" is now named "k-means clustering for grids".
- Saving grids in SAGA: the easiest way is to set any of the output grid settings when you run a module. Outputs usually have "<<" before the output grid option. (and likewise, ">>" for any input grids). You can also save the data for grid files by right-clicking the relevant grid in the Data panel of SAGA. You will also be prompted to save any unsaved grids when you close the SAGA gui, where you can simply check any of the unsaved grids to get them saved upon closing (this is a riskier option, in case SAGA were to crash during the middle of your work).
- Trouble with optical calibration (see below, and also, you may try running Image Concatenation and Optical Calibration in the Orfeo program rather than through QGIS. You'll have slightly more control over the modules by going through Orfeo directly).
If you run optical calibration and get a result of all 0's, you most likely saved the output as an integer data type. Since optical calibration converts raw integer radiance values at the satellite sensor to percentage reflectance values at the top of the atmosphere, the output raster must be of type double or float to accommodate decimal numbers.
This may not really be an error at all. Look at the actual values stored in your new GeoTIFF by using the identify tool in QGIS or moving the cursor around the scene in Orfeo. It's likely that the background values are -999999 (the default nodata value in SAGA) and your legitimate data values are still in the range you'd expect (from 0 to 1). Since nodata information is lost in the file conversion, hopefully all you need to do is set the new nodata value to -999999 (or whatever the background values may be) using the Orfeo No Data Management module.
Adjacent Landsat scenes look very different (one darker or lighter than the other) after Optical Calibration
There are three possible explanations:
- The brightness of the scenes actually did change due to real changes in the landscape or atmospheric conditions.
- Optical calibration did not work correctly: check to make sure all of your values are in a range from 0 to 1, and check to see whether objects that should look very similar over time (e.g. a dark water body or patch of forest) have similar values in both scenes.
- The landscape didn't change much and optical calibration did work correctly, but the composition of each scene differs enough that Orfeo's automatic histogram stretching makes them appear differently. As in (2), the actual data values for similar features should be similar, in which case you either just need to go ahead to Mosaic the images so that they both render with the same histogram for each band, or you can play around with the percentage cut values in the Color Dynamics tab.
Unexpected results in NoData areas of Landsat scenes (particularly the SLC-off bands of Landsat 7) while using Mosiac in Orfeo
This problem arises because Mosaic may be trying to interpolate values for the unknown locations. Try to use the "simplest composition mode" for the Feathering Method in Orfeo, and make sure that the output image has the same number of bands as the input.
The video tutorial apparently makes this sound more complicated than it is. You have satellite scenes for two time periods. Let's call them Time A and Time B. They mostly overlap, but not quite, because the satellite orbits drift a little over time. You want to create one unified boolean mask with a 1 wherever there's legitimate data for all the bands for both periods of time. Before you can do that, the two scenes must share the exact same grid system. In SAGA, you'd accomplish this with the Resample module, by resampling one grid (let's say Time A) into the other grid's system (Time B's). You can then use band math, crosstabulation, and other tools on resampled grid A and the original grid B. In Orfeo, the tool is Superimpose Sensor, and it does the same work as RESAMPLE. In the video tutorial, I only make an additional copy of Grid B so that I could start the next section of the workflow in a new folder with consistently named scenes. To be absolutely clear, you resample or superimpose one grid (let's say Time A) into the other grid's system (Time B's), and then move along with the analysis using the resampled/superimposed Time A and the original Time B. The next step is creating a boolean mask so that you can cut out all the extraneous data before you classify.
Hey everyone, I just spoke with Joe about what he wants us to have for Monday, and I figured I would post it here so that everyone can see it. He went over this in class, but I thought it couldn't hurt to have it written in multiple places.
Our main objective is to create a poster that we can use to tell a story of what happened in our region of interest. Five components we can use to tell this story are:
- Population Change Maps
- Population Change Tables
- Land Cover Classification Maps
- Land Cover Classification Tables
- Scatterplot connecting the two (once the first four parts are complete)
In order to draw polygons to create our classes, is helpful to have different visualizations of the satellite imagery (e.g. RGB, False Color, NDVI). An unsupervised classification can be helpful to make us thing like the computer and create polygons to differentiate between classes the algorithm might confuse. It is not necessary, however, to have a nice looking map and legend for the unsupervised classification. RGB, NDVI, and other maps can be helpful to tell a story and also they can look cool.
Hope this is helpful! - Jonah