> >
>> > y = 0, 0, 20, 20, 0, 1, 5, 1, 1, 15, 19, 15, 15, 15, 19, 15, 15, 25,
>> 25, 29,
>> > 25, 25, 25, 29, 25, -40, -45, -30, -40, -35, -30, -10, -5, -20,
>> -35, -20, -15, -25, -20, 20,
>> > 40, 40, 20, 5, 10, 15, 5 ;
>> >
>>
th contiguous_ragged_dimension pointing to the
> dimension of the coordinate index variable to determine how to index into
> the coordinate index.
> > Iterate over polygons, parsing out geometries using the contiguous
> ragged start variable and coordinate index variable to interpret the
> coordinate data variables.
> > Or, without reference to timeSeri
Dear Bob,
I’ll just take these in line.
1) noted. We have been trying to figure out what to do with the point
featureType and I think leaving it more or less alone is a viable path forward.
2) This is not an exact replica of WKT, but rather a similar approach to WKT.
As I stated, we have
1) There is a vague comment in the proposal about possibly changing the
point featureType. Please don't, unless the changes don't affect current
uses of Point. There are already 1000's of files that use it. If this new
system offers an alternative, then fine, it's an alternative. One of the
most
