WhirlyGlobe
WhirlyGlobe copied to clipboard
(iOS) 2D map viewWrap issues on different library versions
Hello, I've been trying to update from v2.5 to newer versions of the library and I faced some issues during the process. The most important happens when trying to setup the 2D map with viewWrap set as true, as my purpose is to have an horizontally continuous flat map as I currently do with v2.5.
First of all I tried with the most recent binary version (3.3). As first trial I converted my previous .png tiles to mbtiles format to be able to follow the tutorial as it is, however even setting the viewWrap as true the map is only displayed one time. I was wondering if it could be due to an error converting the files to mbtiles so I made another try using the .png tiles and loading them using the new MaplyRemoteTileInfoNew and passing it to the MaplyQuadImageLoader. No luck, the map is not replicated and is displayed only once.
Is there identified any issues related with viewWrap under v3.3?
After that, I decided to try the most recent version previous to the new Metal v3.x. I added the library as submodule to avoid issues with the signature and I get it working using v2.6.7 tag. In this case, the viewWrap works as it used to work, and the map is continuously displayed horizontally. However, this time I noticed that viewWrap also tries to wrap vertically causing undesired movements when you are moving around the poles. I tried to limit the view extents but it doesn't seem to work.
Is there any way to block vertical wrapping under v2.6.7 or any workaround that could do the trick?
We dropped view wrapping support in 3 on iOS and haven't put it back yet. None of the sponsors of version 3 used it and no one on support uses it either.
It's on the list for features we would like to get working again. Tim took a pass at it recently, but ran into some problems that I need to look into. I'm not sure when I'll get to that.
Of course, if a support customer or client needs it we'll get it working. But until then, it'll have to fit into overhead time and there's never as much of that as we'd like.
It's back in develop.
Thanks for bringing it back to develop.
We are trying to use this new version and we wonder if there is any stable branch that contains this feature or we should go directly with develop. Is there any plan to release a 3.6 containing the fix?
We largely follow our own development needs at this point. So yes, there will be a release, but I would guess it's a few weeks away after we finish a big set of changes for our own extensions.