> Le 2 janv. 2018 à 17:26, Henrik Sperre Johansen > <henrik.s.johan...@veloxit.no> 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 >
It looks like a big addition… :-) I’ll open an issue on the GitHub in case someone has some time to implement it (I may not do it myself since I do not need this feature for now). Thanks for the idea. Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40
