uDIG

BasicFeatureRenderer problem with bounds having width or height smaler than 50 pixels (point layers)

Details

Description

Having a point layer and updates features that have nearly the same X or same Y values the renderer doesn't work correctly. if the bounding box is smaler than the symbols the renderer hat to create for the poins (lets say triangle markers) the symbols are cropped. See attachement

Furthermore the bbox is not correct for a single point (width or heigth == 0) in the BasicFeatureRenderer. The max.y value is never set.

  1. Text File
    UDIG-1765.patch
    23/May/11 3:23 AM
    2 kB
    Frank Gasdorf
  1. triangles.jpg
    6 kB
    23/May/11 3:13 AM

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. GEOT-4238 MetaBufferEstimator should analyse image size for ExternalGraphic if graphic size is set

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Frank Gasdorf added a comment -
Patch File for udig-platform master
Show
Frank Gasdorf added a comment - Patch File for udig-platform master
Hide
Permalink
Jody Garnett added a comment -
So if I read your patch correctly; you are padding the height by a set amount (in the same fashion as the width was formally padded).

So if the patch is working for you (and fixes your issue) please go ahead and commit.

The only problem I could see is respecting the limits set by the back end data source (some web feature servers get very upset when we ask them for data outside of the valid area - example north of the north pole).
Show
Jody Garnett added a comment - So if I read your patch correctly; you are padding the height by a set amount (in the same fashion as the width was formally padded). So if the patch is working for you (and fixes your issue) please go ahead and commit. The only problem I could see is respecting the limits set by the back end data source (some web feature servers get very upset when we ask them for data outside of the valid area - example north of the north pole).
Hide
Permalink
Frank Gasdorf added a comment -
Yes, it works quite fine.

Some notes/questions about the limits for some kind of data sources like WFS. I'm not sure where to get the limits (ReferencedEnvelope) for the DataSource from. I tried to intersect the new paint area with the context.getLayer().getBounds(..) that was converted to a rectangle before. But that leeds into the same behavior like before because the bounds of the layer for new created data sources is quite small. Intersection with that doesn't really help...

IMHO we should give the patch a try as it is. Considering the fact that the exceed limits would only lead into problem in a small frame at the CRS Envelope. Properly we could define a property for the padding size that could be changed before startup or at runtime?

Any Suggestions?
Show
Frank Gasdorf added a comment - Yes, it works quite fine. Some notes/questions about the limits for some kind of data sources like WFS. I'm not sure where to get the limits (ReferencedEnvelope) for the DataSource from. I tried to intersect the new paint area with the context.getLayer().getBounds(..) that was converted to a rectangle before. But that leeds into the same behavior like before because the bounds of the layer for new created data sources is quite small. Intersection with that doesn't really help... IMHO we should give the patch a try as it is. Considering the fact that the exceed limits would only lead into problem in a small frame at the CRS Envelope. Properly we could define a property for the padding size that could be changed before startup or at runtime? Any Suggestions?
Hide
Permalink
Jody Garnett added a comment -
Hi Frank.

Really the DataStore's should "trim" the bounds to be within something they can handle. We were going to do the trim ourself here in the renderer as we don't really trust them.

Rather than hard code the symbol size of "30" we could use the style visitor MetaBufferEstimator to calculate it for us.
Show
Jody Garnett added a comment - Hi Frank. Really the DataStore's should "trim" the bounds to be within something they can handle. We were going to do the trim ourself here in the renderer as we don't really trust them. Rather than hard code the symbol size of "30" we could use the style visitor MetaBufferEstimator to calculate it for us.
Hide
Permalink
Frank Gasdorf added a comment - - edited
I'll refactor BasicFeatureRenderer and remove the hard coded value of 30 pixs. That task was already on my TODO list. Thanks for the pointer to MetaBufferEstimator!
Show
Frank Gasdorf added a comment - - edited I'll refactor BasicFeatureRenderer and remove the hard coded value of 30 pixs. That task was already on my TODO list. Thanks for the pointer to MetaBufferEstimator!
Hide
Permalink
Frank Gasdorf added a comment -
updated to MetaBufferEstimator
 see pull request 24 : https://github.com/uDig/udig-platform/pull/24
Show
Frank Gasdorf added a comment - updated to MetaBufferEstimator  see pull request 24 : https://github.com/uDig/udig-platform/pull/24
Hide
Permalink
Frank Gasdorf added a comment -
this issue is related to GEOT-4238 (ExternalGraphic is not recognized correctly)
Show
Frank Gasdorf added a comment - this issue is related to GEOT-4238 (ExternalGraphic is not recognized correctly)
Hide
Permalink
Frank Gasdorf added a comment -
reopened because of linked GeoTools issue
Show
Frank Gasdorf added a comment - reopened because of linked GeoTools issue

People

  • Assignee:
    Frank Gasdorf
    Reporter:
    Frank Gasdorf
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: