Polygon features are drawn wrong when not completely in the window

[waltweltonlair]

With the new stylization, feature geometry is clipped to the edge of the visible window. This results in some rendering quirks. Two examples:

• Consider a polyline drawn using a thick line style (see the attached file polylineImage). If you pan the view so that a portion of the polyline is slightly beyond the visible extent, then that portion is clipped and nothing is drawn (see the attached file polylineImageClipped). The expected behavior is that you would still see the clipped portion because of the line thickness.

• Consider a polygon drawn using a thick edge style (see the attached file polygonImage). If you pan the view so that a portion of the polygon is far beyond the edge of the visible extent, then that portion is clipped and replaced with one or more lines which follow the edge of the visible extent (added to keep the polygon closed). The thick line style is applied to these clipping lines, and results in an incorrect representation of the polygon's boundary (see the attached file polygonImageClipped).

[waltweltonlair]

Fixed in trunk with submission ​https://trac.osgeo.org/mapguide/changeset/3440.

[waltweltonlair]

Fixed in branch with submission ​https://trac.osgeo.org/mapguide/changeset/3442.

[crispinatime]

Hi,

This is an interesting submission as the polygon clipping seems to be in its entitity to be a programming renderign utility and not a cartographic requirement (unlike the thick line clipping ticket).

With my cartographic / data visualisation hat on, the map shown should represent a window onto the data, just like moving a picture frame over a raster map. Sure we have advantages with smart label placement to optimise the actual window of data displayed -- but should MapGuide be displaying a new artificial polygon psaudo-edge at the edge of the screen? This implies there is data that forms vertices and edges where MapGuide has drawn them - but these do not exist.

I understand why for rendering efficiency the clipping occurs but cartographically I personally think the polygon should just flow to the map edge and not show the clipped edge line. This is obviously a change to existing behaviour but a future flag to not show these created clipped-edge-lines could be an option? I would be interested in your / other thoughts.

The second reason the whole behavious is not consistent at present in a final MapGuide solution is that on the basic viewer with the status-bar turned on the map renderign height in AJAX is not calculated correctly so the map always renders too 'tall' - you can see this easily because panning up will pull up and expose the image part that was hidden behind the status bar. The end result of this is that only the clipping done is actually visible on the North, West, East sides of the map so the whole MapGuide end-user experience is inconsistent.

[waltweltonlair]

Since MapGuide 1.0, feature data has been clipped to the edge of the screen and the pseudo-edges have been displayed. Only recently did we receive this request to not display these pseudo edges.

As I explained above, we're dealing with two types of quirks: 1) the case where a polyline segment is clipped and not drawn, when in fact it should still be drawn (say because the line style has thickness); 2) the case where a clipped polygon segment (a pseudo edge) is drawn, when in fact it should not be drawn

The fix for the first quirk is to expand the clip region by an amount corresponding to the "thickness" of the style being applied. This ensures we don't clip away any feature geometry that would otherwise still be graphically visible inside the display area due to the style's "thickness". This applies to both polylines and polygon edges.

For the second quirk, one way to fix this is to not draw the pseudo-edges that get inserted when we clip polygons. But the fix for the first quirk also happens to address the second quirk. The pseudo-edges are currently still being rendered, but because we've expanded the clip region those pseudo-edges are now offscreen far enough so that they won't be graphically visible inside the display.

So given that the graphical result should now be correct, I don't see any value in doing more work around this. In fact, if we add code to filter out the rendering of pseudo-edges then the stylization / rendering performance will almost certainly decrease somewhat.

The issue you describe with the status bar is a separate AJAX bug, and has nothing to do with the clipping / rendering work done in this submission. The AJAX viewer needs to account for the status bar and properly size / position the mapframe.