IdentifyTask removed in version 4.1. Which alternative(s)?

[WillemLigtendag]

I have a MapImageLayer on which I was using an IdentifyTask‌ in version 4.0. Unfortunately that task is removed from version 4.1. I don't know why. It isn't mentioned in the documentation. Supposedly the QueryTask can be used instead. I need to get out the values from one single sublayer, so that would be a valid alternative for me. But I can't get the QueryTask to work on the MapImageLayer. Does anyone know if that can be done and if so, which parameters to use? I keep getting the message "Invalid or missing input parameter".

[RobertScheitlin__GISP]

Williem,

  Have you seen the sample for the QueryTask?

ArcGIS API for JavaScript Sandbox | QueryTask 

[WillemLigtendag]

Robert,

Yes, I have. But that doesn't help me much as in that sample the QueryTask is used on a FeatureService, not on a MapService containing a Raster Layer.

[RobertScheitlin__GISP]

Williem,

   Sorry I did not see where you where querying a Rater layer in a map service. The only way to to that in the 3.x world was to use IdentifyTask so I would assume the same applies to 4.x. I will test that on my end. I removal of a whole class without it be documented is not normal. Maybe odoe‌ can provide some input.

[YannCabon]

Hello Willem,

You can use directly the queryFeatures method on the Sublayer. Sublayer | API Reference | ArcGIS API for JavaScript 4.1 

Indeed we had remove the IdentifyTask from 4.1, this slipped through the release notes. Sorry about the inconvenience. We removed it because this class was using the old way of defining definitionExpressions, dynamic layers, etc... for the sublayers of the MapImageLayer.

Now you can directly invoke queryFeatures which saves a lot of time. We are still considering if we reintroduce the IdentifyTask (as well as FindTask) to a later release or not. We are hesitant because the IdentifyTask is really tied to 2D and would be really hard to configure in for a 3D view. Of course we could say it's recommended for 2D only but we don't want you to build a 2D experience that you could port to 3D.

[WillemLigtendag]

Yann,

Thanks! Ok, that makes sense. I'm going to try the queryFeatures method on the Sublayer then.

Cheers,

Willem

[janjermei]

I am getting really frustated here:

- we have started developing a new application using JS API 4.0 in May 2016, bearing in mind that we did not want to start with an 'old' API version 3.x,

- since then, the content of the next release has never been clear, until the moment of release: there are always texts like 'coming soon', or blanks,

- measuring, redlining, editing, OGC layers have all been promised but never released,

- now even the IdentifyTask has disappeared in 4.1, while we are using it in 4.0 to query MapImageLayers with multiple sublayers,

- for nearly every functionality we have to decide if we will wait for a new 4.x release with uncertain contents or if we will develop something ourselves.

At this point we are considering rewriting our application in the latest 3.x API or switching to another vendor, since we are fed up with aming at a moving target with zero transparency.

I do not understand that you announce a new version of the API (4.x) when there is still so much development work to be done and so much volatility.

It would have been better to develop until you had 80% of the final functionality ready and then announce the release and roll it out in a few months instead of a few years.

[ReneRubalcava]

The MapImageLayer has built-in query functionality at the Sublayer level.

Sublayer | API Reference | ArcGIS API for JavaScript 4.1 

It was, in fact, much of the work done to add the enhancements to MapImageLayer so that each Sublayer could use definitionExpressions, renderer, popupTemplate, and query capabilities in a much simpler API than 3.x that the current implementation of the IdentifyTask had to be tabled for this current release. It was an oversight that this was not cited.

We will be evaluating the IdentifyTask for upcoming releases to meet varying needs.

Thank you.

[JuliePowell]

Hi Jan, I support the JS API from a product management perspective. I understand your frustration and the difficulty you are experiencing right now. It may not make your job easier, but I'd like to be transparent about our release strategy to at least provide insight into why we released the API into production, and also some info about upcoming releases.

As you know, 4.x was a complete rewrite of the API. While 4.0 didn’t have functional equivalence with 3.x, it did lay the foundation with a brand new architecture, programming patterns, and integrated new capabilities like 3D and map rotation. Developers wanting to build web apps with 3D visualization could start using this API and put them into production with the confidence of a fully-released API. In fact, there are already hundreds of great apps already out there that are built on 4.x. Developers that wanted to build 2D web apps could use the online SDK to figure out whether the current version of the API had the capabilities needed for their application requirements. In many cases, developers had to (and continue to) use 3.x because they needed something such as edit which is not yet available in 4. However, by releasing 4.0 to production, we are not holding back those developers who are building apps with requirements that are met by the current API. Because of the value we see in both APIs, we have committed to releasing both APIs concurrently – 4 releases of both 3.x and 4.x are planned for 2017.

That being said, we received feedback from the developer community that they needed more help determining whether the current version of the 4.x API had the capabilities needed for their app. For that reason, we put together the Choosing a version guide and detailed matrix help developers quickly determine whether a particular functionality had been built, and also "map" 3.x classes/properties/methods to 4.x (especially useful for cases where the implementation has been redesigned for 4.x). To your point, we haven't provided extensive information about when each of the remaining capabilities will be implemented in 4.x. I understand that this could make it difficult for you when planning your development work.

To share information on our release strategy, and a potential way in which we might be able to improve a bit: We have a very dynamic development and release process, with requirements that are driven by the ArcGIS platform (such as enhancements in ArcGIS Online, deeper support for 3D across the platform, vector tile layer support, etc), requirements specific to the API that we've collected from customers over time such as map rotation, and then all of the capabilities that will bring 4.x at parity with 3.x. At any given time, the team works on shorter-term advancements that make it into the subsequent release, and also longer design work that can span multiple releases. Because of all of this complexity and the dynamic nature of our work, we are careful about not committing to time frames unless we are very confident about the timing (so that developers don't plan their development schedule around something that they depend on and later find that it has been delayed). With this in mind, I think we can do better at communicating at least what we are working on, without a firm commitment to a particular release. I think this will give developers an idea about what capabilities are *in progress*, and those that will take longer to implement. One idea we had was to post a blog approximately one month before each release that describes this information. Do you think that would help?

I think it is also worth mentioning that 3.x is still a great option - it is a fully featured 2D API that will be supported through 2020. All versions of the API will also be hosted on our CDN indefinitely, so apps won't break, even after the API version reaches the retirement phase. More info here. 

As you suggested, the 4.x API is in fact a moving target; I promise that we will do our best to support you as you plan your development and build your apps. If you have any specific questions about the status of an API feature, please post them on geonet or contact me directly and we can have a transparent conversation about it.

Thanks,

Julie

[janjermei]

Hi Julie,

Many thanks for your extensive reply.

An overview of the developments/capabilities in progress would be useful, because this adds transparency.

In fact, the situation that we face on our side is as follows:

- we wanted to start developing a new GIS Viewer web application (not a replacement of an existing one) end 2015,

- at that time there were beta-releases of JS API 4 available, so we compared these to the 3.x JS API and we decided that we could start with JS API 4 because our GIS Viewer would start small and functionality would increase with time, which would also be the case for the JS API 4, and because  the JS API 4 is indeed a lot more consistent and thus interesting from a development point of view (by the way, we appreciate the effort ESRI has done so far 🙂 ),

- another point that made us decide to use JS API 4 is that ESRI gave the message that upgrading from 3.x to 4.x could best be done by rewriting the application, which we would like to avoid,

- today we have a first version of our GIS Viewer up and running and it is using mainly MapImageLayers for the map layers, geometry.fromJSON to overlay and handle geometries returned by other services, IdentifyTask to query the MapImageLayers by user defined groups of layers, and the users are happy,

- the main capability we are missing at this moment to make this first version really complete, would be displaying WMS layers,

- next to that we also hope that features that were working in 4.0 still keep working in future 4.x releases, such as IdentifyTask, or be replaced by iso-functional capabilities that do not require too much rework or rethinking of the application, otherwise we have too much rework along the way (which we tried to avoid by not choosing the 3.x API).

Best regards,

Jan