Latest Contributions by JoelBennett

In case anybody else runs across this... We have an application that will load one of many different FeatureLayers at any given time, and one of those layers was throwing an error that said "Coordinate Quantization parameter specified is not correct". I ultimately traced this to the map service returning this in the metadata for the layer (i.e., part of what you see when you go to http://server/arcgis/rest/services/MyService/MapServer/0😞 "extent": { "xmin": "NaN", "ymin": "NaN", "xmax": "NaN", "ymax": "NaN", "spatialReference": { "wkid": 102100, "latestWkid": 3857 } }‍‍‍‍‍‍‍‍‍‍ So there was a problem with the extent for the layer. I'm not sure why it was doing this, but this layer was a valid query layer with valid data, and the problem occured using ArcGIS Server 10.6.1 and JavaScript API 3.27. Whatever the case, there at least three possible solutions for this problem: 1) Somehow correct the problem causing the service to generate this info. This could possibly involve restarting and/or republishing the service. Depending on your organization (or if you're using data outside your organization), this might not be feasible or possible for you, especially if you need it working "now". 2) You could pass an undocumented property within the "options" argument of the FeatureLayer constructor with the name "quantize" and the value of false. For example: var layer = new FeatureLayer(url, {id:"myLayer",visible:true,quantize:false});‍ As mentioned in my case, the problematic layer was one of many, and I didn't necessarily want to disable quantization for them all, so this wasn't optimal. However, depending on your restrictions, this may be the only option you have. 3) If you have a locally hosted copy of the API, you can "fix" your copy of it. The reasoning is that (1) since it is possible for ArcGIS Server to return an invalid extent, then (2) the JavaScript API should handle that gracefully, but in its current state, it doesn't. By default, quantization is used (a) if it is enabled in the FeatureLayer object (see undocumented "quantize" parameter discussed in option 2 above, which defaults to true), and (b) if ArcGIS Server supports quantization for the layer in the map service. We can add an additional condition (c) that the extent object must also be valid, because quantization works only with a valid extent. This way, we won't waste network and server resources by sending requests we already know will fail. To do this, I opened the init.js file, and did a find (Ctrl-f) for this text: this.quantize&&this.supportsCoordinatesQuantization?("esriGeometryPolyline" ...and replaced it with this text: this.quantize&&this.supportsCoordinatesQuantization&&!isNaN(this.fullExtent.getHeight())&&!isNaN(this.fullExtent.getWidth())?("esriGeometryPolyline" I took the third option because it would've been a pain for me to troubleshoot the map service, and I didn't necessarily want to lose the benefits of quantization on "good" layers. And so now, the "problematic" layer works just fine. ... View more

A bug exists in the Measurement dijit of version 3.17 of the API.  This could also exist is previous versions as well. Description: After obtaining a location value, you get nothing or a garbage value when switching the units to UTM, MGRS, or USNG. Conditions: 1) Your map's spatial reference is web mercator (may happen for other spatial references besides WGS 84 as well). 2) You create the measurement dijit with "advancedLocationUnits" set to true Steps to reproduce: (Note, you can reproduce this is in the measurement widget sample at https://developers.arcgis.com/javascript/3/sandbox/sandbox.html?sample=widget_measurement if you also add the "advancedLocationUnits" parameter and set it to true in the constructor and then run the sample) 1) Click the "Location" tool of the widget 2) Click a point on the map so you see the output for the point 3) Switch the units to UTM, USNG, OR MGRS Note: This bug is not manifested if you select UTM, USNG, or MGRS and then click the point on the map.  It is only where there is an existing point and you switch units. Example: If your original units are UTM, and you click a point, you get a good value.  If you then re-select UTM in the units list, you get a garbage value for the same location. Diagnosis: There are different code paths taken when clicking on a point, or switching the dropdown list.  The problem occurs in the _switchLocationUnit function, particularly in this line of code: "esriDegreeMinuteSeconds"===b||"esriDecimalDegrees"===b?(this._mouseMoveMapHandler=c.connect(this._map,"onMouseMove",this,"_locationMoveHandler"),this._toggleLocationResultsTable(!0,!1),this._locationGraphic&&this._calculateLocation(this._locationGraphic.geometry,!0)):(this._toggleLocationResultsTable(!1,!1),null===this.resultValue||null===this.markerLocationX&&null===this.markerLocationY||(a=this.markerLocationX,d=this.markerLocationY,this._locationGraphic&&this._updateGeocoordinateStringLocation({coordinates:[[a, d]],sr:{wkid:4326},conversionType:this._unitStrings},this._locationGraphic.geometry))) Since that's difficult to comprehend, I've translated it (more or less) here: if ((b == "esriDegreeMinuteSeconds")  || (b == "esriDecimalDegrees")) { this._mouseMoveMapHandler = c.connect(this._map, "onMouseMove", this, "_locationMoveHandler"); this._toggleLocationResultsTable(true, false); if (this._locationGraphic)   this._calculateLocation(this._locationGraphic.geometry, true); } else { this._toggleLocationResultsTable(false, false); if ((this.resultValue !== null) && (this.markerLocationX !== null) && (this.markerLocationY !== null)) {   a = this.markerLocationX;   d = this.markerLocationY;   if (this._locationGraphic)    this._updateGeocoordinateStringLocation({coordinates:[[a,d]], sr:{wkid: 4326}, conversionType:this._unitStrings}, this._locationGraphic.geometry); } } Notice the call at the end to _updateGeocoordinateStringLocation...notice in particular the hard-coded value of the "sr" parameter {wkid:4326}.  This is the problem...explanation below: When just clicking a point on the map, the workflow goes from _measureCustomPoint to _calculateLocation.  This results in call to _updateMarkerLocation, where markerLocationX and markerLocationY are set to wm values of _userGeometry (the point the user clicked).  In _calculateLocation, a copy of the geometry projected to wgs 84 is obtained, which then makes its way to _updateGeocoordinateStringLocation.  This works because the coordinate values passed are in wgs 84. However, when changing the unit drop-down, the flow is a little different.  This starts with a call to _switchLocationUnit, which, as you can see in the code, grabs the markerLocationX and markerLocationY values, which are in web mercator, but slaps a hard coded wkid of 4326 on them, saying they're wgs 84 instead.  You can probably see where this is a problem.  This is why you get nothing/garbage when switching to UTM, MGRS, or USNG. Prescription: You can do this yourself if you have a locally hosted copy of the API.  The cause of the bug lies in the hard-coded value for sr (sr:{wkid: 4326}).  I instead recommend changing it to sr:this._locationGraphic.geometry.spatialReference This is because the values of the _locationGraphic geometry are actually copied into markerLocationX and markerLocationY, which are the coordinates passed in the same call.  See flow of _locationClickHandler -> _calculateLocation -> this._updateMarkerLocation ... View more