v1.0.2 draft #36
v1.0.2 draft #36
Conversation
|
|
||
| Geometries are stored as an a single array of integers that represent an command,x,y stream (where command is a rendering command like `move_to` or `line_to`). Commands are encoded only when they change. | ||
|
|
||
| Geometries with multiple parts (multipoint, multiline, or multipolygon) should be encoded one after another in the same `geometry` field and therefore are "flattened". Geometries with only a single part will have only a single `move_to` present. For multipoints and multilines a repeated `move_to` will indicate another part of a multipart geometry. For polygons a repeated `move_to` will indicate either either another exterior of a new polygon part or an interior ring of of the previous polygon part. The winding order should be used to distinguish between the two types: polygon interior rings (holes) must be oriented with the opposite winding order than their parent exterior rings and all interior rings must directly follow the exterior ring they belong too. Exterior rings must be oriented CCW and interior rings must be oriented CW (when viewed from the "top") |
There was a problem hiding this comment.
must directly follow the exterior ring they belong too
typo? "belong to"
|
This looks good to me. 👍 |
|
Flyby comment.... What's the suggested format for the raster data? And is that info supposed to be encoded in the tags? |
…e spec a little with more sections.
|
The improvements make sense 👍 |
Clarify Winding Order
|
|
||
| Geometries are stored as an a single array of integers that represent an command,x,y stream (where command is a rendering command like `move_to` or `line_to`). Commands are encoded only when they change. | ||
|
|
||
| Geometries with multiple parts (multipoint, multiline, or multipolygon) should be encoded one after another in the same `geometry` field and therefore are "flattened". Geometries with only a single part will have only a single `move_to` present. For multipoints and multilines a repeated `move_to` will indicate another part of a multipart geometry. For polygons a repeated `move_to` will indicate either either another exterior of a new polygon part or an interior ring of of the previous polygon part. The winding order should be used to distinguish between the two types: polygon interior rings (holes) must be oriented with the opposite winding order than their parent exterior rings and all interior rings must directly follow the exterior ring they belong to. |
There was a problem hiding this comment.
For polygons a repeated
move_towill indicate either either another exterior of a new polygon part or an interior ring of of the previous polygon part.
In the fourth sentence, should either either and of of just be one either and one of?
|
Just wondering — should we also mention that polygon geometries need to be strictly simple? |
|
|
||
| Geometry collections are not supported. | ||
|
|
||
| Geometries SHOULD be clipped, reprojected into spherical mercator, converted to screen coordinates, and MUST be [delta](http://en.wikipedia.org/wiki/Delta_encoding) and [zigzag](https://developers.google.com/protocol-buffers/docs/encoding#types) encoded. |
There was a problem hiding this comment.
SHOULD be clipped, reprojected into spherical mercator
Geometries are stored as graphics in the tiles, as they are projected, clipped and converted to screen coordinates.
The client doesn't have to know about what projection the geometries were before that process, as it consumes only the final screen coordinates.
I wouldn't word this as SHOULD IMO
|
This pull request have been closed with out merging due to the new version 2 pull request #39 |
v1.0.2 proposed
rasterproperty on feature/cc @mourner @jfirebaugh for review.