|
POST
|
Hi Selvaraj, Could you be a little more specific with your issue? Are you having trouble with QueryTask, zooming to a feature's extent in general? Or only in the SceneView (you get it to work in MapView)? I was able to query features using this sample as a base. Here is my sample app in a jsbin: JS Bin - Collaborative JavaScript Debugging Here are the highlights: QueryTask - This module essentially works the same as it does in 3.x. The main difference is that it returns a Promise instead of a Deferred, so to get the features you need to use .then(). This also allows you to chain multiple functions, which makes your code easier to read. If you're not familiar with using Promises, I encourage to you read the Working with Promises page in our SDK. ZoomTo - This can easily be done using the animateTo() method on the view. You can animate to a point, geometry, graphic, ViewPoint, and camera (only in SceneView). In my sample app, I passed in the first graphic returned from the query. You are supposed to be able to animate to an array of graphics or geometries, but I wasn't getting that to work properly in my app. That may be a bug, so I'll look in to it. Here are the main lines of code you should focus on: //Set base parameters of query
var q = new Query({
distance: 150, //get features within 150ft of mouse click
units: "feet",
returnGeometry: true,
spatialRelationship: "esriSpatialRelIntersects",
outFields: ["*"]
});
view.then(function(){
view.on("click", qFeatures);
});
//Executes a query task based on mouse click
function qFeatures(evt){
q.geometry = evt.mapPoint;
var qTask = new QueryTask({
url: featureLayer.url
});
qTask.execute(q).then(function(response){
return response.features;
}).then(highlightGraphics).then(zoomTo); //chain functions
}
var highlight = new SimpleMarkerSymbol({
color: "yellow",
size: 8,
outline: new SimpleLineSymbol({
color: "red",
width: 8
})
});
//highlight queried features
function highlightGraphics(graphics){
resultLayer.clear();
graphics.forEach(function(item, i){
item.symbol = highlight;
});
resultLayer.add(graphics);
return graphics;
}
//animateTo those features - This acts like a zoomToExtent method
function zoomTo(features){
view.animateTo({
target: features[0], //you should be able to pass the entire array here
scale: 1200
});
} Does this help? This sample should work in a SceneView as well; although the FeatureLayer rendering doesn't perform great at the moment, but you still should be able to observe the animation to the graphics.
... View more
08-18-2015
12:22 PM
|
0
|
0
|
551
|
|
POST
|
Robert, I'm not sure that I understand your issue completely, but I'll give it a shot. In 3.14, instead of using esri.basemaps, you can create your own basemap instance using the Basemap and BasemapLayer classes. You can then pass your own Basemap instance into the BasemapGallery. I did this with the Stamen toner tiled layer in this bin: JS Bin - Collaborative JavaScript Debugging You mentioned map.setBasemap in your last comment. I don't believe you can use setBasemap() to switch over to your own. BasemapGallery and BasemapToggle will allow you to do this, however. That being said, this will all be easier in the 4.0 API. You can already see how much easier it is by taking a look at this sample: JS Bin - Collaborative JavaScript Debugging where I create a Stamen basemap and pass it into the BasemapToggle widget. What's different about this sample is that not only is constructing each instance simpler, but you can also use the new basemap instance to set your map's basemap. In 4.0, instead of map.setBasemap(), you can set it directly on the basemap property like this: map.basemap = stamen; That's all there is to it! Go ahead and try it in the sample I referenced: JS Bin - Collaborative JavaScript Debugging . Open the console and type map.basemap = stamen. Then try switching to the others as well. Hopefully this helps answer your question.
... View more
08-11-2015
01:53 PM
|
3
|
1
|
1027
|
|
POST
|
Is the following line pointing to your proxy file in some way? esriConfig.defaults.io.proxyUrl = "localhost:8083"; What type of proxy are you using (PHP, JSP, DotNet)?
... View more
08-11-2015
11:05 AM
|
0
|
1
|
5078
|
|
POST
|
Austin, Thanks for posting the suggestion. This will be discussed and evaluated in the near future.
... View more
08-11-2015
10:58 AM
|
0
|
0
|
995
|
|
POST
|
Yes, there are many good use cases for subsurface capabilities. It will be supported by the time 4.0 moves out of beta. We're just don't have a timeline on when it could be released while we're still in beta.
... View more
08-11-2015
10:56 AM
|
0
|
1
|
1335
|
|
POST
|
In 4.0 beta1, there is no support to permit the camera to go below the surface. It's being discussed for future releases. Keep an eye out for more information related to this in the future.
... View more
08-10-2015
04:35 PM
|
0
|
4
|
1335
|
|
POST
|
Chris, Tim is correct. If you can't find it in the API reference, then there is no current support. The features you're familiar with in 3.14 will eventually be integrated into 4.0 by the final release next year.
... View more
08-10-2015
04:14 PM
|
1
|
0
|
853
|
|
POST
|
Hi Josh, If a class is not documented in 4.0, it is not supported. You can certainly try to use the class, but it isn't recommended. DynamicLayer does not perform as expected. For that reason it is not documented in beta1. It will eventually be supported in a future beta release. Information related to the current state of the API is found it the API reference. At the moment, we do not have a page dedicated to what we expect to develop and release in future betas since this changes often. As of now, you can expect nearly everything in the current 3.14 API to be included in the final 4.0 release (with the exception of deprecated classes like Geocoder). Regarding your last question, do we expect the code in 4.0beta1 to work against the final 4.0 release? That would certainly be ideal, but we cannot promise that all code structure will remain the same. That's one of the reasons we are releasing in beta - because the code base isn't completely stable yet.
... View more
08-10-2015
04:05 PM
|
1
|
0
|
924
|
|
POST
|
I should have noticed the proxy extension. Sorry about that. 😕 Try using the urlUtils like you do in 3.14. The import is different though: It's now "esri/core/urlUtils". This isn't documented, which means things can change in beta2, so keep an eye out for doc updates related to this in the future betas.
... View more
08-06-2015
01:37 PM
|
0
|
3
|
1367
|
|
POST
|
Did you include the URLs you want proxied in your proxy.config file? Which proxy are you using, PHP, DotNET, or JSP?
... View more
08-06-2015
12:00 PM
|
0
|
5
|
1367
|
|
POST
|
You should only expect updates coming with each beta release.
... View more
08-05-2015
10:51 AM
|
0
|
0
|
1862
|
|
POST
|
Cees van Altena Yes, this is a bug. However, you can also set the height of the view directly in the MapView constructor (view.height). Here's a link to the doc: https://developers.arcgis.com/javascript/beta/api-reference/esri-views-MapView.html#height. When you set the height inside the constructor instead of CSS, it seems to work as expected in your sample. View my bin here demonstrating this: JS Bin - Collaborative JavaScript Debugging This can be a current work around to your issue, although setting the CSS directly should work as well.
... View more
07-30-2015
02:11 PM
|
1
|
0
|
822
|
|
POST
|
Hi Gary, No, this is not supported at the moment. This is a concept we'll be discussing though and will let you know about future plans.
... View more
07-29-2015
03:19 PM
|
2
|
1
|
936
|
|
POST
|
Hi Adam and Adam, The documentation on this is misleading and, in the cases you both brought up, contradictory. The reason for this is because the way these workflows are being designed has been changing and will continue to change as 4.0 progresses through multiple betas into the final product. The documentation reflects some of these changes over time, but isn't consistent with how things are now. We are updating it so that it will not be as confusing. featureLayer.graphicsCollection does not exist. The Migration page in the guide is wrong and will be updated soon. featureLayer.graphics exists, but as the original post mentions, doesn't actually do anything. This too will likely go away and accessing graphics on the view will change in the future. Stay tuned for documentation updates explaining this. There are a number of reasons featureLayer.graphics will no longer be used, the primary reason being that features are no longer rendered on the layer or the map; rather, they are rendered in the LayerView and View. This is a major difference between our 3.x and 4.x APIs, so keep a look out for updated documentation, blogs, etc that go into greater depth explaining these concepts and classes. In the interim you can access the graphics displayed in the view via the 'graphics-controller-create' event on the featureLayer. This is undocumented, but will be later. The event object has a graphicsController property, which is an object that has a graphicsCollection property. See this jsbin for an example of accessing the graphics using one of our existing samples: JS Bin - Collaborative JavaScript Debugging I hope this helps!
... View more
07-29-2015
03:10 PM
|
2
|
3
|
1862
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 05-06-2025 03:09 PM | |
| 1 | 04-29-2025 08:36 AM | |
| 1 | 08-20-2024 08:06 AM | |
| 1 | 08-13-2024 11:53 AM | |
| 1 | 07-22-2024 11:04 AM |
| Online Status |
Offline
|
| Date Last Visited |
05-06-2025
03:01 PM
|