AW: [mapserver-dev] RFC49: mapfile simplifications andsymbologyenhancements

Stephen Woodbridge woodbri at swoodbridge.com
Tue Dec 9 15:33:23 EST 2008


Daniel Morissette wrote:
> Steve,
> 
> I agree that expressions like this would be really cool, but wouldn't 
> they be quite slow if applied to large number of shapes?

I think it depends on how the expression is compiled and executed at 
run-time. I you think about it, it should be no slower than using Perl 
or PHP to do the same thing. If the compiler is dumb, then in the 
example below it re-eval the whole constant expression every time, but 
if it were smart:

get and push bound value
push constant (( 43-18)/(5000-30000))
mult
push constant (18)
add
pop and bind to size

-Steve W

> Daniel
> 
> Steve Lime wrote:
>> I kinda like this approach since it would already be familiar to folks
>> (I think Steve W. was lobbying for this back when I proposed the binding
>> support. Would just have to document a couple
>> of standard "recipes" for users.
>>
>> Steve
>>
>>>>> On 12/5/2008 at 9:43 AM, in message
>> <49394C1D.5040108 at geoanalytic.com>, Brent
>> Fraser <bfraser at geoanalytic.com> wrote:
>>> Steve,
>>>
>>>   Perhaps a compromise would be to allow some simple arithmetic
>> expressions
>>> (like the ones in the FILTER keyword?), such as:
>>>
>>>     SIZE  ( 18 + [poptotal] * (( 43-18)/(5000-30000))  )
>>>
>>> In my case, I've got ANGLEs in a shapefile (ok, 13,000 shapefiles) as
>>
>>> "standard" angles (0=x-axis, + is ccw) but Mapserver likes azimuths 
>>> (0=y-axis, + = cw).  I'd rather not add another field to the
>> shapefile, to
>>> minimize the data management problems.
>>>
>>> Brent Fraser
>>>
>>>
>>> Steve Lime wrote:
>>>> MapServer's interpretation of size through an attribute binding is
>>>> literal. That is, the value
>>>> in the column is used as the size in pixels. Since you set a max
>> scale
>>>> it makes sense you
>>>> see all size 43.
>>>>
>>>> In that case your suggestion makes sense although I'm not sure the
>> best
>>>> way to implement.
>>>>
>>>> I don't think strictly following the charting syntax makes sense
>> since
>>>> we'd then have two ways
>>>> to bind attributes which would get confusing. Any ideas?
>>>>
>>>> Steve
>>>>>>> "Karsten Hoffmann" <khoffmann at igf.uni-osnabrueck.de> 12/04/08
>> 5:59
>>>> AM >>>
>>>> Hi Thomas,
>>>>
>>>> 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
>>>> 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 field
>> (pop_size)
>>>> in
>>>> the attribute table. The Style is then:
>>>>
>>>>     STYLE
>>>>         SYMBOL 'circle'
>>>>         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"
>>>>
>>>> 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
>>>>>> 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
>>>> _______________________________________________
>>>> 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
> 
> 



More information about the mapserver-dev mailing list