Latest Contributions by JoelBennett

‎06-03-2021

I've found a consistent and reproducible case for this kind of behavior that may be the cause of what you're experiencing. Please see this post: SketchViewModel geometry editing bug 4.19

‎06-03-2021

The interactive geometry-editing utility of the SketchViewModel will not work if the view's extent is not normalized. This can be verified in the sample "Edit features with the Editor widget" with the following steps: Load the sample. Pan east (or west) until you go all the way around the world. This will go much faster if you zoom way out, pan, and then zoom back in to the editable features. In the "Editor" widget, click "Edit feature". Click on a polygon feature; this puts the feature into interactive geometry-editing mode. Move the mouse cursor over the rotation handle; note that rotation handle doesn't become highlighted like it should. Click and drag on the rotation handle; the feature is not rotated, and the map is panned instead. The same occurs if you attempt to use the resize handles or drag the feature to a new location. This was observed in 4.18 and 4.19; I don't know if it worked in previous versions or not. I haven't attempted to troubleshoot the API code itself. Instead, my current workaround is to detect if the view's extent is normalized before using the SketchViewModel, and if it is not, to normalize it before allowing further action to take place.

‎05-07-2021

I was able to download the files for 3.36 yesterday, but the ones for 4.19 are still missing. Is there another update on when we might be able to download 4.19?

‎04-30-2021

@BjornSvensson, thank you for the update. I'll be downloading both the API and the SDK for both 3.x and 4.x. We have primarily transitioned to 4.x (still using AMD), but are still supporting our 3.x-based framework in parallel for the time being. We host the API and SDK locally for two primary reasons. First and foremost, is that our applications must continue to operate even if a connection to the internet is not available. In some cases, we also support our framework on networks that have no internet access, so a locally hosted API is a must. Secondly, having the API allows us to work around its issues immediately, without being reliant on a third-party for technical support. I have 11 such "fixes" for 3.35, and 10 for 4.18, of varying criticality. For example, this one would be a deal-breaker; I couldn't release our solutions into production with something like that going on. All in all, the ArcGIS API for JavaScript continues to be an outstanding platform; thank you and your team for all you do in continuing to make it happen.

‎04-30-2021

It was said previously the API and documentation would be available for download yesterday, but as of now it still does not appear to be available. Is there any chance you might have a new ETA? Thank you -

‎04-20-2021

Here's a simplified solution for 4.18. In init.js, search for: p=b.urlToObject(p);p=p.path.match(k)||p.path.match(r); ...and replace with: p=b.urlToObject(b.makeAbsolute(p));p=p.path.match(k)||p.path.match(r);

‎01-29-2021

I was receiving this same error today using 4.18, and tracked it down the following problem: I had code like this: define(["esri/Geometry/Extent", "esri/layers/FeatureLayer", "esri/tasks/support/Query"], function(Extent, FeatureLayer, Query) { //etc }); However, notice the capital "G" in "Geometry". Unfortunately, it took me quite awhile to notice that, but once I fixed it to the following, the error messages stopped: define(["esri/geometry/Extent", "esri/layers/FeatureLayer", "esri/tasks/support/Query"], function(Extent, FeatureLayer, Query) { //etc }); This doesn't appear to be the problem you're having, but if, like me, somebody else ends up here because they're getting this message, hopefully this might help. One other thing to mention, I notice your code has: query.outSpatialReference = new SpatialReference(31370); However, the documentation doesn't indicate support for passing a number in the constructor. I have observed that 4.16 - 4.18 do allow this in practice, but considering the date of the original post, maybe you were using an older version of the API that had a problem with it? To be consistent with the documentation, though, it would be best to pass an object with the wkid property set: query.outSpatialReference = new SpatialReference({wkid:31370});

‎12-18-2020

I have downloaded version 4.18, tested my application, and found that this issue has not been fixed. In my situation, I have the following: Layer A (a MapImageLayer with no dynamicLayers) is visible by default, and loaded into the map. Layer B (a TileLayer with no dynamicLayers) is not visible by default, and is also loaded into the map. A Legend widget is created for Layer A and correctly displays the symbology for Layer A. A Legend widget is created for Layer B, but displays nothing because the layer is not visible. Layer B is set to visible, and Legend B correctly displays the symbology for Layer B. After zooming in on the map, Legend A refreshes and now incorrectly displays the symbology for Layer B. (Legend B continues to display the symbology for Layer B, as it should.) My workaround for 4.18 is the same as for 4.17, although the code to replace in esri/widgets/Legend.js is slightly different: Part 1: search for (in function _getLegendLayers): (a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default",A=va&&va[q]; Replace with: this.layer.url+((a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default"),A=va&&va[q]; Part 2: search for (in function _generateLegendElementsForSublayers): W=Q.hasDynamicLayers&&Q.dynamicLayers||"default"; Replace with: W=this.layer.url+(Q.hasDynamicLayers&&Q.dynamicLayers||"default");

‎10-21-2020

Please see also this thread. I also observed this happening in 4.16, but didn't investigate until after upgrading to 4.17. I'm fairly certain it's the same problem though.

‎10-21-2020

I've observed the Legend widget displaying the wrong symbology for some layers; in particular, the Legend will take the symbology for "layer b" and display it for "layer a". I'm fairly certain this is the same problem mentioned in this thread, which was observed in 4.16. Below is a description of the cause and a proposed 4.17 solution for those who need a fix "now". The ActiveLayerInfo class has an internal dictionary for caching legend information retrieved from the server. Keys for this dictionary are generated for each service based upon whether or not the service supports dynamic layers. If dynamic layers are supported, the key is the long JSON string passed as the "dynamicLayers" parameter in the legend request. If dynamic layers are not supported, the key for the layer is the string "default". This cache is shared across all instances of ActiveLayerInfo. The intent here is good, in that it can eliminate redundant requests to the server for information that the application has already retrieved. However, the key generation is highly susceptible to collisions. For example, it is possible for multiple layers that do not support dynamic layers to share the same key "default". Since there is only one entry in the dictionary possible for this key, it will always store the most recently retrieved legend response. As a result, when layer symbology is rendered in the legend, a layer can incorrectly display the symbology for a completely different layer. A fix for this is to generate better keys that have fewer collisions. If you're using a locally hosted copy of the API, you can do this yourself. In my solution, I've prepended the layer's URL to the key. In this case you will need to do two find-and-replace operations in the file esri/widgets/Legend.js. Note, this solution is for version 4.17, and may not work with other versions. Part 1: search for (in function _getLegendLayers): var b=(a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default",e=I&&I[b];‍ Replace with: var b=this.layer.url+((a=a&&a.hasDynamicLayers?a.dynamicLayers:null)||"default"),e=I&&I[b];‍ Part 2: search for (in function _generateLegendElementsForSublayers): p=f.hasDynamicLayers&&f.dynamicLayers||"default"‍ Replace with: p=this.layer.url+(f.hasDynamicLayers&&f.dynamicLayers||"default")‍ It should be further noted that my application uses multiple instances of the Legend widget simultaneously, but if I understand this problem correctly, it could still manifest itself when using a single Legend instance.

‎08-13-2020

When creating an instance of a FeatureLayer, I've run across a bug that occurs when passing a relative URL for the service. For example: var layer = new FeatureLayer({url:"/arcgis/rest/services/someFolder/someService/MapServer/0"});‍ The layer loads its service properties ok, but when querying the service for features, it includes the layer ID in the URL twice: https://hostname/arcgis/rest/services/someFolder/someService/MapServer/0/0/query?f=json&etc=etc Needless to say, the queries fail to execute. When initializing the FeatureLayer object, the logic "thinks" it parses the URL into a path and layerID. For example, if you pass an absolute URL, the following properties will be set: //sample URL = https://hostname/arcgis/rest/services/someFolder/someService/MapServer/0 url: https://hostname/arcgis/rest/services/someFolder/someService/MapServer layerId: 0 However, if you pass the relative URL: //sample URL = /arcgis/rest/services/someFolder/someService/MapServer/0 url: /arcgis/rest/services/someFolder/someService/MapServer/0 layerId: undefined After the layer's service info gets loaded, the state becomes: url: /arcgis/rest/services/someFolder/someService/MapServer/0 layerId: 0 Queries to the service join the url and layerId properties, thus you get: /arcgis/rest/services/someFolder/someService/MapServer/0/0 The problem can be tracked down to the parse function of the esri/layers/support/arcgisLayerUrl module, which uses regular expressions to parse the service URL into various components. This works fine for absolute URLs, but fails to work with relative URLs. One possible workaround is to convert all your URLs to absolute. However, this can be a problem if different users access the same server with different host names. Should you be using a locally hosted copy of the API, a more robust workaround would be to fix the aforementioned parse method...in this case, directly in the init.js file. The first two statements of that function are as follows: c=a.urlToObject(c); var b=c.path.match(g)||c.path.match(f);‍‍ I've inserted the following code between those lines to convert relative URLs to absolute prior to being tested against the regular expressions: if (c.path.indexOf("http") !== 0) { if (c.path.indexOf("/") === 0) { if (c.path.indexOf("//") === 0) c.path = window.location.protocol + c.path; else c.path = window.location.protocol + "//" + window.location.hostname + c.path; } else if (c.path.indexOf(".") === 0) c.path = window.location.protocol + "//" + window.location.hostname + window.location.pathname.substring(0, window.location.pathname.lastIndexOf("/")) + c.path; }‍‍‍‍‍‍‍‍‍ However, I've minified it when updating the init.js file. So basically, in init.js, you would search for: c=a.urlToObject(c);var b=c.path.match(g)||c.path.match(f); and replace it with: c=a.urlToObject(c);if(c.path.indexOf("http")!==0){if(c.path.indexOf("/")===0){if(c.path.indexOf("//")===0)c.path=window.location.protocol+c.path;else c.path=window.location.protocol+"//"+window.location.hostname+c.path;}else if(c.path.indexOf(".")===0)c.path=window.location.protocol+"//"+window.location.hostname+window.location.pathname.substring(0,window.location.pathname.lastIndexOf("/"))+c.path;}var b=c.path.match(g)||c.path.match(f); As an aside, relative URLs worked fine in 3.x, and the 4.x documentation doesn't specify that absolute URLs are required. This solution is specific to 4.16 and may not work in other versions. This post is for the benefit of those like me who experience this problem, and need a solution *now*. I will not respond to requests to submit this to ESRI support.

‎07-24-2020

I see this is an old thread, but I came across it having the same question, and I may not be the last. In my case, I was trying to figure out what the values in the STORAGE_TYPE field meant, hoping they would indicate the specific storage type (ST_GEOMETRY, SDO_GEOMETRY, etc). As it was, I had an application with these values in it that explain the contents of the GEOMETRY_TYPE column: //Values as stored in SDE.GEOMETRY_COLUMNS table, GEOMETRY_TYPE field public const int SDE_GEOM_TYPE_GEOMETRY = 0; public const int SDE_GEOM_TYPE_POINT = 1; public const int SDE_GEOM_TYPE_CURVE = 2; public const int SDE_GEOM_TYPE_LINESTRING = 3; public const int SDE_GEOM_TYPE_SURFACE = 4; public const int SDE_GEOM_TYPE_POLYGON = 5; public const int SDE_GEOM_TYPE_COLLECTION = 6; public const int SDE_GEOM_TYPE_MULTIPOINT = 7; public const int SDE_GEOM_TYPE_MULTICURVE = 8; public const int SDE_GEOM_TYPE_MULTILINESTRING = 9; public const int SDE_GEOM_TYPE_MULTISURFACE = 10; public const int SDE_GEOM_TYPE_MULTIPOLYGON = 11;‍‍‍‍‍‍‍‍‍‍‍‍‍ However, I wrote that while ago, and for the life of me, I had no idea how I got that information. I figured wherever the answer to that was, I'd also find the answer to the STORAGE_TYPE fields. In looking in the current documentation, ESRI doesn't say much about the system tables. However, but they did much more in days gone by, for example in the 9.3 documentation. In the section for the GEOMETRY_COLUMNS table, my eyes went straight to the table contents the first couple of times I looked at the page, but unfortunately it didn't explain the values. Eventually, though, I read the description, and it was very helpful, because it indicates that this table complies with the OpenGIS SQL specification. After a visit to Google, I ended up here: Simple Feature Access - Part 2: SQL Option, and the documents there show the values for these two columns. The values of GEOMETRY_TYPE in the original version 1.1 documents match up exactly with what I had in the code above, and based on my 10.6.1 geodatabase, it appears the SDE.GEOMETRY_COLUMNS table still uses those values. It is worth noting, though, that the later versions (e.g. 1.2.x) have a different set of values for GEOMETRY_TYPE, so proceed with some caution. As for STORAGE_TYPE, the values are consistent across the documents: 0 = normalized geometry implementation 1 = binary geometry implementation (Well-known Binary Representation for Geometry) NULL = geometry types implementation (added in version 1.2.0) However, it appears ESRI has departed a little from this, since in my 10.6.1 geodatabase, I see a value of 2 for ST_GEOMETRY. I've also come to find they also assign a 2 for SDO_GEOMETRY as well. This is consistent with the version 1.1 document approach to the values in GEOMETRY_TYPE, since the values of 0 and 1 were not suitable...it looks like they chose an arbitrary value (2) and went with it. (Note that the correct 1.2.0 value would be NULL, which some might wonder about...) So it turns out this field won't be the simple solution I was hoping for, but that's ok...there are other ways. Hope this helps somebody...

‎04-02-2020

In addition to the link you provided, this one also mentions the removal, but provides no reasoning or justification, which only makes the situation all the more frustrating as we watch the investment in our custom providers go to waste: What's new in ArcGIS Server 10.8—Documentation | Documentation for ArcGIS Enterprise Custom identity stores are a very valuable feature that allow us to link map service permissions to application permissions. In this way, we only have to maintain a single ACL. Without it, we have to maintain duplicate ACLs: one for application permissions, and the other for map service permissions because the latter does not imply the former. This alone is an administrative headache, but these ACLs will undoubtedly get out of sync which only compounds the problem, especially if you have to manage multiple, separate installations. Unless these are brought back, developing some automated tool that translates the application ACL to ArcGIS Server via the REST API on a periodic or ad hoc basis is about as good as it's going to get...which is too bad, because it's already been proven that it could be so much better.

‎03-31-2020

It's been a few months here, but in case this helps someone else... We ran into this same error recently while trying to copy and paste a feature class from one geodatabase into another. We found that if we removed all field-to-domain associations from the source feature class (such that the domains were no longer being copied), the operation would succeed. This indicates that the object with a name conflict is actually a domain, and not the feature class itself. Our customer didn't care about the domains not being present, so we didn't try to figure out which domain was the problem or troubleshoot any further.

‎08-12-2019

For posterity, this was fixed in 3.29. The "What's new in Version 3.29" page also reads: NIM098119: It is now possible to consume a Web Map Tile Service (WMTS) layer with resource info object on RESTful service mode.

My Ideas

Latest Contributions by JoelBennett

Re: Map dragging instead of vertex moving when editing in 4.x version?

SketchViewModel geometry editing bug 4.19

Re: ArcGIS API for JavaScript 4.19 and 3.36

Re: ArcGIS API for JavaScript 4.19 and 3.36

Re: ArcGIS API for JavaScript 4.19 and 3.36

Re: 4.16 FeatureLayer bug when using relative URL for service

Re: Error Accessor#set Assigning an instance of 'esri.geometry.SpatialReference' which is not a subclass of 'esri.geometry.SpatialReference'

Re: Wrong symbology in 4.17 Legend widget

Re: Legend is updated incorrectly in 4.16

Wrong symbology in 4.17 Legend widget

4.16 FeatureLayer bug when using relative URL for service

Re: geometry_columns

Re: custom identity stores deprecated

Re: ERROR 000260: Item with the same path name already exists.

Re: WMTSLayer bug

Re: 4.19 Legend widget bug - duplicated requests

Re: Go to specific index in popup

Re: ArcGIS Maps SDK for JavaScript – Version 5.0 R...

Re: Adding a row to a table using JS 4.x

Re: Timeslider web component ShadowDom not fully r...