<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

Hi Steve,

<br>thank you very much for your answer. I'd like to include my comments

directly into

<br>your answers. But first of all, I love your map server and would like

to thank you for

the very good job you do here!

<br>Unfortunately I wasted a lot of time with a GMT wrapper. It's fast,

but not flexible enought.

<p>Stephen Lime wrote:

<blockquote TYPE=CITE>Hmmm. I wrote a nice detailed response to this on

Friday. Looks like it never made

it to the list. Probably a DNR problem. Anyway, here's the skinny...

<p>First of all I understand the problem. That said everyone must understand

that the

<br>MapServer was written (initially) to support interactive mapping. That

is, interfaces

<br>where the user would pan/zoom repeatedly. In that scenario image size

needs to

<br>be constant.</blockquote>

May be it's enough, that only one dimension has be constant. Our "best

practice" is

<br>568 pixel horizontal  see: <A HREF="http://dc.gfz-potsdam.de/gis/">http://dc.gfz-potsdam.de/gis/</A> 

.

<blockquote TYPE=CITE>You could change it (i.e. via mapsize=) but once

set it was fixed and

<br>the extent was massaged to fit the image size perfectly. When acting

as an image

engine for other apps I can certainly see the value of supporting 1.

as defined by

<br>Frank below. Trouble is how to do that. An extent is not enough. In

addition to the

<br>extent you need either:

<p>  - one image dimension, the other can be calculated</blockquote>

That's what I  prefer!!!

<blockquote TYPE=CITE> 

<br>  - an image resolution, cellsize for which both image dimensions

can calculated

<p>Me thinks both should/can be supported. For case one I propose adding

a new

<br>mapfile parameter, something like FIT which would have to possible

values- IMAGE

<br>and EXTENT with the default being EXTENT. You'd still define a SIZE

but only one

<br>dimension would be used depending on how things are oriented. This

is just like extents

<br>are handled now.</blockquote>

Why not only to check, whether there are width and height in the request

and when

<br>only one dimension is specified you can  calculate the second

dimension on the fly.

<blockquote TYPE=CITE>For case two i'd propose adding a new CGI parameter

(cellsize) that

would be used with mapext in generating image size.

<p>I can make these changes in 3.3.010 if it's seems ok to folks. These

changes would

<br>have no impact on existing apps.</blockquote>

This would be great!!!

<blockquote TYPE=CITE> 

<p>There of course other alternatives:

<p>  - you can use mapscript to generate image sizes based on extent

yourself

<br>  - the client application can do it

<p>It should be noted that the assumtion that 'the result should exactly

fit in the bbox' will almost

<br>never be true even with the modifications discussed. The is because

image sizes are integral

and computations often result in fractional (i.e. 525.345) results.

However, with the changes

<br>suggested about errors will be less than half a pixel which is as good

as one could expect unless

<br>you do work in the client application to ensure a perfect fit.</blockquote>

I can live with that. But if you use e.g. the OGC (www.opengis.org) specification

for map servers,

<br>the idea is to use different OGC map servers to generate layers. You

should be able to overlay

<br>these layers from different map servers into one map. That's why, the

BBOX has to be exactly

what was specified for the request to the map server.

<br>We've a very poor interface to 2 map servers (under construction) following

partly the OGC map

server specs  (<A HREF="http://dc.gfz-potsdam.de/~puchert/metaserver/mapserver_demo.html">http://dc.gfz-potsdam.de/~puchert/metaserver/mapserver_demo.html</A>).

<br>The wrapper for your map server (to make it OGC conform)  is from

Rob Atkinson with some

of our own additions.

<br>You can use the interface or you can use the URL's directly, that are

beneath the "Request" button.

<blockquote TYPE=CITE> 

<p>Steve

<p>Stephen Lime

<br>Internet Applications Analyst

<p>Minnesota DNR

<br>500 Lafayette Road

<br>St. Paul, MN 55155

<br>651-297-2937

<p>>>> Frank Lochter <marco@gfz-potsdam.de> 03/17/00 09:14AM >>>

<br>Hi Steve,

I have a small problem and would like to discuss this here.

<p>1. When I specify a bbox (lat, lon), then the result map should 

fit exactly within this BBox.

<br>2. When I specify a width and height, the result bitmap should have

this width and height.

<br>3. What is when I specify bbox and width and height? Then something

is over defined!

<p>    - I assume, the result should exactly fit in the

bbox AND the bitmap should fit exactly in one

<br>     dimension width or height and the other dimension

of the bitmap should be calculated on

<br>     the fly!

<p>    - I get something unexpected when the map server

extracts the bbox, especially when I

<br>      like to integrate the bitmap into an

other application and assume, that the bitmap has

the bbox, that I used to generate it.

Is there any way to get what I assume in 3. !

<p>Sincerely

<p>Frank Lochter

<p>Stephen Lime wrote:

<p>> Yup, the extent is recaclulated based on the shape of the extent and

the window

<br>> size/shape. You are gauranteed to see the whole extent plus a bit

more. The

<br>> algorithm fits your requested extent in either x or y dimension (whichever

fits

<br>> best) and then pads the other dimension as needed. This has to be

done in

<br>> order to get the right map to image transformation. You wouldn't

necessarily

<br>> have to actually display data outside the actual requested extent

but that would

<br>> result in a great deal of blank space in the resulting image, so

the computed extent

> is used to select/clip data.

<br>>

<br>> Steve

<br>>

<br>> Stephen Lime

<br>> Internet Applications Analyst

<br>>

<br>> Minnesota DNR

<br>> 500 Lafayette Road

<br>> St. Paul, MN 55155

<br>> 651-297-2937

<br>>

<br>> >>> Ralf Puchert <puchert@gfz-potsdam.de> 03/16/00 10:33AM >>>

<br>> Hello,

<br>>

<br>> When we use

<br>>

<br>> <a href="http://130.11.52.178/cgi-bin/mapserv?mode=map&layer=elevation&mapext=">http://130.11.52.178/cgi-bin/mapserv?mode=map&layer=elevation&mapext=</a>

<br>> -180+-10+180+90&map=/var/mapserver/global/global.map&mapsize=500+250

<br>>

> the outputmap has the wrong southernmost latitude.

> It seems to be that something is overdefined.

<br>> Will the produced map whithin geographic coordinates expanded

<br>> to the width and height values of the bitmap or

> will the geographic bounding box be recalculated ?

<br>>

<br>> Sincerely

<br>>

<br>> Ralf Puchert

<p>--

<br>Dr. Frank Lochter

<br>Data Centre

<br>GFZ Potsdam

<br>Telegrafenberg A3

<br>14473 Potsdam

<br>fon. +49-331-288-1701

<br>fax. +49-331-288-1703

<br>url   <a href="http://www.gfz-potsdam.de/~marco">http://www.gfz-potsdam.de/~marco</a></blockquote>

<p>--

<br>Dr. Frank Lochter

<br>Data Centre

<br>GFZ Potsdam

<br>Telegrafenberg A3

<br>14473 Potsdam

<br>fon. +49-331-288-1701

<br>fax. +49-331-288-1703

<br>url   <A HREF="http://www.gfz-potsdam.de/~marco">http://www.gfz-potsdam.de/~marco</A>

<br> </html>