Thanks Andrea, - Can you point me to the source of the read parameters for this operation? Would it simply be a new member variable in FeatureInfoRequestParameters, or are you talking about a GeneralParameter? - Is "excess granule removal" something that I would have to call/invoke? - For the feature collection aspect, the RasterLayerIdentifier currently returns a FeatureCollection containing a single SimpleFeature containing the pixel values. Instead of that feature containing a feature collection, I could potentially generate multiple features in the collection that's already being created, one for each feature at that pixel location. However, this seems overkill and excessive duplication of data as each feature would have the same values. - Using complex features for the response and including other feature data you mentioned (cloud cover, etc), in the event of multiple originating features, would those values have to be aggregated or averaged or something? Taking this a step further, would it be useful or make sense to build that collection that includes the original individual feature data and original pixel values for each original feature, and then a meta-feature that represents the mosaic?
I'm getting pretty far out of my league here as this gets more complex, as I don't understand how granule selection works or what actually happens when there are multiple images. I based my original proposal on the discovery that the coverage contains a single "sourceUrl" property at the time the single SimpleFeature containing the pixel values is created. Tracing back further, the GranuleLoadingResult contains a single feature called "originator", and the RasterLayerResponse contains a single String for "sourceUrl", which it puts in the grid coverage's property map with the key GridCoverage2DReader.SOURCE_URL_PROPERTY. I'm sure I'm missing something here... BaseSubmosaicProducer loops through each GranuleLoadingResult, but defines the sourceUrl variable outside the scope of the loop and assigns the value inside the loop, so the value ends up being the last result iterated over in the collection. My original idea was to simply utilize the fid that corresponds to the feature that the sourceUrl value came from, but if that isn't valid, it seems the existing sourceUrl value shouldn't be valid either. On Thu, Jul 18, 2019 at 8:53 AM Andrea Aime <[email protected]> wrote: > Hi Josh, > I'm generally ok with the idea, but with some observations: > > - The ids should not show up by default, they could be many (hundreds > of thousands in a mis-configured time based mosaic) and result in a really > weird and heavy featureinfo output. Probably something to activate with a > read parameter, which is either configured in the layer, or via a vendor > request parameter... and there is a security angle too, people might not > want to expose the keys at all (you cannot assume they are auto-generated, > they might have a business meaning too). From that P.O.V. best if the admin > alone is in control. > - The read parameter should be generic, so that other reader > implementations can participate in the game if they wish to (of course > you'll implement it only for image mosaic) > - Even if you don't have multi-image overlap, in some places the image > generation will have N input images, all overlapping the requested area, > even if just one contributes pixels to the output. Excess granule removal > can reduce or eliminate that, but it's not commonly used. So, in general, > remind users that not all images might show up in output in that point. > - Getting a FeatureCollection instead of concatenated strings is more > flexible and would allow for interesting outputs to be generated, but it > would also expose information that one might not like to advertise. It > would also make the SimpleFeature not simple anymore, as one of its > attributes would be a feature collection... we'd have to switch to complex > features to handle that case, not sure how ready the GetFeatureInfo > machinery is, along with the gml/json/text/html encoders. But it would sure > be useful in some cases (e..g, I click on a mosaic image and get > information about cloud cover, snow cover, off nadir and so on) > > Cheers > Andrea > > > On Thu, Jul 18, 2019 at 2:42 PM Josh Fix via Geoserver-devel < > [email protected]> wrote: > >> Hey Jody, >> >> Yes, the goal is to surface the information not only for the HTML output >> of GetFeatureInfo, but for all outputs. The pixel values are bundled in a >> SimpleFeature, and the line that builds that feature in >> RasterLayerIdentifier looks like this: >> >> return DataUtilities.collection(SimpleFeatureBuilder.build(gridType, >> values, "")); >> >> Where "" is the id String. That feature is used as the source for all >> output formats, and for all output formats, the fid is empty. In GML3, the >> output looks like this: >> >> <gml:featureMembers> >> <ws:geotools_coverage gml:id=""> >> <ws:RED_BAND>2659.0</ws:RED_BAND> >> ... >> >> - On your first point, I may be a little confused. The feature ID is a >> string. I'm not certain what a record ID is. >> - For your second point/idea, that is entirely possible. I could stuff >> the entire feature(s) into the properties map if that were desirable. My >> goal is only to obtain the fid; I'm open to including anything extra, so >> long as I can get to the fid. >> - I don't honestly know what I'm talking about here, other than trying to >> answer the question of what to do if the pixel values are calculated from >> more than one granule. Totally open to suggestions and can write this any >> way that makes sense. >> >> On Thu, Jul 18, 2019 at 12:58 AM Jody Garnett <[email protected]> >> wrote: >> >>> That sounds okay, goal is to surface this information for use in the >>> GetFeatureInfo free marker template? >>> - It may be more appropriate to use a RecordId or FeatureId then a >>> String? >>> - Idea: If you are surfacing the feature id it may be worth outing the >>> other granule properties at the same time, or is that already available .... >>> - The handling of interpolation sounds a bit suspect, may be better to >>> return the nearest neighbour FID and attributes >>> >>> -- >>> Jody Garnett >>> >>> >>> On Wed, 17 Jul 2019 at 13:48, Josh Fix via Geoserver-devel < >>> [email protected]> wrote: >>> >>>> I was interested in submitting a PR to enhance the GetFeatureInfo >>>> response for image mosaics, but thought I would post here first. >>>> >>>> When GetFeatureInfo is called on an image mosaic, the pixel values are >>>> returned in a table. The first column of the table is "fid", but is never >>>> populated. I would like to submit PRs (requires a PR for GeoTools and >>>> GeoServer) to return the fid(s) of the features used for granule(s) used >>>> for the corresponding pixel values. I thought I would start a conversation >>>> here first. >>>> >>>> The changes would entail: >>>> >>>> 1) [gt] Adding a "String sourceFid" to RasterLayerResponse >>>> <https://github.com/geotools/geotools/blob/master/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/RasterLayerResponse.java#L524> >>>> 2) [gt] In BaseSubmosaicProducer >>>> <https://github.com/geotools/geotools/blob/master/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/granulecollector/BaseSubmosaicProducer.java#L228>, >>>> get the fid from GranuleLoadingResult.originator >>>> <https://github.com/geotools/geotools/blob/master/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/GranuleDescriptor.java#L336>, >>>> which is a `SimpleFeature`, and set it on the rasterLayerResponse. >>>> 3) [gt] In RasterLayerResponse >>>> <https://github.com/geotools/geotools/blob/master/modules/plugin/imagemosaic/src/main/java/org/geotools/gce/imagemosaic/RasterLayerResponse.java#L1240>, >>>> put the fid into the properties map for the coverage. (maybe need to add a >>>> new public static final String for the key to GridCoverage2DReader... >>>> SOURCE_FID_PROPERTY?) >>>> 4) [gs] In RasterLayerIdentifier >>>> <https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/featureinfo/RasterLayerIdentifier.java#L327>, >>>> get the fid from the properties map in the coverage object, and set it as >>>> the id in the call to SimpleFeatureBuilder.build. >>>> >>>> In the event the value comes from interpolation of more than one >>>> granule, the fid would be a comma separated string containing the feature >>>> ids of the granules used to calculate the value. >>>> >>>> Any thoughts or objections? >>>> >>>> V/r, >>>> >>>> Josh >>>> >>>> >>>> >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >>> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > -- > > Regards, Andrea Aime == GeoServer Professional Services from the experts! > Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime > @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 > Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 > 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* >
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
