[Openstreetmap-dev] Streets in GPX

[Immanuel Scholz]

Hi,

> > Now you are starting to introduce structure. A new data type: bus route.
> > May be you are able to share that datatype and label it "route". Still the
> > resulting structure is more complex than the simple "tracks=routes=streets
> > are vectors of street segments".
> 
> That's true, bus routes represented this way would probably have to go in some 
> other data format, not GPX (an argument for a custom data format in the 
> long-term?)

Bus routes are just streets are just routes are just tracks. There is no
difference in structure, only in data. The difference in data will be an
key/value which says: this is a bus route.


> > bus 13
> > --------\
> >          \                  Baker street
> > -----A----+------B-------+-----C--------
> > Baker street              \
> >                            \ bus 13
> >                             \
> >
> > If the track segment was former composed of a single track segment ABC, it
> > is now split into A, which only belongs to "Baker Street", B which is
> > assigned to both, the street and the bus route and C, which is only in
> > "Baker Street" too.
> 
> How would one explicitly link a bus route to a street? I'm guessing it will be 
> as follows (but I'm probably wrong...) 

You don't link them together. A street consist of several street
segments. So do a bus route. In my example, some segments are shared
between the street and the bus route. This is the "link".

This works, regardless whether you have n-node-segments or
2-node-segments. That was the point I wanted to make. ;-)


> Presumably the nodes (=trkpts) in the GPX will be tagged with an ID which 
> incorporates the street ID?

1) There is no "trkpts". You probably mean wpt ;-)
2) Not the points have links to their street, but the street is build
from points:

<trk>
  <name>Baker Street</name>
  <trkseg>
    <wpt lat="10" lon="10" />
    <wpt lat="11" lon="11" />
  </trkseg>
  <trkseg>
    <wpt lat="11" lon="11" />
    <wpt lat="20" lon="20" />
  </trkseg>
  <trkseg>
    <wpt lat="20" lon="20" />
    <wpt lat="21" lon="21" />
  </trkseg>
</trk>
<trk>
  <name>Bus route #13</name>
  <trkseg>
    <wpt lat="40" lon="40" />
    <wpt lat="11" lon="11" />
  </trkseg>
  <trkseg>
    <wpt lat="11" lon="11" />
    <wpt lat="20" lon="20" />
  </trkseg>
  <trkseg>
    <wpt lat="20" lon="20" />
    <wpt lat="50" lon="50" />
  </trkseg>
</trk>

In this example, the bus route shares the middle track segment with the
baker street. Unfortunatly, you can't specify the link directly within
GPX (without extensions), since trkseg does not have an id.


> Baker Street: route ID 10
> Baker Street segment A: nodes 10n to 10n+1
> Baker Street segment B: nodes 10n+1 to 10n+2
> Baker Street segment C: nodes 10n+2 to 10n+3
> 
> Bus route: incorporates nodes 10n+1 to 10n+2 (amongst others)
> 
> divide by n and we get 10, and we know this is a Baker Street segment, i.e. 
> the bus follows Baker Street.

Please.. if you want to store more than one different pieces of
information, use more than one different variables. Do not mangle two
informations into one thing (except in case of emergency ;)

Such things as "this is an id but if it divided by the id of a street,
this segment belongs to this street" are going to kill you in long term
view! (This is a promise - either they kill you or I come along ;-)

Better say: This is an id. And this other value is the id of the street.
Cleaner, simpler, easier to understand and code. :-) (But remember, that
it is a bad idea to store the id of the street a segment belongs to
within the segment, since the segment could be part of more than one
street. So better store the id of the segment in the street..)


> Even the "streets with gaps" scenario does not necessitate the two-point 
> segments; for example (as I said in another message) the A34 has a gap 
> between Oxford and Birmingham; it could be treated as two segments each of 
> many points.

That's what I talking about: The two systems are equal in power. ;) You
can't find anything that can only expressed in the one but not in the
other. 

(I am sure, since you can convert one into the other ;)


Ciao, Imi.