Update to use Wagyu for clipper #719
Conversation
…as submodule dependencies until resolution on proper way to include external C++ header only library, updated to use std c++14
…p to new build system. Updated to use 1.3.0 of mapnik-vector-tile.
|
I've started reviewing the visual changes. Right off I see something that looks problematic - it appears as if valid polygons are being lost with wagyu or the changes related to integrating wagyu. If you look at the change to the
While the new image is missing northern Norway:
(Run the "swipe" on the github diff page or open them both in a browser tab and flip back and forth and the difference is obvious) The missing regions appear to be |
|
The before:
after:
|
| assert.equal(validityReport.length, 25); // Dataset not expected to be OGC valid | ||
| assert.equal(validityReport2.length, 0); // Dataset not expected to be OGC valid | ||
| assert.equal(validityReport3.length, 26); // Dataset not expected to be OGC valid | ||
| assert.equal(validityReport4.length, 25); // Dataset not expected to be OGC valid |
There was a problem hiding this comment.
@flippmoke can you offer an explanation for why these results are so different between clipper and wagyu?
There was a problem hiding this comment.
@springmeyer they are completely different outputs, some of this is due to snap rounding, but in general the number of errors and warnings that boost geometry is valid reports here has completely changed. We have found that in the multipolygon case it is often wrong, this is why this has the not expected to be OGC valid is left there still. This is an old warning but none the less a problem that we have seen. Hopefully it will be fixed soon in some bug fixes that boost geometry is working on.
| @@ -3095,7 +3095,7 @@ describe('mapnik.VectorTile ', function() { | |||
| "id":1, | |||
| "type":3, | |||
| "geometry":[ | |||
| [[2784,1776],[1976,1776],[1976,992],[2784,992],[2784,1776]] | |||
| [[1976,1776],[1976,992],[2784,992],[2784,1776],[1976,1776]] | |||
There was a problem hiding this comment.
Is this reversed ring direction expected?
There was a problem hiding this comment.
Not a reversed ring direction, just a shift in the starting position of the rings.
| assert.deepEqual(vtile3.names(),["water","admin"]); | ||
| vtile3.render(map,new mapnik.Image(256,256),function(err,im) { | ||
| if (err) throw err; | ||
| assert.equal(0,compare_to_image(im,expected_file)); | ||
| vtile4.composite([vtile2],{reencode:true,max_extent:world_clipping_extent}, function(err) { | ||
| if (err) throw err; | ||
| assert.equal(vtile4.getData().length,54522); | ||
| assert.equal(vtile4.getData().length,54576); | ||
| assert.deepEqual(vtile4.names(),["water","admin"]); |
There was a problem hiding this comment.
are these buffer sizes consistently bigger with this PR because less data is dropped per #719 (comment)?
There was a problem hiding this comment.
Wagyu tends to be able to keep more data then the angus clipper did in general for attempting to put valid geometry into the data. Therefore, it has been fairly consistent that more data has been added.
|
As per the questions around: #719 (comment) This is in some ways related to mapbox/mapnik-vector-tile#131. Originally when we first put in the Angus clipper we were finding that better outputs with less errors were occuring when we did Wagyu was designed to deal with all the problems that |
|
I really hate it when I don't remember why we have a test, but we do... The data is not missing from the tile because This is the funky case when we are testing the rendering from a vector tile using a negative buffer. This might be slightly different due to a slight change in a coordinate of this little region that perhaps made mapnik do something different, or perhaps the latest version of mapnik has a small change here? |
No description provided.