I have to disagree. Mathematically speaking the topological dimension
is a counting number (e.g. in the set {0,1,2,...}. I don't see any
reason why this shouldn't be represented as an integer value (and plenty
of reasons why it should - e.g. ordering, comparison, etc)
strk wrote:
On Tue, Ma
getDimension follows the OGC spec. Seems to me it's better to simply
change it to match the spec and the C++ API. This was clearly a bug in
the first place, no?
strk wrote:
On Tue, May 25, 2010 at 09:27:16PM -0400, Frank Warmerdam wrote:
I think we will have to change the values returne
On Tue, May 25, 2010 at 09:27:16PM -0400, Frank Warmerdam wrote:
> I think we will have to change the values returned by the C API getDimension
> function to match C++ even though this introduces a modest risk of problems
> for applications using the undocumented current behavior.
What's the prob
On Tue, May 25, 2010 at 01:56:25PM -0700, Martin Davis wrote:
> Maybe strk is right, and this should be changed to an enum. Perhaps the
> enum could be defined as
>
> XY = 2
> XYZ = 3
> XYZM = 4
> XYM = 5 ?
My enum suggestion was for the spatial dimension, not coordinate dimension.
PUNTUAL/LINE
On Wed, May 26, 2010 at 12:41:53AM -0400, Frank Warmerdam wrote:
> Note that I'll default to writing the new syntax. I'm not sure if I
> will support writing the old syntax or not via a flag.
If current WKTWriter didn't output old syntax it makes perfectly
sense to start the support with new syn
On 26/05/10 02:27, Frank Warmerdam wrote:
Martin Davis wrote:
Maybe strk is right, and this should be changed to an enum. Perhaps
the enum could be defined as
XY = 2
XYZ = 3
XYZM = 4
XYM = 5 ?
Or perhaps there is already a convention covering this?
My personal opinion is that the interpretat