POST
|
I created a Survey123 based on a Enterprise Geodatabase Feature Class. The survey is planned to be made public so securing the data from this survey is key. To secure the data the query capability needs to be disabled, however this also makes it impossible to use the data in a webmap in Portal. So is there no way of making a survey public and the data secure but still visible/open to administrators with an Enterprise Geodatabase FC? In a hosted layer you can create hosted views and apply different settings to these views. The same functionality is needed when creating surveys based on an Enterprise Geodatabase FC. Hoping for tips.
... View more
11-05-2020
07:13 AM
|
0
|
1
|
802
|
IDEA
|
From 10.6 and onwards, system languages are disabled once you disable external content in Portal. We would like the ability to use our local system language in Portal, while still disabling external content in Portal. Update Content Configuration—ArcGIS REST API | ArcGIS for Developers
... View more
10-28-2020
07:01 AM
|
1
|
0
|
389
|
POST
|
Thank you, this really helped! I am going to use both methods and examine the results and the differences. Therefore I am marking your first answer as the "correct" answer, but both answers helped me.
... View more
09-30-2020
03:48 AM
|
0
|
0
|
2996
|
POST
|
Thank you for your reply Mervyn Lotter. For the buildings raster I have already applied a buffer of 100 meters, which reflects the distance I want to stay outside of. So all cells outside of these buffers are suitable per se. Is it correct in this case to classify all surrounding (cells outside of this 100 m buffer) to 10 - most suitable? For my second raster it would perhaps be more relevant to use the distance approach because I have not applied a buffer already. Also, this is not a raster with cells that should be avoided, but there are cells that should be prioritised more than surrounding cells.
... View more
09-28-2020
03:14 AM
|
0
|
2
|
2996
|
POST
|
Hi, I am doing an weighted overlay analysis with five rasters. I am using a common scale from 1 to 10 (10 being most suitable and 1 being the least suitable). I have some questions about two of the rasters: One raster is originally a vector dataset of buildings I want to stay away from as much as possible, but not exclude completely. Thus, the raster cells containing building are classified to 1 (less suitable), but my question is, what do I classify the surrounding raster cells where there are no buildings? Is it correct to classify them to 10 - most suitable? I also have a raster where the situation is the opposite: this dataset contains an area I want the analysis to stay as close to as possible (originally a vector dataset now converted to raster). Therefore, the raster cells which contains this wanted area is classified to 10, but what do I classify the surrounding cells to? In this case the surrounding raster cells are not the least suitable, they are just not as suitable as the cells with the wanted area...In my head it would be wrong to classify them as 1 (least suitable). Please ask if anything is unclear.
... View more
09-27-2020
07:44 AM
|
0
|
4
|
3074
|
POST
|
Thank you Jay, your reply got me into the right mindset. I also discovered the Cell Statistics tool which have a "Ignore NoData" parameter which was the best solution for me. I set the calculation parameter to "Sum".
... View more
09-23-2020
07:02 AM
|
0
|
1
|
4545
|
POST
|
Hi Dan, thanks for the response. I do not mean that NoData makes the calculation incorrect, I mean that classifying NoData to a value makes the results inaccurate and in turn incorrect. I explain all of it below: If you are running the Weighted Overlay tool with three rasters and one of the raster have cells of NoData, this results in a raster where the NoData areas in one of the rasters "propagates" into the resulting raster (see figure below). This results in kind of a "Intersect" operation of the rasters, which I do not want. So to avoid this "Intersection", you have to classify NoData to a value - let's say the value 10. In the Weighted Overlay calculation, this means that these areas (now with the value 10) are a part of the calculation and are effectively made relevant with a weighting, when they are originally not relevant. In my head it would cause incorrect and inaccurate results if you classify NoData values to a number value (value of 10 used as example) and run the Weighted Overlay tool. Hope this explained better. So is my thought process about this totally wrong? This post also explains the issue: arcgis desktop - Weighted Overlay with "nodata" cells - Geographic Information Systems Stack Exchange
... View more
09-16-2020
04:49 AM
|
0
|
4
|
4545
|
POST
|
Hi, I am working on a weighted analysis with four rasters. Two of the rasters have areas of NoData, which means I do not want to use the Weighted Overlay tool because this tool does not ignore NoData in calculations. If I were to use the Weighted Overlay tool I would have to assign a value to areas of NoData - and my conclusion is that this would not make the weight calculations completely correct. Someone please correct me if I am wrong! To get around this problem I started looking into using conditional statements using Con in Raster Calculator. I found a post where someone came up with this syntax: Con(IsNull(Raster3), Float(w1*Raster1 + w2*Raster2)/(w1+w2) , Float(Raster1 + Raster2 + Raster3)/3) Where wx is the weighting applied to each raster. So this works fine with three rasters, where one of the rasters contains areas of NoData. But what is the syntax if you have two rasters that contains areas of NoData? Additional questions: - Is the division necessary in the calculations because not all three rasters are included? And why is the second Float divided by the number 3 and not 1 (as in 100%)? - In the syntax above, in the second Float the rasters are not multiplied with weightings - is this correct? And if so, please explain why. Hoping for help!!
... View more
09-16-2020
02:00 AM
|
0
|
6
|
4652
|
Title | Kudos | Posted |
---|---|---|
1 | 10-28-2020 07:01 AM |
Online Status |
Offline
|
Date Last Visited |
04-21-2023
01:08 PM
|