[Ns-developers] [ns3] Vector and different coordinates system

[Federico Guerra]

Hi Tom, 
I also fear that the mobilityModel could be really coupled with the coordinate system.

In geographical coords (or spherical coords, is the same) even a simple model that makes you move
from point A to point B at the same altitude (so along the same spherical surface) should not use the standard cartesian distance, but would use the 
distance along a great circle.

As Nicola pointed out before even a simple rectangle position allocator won't work that well with geographical coords.

I think that this example could be found for other coordinates as well.


So I think that the easiest solution would be to stick with Vector, since I would have to rewrite the most of the MobilityModels anyway.
Actually for the first version I would write the bare minimum, and I would add new models in the future.

The ideal solution, since I have to rewrite the mobilitymodel, and since this models would work only with geographical coords (or spherical coords),
would be to introduce, as Mathieu already pointed out, a new SphericalMobilityModel base class, that extends MobilityModel, and that introduces something like:

virtual SphericalVector GetPosition( ) = 0;

and make all the new MobModels inherit and implements this new function. But I agree that this solution would be a code bloat.

In my ideal world the best solution would be:

class CoordType
{
// could be anything you want, from attribute or whatever,

    Vector* GetPrototype() { return vector_ptr->clone (); )

    protected:
    
    Vector* vector_ptr; // this is a prototype object that can be used for virtual factory
};

// different coord types should add their dynamic allocated Vector subclass that can be used for factory purposes
// in this way the framework don't really need to know which Vector subclass is associated to the coord type
// and to obtain new object could simply call the clone() method

class Vector
{
 public:
 Vector(double x, double y, double z);
 virtual ~Vector () {} // to make this class inheritable

 virtual Vector* Clone (); // could be used for virtual factory

 virtual CoorType GetCoordType () const; // returns the associated type

 virtual isValid () const; //  this should be rewritten by derived classes

// insert accessors method here

protected:

double x,y,z;

 bool is_valid; // set to false if conversion was not possible or with errors

}; // base coord class

// user should derive from Vector to define their Coordinates


class MobilityModel
{

   // returns invalid Vector if conversion failed
    virtual Vector* GetPosition ( CoordType& desired_coord );

    void AddCoordTypeConvCallback (const CoordType& from_coordType, const CoordType& to_coordType, callback_for_conversion_here);

};

//the callback would be something like

Vector* ConvertCoords ( Vector* input, const CoordType& to_coord_type)
{
// this function would create the desired coords Vector class or have a clone() from _to_coord_type
// it would get the type from the input, and then dynamic_cast it to the associated coords Vector class
// perform the conversion and return a heap allocated coords Vector class
}


Cheers,

Federico Guerra


________________________________
 Da: Tom Henderson <tomh at tomh.org>
A: Pavel Boyko <boyko at telum.ru> 
Cc: ns-developers at ISI.EDU 
Inviato: Giovedì 19 Aprile 2012 18:52
Oggetto: Re: [Ns-developers] [ns3] Vector and different coordinates system
 
On 19.04.2012 09:58, Pavel Boyko wrote:
> Hi Tom,
> 
> I don't really think that many mobility models can be reused in different
> coordinate systems and vote to keep things as simple as LatLonMobilityModel
> : public MobilityModel; LatLonPropagationLossModel : public
> PropagationLossModel, etc.
> 

If I understand correctly your suggestion, you would introduce new coordinate-specific base classes in the hierarchy, under the expectation that mobility models are highly coupled to coordinate systems.  But I thought the original question was how to reuse the existing mobility models with different coordinate systems, and Nicola's response was to not touch the classes and just provide conversion utilities.

I think we have not converged on requirements and architecture, which is why I am chiming in before Federico goes off and implements something.

- Tom