Latest Contributions by daveostrander

Hi Michael, just tried editing the web.config file using your supplied code. The only thing I changed was to change the time frame from 1 day to 5 minutes, and didn't seem to have any luck when using Chrome. It's possible I put the code in the wrong spot, in this case, within the staticContent tags. I tried a couple of other places, but that ended up breaking the application entirely. Since there is not that many spots to put it, is there something I am missing? ... View more

I have a stand alone ArcGIS Server (currently not federated), and this issue is still occurring in web maps hosted on AGOL that consume map server level map services from my stand alone ArcGIS Server. Obviously, the install was immediately applied on Esri managed AGOL servers, yet the issue remains. Is there some other reason why my web maps might still be affected by this issue? ... View more

I spoke with Ismael Chivite‌ this past spring about adding this type of functionality to Survey123. No promises were made, but there was definitely an effort made on his part to fully hear out and explore the idea, which I am entirely thankful for. A company called MyScript has developed an SDK called Interactive Ink that is advertised to effortlessly convert handwriting to text using supported devices and active pens (i.e. iPadPro and Apple Pencil). Interactive Ink's selling points are: easy sharing, easy backup, search, input/result cleanness, flexible editing, dynamic space management, machine-understandable and fully exploitable, and operating system portability. There is also an app developed by MyScript called Nebo (paid app), but maybe it could be used in conjunction with your workflow (using a copy and paste method, export as an attachment, etc...). Obviously, it would be ideal if this functionality existed natively within Survey123, but I haven't received any updates on that, which reminds me... Hey, Ismael Chivite has there been any progress/decisions made on this yet? ... View more

I encountered the same error message when attempting to configure Portal to use our enterprise active directory identity store. In my case, it was a simple syntax error in my user store configuration JSON. For the user parameter, make sure you use a double backslash (i.e. "mydomain\\winaccount"). If you use a single backslash the Portal identity store configuration will fail, and return the error above. See entire JSON example below for further context. {   "type": "WINDOWS",   "properties": {        "userPassword": "secret",        "isPasswordEncrypted": "false",        "user": "mydomain\\winaccount",       "userFullnameAttribute": "cn",        "userEmailAttribute": "mail",        "caseSensitive": "false"      } } ... View more

If you were following the upgrade documentation then you likely saw that the command line syntax listed in the help for the old version states, "Your previous version of the Web AppBuilder installation directory is similar to C:\arcgis-web-appbuilder-1.0". If you use this path you will receive the invalid path error. Try using C:\arcgis-web-appbuilder-2.7\WebAppBuilderForArcGIS instead. ... View more

Scott, thank you for your reply! Essentially, we would use this anywhere we have comments/notes fields that require more than a short sentence of text, or in places where annotating directly on a photo or image would be useful. While this is not reserved to a single workflow/project, an example that comes to mind is building inspections. Our building inspector often needs to meticulously explain why a contractor has failed a building inspection, and layout what corrective actions will be needed to pass the next inspection. Similarly, having the ability to take photos on the job-site, and then marking them up to better point out the problem areas would also be useful. You can visit this older ideas post that talks about roughly the same type of workflow: Add Support for In App Writing Using Collector for ArcGIS and iPad Pro  ... View more

Hi Kevin, that behavior is expected since your url scheme is calling the mobile application, and not an http:// address. ... View more

Great article!!! This has been a sore spot in our field for sometime, and getting to the root of it in a single degree program is not exactly easy, or for that matter cut and dry. We are essentially talking about how to package two distinct fields, computer science and geography, into one. Unfortunately, both fields are extensive, and attempting a kitchen sink approach could lead to poor coverage overall. I think the hard reality we all need to accept as modern day GIS professionals is to stay hungry, and commit to being life-long learners. Honestly, the technology requires this anyway. I am not arguing against a healthy dose of computer science in geography curriculum, instead I am advocating that we all be a bit more realistic. I think a great idea that university geography programs could adopt is the notion of nano degrees for GIS development tracks. Package up 3 to 5 courses specializing in various GIS development functional areas (i.e. big data specialization, web development, GIS tool/software creation), and offer them as ancillary certificate type programs. That way students will start with a more traditional style graduate program that includes some of the computer science elements (i.e. a GIS based python course, introductory cloud computing, or intro to using an API), and then can optionally go back for a nano degree that specializes in building on those skills. I think this approach would go a long way to providing students the deserved time and attention these skills require to learn. If done correctly I am willing to bet that the future outcomes of this survey would render vastly different results. UW-Madison has an online M.S. degree geared toward GIS and web map programming. That is a good start, but for someone who already has a MGIS degree it is still a tough sell. Hopefully in the near future they, or institutions like them, will break that MS degree down into a slew of bite sized post-grad GIS nano degrees. ... View more

Thanks Again James, All of my data exactly matches what you have outlined above (GlobalIDs and GUID fields for relationships, offline data preparation for both the sde data, and the published feature service (i.e. sync checked). However, when I tried to connect to my related table layer and publish in Survey123 in playing around with the different options available I got either a submission_url error, or a "this table not compatable" error. I do have a case open with Esri technical support, but so far we haven't progressed too far. Hearing that you think this setup is possible is a huge relief! After today I had begun thinking I would be waiting for the smart form enhancement to be made available in Collector. Aside from theoretical hypotheses, have any of the Devs, or product teams successfully accomplished what I am trying to create here? ... View more

Hi James, Thanks for getting back to me on this! I probably should have been a bit more specific on what I am trying to accomplish. In my use case scenario I am trying to replace paper based building inspection forms using a combination of Survey123, web maps, and Collector. I have seen that you can create surveys off an existing dataset (shown here). However, when I attempt to publish the survey I receive an error, which informs me that the schemas don't match (i.e. The custom feature service is not compatible with this survey (Field "Field Name" not found in "Layer Name"). At any rate, I really don't want the schemas to match, instead I want the surveys to act as related tables to the feature service I am attempting to connect them with. What I am really after is to have a feature service that contains it's own separate attribute data (some of which, say a GlobalID that could be transferred to the survey data so that the relationship works), and then have multiple related surveys that contain their own separate attributes (either many different surveys, or a single survey that uses logic to hide/show fields based on a user's answer to a preliminary "survey type" question at the top of the survey). To illustrate this point let's use building inspection data as the example. In this scenario a single building permit that gets issued may require multiple different building inspection site visits (rough, roofing, plumbing, electrical, finishing, deck, pool, etc..). The process all begins with a building permit that would be created in the office by staff using an ArcGIS Server hosted feature service. The permit feature would have some basic kinds of information stored within it like you would encounter on a one page building permit form. This data may also have attachments like architectural plans, and a scanned copy of the signed building permit itself. The building inspection data that will then need to be collected going forward, is on the other hand far more complex, which really lends itself to using the Survey123 UI in order to fill it out. However, each inspection will happen on different days over the course of the build, each phase of the inspection will require entirely different forms, and because not all builds are the same (house, fence, pool, deck, addition etc...), not all of the inspection forms will always be used. When I envision this process working in the best possible way I return Jeff Shaner's Collector post, where he discusses "what's the big deal about 'Related Tables'". In this scenario a building permit represents the origin layer with related tables representing each survey type (see graphic below (visually substitute the hydrant for a house)). Given the complexity of some of the building inspection forms, using Collector to collect this sort of data would be a rather maddening user experience (tens of drop downs options, fields that are not required unless certain questions are answered, and so on). Additionally, this kind of table orientated data is not so easily digested by contractors or homeowners, which is why the Survey123 forms provide such an enticing UI. Is this sort of related record data schema possible by integrating a feature service with Survey123? ... View more

Any updates on this? I am currently working in the weeds to get this realized. I have posted elsewhere on this, but to reiterate here, ideally we would have a solution that does it all. The reality is that data is often both map centric, and form centric at the same time.  Here is what I am imagining: A feature service with its own set of attribute data, related (1:M) to a table containing survey123 data. The idea would be that directly from Collector you could fill in attribute data on a feature service then add one or more related Survey123 form(s) to the feature service. Users would have the nice experience of filling out the form data using the Survey123 UI, but know that once the survey is published all the data (FS attributes, related surveys, and associated attachments) are connected into a single feature service. That feature service could then be consumed by, viewed, edited, or exported in any web map. Right now it seems like every application (Workforce, Collector, Survey123)  is somewhat integrated (URL schemes), but each is creating its own disparate datasets. Maybe I am missing something integral... still working my way through it.  ... View more

Should have kept reading   . So to be clear, setting up primary and foreign keys (i.e. auto populating GlobalIDs) will ensure a relationship between my feature service and related surveys? ... View more

Call me anal, but I would love to see a single feature service that has related surveys. In example, create points via a desktop web mapping application (Web AppBuilder), open Collector and navigate to said points with Navigator, arrive at destination and return to Collector, bring up point attributes and launch a related survey123 form record, fill out the form using drop downs, radials, etc..., attach images, fill out notes/comments sections using a stylus (i.e. Apple Pencil) and then attach as another image, immediately send completed survey form to a recipient as a PDF via email, return to Collector, and launch a second related Survey123 form record (rinsing and repeating as necessary), return to office and view everything from a single feature service on a web map. As a bonus have workforce be treated as related records too!  Related records to keep everything connected to a single feature service. Voila the perfect set up!  ... View more

Renato, I think you have a great idea here! You should up vote it!!! ... View more

This is definitely something that would be highly useful, while also making the process more efficient. Take this use case scenario as reasoning why it would be useful: Say you have a survey for building inspections, and you would like your building inspector to perform the inspection in the field, and then give the contractor/home owner an electronic receipt of the inspection results. Being able to email the survey inspection directly from the Survey123 application would give both parties immediate gratification in a simple and seamless way. ... View more