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
