[fdo-users] RE: RE: Conditional "IF" in Expressions

Traian Stanev traian.stanev at autodesk.com
Wed Jul 18 11:37:35 EDT 2007


The patch I sent will evaluate the arguments as expressions, no matter
how complex they are -- that's why there is an evaluation stack in
MapGuide. As I said, the only restriction is that due to parser support,
the first argument has to evaluate to a numeric rather than conditional.
The latter two arguments can be expressions of any complexity.

The arguments do not need to be of the same type. They will get
converted to the type most appropriate for the result. For a label, they
will get converted to a string. There are many computer languages that
use weak typing like this, including pretty much all scripting
languages, and they support functions that don't need to return exactly
one type. Anyway, this particular point is not a technical issue, it's a
philosophical one.


Traian


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
Sent: Wednesday, July 18, 2007 11:11 AM
To: fdo-users at lists.osgeo.org
Subject: [fdo-users] RE: RE: Conditional "IF" in Expressions


Hi Traian,

Actually, labeling via conditional expressions was just a lightweight
example of their use, but thanks for the tip and the source anyways. I
was
thinking to using them to build provider-neutral function defintions and
gain better access to calculated property values, i.e.:

- Height of a Building is calculated using formula NumberOfFloors * 3.5
- but, if Building has RoofType of 1 (it's not flat), then overall
Height is
increased by 2.5

if(Bulding.RoofType=1,Building.NumberOfFloors*3.5+2.5,Building.NumberOfF
loors*3.5)

So, function IF has three parameters: A (which is always Boolean, and
evaluates to either True or False), and also B and C that actually get
returned as a result, depending on evaluated A. Using state machine it's
possible to create branching of any depth. Parameters B and C need to be
of
the same type, since function returns exactly that type. 

As Orest proposed, one of possible conditional function definitions
would
look like:

int32 = if(boolean, int32, int32)

or

string = if(boolean, string, string)

etc.

Possiblity of using conditional branching within defined expression is
something just very handy thing.

Regards,
Maksim Sestic



Traian Stanev wrote:
> 
> Hi,
> 
> I assume that since you are talking about labeling, you are using
> MapGuide and my advice below applies. Otherwise, ignore my email.
> 
> For the purposes of MapGuide theming expressions, you can simulate IF
by
> creating several theming rules. So in your case you would have one
> theming Rule that is triggered with the condition (Lanes = 1) that
draws
> in red for example and another Rule that triggers when (Lanes > 1)
that
> draws in yellow for example.
> 
> That said, it is fairly simple to implement an IF as an expression in
> MapGuide, and it is not necessary that argument types match. One
problem
> currently is that an FDO function cannot have a conditional as
argument
> (the parser can't handle it). So for example something like 
> 
> IF(Lanes>2, 7, 8) 
> 
> would not parse.
> 
> However, if you implement the IF such that if the first argument is
say
>>0, then it means true and otherwise false, you can do it. For example
> the following 
> 
> IF (Lanes-2, 'Hello', 12345)
> 
> would be equivalent and would also parse successfully. In order to
> evaluate such a thing in MapGuide, you can use the attached patch (if
> you are running from source of course :). MapGuide still does implicit
> type conversion, so the example I give above with the string and the
> number works fine for conditional labeling, that's what I used to test
> it.
> 
> 
> 
> Traian
> 
> 
> 
> -----Original Message-----
> From: fdo-users-bounces at lists.osgeo.org
> [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Wednesday, July 18, 2007 10:18 AM
> To: fdo-users at lists.osgeo.org
> Subject: [fdo-users] RE: Conditional "IF" in Expressions
> 
> 
> Hi Orest,
> 
> You're right, it returns different types depending on it's return
> parameters
> (true and false parts). As a rule, both parameters (therefor
function's
> return value, too) must be of the same type, i.e.:
> 
> if(Road.Lanes>1,"Multiple lanes","Single lane")
> 
> Here, return value is String - so both params must conform to this
rule.
> This sort of conditional branching is quite useful when building label
> expressions, here's an example:
> 
> - Parcel feature class has two data properties - Number and SubNumber
> (both
> are strings)
> - if there's subnumber set, then it should display "Number/SubNumber"
> (notice slash sign inbetween)
> - otherwise, it displays only "Number" part
> 
>
if(Parcel.SubNumber="",Parcel.Number,concat(Parcel.Number,(concat("/",Pa
> rcel.SubNumber))))
> 
> This happens even more often when it comes to labeling infrastructure
> entities, since it's labels depend on multiple states of a network
> element,
> etc.
> 
> Certainly, labeling is not the only use of conditional branching of
that
> sort :-)
> 
> Regards,
> Maksim Sestic
> 
> 
> 
> Orest Halustchak wrote:
>> 
>> Hi Maksim,
>> 
>> This seems doable. It's similar to a null value function that some
>> providers such as rdbms providers could support: nvl(a,b) which
> returns
>> a if a is not null, otherwise b. In your case it's if(a,b,c) where a
> is
>> boolean. This would need a number of signatures for different data
> types
>> that it would return, e.g. int16 = if(boolean, int16, int16), but
>> FdoFunctionDefinition can deal with it.
>> 
>> The main concern that I would have about it is implementation in an
>> efficient manner, although for rdbms providers, SQL includes a CASE
>> expression that could be used.
>> 
>> Thanks,
>> Orest.
>> 
>> -----Original Message-----
>> From: fdo-users-bounces at lists.osgeo.org
>> [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
>> Sent: Wednesday, July 18, 2007 4:52 AM
>> To: fdo-users at lists.osgeo.org
>> Subject: [fdo-users] Conditional "IF" in Expressions
>> 
>> 
>> I was wondering if future versions of FDO will support conditional
>> branching
>> in Expressions (and Filtering) mechanism, i.e.:
>> 
>> if(conditional_expression,true_part,false_part)
>> 
>> if(Road.Lanes>1,"Multiple lanes","Single lane")
>> 
>> also
>> 
>> if(Road.Lanes>0,if(Road.Lanes>1,"Multiple lanes","Single lane"),"No
>> lanes
>> set")
>> 
>> Useful link:
>> http://www.codeplex.com/dotMath Steve Heberts dotMath library 
>> 
>> Regards,
>> Maksim Sestic
>> 
>> 
>> -- 
>> View this message in context:
>>
>
http://www.nabble.com/Conditional-%22IF%22-in-Expressions-tf4101935s1816
>> 2.html#a11664863
>> Sent from the fdo-users mailing list archive at Nabble.com.
>> 
>> _______________________________________________
>> fdo-users mailing list
>> fdo-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>> 
>> _______________________________________________
>> fdo-users mailing list
>> fdo-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-users
>> 
>> 
> 
> -- 
> View this message in context:
>
http://www.nabble.com/Conditional-%22IF%22-in-Expressions-tf4101935s1816
> 2.html#a11669595
> Sent from the fdo-users mailing list archive at Nabble.com.
> 
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> 
> 
> 
>  
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
> 
> 

-- 
View this message in context:
http://www.nabble.com/Conditional-%22IF%22-in-Expressions-tf4101935s1816
2.html#a11670427
Sent from the fdo-users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users




More information about the fdo-users mailing list