I’m new to this tool, I am currently running the coastal vulnerability model in version 3.8.9.
The data inputs seems OK to run, and I’ve get the accomplished result.
I can open the “coastal_exposure.csv”. However, I failed to open the “coastal_exposure.gpkg”. I’m sure that my ArcGIS version can open .gpkg document, since I’ve successed in opening the result of sample data.
Please tell me how to correct it. Here I attached the model log file. CSV+gpkg+log.zip (413.0 KB)
Thanks for the post and using the forums! Also, thanks for so nicely uploading a zip with the log file and data. It is strange that you can’t open the file in ArcGIS, I am using QGIS and was able to get the following:
I don’t have ArcGIS, so it’s hard for me to troubleshoot. Do you get any errors or messages when trying to open in Arc? Maybe @jesseG would have some insights?
Thank you so much for helping me with this problem.
Actually, I’m using ArcGIS 10.7, and it didn’t warn me with any messages, it behaved like I didn’t add any data. What confused me most is that the calculation results of the sample data can be displayed in ArcGIS (Shown in Picture). Maybe there are bugs in my ArcGIS.
I’m trying to open your output in both ArcGIS 10.7.1 and QGIS. It does not open in ArcGIS but does in Q. When I try to look at the layer or its metadata in ArcCatalog, I get the error “The coordinate system description is invalid”. QGIS shows that the coordinate system is “Krasovsky_1940_Albers - Projected”. So I’m wondering if the coordinate system is the problem. Can you try reprojecting your inputs to a different projected coordinate system (like UTM) and see if that allows the results to be opened in Arc?
It could also be that it’s not the coordinate system itself that’s an issue, but how the projection’s information is saved in the .gpkg.
One other thing that may be of concern is that the log file shows several of these warnings: “WARNING D:/coastalvulnerable/DEM_xiamen.tif is unprojected and will be warped to match the AOI and resampled to a pixel size of 1000 meters”. I know that it’s ok if only the AOI has a projected coordinate system, and the other input layers have a geographic coordinate system, but I believe that the other input layers must have some sort of coordinate system, whether geographic or projected, they shouldn’t have no coordinate system at all. Can you make sure that your other spatial input layers do have some sort of coordinate system set?
What follows is a bit of tangent, I bet @swolny may have already identified the source of the problem - that “invalid” (as far as Arc is concerned) coordinate system.
That warning about “unprojected” data is actually triggered when the raster has a “geographic” coordinate system. There’s nothing wrong with that, but we issue the warning mainly because we have to project the raster and need to make an arbitarary choice about the target pixel size (since we’re going from spherical unit pixels - degrees - to linear unit pixels - meters). So we warn the user in case they would prefer to project the data ahead of time and choose a more appropriate target pixel size in the process.
If the raster was already in a projected coordinate system, it still may need to be transformed to match the projection of the AOI and other layers, but we wouldn’t need to guess about what the corresponding pixel size should be - we could just directly scale from one linear unit to another linear unit.
Thanks @dave for the clarification of what triggers that message. Many other models use a particular raster input as the basis for what pixel size to reproject other layers to (like the DEM for freshwater models). Since only the vector AOI input is required to have a projected coordinate system for CV, I guess that doesn’t work for this model. How does the model choose, in this case, a pixel size of 1000 meters? I wonder if some of this information should be added to the User Guide.
@swolny yeah CV is kind of unique in this respect because while it has a few raster input requirements, it’s main computations are not based on a stack of aligned rasters like many other invest models. The individual raster inputs (DEM, bathymetry, population) are never involved in a computation that includes more than one of those rasters at a time. For each raster, values are extracted at or around the shore point vector (<-- that’s an oversimplification). So it’s not neccesarry for the rasters to be exactly aligned with one another, or to have the same resolution as one another.
If a raster needs to be transformed from a geographic projection, the target pixel size comes from the user-input model resolution. That input’s main purpose being to specify the spacing of shore points along the coastline, but it serves double-duty in this case.
If we want to, we could add to that warning message to also say: “WARNING D:/coastalvulnerable/DEM_xiamen.tif is unprojected and will be warped to match the AOI and resampled to a pixel size of 1000 meters. If that is not an appropriate pixel size for this raster, you may use a raster with a projected coordinate system and it will not be resampled.”
I am stuck with the similar problem, but my gpkg failed to open in ArcGIS and in QGIS, it is opening but there is no information in the attribute table. Kindly help me with this.
Hi @Nivedha1994, I downloaded your data and I don’t see any problems. The gpkg opened in QGIS and the table looks how I would expect. What version of QGIS are you using? It could be worth updating.
I recently had a similar problem where a .gpkg opened fine in QGIS but not ArcGIS, where it had a missing attribute table and a cryptic error message. Turns out it was an issue with field names in the attribute table, ArcGIS hates anything but the most basic field names. Doesn’t sound like the exact issue here, but something to double check.
Also a note that you can’t drag and drop .gpkg files into ArcGIS, they only seem to work if you use Add Data, then navigate into the .gpkg to select the layer you want. And I’ve seen the same issue as @rmgriffin, that sometimes the field names cause problems, especially if they’re really long.
