POST
|
So, Bern's blog here Using images as custom point symbols tells how to do this - and I have done this, many times, over time. But, as of yesterday, however, my symbols keep disappearing on my maps where I have uploaded these little images to AGOL, then get them working, something happens and they are disappearing from the maps - not just one, but from all of the ones that I have made, using these - it just leaves a blank space in the legend where the custom symbol should be. It was there before, and functioning - now it is not. I have had to go start all over again, re-inserting the link to the image, re-sizing, etc. Late last night, the image would not load up, then suddenly, it did. Now today, just within the past hour, the symbols have disappeared from the maps again - maps are not edited or changed when this is happening - they are saved maps. It seems that something underlying is breaking these - in AGOL, maybe? Anyone else having these issues? This is using the tried and true old Map Viewer in AGOL, not the new beta one. We rely on being able to do this because the "out of the box" symbols do not have what we need. Any insight into this issue will be very helpful to us. Thanks, -Ellen Nodwell
... View more
08-04-2020
04:55 PM
|
0
|
3
|
1530
|
IDEA
|
Definitely, the symbology takes a lot more steps - importing is possible, but initially, the steps to get symbols to be the desired ones takes some extra time. Recently, while fooling around with trying to get symbology sets for specific topic areas, not present in the "out-of-the-box" styles, I found this link https://esri-styles.maps.arcgis.com/home/index.html which has the links to downloads of sets of different symbol styles - and there are a number of them out there. It was a search and discover exercise, but it is referenced in the Styles—ArcGIS Pro | Documentation on Styles... along with a bunch of other info. Let's say that symbology in Pro is a whole new ball game - and on the flexibilty-complexity curve, it ranks high - high flexibility (does many things), but highly complex and complicated - as compared to ArcMap. This involves a lot of learning and change. Adding the functionality mentioned above would be great - could be good to really think through what the users do when symbolizing - and especially, changing from the tiny dot or plain polygon or line random selection color that they get initially when adding layers to their maps.
... View more
02-25-2020
07:53 AM
|
0
|
0
|
4819
|
IDEA
|
This is a significant constraint in organizations that only have SQL Server OS authentication for users (many organizations). Microsoft recommends OS Authentication as a best-practice, and discourages the use of individual SQL Server users, when possible due to the security vulnerabilities that this exposes which takes extra layers of security that organizations must provide.
... View more
02-02-2020
10:10 AM
|
0
|
0
|
792
|
POST
|
Just want to give kudos to Kory Kramer and the Esri folks who spent time with me today walking through some of the issues - we do have some very caring folks behind the scenes that do want this to be on the continuous improvement scale in the up direction and for one, I will say again, I truly appreciate the great support that we get from you guys and gals in the various development teams and in the Support Group at Esri. When there's trouble, there is support to help. We really do want Pro to work and realize that it takes time to get there - and including us in the process makes us feel better, for sure!
... View more
12-10-2019
05:06 PM
|
14
|
0
|
1830
|
POST
|
Thanks Matt - so noted on the specs. We're going to be shopping in the new year... What you say Unfortunately we can't do this for all our users, but we're trying. This is so true in many organizations who don't cycle equipment that often and when they do they minimize expenses in doing this - sometimes not speaking with GIS users at all before buying equipment. This is an art form to get the hardware folks to engage in an organization to understand that the specs are higher for ArcGIS Pro and ArcGIS servers that others. Yet, this is the wave of the future - along with cloud storage - along with the variants of all of this combined together - everyone's environment configs are different - there is no same anywhere, I reckon. Thanks again for your response!
... View more
12-10-2019
04:58 PM
|
2
|
0
|
1830
|
POST
|
Thanks for more info to consider - yes, we've all done some hoops for our ArcGIS installs - always good for a conversation opener with the IT packaging teams I've worked with - "Hey, want some fun challenges to solve?" - It definitely encourages creativity - especially when they know that management wants this package out there and there is no "no" option. ArcGIS, however, is not alone in challenging enterprise IT departments - some of the heavy-duty geoscience software out there that has a high pricetag definitely pushes the envelope - one popular one even drove the build of a new data room in an old building in London where one of our teams was located as well as having to get a different configuration of servers because the doors were too small for some of the equipment (this was all pre-cloud) - very many challenges... connectivity being another - internet in some places simply is not accessible except through something like phone lines and a Hayes modem! One lady from Alaska was lamenting that they could not use AGOL due to this. It just would not work with the bandwidth limitations and areas where they had NO connectivity - deja vu back to the early 1980's! Thanks for responding to my post!
... View more
12-10-2019
04:52 PM
|
2
|
0
|
1830
|
POST
|
Reply to original discussion - at this point - this has many threads and offshoots - so, that's difficult. However, I am going to jump in here... I am a fairly picky very experienced ArcGIS user - I have used every version of ArcGIS since the days when we first had a PC application called ArcView introduced to us... Yeah. I'm old. So, IMHO, ArcGIS Pro in it's current "production" iteration has been presented to the users as "you'll love it - like a duck takes to water"... yada yada yada. Well, no, it isn't so hard to learn to use it, but does it work as well as ArcMap? No. OK. Reality: first prod release - unusable. Each time a new one comes out, I try to use it more. Functions we have begged for, some have been added... Much appreciated when they have... But here lately, and according to "Can U Run it" - I should be having an excellent experience - I'm not. Still. OK, so, what do I mean by "I'm not. Still." ? #1 - it is slow(er) - or should I say, it's very BOGGY - it seems to be very busy doing lots of things that make my machine make noises and sound like it's nearly stressed out - I watch the performance meter - hard to pin down exactly what is sucking the resources the most - sometimes it's nothing really - it just seems to be doing "something" (?) and it's not wanting to be available to me at that time. I wait on it. A lot. I wait on it to do some things that should be relatively quick. I know that each layer has some hooks to stuff and that we need to minimize to only what we need. Basic managing resources 101. But sometimes, it's the basemap. Sometimes it's just ? something only ArcGIS Pro thinks should take a long time. Who knows? Sometimes it comes back and is perfectly happy and goes on normally enabling me to do all kinds of things - as long as the data doesn't get too big for it - don't even think about doing any sort of large scale crunching! No way. I have a biggish data set that I can't even load into Pro without it croaking. This is all inside my environment - no network shares - no remote databases - this is all inside my very hefty environment on a gaming-quality high-performance machine. It's me and my connection to ArcGIS Online - which may be one of my issues, I suspect... but sometimes, when totally disconnected (and I have tried this), Pro just won't do things without getting fussy. You tell me. Geo-processing? Oh. my. goodness. I did attempt a few routines here recently and the outcomes have been horrid (this is on an attempted view shed plain vanilla analysis) - first time, it totally crashed my machine! Seriously. Big time core dump. Assassinated everything and I had to do a hard shut-down the power type restart. Prayed I wouldn't get the "blue screen" = yeah - that bad. The next time, I reduced my AOI - tried it again. Got one of those 9999999xxxx errors - meaning - "Yay! Congratulations! You win the "bug-finder" prize!" essentially - or else there isn't any exception handling for your exception (you exceptional thing, you!). Well, well - this is not new. I find bugs a lot. It's not my favorite thing. I get good and frustrated - but, hey? What am I going to do? I need to get my work done. I need to do the analysis that crashed my machine. I don't have time to now go off and create some alternative script because this out-of-the-box tool does not work. This means that I have to take extra time and I have to go to extremes and be clever to figure out some sort of workaround - all because I "happened upon" a part of this software that doesn't work. Options? Call Esri Support. Do that thing. They do try their best. Good folks. But sometimes these problems that we have with Pro, these stress them to the max. You can hear it in their voices. I try to not get frustrated with them because they are trying and they are on your side. Occasionally, there is an answer, sometimes it goes on a list...and of course, this takes time for someone to figure out and/or find someone to help figure it out if they can't figure it out... and this could take some time. More time that we have. Ticking clocks. Work not getting done. That's the point - we're not out here using ArcGIS Pro or Desktop to have a holiday. It's for work product. So, yes, I sound frustrated. I am. I want to run a 3D analysis and it keeps crashing! I just want to get my work done! I just want this to work and I want it to work BETTER than ArcMap. ArcMap has evolved after a serious number of years whereby users asked for fixes and new functions to be better and better. ArcGIS Pro is a great idea. I think that we are on a curve where we are still watching it evolve and going through that "stuff got left out or stuff isn't well tested" or potentially, the data used for testing isn't what we out here in the trenches are facing each day in our work - we really don't know all the reasons why we are not seeing vast improvements each time. But, each time we do see some improvements. We just want the product and what's inside to work - or else, if there are limits - state them. Since you can do an analysis of your machine's capabilities to run Pro, why not have something that spells out your limitations when you go to run a geoprocessing tool? Using the same "readers" of your resources, why not? Instead of subjecting the user to long processing times, then failures if something overloads or an exception occurs - why not spell out ahead of time that something won't work in a user's given environment. If Pro is tested in a defined environment or different defined environments - could the comparison be made against the tested environment of a user's machine ahead of running a geoprocessing tool? Why not? It's pretty simple to get that info running in a command line - it's not rocket science to compare certain resources to those required to run geoprocessing scripts with certain data and such - all the info is there - and it's meta is all readable. Often we learn during or after the fact that our machinery was not up to the task, or we have to reset parameters - in the Pro documentation, some of this is there and you have to dig to find it - I'm speaking about the CUDA configs and such. Sometimes I believe that we make this more complicated than it has to be, or else the user-perspective is not considered (the real life one, I mean). Pro is a resource hog, that's for sure. If you trace what's going on using your admin tools or some sort of third party tracing tools, you get a picture of lots of things happening - too many to monitor - and the users should not be having to do this on a machine that specs out by analysis (Can U Run It) that says we should be having a great experience. All we want is something that works. So, folks, IMHO, I think that adequate testing by automated testing ahead of this getting into any user-testing, should be detecting the bugs that all the functions might be generating - and then these get corrected ahead of release, ideally. This is possible using simulations of various machine configurations, etc., this much I know. Hopefully, this is happening, but the evidence is that perhaps that needs to be tweaked some, because not all of us are having a great experience. We also have users out there whose organizations will not allow Pro to be used because of it's issues - IT organizations often do their own testing and nix any software that does not meet minimum criteria for their user-machine configurations. If something crashes a machine in testing, for instance, this would not be allowed for an organization-wide push until that gets sorted out. That's a reality experienced in organizations whose IT governance has tight restrictions about software that is run on its computers. How often will Pro pass that test? Even if it does not yield the products required by users in their jobs as quickly as ArcMap - supervisors will just tell people to not use it. Work demands drive use - and simply stated, it must meet those demands in order to be a widely used software suite. ArcGIS Pro is our next generation - as we went from ArcView to ArcMap/Desktop, we are all going to Pro. We do really want this to work in real-life work situations. Our old friend, ArcMap has been a trusty enabler of a lot of great work by people. We know that being 32-bit, the more robust 64-bit new kid will eventually take over. The kinks must be worked out, as they were over the years with ArcGIS Desktop (ArcMap, et. al.). Obviously, we have a lot of issues discussed here in this thread. Fact of the matter is - today - that ArcMap is more stable and more predictable. Sure, sometimes it crashes, but mostly it doesn't cause a user's whole system to crash violently. We would hope that ArcGIS Pro reaches this level of stability and that the resource consumption is optimized to give the best UX - without crashes, without going off into where you're hearing "crickets" and everything goes dim until some undetermined point in the future - or not. My two cents on the experience. Relating back to the original discussion point - yes, we can't do everything in Pro that we do in ArcMap, but we can do some things that we cannot in ArcMap - but, the teething is still ongoing. Pro is not there yet..
... View more
12-05-2019
05:52 PM
|
17
|
9
|
2180
|
POST
|
Oh how I wish I had an old copy of that!!!! Somehow left it somewhere... 😞
... View more
11-17-2019
01:35 PM
|
7
|
1
|
1440
|
POST
|
Dan, we did solve the issue in another post thread you are tagged - We poked around and found that one user's OneDrive WAS showing up. We found on the user machine having difficulty that OneDrive was hidden (learned this by opening the Properties of the OneDrive folder - it showed it was hidden). We unchecked the box - waited for it to go through it's un-hiding paces, then closed the properties. We opened ArcGIS Pro and sure enough - on the user's machine who could not see OneDrive before - after it was un-hidden it is now listed in their folder list. Thanks for your inspiration for us to dig deeper! BTW, we typically do not have issues with OneDrive - we have been using it for a long time, and steadily, it has improved over time - now a standard in Microsoft's Office 365, which also helps our mobile users to be able to work anywhere.
... View more
03-10-2019
12:37 PM
|
1
|
0
|
1969
|
POST
|
After digging deeper, when Dan Patterson responded to me about this access issue, I found the problem solution - not a hard fix - We continued to troubleshoot and explore - in this, we looked into another User's ArcGIS Pro initial folders pane, and OneDrive was present in their ArcGIS Pro file list. We then went into the OneDrive properties in Windows Explorer, again - on the user-machine having difficulty. We discovered when looking at the OneDrive Properties, under General, it showed OneDrive to be Hidden. Could this be the issue? We unchecked the "Hidden" box The files were then un-hidden; it took about a minute or two for Windows to un-hide the folders and files. Then we opened ArcGIS Pro and the user can now see the OneDrive folder. Voila'! Problem solved. We can see iCloud Drive - the DropBox is not installed, but we reckon that we might be able to see DropBox. We will be testing this. For those who have this issue, check this out and see if it fixes the issue. Thanks Dan Patterson for getting our minds to "thinkin' about other possibilities"! #OneDrive now is accessible and we will know how to fix this (fingers-crossed!).
... View more
03-10-2019
12:32 PM
|
0
|
1
|
1944
|
POST
|
To everyone here, considering the higher plane - the UX - since not all users have the system admin skills or capabilities or rights...to do the suggested workarounds with going into the back-end, through the command line... With the newest version of ArcGIS Pro, the clicking and dragging from Windows Explorer does NOT work for the initial access to the OneDrive folder. It DOES work, once you set-up your project and have access to the Catalog - however, the issues related to initially accessing OneDrive are not simple to solve. Since Microsoft and Esri are partners - it would seem that OneDrive, one of the basic storage platforms in Microsoft established several years ago, and widely used by many organizations, would be recognized by this software interface (ArcGIS Pro), as it has been in prior versions - as a set of folders or a link in ArcGIS Pro's user's folder view. Why is it not? Think about it - is this a good thing for users to have to do the workaround? Having to go through all these hoops and hurdles and the user having go out and do system admin re-configuring to make it work? It seems to me that use-ability is at risk here... Furthermore, after jumping through some hoops, and then saving my project to my OneDrive folder (on my local machine), the next time I went to access the project, I got error messages and it could not be located on my local machine's OneDrive folder - I had to go out and download it from OneDrive via a web browser. Luckily, I was able to open the project and suffered no corruption issues. I'll be bringing this up with Support, as in prior versions, we did not see the issue that we see with 2.3.1 - this is a backslide, not an improvement - or else it is a bug, not a feature; Definitely, it is not better for data access for Pro users when their files, projects, etc. are stored in OneDrive (or any other product, actually). After all, OneDrive just a storage drive or path which utilizes both local storage and the cloud - with synchronization. This especially is not enabling mobile workers, where the advantages of offline and syncing to cloud when online are needed. What we do not want users to be forced to do is go back and use thumb-drives, external hard drives, or other means, where they want to back-up and access their projects, data, etc., while using ArcGIS Pro.
... View more
03-10-2019
12:20 PM
|
1
|
2
|
1944
|
POST
|
Hi Dan - Yes, once inside a project - in Catalog - this is true but in the initial interface when opening ArcGIS Pro, it is not - cannot drag the folder into that folder list view. Am documenting this today to send over to support. Thanks for your quick response! Ellen West Nodwell, GISP CEO IntegraShare Dimensions, Inc M +1 832 298 6892
... View more
03-10-2019
11:28 AM
|
0
|
2
|
14032
|
POST
|
Now with the newest version of ArcGIS Pro, the OneDrive folder link has disappeared. Will be turning in a request for investigation to Support.
... View more
03-10-2019
10:39 AM
|
0
|
4
|
14032
|
BLOG
|
Helpful to understand the differences - thanks for sharing this, Derek.
... View more
12-29-2018
02:32 PM
|
1
|
0
|
2187
|
POST
|
If you have ever tried to use the Elevation Profile web app template in ArcGIS Portal - it works somewhat differently from using this in ArcGIS Online. The instructions in the Portal Documentation online do not spell out that first, this service (from ArcGIS Online) must be enabled in the Portal's settings - and that using this service consumes credits. In the configuration, there are options for other services (like Bing Maps - and putting that key into the configuration), and there is discussion about if your Portal is not on a machine connected to the internet - and the links to building a custom elevation profile service are there - but, the instructions are sparse related to AGOL - only after some digging do you discover why it isn't working. When you try to configure this web app using the template, and you don't know about how your Portal is configured - this elevation profile tool may not work - there are no errors - just nothing appears. It means you're not configured to use your ArcGIS Online account's elevation service. Uh oh. Who knew? Let's pretend you are a publisher - no Portal admin rights, or a user with no Portal admin rights, who puts maps and apps together - you don't know what you don't know. You might think it's your map. You might think it is some other setting. You check and try - even look up the documentation - hmmmm... - everything seems right... but it isn't. Still not working. You (the web app maker) might poke around and continue to look this issue up and eventually, after digging enough, you call your admin and say, "Hey - is this elevation service from ArcGIS Online hooked up for us to use?" - and the admin says, "Nah, it consumes credits, so we don't hook it up." Well, you can see how this is going... What is the user who is trying to build this app going to do? Probably walk away, right? Go look for some other app template that works for the purpose or go do something else in the in-basket. This is unfortunate, because within these web app templates - people have put in a lot of time and work to build for sharing to everyone so that they do not have to invent these from scratch. It's the beauty of Portal and AGOL, both, enabling people to put together apps without being a developer! Mapping apps for everyone! But, when using these does not give the intended result - this can cause a great app to never be used again - word gets around... So, what's the answer to enable better use of some of these brilliant tools that people have worked hard to put together for Portal users? Better documentation, I would say, could be a start - I would love to hear from some of you out there who have used (or tried) some of these web app templates - Some of these are truly awesome for quick app building - they make beautiful apps with your maps - and everyone hopes that they will get used... For example, I use this elevation profile app on my own ArcGIS Online site and love it - also love the compare 4 maps of the same place as they sync and interact - that one is very cool. I submitted some feedback. Do you do this? Thoughts?
... View more
10-05-2018
01:10 PM
|
2
|
1
|
1116
|
Title | Kudos | Posted |
---|---|---|
1 | 03-10-2019 12:20 PM | |
2 | 10-05-2018 01:10 PM | |
1 | 10-14-2022 08:13 AM | |
1 | 07-05-2022 02:12 PM | |
2 | 06-27-2022 02:43 PM |
Online Status |
Offline
|
Date Last Visited |
07-06-2024
01:25 PM
|