Is Map.ExtendBuffer completely bugged or am I being stupid?

Mar 8, 2013 at 2:12 PM
Edited Mar 8, 2013 at 2:15 PM
I turned on Map.ExtendBuffer, and now everything is screwed up. Pixel dont project correctly anymore and panning and zooming is impossible.

I tried to find the bug, and I found this:

        public static Coordinate PixelToProj(this IProj self, Point position)
            double x = Convert.ToDouble(position.X);
            double y = Convert.ToDouble(position.Y);
            if (self != null && self.GeographicExtents != null)
                x = x * self.GeographicExtents.Width / self.ImageRectangle.Width + self.GeographicExtents.MinX;
                y = self.GeographicExtents.MaxY - y * self.GeographicExtents.Height / self.ImageRectangle.Height;
            return new Coordinate(x, y, 0.0);
But self.GeographicExtents has the width of the buffer, and not of the map display...

Also, self.ImageRectangle is the map display pixels divided by 3, which I dont get either...

Please, am I going insane? How does the math add up here...

I have no idea where to start fixing this either...

Thx for help.
Mar 15, 2013 at 7:38 PM
Hm looks like nobody knows, hu?
No wonder, actually.

Additional info:

The "self.ImageRectangle" ends up being 0.33 x the size of the Map control. Obviously the idea is that "self.ImageRectangle" is 0.33 x the size of the buffer, but for some reason the width initially is set to the width of the map control, and not the buffer width. I did not find out why this is, it does not make sense, but it's impossible to find out with this inheritance nightmare.

All the functions that could fix it like "ResetBuffer" "ResetExtent" do not work because of the faulty Pixel Projection.

When I debugged it deep inside the core of DotSpatial I fixed the Pixel Projection functions to work on the map control, like they should.
However, that was a useless fix, as the core obviously uses the Pixel Projection functions somewhere deep inside as if they were Buffer Projection functions.

So I ended up with a fixed problem, but nothing else worked anymore.

Also I have to say, the whole DotSpatial project is very hard to debug.

Having lots of interfaces and mini-classes is really nice to show off if you are a scientist, but really bad for a big project, because it will end up being like a gigantic puzzle. Not every class needs it own interface class. Yes, some do, and yes, this project probably needs some.

But I was reading through that whole mess of Symbol and following the inheritance down to the ground, and I finally realized that who wrote it lost track himself of everything the class actually can do. For example, there is an Angle property, but there is no constructor allowing you to specify one. Then there is a scale property, but its only a double, so you cant scale differently in the x/y axis.

Please, it should all be consistent, accessible and structured, so people can contribute code.

It took me 3 days just to find out how to draw a correct ellipse (for example 5 nm wide / 10 nm high) and I had to change code in like 20 different classes that have nothing to do with the actual problem, because somewhere down in the stack the scale was declared as a double.

Also, it's very hard to find out where the draw code is, cause it is hidden deep inside the classes and there are lots of code sections that never actually get executed. Example given: Drawing of Symbols - Circles. I have actually worked with full commercial grade 3D engines that were a lot easier to understand, simply because the code flow was clear.

I really suggest refactoring and cutting down on OO structures that are not 100% needed. Yes I understand that some are needed. But the most important principle in programming is KISS - keep it simple and stupid. Something like this guy here wrote:

Yes I am a little bit annoyed right now. Sorry.

I really wanted to contribute some code, but every small change means I have to change something in all the inherited classes, so it leads to me changing tons of files.
May 29, 2013 at 2:09 AM