ThinkGeo.com    |     Documentation    |     Premium Support

V12.1 - MapView.ToWorldCoordinate Returns Invalid X/Y

#1

ThinkGeo Team,

I’m noticing that MapView.ToWorldCoordinate returns an invalid PointShape X/Y the very first time that this method is invoked after the application is started. After the first time this method works just fine.

These are the basic instructions:
First time after map start–>>
MapMouseDownPoint = {1283,522}

PointWorld = MapView.ToWorldCoordinate(MapMouseDownPoint);

PointWorld = {-9757415.837908994,5143153.17437942,0}

Next time after map start–>>
MapMouseDownPoint = {1283,522}

PointWorld = MapView.ToWorldCoordinate(MapMouseDownPoint);

PointWorld = {-9758260.152503068,5143177.348816365,0}

It is the Y coordinate that is not correct. The X coordinate is fine.

Another odd behavior, and again only first time after the application is started, has to do with what happens upon resizing the application and hence MapView. If the first thing after restarting the application is to resize the application the map extent is wildly changed. Once either of these ‘first time’ things are done ToWorldCoordinate and resizing work fine.

Again, same code as in V10.6.

Regards,
Dennis

#2

Thanks Dennis,
I think this is the same as the V12.1 - MapView_CurrentExtentChanged

The ToWorldCoordinate is depend on the current extent and map size etc.The very beginning the current extent may be some old value. So if you hookup the get current world coordinate to the mouse move event. After you zoom in/out the first few results may still based on the old extent. but soon it will get the new value base on the new extent.

Thanks

Frank

#3

Frank,

This did not work like this in V10.6. You’re asking me to jump thru hoops to change my code. I view this as a bug in ThinkGeo.Core.

Dennis

#4

Thanks Dennis,
Yes. We have fixed this one. CurrentExtent get change right before the CurrentExtentChanged trigger. You can try with latest V12 nugget package.

Thanks

Frank

#5

hi Frank,

I’ve upgraded to ThinkGeo.Core V13.0.0-beta164 and ThinkGeo.UI.Wpf V13.0.0-beta183.

Unfortunately, this issue still persists.

Dennis

#6

Thanks Dennis,
I attached you a demo project. You will find when the application start I console the PointWorld. After the application load complete I have a button to get the PointWorld. The results are the same. Could you modify my demo project to reproduce the issue you mention in this Post. Could you also reproduce this issue V12.1 - ZoomLevel Change Results in Pink Tiles on the demo project. I already got the sqlite file you sent to us.

Thanks

Frank

#7

Frank,

I don’t see a demo project with your PointWorld example.

Dennis

#8

Sorry Dennis,
Here is the attachment.
Demo.zip (46.9 KB)

Thanks

Frank

#9

Frank,

I’m not yet able to recreate this in a test application. Your demo application is really oversimplified and certainly would not reproduce this issue. My application encounters this under the MapView.MouseUp event.

I’ll continue to investigate, but once again this is all same code as under V10.6.

My application does have reprojection for all the layers so I’m thinking it might be where the issue is. My test application does not make use of ProjectionConverter at this point and so I am going to add that to the code.

Dennis

#10

Frank,

Projection does not affect this issue one way or the other.

Here’s another odd thing that occurs only once right after the application is started…

If I hold the left mouse button down to pan it not only pans, but also does a zoom from Level17 to Level15.

Is there feature in ThinkGeo.Core that does such a thing?

Thanks,
Dennis

#11

Thanks Dennis,
No. This is not the feature of the V12.

Thanks

Frank

#12

hi Frank,

The action I described appears to be the same as described in this post:
Upgrade from v10.3 to v12.2 Issues

I had set breakpoints in my code on the TrackingOverlay Events and none were hit.

Also as mentioned in the above post, I’m seeing that FontSize is smaller in V12 as opposed to V10.6.

Even after upgrading to ThinkGeo.Core V13.0.0-beta167 and ThinkGeo.UI.Wpf V13.0.0-beta186 these issues still persist.

I don’t believe these to be caused by application code.

Dennis

#13

Thanks Dennis,
I set a breakpoint on the map.TrackOverlay.TrackEnded. It seems work good. I attached you the demo project.
Demo.zip (10.0 KB)

For the font size. I talked with the developer team. In the mapsuite 12 we use a different standard. So it looks smaller than before.

Thanks

Frank

#14

hi Frank,

I believe you misunderstood my last post when I stated:
“I had set breakpoints in my code on the TrackingOverlay Events and none were hit.”

I was not trying to tell you that TrackingOverlay breakpoints were not working.

What I was trying to say was that when this issue occurs my application does not get any Tracking Overlay breakpoints. Which is to say that since my application did not get any breakpoints it is not executing any code that could cause this behavior. Which does mean that the SDK for some reason is doing this Pan and ZoomIn.

Under normal operation TrackingOverlay breakpoints are received and the application code executes properly.

As far as fonts are concerned…are you saying that fonts under V10.6 were actually incorrect and they have been corrected under V12.1? You state that V12.1 is using a different standard. I always thought a font was a font. The issue for me, and I’m sure everyone else, is that now I have to go and change all of my font definitions. I have nearly 90 layers so this is going to take quite a bit of time.

Dennis

#15

Thanks Dennis,
A quick update. For the first issue. I am still trying to re-produce it. For the font size. I am discussing with the developer team. I will let you know once we have an solution.

Thanks

Frank

#16

Dennis,
We have done some enhancement for the multiple threading. Could you try the latest beta version see if this fix the issue. For the font size. it is breaking changes. You may need adjust the code to enlarge the font size a little to keep them consistent with V10.

Thanks

Frank

#17

hi Frank,

I’ve upgraded to the latest packages, but the issue still exists. I do believe you are correct that this is a timing/threading issue.

I’ve experimenting with my code to see if I can resolve this.

I’ll adjust my configuration (not code) to enlarge the font sizes.

Dennis

#18

Frank,

I’ve resolved the issue centered around MapView.ToWorldCoordinate.

The code was passing MapView.CurrentExtent to a method, which in turn modified said parameter, which had the effect of modifying MapView.CurrentExtent.

To resolve this a CloneDeep was incorporated as MapView.CurrentExtent.CloneDeep().

What’s odd is this was not an issue under V10.6.

Apologies for having troubled you with this issue.

Dennis

#19

Thanks Dennis,
Good to know it works. Go ahead let us know if you have more question.

Thanks

Frank