|
POST
|
Hi Tim, The difference between the two is that the second includes a value for the outSR parameter which causes features to be projected to the specified SRID before being sent to the client. When you create a feature layer with the JS API and add it to your map, requests are sent to your service for features. The JS API talks to the REST API so I was showing that the REST API is capable of what you're requesting. Unfortunately, the data behind the map service I was using seems to have changed so you can't see this in action. Instead, take a look at the attached screen shots.
... View more
05-05-2011
01:50 PM
|
0
|
0
|
2764
|
|
POST
|
I did some quick testing with an endpoint on one of the arcgis.com sample servers and it looks like it's working (at least via the REST API...). Check out these two urls: defalt, lat/long: http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/Earthquakes/EarthquakesFromLastSevenDays/MapServer/0/query?text=&geometry=&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=objectid%3D28436611&time=&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=&outFields=&f=html projected to web mercator: http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/Earthquakes/EarthquakesFromLastSevenDays/MapServer/0/query?text=&geometry=&geometryType=esriGeometryPoint&inSR=&spatialRel=esriSpatialRelIntersects&relationParam=&objectIds=&where=objectid%3D28436611&time=&returnIdsOnly=false&returnGeometry=true&maxAllowableOffset=&outSR=3857&outFields=&f=html What do the requests being sent to your server look like? Do they include the proper outSR parameter?
... View more
05-05-2011
12:22 PM
|
0
|
0
|
2764
|
|
POST
|
Can you clarify? In the code you posted, the query runs shortly after the page loads.
... View more
05-04-2011
03:24 PM
|
0
|
0
|
2119
|
|
POST
|
Use a geometry service to project your point. Geometry service project a point sample.
... View more
05-04-2011
01:56 PM
|
0
|
0
|
3288
|
|
POST
|
Couple things... -I would set returnGeometry to false if you're just populating a filteringSelect -your map service looks like it'll return up to 20k records; even w/o geometries, this can be slow -using "all" as query.text returns no records, in the code below I'm using "011" -the "identifier" property of the JSON object used to build a data store needs to be unique...you could filter your results from your query to be unique...or you could not use an "identifier" property and have dupes in your filteringSelelct...probably to filter your results before setting up your data store Working code: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=7" />
<title>
FilterSelect Query
</title>
<link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgis/2.0/js/dojo/dijit/themes/tundra/tundra.css">
<script type="text/javascript">
djConfig = {
parseOnLoad: true
};
</script>
<script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=2.0">
</script>
<script type="text/javascript">
//Be sure to define you dojo components
dojo.require("dijit.form.FilteringSelect");
dojo.require("dojo.data.ItemFileReadStore");
function init() {
var queryTask = new esri.tasks.QueryTask("http://dingo.gapanalysisprogram.com/ArcGIS/rest/services/PADUS/PADUS_status/MapServer/0");
dojo.connect(queryTask, "onComplete", initLineID);
var query = new esri.tasks.Query();
query.outFields = ["P_Des_Nm"];
query.text = "011";
query.returnGeometry = false;
queryTask.execute(query);
}
function initLineID(features) {
var lineIdObjects = [];
dojo.forEach(features.features, function(feature) {
lineIdObjects.push({
"name": feature.attributes.P_Des_Nm
});;
});
var data = {
//"identifier": "name", // identifier needs to be unique, results returned from the server are not unique so omit this property
"items": lineIdObjects
}
//bind the data object to the datastore
var lineDataStore = new dojo.data.ItemFileReadStore({
data: data
});
//bind the data store to the FilteringSelect component
dijit.byId("lineid").store = lineDataStore;
}
function doSomething(v) {
alert(v);
}
dojo.addOnLoad(init);
</script>
<body class="tundra">
<input dojoType="dijit.form.FilteringSelect" id="lineid" searchAttr="name" name="widgetName"
onChange="doSomething(this.value)">
</body>
</html> CODE tags are your friends as well as http://jsbeautifier.org/
... View more
05-03-2011
09:05 PM
|
0
|
0
|
2119
|
|
POST
|
Hmm...is your endpoint publicly accessible? I'm not sure how helpful I can be w/o access to test for myself. If it's not available publicly, I would say it's time to talk to tech support.
... View more
05-02-2011
12:15 PM
|
0
|
0
|
2989
|
|
POST
|
Which version of the Flex API were you using? And which version of ArcGIS Server?
... View more
05-02-2011
08:59 AM
|
0
|
0
|
2989
|
|
POST
|
@Stess if it works via the REST endpoint, but not with JS, then there's either a bug in the JS API or a problem with your code. Can you post a more complete code sample?
... View more
04-29-2011
08:44 AM
|
0
|
0
|
2989
|
|
POST
|
This is a strange one...I think it is a bug. It looks like only it happens when the difference between x coords is between 179.5 and 180.5. How'd you find this?
... View more
04-28-2011
04:01 PM
|
0
|
0
|
657
|
|
POST
|
@Eric I'm not too familiar with the Flex API but I took a quick look at the docs and maxAllowableOffset is there for both Feature Layers and QueryTasks (same as JavaScript). I understand the underlying issue, hence the reason I suggested a server object extension earlier in this thread 😉
... View more
04-25-2011
02:15 PM
|
0
|
0
|
1803
|
|
POST
|
@Eric have you experimented with maxAllowableOffset to manage the size of a response sent to the client? The generalize sample shows it in action.
... View more
04-25-2011
01:46 PM
|
0
|
0
|
1803
|
|
POST
|
OK, when specifying "handleAs: 'text'", and using a proxy, yes, the response is a string. My point is that there is a clearer way to do this and it uses less code. In this case, I'm not saying you shouldn't use eval() because of security concerns. Rather, I'm saying you shouldn't use eval() because you can just request json using esri.request() and you don't need to do your eval (dojo actually does it for you). You're saying that the text response is lighter/smaller than the json response but I'm saying they're the same. If you do both and monitor the http traffic using firebug, chrome dev tools or a standalone piece of software like fiddler or charles, you'll see that the responses are the same size (because they are from the same url). The difference is what dojo does once it receives the response. Take a look at the dojo source for the various handlers you can use with xhrPost (esri.request() calls dojo.xhrPost() when you use a proxy): http://bugs.dojotoolkit.org/browser/dojo/trunk/_base/xhr.js#L255 The text handler simply return responseText while the json handler calls dojo.fromJson which, it turns out, does exactly what you're doing in your callback. So both of our methods end up with the same result but I think it's clearer to people reading your code (and maybe even you when you come back to this in a year or two) what's happening when you use handleAs: json.
... View more
04-25-2011
01:41 PM
|
0
|
0
|
1803
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-23-2012 07:54 AM | |
| 1 | 05-28-2010 08:31 AM | |
| 1 | 11-12-2012 08:12 AM | |
| 3 | 02-23-2012 10:57 AM | |
| 1 | 06-27-2011 08:51 AM |
| Online Status |
Offline
|
| Date Last Visited |
11-11-2020
02:23 AM
|