-
-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added rotation support for viewport and WPF renderers #11
Conversation
... there is a slider in the sample WPF application you can use to test out the map rotation |
hi, im away right now. I hope to look at this the coming days. Did you notice my comments at issue #10? |
Didn't see it until just now.... I can see pros/cons to both approaches. I think the first approach of I ended up taking the second approach in which I rotate the individual Looks like the rest of your comments are in line with what I did. Sent from my "smart" phone
|
The WindowExtent was represented by a BoundingBox which needs to be axis-aligned since it only stores min and max points. If the viewport is rotated, the actually visible extents (WindowExtent) will not be axis-aligned. Added the Quad class which stores 4 corner points that do not have to be axis-aligned and used this class to represent the Viewport.WindowExtent instead of BoundingBox so it would contain the proper values when rotated.
Improved rendering of tiles to hide lines between tiles. Added IViewport.WorldToScreenUnrotated() which goes along with IViewport.WorldToScreen(). The first converts world coordinates to screen coordinates assuming the screen isn't rotated while the later does a full conversion taking rotation into account. The WorldToScreenUnrotated() is useful for placing WPF elements in cases where a transform will handle the rotation portion of the positioning.
Had a chance to look into this? About to start integrating this feature into my application and it would be good to know which rotation approach you're going to take as my other drawing items will depend on it. Thanks |
I will try to look at this tomorrow. |
Thanks a lot! I did not have time to look at the changes in detail. I hope I can give more feedback later. I will try to add rotation to OpenTK as well, and will learn more about the rotation code in the process. If I understand correctly you rotate the whole canvas and then counter rotate the labels. This way most of the code will stay intact. I saw you even made sure the stacklayels function sitll correct, awesome. Using the Quad in the Viewport with the ToBoundingBox on top is a fairly simple solution. The name 'ToBoundingBox' suggest a conversion but that is not really what it does, better to use 'GetBoundingBox', which is in line with the IGeometry.GetBoundingBox. |
Glad to help. Changing to GetBoundingBox makes sense. Actually, I did not rotate the entire canvas that way the screen If you want the canvas rotated instead of the elements, that probably On Fri, Sep 19, 2014 at 8:07 AM, Paul den Dulk notifications@github.com
|
When the viewport is rotated, the IViewport.Extent is expanded to include the rotated rectangular view. Simply expanding the viewport's extent to be the circumscribed rectangle around the rotated viewport makes the logic easier and eliminated the need to change the fetcher or the BruTile library.
Along with Rotation, the IViewport has a new WindowExtent property which represents the visible bounds of the viewport. Since the IViewport.Extent box is rotated, some of it will be outside the visible region.
I still need to correct the pixel rounding or expand the tiles by 1 pixel when the viewport is rotated as sometimes you can see the tile borders. However, works well enough to see what you think.