GeoServer

Bounding box for WFS doesn't update when an edit occurs

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.5.3
  • Fix Version/s: None
  • Component/s: Configuration, Transactions/Locking
  • Labels:
    None
  • Environment:
    Editing with uDig (or others?)
  • Number of attachments :
    0

Description

GeoServer does not dynamically generate bounds - the just reports back the bounds provided during configuration. This value is incorrect when you use WFS-T to draw new content outside of the original border.

We need to listen to our Transaction operations and either update the bounds as we go; or set them to refresh next time a capabilities document is generated.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. UDIG-1219 Bounding box for WFS doesn't update when an edit occurs

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -

I don't have a listening framework on 1.5.3 so I'm not sure I'll be able to fix this on 1.5.x.

Show
Andrea Aime added a comment - I don't have a listening framework on 1.5.3 so I'm not sure I'll be able to fix this on 1.5.x.
Hide
Permalink
Andrea Aime added a comment -

Implementing this in trunk should be easy, but there are some scary implications.
If you add a feature, I can just expand the bounds accordingly.
But what should I do when you delete one or update the geometry of one? Triggering the recomputation of the bounds could be intolerably expensive if the data set is very extensive (can take minutes).
Shall we be happy to just update the bounds when they expand? This should eventually be user controllable, but this would be a configuration change...

Show
Andrea Aime added a comment - Implementing this in trunk should be easy, but there are some scary implications. If you add a feature, I can just expand the bounds accordingly. But what should I do when you delete one or update the geometry of one? Triggering the recomputation of the bounds could be intolerably expensive if the data set is very extensive (can take minutes). Shall we be happy to just update the bounds when they expand? This should eventually be user controllable, but this would be a configuration change...
Hide
Permalink
Jody Garnett added a comment -

Just updating the bounds when they expand would be fine; the bounds are a contract that say they contain all the features - so if they are a little too big we will at least still see something.

Show
Jody Garnett added a comment - Just updating the bounds when they expand would be fine; the bounds are a contract that say they contain all the features - so if they are a little too big we will at least still see something.
Hide
Permalink
Andrea Aime added a comment -

As I just reported on the associated udig jira, even updating manually the geoserver metadata did not help. Moreover, adding a point outside of the current bbox we are not able to commit it either (this is with RC14...).

Show
Andrea Aime added a comment - As I just reported on the associated udig jira, even updating manually the geoserver metadata did not help. Moreover, adding a point outside of the current bbox we are not able to commit it either (this is with RC14...).
Hide
Permalink
Jody Garnett added a comment -

I can fix that for uDig; but I agree Andrea a lot of clients are going to cache the capabilities document - unless you change the number at the top and it knows to re-request it? Would you like uDig to poll for GetCapabilities changes?

Show
Jody Garnett added a comment - I can fix that for uDig; but I agree Andrea a lot of clients are going to cache the capabilities document - unless you change the number at the top and it knows to re-request it? Would you like uDig to poll for GetCapabilities changes?
Hide
Permalink
Andrea Aime added a comment -

Nope, that's not needed. As I already stated in UDIG-1219, what I'd like is that uDig stops using the declared bbox to make requests as it does not make any sense, and use the current view bbox entirely instead. That's what OL is doing and works great, I don't undestand why uDig is doing extra work to get an inferior result.

Show
Andrea Aime added a comment - Nope, that's not needed. As I already stated in UDIG-1219 , what I'd like is that uDig stops using the declared bbox to make requests as it does not make any sense, and use the current view bbox entirely instead. That's what OL is doing and works great, I don't undestand why uDig is doing extra work to get an inferior result.

People

  • Assignee:
    Andrea Aime
    Reporter:
    Jody Garnett
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: