WFS GetFeature with BBOX Filter on FeatureType with no geometry

WFS GetFeature with BBOX Filter on FeatureType with no geometry

Hello list,

Running a GetFeature request with a BBOX filter on a FeatureType that doesn’t have a geometry creates troubles.

deegree ends up looping through the whole Database table before returning with an empty response. This isn’t good since it basically locks down a single core for the duration of the process (could be minutes depending
on size of the table).

I’ll report this as an issue to the issue tracker if someone verifies they can recreate this issue.

Testing should be fairly simple if you’re serving a FeatureType that doesn’t have geometry (e.g. INSPIRE cp:BasicPropertyUnit)

-Send a GetFeature request with no BBOX restriction and maxFeatures/count=1

oThis should return ~instantly because of the count=1

-Send another one does have a BBOX restriction (size or location shouldn’t matter) and the same maxFeatures/count limitation as previously

oThis should take minutes if you have millions of rows in the table in question

I’ve added a custom Filter in front of deegree that modifies the queryString before passing it further in the filterChain. It removes the BBOX key-value-pair from the queryString if the value of typename(s) is found within
a predefined set of typenames.

Now this isn’t really a solution, but it blocks this specific case (for GET/KVP encoded requests).

br, Janne

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev_______________________________________________
deegree-users mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/deegree-users

Running a GetFeature
request with a BBOX filter on a FeatureType that doesn’t
have a geometry creates troubles.

deegree ends up looping
through the whole Database table before returning with an
empty response. This isn’t good since it basically locks
down a single core for the duration of the process (could be
minutes depending on size of the table).

I’ll report this as an
issue to the issue tracker if someone verifies they can
recreate this issue.

Testing should be fairly
simple if you’re serving a FeatureType that doesn’t have
geometry (e.g. INSPIRE cp:BasicPropertyUnit)

-Send
a GetFeature request with no BBOX restriction and
maxFeatures/count=1

oThis
should return ~instantly because of the count=1

-Send
another one does have a BBOX restriction (size or location
shouldn’t matter) and the same maxFeatures/count limitation
as previously

oThis
should take minutes if you have millions of rows in the
table in question

I’ve added a custom
Filter in front of deegree that modifies the queryString
before passing it further in the filterChain. It removes the
BBOX key-value-pair from the queryString if the value of
typename(s) is found within a predefined set of typenames.

Now this isn’t really a
solution, but it blocks this specific case (for GET/KVP
encoded requests).

br, Janne

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev

Running a GetFeature request with a BBOX filter on a FeatureType that doesn’t have a geometry creates troubles.

deegree ends up looping through the whole Database table before returning with an empty response. This isn’t good since it basically locks down a single core for the duration of the process (could be minutes depending
on size of the table).

I’ll report this as an issue to the issue tracker if someone verifies they can recreate this issue.

Testing should be fairly simple if you’re serving a FeatureType that doesn’t have geometry (e.g. INSPIRE cp:BasicPropertyUnit)

-Send a GetFeature request with no BBOX restriction and maxFeatures/count=1

oThis should return ~instantly because of the count=1

-Send another one does have a BBOX restriction (size or location shouldn’t matter) and the same maxFeatures/count limitation as previously

oThis should take minutes if you have millions of rows in the table in question

I’ve added a custom Filter in front of deegree that modifies the queryString before passing it further in the filterChain. It removes the BBOX key-value-pair from the queryString if the value of typename(s) is found within
a predefined set of typenames.

Now this isn’t really a solution, but it blocks this specific case (for GET/KVP encoded requests).