Hi Niels, the convention you mention is deeper and existed before WFS 2.0 Stored queries implementations. Even starting with WFS 1.0, a client can make a GetFeature without the target feature type, as long as it specified a list of feature identifiers, and the server should be able to return only those features.
As you say, not having a convention would require querying all existing feature types one by one... which would be too slow. Documenting the convention is probably the sensible thing to do. Eventually I guess one could be able to advertise, at the datastore level or feature source level, if the store is following the convention or not, and just run queries on the feature types that do not... but it would still require to open all stores/feature sources, which would still be quite slow. Maybe this knowledge could be cached? Anyways, just thinking out loud. Cheers Andrea On Fri, Dec 4, 2020 at 1:00 PM Niels Charlier via Geoserver-devel < [email protected]> wrote: > Some issues have been reported with GetFeaturById finding features, in > particular with app-schema layers (see > http://osgeo-org.1560.x6.nabble.com/urn-ogc-def-query-OGC-WFS-GetFeatureById-td5402041.html > and > https://gis.stackexchange.com/questions/342744/geoserver-getfeaturebyid-stored-query-not-working > > It turns out that the Storedquery GetFeatureById is implemented in such a > way that it assumes that ID’s are always of the form “layername.id”. But > this is only a convention, for which each datastore’s own implementation is > responsible. In App-schema, this convention is not automatically followed > (but can be, if so specified in the mapping file). I don’t really see > another way of implementing this feature though: it would have unacceptable > performance to search in all layers (particularly if you have 100s or 1000s > of them). > > But perhaps it should at least be documented somewhere that this > convention is assumed for the storedquery to work, and that app-schema > users (or other stores that do not follow the convention automatically) > should be aware of that? > > Kind Regards > > Niels > _______________________________________________ > 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
