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
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
···
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.
Hmm, I guess the most generic solution would be to have a method .hasFeatureId(String fid) on the datastore level, where either the convention, a brute search or some custom implementation could be used.
But I think even in a situation where you have a few dozen app-schema layers (an inspire server for example), searching through all the layers would be unworkable. I think ideally this convention would actually be enforced by geoserver on the core level, but it’s a bit too late for that. Documentation would then be the next best choice …
Regards
Niels
···
On 05/12/2020 19:39, Andrea Aime wrote:
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 <geoserver-devel@lists.sourceforge.net> 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
Geoserver-devel@lists.sourceforge.net
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.