<!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
<br>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
<br>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
<br>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
<br>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
<br>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
<br>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
<br>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
<br>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,
<p>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
<br> the bbox, that I used to generate it.
<p>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
<br>> 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>>
<br>> the outputmap has the wrong southernmost latitude.
<br>> 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
<br>> 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>