Hello Stu, can you tell please, what is wrong with my code?
It only generates the standard name objects "pier_2_5", but does not trigger on the individual pier:widthCode
- <selectionCondition expression=" ($pier:width) >= '10'"/>
- <staticModel name="Piers\Pier_2_5\pier_2_5"/>
- <spacing min="5.0" max="5.0"/>
- <startDistance min="0" max="0"/>
- <offSetLeft min="0.0" max="0.0" orientationSense="100"/>
- <staticMapEntry expression="($pier:width == '150')" name="Piers\Pier_1_5\pier_1_5" FORrotationOffSet="0.0"/>
- <staticMapEntry expression="($pier:width == '250')" name="Piers\Pier_2_5\pier_2_5" FORrotationOffSet="0.0"/>
- <staticMapEntry expression="($pier:width == '300')" name="Piers\Pier_3_0\pier_3_0" FORrotationOffSet="0.0"/>
A number of issues here
At first I thought
"Of course, you are not using the operator alias #GE# for >="
The expression engine provides the alias/escape strings for operators to avoid special characters in XML. However >= will actually evaluate correctly.
"<=" will give a syntax error. for consistency it is probably better to always use the alias strings
The (...) construct is intended to define precedence in the expression. The ($pier:width) defeats my variable preload algorithm.
I am parsing the expression into tokens on spaces to pick out variable names to preload before tag data is loaded. This avoids a "variable not defined" exception from the expression engine and allows the sparse tag negation functionality added in 0.7.1
Use $pier:width #GE# '10' or ($pier:width #GE# '10')
That lead me to the core problem. It appears there is a bug in the XSharper engine with comparison of left justified numeric values.
($height #LE# '90') will evaluate true for height tag value '100'
($height #LE# ' 90') will evaluate to false
I need to look under the hood of the XSharper engine to see if there is any way to fix this or find a workaround.
what tag data are you comparing?
zero padding will work.
'090' will evaluate correctly compared with '100'
where '90' will not.
If you have added these tags using leading zero pad
turns out XSharper variables were defaulting to string type.
need to detect tag datatype and force a cast to int or float as the variable is set.
Thank you Stu for your commens.
Yes silly from me, not to use #GE# ...
But as this criteria triggers OK for me, the main problem in fact is, that it does not trigger the conditions:
expression="($pier:width == '150')"
These are my OSM data:
I now tried 0150, but that did not help either:
expression="($pier:width == '0150')"
The LOG looks OK so far, but finally, only the type
As I mentioned in the postscript to a previous post, the expression engine did not internally resolve data types of
variables and all variables defaulted to string. So it was doing a string compare for all numeric variables in expressions.
I am testing a fix that loads int or float variables as required.
In the pier example what is the expression in the model map?
sorry I did not scroll down in the include.
Based on the log, the string compare (without leading zero) should have exported 2 different models.
But it is actually exporting <[string8][geometry][..\objects\Piers\Pier_Wood_1_6\pier_wood_1_6]> ???
I don't see where that could possibly come from based on the included config.
"1_6" does not appear anywhere in the config!!!
Yes, what looks like a valid expression is always returning false.
I will have to see if I can reproduce the problem.
wait.... I must be stupid but.... does that mean that these cars are not static ??? they move ????
That would be great !
I wish moving traffic was that easy!!!
By "collision" I meant more than one vehicle occupying the same coordinates