I have always why it was escaped. For my part I will have to comment out code that translated those escape sequences into char(10) which will be nice because then my code doesn't have to have special cases for the tab files when I am reading in from both shapefiles and tab files in one reader. It may break a tiny bit of my code but going forward it will be easier to maintain so for my two cents I say change it because I will only have to comment some lines out not re-write anything.
-----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Daniel Morissette Sent: Friday, July 08, 2005 8:39 AM To: [email protected] Subject: [mitab] Use of escaped '\n' in string attributes Hi, It has been pointed to me that the way MITAB returns newlines in escaped "\n" format in string attribute values is not consistent with the way other OGR drivers do things. (See quoted email from the MapServer-Dev list below) Since MITAB is also used as a driver in the OGR library, it seems that the best way to go would be to align its behavior with the behavior of other OGR drivers, which would mean that the escaped "\n" should actually be returned as a single ASCII-10 character in the future (which is what is stored internally in a .DAT file). In the case of MIF files, the "\n" sequence from the files would also be converted to ASCII-10 by the library. I realize that this is a serious change and may cause a problem to existing apps using MITAB that expect the escaped "\n" sequence, that's why I'm writing this, to get feedback from users. Perhaps we could also expose a new set of EscapeString() and UnEscapeString() methods for those who want to work with escaped versions of the strings. Any comments, suggestions? Daniel -------- Original Message -------- Subject: Re: [UMN_MAPSERVER-DEV] OGR WRAP character Date: Fri, 8 Jul 2005 11:09:15 -0400 To: [EMAIL PROTECTED] Frank Warmerdam wrote: > > My first thought is that the MITAB driver should not be turning char-10 > into escaped \n format. The \n character is legal (though possibly > occationally a nuicance) in attribute values and I don't think most other > drivers fool with special characters like this. > So should I take this as a clear statement that it is okay (and actually the recommended way) for an OGR driver to return strings with non-printable characters in them? I guess that was my main question before making a decision on what to do about the specific problem between MITAB and MapServer. > Since Daniel "owns" MITAB you guys are welcome go ahead to a > change to the behavior if you are comfortable with it, though it might > be nice to raise the issue on the mitab mailing list. > Still not sure what to propose for MITAB: MIF files contain '\' + 'n', so that's what users of the lib are likely to expect. If MIF files return one thing and TAB files return a different thing then that means applications using MITAB need to handle both cases in a different way which is ugly. Changing the behavior to return ASCII-10 even in the MIF case may be the way to go, I'll have to dig and try to figure out why I bothered implementing this escaping in the first place. yuck! Thanks for your input. Daniel -- ------------------------------------------------------------ Daniel Morissette [EMAIL PROTECTED] DM Solutions Group http://www.dmsolutions.ca/ ------------------------------------------------------------ Yahoo! Groups Links Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/mitab/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
