AW: [mapserver-dev] RFC49: mapfile simplificationsand symbologyenhancements

Steve Lime Steve.Lime at dnr.state.mn.us
Sat Dec 13 16:59:05 EST 2008


Instead of the cryptic formula Brent proposed I think I would favor a
function implemented in the expression evaluator. For example:

  SIZE (mrange([itemname], mininput, maxinput, minoutput, maxoutput))

or something like that, not sure about the function name. We want to 
map one range to another. The function would implement something 
like the Brent's formula.

One other idea that came to me was perhaps creating defining pseudo 
item/column and then using them for SIZEs, labeling or whatever. So, at
the
DEFINE level you'd:

PSEUDOITEM
  'mySize' (mrange([itemname], mininput, maxinput, minoutput,
maxoutput))
  'myText (commify(round([itemname], 2)) + ' ac')
END

LABELITEM 'myText'
CLASS
  STYLE 
    COLOR 255 0 0
    SIZE [mySize]
  END
  LABEL
    ...
  END
END

The pseudo items would be added to the shapeObj when it is read from
disk
and would appear just like other items. Might be useful for disk-base
data.

Steve

>>> "Karsten Hoffmann" <khoffmann at igf.uni-osnabrueck.de> 12/12/08 12:37
PM >>>
Hi Håvard,

thanks for the explanations. I know the functionality of scalable
symbols in
Mapserver. But what I would like to have are symbols with fixed sizes.
And the
sizes of the symbols should depend on an attribute, for example the
total
population of different countries. 

The result is a thematic map in which for every country the total
population
is visualised by the size of a circle or a square for example. So the
important kind of visualising the total population here is the size (one
of
the graphic variables in cartography). 

This principle is already implemented in the CHART Layer with
PROCESSING "CHART_SIZE_RANGE=itemname minsize maxsize minval maxval"
In my case I don't want to have a pie chart but only a symbol where the
size
depends on an attribute.

I'm not sure if I understand exactly the syntax of the proposition

SIZE  ( 18 + [poptotal] * (( 43-18)/(5000-30000))  )

but I think it goes in the direction what I would like to have.
If it's a normal calculation then I got for the number of 30000
habitants a
size of 48 pixels. But the aim was to have 43 pixels for 30000
habitants.

Or would it be possible to define it similar to how it works in the
Chart-Layer? For example:
SIZE ( [itemname] minsize maxsize minval maxval )

In my case would it be
SIZE ([poptotal] 18 43 5000 30000)

Karsten


> Karsten,
> 
> If you want scalable symbols you need to use the layer
> level key SYMBOLSCALEDENOM.
> The default size (given by "SIZE") will be used for the
> SYMBOLSCALEDENOM scale, and the symbol will be scaled
> according to the current mapscale (within the bounds
> MINSIZE..MAXSIZE).
> 
> http://mapserver.gis.umn.edu/docs/reference/mapfile/layer
> 
> For example, given the following values:
> SYMBOLSCALEDENOM 10000
> SIZE 10
> MINSIZE 2
> MAXSIZE 40
> The symbol will be 10 pixels high when rendered at the
> map scale 1:10000, 20 pixels high when rendered at the
> map scale 1:5000, 5 pixels high when rendered at the
> map scale 1:20000.  For very small map scales the height
> will be 2 pixels, for very large map scales, the height
> will be 40 pixels.
> 
> Håvard
> 
> Karsten Hoffmann wrote:
> > Hi Thomas,
> > 
[WINDOWS-1252?]> > I’m not sure if I understand what you mean.
> > 
> > I tried your proposition with Mapserver 5.2. But all circles have
the same
> > size (43 pixel):
> > 
> > LAYER
> >   NAME        population
> >   TYPE         POINT
> >   STATUS    default
> >   DATA         Lan_point.shp
> >   CLASS
> >     NAME 'Population'
> >     STYLE
> >         SYMBOL 'circle'
> >         SIZE [poptotal]
> >         MINSIZE 18
> >         MAXSIZE 43
> >         OUTLINECOLOR 0 0 0
> >         COLOR 0 0 255
> >     END
> >   END
> > END
> > 
> > The sizes of the circles should vary depending on the number of
habitants. I
[WINDOWS-1252?]> > don’t want to preprocess the population data. At the
moment
I calculate the
> > sizes of the circles by myself and write them in a new fie> >         SIZE [pop_size]
> >         OUTLINECOLOR 0 0 0
> >         COLOR 0 0 255
> >     END
> > 
> > The population varies from around 5000 to 30000 habitants. The sizes
of the
> > circles should vary from 18 to 43.
> > 
> > With a Chart-Layer it is very comfortable to define this:
> > 
> > PROCESSING "CHART_SIZE_RANGE=poptotal 18 43 5000 30000"
> > 
[WINDOWS-1252?]> > But I don’t want to have a pie chart with slices here
just
a simple filled
> > circle.
> > 
> > Best,
> > Karsten
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: thomas bonfort [mailto:thomas.bonfort at gmail.com]
> > Gesendet: Donnerstag, 4. Dezember 2008 12:18
> > An: Karsten Hoffmann
> > Cc: mapserver-dev Mailing List
> > Betreff: Re: [mapserver-dev] RFC49: mapfile simplifications and
> > symbologyenhancements
> > 
> > karsten, if I understant your request correctly, MapServer already
has that:
> > 
> > STYLE
> >  SYMBOL "circle"
> >  SIZE [population]
> >  MINSIZE 3
> >  MAXSIZE 20
> > END
> > 
> > you'll probably want to preprocess the [population] in your data
> > request (to add steps, or scaling)
> > 
> > regards,
> > thomas
> > 
> > On Thu, Dec 4, 2008 at 11:45, Karsten Hoffmann
> > <khoffmann at igf.uni-osnabrueck.de> wrote:
> >> Dear developers,
> >>
> >> I would like to ask for another feature which could be perhaps
included in
> >> this RFC.
> >>
> >> Since version 5.2 it's possible to bind the size of pie charts to
an
> >> attribute (https://trac.osgeo.org/mapserver/ticket/2136):
> >> PROCESSING "CHART_SIZE_RANGE=itemname minsize maxsize minval
maxval"
> >>
> >> This would also be useful for point symbols as simple diagrams
without
> >> slices or bars. The idea is to have a symbol, let's say a filled
circle or
> >> square, which varies continuously in size. The size is bound to an
> > attribute
> >> for example the absolute number of habitants of different
countries.
> >>
> >> This would be a useful feature for thematic mapping. Is it possible
to
> >> implement this?
> >>
> >> Best regards
> >> Karsten Hoffmann
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: mapserver-dev-bounces at lists.osgeo.org
> >> [mailto:mapserver-dev-bounces at lists.osgeo.org] Im Auftrag von
thomas
> > bonfort
> >> Gesendet: Donnerstag, 4. Dezember 2008 11:18
> >> An: mapserver-dev Mailing List
> >> Betreff: [mapserver-dev] RFC49: mapfile simplifications and
> >> symbologyenhancements
> >>
> >> Hi,
> >>
> >> Not sure if the changes warrant a full blown RFC, but as there
quite a
> >> number of them I've regrouped them.
> >>
> >>
> >
http://trac.osgeo.org/mapserver/browser/trunk/docs/development/rfc/ms-rfc-49
> >> .txt
> >>
> >> These changes are/were all in RFC45, but were extracted to keep
things
> >> moving on as some of the stuff in rfc45 lacks funding in the near
> >> future.
> >>
> >> You can see it in action here on openstreetmap data:
> >> http://mapserverosm.s3.amazonaws.com/parisosm.html
> >> nothing that's impossible to do with the current mapfile keywords
> >> (except for polygon label placement, and thin lines thanks to
> >> fractional size/widths), but the mapfile maintainance and creation
is
> >> greatly simplified, as e.g. roads are mostly defined with a single
> >> class whatever the scale (using a combination of sizeunits at the
> >> layer level, and min/max width and min/max scale at the style
level)
> >>
> >> regards,
> >> thomas
> >> _______________________________________________
> >> mapserver-dev mailing list
> >> mapserver-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >>
> >>
> > 
> > _______________________________________________
> > mapserver-dev mailing list
> > mapserver-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >
> 
> -- 
> Håvard Tveite
> Department of Mathematical Sciences and Technology, UMB
> Drøbakveien 31, POBox 5003, N-1432 Ås, NORWAY
> Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt/
------- Emapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev



More information about the mapserver-dev mailing list