Latest Contributions by Jay_Gregory

Thank you Vince - I am onboard 100%.  I always took for granted that native geometry types are required.  My challenge is convincing other people (namely DBAs who have little to no spatial experience) of the same.  They store polygons as geojson representations in a string field.  It makes zero sense.  And the geojson doesn't even conform to spec.  I'm just trying to make a case for point data with a lat / long column, since like I mentioned I can create a query layer or database view, publish a feature service on top of it and get access to the same geospatial queries.  Unfortunately I was raised on esri geodatabases, so dealing with spatial indices, query performance, and the like outside of that environment is somewhat opaque to me.   I'll try PGAdmin directly against my three tables and see if query performance is different.  Thanks! ... View more

@VinceAngelo Looping back around to this, I've been trying to performance test queries on ArcGIS services built on different types of "layers" to demonstrate we should be storing spatial data with native spatial types.  In all cases, I have 500k records with the same points, lat / longs generated randomly roughly over the contiguous US. 1. Native geometry in esri enterprise geodatabase (on top of postGIS) point feature class 2. Query layer on lat / long column from non-spatial table with lat / long columns (table also exists in enterprise geodatabase though because that's all I have access to currently) 3. Database view on same table as 2. above In the case of the database view and query layer, they were created using  SELECT *, ST_SetSrid(ST_MakePoint(longitude, latitude),4326) FROM randomtable.  I have three MapServices published on each of those layers, and have been performing 10 spatial queries with different geometries on each, and taking the average response time of the API for each service.  At 500k records, the differences are in the 100ths or 1000ths of a second, IMO too small.  Are the real differences as you indicated going to appear with way more records than 500k, or am I going about this incorrectly? Thank you!     ... View more

And tracking at the web server (web adaptor, load balancer, etc) level could work, but would require custom development.  Also a single map might make dozens if not hundreds of queries to the same service as the user pans and zooms - I'm hoping for a solution that does not require sorting though all that to generate single session logs.   ... View more

Thanks all - good info here.  Ours is more a "security compliance and auditing requirement."  We have a number of restricted datasets, and need to pull logs on who is accessing them to ensure that only those that should are.  This falls more into the "does ArcGIS Enterprise security work the way they say" category unfortunately, which I have no reason to doubt, but the powers that be need to cross check logs anyway for auditing purposes.   ... View more

We have Enterprise 10.9 and have the exact same issue in trying to embed our own dashboards (same origin, but still getting CORS errors).  Curious if you've upgraded to 10.9.1 and it's been fixed or not?  I know there is a workaround / hack listed below, but generally only do that as a last resort.   ... View more

@baohuachu2 Yeah, I'm unsure if Esri will change their API to support native Proxy objects like Vue uses.  Some of the additional code examples at the bottom of this thread show some good patterns for working with Vue 3.x and AGIS JS API.  In short, don't set your esri objects (map view, map, etc) to be vue reactive in your individual components, but instead use the AGIS JS API to handle the reactivity of Esri objects.  You can create non reactive objects and return them in the setup function to use through the rest of your component.  I don't think this kind of option existed for Vue2.  If you are using Vuex, I believe I ended up using toRaw and markRaw (https://vuejs.org/api/reactivity-advanced.html#toraw) to handle reactivity of Esri objects in Vuex.  Hope this helps.  At this point it's been a while so I forget the exact details.  🙂 ... View more

Thank you! I knew it was somewhere in there! dir(item) just returns too many properties 🙂 ... View more