make polygon a vector of rings

[jfirebaugh]

polygon currently has individual exterior_ring and interior_rings members.

It would be easier to work with in certain cases (notably GeoJSON serialization/deserialization) if it instead inherited from std::vector<linear_ring<T>>, where the exterior ring was element 0 and interior rings followed.

[artemp]

Having clear distinction between exterior ring and interior rings makes it easier to work when OGC geometry model is expected - WKT, WKB(postgis), boost::geometry.

Explicit is better in this case. We used to have where the exterior ring was element 0 and interior rings followed in mapnik and it was causing more issue then solving.
/cc @springmeyer @flippmoke

[jfirebaugh]

The further I get with integrating geometry.hpp and exploring how we'd write algorithms, the more I'm convinced that polygon should be a simple vector of rings. Uniformity and harmony with the other geometry.hpp types and with GeoJSON is more important than conformance with OGC in this case.

Unless there are vehement objections, I'm going to pull 6b52596ec0efd0c5b6530782a79175428bce01f2 into the next release.

[springmeyer]

Good to know your experience here @jfirebaugh. I've found this design without limitations myself, but I'm open to considering the merits of this. However I do cringe as it would require large updates to mapnik-vector-tile if we adapted to the latest geometry (https://github.com/mapbox/mapnik-vector-tile/search?utf8=%E2%9C%93&q=interior_rings) and the distinction has felt very useful.

[jfirebaugh]

@springmeyer: from what I can see it will make mapnik code much shorter and simpler too. Every place that the same algorithm is repeated for exterior_ring and then interior_rings becomes a simple single loop. Here, here, here, here, here, here. In fact I found only a single place where exterior and interior rings were treated differently. All other uses will benefit from keeping all rings in a single vector.

[jfirebaugh]

Done in 3d55ece.

Here's an example of how this enables writing concise generic algorithms.

[springmeyer]

Here's an example of how this enables writing concise generic algorithms.

Ooooo. Nice @jfirebaugh! 🙌

[springmeyer]

@jfirebaugh - one thought: In Mapnik, for best performance with polygons with lots of holes, we only use the exterior ring to determine the envelope: https://github.com/mapnik/mapnik/blob/d97583b53e134ca916aebbf9abbc4e8a5851d41f/include/mapnik/geometry_envelope_impl.hpp#L80-L95. How about specializing on multipolygon to avoid those extra loops?

[flippmoke]

After thinking about this for some time I am not convinced this is the best decision. @artemp is right in that it is very hard to adapt this to something like boost. For example look at the code where I am trying to adapt boost geometry to geometry.hpp:

template <typename CoordinateType>
struct exterior_ring<mapbox::geometry::polygon<CoordinateType> >
{
    static mapbox::geometry::linear_ring<CoordinateType> & get(mapbox::geometry::polygon<CoordinateType> & p)
    {
        return p.exterior_ring;
    }

    static mapbox::geometry::linear_ring<CoordinateType> const& get(mapbox::geometry::polygon<CoordinateType> const& p)
    {
        return p.exterior_ring;
    }
};

template <typename CoordinateType>
struct interior_rings<mapbox::geometry::polygon<CoordinateType> >
{
    using holes_type = typename mapbox::geometry::polygon<CoordinateType>::rings_container;
    static holes_type&  get(mapbox::geometry::polygon<CoordinateType> & p)
    {
        return p.interior_rings;
    }

    static holes_type const& get(mapbox::geometry::polygon<CoordinateType> const& p)
    {
        return p.interior_rings;
    }
};

The problems here is that I am not able to provide easily a reference of a std::vector that is a portion of a std::vector for interior rings and what am I supposed to do if there is no first ring in the vector or linear rings? Again, this is passed as a reference, so even if I made a temporary empty linear ring it would go out of scope.

[jfirebaugh]

You can use a boost iterator_range to model interior rings. Here's a proof of concept:

https://gist.github.com/jfirebaugh/c5e07939b6c4a5b975e20b966e371e3b

[artemp]

@jfirebaugh - iterator_range doesn't cut it unfortunately. Mutating algorithms e.g clipping needs to be able to resize/reserve internally

boost::geometry::intersection(bbox, polygon, result);

error: no member named 'resize' in 'boost::iterator_range<std::__1::__wrap_iter<mapbox::geometry::linear_ring<double, std::vector> *> >'
                interior_rings(destination).resize(

FYI, https://gist.github.com/jfirebaugh/c5e07939b6c4a5b975e20b966e371e3b - calling is_valid on empty polygon throws `out-of-range' exception which is wrong too.