
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 10 Sep 2009, at 09:01, Frankie Roberto wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">2009/9/10 Peter Miller <span dir="ltr"><<a href="mailto:peter.miller@itoworld.com">peter.miller@itoworld.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im"><br> On 10 Sep 2009, at 00:45, Thomas Wood wrote:<br> <br> > NaPTAN provides relations for stations (or at least it should, I've<br> > yet to check), in most cases, this will contain the station node, and<br> > entrance nodes, and child relations eg, the stops outside of it.<br> > I've yet to import them, but I do have all the backreferences stored<br> > to do so.<br> <br> </div>NaPTAN allows for a hierarchy of stop areas.<br> <br> In NaPTAN there should be a Stop Area for all the features directly<br> associated with the railway station.<br> <br> There can then be other (un-related) stop areas associated with groups<br> of bus stops around the station<br> <br> I believe that an additional Stop Area can then be used to bind all of<br> the above into one. The rendered can then choose to do one blob for<br> all the public transport features around the station, or one for<br> station itself and to identify every feature individually.<br> <br> Stop Areas are not well used across the UK, some areas use them, some<br> don't and where they are used the data can be a little suspect.<br> Possibly we could aim to do a better job over time?<br></blockquote><div><br>So, in the case of a large train station that's surrounded by bus stops, we should aim for one relation that contains all the train station elements (platforms, walkways, stopping points, etc), one relation that contains all the bus stops, and then have both of those relations belong to a parent relation...?<br> <br></div></div></blockquote>To be clear, there may be many groups of bus stops around the station in their own logical groups and these would be modelled separately in NaPTAN and also in IFOPT. Let's decide what we want, rather that just following the standards but I think the approach is pretty sensible.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>These seems a little over-complicated to me - are there any benefits to doing it this way, rather than having a single relation in OSM?<br><br></div></div></blockquote><div><br></div>It allows more finessing of the level of detail as one zooms in. The overall Stop Area is also a good indication to routing engines that one can reasonably transfer between modes</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Also, what happens in the case that there are multiple modes (tram, metro) within a train station - does each of these get its own relation, or is it more the case that we should simply separate features within a station building, and features outside of the building on the road network (bus stops, maybe tram stops) that are simply used to connect to the station?<br> <br></div></div></blockquote>A pair of tram stops would be in a relation separately from a groups of bus stops, and then these might be combined.</div><div><br></div><div>However... do feel free to create simpler stop areas to start with - the model can build in complexity as needed over time, even if the stop areas need to be refactored later.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Frankie<br><br>P.S Waterloo station seems to have 3 relations: <a href="http://wiki.openstreetmap.org/wiki/United_Kingdom_train_stations">http://wiki.openstreetmap.org/wiki/United_Kingdom_train_stations</a><br> </div></div></blockquote><div><br></div>It does appear to be a little complex around Waterloo and possibly wrong?</div><div><br></div><div>The stop areas you refer to have type codes which are described in the NaPTAN schema document, but I am not clear that it is at all correct based on a quick look I also notice that many of the areas have duplicate names which also makes it harder to sort out.</div><div><br></div><div>I believe that there is another relation in NaPTAN for the station that has not yet been imported into NaPTAN which makes it even more complicated.</div><div><br></div><div>Let's use Waterloo as a test case for OSM. Bank/Monument would also be useful because it is given as an example in the NaPTAN documentation. Lets also focus on the stations given in the IFOPT documentation examples. Incidentally Waterloo is used as an example thoughout the IFOPT documentation.</div><div><br></div><div>Possibly we should have a mapping party there (I passed though it yesterday as it happens).</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div>Peter</div><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"> </div>-- <br>Frankie Roberto<br>Experience Designer, Rattle<br>0114 2706977<br><a href="http://www.rattlecentral.com">http://www.rattlecentral.com</a><br><br> _______________________________________________<br>Talk-transit mailing list<br><a href="mailto:Talk-transit@openstreetmap.org">Talk-transit@openstreetmap.org</a><br>http://lists.openstreetmap.org/listinfo/talk-transit<br></blockquote></div><br></body></html>