Latest Contributions by DrewMillen

We've build Geocortex software to access content in Portal for ArcGIS and ArcGIS Online. Wondering how many organizations are using both Portal for ArcGIS and ArcGIS Online (versus one or the other)... ... View more

It would be useful to have automatic resolution of coded domains from REST endpoints. The GeoServices REST Specification exposes a number of endpoints which return attribute values. Some of the rest endpoints supply automatic coded domain resolution (for example the Identify and Find resources); however, others do not. Specifically, the following REST endpoints return coded values (instead of resolved values): Feature – Map Service http://<layer-url>/<featureId> Feature – Feature Service http://<featurelayer-url>/<featureId> Query (Operation) http://<layer-url>/query Query - Feature Service (Operation) http://<featurelayer-url>/query Query Related Records (Operation) http://<layer-url>/queryRelatedRecords Query Related Records - Feature Service (Operation) http://<featurelayer-url>/queryRelatedRecords There may be others as well, but these are the endpoints most exercised by typical client applications. I would like to propose a change to the GeoServices REST Specification to allow an optional parameter on these endpoints (for example, “resolveCodedDomains=true”) which when supplied would instruct the endpoint to return resolved values as opposed to coded values. I believe that this would be a non-breaking change since the default behavior could remain the same. Obviously, if subtypes are used then the coded values should be resolved according to the subtype of the feature returned. Additionally, there are several REST endpoints which require the use of coded values in their parameters. For example, although the “Find” resource successfully resolves coded domains when returning results, clients of the operation must supply the “searchText” parameter using the coded values (and not the resolved values). Similarly, the layerDefs parameter used by Identify and Export operations of a MapServer require the use of coded values. It would be helpful if we could provide a parameter to a resource which specifies that the supplied parameters contain resolved coded domain values (instead of the coded values). ... View more

It would be useful to have automatic resolution of coded domains from REST endpoints. The GeoServices REST Specification exposes a number of endpoints which return attribute values. Some of the rest endpoints supply automatic coded domain resolution (for example the Identify and Find resources); however, others do not. Specifically, the following REST endpoints return coded values (instead of resolved values): Feature – Map Service http://<layer-url>/<featureId> Feature – Feature Service http://<featurelayer-url>/<featureId> Query (Operation) http://<layer-url>/query Query - Feature Service (Operation) http://<featurelayer-url>/query Query Related Records (Operation) http://<layer-url>/queryRelatedRecords Query Related Records - Feature Service (Operation) http://<featurelayer-url>/queryRelatedRecords There may be others as well, but these are the endpoints most exercised by typical client applications. I would like to propose a change to the GeoServices REST Specification to allow an optional parameter on these endpoints (for example, “resolveCodedDomains=true”) which when supplied would instruct the endpoint to return resolved values as opposed to coded values. I believe that this would be a non-breaking change since the default behavior could remain the same. Obviously, if subtypes are used then the coded values should be resolved according to the subtype of the feature returned. Additionally, there are several REST endpoints which require the use of coded values in their parameters. For example, although the “Find” resource successfully resolves coded domains when returning results, clients of the operation must supply the “searchText” parameter using the coded values (and not the resolved values). Similarly, the layerDefs parameter used by Identify and Export operations of a MapServer require the use of coded values. It would be helpful if we could provide a parameter to a resource which specifies that the supplied parameters contain resolved coded domain values (instead of the coded values). ... View more

It would be useful to have automatic resolution of coded domains from REST endpoints. The GeoServices REST Specification exposes a number of endpoints which return attribute values. Some of the rest endpoints supply automatic coded domain resolution (for example the Identify and Find resources); however, others do not. Specifically, the following REST endpoints return coded values (instead of resolved values): Feature – Map Service http://<layer-url>/<featureId> Feature – Feature Service http://<featurelayer-url>/<featureId> Query (Operation) http://<layer-url>/query Query - Feature Service (Operation) http://<featurelayer-url>/query Query Related Records (Operation) http://<layer-url>/queryRelatedRecords Query Related Records - Feature Service (Operation) http://<featurelayer-url>/queryRelatedRecords There may be others as well, but these are the endpoints most exercised by typical client applications. I would like to propose a change to the GeoServices REST Specification to allow an optional parameter on these endpoints (for example, “resolveCodedDomains=true”) which when supplied would instruct the endpoint to return resolved values as opposed to coded values. I believe that this would be a non-breaking change since the default behavior could remain the same. Obviously, if subtypes are used then the coded values should be resolved according to the subtype of the feature returned. Additionally, there are several REST endpoints which require the use of coded values in their parameters. For example, although the “Find” resource successfully resolves coded domains when returning results, clients of the operation must supply the “searchText” parameter using the coded values (and not the resolved values). Similarly, the layerDefs parameter used by Identify and Export operations of a MapServer require the use of coded values. It would be helpful if we could provide a parameter to a resource which specifies that the supplied parameters contain resolved coded domain values (instead of the coded values). ... View more

Hi There, As I understand it, the use of the token property is no longer the preferred method for accessing Bing Maps services.  In the place of tokens, it is recommended that developers use a "Bing Maps Key".  This is described here: http://msdn.microsoft.com/en-us/library/cc980937.aspx (see the "Note" section) and there's also a related thread on the Silverlight API forum here: http://forums.arcgis.com/threads/4482-Bing-Service From the forum link above: "The staging servers has been deprecated by Microsoft, including their token service. The good news is that it has gotten a lot simpler now. Instead, go to www.bingmapsportal.com sign up, log in and generate a token/app id. This token doesn't expire." I see that the Flex API and Silverlight API have both been updated to accept the "key" property belonging to the esri.virtualearth.VETiledLayer class. I would like to start using the 'key' in place of tokens in my applications.  Are there plans to update the ESRI JavaScript API in order to support the new way of connecting to Bing Maps services? If so, do you have a timeline in mind? Thank you in advance for any insight you may be able to provide. Drew. ... View more