[Openstreetmap-dev] CSV transport encoding scheme

Thomas Walraet thomas at walraet.com
Tue Jan 24 23:28:21 GMT 2006


Immanuel Scholz a écrit :
> 
>>I think it's better to use tabulation instead of coma as separation
>>character. So we can use coma in properties values without escaping,
> 
> I am not sure, but we may loose some applications as Exel when choosing
> something different than comma as separator.

Tabs are widely use as separator. It has the advantage that nobody use
it outside computer world. (if we use coma, we have to escape/unescape
coma in properties values)

BTW, with variable-length line I dont think you could do anything
usefull in spreadcheats.


>>and coma can be use as separator for element list.
> 
> This means, you suggest mixing two different CSV-Systems into each other.
> The first is using tab as separator and embedded in one data field is a
> second CSV-line with comma as separator.
> 
> In theory, we could do that, but this is not simple CSV anymore.

If the goal is to have a text format simple to generate and to parse, I
think it's a good idea.

You can use StringTokenizer in java, split() in javascript, etc. to
tokenize each line at tabs.
Then if the first token is "street" then you know that the third token
is a segment list that could be split with coma...


I think it's much much more _simple_ to use than a flat list of elements.


> (*sigh* Another "own invented text based format".  Maybe fixing XML would
> be an attractive alternative to this.)

In fact my opinion is that OpenStreetMap should stick with XML for data
transfert, but it's not a subject for this thread ;)

Or, at least, keep a structured data format even if it's not purely CSV.





More information about the dev mailing list