[mapserver-dev] Scales and raster maps

Fri Aug 9 02:28:24 PDT 2013

Am 2013-08-09 10:51, schrieb thomas bonfort:
> snip ...

> The ambiguity I'm referring to is that if you are supporting multiple
> clients, you are also possibly supporting multiple SRSs and this means
> multiple ground units. i.e. there's an ambiguity when you've defined
> your map resolutions in meters per pixel, and you receive and
> epsg:4326 request which is expressed in degrees per pixel (even worse
> in this case: the mapping from degrees per pixel to meters per pixel
> is going to be latitude dependant).
> As Edward pointed out, we can go back to look at layer->units or
> map->units to determine which ground unit is being used to define the
> layer min/max resolutions. This is already a first ambiguity.
> Secondly, the layer->units and map->units are more or less used to
> define the ground units of the data sources, i.e. might be completely
> different than what is needed to determine min/max layer resolution
> limits you are talking about (which need to be consistant throughout
> layers).

Your're completely right, and now I understand what you mean. And I 
don't have a solution at hand. I was just planning ahead of some 
projects and the issue arose that I couldn't correlate the clients 
requests 1:1 to map styles. Nevertheless the DPI scale calculation 
bothered me already for years, but more subconscious. And now it broke 
free ;-)

>
> tl;dr : using resolution instead of scale is preferable for digital
> maps in the vast majority of cases. however there are a number of
> corner cases that need to be addressed.

Of course, but I really never meant to replace the existing system with 
the other. I just think it would be nice to have another, easier way to 
sync web clients with mapserver by having another mean for defining 
style rules. Because right now I only have the SCALEDENOM parameters 
around for switching styles and they are not precise/exact enough for me 
due to differently implemented rules concerning scale or the completely 
missing implementation of it on behalf of the client ...

It's not only the Javascript map clients, but also the proxy/tms 
clients. Even WMS request are done by the resolution concept and are not 
requested by scale ...

>
> another point: if you factor out dpi completely and only rely on
> pixels per unit, how do you differentiate a retina request from a
> 72dpi request? As you're going to serve the same image, you're going
> to end up with either too small or too large features depending on the
> device.

Don't know, but wouldn't it be on the client to decide whether to 
request a retina image? But even the web designers still struggle to 
deliver the right image to a device. Left alone the approx. double 
amount of data to transfer for the same content ... maybe images aren't 
good anymore for this kind of dilemma and vector tiles are the way to 
go, but I really don't know :-)
One solution could be to have a highres/retina mapfile and a standard 
one and then decide with media queries which mapfile to query. I don't 
think this is solvable by just using one mapfile. From what I know this 
is what the web designers do - but they're struggeling too with that 
issue http://coding.smashingmagazine.com/2012/08/20/towards-retina-web/

Frank

>
> --
> thomas
>
>>
>> Problems arise when a client software comes into play that doesn't have the
>> same concept for scales/dimensions as Mapserver does, like my QGIS example
>> from the last post. Then the client gets maybe a wrong map delivered and
>> this can be avoided when we had a scale independent mechanism for
>> determining style based "breakpoints".
>>
>> I hope this is a bit more clear,
>>
>> Frank
>>
>>
>>
>>
>> Am 2013-08-09 10:07, schrieb thomas bonfort:
>>
>>> Frank,
>>> While I again agree with all you have said, you have not responded as
>>> to how to treat the "ground unit" ambiguity. If I'm not mistaken, you
>>> are proposing to replace the dpi ambiguity with a ground unit one.
>>>
>>> --
>>> thomas
>>>
>>> On 9 August 2013 10:02, Frank Broniewski <brfr at metrico.lu> wrote:
>>>>
>>>> Hi Thomas,
>>>>han what is needed
>>>> Am 2013-08-09 09:11, schrieb thomas bonfort:
>>>>
>>>>> Frank,
>>>>> While I agree with you that the concept of "scale" is not suited for
>>>>> digital maps, I'm not seeing it go away as it is the the only metric
>>>>> that gives you a tangible sense of "what should I be displaying when
>>>>> I'm zoomed in at a given level". more inline...
>>>>
>>>>
>>>>
>>>> my point is probably a bit academic and I really don't want to replace
>>>> the
>>>> (existing) scale systems in our web mapping applications. Problem is that
>>>> the scale that you are using for the determination of what you want to
>>>> display is totally wrong. When you deliver a map with a certain pixel
>>>> resolution (e.g. 800x800 pixels) it's scale varies greatly depending on
>>>> the
>>>> output device. OGC defines a pixel with 0.28^2 mm, the Iphone has a pixel
>>>> size of 0.0779^2 mm. So the "real" dimension of map is totally different
>>>> depending on the device and therefore the scale.
>>>> It's maybe the word scale that bothers me here, because it is not *the*
>>>> map
>>>> scale we refer to when we talk about maps, but it is a ratio of real
>>>> world
>>>> dimensions against a internal setting.
>>>>
>>>>>
>>>>> snip ...
>>>>
>>>>
>>>>
>>>>
>>>>> 1. Openlayers allows you to work with scale *and* resolution, which is
>>>>> even more confusing.
>>>>
>>>>
>>>> I know, it wasn't probably the best example taken but I think this is
>>>> something to consider. A two way approach ...
>>>>
>>>>
>>>>> 2. While pixels per ground unit is great for tiling because "ground
>>>>> unit" is strictly defined by your grid definition, this does not fit
>>>>> with a mapserver where you want to define scale-based ruled rendering,
>>>>> but you have no idea what the ground unit will be (i.e. depending on
>>>>> the request, it can be meters, degrees, feet, miles, nautical
>>>>> miles....)
>>>>
>>>>
>>>>
>>>> Again, your scale is based on wrong assumptions because you do not know
>>>> the
>>>> output mediums resolution at all. Leaving the DPI/PPI issues aside, you
>>>> simply cannot know what dimension your map will span on the output
>>>> medium.
>>>> Scales need to be precise. If a user requests a map at a scale of e.g.
>>>> 1:20.000 the scale needs to be the same across all output mediums. With
>>>> paper maps (and PDF) it's easy because you know the dimensions. But with
>>>> raster maps it's virtually impossible to know.
>>>> And I think it is more precise, better easier, to define a style for a
>>>> pixel
>>>> with 5mx5m resolution than for a somewhat vague 1:20.000 scale (numbers
>>>> are
>>>> not related).
>>>>
>>>> Other problems arise when a client software doesn't have the same
>>>> assumption
>>>> about the DPI setting like Mapserver has (or you have defined in the
>>>> Mapfile). I found this post on the QGIS hub [1] where the map layout is
>>>> broken because QGIS does have another view on the clients DPI as the OGC
>>>> has. Because then 1:20.000 isn't 1:20.000 anymore and the wrong map gets
>>>> delivered to the client.
>>>>
>>>>
>>>>>>
>>>>>> Would this be possible to implement along the DPI/scale setting? I
>>>>>> think
>>>>>> this would be handy to have and would be also more future proof than
>>>>>> the
>>>>>> DPI/scale setting. Since this measurement is not based on an arbitrary
>>>>>> estimated value but is based on real output dimensions that is the
>>>>>> pixel.
>>>>>> Well, most of the time I mean ;-)
>>>>>
>>>>>
>>>>>
>>>>> What are you proposing concretely ?
>>>>
>>>>
>>>>
>>>> What I would like to -have- see as an addition is another way of defining
>>>> my
>>>> cartography rules. Something like the resolutions from Mapproxy (to leave
>>>> out OpenLayers for this time, even if Mapproxy isn't a cartography tool
>>>> by
>>>> itself) . I'd find it really helpful to make my styles dependent on pixel
>>>> to
>>>> ground units ratio than scales. May it be feet per pixel, meters, km or
>>>> whatever. To speak in Mapfile terms I'd like to have an addition to the
>>>> MIN-
>>>> and MAXSCALEDENOMINATOR parameter. Something like a MIN- and
>>>> MAXRESOLUTIONDENOMITATOR. The resolution itself is always easily
>>>> calculable
>>>> because you know the map's extent and the pixel output size. Having this
>>>> mechanism available would decouple Mapservers output from any assumptions
>>>> about the client.
>>>>
>>>> Just to repeat it: I don't think it is feasible to remove the scale based
>>>> mechanism from Mapserver, what I think would be helpful is a more device
>>>> neutral styling determination mechanism as an addition.
>>>>
>>>>
>>>> thanks,
>>>>
>>>> Frank
>>>>
>>>>
>>>> [1] http://hub.qgis.org/issues/6430
>>>>
>>>>
>>>>>
>>>>> regards,
>>>>> thomas
>>>>>
>>>>>>
>>>>>>
>>>>>> Many thanks for reading,
>>>>>>
>>>>>> Frank
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> http://osgeo-org.1560.x6.nabble.com/MapProxy-Seeding-in-a-certain-scale-tp5071082p5071464.html
>>>>>>
>>>>>> --
>>>>>> Frank BRONIEWSKI
>>>>>>
>>>>>> METRICO s.à r.l.
>>>>>> géomètres
>>>>>> technologies d'information géographique
>>>>>> rue des Romains 36
>>>>>> L-5433 NIEDERDONVEN
>>>>>>
>>>>>> tél.: +352 26 74 94 - 28
>>>>>> fax.: +352 26 74 94 99
>>>>>> http://www.metrico.lu
>>>>>> _______________________________________________
>>>>>> mapserver-dev mailing list
>>>>>> mapserver-dev at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Frank BRONIEWSKI
>>>>
>>>> METRICO s.à r.l.
>>>> géomètres
>>>> technologies d'information géographique
>>>> rue des Romains 36
>>>> L-5433 NIEDERDONVEN
>>>>
>>>> tél.: +352 26 74 94 - 28
>>>> fax.: +352 26 74 94 99
>>>> http://www.metrico.lu
>>>
>>>
>>>
>>
>>
>> --
>> Frank BRONIEWSKI
>>
>> METRICO s.à r.l.
>> géomètres
>> technologies d'information géographique
>> rue des Romains 36
>> L-5433 NIEDERDONVEN
>>
>> tél.: +352 26 74 94 - 28
>> fax.: +352 26 74 94 99
>> http://www.metrico.lu
>
>

-- 
Frank BRONIEWSKI

METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN

tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu