Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Holes at North and South poles #2

Closed
tristanseifert opened this issue Sep 15, 2012 · 13 comments
Closed

Holes at North and South poles #2

tristanseifert opened this issue Sep 15, 2012 · 13 comments

Comments

@tristanseifert
Copy link

I've been toying around with this framework a bit recently, and I've got to say it's very nice, but I've noticed some issues — namely the fact that there's a gaping hole at the North/South poles when using anything but the local low-res textures:

Local imagery

And now with the remote OpenStreetMap textures:

OpenStreetMap textures

Is there any way to fix this?

@mousebird
Copy link
Collaborator

Right, good eye and nice description. Here's what's going on.

The first data set is in geographic WGS84 and covers the whole earth, so no hole. The second data set (Open Street Maps) is in Spherical Mercator and covers everything up to that little section of the poles. That's just in the nature of the map projection, as it was designed for flat maps.

The fix is to stick colored caps at both the north and south poles. Those caps may or may not need to be adaptive. I'd have to see.

It actually makes an amusing demo and a comment on web mapping's use of Spherical Mercator. To professionals in the field it also says "Hey look, WhirlyGlobe is coordinate system savvy". I intended to fix it when someone articulated why it was messing with their app.

So please, tell me what you're up to, why this is causing you problems and I'll take some time out to make the caps.

@tristanseifert
Copy link
Author

@mousebird, Thanks for that quick response. I figured that the way the maps were made had something to do with that. I was actually pondering on just adding white (or whatever colour they need to be to match the map style) caps there, but I simply have no real idea how (I'm not an OpenGL guy by any means.)

Anyways, the app I'm writing basically overlays various information specified by the user onto the map — things like climate regions, elevation data, and so on. The holes on the top don't ruin the usability aspect of the app, but in my opinion they're just kinda distracting when you're viewing very far north/south regions. Many users of this app aren't gonna be very technically inclined, so most would write that behaviour off as a bug. The app'll also get used in an education environment, and most students get distracted real easily by things like that.

Like I said, I'm not an OpenGL guy, but is it perhaps possible to 'trick' OpenGL into loading plain coloured textures for regions where there is no data available? Like setting the plain texture as the default, and if a texture is available, that texture could be displayed, clearing out the existent plain texture. Perhaps this controllable by some sort of boolean value that can toggle them on and on, and their colour could also be configured.

Thanks for the quick response.

@mousebird
Copy link
Collaborator

You have to actually build the geometry to get those caps in place. It's not too hard on my end.

It might get done this week, if not then shortly thereafter.

Your app sounds cool so feel free to post some pics when you're further along.

@dindonkey
Copy link

First of all, congratulations! It's amazing to have such kind of component "plug and playable" as viewcontroller...and it works very well!

What about to create a vectorial polygon (circle) and load it over the mbtiles? (like other vectorial stuff e.g. country borders etc) ?

@mousebird
Copy link
Collaborator

Thanks!

If you needed that for a workaround right this second, then that would probably work fine.

I'm planning on adding that to the data layer itself so it'll be as intelligent as it needs to be, which is hopefully not very, but realistically a little bit.

It's on the critical path for a client, so it should be fixed shortly.

@mousebird
Copy link
Collaborator

I've got this fixed in the develop branch (not that I suggest you switch over). I should put a new component up in the next few days.

@SiarheiBarysenka
Copy link

Thanks for your work!

Is there any possibility to load both maps textures together without the hotspots? I mean, it would be nice if I could load the poles from the local textures (for example, by using method addSphericalEarthLayerWithImageSet) and the rest of map - from the remote server. I try to do this just by calling those both methods one after another, but the map then becomes full of the hotspots. What do you think about it?

@mousebird
Copy link
Collaborator

What I've implemented now is to stretch the texture upward across the poles. It works okay if the texture is constructed right, but can look a little goofy if not.

@mousebird
Copy link
Collaborator

What I've implemented now is to stretch the texture upward across the poles. It works okay if the texture is constructed right, but can look a little goofy if not.

Local imagery

So I'm open to other approaches. One would be to simply use a color. You could make them white.

Another would be to provide two textures, one for each pole. Then I would just project those directly on to the (roughly circular) polygon I make at the poles. Well, it's not quite that simple, but it's a good description.

Using two layers for this purpose seems a little gratuitous so I'm inclined to do something less memory and CPU intensive.

@mousebird
Copy link
Collaborator

Oh, as to the multiple loading question. That's really another issue, I think.

@SiarheiBarysenka
Copy link

So, there is another little issue. If you enable the country boundaries on the map or if you place markers with the coordinates of any city, you will see that boundaries and markers are in slightly wrong place. That's because of inaccuracy of coordinate system, and if you try to set it up more precisely it will give an effect.

In method -initWithBaseURL:ext: in file NetworkTileQuadSource.mm there are lines
GeoCoord ll = GeoCoord::CoordFromDegrees(-180,-85);
GeoCoord ur = GeoCoord::CoordFromDegrees( 180, 85);
So setting the value 85.05113 instead of 85 in both cases will give an effect.

P.S. I'm sorry for the details, but it may be useful =)

@mousebird
Copy link
Collaborator

Very useful! Thanks, that is a mistake on my part.

I'm correcting it in the master branch and I'm just about to put out a new Component distribution anyway.

@mousebird
Copy link
Collaborator

I've added the poles based on the colors in the textures at the top and bottom, respectively. It works... well enough. We'll see.

The coordinate bug in the NetworkTileQuadSource is also fixed.
master branch has been updated and a new Component distribution (1.01) is uploading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants