[mapserver-dev] Scales and raster maps

Fri Aug 9 01:21:40 PDT 2013

Thomas,

For each Layer there are already UNITS, TOLERANCEUNITS, SIZEUNITS: would RESOLUTIONDENOMUNITS (/ pixel), defaulting to the layer units (or meters?), remove that ambiguity? Factors for converting between the different units are already in there somewhere.

Regards,

Edward

-----Ursprüngliche Nachricht-----
Von: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] Im Auftrag von thomas bonfort
Gesendet: Freitag, 9. August 2013 10:07
An: Frank Broniewski
Cc: MapServer Dev Mailing List
Betreff: Re: [mapserver-dev] Scales and raster maps

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,
>
> 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-sc
>>> ale-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
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev