[ANN] Orientation

Le 2 janv. 2018 à 17:26, Henrik Sperre Johansen <[hidden email]> a écrit :

Julien wrote

Hello,

I developed a small framework to model orientation (north, east, south,
west). It defines some common operations that can be done  on such objects
(turning, getting the opposite orientation, moving on n steps on a
discrete grid from a given position following certain orientation, etc…).
Also, it supporte composed orientations (e.g. north-east).

This is not a lot but it is tested and I think it does its job well. So if
you need to model orientation, consider to use it. :-)

If any ideas of what I could add to this API, I’m interested.

A special class for holding  a set of Orientations with associated value(s)
<https://en.wikipedia.org/wiki/Wind_rose>   could be a useful addition.
In addition to the orientations/data itself, such a set would benefit from
specifying both
- An interpolation method to use *
- An offset from physical orientation to set-local orientations.

From my experience, the following can be bug-prone scenarios if the above
two are not part of such a model:
- Querying a dataset for orientations not part of the original set**.
Example: Your source data consists of 6 equally spaced data points, but in
use, values for 8 equally spaced orientations are queried.
- Representing/converting different types in a good way.
Example: You model some entity where North(0@1) in design, is WSW in
physical terms (presumably, because it makes the entity align more nicely
with x/y axis), but source datasets are received in terms of Physical
directions.***
- Redefine logical north of datasets with a preexisting logical north, while
maintaining toPhysical(preRotDataset) = toPhysical(postRotDataset) ****
Example: The physical orientation of the entity should be rotated, and you
update the logical north to compensate, but the data should remain the same
wrt. physical orientations.

Cheers,
Henry

* Both for converting to a different set of orientations, and when queried
for the value of a non-specified orientation
** With an interpolation method specified, you have the choice of tradeoff
between speed (convert internal set to queried orientation, direct lookup),
and adherence to original data set (keep internal set, interpolate each
query)
*** And avoiding physical -> model local orientation translation on each
query can be nice, performance-wise
**** Obviously, this is only troublesome if one does convert physical ->
model local orientations



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html