Tabs and spacees within <gml:coordinates> tags.

[ethan@…]

Tabs and space are being written between <gml:coordinates> and 
</gml:coordinates> from mapgml.c

I've attached a patch file for mapgml.c 1.45

[ethan@…]

diff for mapgml.c

[ethan@…]

Frank said I should assign to him.

PS) I tested the changes on polygon, line and point shapefiles

[fwarmerdam]

Patch applied in 4.4 branch.  I will review a few similar problems in 4.5 
though the code has changed alot there. 

[fwarmerdam]

A small related patch made in 4.5 for gml:coordinates in a gml:box. All
other cases seem to have already been fixed in 4.5 as part of other rewrites.

[dmorissette]

Can someone (Frank, Ethan?) please explain why it's bad to have blank chars in a
gml:coordinate element, so that we don't reintroduce the issue by accident? IS
it the GML specs that dictates that (I didn't check, I'm just asking)? I would
have thought that blanks were more or less ignored in XML element values, i.e. a
single space is the same as a new line or a string of 10 spaces.

[fwarmerdam]

Daniel, 

The contents of the coordinates tag is "CDATA" or literal text.  It is
then interpreted according to the GML specification.  But the GML spec 
uses spaces as a delimeter between tuples (or perhaps it is values within
the tuple), and species no meaning for special characters like newlines.  

A smarter reader will strip surrounding white space off the coordinates
string, but I'm not sure if it is required to be able to or not.  Dumb
parsers often get mixed up on coordinates when there are extra newlines
or even spaces in odd places. 

So, I'm not sure if it is in-spec, but it definately screws up some parsers. 
So it seems prudent to avoid it. 

I don't know how to avoid having it crop up again. 

[dmorissette]

I had CC'd on this bug those who work on mapgml.c from time to time, so if
everyone takes note of your explanation then that should prevent the issue from
coming back. Thanks!