[mapserver-dev] Questions regarding to the extent/scale calculations in MapServer

[Lime, Steve D (MNIT)]

Tamas: Do you want to create an enhancement ticket for this?

Steve

From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Tamas Szekeres
Sent: Wednesday, November 27, 2013 10:14 AM
To: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] Questions regarding to the extent/scale calculations in MapServer

Thank you all for the information.
I concur with Steve that supporting both of these options controlled by a parameter in the mapfile would be a good compromise (keeping the current behaviour as the default).

Best regards,

Tamas


2013/11/27 Daniel Morissette <dmorissette at mapgears.com<mailto:dmorissette at mapgears.com>>
Oh wait... re-reading my own ticket, we never added the wms_bbox_mode metadata that was initially suggested, what was done in the end is that we implemented a vendor-specific WMS GetMap param called BBOX_PIXEL_IS_POINT=TRUE to switch the pixel model on the fly (works for WMS only).

Daniel


On 13-11-27 10:37 AM, Daniel Morissette wrote:
FYI WorldWind also uses this PixelIsPoint model, and even worse, in
their case they implemented their WMS client code to incorrectly send
center of pixel coordinates in the WMS BBOX (the WMS spec says that BBOX
coordinates are the outside of the corner pixels == PixelIsArea).

So in order to allow compatibility with WorldWind when deploying
MapServer servers for WorldWind use, we added a wms_bbox_mode param that
does more or less what Steve suggests here, but for WMS only (and it
indeed breaks WMS compliance).

More info: https://github.com/mapserver/mapserver/issues/4652

Daniel


On 13-11-27 10:27 AM, Stephen Woodbridge wrote:
Steve L,

If this would be "easy" to change internally would it make sense to
allow this to be configured in the mapfile. By default the behavior
would remain the same, but we would have an option in the map object
like:

PIXELMODEL POINT|AREA

then it would be easy for people to use what they need?

Food for thought!

-Steve W

On 11/27/2013 10:15 AM, Lime, Steve D (MNIT) wrote:
The model was based on how ERDAS represented pixels back when MapServer
was first written. I was a satellite image processing guy at the time
and that was the initial focus of the software. Early code used the
ERDAS C toolkit which reinforced the model. Personally I think the
center of a pixel model makes more sense.

Changing would probably be **very** disruptive. Not so much within
MapServer code since the areas of change are pretty isolated in a few
macros and transformations in the OWS code. The change would affect
every mapfile that sets or uses scale denominators. Plus, clients would
need to be updated and need to be made version aware.

Steve

*From:*mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org>
[mailto:mapserver-dev-bounces at lists.osgeo.org<mailto:mapserver-dev-bounces at lists.osgeo.org>] *On Behalf Of *Tamas
Szekeres
*Sent:* Wednesday, November 27, 2013 8:54 AM
*To:* mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
*Subject:* [mapserver-dev] Questions regarding to the extent/scale
calculations in MapServer

Hi All,

We've already noticed MapServer use a "center of pixel" representation
when doing the extent/scale calculations in the code, which may cause
quite some confusion for the users (mostly from the mapscript side)
regarding to the behaviour.

The most typical issue I've encountered is the complain about "why
mapserver modifies my accurate extent specified in setExtent and why
MapServer calculates a different scale I can calculate?"

The reason of why is in fact that we consider the area coverage of the
image is larger than the area coverage of the map extent (half of the
pixel size in each directions). But the users (and mostly everyone in
the world except MapServer) considers that the area coverage of the
image is the same as the area coverage of the map extent.

Can someone explain why we do things this way and do we have the chance
to get rid of it?

We could also eliminate the unnecessary transformations done in the
WMS/WCS interface where the extent of the BBOX is considered to be in -
let's say - edge of pixel representation and not in center of pixel
representation.

Best regards,

Tamas



_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/mapserver-dev



--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000

_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20131202/73b27f48/attachment-0001.html>