when using a function to generate an angle for a point, it expects radians, not degrees

[burritojustice]

trafficstars

https://github.com/tangrams/tangram-docs/blob/gh-pages/pages/draw.md#angle

when returning a value for angle with a function, it looks like it expect radians, not degrees.

            draw:
                mapzen_icon_library: # _points:
                    sprite: airport
                    collide: false
                    # angle: 180
                    angle: |
                        function(){
                            return 3.14/2
                            // return 180
                            }

returning 180 does not point south, while pi/2 does...

Note that passing degrees without a function, e.g. angle: 180, works as expected.

[nvkelso]

Is this an error in Tangram JS logic? Agree we should document the current state regardless, just wondering if there's another Tangram JS issue to file here? @meetar

[bcamper]

I would expect degrees, so if that's not current behavior, we should fix.

On Mon, Jun 25, 2018 at 5:18 PM, Nathaniel V. KELSO < [email protected]> wrote:

Is this an error in Tangram JS logic? Agree we should document the current state regardless, just wondering if there's another Tangram JS issue to file here? @meetar https://github.com/meetar

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tangrams/tangram-docs/issues/250#issuecomment-400099096, or mute the thread https://github.com/notifications/unsubscribe-auth/AABBXWZ0OGNYwWIeKwa5Znq01ttzHsIBks5uAVO_gaJpZM4U22Yp .

[burritojustice]

It looks like if you assign angle a number as a string, it assumes it's radians, but if you give it a number, it assumes degrees:

angle: "3.14" vs angle: 180 vs angle: "180"

So this could be something as simple as the function returning a string?

[bcamper]

The behavior should be normalized (to degrees) nonetheless. But that's a good clue.

On Mon, Jun 25, 2018 at 5:44 PM, burritojustice [email protected] wrote:

It looks like if you assign angle a string, it assumes it's radians, but if you give it a number, it assumes degrees:

angle: "3.14" vs angle: 180 vs angle: "180"

So this could be something as simple as the function returning a string?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tangrams/tangram-docs/issues/250#issuecomment-400105757, or mute the thread https://github.com/notifications/unsubscribe-auth/AABBXbglMd-oIPb58ddCFmEANNExjsJtks5uAVmkgaJpZM4U22Yp .

[bcamper]

Root issue is addressed in Tangram JS here: https://github.com/tangrams/tangram/pull/652

Note this does NOT change static string behavior like angle: "90"... my opinion is that is incorrect syntax (there are valid string return values like auto, but a stringified number isn't one of them), and since YAML is generally good at type inference, we don't need to do any additional coercion here. That behavior was a useful clue as to why the function return value wasn't being parsed properly though.

@matteblair do you agree and does this reflect ES behavior?

[matteblair]

The behavior you're describing sounds reasonable to me, I think it's unlikely that someone would quote a number literal for angle.

What I'm observing in Tangram ES now is that both number and string literals (e.g. 90 and "90") are accepted as valid degree values. Functions for the angle parameter only work in ES if the function returns the number as a string, which seems like a bug so I'll investigate that.

[bcamper]

Got it. Yeah I also realized, the question with string representations of numbers is way more pervasive than this -- probably any (or many) parameters on the JS side that expect numbers. So I believe we should keep that as-is, with strict types (again I don't think this is a practical issue given YAML does this well), and we wouldn't want to just change behavior for this one parameter. Given differing JS vs. ES behavior, that seems like "undefined behavior" for going outside the documented value types for the parameter.

Sounds like if ES is updated to handle numbers returned as angles, we're in alignment on the expected/documented functionality anyway.

[matteblair]

Yep, the issue with stringiness of scalars applies in other places as well.

The documentation for angle could also mention that a function can be used.