[mapserver-dev] Scales and raster maps

thomas bonfort thomas.bonfort at gmail.com
Fri Aug 9 02:40:57 PDT 2013 

On 9 August 2013 11:28, Frank Broniewski <brfr at metrico.lu> wrote:
> 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?
Well that's where you have to factor in dpi if you want do something
minimally generic (i don't consider passing a retina=yes or using
different mapfiles to be a suitable solution). I've just added a
couple of tests to show how you'd do it with mapserver, which involves
using map.resolution (i.e. dpi) and adjusting requested image size:
https://github.com/mapserver/msautotest/commit/715683be8f598f5e03d6e11351ccb4f8aaef23e7

in essence
a request for size=100,100 and resolution=144 will produce an image
that is identical, once scaled by 50%, to an image produced with
size=50,50 and resolution=72

>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

More information about the mapserver-dev mailing list