Latest Contributions by PaulHaakma

‎12-01-2020

Hi @TanuHoque Thanks for merging and tagging me in this thread. Yes I think this discussion is relevant to my question so I will keep an eye out for the upcoming changes and review them to see if they help with our use cases. cheers, -Paul @DeanPetricevich

‎11-24-2020

Using ArcGIS Pro v2.6.3 and ArcGIS Online. We have noticed that, when updating date fields, the raw date that ends up stored in the feature service is different depending on whether the method used to enter the date was Pro vs other applications. When we update a date using the standard ArcGIS Online map viewer or Collector, the datetime picked will be in our local timezone (happens to be Auckland, NZ) and the date is converted and stored in UTC time (currently 13 hours behind) which, to us, is correct and is what we expect. However, if the same datetime is entered via Pro, this is stored directly as-is into the database. Meaning the stored date, when compared to the other UTC times, is 13 hours ahead of what it should be. The answer according to several blogs and Geonet posts appeared to be to set a timezone when publishing the feature service. We tried this by publishing a new test service, but it made no difference. To try and understand this, we examined the REST endpoint JSON and observed that the feature service had the following set in the service definition: "dateFieldsTimeReference" : { "timeZone" : "UTC", "respectsDaylightSaving" : false } This seemed unusual, since we had specifically set a timezone in Pro before publishing. We tested publishing several more feature services, sometimes specifying a timezone and/or different timezones and with daylight savings ticked/unticked, but every time the JSON says the timezone was UTC and respectsDaylightSaving was false. We then tried manually updating the service definition using the admin rest endpoint. We weren't able to find any documentation about what values should be set in place of "UTC", but we at least tried setting "respectsDaylightSaving" to true. No error message was reported when updating the definition, but when we examined the JSON of the service definition afterwards, it was still set to false, so nothing had actually updated. In summary, currently whenever we enter a date using Pro, it ends up 13 hours out. The only workaround is to tell users not to update the dates in Pro, or else manually enter a time 13 hours in the past. Publishing with a timezone either does not work, or we are misunderstanding how it works. Does anyone have any suggestions?

‎09-03-2020

Thanks Luke. Knowing that 'strftime' was the issue, I went back and relooked at creating the query string. Essentially I was manipulating the field data before comparing it. So instead I left that as is and converted the comparison date to the same format. The field data is stored as a Julian Date, so I googled a function to convert a javascript date, injected that into the query and now I have it functional. The convert to Julian function I took from here: Calculating julian date with javascript - Stack Overflow function toJulianDate ( date ) { var floor = Math . floor ; var y = date . getUTCFullYear (); var m = date . getUTCMonth () + 1 ; var d = date . getUTCDate () + ( date % 8.64e7 ) / 8.64e7 ; if ( m < 3 ) { y -= 1 ; m += 12 ; } var a = floor ( y / 100 ); var b = date < new Date ( Date . UTC ( 1582 , 9 , 15 ))? 0 : 2 - a + floor ( a / 4 ); var c = floor ( y < 0 ? 365.25 * y - 0.75 : 365.25 * y ); var e = floor ( 30.6001 * ( m + 1 )); return b + c + d + e + 1720994.5 ; } and my SQL query is now: `proposedRevisitDate >= ${toJulianDate(plannedRevisitDateFrom)}` cheers, -Paul

‎08-30-2020

I have a map, taken offline from a webmap in ArcGIS Online. There is a layer in it with labels enabled. The label is fairly simple, just labelling off a single field. The labels display fine on the map. Until, that is, I apply a very specific definitionExpression to the layer. I can apply various different definition expressions and the labels continue to display fine. But if I try this particular expression the labels disappear: "(CAST(strftime('%s', proposedRevisitDate) AS integer) >= 1501545600" In this example, 'strftime' should take the value found in the 'proposedRevisitDate' field and return it as seconds since 1970, which should then be CAST as an integer, and then compared to the number on the right. The SQL expression does appear to resolve ok, as the map layer is successfully filtered to the expected features. The only weird thing is that suddenly the labels disappear. If I remove the definition expression, the labels reappear. I have checked that layer.labelsEnabled is always true which it is. I have checked that the label definition list model has a label definition, which it does. In other words, nothing seems to change regarding the actual labels. I'm at a loss to explain why setting a definition expression should affect the display of the label. Any ideas? Cheers, -Paul

‎08-28-2020

I realise this one might be a bit hard to follow, so here is a link to a short 34sec video showing what I mean... AppStudio - GeoPackage new features no displaying - YouTube

‎08-27-2020

I am using the QML api. I load a GeoPackage into a feature layer and successfully load it onto the map and can see the polygons contained in the feature table on the map. While the app is still open, I also open the GeoPackage up in Pro and add a new feature. If I add the feature 'within' the current extent of the layer, a simple zoom in or out back in my app refreshes the layer in the app and displays the new feature at all map scales. However, if I try to add a new feature 'outside' the current extent of the layer, the new feature does NOT appear, unless (for some weird reason) I zoom waaaay out. If I zoom out far enough (and I've drawn a big enough polygon that I can still see it at that scale) eventually the new feature pops into view. But if I zoom back in it then disappears. So, I know that the new feature has successfully been saved within the GeoPackage database itself, and must be present in the corresponding GeoPackageFeatureTable. But I'm not sure what's going on with the layer and the map itself. Is there someway I can force a refresh of the layer extent? Or any other suggestions on what might be going on? I tried playing with the renderingMode and setting it to Enums.FeatureRenderingModeDynamic, but then I got some weird results where sometimes the new feature appeared and sometimes not and I couldn't pin down a pattern.

‎08-22-2020

Read up on GridLayout which allows you to specify the maximum number of columns GridLayout QML Type | Qt Quick 5.15.0

‎08-22-2020

Do a google search for "qml layout" and you will see there are several layout types. You are using ColumnLayout which is why they are displayed in a column. Try RowLayout or GridLayout for different options.

‎08-06-2020

Is there a reason feature collection and kml layers don't have label definition properties in the QML api? Is there any way to label layers of these types?

‎08-05-2020

Good point about server, I'll try frame up a bug report (maybe more of a 'feature enhancement'). I forgot to mention that I was working with offline data, so interacting with a local geodatabase and the qml api only, although that doesn't change much I guess.

Online Status	Offline
Date Last Visited	‎12-01-2020 01:25 PM

My Ideas

Latest Contributions by PaulHaakma

Re: Time zone toggle in ArcGIS Pro

Can't publish feature service with timezone

Re: Definition expression makes labels disappear

Definition expression makes labels disappear

Re: How to refresh feature layer extent

How to refresh feature layer extent

Re: How to show Images In a row using repeater in qml?

Re: How to show Images In a row using repeater in qml?

Label definition on feature collection or kml layer using QML api

Re: attachmentlistmodel updateAttachmentWithIndex behaviour

Web AppBuilder Custom Widgets

Cloud Computing