tags 913708 +patch thanks This was one of the few remaining blockers for the icu transition in raspbian buster, so I hacked up a fix.
I am far from an expert (just a maintainer of a Debian derivative who ran into this build failure) but here is my interpretation of what is going on. mapbox::geometry::geometry is a "variant" type which can be one of a variety of subtypes. There is an implementation of encode_geometry_pbf that takes said variant and uses some template magic to look up the type stored in the variant and dispatch it to the correct implementation. It looks like a new type "empty" was added to the list of types supported by the variant. When the template magic trys to generate the dispatch for the variant the compiler fails to find the routine to dispatch to, for reasons I don't fully understand it considers this as "ambiguous" rather than "no match". The fix was to add an implementation of encode_geometry_pbf for mapbox::geometry::empty . From reading the existing "multi point" implementation I concluded this implementation should simply return false (I am far from an expert) and implemented it as such. The wrinkle was that ideally the fix would be implemented in mapnik-vector-tile, but it seems that cannot be built on 32-bit systems (raspbian is 32-bit), building it in debian buster seems to be blocked up by some ICU symbols issue and building it in Debian sid seems to be blocked up by the hdf5 transition. The way I got around that wrinke was making the node-mapnik build process copy the headers to the build-tree, then patch them. That way I could fix the issue from the node-mapnik source package. ugly but it works. A debdiff should show up soon at https://debdiffs.raspbian.org/main/n/node-mapnik no intent to NMU in Debian.
