POST
|
That is exactly my problem. Having worked with ESRI software for almost a decade at this point, I was privileged enough to go to school and work in places with a full suit of Enterprise capabilities (as large organizations). Now I find that I have to MacGyver/ hodge-podge almost half of the work I do at my current job because I can't by default do certain things with ESRI; I find myself having to go to open source software, or more recently, start venturing into the Developers world just to see what I can do with my Python/Java/JavaScript know-how to get our projects off the ground. Which is a great step, thoroughly interesting, and I would encourage anyone to look into .... but like most people I don't have the luxury of spending my days at work learning code and how to apply it because there is 10 years worth of GIS work to do sitting in the company vault that is entirely my responsibility. Which means I have to do it at night. I don't have a family or kids so after hours works okay, but now I'm putting in 60 hrs a week just on my career. Just for the chance of finding a better way I know its a privilege you pay for but it strikes me that even outside of packages you can purchase to augment your license, or access to mobile capabilities that are included, there are simply things that will only work/ work better with, or problems that only have reasonable solutions through/ or ultimately end up requiring access to, Enterprise.
... View more
01-06-2017
10:14 AM
|
0
|
0
|
231
|
POST
|
Is there any word from ESRI on this issue? As of January 2017 this is still an ongoing and completely frustrating issue for myself and for our field crews (who rely on this technology to keep water flowing to almost 100k people). Might I suggest that if Collector wishes to only allow us to view device-based maps without without "glitching a fit", that we get the functionality to side load .mpk/.mmpk's to our mobile devices via MicroSD cards and avoid the issue entirely? Kylie Donia Brent PierceCollector for ArcGIS ArcGIS Online https://community.esri.com/groups/mobile-gis?sr=search&searchId=a07a6565-1b6c-4deb-98a9-0c5dbcd67cee&searchIndex=0
... View more
01-06-2017
09:32 AM
|
0
|
0
|
1230
|
POST
|
Hi Kylie - do you know where on ESRI's roadmap this is going to be (ex. first half of 2017, July next year, etc)? Pretty important to companies trying to run collector on less-expensive platforms with minimal upgrades to memory
... View more
12-16-2016
07:12 AM
|
0
|
1
|
585
|
POST
|
Hey Brenda (et al.) - I know this won't help you right now, but I logged an idea through ESRI to make information regarding open bugs available directly through the ArcGIS Resource documentation online after a similar issue. In the interest of all I'm trying to get more visibility and more votes up on this one. I have legitimately wasted days of time waiting to hear from ESRI just so they can tell me that yes there is a bug, and here are the work-arounds that have been developed. https://community.esri.com/ideas/11858?commentID=37416#comment-37416
... View more
10-03-2016
09:13 AM
|
1
|
0
|
1028
|
POST
|
Hi Jason - We just finished our yearly hydrant inspections here (and are moving on to our ARV Inspections); while I can't give pointers on Workforce (we're in the beta but unfortunately I haven't had to time to test it out and get all my other work done 😕 ), I think I can shed some light on the question you're asking. I had a conversation with ESRI support regarding this at one point and as far as I understand it, right now there is no way to call data from your feature service into your related table. This was counter-intuitive to me that this was not available because two objects stored in the same place that are already talking to one another through a relationship -SHOULD- be able to pull data from one into the other. In our case, I wanted to pull our internal Hydrant ID numbers from the feature service into the related Hydrant Management Table so that when I viewed the related records, I could tell within AGOL which hydrants required repairs. We used GlobalIDs and GUIDs to create the relationship rather than based on the Hydrant ID numbers to avoid any relationship issues. In order to work around this, our operators were required to copy the ID # from the basemap labels I included in our custom basemap into new management records so we could quickly find records related to hydrants needing repairs as they came in from the field. The only way to both see related records easily and edit them was to dual-wield AGOL via desktop and Collector via tablet so you can immediately see related data and edit it. Other than these crude work arounds, the only way to see the related records is to download your data from AGOL and perform a "Make Query Table" in ArcGIS Desktop (only way to join the two tables with a 1:M relationship). However when you have thousands of features in a feature service, and occasionally multiple records for each feature, this download can take a while ... quite often in the business of emergency assistance infrastructure like a fire hydrant, this is a lot longer than questions requiring immediate attention can be left unanswered. IMO, part of the problem here is that when you click on a feature in a feature service within AGOL, it doesn't offer you the ability to see the related records associated with that point in the primary pop-up. In order to see that instantly, you must also have collector open in front of you. While I did find that filtering the features and related table by edit date I could narrow down the data I had to sort through, this was imperfect (due to user error such as forgetting to re-symbolize hydrants from requiring inspection to complete or requiring maintenance/repairs, or accidentally moving our hydrant points around while editing). Hope this helps.
... View more
03-07-2016
06:58 AM
|
1
|
0
|
323
|