[mapserver-dev] MS RFC 107 again

Tue Aug 19 05:17:33 PDT 2014

Hi,

Is this a typo, shouldn’t it be 1 for the current model?
MAP
    # 0 for using the OGC extent model 2 for the current edge-of-pixel model
    PIXELADJUSTMENT 0

I have read the RFC before and it took me a long time to understand this
“Well, it goes back to companion software that existed along side MapServer to display satellite data stored in ERDAS that used the center to center extent model. The math is simple and there is a certain logic in having the extent actually represent pixel values - that is, if you render the extent as a polygon you get the exact edge of the image as one might expect..”

My conclusion was that the author was thinking about rendering the bounding box with 1 pixel wide outline. I had never though it that way but I admit it is true.  For me the best feature of the center of pixel model is that the radiometry of a pixel is computed around the same place independently of pixel size. See the attached image and think that pixels are describing something like temperature. The big pixel resampled by the edge of pixel model is giving the average temperature from another place than the center of pixel model.

I spent a long time by making drawings and thinking about what happens to the selection rectangle at different overview levels. I came to conclusion that the suggested change is good thing especially when rendering from vector data because the decreased search rectangle selects too few features and ever less when the pixel size of the output gets bigger. I am not totally sure about what happens when the source data are rasters but probably the change is good even then. I would test the new system by making some WCS requests. With output to native pixel size I would await that the output image is identical with the original pixel by pixel.

-Jukka Rahkonen-

Tamas Szekeres wrote:

Hi Devs,

This RFC<http://mapserver.org/development/rfc/ms-rfc-107.html> has been abandoned a bit, but I'd like to see it in MapServer 7.0, too.
The proposed changes are fairly straightforward, but requires to modify several files.

Up to this time we haven't found any compatible solution which would satisfy with the client's need and would require smaller amount of modifications, but the proposed changes have been implemented locally at the client and works without problems for quite a long time.

Do we have any specific issues which would prevent me from calling a vote on it?

Best regards,

Tamas

2014-03-26 14:43 GMT+01:00 Tamas Szekeres <szekerest at gmail.com<mailto:szekerest at gmail.com>>:
Hi Devs,

We had a small discussion here in the codesprint, whether we should apply this RFC as it stands or not. In fact I understand that the proposed changes are fairly system wide, but let us review the issues that should anyway be handled in some way.
I've also discussed with the client who has raised this problem originally, mainly to refresh my memory related to all aspects. It must also be added that applying the proposed changes in a local build could indeed solve all issues they had. So the problems are as follows:

1. Correction code should be applied at the client when using setExtent/getExtent in mapscript. This is fairly odd for most users who would prefer to go with the edge of pixel extent model. We could however provide variants for   setExtent/getExtent which mimics the  edge of pixel extent model at the interface.

2. The current code regarding to the geographical width yields incorrect result from the WMS side, which should probably be reverse corrected if the query has been originated from WMS specifically. Actually the user would expect to have the map drawn at the specified extent, but mapserver considers as if a smaller extent has been specified by the user. When using geo width dependent rendering (MINGEOWIDTH/MAXGEOWIDTH) the layers may unexpectedly be drawn at a given zoom level where it should not normally be drawn.

3. The user wants to draw a given extent, but actually a smaller amount of features are provided in the view. Given a large extent (like a whole continent) half pixel difference in each directions is not negligible

4. Smaller amount of features are retrieved from the database which the WMS client may expect. We should probably reverse correct the extent when setting the spatial filter against the database to get the correct set of the features drawn on the map.

Lastly to add the other way to look at it is the original mapserver implementation for this is very, very old and not OGC compliant which is now the de-facto standard. It was originally done for a specific purpose as I understand it (integration with ERDAS reading the discussion related to this).

Perhaps it is time to review this to be in line with OGC standards and the other mapping engines. Also I don't buy the argument about 'the effect on all existing map files out there' is a valid one. I don't think users would notice any difference. Besides the approach suggested have been configurable in the map file.

Best regards,

Tamas

2014-01-01 15:43 GMT+01:00 Tamas Szekeres <szekerest at gmail.com<mailto:szekerest at gmail.com>>:
Hi Devs,

Happy New Year All!

According to this thread<http://osgeo-org.1560.x6.nabble.com/Questions-regarding-to-the-extent-scale-calculations-in-MapServer-td5091493.html> I've ringed in to write an RFC about the proposed changes.
Please find RFC-107 for review submitted to the documentation tree:
http://mapserver.org/development/rfc/ms-rfc-107.html

Let me know about your suggestions.

Best regards,

Tamas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140819/3136952f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pixel_edge_or_center.png
Type: image/png
Size: 13714 bytes
Desc: pixel_edge_or_center.png
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140819/3136952f/attachment-0001.png>