mapsize

[Frank Lochter]

Hi Steve,
thank you very much for your answer. I'd like to include my comments directly into
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!
Unfortunately I wasted a lot of time with a GMT wrapper. It's fast, but not flexible enought.

Stephen Lime wrote:

> 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...
>
> First of all I understand the problem. That said everyone must understand that the
> MapServer was written (initially) to support interactive mapping. That is, interfaces
> where the user would pan/zoom repeatedly. In that scenario image size needs to
> be constant.

May be it's enough, that only one dimension has be constant. Our "best practice" is
568 pixel horizontal  see: http://dc.gfz-potsdam.de/gis/  .

> You could change it (i.e. via mapsize=) but once set it was fixed and
> 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
> Frank below. Trouble is how to do that. An extent is not enough. In addition to the
> extent you need either:
>
>   - one image dimension, the other can be calculated

That's what I  prefer!!!

>
>   - an image resolution, cellsize for which both image dimensions can calculated
>
> Me thinks both should/can be supported. For case one I propose adding a new
> mapfile parameter, something like FIT which would have to possible values- IMAGE
> and EXTENT with the default being EXTENT. You'd still define a SIZE but only one
> dimension would be used depending on how things are oriented. This is just like extents
> are handled now.

Why not only to check, whether there are width and height in the request and when
only one dimension is specified you can  calculate the second dimension on the fly.

> For case two i'd propose adding a new CGI parameter (cellsize) that
> would be used with mapext in generating image size.
>
> I can make these changes in 3.3.010 if it's seems ok to folks. These changes would
> have no impact on existing apps.

This would be great!!!

>
>
> There of course other alternatives:
>
>   - you can use mapscript to generate image sizes based on extent yourself
>   - the client application can do it
>
> It should be noted that the assumtion that 'the result should exactly fit in the bbox' will almost
> 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
> suggested about errors will be less than half a pixel which is as good as one could expect unless
> you do work in the client application to ensure a perfect fit.

I can live with that. But if you use e.g. the OGC (www.opengis.org) specification for map servers,
the idea is to use different OGC map servers to generate layers. You should be able to overlay
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.
We've a very poor interface to 2 map servers (under construction) following partly the OGC map
server specs  (http://dc.gfz-potsdam.de/~puchert/metaserver/mapserver_demo.html).
The wrapper for your map server (to make it OGC conform)  is from Rob Atkinson with some
of our own additions.
You can use the interface or you can use the URL's directly, that are beneath the "Request" button.

>
>
> Steve
>
> Stephen Lime
> Internet Applications Analyst
>
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
>
> >>> Frank Lochter <marco at gfz-potsdam.de> 03/17/00 09:14AM >>>
> Hi Steve,
>
> I have a small problem and would like to discuss this here.
>
> 1. When I specify a bbox (lat, lon), then the result map should  fit exactly within this BBox.
> 2. When I specify a width and height, the result bitmap should have this width and height.
> 3. What is when I specify bbox and width and height? Then something is over defined!
>
>     - I assume, the result should exactly fit in the bbox AND the bitmap should fit exactly in one
>      dimension width or height and the other dimension of the bitmap should be calculated on
>      the fly!
>
>     - I get something unexpected when the map server extracts the bbox, especially when I
>       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. !
>
> Sincerely
>
> Frank Lochter
>
> Stephen Lime wrote:
>
> > Yup, the extent is recaclulated based on the shape of the extent and the window
> > size/shape. You are gauranteed to see the whole extent plus a bit more. The
> > algorithm fits your requested extent in either x or y dimension (whichever fits
> > best) and then pads the other dimension as needed. This has to be done in
> > order to get the right map to image transformation. You wouldn't necessarily
> > have to actually display data outside the actual requested extent but that would
> > result in a great deal of blank space in the resulting image, so the computed extent
> > is used to select/clip data.
> >
> > Steve
> >
> > Stephen Lime
> > Internet Applications Analyst
> >
> > Minnesota DNR
> > 500 Lafayette Road
> > St. Paul, MN 55155
> > 651-297-2937
> >
> > >>> Ralf Puchert <puchert at gfz-potsdam.de> 03/16/00 10:33AM >>>
> > Hello,
> >
> > When we use
> >
> > http://130.11.52.178/cgi-bin/mapserv?mode=map&layer=elevation&mapext=
> > -180+-10+180+90&map=/var/mapserver/global/global.map&mapsize=500+250
> >
> > the outputmap has the wrong southernmost latitude.
> > It seems to be that something is overdefined.
> > Will the produced map whithin geographic coordinates expanded
> > to the width and height values of the bitmap or
> > will the geographic bounding box be recalculated ?
> >
> > Sincerely
> >
> > Ralf Puchert
>
> --
> Dr. Frank Lochter
> Data Centre
> GFZ Potsdam
> Telegrafenberg A3
> 14473 Potsdam
> fon. +49-331-288-1701
> fax. +49-331-288-1703
> url   http://www.gfz-potsdam.de/~marco

--
Dr. Frank Lochter
Data Centre
GFZ Potsdam
Telegrafenberg A3
14473 Potsdam
fon. +49-331-288-1701
fax. +49-331-288-1703
url   http://www.gfz-potsdam.de/~marco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20000321/6e0eacfa/attachment.html