POST
|
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
03-09-2018
08:35 AM
|
0
|
2
|
1872
|
POST
|
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
12-07-2017
12:52 PM
|
0
|
1
|
341
|
POST
|
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
12-07-2017
12:46 PM
|
1
|
0
|
1871
|
POST
|
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
12-07-2017
11:35 AM
|
0
|
5
|
1871
|
POST
|
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
12-07-2017
09:45 AM
|
0
|
7
|
1871
|
POST
|
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
12-07-2017
09:12 AM
|
0
|
0
|
1871
|
POST
|
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
12-06-2017
01:06 PM
|
0
|
1
|
2303
|
POST
|
I created a mosaic from 411 TIFF orthophotos. The TIFFs total 106 GB in size and each are in UTM. However, the final image needs to be projected for our web map (Portal) as it's typically not wise to allow it to reproject on-the-fly over a LAN when you want users to have a relatively fast and responsive mapping experience; hence, it should be in the same projection used by Portal. So I'm in process of projecting the Mosaic using the raster projection tool. I opted to run this through Modelbuilder so I can at least see if the process is indeed processing. However, actual progress, I find, can only be done by monitoring the size of the folder where the final image is going (using Windows Explorer). The problem I'm going to have is time. This folder into which the projected Mosaic will be deposited is growing at about 18 mb/minute, and the resulting file won't be 106 GB...it will more than likely end up being around 150 GB in size. By my calculations (and correct me if I'm wrong), the resulting file is growing at approximately 1 GB/hour; hence, at this rate the projected image will be completed in approximately 150 hours....This means at this rate the final image should be completed in about 6 days. Cripes. Does this should right to you? Should a simple projection of an image take almost a week to process in ArcMap? Is there perhaps a faster way to do this? Thanks
... View more
12-06-2017
01:03 PM
|
0
|
11
|
2813
|
POST
|
I'm using ArcGIS 10.5.1 and I have created a simple file geodatabase with elevation ranges (polygons). These ranges have construction costs estimates associated with them based on those elevations. There are only 4 different cost associated with elevation ranges. I created a float type field and have entered these costs manually into the attribute table. I have also set the number of decimals for this field to be 2 in the attribute table properties. However, whenever I enter a dollar value (to 2 decimals), the number is automatically rounded up; hence, if I enter 1,247,119.96, as soon as I hit <ENTER> it changes to 1,247,120.00. I have also tried setting this right using the properties of that field in the attribute table, but this does nothing. Obviously, I'm doing something wrong...but what is it? I'm praying that this is not a bug as I need to calculate costs per acre throughout this data set and if the numbers are in error then none of this work will be accepted. Thoughts, Ideas, Suggestions?
... View more
09-13-2017
04:55 PM
|
0
|
3
|
4483
|
POST
|
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
06-19-2017
02:46 PM
|
0
|
0
|
572
|
POST
|
Jonathan: Thanks for the response...much appreciated. I'm currently using ArcGIS for Server 10.4....and ArcGIS 10.4.1. I have configured the popup to use the 1/1/2017 date format and it works really well in the Web Map. And when I open the layer's attribute table in the web map it is all perfect too. The problem I'm having is when I open the same web map using the Web Mapping Application. The popup is fine, but when I open the layer's attribute table there's this incorrect date stamp that has been added to the field (I did not ask for that throughout my entire workflow). This is a pain because the users will be using the Web Mapping Application, and it is policy to provide the necessary agencies with the records of data after an incident; hence, they will be exporting the attribute table to CSV...and those incorrect time stamps are then exported to the CSV as well. The time stamps will only cause confusion to the users and the recipients of the downloaded data...and we most certainly do not want to be editing the CSV records every time either. I have been using Microsoft's Edge browser, but the same problem occurs when using Chrome, and we've never had much luck using Firefox for any of this here so we just don't use it. I'm wondering (and hoping that it's not) a bug.
... View more
06-16-2017
01:52 PM
|
0
|
2
|
572
|
POST
|
I have created a Portal Web Map that will be used to track pollution incidents. This map will require user input (add and delete points, plus updating attributes etc.). I have about 95% of it working, however, I'm running into issues with the date field. It works perfectly in ArcMap...I have the default date showing up as 1/1/2017. It works perfectly in Portal's Web Map...the default dates will show up correctly in both the popup as well as the attribute table. However, when I launch the Web Mapping Application it behaves differently (and it's the web app that we want users to use). In the web app the popup will show the correct default date, but when one view's the attribute table it will show the correct date, but for some reason Portal adds a totally useless time stamp, and of course one cannot edit the attribute table in the Web App (and this only occurs in the Web Mapping Application...not the Web Map). We're asking the users to manually add both an incident reporting time stamp as well as a time stamp for when the tracker was updated (editor tracking doesn't allow them to override and update the times the way they're needed). Having a system generated time stamp as a part of a date field is only going to confuse the users and the readers of the reports. Each table is typically exported to a CSV file to be shared with external agencies and that system generated date-time stamp carries over to that file, and we would prefer not to have to manually edit fields in the spreadsheet every time we need to send out reports. Is there a way to force Portal to stop creating this annoying time stamp in the Web Mapping Application? I always thought that the Web Mapping Application referred to the Web Map for data and configuration...perhaps I'm misunderstanding this? Thanks
... View more
06-16-2017
11:41 AM
|
0
|
4
|
1140
|
POST
|
Thank you very much both Rebecca and Jake. This is exactly what I needed to learn. I tried searching for this online but was not able to narrow it down...so you both saved me a lot of extra time. Thank you again.
... View more
06-07-2017
01:08 PM
|
0
|
0
|
524
|
POST
|
We use AGOL sparingly (corporate policy restricts our use of it). However, I would like to learn if it's possible to use one of our cached images in ArcGIS for Server/Portal in AGOL. I don't see much literature on the subject anywhere, so I'm surmising that it might not be possible. But it would be very handy to be able to transfer a cached image that we have already created using ArcMap as a map service to AGOL. We can certainly create map services directly from ArcMap to AGOL...imagery would be nice too :-). This would really help when we need a better image for use in our ArcGIS Collector app when gather data from the field. Thanks
... View more
06-07-2017
12:01 PM
|
0
|
3
|
1032
|
POST
|
Melita: I'm just trying to learn how these numbers were derived so I can replicate the process in the future. I defined my local grid projection based on the parameters above, but the lines are about 2000 m out to the north (slightly northeast). When I just calc the geometry in the attribute table (in excel) using the conversion parameters, and then import the Excel table back into ArcMap the geometry falls into place. I'm not doubting your math, but how could this then be out by 2000 m if it's using the same parameters? Knowing where and how "w" and "z" are derived would probably help I think. What do you think? Thanks
... View more
04-04-2017
11:58 AM
|
0
|
0
|
2421
|
Title | Kudos | Posted |
---|---|---|
1 | 07-08-2016 08:42 AM | |
1 | 08-25-2016 07:12 PM | |
1 | 08-25-2016 09:03 PM | |
1 | 08-30-2016 08:48 AM | |
1 | 09-24-2015 07:26 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|