Poorly encoded multipoints

[springmeyer]

Currently in v0.9.x multipoint geometries are not encoded correctly. Multipoints are currently being encoded as:

directive,dx,dy,directive,dx,dy,directive,dx,dy....

Where directive is the command that stores the command (e.g. move_to in this case) and the length of repeated commands (number of move_to commands). The problem is that the directive is always encoding cmd=move_to and length=1 which it not ideal.

Instead multipoints should be encoded as:

directive,dx,dy,dx,dy,dx,dy,dx,dy.

Where directive is cmd=move_to and length=4 (or more).

This is likely a regression around the time of this merge.

While compliant decoders should (and do) handle this type of encoding, it is incorrect in the sense that it does not take advantage of the ability of the directive to tell the decoder about the # of repeated commands. This bug therefore makes it impossible to take advantage of this obvious optimization (for multipoints): #119

[springmeyer]

The bug is right here:

mapnik-vector-tile/src/vector_tile_processor.ipp

Lines 928 to 937 in 37f42a2

	for (auto const& pt : geom)
	{
	if (first)
	{
	first = false;
	backend_.start_tile_feature(feature_);
	backend_.current_feature_->set_type(vector_tile::Tile_GeomType_POINT);
	}
	path_count += backend_.add_path(pt);
	}

. Instead of encoding each point of a multipoint separately the encoder should be encoding the multipoint itself.

[springmeyer]

fixed in 4a3017c

[springmeyer]

landed in master (and future v0.9.2) in 2f71ea9