Make namespace follow folder structure? about movetk HOT 3 CLOSED

@bacusters indeed this will make finding the required classes easier. Something we also need to consider is the schematic of the components . The idea was to have a very simple grouping into four namespaces. So, maybe we can reorganise the folder structure so that they are in sync with the namespaces and also change the namespaces from movetk_ to fully qualified names as movetk::

Below is the proposed reorganisation of the folder structure under src/include . @bacusters what do you think?
Also adding @mwernerds to the discussion to get his inputs on the same

from movetk.

I think that is a nice setup yes! One question: do we need the 'algorithms' folder in between? I think the folders for the different components are self-explaining enough to not need that? Or do we have common interfaces that we need in the movetk::algorithms namespace?

from movetk.

I think that is a nice setup yes! One question: do we need the 'algorithms' folder in between? I think the folders for the different components are self-explaining enough to not need that? Or do we have common interfaces that we need in the movetk::algorithms namespace?

Well that is a design choice we will have to think about , do we want a common traits and interface under movetk::algorithms or we wish to have traits and interfaces under each component?

One thing is certain that we will now need an interface similar to DistanceTraits.h & DistanceInterface.h for the DTW implementation by @mstroila because when the DTW algorithm moves to movetk/algo/Similarity.h this will create the same circular reference problem since
Similarity.h includes GeometryInterface.h and because boost.geometry already has an implementation of DTW , we have the following interface in GeometryInterface.h

      template<class GeometryTraits, class Norm, class T>
    struct dynamic_time_warping_algorithm {
        typedef T dynamic_time_warping;
    };

    template<class GeometryTraits, class Norm>
    struct dynamic_time_warping_algorithm<GeometryTraits, Norm, void> {
        typedef movetk_support::Dynamic_Time_Warping<GeometryTraits, Norm> dynamic_time_warping;
    };

    template<class GeometryTraits, class Norm>
    struct ComputeDynamicTimeWarpingDistance {
        template<class InputIterator,
                typename = movetk_core::requires_random_access_iterator<InputIterator>,
                typename = movetk_core::requires_movetk_point<GeometryTraits,
                        typename InputIterator::value_type>>
        typename GeometryTraits::NT operator()(InputIterator polyline_a_first, InputIterator polyline_a_beyond,
                                               InputIterator polyline_b_first, InputIterator polyline_b_beyond) {
            typedef dynamic_time_warping_algorithm<GeometryTraits, Norm,
                    typename GeometryTraits::MovetkDynamicTimeWarpingDistance> algorithm;
            typename algorithm::dynamic_time_warping distance;
            return distance(polyline_a_first, polyline_a_beyond, polyline_b_first, polyline_b_beyond);
        }

    };

which needs to know the definition of movetk_support::Dynamic_Time_Warping

So, going forward, we will have interfaces for algorithms as well, whether we wish to have a common traits and interface header (movetk/algo/AlgorithmTraits.h & movetk/algo/AlgorithmInterfaces.h ) or have a separate (movetk/algo/similarity/SimilarityTraits.h & movetk/algo/similarity/SimilarityInterface.h ) is something we need to decide upon.

from movetk.