Pixels per degree lat/lon should be independent of viewport size

[jbeezley]

In all other mapping libraries, when you resize the window the visible bounds change but the zoom does not. In geojs, they both change. This makes it impossible to make features with styles given in pixel distances (point radius, line width, etc.) to be consistent.

[manthey]

I actually like this feature to some degree. For the geoapp (now named Minerva), I want to be able to copy a page url (generated whenever the map is moved or scaled) to another browser or window and ensure that all of the area of the map in the original is visible. This way, I can share a map I'm looking at and not worry that the recipient is using a tiny screen and won't see the features I thought were important.

I'm not against changing the behavior; I just wanted to present a use case.

On Thu, Jun 18, 2015 at 4:34 PM, Jonathan Beezley notifications@github.com wrote:

In all other mapping libraries, when you resize the window the visible bounds change but the zoom does not. In geojs, they both change. This makes it impossible to make features with styles given in pixel distances (point radius, line width, etc.) to be consistent.

— Reply to this email directly or view it on GitHub https://github.com/OpenGeoscience/geojs/issues/399.

David Manthey R&D Engineer Kitware Inc. (518) 881-4439

[jbeezley]

I would argue in favor of using map.bounds for that use case.

[aashish24]

@jbeezley just wanted to understand this. So even if you do pixel perfect tile rendering at zoom level 1 you can only cover 512x512 viewport size. So now if the user expands the window viewport, then we will have to get to the next tile zoom level to cover the entire screen or else things will look blur. Are you saying that do that but not modify the zoom level from API point of view? So then the user will get the same zoom level value as before?

[jbeezley]

That is a fairly rare scenario, but yes, this is what google maps and leaflet do in that scenario. I'm not sure what their api says the zoom level is when that happens. I assume the zoom level returned from the API will always be the zoom level of the tiles shown. In which case resizing the window would in fact trigger a zoom event. For compatibility with other tiled image viewers, we should guarantee that

1. The tiles loaded are of level floor(map.zoom()).
2. The tiles are pixel perfect at integer zoom levels.
3. The above don't depend on the window size.

[aashish24]

talked to @jbeezley I got the essence. We will fix it when we do the orthographic projection. (viewport clipping that is when we make the window size smaller instead of bringing low res tiles to fit the viewport).

[manthey]

In order to make the tiles pixel-perfect at integer zoom levels, we need to have the map center always snap to coordinates that correspond to a pixel-perfect location. Should this be an option, or should we always do this?

[jbeezley]

I'm not sure. In parallel projection, it would make sense to enforce this (I assume that is what other mapping libraries do). For perspective, it makes less sense. I'm not sure of consequences of doing it anyway in terms of performance and interactivity.

[manthey]

For the vgl side of things, the enforcement could be at a single code location where we calculate the view matrix. It wouldn't affect performance in a noticeable way.

[aashish24]

@manthey I am not entirely sure why the map has to snap to particular coordinates from GL point of view. Can you describe it in bit more detail?

[manthey]

This only applies when we are at integer zoom levels.

Either (a) we can snap the coordinates so that the coordinates of the textures are perfectly aligned with the pixels of the OSM tiles, or (b) we have to change the OSM shaders to snap to the closest pixel in the texture. Otherwise, you'll get interpolation between texture pixels for all pixels.

[manthey]

Feel free to come by for a demo.

[aashish24]

Okay, I would phrase it otherwise. The camera will do what it has to do. The tiles and the shader then has to find the center of the texel in that case. I will stop by.

[jbeezley]

Done in #410.