Status Update
No update yet.
Comments
br...@google.com
FeatureView layers were ee.data.listFeatures) or computation. The Code Editor does some magic to parse the response from ee.data.listFeatures for inspection in the Code Editor. I'm going to change this to a feature request and discuss with the team about whether and how to surface this functionality more generally to the client library.
I understand that it could be really useful for performant EE Apps. In the meantime, you could filter the FeatureCollection that the FeatureView was created from for inspector-like functions.
br...@google.com
Here is a hack that will parse the ee.data.listFeatures response into a FeatureCollection that you can call aggregate_array on.
ro...@ldc.com
Yes, I saw that the code editor was using listFeatures to do the magic so I tried to use it myself from my client-side code. And yes, I think it'd really useful to boost EE apps.
The hack you shared is useful, because now I can actually use the output, but it's not exactly what I was looking for, because I want to read the properties from all Features, without having to know the source FeatureCollection. Thanks! 🙂
Description
According to the documentation, the output type of `ee.data.listFeatures` is `api.ListFeaturesResponse`, but I couldn't find more info about this object, neither information about the `api` scope.
Also, the number of features shown by this method seems to differ from the total number of features.
### Steps to Reproduce
### Current Behavior
* shows different number of features than the benchmark
* `Internal error: object not in API` when trying to access the feature's list
### Expected Behavior
* I want to avoid making the user indicate the associated `FeatureCollection`
* Access all the features and get all values for a certain property. Same as `FeatureCollection.aggregate_array("property").distinct()`
---