row, so I can
>> then use that to access individual rows for future access -- if you are
>> accessing via OpenDAP -- that's particular helpful.
>>
>>
>>
>>
>> So -- (b) is clearly (to me) the "best" way to do it -- but is it worth
>> introd
risky to me to take just the first (easy?) step "to
> support the use cases that have a compelling need today" and not solve the
> entire problem. I know the CF way is to just solve real, current needs, but
> in this case it seems to risk a head slap moment in the future when
eatures: I suspect that there will have to be enough custom code
>>>> that the ragged array bits are going to be the least of it.
>>>>
>>>> So I'm for the "new" way of representing ragged arrays
>>>>
>>>> -CHB
>>>
for different b indices.
>> DSG solved this (5 different ways!), but only for DSG.
>> The Simple Features proposal seeks to solve the problem for Simple Features.
>> We still have no support for Unicode variable-length Strings.
>>
>> Instead of continuing to solve t
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
