Latest Contributions by MarkHotz

Adam: Thanks for the response...much appreciated.  I think what I did was that I was too hasty and didn't wait for the web adaptor to prompt me to configure it after I had completed the upgrade; hence, I moved on to upgrading our GIS Server...and then its web adaptor as well.  I will explore IIS and C:\inetpub\wwwroot too though.  Other than searching for everything in the registry and deleting every single occurrence of this install this might be my last hope.  Very annoying. ... View more

Paul: Thanks very much for this too...I had no idea that processing through Python would make that much of a difference, so obviously you and  Jayanta are ahead of the curve here.   I will most definitely explore Python for processing spatial data, and will also looking into ELA as that might be an option for us as well.  I have ArcGIS Pro but have not really used it that much...but this too might be worth exploring.  I just need to make sure that the tool I need to use is actually optimized to run in a 64-bit environment.  If so then this might be the least expensive approach. Thanks again.   ... View more

Rebecca: That's amusing...I have had a few "Homer Simpson moments" where right at the very end of a long process it crashes due to something...most often disk space :-).  I'm not trying to marginalize your experience here, but it is nice seeing that others are experiencing the same issues as me LOL. The most recent disk space issue for me was when I was caching a map service.  We have 1 TB volumes for all of our add-on drives to make it easier for back ups (this decision was made long before GIS arrived here), but what I found when caching is that the ArcGIS estimated required disk space and the resulting disk space used are rarely the same (i.e. the result is always about ⅓ less than the estimated).  However, now I realize that the "estimated disk space" for caching has little to do with the final space required, but everything to do with how much space is required to actually process the cache, so if the estimated disk space required is 900 GB then one would probably need that much space just to process the cache, and the final result would be around 300 GB.  Thankfully, we're not caching a lot of imagery, or I'd be adding dozens of volumes every year :-). ... View more

Rebecca: Thanks again for the response.  What this tells me is that I'm not alone dealing with this...misery loves company I guess LOL.  I cached two items last year:  One orthophoto, which took about 2 hours to cache, and one base map for a large region that actually took 4½ weeks to process.  Even though I managed to cache this base map, and it took a very long time, it will not be necessary to repeat this process any time soon; hence, Image Server simply cannot be justified.  This base map was a vector file but it just took far too long to draw in Portal so I managed to cache the map service, and now this draws to the screen in Portal in less than a second, so it certainly does help. The only reason I cached this base map at all is because our Portal relies solely on ESRI (or Bing) satellite and base map imagery for base maps, and during a crisis if the web goes down (which it does frequently here) we would then be blind.  At the time the organization didn't want to pay $20,000 for a hi-res satellite image (although I should revisit that request again soon), so the least cost-effective method was to simply cache what takes too long to render.  At least it works.  I'm just glad that no one decided to reboot my computer when I wasn't around during the process :-). ... View more

Rebecca: Part of the problem I am having is that when I try to publish this ortho to a map service to use in Portal I'm presented with error messages that tell me my licensing won't permit it.  So I'm surmising that in order to publish a mosaic to a map service then one requires the image server license, which we don't have, nor could we ever justify purchasing. I have successfully masked, clipped and copied mosaics to a file geodatabase in the past, but this then loses all mosaic functionality and creates a flat image file (a composite file).  I have also found that building pyramids and using any compression during the process tends to degrade image quality and does not look good.  However, a raw file is OK for our purposes anyway as we're only using this ortho as an up-to-date base map, and once cached on ArcGIS Server it works really well.  In the GIS itself a raw flat file, although a little slower to draw, still works well, and there are other caching processes to be explored here as well; however, the mosaic can still function in this environment too anyway. As for projection on-the-fly, both ArcGIS and Portal will perform this function automatically, which is fine for small data, but for large ones like ortho or satellite imagery it is not really recommended as this will only slow down rendering on screen, and users will tend to be reluctant to use it if latency is even 5 seconds or more.  I have created a map service with a raw composite orthophoto in Portal in the past (to experiment) and it takes 45 seconds to draw and refresh; hence, caching is really the best way to eliminate this issue.  Once cached the ortho image will draw to the screen in Portal in less than 1-second, but having everything in Web Mercator in Portal is probably a good habit to get into. This all then reverts to the issue of how long should it really take to project a 150 GB orthophoto :-).  I think anything more than 4 hours is ridiculous, but that is just me LOL.  However, what I might try next is to reproject this same ortho using SAFE FME to see if that works better. ... View more

Jayanta: Thanks for the response.  I think using this might help track it's progress better, but it would be using the same geoprocessing tool (raster projection) so I'm surmising that the process would take just as long.  However, it could allow it to process separately in ArcGIS Pro...I should try that next. Thanks. ... View more

Dan: I think I initially used float because the large decimal range wasn't really required.  However, having said that using "double" does work, so thanks for that advice.  Such a small thing to stop a project LOL...I would have been oblivious to that for a few days for sure :-). ... View more

Jonathan: Thanks...it is appreciated.  After some serious head-banging I have only just learned that this is actually a bug in version 10.4, but the good news is that it has also been resolved in version 10.5.  We're planning to upgrade our ArcGIS Desktop as well as our ArcGIS for Server and Portal for ArcGIS to version 10.5 probably within a month (maybe 2) so this is probably good timing on our part.  At least I don't have to continue struggling trying to find a solution...because there isn't one in version 10.4 . I built all of our Web Mapping Applications using the Web Application Builder, but now we know the reason why the web mapping application wasn't honoring the settings I made in the web map.  It was only in the attribute table where this annoying problem is occurring so it was confusing, but now it's just a matter of when we can upgrade.  Everything was fine in both the web map and web mapping application popups though. I have been building some of our web mapping applications with the expectation that some users will be able to update the data themselves (points on the spatial side, and attributes as well).  When one creates a Feature Map Service in Portal (as opposed to a standard Map Service) it allows direct editing of data in the enterprise geodatabase.  This is especially useful to us when using the mobile apps such as collector as the users are then able to update the geodatabase directly from the field (we will be using this rather than AGOL as we have strict policies against using cloud based services).  But with the current desktop web mapping application they can at least edit this after they return from the field, which is sometimes easier to use if they make a mistake entering data etc. ... View more