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
<[email protected]
<mailto:[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 <http://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]
<mailto:[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
