Latest Contributions by JosephMootz1

‎08-31-2016

We use iOS on iPads. Unfortunately, we cannot share the map. Our users noticed this issue in the field. To reproduce the problem we followed these steps: 1. Set up a map with an editable layer. 2. Set the refresh interval of the editable layer to 1minute. 3. Open the map in Collector and add a feature. 4. In Collector, edit the feature then: a. Change a value of a field in the feature and press Done. Do NOT press submit. b. Wait until the minute on the time on the iPad increments by 1. c. Change a value of another field and press Done, the value of the previously edited field reverts to its original value. I hope this helps.

‎08-31-2016

We just discovered the same issue and are going to try the same work around of 5 minutes to see how it works. We've been using Collector for over two years and never noticed it before. However, most of our users use an offline version of a similar map in which the issue doesn't appear since you have to sync to get the updates to the features. I agree this seems to be a bug with collector and will report it as so when I get the chance.

‎05-11-2016

I like it. We are thinking of doing something similar with the short list story map. We use the Robert Scheitlin, GISP? Google Street View Widget 2.0.1 - 04/21/16 in our WAB apps and it works great. thanks for posting this.

‎05-05-2016

This is an issue with projection. The web map is using Web Mercator spatial reference so planar measurements are distorted as you move away from the equator. Although we have our own Non-Tiled basemap for which we can use a different projected spatial reference, we also allow use of ESRI's tiled basemaps. We could set our map and basemap to a projected spatial reference, but then the ESRI basemaps are not listed in the Basemap gallery widget. The ESRI Javascript api functions map.setScale(), map.getScale() , map.extent all use the map's Spatial reference, i.e. Web Mercator . So when we set the scale to 600 using map.setScale(), planar lengths are off by a factor of the ratio of the extent in map units to the extent in planar units. We did some math to get the correct scale to set the map at so that measurements on the monitor match the physical world, i.e. 1 inch on the monitor = 50 ft in the physical world, but that affects other widgets like the coordinate widget and printing widget and it does not seem like a robust solution. Also, the issue with monitor projection is not as important as with printed maps. The simple solution for printing is to force the PrintTask's out spatial reference to a projected spatial reference by modifying the code in the print widget as follows: this.printparams.outSpatialReference =new SpatialReference({ wkid:2914 }); So for now, this issue is resolved for us until we can find a way to have a the web map in a spatial reference other than Web Mercator and still have the Basemap Gallery allow access to ESRI's basemaps. Some helpful related blogs are below: Measuring distances and areas when your map uses the Mercator projection | ArcGIS Blog GeometryEngine: Testing spatial relationships and editing | ArcGIS Blog

‎04-30-2016

What is the best way to ensure web maps display to scale correctly on screen and when printed to match physical measurements? Our customers need to be able to create and print maps to scale. So if the scale is 1:600 for example, 1 inch on the screen map and 1 inch on the printed map represents 50ft in the physical environment (1in:50ft = 1:600). We have a web app with a featurelayer for a basemap so we can zoom to scale without being limited to the LOD settings of a tile basemap. We can set the scale to 600 using map.setscale(600) in the ESRI Javascript API, then draw a 50 foot line on the map to match 50 ft in the physical world. The map.getScale() confirms the current scale of the map. But, the line measures approximately 1.375 inches on the screen and 1.5 inches when the map is printed. If we set the scale to 800, the line measures 1 inch on the screen as it should for a 1:600 scale. If we force the scale to 900 when printing, the printed map measures 1 inch as it should for a 1:600 scale. We have done some tests for other scales and it seems the setscale and getscale functions are off by a factor of 4:3 on the screen and 3:2 for the printer. Do we need to adjust for aspect ratio for the map.setscale() and map.getscale() functions? If so, is the adjustment hardware dependent? I don't know if it is a coincidence but esri's GIS dictionary defines aspect ratio as "[hardware] The ratio of the width of an image to its height. The aspect ratio of a standard computer monitor is 4:3 (rectangular)." This is a public app, so not sure if the aspect ratio of 4:3 would work on all monitors or would need to be adjusted for individual monitors and how to do that. We tried calculating an extent based on the scale and using setExtent instead of setScale based on this technical article (http://support.esri.com/fr/knowledgebase/techarticles/detail/23278) but had the same issue. We calculated the Map Scale Factor = Reference Scale / (ppi * constant), but it seemed like we still needed to adjust by 4:3 for the extent on the screen to match the expected physical measurement . Any help is appreciated.

‎12-09-2015

Hello Miaogeng, Any update on the new release of Collector for iOS? I noticed the Windows 10 version was released on December 7th. We are really interested in seeing how the "Ability to configure photo resolution (iOS platform)" works. We are having issues uploading photos larger than about 4mb. The uploads seem to timeout after about two minutes with a message "Update Failed. Attachments could not be sent." I don't know of a way to tell whether this is an issue with the Collector app, the iPad or with the data communication systems. We are using cellular communications from the field which can be spotty at times but it seems to timeout sometimes even with good coverage and with wi-fi. Thanks for your help.

‎11-20-2015

Thank you for this great widget, Robert. You've done fantastic work and we appreciate it.

‎11-19-2015

Hi Robert, We did some troubleshooting and found that there is one line in the _getLayerInfoWithRelationships function in the Widget.js file that we changed and resolved our issue with related tables. There are 4 resolve statements toward the end of the function as shown below: def.resolve({state: 'success', value: layerInfo}); }), lang.hitch(this, function (err) { def.resolve({state: 'failure', value: err}); })); def.resolve(layerInfo); }), lang.hitch(this, function (err) { def.resolve({state: 'failure', value: err}); })); return def; }, If we change the one underlined above to match the same pattern as the others as shown below, the related tables seem to work in esearch. def.resolve({state: 'success', value: layerInfo}); It looks like the state attribute was missing from that one statement. I hope this helps.

‎11-19-2015

Any word on when the November release of collector will come out. The ArcGIS Online release happened overnight on 11/18/15 and this link (What’s New in ArcGIS Online (November 2015) | ArcGIS Blog ) describes the updates to Collector, but the AppStore and Collector Help site (Collector for ArcGIS | ArcGIS) still have the October release. I am really interested in seeing how the "Ability to configure photo resolution (iOS platform)" works.

‎09-11-2015

Thank you for this response it was very helpful in trying to understand what is going on. I found the place in the synch.js code where the timezone offset is subtracted from the date during the download process. I removed the subtraction of the timezone from the line below and the dates seem to be kept in synch. // Convert from milliseconds (epoch 01-Jan-1970 UTC) to days (epoch 30-Dec-1899 Localtime). fieldValue = 25569.0 + (fieldValue / 1000.0 / 60.0 - (new Date()).getTimezoneOffset()) / 24.0 / 60.0; The timezone offset is also subtracted during the upload process, but it does not effect synchronization of the dates. // Convert from VARIANT time to UNIX time. fieldValue = fieldValue - (new Date().getTimezoneOffset()) * 60.0 * 1000.0; It appears to me that the ArcPad date and time is stored as local database time (days (epoch 30-Dec-1899 Localtime) and the ArcGIS server date and time are stored as UTC date and time (milliseconds (epoch 01-Jan-1970 UTC)). During the upload portion of the synch process the ArcPad date and time is converted to the ArcGIS Server format by subtracting the timezone offset. So if I have a time of 15:00 in ArcPad it still appears as 15:00 when uploaded to ArcGIS server. If I try to synch again, the timezone is subtracted from the ArcGIS Server time during the download process. On the west coast this results in 7 hours being added to the time making the time now 22:00. On ArcGIS Server the EditDate is in UTC Time, so there is no need to subtract the time zone offset when downloading to ArcPad. With the original code, 7 hours were subtracted from the EditDate, so that a feature edited at 22:00 on ArcGIS Server gets downloaded with an EditDate time of 15:00. So when the synch process is tried again, the EditDate on ArcPad is always 7 hours earlier than the EditDate on ArcGIS server so the feature always appears out of synch. I am still not sure if I have this all right. I have not had a chance to double-check all the calculations but I think they are right. Basically, if a date and time are recorded as local time on ArcPad I would like the same value for date and time to appear in ArcGIS Server, 15:00 on ArcPad = 15:00 on ArcGIS Server. If ArcGIS server records a date as UTC, it should still have the same value when downloaded to ArcPad otherwise there is no way to tell which features need to be synchronized. The solution for me seems to be to remove the subtraction of the Timezone offset on the Download.

‎09-10-2015

I have an ArcPad 10.2.2 app that synchronizes with an ArcGIS Server using a feature service. It works fine without Editor tracking enabled and with Downloads Suppressed. I have set it up to use Editor Tracking, but there is a discrepancy in how ArcPad handles the Edit Date field. This field is in UTC time on the ArcGIS Server. During the synch process this field gets converted to local database time in the ArcPad .axf file. Therefore, every record is downloaded for every synch process because the time zones are different between the ArCGIS Server REST Service and the ArcPad .axf file. I understand the REST service requires the use of UTC time and that cannot be changed. I have verified that by changing my local computer time to the UTC time zone the synch process works as it should only downloading records that have changed. I notice that the same conversion happens going from ArcPad to the ArcGIS server with other date fields. I have date fields in ArcPad that when synched to the ArCGIS server are different by 7 hours from what they are in the .axf file. Is there a way to set up ArcPad to use UTC time instead of local database time? We do not use a GPS unit with this application.

‎07-29-2015

I cannot seem to import some of the WAB apps from ArcGIS Online to my the WAB Developer Edition version 1.1. I believe I could do this before the latest release of the ArcGIS Online edition. If I try to import a ArcGIS Online WAB app which has been saved after 3/1/15, I get the following message: Failed to upgrade app! Please refer to the log for details. I checked the \server\logs\appbuilder.log but there are no new entries corresponding to the time I tried the import. Is this a recent development from the latest ArcGIS Online update? If so, will a developer edition be released so to match the ArcGIS Online edition?

‎07-29-2015

Are there plans to update the web App Builder developer edition to include the new features of the recent ArcGIS Online release, including the new themes and search widget updates? If so, when can we expect the updates?

‎03-11-2015

Editor tracking is enabled on the geodatabase Feature Dataset. This will add the necessary fields to the feature classes for editor tracking .When features are created or modified the editor tracking fields are updated automatically. The following links describe the setup for 10.2. About tracking an editor's changes to data Enabling and managing editor tracking

‎03-06-2015

Thanks for the follow up. We are using desktop ArcPad 10.2.2 on a Windows laptop device. The Synchronization works fine without editor tracking enabled, although functionally it downloads all records every time since there is no Edit Date to tell what has changed, i.e. we get the "Incremental downloads not available.." message. We have a lot of records so we Suppress downloads to disable that function and keep the synchronization time to a minimum. When Editor Tracking is enabled, it seems that the first time we try to synch it deletes all records in the axf. Then the next time it downloads all records from the server and adds them back in to the axf. Messages from subsequent synchronizations indicate all records are edited. This seems to be the most consistent behavior.

Online Status	Offline
Date Last Visited	‎10-12-2021 03:58 PM

My Ideas

Latest Contributions by JosephMootz1

Re: Refresh Interval

Re: Refresh Interval

Re: Google Street View Button

Re: Scale vs Physical Measurement on web apps

Scale vs Physical Measurement on web apps

Re: Collector November 2015 Release

Re: eSearch widget and related tables

Re: eSearch widget and related tables

Collector November 2015 Release

Re: Set up ArcPad to use UTC time instead of local database time

Set up ArcPad to use UTC time instead of local database time

Import From WAB ArcGIS Online to Developer Edition

Update WAB Developer Edition to ArcGIS Online release

Re: ArcPad 10.2.2 Feature Service Fails with Editor Tracking Enabled

Re: ArcPad 10.2.2 Feature Service Fails with Editor Tracking Enabled

Re: eSearch widget and related tables

Re: Set up ArcPad to use UTC time instead of local...

Re: "Geocoder" in "Tab Theme"

Re: "Geocoder" in "Tab Theme"

Re: collector map download failed