Rotation in V10?

Russ · July 25, 2017, 8:07pm

Some time back when I had to completely re-write our map to get over the ThinkGeo 3.0 clean slate rewrite, one of the highly desirable goals given to me was to be able to specify an arbitrary rotation for our entire map. I don’t recall the reason, and couldn’t find our forum discussion from back then, but eventually we gave up on that. I couldn’t find any recent threads on the topic, and somewhere we saw that improved rotation was talked about, so now we are wondering if we can circle back to pick that up with your V10 update?

So this is our problem.

Our actual map is composed of several layers. [0…1] raster background, [0…n] shape layers, and [0…n] dynamic “in memory” layers. These maps are often longer along 1 axis, which may or may not align with our map aspect ratio with North at the top. Our default zoom is “full extent”, which for some maps provides far less than ideal utilization of the map UI space. For instance if our map window is substantially wider than tall, but the actual map is substantially longer North to South, you see a tiny map using vertical space but wasting most of the horizontal.
So we have a significant number of users that would like to be able to say "rotate my maps to better use the window space. So maybe they want it at 70*, or perhaps 210* might better correspond to their notion of “Up” rather than forcing “North up”. This is the general use case. Note this is NOT to let the user arbitrarily click and spin things, but just to let them specify a rotation to always be applied. We ideally like to let the user specify rotation using the map and mouse, but are perfectly fine with entering the numeric degrees of rotations if interactive specification is not easily done. This is really just a “one and done” edit we need to be able to support. The key is that all 3 types of layer have to rotate together and stay aligned.
I believe it was the raster background not rotating that shut us down on this last time?
We also use adornment layers based on your “mini-map”, “compass”, and “scale bar” samples. Obviously these would not rotate with the rest of the map, though the compass would certainly need to rotate IN PLACE to show correct orientation of North. If there is a convenient way to rotate the compass in place (not with the other layers) that would be great, but I’m not at all worried about the custom drawing to orient the compass if I can get the 3 main types of layers to rotate about their center axis, and correctly participate in the various “extent” calculations based on that orientation (for things like “zoom full extent”, and calculating the zoom levels)

Ethan · July 26, 2017, 8:53am

Hi Russ,

We have a RotationProjection which is used to rotate a layer, it should support raster layer, shape layer and inmemory layers. You should want to assign it to the featureSource or imageSource of the layers.

Here we have a sample about it: https://github.com/ThinkGeo/CenteringAndRotatingSample-ForWpf/blob/master/CenteringAndRotating/TestWindow.xaml.cs

The “compass” should be named MagneticDeclinationAdornmentLayer now, it can be set projection by ProjectionToDecimalDegrees, the ScaleBarAdornmentLayer also have this property.

For mini map you should want to assign the projection to each layer inside it:

github.com

ThinkGeo/MiniMapSample-ForWpf/blob/master/MiniMap/MiniMapAdornmentLayer.cs

using System.Collections.Generic;
using System.Collections.ObjectModel;
using ThinkGeo.MapSuite.Drawing;
using ThinkGeo.MapSuite.Layers;
using ThinkGeo.MapSuite.Shapes;
using ThinkGeo.MapSuite.Styles;

namespace MiniMap
{
    public class MiniMapAdornmentLayer : AdornmentLayer
    {
        private Collection<Layer> layers;
        private int width;
        private int height;

        public MiniMapAdornmentLayer()
            : this(new Layer[] { }, 100, 100)
        { }

        public MiniMapAdornmentLayer(int width, int height)

This file has been truncated. show original

Regards,

Don

Russ · December 19, 2017, 9:59pm

Thanks. I will let the interested parties know that this should be available now, and that they can prioritize to work into our schedule as they see fit.

Oddly, I note that you are now responding as “Ethan”, but signing as “Don”.

Ethan · December 20, 2017, 5:43am

Hi Russ,

Thanks for your update.

And please don’t worry about the account name, it just renamed this year.

Regards,

Ethan

Russ · February 19, 2020, 6:31pm

Even though rotation has been a significant desire for a long time, those making priority decisions kept deferring it until now. So I’m just now starting on this by migrating my original rotation code (from before raster layers supported transforms) to the current TG library we are using (10.0.0.0). It all went very smoothly until I started testing.

Everything stays aligned until you hit 90*. At that point the raster layer changes aspect ratio from rectangular to square. You can see the effect in the images below. Both layers use a shared rotation transform, and no other transforms are applied.

Still ok. Notice how shape file (blue line) aligns with features and edge when rotated left 75*

// but when it goes to 90* left, the shape file maintains it’s aspect ratio, but the raster image has become distorted into a square

Russ · February 19, 2020, 6:36pm

I forgot to include that it’s clipping the raster image top and bottom. So it seems the “view port” aspect ratio has changed, essentially “hiding” a portion of the top and bottom of the background image. So features of the background layer remain well aligned with features of the shape layer, but the top and bottom of the raster layer are not shown.

Russ · February 19, 2020, 7:18pm

Interesting update. It’s not always consistent in what it’s producing. Notice this image is 180* from normal non-rotated image. In this one, it’s not clipping the raster image, but rather the shape file is now shifted down and misaligned with the background features. In the first image above, you can see how the shape file blue line sort of follows the outline of some of the darker features. And looking at this image, those outlines are clearly offset downward, plus the line hanging off the bottom of the background image.

And it changes from one test to another. Here is another image with only 90* left (CCW)) rotation from original.

And another more jacked up. It’s only a small amount misaligned, but the view port clipping on the raster layer is even more pronounced.

Ethan · February 20, 2020, 9:21am

Hi Russ,

Thanks to let us know this issue.

Our developer will try to reproduce it and work on it.

We want to know what’s the type of raster image and moer information for example your detail package version. If possible could you please upload your test sample with the test data, it should be helpful.

Regards,

Ethan

Russ · February 20, 2020, 5:43pm

I doubt it matters, but the raster is a jpeg.

I would be happy to provide you with the “detail package version”, but you’ll need to tell me how to do that. I thought it might be in the Product Center, but that doesn’t seem the case. I looked at the NuGet intalled list, but that’s a bit of a mess. Installed Version shows version 10.1.0, but each package has a different version including 10.6.0, 10.6.2, 10.6.7, and 10.6.12. All those are annotated with “Latest Stable”, so hopefully that helps without having to laboriously detail each package.

Russ · February 20, 2020, 9:17pm

Not sure if it helps, but when interleaving zooming and rotating, the problem seems to be exacerbated.

Ethan · February 21, 2020, 8:40am

Hi Russ,

I think you should also render the image by NativeImageRasterLayer and rotate it by RotationProjection, if you are using other class please let me know.

I build a sample then reproduce that, it looks the image resize follow rotate angle get changed, our developer will look into it.

Any update I will let you know.

Regards,

Ethan

Russ · February 22, 2020, 1:49am

You are correct in what was used. Also, the same RotationProjection is used for all layers.

Thank you. Looking forward to answers.

Ethan · February 26, 2020, 8:57am

Hi Russ,

Thanks for let us know it, this is a complex issue.

Our developer is working for it, any question or update I will let you know.

Regards,

Ethan

Russ · February 26, 2020, 7:12pm

Thank you, looking forward to it.

Ethan · February 27, 2020, 8:13am

Hi Russ,

Attached is the sample about how to make it works 8619.zip (37.2 KB)

We need to modify the extent like this:
winformsMap1.CurrentExtent = rotate.GetUpdatedExtent(winformsMap1.CurrentExtent);

It looks this API is not so easy to use, I think we will enhance it in future version.

I hope that solve your problem.

Regards,

Ethan

Russ · February 27, 2020, 7:22pm

Unfortunately, we already do that, and have since the beginning. Other than dealing with other layers (like compass), and different variable names, it’s exactly the same.

And your sample isn’t even reasonably acceptable.

First, when at/near 90* it just truncates everything as it forces the longer width to clip to match the shorter height. This is doing nothing but demonstrating the clipped view window I already reported.
Given that our maps are sized to utilize almost all the space, that simply doesn’t work. And our maps are generally almost twice as wide as they are tall, this is even more problematic.

Also, it doesn’t include a shape layer. As shown in my images, they don’t get clipped when at/near 90 when the image does get clipped. It’s just rotating a raster image, which apparently is all they tried and called it good, “ship it”.

On top of that, if you keep rotating, it gets completely nuts as more and more of the map along both width and height gets clipped (not just the long side). It’s not always reproducible, but seems to require interaction between zoom and rotate, something that we need to work correctly. See image taken from your unmodified project for reference.

So again, all you did was post an example of nothing but a raster layer rotating, and failing exactly as I reported, without even an attempt to include a shape file layer for reference.

Russ · February 27, 2020, 8:09pm

Also, please remember that there is one reported problem that isn’t even part of your 8619.zip. That problem is that when you include a shape file with features that must align with features on the background image, AND you get into that unpredictable state caused by changing zoom and rotating, the layers become increasingly misaligned.

But you (they) can’t even consider whether that problem is managed by a “work around” if a shape layer isn’t included.

I’ll also add that we also use InMemoryFeatureLayer layers on top of the shape layers, which all need to remain aligned without arbitrary clipping. I didn’t include that in my initial report because the shape file layer is sufficient to see the problem, and they seem to be staying aligned with the IMMFL layers when rotating and zooming. Omission of that detail was intended to keep it simple, but I thought I would add that point in just for reference.

Ethan · February 28, 2020, 9:33am

Hi Russ,

My apologies. I don’t know your code so when I reproduce it my sample hadn’t set the rotated extent, after that I found add it the image don’t get stretched in most angles. I think that should be the reason and your code should hadn’t set it also. I hadn’t found a shape file match the image file to test, so I used our states.shp but it didn’t shows the match issue, then I removed it from sample.

Today I test it follow your information, I found the issues include image get clipped in special angle, exception get thrown when zoom&pan&rotate works together.

In fact our rotate is not direct rotate the source image, it used the projection to simulate a rotate. Projection work for vector layer for example shape file, so it have some issues when used to rotate an image for example the raster layer. I am not sure whether the issues can be solved but our developer will keep work on it.

In fact there is a better solution, you can try our WPF edition version 12, WPF edition support perfect rotate without the issues, because it rotate the map in control level. You can try it from our simple sample for example: https://github.com/ThinkGeo/QuickstartSample-forWpf.NetCore, when the map shows, you can press left “Alt” in keyboard and rotate the map by mouse. You can also set it in code to mapView.RotatedAngle;

Our latest version 12 support .net framework 4.6.1 also. And your application can keep to use WinForms, here is a guide about it: https://blog.thinkgeo.com/2019/05/23/using-the-thinkgeo-ui-control-for-wpf-in-your-winforms-app/

If you have any question about it please let us know. I hope it’s helpful to solve your issue, any update if we get in rotate projection I will let you know also.

Regards,

Ethan

Russ · February 28, 2020, 9:01pm

Thank you.

I don’t think we’ll be porting it to WPF. The cost would far outweigh the benefit.

Are you saying that the WinForms v12 library works for rotation of raster images? If so, that’s probably the best bet. And for reference, we are on .Net 4.8

As for rotating the image after rendering, that would seem clearly the best choice. Too bad they didn’t do that in WinForms

Ethan · March 2, 2020, 6:44am

Hi Russ,

In fact your can keep your application in winforms, just use the WPF control to render map. And in same version, the code to render on WPF is nearly the same with Winforms, I think you can did a quickly test on that.

Because special feature in WPF we can implement the rotate in control level, but we hadn’t found a way to do the same thing for winforms.

If you choose rotation projection way it’s the same in V12 and V10, the rotate control is new feature in V12.

Regards,

Ethan