Latest Contributions by CollinJohnston

@Pål_Herman_Sund Thank you for your insights, not really what I needed though. I understand how to create these analysis results, I'm more interested in how they are being derived within Earth. It's kind of a black box. @Chenyu_Li Thanks for your reply. Can you help me unpack it a bit more? using this statement " If you don't add any data, the analysis will be based on default terrain" against the visual display below it, I am again left confused. If you are using the default terrain data (Does not include surface features like buildings if I am correct?) How are you able to show that the built environment (buildings) is visible or not, or that the structures will cast "shadows" behind them providing a visibility screen? I guess I'm stuck on the visual example shown in the documentation vs. using the out of the box feature of terrain.

Looking at the results from ArcGIS Earth's interactive tool set, specifically the Viewshed. Left confused. We run Viewshed models frequently within Pro, sourced from a variety of Lidar. As you would expect, we get a fairly robust DSM from the lidar which allows us to see the way trees, structures etc will effect the view towards a tower, for example. Looking at this tool in Earth, I am seeing that the input surface service is an ESRI surface https://elevation3d.arcgis.com/arcgis/rest/services/WorldElevation3D/Terrain3D/ImageServer Unless I'm mistaken(most likely the case!!), this would only provide a ground surface value and not anything above the ground? And if that is a correct statement, then I'm confused as to how the Viewshed example in this document https://doc.arcgis.com/en/arcgis-earth/use/interactive-analysis.htm is able to provide a result which seems to include the features above the ground in the analysis. Anyone able to help clarify this for me?

‎09-17-2020

poking around for a similar solution. Any chance there is one out there someone following can point me towards?

‎08-21-2020

Are you able to tell me what method you used in order to see these changes reflected in your REST service? I'm guessing I need to republish (overwrite?) or simply restart the service in order for these domain value changes to be accessible. Would like to avoid having to republish.

‎06-12-2020

Thanks for the screen shot - That's what I needed!

‎02-18-2020

Came in to say exactly this. We thought we were 100% migrated to Pro workflows and tools, about a year ago. Still finding random things that have hurdles, such as this. Recently received a .mdb from a client, they were unable to provide in a different format. Glad I still have good old catalog to use for this... no .mdb access via pro seems like a mis- step to me even if we are leaving .mdb's in the past.

‎01-23-2020

For what its worth for those who stumble on this thread. We had the same issue (Portal 10.6.1) and realized it was a very easy fix. From what we have found, you need to use a Feature service, not the Map image service. When we first published this service we figured a Map Image Service alone would suffice. However...when loading in a map image service to the Map Viewer, the option for heat map display does not show up. You can still filter and change symbology etc. When loading in the same underlying source but as the feature service, you will see the option for Heat Map symbolizing. So we republished our service with both Feature and Map enabled and it now allows for Heat Map symbolizing.

‎01-15-2020

Did your org find a solution or workaround for this? Seems as though we are in the same boat. Have a ticket open but I'm antsy....

‎11-27-2019

Ah, that is right, thanks for the reminder Doug. I'm really just taking Survey123 for a test drive with our Portal so I wanted to share my troubleshooting success. Cheers!

‎11-27-2019

I was getting the same behavior when Publishing a Survey that was created in the web interface and being published as a Portal service. Same basic no details error message as in OP. Furthermore the server manager logs UI just reiterated the same message. Neat. I believe I was able to capture the actual error by switching the the desktop app for publishing designing surveys. From the desktop app I was able to see a more robust error message that read something like "You can't use an uppercase letter in the field name" VIOLA! The name of my date field was simply "Date" and once I changed to "date" I was able to publish from the desktop app with an error. Anyone stuck on this I would recommend using the desktop app to see if a better error message comes out. For some reason my Hosted db is a bit more finicky than AGOL db I guess? IDK, but it works now after updating names of fields with lowercase.

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by CollinJohnston

Re: Interactive Viewshed Surface vs results

Interactive Viewshed Surface vs results

Re: Registering a view with the geodatabase

Re: How to add a new code value to existing domain?

Re: Export to Table or Excel drops domain and subtype descriptions

Re: I need to open a MDB file in ArcGIS Pro

Re: Heat map in Portal for ArcGIS

Re: Exporting data from Survey 123

Re: Unsure how to fix "ERROR: Adding field to the table failed."

Re: Unsure how to fix "ERROR: Adding field to the table failed."

Web AppBuilder Custom Widgets