Repository navigation
Clarification of expected value for npoints in linear ring #26
Description
Current specification for polygons is:
for each ring there will be
an npoints unsigned varint giving the number of points in the ring
a pointarray of varints
rings are assumed to be implicitly closed, so the first and last point should not be the same
It would be interesting to specify if npoints should contain the real number of points of the ring, or the encoded number of points that should be read (thus excluding the last point of the ring).
Example with POLYGON((0 0,1 1,1 0,0 0)) : should npoints be 3 or 4?
Activity
pramsey commentedon Jan 28, 2022
npoints is the encoded number of points to be read, though in the case of your example, there is no rule about discarding the end points. Examining the code, point arrays are evaluated from front to back, and dupes in the stream are discarded, so the fact that start==end will not be noticed by the code and mostly both points will end up encoded.
pramsey commentedon Jan 28, 2022
So actually the spec and the (postgis) code disagree, which is interesting. postgis code definitely encodes all the (non duplicate) entries in the point array, and specified a minimum output size of 4 for polygon rings (so start==end).
The postgis reader on the other hand does check for ring closure and adds a point if the start!=end. So it is tolerant of both closed and unclosed input.
So it's not clear that the code can tell us anything about what the spec should be. @nicklasaven ?
nicklasaven commentedon Jan 29, 2022
I think that the spec should be that readers are supposed to handle both cases. For writers the prefered behavior is to not have same first and last point in the name of tinyness. I don't remember why it is worded as it is. Any objections to that?
pramsey commentedon Jan 29, 2022
Sounds good. So it's actually a number of statements
nicklasaven commentedon Jan 30, 2022
murdos commentedon Jan 30, 2022
Thanks for the clarification.
I think it could also be worth mentioning in the specification that for linestrings, encoder may remove duplicate consecutive coordinates (either from input geometry or after applying encoding precision).
So it would be excepted that encoding then decoding a geometry may produce a difference in the number of coordinates.
WDYT?