Open mouse4d opened 12 years ago
Nice. Looking forward to the future of the new renderer.
Sounds great :), looking forward to it
Can't wait to use it!
I should point out that this renderer is available now:
https://github.com/mapbox/mapbox-gl-cocoa
It's just not as full-featured yet as we're intending. Soon!
Awesome go mapbox!
BTW any issue in this repo tagged with v
is a nod to something that is more fundamental in the current renderer that can be solved by the new (vector) one (i.e., writing in OpenGL instead of using Core Graphics basing things on UIScrollView
& CATiledLayer
).
For some clarification on roadmap, I just added this: https://github.com/mapbox/mapbox-gl-cocoa/blob/master/FAQ.md
Thanks @incanus for the FAQ, but it didn't answer one of my most important questions: What iOS versions will it support? The current repo says iOS 7+, will it be the same after release SDK 2.x?
@mohpor I've just updated the FAQ. GL will support iOS 7 & greater, which means that moving from the iOS SDK will leave behind iOS 5 and 6.
Such a bad news :(
You can keep using the SDK for the older versions, but by the time GL is stable, iOS 8 will be out. There is already 90%+ upgrade to iOS 7 in less than a year after release, and iOS 8 only dropped the iPhone 4, so I expect similar numbers for upgrades this fall. While GLKit is available back to iOS 5, supporting iOS 7+ lets us focus on UI and UX testing for the modern platforms instead of a lot of code branching like in the iOS SDK to support the dual appearances.
I see what you're saying, but as you sure know, Location Aware apps are fundamental applications that need to cover a larger than usual demographic... I hope i can try and make it work under at least iOS 6. Thanks for the effort and let me know if I could be of any help. I have tried and answered some issues here and on SO, to share some daily burden and make you free to work on 2.x.. Cheers
Yes, your help has been very much appreciate @mohpor and I am happy to work with you to help make GL unofficially available to earlier versions.
Glad to help.
Is there any working solution for shaking RMAnnotations problem ?
@pawel-sp No, not currently. This is a possible interim approach:
https://github.com/mapbox/mapbox-ios-sdk/issues/72#issuecomment-14188749
I'm having the same problem with my RMAnnotations and it's really annoying. Any fix or workaround?
in iOS8 the problem is gone.
I have noticed some changes to UIScrollView
, including better debug logging. I'll bet they increased the precision to deal with potential larger content views for larger and denser displays.
I just found out that the problem is only gone in the simulator. In a iphone 5 with iOS8 the problem still exists.
Dang.
To update everyone and summarize the above, this is a weakness of using a literal scroll view contentSize
that maps to the actual pixel size of the whole planet once you get really far zoomed in. Each map zoom level is (2 ^ z) * 256
pixels on an edge, so z17
is 33,554,432
pixels, which runs into float
precision problems.
This is solved in Mapbox GL by rendering in an OpenGL context on screen instead of a content view with virtual pixel size. Migration path coming soon...
hi: incanus You said:“Each map zoom level is (2 ^ z) * 256 pixels on an edge, so z17 is 33,554,432 pixels, which runs into float precision problems” , this conclusion is correct, but why we can't break through this precision problems. I encounter the same problem on our 2D Map SDK. using the same technology. UIScrollView+CATiledLayer. so our problem is the same. But now we have a Solution:
This solution has a basic precondition: using double/long double to convert geographic coordinate system to UIScrollView coordinate system.
And Then: We Just need to replenish the difference using translation transform. directly to reset center using "center" property is invalid.
// Get the coordinate of annotation.
CLLocationCoordinate2D coo = [annotationView.annotation coordinate];
// using long double to convert geographic coordinate system to UIScrollView coordinate system.
long double reX, reY;
[self convertLat:coo.latitude lon:coo.longitude to:&reX y:&reY];
reX += annotationView.centerOffset.x;
reY += annotationView.centerOffset.y;
// Set center first annotationView.center = CGPointMake(reX, reY);
// Retrive the center.
CGPoint after = annotationView.center;
// Calculate the difference. We know the center will be cut to times of 2.
double dx = reX - after.x;
double dy = reY - after.y;
// Construct a translation transform.
CGAffineTransform translation = CGAffineTransformMakeTranslation(dx, dy);
// replenish the difference using translation transform annotationView.transform = translation;
Yea: using the above code. The joggle is disappeared.
Good Luck!
Yes @tabsong this is what is described above in https://github.com/mapbox/mapbox-ios-sdk/issues/72#issuecomment-29924109. However this is a pretty major refactoring and not just happening at one place in the map view code. I'd love to see this happen but we don't have the resources for it presently.
@incanus Sounds like sadness, But i respect your choice. May be some days later. at lease there exists a non-elegant solution.
So we can conclude that this bug will stay unsolved. The solutions that are described earlier in this thread are too much work to make it reasonable and the Mapbox team is focussing on the MapboxGL migration. @incanus, you're saying that this bug doesn't occur in MapboxGL, right?
Unfortunately, according to the documentation MapboxGL isn't production ready and misses some features such as offline maps and annotation clustering. So, it's either using the standard Mapbox with dancing markers or use MapboxGL and hope that things as offline maps are ready in the upcoming months. Am I right at all of this?
@florianbuerger What did you decide to do to built your indoor map app?
@incanus, you're saying that this bug doesn't occur in MapboxGL, right?
Correct. This bug is inherent to using UIScrollView
for maps and having precision problems with its API at high zoom levels because the content view is so large. Mapbox GL doesn't scroll, but actually redraws individual frames with OpenGL in response to zoom, pan, and rotation changes.
hope that things as offline maps are ready in the upcoming months
Yes. Plans for GL include offline maps and most likely clustering.
Okay, thanks.
The FAQ on MapboxGL says "The library is open source right now, but an official, production-recommended release will come later in 2015.". Does this mean that there is a big possibility that offline map support will be implemented before Q3 2015? Or is that just too optimistic?
I think Q3 2015 is a pretty fair estimate. We are considering offline use and programmatic runtime style API in GL to be flagship features, but post-1.0, and are looking at a 1.0 by midyear at latest, I'd say.
I'm beginning to suspect this issue is because of 32/64bit architecture. If the problem is apparent on iPhone 4 and 5, but not on 5S or 6 regardless of iOS version, it could be that.
@Svantulden Yes, it is exactly that way. The CGFloat in the Core Graphics on 64Bit Systems (e.g. iPhone6) is internally a double value, but on older 32 Bit devices it is a float (due to performance reasons). The Float is not precise enough to allow this kind of behavior that the ios-sdk uses, but the double value are...
Just a note that this problem can be circumvented with the rapidly-maturing Mapbox Mobile OpenGL-based renderer, which can also do raster tiles.
while scrolling the map the RMMarker and RMPath overlay "vibrates", it's like the overlay tries to "catch up" with it's normal position when the map is scrolled. It's just a few pixels, but when zoomed it looks pretty bad. this happens most probably because the -draw() method is called only when the map is moved more than just a pixel.