[Openstreetmap-dev] OSM's Schema - moving it forwards.

Immanuel Scholz immanuel.scholz at gmx.de
Thu Dec 1 10:53:37 GMT 2005


Hi,

>> I doubt that the XML converting part is the most complicated thing we
>> currently have.
>
> Wrong. Based on the amount of effort spent on the OSM mailing lists with
> debating the intricacies of the data transmission format, it is the most
> "complicated" issue. Or at least the most charged.
>
> It's with this wasted effort that I am concerned.

Well, I like to differentiate between "defining the data structure" and
"defining the transport format".

I only used the "transport format" XML to express my ideas about how the
data should be structured. I did it because I already know XML while I do
not know CSV or any other transport format as well.

My suggestion schema was the idea of reference data objects by id and send
it as a list rather than a hirachical tree where every data object contain
the full data of all childs, even if that mean to double data (as in GPX).



GPX send data by sending tracks which fully contain segments which in turn
contain points:

<trk><trkseg><trkpt lat=10 lon=20/></trkseg></trk>
<trk><trkseg><trkpt lat=10 lon=20/></trkseg></trk>

Both tracks contain the same point but both need to repeat the
information, which means data doubled and it is not clear whether there
are two points above each other or if these are the same point. Same is
for trkseg's that are part of a track: does the track segment above is
really the same track segment or is it another accidently have the same
point stored in it?


This is inefficient and not the idea of OSM data storage, where segments
and points should be reused and combined to other objects if necessary.


So I suggested a data structure where this fits better. I just used XML as
transport format because GPX uses XML, because many people love XML,
because data in XML is somewhat self explained and because I just believe
that it does not matter in terms of performance (if the right library
used).


Now, if you disagree that XML fits as a transport format, we can discuss
another transport format. Make a concrete suggestion of the CSV structure,
write some ruby and maybe point out a java library for CSV and we can try
it out.

But it could be wise to first profile some performance measurements on the
server and applet since I still bet that the XML part is not the problem.


Ciao, Imi.






More information about the dev mailing list