Latest Contributions by TeresaBlader

Allow users to select time zone when appending data so it is not automatically correcting for UTC and distorting the date data when appending feature layers and stand alone tables. This function would be the same as when creating a feature layer or table where you can select the time zone in the drop down. This would also be helpful when appending in Pro as well instead of just when overwriting.  As is, you can create a table, select the time zone, and the date data will appear at least with the correct date and with a time stamp of 12AM if not provided. However, when appending after creation, the date data displays as subtracting or adding the computers time zone from UTC. Ideally, it would be nice to be able to have the options of telling the data display "as is" in the data base instead of correcting for a time zone at all or prevent it from assuming that data is in UTC before appending. Or even adding a time stamp... but at least as the same date. If I say 12/28/2020, I want the date to say 12/28/2020. Not 12/28/2020 12:00:00 AM, not 12/27/2020 6:00:00 PM... just 12/28/2020, however saying 12/28/2020 12:00:00AM is fine. Updating the Definition to the appropriate time zone before or after appending does not do anything. It's like the current append to is set to overwrite the current database from whatever time zone to UTC.  I can appreciate the helpfulness of wanting AGOL to do auto display calculations for all the reasons Esri gives, but then it seems to reason that having the option to not have auto calculations would be helpful as well. And from reading the forums and blogs, it sounds like the cry of many AGOL user's hearts.  ... View more

Anyone have experience trying to integrate the CLUE-S Model in ArcGIS for land use/land cover changes/predictions? Looking for tips/instructions/videos on how to get started.  ... View more

We (Myself and Hannah Hutchins) are trying to use the Crowdsource polling application, but are getting a little lost when it comes to building the relationship class in Catalog between the feature class and the table that will house the comments. Our end goal is to collect comments using the web app template where public citizens can open the template, select the polygons, and add comments.  Right now in our feature class containing the 30 polygons that we want public feedback on we have a field called comments (among other attributes). My understanding is that I create a table in the .gdb that will house the comments, and then build a new relationship class between the polygons feature class and the table. These are the steps and questions that come up as I work through building the new relationship class. If someone has an example of a similar successful crowd source polling map relationship class output, that would be helpful. My origin table is the poly feature class (LRTP_PComm) attribute table and the destination table is the new comment table (LRTP_Comm). This relationship type would be composite? Each polygon will have multiple comments. If the polygon is deleted, then yes, we don't need the comments as they only pertain to the polygon they were commented on. Direction: It is a forward relationship because the user would be clicking on the polygon and entering a comment, but not the other way around? Or is it both because comment history can display in the web app? 1 -M: It is one to many because each polygon can have multiple comments? Or is it 1-1 because each polygon in the feature class will have its own set of comments?  Do I want to create attributes in this relationship class for these comments? If so, what would they be? Is this where you would store the names of the commentors? Is this where vote tally's should be counted or is that in my feature class attribute table? The output: Name: LRTP_PComm Origin object class: LRTP_2045_Poly Destination object class: LRTP_Comm Type: Composite Forward Path Label: LRTP_Comm Backward Path Label: LRTP_2045_Poly Message propagation: Forward (origin to destination) Cardinality: 1 - M Has attributes: No Origin Primary Key: OBJECTID Origin Foreign Key: OBJECTID crowdsouce pollling‌ relationship-class‌ arcgis-online‌ web-app templates  ... View more