slideToAndCenter only work while most zoomed in about mapview HOT 19 CLOSED

wierd... this was happening to me before the update, and the patch should have fixed it... i was using coordinates at runtime (user taps)... as mentioned in the update readme, the positioning has gotten a little crummy and i need to do a thorough review of all that (unless some kind soul commits a fix).

I'm guessing you're using fixed pixels - if you want to hack it for now, the changes were in the getPosition returns (https://github.com/moagrius/MapView/blob/master/src/com/qozix/mapview/MapView.java#L867) and in addMarker (https://github.com/moagrius/MapView/blob/master/src/com/qozix/mapview/markers/MarkerManager.java#L29) and (https://github.com/moagrius/MapView/blob/master/src/com/qozix/mapview/markers/MarkerManager.java#L35)

HTH, LMK how it goes.

from mapview.

Yes we used fixed pixels.

I'll see when I can hack into it.

from mapview.

could it be link to mapView.setScaleToFit(false); ?

Btw I'm on another project now so I won't be able to hack into it...

from mapview.

np.

no it's not linked to setScaleToFit - I moved responsibility for positioning to several class and am paying for it now - I need to clean that whole bit up.

from mapview.

Any luck cleaning it up ?

from mapview.

honestly i just haven't had the time - been slammed - i'm hoping to make an update Saturday; failing that it'll be next week.

If you're only using pixels, I'm pretty sure I can tell you a couple lines to change to make it "work" for now

from mapview.

I'm not in a hurry so that's fine
On 18 Apr 2013 19:21, "moagrius" [email protected] wrote:

honestly i just haven't had the time - been slammed - i'm hoping to make
an update Saturday; failing that it'll be next week.

If you're only using pixels, I'm pretty sure I can tell you a couple lines
to change to make it "work" for now

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-16590238
.

from mapview.

This was a quick fix - it's done on my local build and appears to work property with both coordinates and absolute pixel values. As mentioned in other comments today, I'm in the middle of a big update and probably won't commit for a while, but it has been addressed. I'll leave the issue open until it's committed and we're confident that everything is working as expected. Thanks for all the help so far.

from mapview.

thank you ;)

Benoit Billington

On Sun, Apr 21, 2013 at 12:17 AM, moagrius [email protected] wrote:

This was a quick fix - it's done on my local build and appears to work
property with both coordinates and absolute pixel values. As mentioned in
other comments today, I'm in the middle of a big update and probably won't
commit for a while, but it has been addressed. I'll leave the issue open
until it's committed and we're confident that everything is working as
expected. Thanks for all the help so far.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-16712337
.

from mapview.

I did a quick test and it didn't work out

I guess I did something wrong, I'll look more during the week.

I have tried putting with and without the 3rd parameter (absolute: true) with no luck

The slideToCenter was still buggy and my marker positions were also wrong but I previously used a correction in order to place them so maybe this is the problem.

To be investigated further during the week

from mapview.

The sample project makes use of slideToAndCenter, and uses both pixels and coordinates. Might be worth a look.

from mapview.

I bet I know what happened... So the signature slideToAndCenter that accept pixels (either because you passed a boolean true to the last parameter, or because there's no geolocator) scales the x and y values for you. Some of the support classes manage scale internally, but some don't - this is largely intentional though, so that a user can use the same set of points for adding markers, sliding to those markers on click, showing callouts relative to that marker, draw paths based on those positions, etc, without have to constantly recalculate position. The x and y values are assumed to be relative to the map at it's full size ( full size = largest zoom level at scale 1.0f). My guess is that you're using pixels appropriate to the current scale state (possibly scaling the base value).

If you want to use pixels that aren't scaled, I'm pretty you can use the superclass's (ZoomPanLayout) slideToAndCenter(Point) signature, otherwise just use pixel values as they'd be at the map's full size.

LMK if that helps.

from mapview.

btw I did not have time yet to look into this sadly :(
Maybe next week

from mapview.

np - i think it's fixed but will leave open until you confirm. no rush

from mapview.

Ok this is working fine, we had some trouble with the markers but they got resolved by changing using the following anchors : setMarkerAnchorPoints(-0.5, -1.0)
I thought it should be 0.5 & 1.0 but it worked best with negative values

from mapview.

yeah, I "flipped" anchors last update (so they were "natural") - I usually use negative values too, but I think it makes more sense this way. Thanks for confirming.

from mapview.

So now it is supposed to be positive values? because I had to use negative to have the effect I wanted

from mapview.

I would assume that generally most people will use negative values. Previously, I was "flipping" it myself, but I didn't think that was appropriate.

Previously, it was (psuedo-code):

view.x = view.layoutparams.x - (view.width * view.anchorX);

As you can see, I use a minus. This isn't really semantic - it should be plus. Now it's

view.x = view.layoutparams.x + (view.width * view.anchorX);

So if you want it to center along the x-axis, you'd use -0.5f (which is pretty common for google-maps style markers)

However, there are many situations where you want to offset it differently (situations I've encountered in production use of the component, for example on a small area with big markers where we wanted the marker to be positioned completely within the bounds, and never get cut off). In these cases, you might want to offset by a positive value, so would pass positive floats.

The "standard" google map style marker (which points down at the position it's indicating) would use -0.5f, -1.0f (negative half width, negative full height).

Hope that makes sense.

from mapview.

yep all clear now :) thanks !

Benoit Billington

On Fri, May 3, 2013 at 10:40 PM, moagrius [email protected] wrote:

I would assume that generally most people will use negative values.
Previously, I was "flipping" it myself, but I didn't think that was
appropriate.

Previously, it was (psuedo-code):

view.x = view.layoutparams.x - (view.width * view.anchorX);

As you can see, I use a minus. This isn't really semantic - it should be
plus. Now it's

view.x = view.layoutparams.x + (view.width * view.anchorX);

So if you want it to center along the x-axis, you'd use -0.5f (which is
pretty common for google-maps style markers)

However, there are many situations where you want to offset it differently
(situations I've encountered in production use of the component, for
example on a small area with big markers where we wanted the marker to be
positioned completely within the bounds, and never get cut off). In these
cases, you might want to offset by a positive value, so would pass positive
floats.

The "standard" google map style marker (which points down at the position
it's indicating) would use -0.5f, -1.0f (negative half width, negative full
height).

Hope that makes sense.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-17416918
.

from mapview.