Simplification algo appears to cause tile seam artifacts.

[remster]

We had to turn the simplification off as wedges would develop on tile seams preventing the bleed/buffer (grep for buffer) to be correctly applied. My guess is that Douglas–Peucker that you use removes poly edges that we have deliberately bleed out of the tile for proper blending. At least this is my theory.

I am not a tiling expert, but why wouldn't it be appropriate here:

	for _, p := range points {
		dx, dy := c.GetDeltaPointAndUpdate(p)
		//	encode our delta point
		g = append(g, encodeZigZag(dx), encodeZigZag(dy))
	}
	return g

to check whether there dx,dy are different from previous and skip them if they're the same. Wouldn't that serve as oftentimes sufficient simplification?

Here's the offending geometry:

{
  "coordinates": [
    [
      [
        -118.915929794311523,
        34.13671875
      ],
      [
        -118.915929794311523,
        34.08899026424313
      ],
      [
        -118.944625096552102,
        34.08899026424313
      ],
      [
        -118.949598455211159,
        34.090160115815209
      ],
      [
        -118.964824913325486,
        34.096622314681383
      ],
      [
        -118.978246085407733,
        34.105430017405581
      ],
      [
        -118.989346656919466,
        34.11624539420265
      ],
      [
        -118.997699850573255,
        34.128653494887246
      ],
      [
        -119.000850912295292,
        34.13671875
      ],
      [
        -119.002983854653664,
        34.142178092208631
      ],
      [
        -119.003992080688477,
        34.149260049035767
      ],
      [
        -119.003992080688477,
        34.161889212837202
      ],
      [
        -118.915929794311523,
        34.161889212837202
      ],
      [
        -118.915929794311523,
        34.13671875
      ]
    ]
  ],
  "type": "Polygon"
}

with simplification on:

without simplification:

[gdey]

The skipping of dy and dx was the first system we used. But it did not reduce the number of points. One thing I'm trying to figure out how to plumb through is the ability to turn off simplification on a per layer bases. Also, there is a different simplification algo, that I'm planning on implementing; but I think it will have the same effect.

[remster]

Thanks @gdey for accepting this.
Not sure i follow why skipping dx,yx==[0,0] would not reduce the number of points - at least in the use case we care for most - down-sampling for coarser zooms.
Suppose we have this poly:

{
  "coordinates": [
    [
      [0,0],
      [0.1,0.1],
      [0.2,0.2],
      [0,1],
      [1,1],
      [1,0],
      [0,0]
    ]
  ],
  "type": "Polygon"
}

If you feed it today, if i understand correctly, it will generate:

MoveTo[0,0]
LineTo[0,0] <- noop
LineTo[0,0] <- noop
LineTo[0,1],
LineTo[1,0],
LineTo[0,-1],
LineTo[-1,0]

if the loop I pointed to skipped such dx,dx==[0,0] then, correct me if i am wrong, you should get:

MoveTo[0,0]
LineTo[0,1],
LineTo[1,0],
LineTo[0,-1],
LineTo[-1,0]

and thus you have reduced the number of points if the zoom-informed scaling has floored some of the neighbours to the same int. Which is down-scaling case we care for. Of course this may turn out to be insufficient, but seems like the first useful thing to do. But like i say, i am not a tiling expert.

Thanks again.

[gdey]

Sorry, I was not being very clear in my statements. We did not see a significant amount of point reduction compared to simplification. In fact part of the makeValid I do this very thing. Just not in encode cmd, though as you correctly point out it would be a noop. So, I will put this back in. But, there are features which are detailed for the low zoom levels that are reduced significantly with Douglas–Peucker to make sense to have simplification. However, if a feature is already simplified the simplification can have an adverse effect on the geometry of the feature. The other simplification method (#166) may actually help with this as it works off the largest area instead of a threshold of a distance from a line. We, also, have #165 for plumbing through simplification. Did you use the environmental variables to disable the simplification or did you change out the encoding to skip if dx and dy are zero?

[remster]

Did you use the environmental variables to disable the simplification or did you change out the encoding to skip if dx and dy are zero?

Well, i discovered this:

• DontSimplify: true
• &tegola.BoundingBox{Z:... which i guess you need to document (show in the example)

I think it makes a hygienical sense to skip the [0,0] noops and i am not surprised this doesn't serve as sufficient simplification. I am though surprised by the very bug and Douglas-Peucker seemingly cutting a distant and crucial aspect of the polygon - where it's been cut with a straight razor (has no intermediate vertices along the whole tile seam). Maybe this is just a simple bug. Or maybe the bleed-buffer needs special protection.

thanks again!