Multiple setup issues

[tachyon-work]

Setup in 10.3.1, trying to run a simple calculate weights:

1. There is a significant change from the previous SDM in that apparently now all the environment settings require you to have everything stored in a gdb. Historically you just set the environment settings to the relevant raster and the SDM worked. Now, if you don't have all your files in a gdb, everything fails to run. This needs to be made explicit in the documentation, as this has never been necessary in the past. I appreciate that this SDM is being designed to work in ArcGIS Pro, and I know that there are differences in the geodatabase structures between Pro and previous versions. So if SDM is no longer going to work in anything prior to Pro, can you please let us know.

2. Tools fail to run unless your mask is set to a polygon in a gdb. This means you are now required to have a different snap raster and mask. This is a serious fundamental problem, because the areas are going to be marginally different, cell counts will be off, and this messes with the statistics. The mask has to be allowed to be a raster. This is pretty urgent.

3. Even when you do change the above to get past the errors that pop up, you get the following error anyway: It looks like there might be a typo in the code somewhere.

The second issue is fundamental and is of serious concern.

[trotor]

Thanks for the commments! Everything should work in arcmap and I personally even run them on here. And everything should work without GDB too - I will re-request non-gdb demodata again from the demodata team, I don't have it currently available.

RasterLayers are supported, raster datasets are not - there is no real reason for that except that they behaved differently from rasterlayers and I disabled them because of my work schedule. I can focus on them as soon as I get working example from the demodata team.

Dwrite line issue fixed on v 28

[tachyon-work]

Ok, thanks for the info. I created a raster layer from the raster dataset, and now I get this:

It won't read the info from the layer file?

[tachyon-work]

I downloaded your GTK demo data, because I wanted to see what was going on. If I open up your MPM_DemoData mxd to examine the environment settings so that I can make sure I'm setting mine up in a similar way with my data, I notice there's a few issues:

1. You don't have output coordinates or the processing extent set - these are critical to ensure correct ouput:

2. The raster analysis settings are not set properly. The cell size isn't set (it should be set to the size of the raster mask), and the mask has to be a raster for the analysis to work properly. The demo data mxd has it set to a vector layer. This will invalidate the statistics the tools generate because it messes up the cell alignment and cell counts. It needs to be a raster to get accurate results.

This may explain why you're not able to replicate the errors that myself and @DarthSysmon are getting.

[trotor]

I will take a look at there raster dataset issues asap. I think it could be that rasterdataset (file?) stored in fgdb is rasterlayer and there were some differences how they are accessed via arcpy.

On Wed, Jan 3, 2018 at 8:57 PM, tachyon-work notifications@github.com wrote:

Ok, thanks for the info. I created a raster layer from the raster dataset, and now I get this: [image: image] https://user-images.githubusercontent.com/32659237/34534566-7ad17464-f123-11e7-92d9-d26ad768124c.png

It won't read the info from the layer file?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/gtkfi/ArcSDM/issues/79#issuecomment-355095778, or mute the thread https://github.com/notifications/unsubscribe-auth/AKV5efJvH_r5hHUpK03CF5Yyn-rWy9fWks5tG82igaJpZM4RRIAu .

[tachyon-work]

My suggestion for the raster mask is to simply export one of your pre-existing grids to a new study_area raster in the gdb and use that to define the mask and snap raster. That being said, if you update your environment settings accordingly you then run into the aforementioned error where it says you can't have a raster dataset as a mask...

[trotor]

I did and fixed the rasterdataset mask issue. The problem lies somewhere in counting mask size for prior-probability. Now fixed but might not work on all inputs. output coordinate system and extent shouldn't have effect anymore, I have made it to obey "same as input" on most places. But will forward the suggestion to demodata team and will test with that .

[tachyon-work]

Output coordinate system: this assumes all your input data is in the same projection. This is rarely the case in reality. If anything happens to be in a different projection, this will end up causing problems when you start doing raster processing. Even in your demo data, not everything is in the same projection. I can see some rasters are in a Finnish projection, some are in some ETRS transverse mercator projection. To ensure consistent raster outputs for any raster processing (either SDM or Spatial Analyst), the output coordinate system needs to be set. You can't have it set to "same as input" unless your inputs are all the same. They're not the same.

Extent: As above - you're assuming the extent of all your inputs is the same. And you're also assuming you have no missing data areas. While the rasters in your demo data all appear to have the same extent (and that's fine), it's very easy to create one from the included vector data that doesn't, as well as one that includes missing data. This has to be tested, because it's one of the fundamental issues that has to be dealt with in SDM. At the very least the snap raster has to be set.

[trotor]

Okay, very good points, I will take this into account. And special thanks for pointing out that our demodata still contains some non-standard data, it should not. We are obligated to use ETRS EUREF on all of our data and will fix it!

T

On Thu, Jan 4, 2018 at 9:07 PM, tachyon-work notifications@github.com wrote:

Output coordinate system: this assumes all your input data is in the same projection. This is rarely the case in reality. If anything happens to be in a different projection, this will end up causing problems when you start doing raster processing. Even in your demo data, not everything is in the same projection. I can see some rasters are in a Finnish projection, some are in some ERTS transverse mercator projection. To ensure consistent raster outputs for any raster processing (either SDM or Spatial Analyst), the output coordinate system needs to be set. You can't have it set to "same as input" unless your inputs are all the same. They're not the same.

Extent: As above - you're assuming the extent of all your inputs is the same. And you're also assuming you have no missing data areas. While the rasters in your demo data all appear to have the same extent (and that's fine), it's very easy to create one from the included vector data that doesn't, as well as one that includes missing data. This has to be tested, because it's one of the fundamental issues that has to be dealt with in SDM. At the very least the snap raster has to be set.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/gtkfi/ArcSDM/issues/79#issuecomment-355370168, or mute the thread https://github.com/notifications/unsubscribe-auth/AKV5eR4uH6JQ3zHe_m4Sin9oqaMMRjUWks5tHSFmgaJpZM4RRIAu .

[tachyon-work]

Most appear to be in EUREF_FIN_TMFIN, but the Geol_grid maps are in ETRS_1989_Transverse_Mercator.

If you take a look at the Era_200k raster for example, it has different extents to other rasters.

[trotor]

New demodata set uploaded. Are other points still valid?

[tachyon-work]

That updated code I sent to your team a while back fixed it. This can be closed.