Hi Soren, yes, that's a good idea in general... I guess you're using a data source that does not perform any sort of paged access? E.g., when working against a shapefile, only one record will be actually read by DataUtilities.first, and when using a database, a "fetch size" worth of records should be transferred (which is still a lot more than strictly needed).
While you're at it, I would also add a limit of 1 feature in the Query object, which depending on your data source and data structures, might have a more of an effect of limiting the attributes (doing both is best). Please make a pull request with the suggested code change. Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ 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 On Thu, Jul 11, 2024 at 9:00 AM Kalesse Sören <soeren.kale...@dwd.de> wrote: > Hi, > > we have a question regarding the fix for > https://osgeo-org.atlassian.net/browse/GEOS-9757. We are indeed happy > about this functionality, but we noticed an inconvenience. > > We observed that the validation code for vector dimensions creates a > filter for the particular dimension but wraps it using a ALL_NAMES query, > which basically results in a query for all features attributes. This > behavior could result in a lot of feature data to be transferred from the > backends to GeoServer (probably depending on the store implementation). > > On the other hand when querying the data stores for capabilities, the > queries used there are limited the particular dimension attribute. This > results in much less data to be transferred from the backends, especially > if the result is only used to check if it's not empty. > > The question would be if the validation code could be improved in such a > way that it functions similar to the way dimension data for capabilities is > queried - wrap the filter in a query, but fix the query property to be the > particular dimension attribute. The org.geoserver.wms.WMS#validateTimes() > method for example could be adjusted in a way as depicted below (and > similarly for the validation methods for elevation and custom dimensions): > > private void validateTimes(.... > ... > Query timeQuery = > getDimensionQuery( > getTimeFilter(explicitTimes, typeInfo, > builder), > timeInfo, > > typeInfo.getFeatureType().getName().getLocalPart()); > if (DataUtilities.first(fs.getFeatures(timeQuery)) == null) { > throwInvalidDimensionValue(request, ResourceInfo.TIME, > ResourceInfo.TIME); > } > ... > } > > /** > * wraps the given filter in a query for dimension requests. > * > * @param filter the filter > * @param dimensionInfo the dimension info > * @param typeName the feature type name > * @return a query that wraps the filter and restricts the query to > the dimension attribute > */ > private static Query getDimensionQuery(Filter filter, DimensionInfo > dimensionInfo, String typeName) { > final Query dimQuery = new Query(typeName, filter); > List<String> propertyNames = new ArrayList<>(); > propertyNames.add(dimensionInfo.getAttribute()); > if (dimensionInfo.getEndAttribute() != null && > dimensionInfo.getPresentation() != DimensionPresentation.LIST) { > propertyNames.add(dimensionInfo.getEndAttribute()); > } > dimQuery.setPropertyNames(propertyNames); > return dimQuery; > } > > Thanks for the help > Best Regards > > Sören > > > _______________________________________________ > Geoserver-users mailing list > > Please make sure you read the following two resources before posting to > this list: > - Earning your support instead of buying it, but Ian Turton: > http://www.ianturton.com/talks/foss4g.html#/ > - The GeoServer user list posting guidelines: > http://geoserver.org/comm/userlist-guidelines.html > > If you want to request a feature or an improvement, also see this: > https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer > > > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users >
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
