features

[jfirebaugh]

Several use cases for this library will also require a feature representation: geometry plus properties.

A basic sketch of the necessary types would be:

using value = mapbox::util::variant<bool, int64_t, uint64_t, double, std::string>;
using property_map = std::unordered_map<std::string, value>;

template <class T>
struct feature
{
    property_map properties;
    geometry<T> geometry;
};

template <class T, template <typename...> class collection>
struct feature_collection : collection<feature<T>>
{
    using collection_type = collection<feature<T>>;
    using collection_type::collection_type;
};

[ansis]

Should object and array property values be supported? Or would json arrays be stored in stringified form? slightly related: https://github.com/mapbox/mapbox-gl-js/issues/2434

[artemp]

@ansis - we can and should store recursive types via variant::recursive_wrapper<T> @jfirebaugh - feature sketch looks like a good start. I'm wondering why distinguish between signed and unsigned, though? /cc @kkaefer ?

[jfirebaugh]

@artemp The JSON specification does not limit the size of integers, so it's useful to expose both signed and unsigned 64-bit integers to cover the widest possible range. This also follows the vector tile spec, existing convention in mapbox-gl-native, and what rapidjson exposes.