<div>As a dedicated mapper of public transport in Birmingham I would love to participate but I currently have limited access to email in deepest rural france. I hope I dont havz to redo a lot of work! Thomas Im quite proud of Birmingham city centre bus stops perhaps q different icon from the curent osmarenderer one would be an improvement?</div>
<div> </div>
<div>Regards</div>
<div> </div>
<div>Brian<br><br></div>
<div class="gmail_quote">2009/6/3 <span dir="ltr"><<a href="mailto:talk-transit-request@openstreetmap.org">talk-transit-request@openstreetmap.org</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send Talk-transit mailing list submissions to<br> <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>
<br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">http://lists.openstreetmap.org/listinfo/talk-transit</a><br>or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:talk-transit-request@openstreetmap.org">talk-transit-request@openstreetmap.org</a><br><br>You can reach the person managing the list at<br> <a href="mailto:talk-transit-owner@openstreetmap.org">talk-transit-owner@openstreetmap.org</a><br>
<br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Talk-transit digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Public transport workshop in Germany (Peter Miller)<br>
2. Public transport schema (Sebastian Schwarz)<br> 3. Re: Public transport schema (Thomas Wood)<br> 4. Re: Public transport schema (Peter Miller)<br> 5. Re: Public transport schema (Paul Johnson)<br> 6. Re: Public transport schema (Thomas Wood)<br>
<br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Tue, 2 Jun 2009 13:04:22 +0100<br>From: Peter Miller <<a href="mailto:peter.miller@itoworld.com">peter.miller@itoworld.com</a>><br>
Subject: Re: [Talk-transit] Public transport workshop in Germany<br>To: Sarah Hoffmann <<a href="mailto:lonvia@denofr.de">lonvia@denofr.de</a>>, <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>
Message-ID: <<a href="mailto:E33A3721-C45A-4911-97A9-01AD515869E3@itoworld.com">E33A3721-C45A-4911-97A9-01AD515869E3@itoworld.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes<br><br>
<br>On 1 Jun 2009, at 23:09, Sarah Hoffmann wrote:<br><br>> On Mon, Jun 01, 2009 at 08:05:30AM +0100, Peter Miller wrote:<br>>>> For railway stations it can be sure that there is exactly one symbol<br>>>> on the line of the railway neatly aligned to the middle of the way.<br>
>>> With the new schema a lot of preprocessing and guess work will be<br>>>> required to get the same result when stop places contain multiple<br>>>> stopping places and/or access points.<br>>>><br>
>>> The current situation with bus stops is more messy. (Just see<br>>>> Birmigham which seems to entirely consist of bus stops.) While<br>>>> stop places in the new schema allow to clean this up a bit, again,<br>
>>> the renderer only has the choice to either paint two many<br>>>> symbols (all access points or all stopping points) or badly<br>>>> guess where to put the single point.<br>>><br>>> Which rendering view are you using? for the main Mapnik view on<br>
>> openstreetmap there are no bus stops until one zooms in to zoom 17 at<br>>> which point there are certainly lots of bus stops (accesses).<br>><br>> Yes, I had Mapnik in mind although the problem is a more general one.<br>
> There are no bus stops for lower zoom level because they would<br>> completely clutter any map.<br>><br>>> Even at zoom level 17 it may be appropriate to render bus stops at<br>>> the<br>>> Stop Place level of detail (with one blob for two Accesses/bus<br>
>> stops on<br>>> either sides of the road, or one blob for three Accesses/bus stands<br>>> in a<br>>> row on one side of the road).<br>><br>> Rendering the Stop Place is only useful, if there is additional<br>
> information<br>> available, e.g. the name. But how this can be displayed without<br>> overwhelming the user is an unsolved problem indeed. However, I was<br>> hoping of resolving the rendering of the lower zooms first.<br>
<br>A Stop Place should have a name - I believe that is part of the<br>definition of a Stop Place that it does have a recognised name.<br>However it may sometimes just be appropriate to to put a single dot on<br>the map for a Stop Place without a name and will be less cluttered<br>
that every Access.<br><br>><br>><br>> Actually, looking at Birmingham in the ?PNVKarte<br>><br>> <a href="http://www./?pnvkarte.de/?lat=52.47884&lon=-1.89495&zoom=17" target="_blank">http://www.?pnvkarte.de/?lat=52.47884&lon=-1.89495&zoom=17</a><br>
><br>> I see that all bus stops in the inner city belong to the same<br>> stop place, namely "city center". I know that this is very common in<br>> the UK (and very frustrating for the visitor, but that's another<br>
> story).<br>> How would you fit that into the proposed model? A stopping place and<br>> access point for each bus_stop and then all of them into one stop<br>> place<br>> relation? Subdivide them by street? How do the regular users see them,<br>
> as single bus stops or as quais of one and the same stop?<br><br>To be clear. Birmingham City Centre is too big to be a Stop Place<br>(where all points should be within a few minutes walk from each<br>other). 'Birmingham City Centre' is actually a locality name in<br>
NaPTAN. Localities are used for named settlements or suburbs. Some<br>authorities create a locality for the centre of large places.<br><br>><br>>>> Thus, if above example is modelled as two stop places with<br>
>>> oneway=yes<br>>><br>>>> and both stop places are put into a stop place group<br>>>> "Waffenplatzstrasse"<br>>>> (together with the two bus stops, which are incidentally directional<br>
>>> as well) all necessary information for the renderer should be there.<br>>>> Is this within the intended use of stop places and stop place<br>>>> groups?<br>>>> The Wiki is not very clear on this point.<br>
>><br>>> I agree that a direction does seem to be needed, both for the<br>>> Stopping<br>>> Places and also possibly for the Accesses. It is not clear how one<br>>> should code the direction - A one-way tag doesn't seem to encode<br>
>> all the<br>>> necessary information.<br>><br>> This would be more a directional information that encodes in which<br>> direction the vehicle will continue its journey from the stopping<br>> point. This would indeed suffice. Unfortunately, it brings us back to<br>
> the still unresolved question of forward/backward tagging, which<br>> seems to go nowhere.<br><br>In NaPTAN the Accesses (bus stops) have a bearing N, NE, E etc, in<br>which the vehicle leaves the stop. Slightly tricky to interpret with<br>
the mapping data, but the NaPTAN dataset if road dataset neutral so<br>can't reference any particular road data set (OS, OSM, Navteq).<br><br>><br>>> I would expect that Waffenplatzstrasse would consist of one Stop<br>
>> Place<br>>> with two accesses and two Stopping Places. Is that sufficient or<br>>> should<br>>> each Access have its own Stop Place and these be grouped into a Stop<br>>> Place Group? If one uses one Stop Place then how are the individual<br>
>> Accesses and Stopping Places associated with each other? The Accesses<br>>> need names that indicate direction, such as 'Northbound', 'towards<br>>> city<br>>> centre', 'Sto A', 'Stand A', 'Bay A', Gate 13' etc. In the UK this<br>
>> information is encoded in the 'indicator' field and the Name for the<br>>> Access (called Common Name) tends to be shared with the other<br>>> Accesses in<br>>> the Stop Place.<br>><br>
> Do you mean stopping place here? I'd expect this indicator to be<br>> unique<br>> for all accesses in a stop place.<br><br>It is good practice (that is not always followed or appropriate) for<br>all Acesses within a Stop Place to have the same name, but to all have<br>
unique indicators. I would encourage us to adopt this approach.<br><br>><br>><br>> What is the relation between accesses and stopping places? There is an<br>> example in the proposal of a stopping place having multiple accesses.<br>
> Can one access also be used for multiple stopping places?<br><br>I would suggest that where one creates an Access but no Stopping Place<br>that the system (or some tool) guesses that a Stopping Place on the<br>nearest highway/Railway is required and that they should be connected<br>
with a relation.<br><br>Where one Stopping Place is served by two Accesses or where a single<br>Access serves two Stopping Places or where there is ambiguity about<br>which highway a vehicle might stop on then we will need to create the<br>
Stopping Places and relations manually.<br>><br>><br>>> Just to note at this point that I am concerned that we will run out<br>>> of<br>>> Stop Place levels as we get into this. IFOPT allows recursive Stop<br>
>> Places which is wonderfully general but possibly hard for renders and<br>>> for our relation handling. We may want to revisit this later to allow<br>>> multilevel Stop Places.<br>><br>> As a programmer I love the idea of recursion, as a mapper I find it<br>
> awful. We should find something simpler.<br><br>Ummm. I agree with your sentiments, but not necessarily with you<br>optimism! We could try Heathrow Airport as a worst case mapping<br>challenge. (one of the busiest air ports in the world).<br>
<br>><br>><br>>> It feels to me that we need a little more time discussing and<br>>> developing<br>>> this proposal before we start tagging features with it to give us<br>>> more<br>>> time to refine the ideas.<br>
><br>> Tagging small test patches in different countries might help uncover<br>> weaknesses, we cannot see in a theoretical discussion.<br><br>Absolutely, but lets settle the tag names issue before doing that.<br>
<br>I would also like us to consider separating Access from Entrance and<br>use different tag names as per CEN feedback. Does anyone object<br><br>Also including an option for Access Areas and Boarding Points to<br>complete the model mapping to CEN.<br>
<br>There are some outstanding suggestions about the use of route (tagging<br>ways or tagging relations) which we need to bottom. Also, I feel the<br>Line Variant element could do with a little review which I will do<br>unless anyone objects.<br>
<br><br>Regards,<br><br><br><br>Peter<br><br>><br>><br>> Sarah<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 2 Jun 2009 18:34:39 +0200<br>From: Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>><br>
Subject: [Talk-transit] Public transport schema<br>To: <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>Message-ID: <<a href="mailto:8969E5E7-4B55-4D32-BBA1-992EF08CFA3F@kahlfrost.de">8969E5E7-4B55-4D32-BBA1-992EF08CFA3F@kahlfrost.de</a>><br>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes<br><br>Hi!<br><br>Well, I have been en-route the last days and thus did not have time to<br>respond to any of the numerous mails covering almost all aspects of<br>
the new proposal relating to public transport. But I see the<br>discussion sort of loosing sight of the mappers. From my point of<br>view, we should find a good compromise which primarily serves the<br>mappers and not the CEN. So, the schema should not be as compliant as<br>
possible to the standards but as good as possible for the mappers -<br>provided with a reasonable part of standard compliance, of course. We<br>do not want to model Heathrow Airport (apart from that, airports have<br>never been part of the proposal!) but we want to start with the bus<br>
station around the corner!<br><br>@Gerrit Lammert:<br>Sorry!!! Initially, we completely forgot to mention other proposals we<br>used as a source of inspiration - but now, the link to your proposal<br>is set. Anyway, in my diploma thesis (which I am currently doing on<br>
public transport in OSM) your proposal is not only refrenced but<br>analyzed, too.<br><br>Kind regards<br><br><br>--<br>Sebastian<br><a href="http://kahlfrost.de/" target="_blank">kahlfrost.de</a><br><br><br><br>------------------------------<br>
<br>Message: 3<br>Date: Tue, 2 Jun 2009 18:18:21 +0100<br>From: Thomas Wood <<a href="mailto:grand.edgemaster@gmail.com">grand.edgemaster@gmail.com</a>><br>Subject: Re: [Talk-transit] Public transport schema<br>To: Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>><br>
Cc: <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>Message-ID:<br> <<a href="mailto:1e14d5320906021018y42294a51t45bf771be71c9e8a@mail.gmail.com">1e14d5320906021018y42294a51t45bf771be71c9e8a@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br><br>2009/6/2 Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>>:<br>> Hi!<br>><br>> Well, I have been en-route the last days and thus did not have time to<br>
> respond to any of the numerous mails covering almost all aspects of<br>> the new proposal relating to public transport. But I see the<br>> discussion sort of loosing sight of the mappers. From my point of<br>> view, we should find a good compromise which primarily serves the<br>
> mappers and not the CEN. So, the schema should not be as compliant as<br>> possible to the standards but as good as possible for the mappers -<br>> provided with a reasonable part of standard compliance, of course. We<br>
> do not want to model Heathrow Airport (apart from that, airports have<br>> never been part of the proposal!) but we want to start with the bus<br>> station around the corner!<br><br>But by it's nature as the foundation of how transportation stop areas<br>
are represented in OSM, then airports are important as a higher tier<br>of transportation. By their nature, they'll often have several other<br>modes of transport related to them, metro, mainline rail, bus and<br>coach services, and they should still be seen by routing software as<br>
an interchange that could be possibly used.<br><br>In time, we will want to map them in excessive detail, whilst we have<br>the opportunity, this scheme should allow the scope for further<br>expansion of other transportation types.<br>
<br>><br>> @Gerrit Lammert:<br>> Sorry!!! Initially, we completely forgot to mention other proposals we<br>> used as a source of inspiration - but now, the link to your proposal<br>> is set. Anyway, in my diploma thesis (which I am currently doing on<br>
> public transport in OSM) your proposal is not only refrenced but<br>> analyzed, too.<br>><br>> Kind regards<br>><br>><br>> --<br>> Sebastian<br>> <a href="http://kahlfrost.de/" target="_blank">kahlfrost.de</a><br>
><br>> _______________________________________________<br>> Talk-transit mailing list<br>> <a href="mailto:Talk-transit@openstreetmap.org">Talk-transit@openstreetmap.org</a><br>> <a href="http://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">http://lists.openstreetmap.org/listinfo/talk-transit</a><br>
><br><br><br><br>--<br>Regards,<br>Thomas Wood<br>(Edgemaster)<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Tue, 2 Jun 2009 22:27:55 +0100<br>From: Peter Miller <<a href="mailto:peter.miller@itoworld.com">peter.miller@itoworld.com</a>><br>
Subject: Re: [Talk-transit] Public transport schema<br>To: Thomas Wood <<a href="mailto:grand.edgemaster@gmail.com">grand.edgemaster@gmail.com</a>><br>Cc: <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>
Message-ID: <<a href="mailto:13202734-2707-4BCA-B057-A64BCC0FF824@itoworld.com">13202734-2707-4BCA-B057-A64BCC0FF824@itoworld.com</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes<br><br><br>
On 2 Jun 2009, at 18:18, Thomas Wood wrote:<br><br>> 2009/6/2 Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>>:<br>>> Hi!<br>>><br>>> Well, I have been en-route the last days and thus did not have time<br>
>> to<br>>> respond to any of the numerous mails covering almost all aspects of<br>>> the new proposal relating to public transport. But I see the<br>>> discussion sort of loosing sight of the mappers. From my point of<br>
>> view, we should find a good compromise which primarily serves the<br>>> mappers and not the CEN. So, the schema should not be as compliant as<br>>> possible to the standards but as good as possible for the mappers -<br>
>> provided with a reasonable part of standard compliance, of course. We<br>>> do not want to model Heathrow Airport (apart from that, airports have<br>>> never been part of the proposal!) but we want to start with the bus<br>
>> station around the corner!<br>><br>> But by it's nature as the foundation of how transportation stop areas<br>> are represented in OSM, then airports are important as a higher tier<br>> of transportation. By their nature, they'll often have several other<br>
> modes of transport related to them, metro, mainline rail, bus and<br>> coach services, and they should still be seen by routing software as<br>> an interchange that could be possibly used.<br>><br>> In time, we will want to map them in excessive detail, whilst we have<br>
> the opportunity, this scheme should allow the scope for further<br>> expansion of other transportation types.<br>><br><br>Firstly, can I say again how much your proposal is appreciated. We<br>have needed to do a thorough review of PT related tagging for<br>
consistency for some time and your work is a great starting point.<br><br>Secondly, can I apologise for tearing into you document and I hope we<br>haven't ruined you thesis but from a Wikipedia perspective this is how<br>
good articles get written. People build something, others build on it,<br>some changes stick, some get challenged and removed, but the general<br>direction is positive. Your work certainly isn't going to gather dust<br>
on some shelf but will be used with a vengeance very soon - I just<br>want to make sure that we do the design work at this stage to ensure<br>that it is robust before it gets extensively used.<br><br>With reference to mappers, I really don't think we are making things<br>
much harder for the average mapper are we? Once we agree on terms and<br>definitions that is. We have rationalised platforms and bus stops and<br>ferry quays into Accesses. We have renamed Stop Areas as Stop Places.<br>We have added Stopping Places and Stop Place Groups. We are proposing<br>
a new relation binding from Accesses to Stopping Places. I am<br>proposing that we added Entrances and Boarding Points, but all these<br>are optional extras to the modelling and not something that the<br>average mapper needs to touch to start with.<br>
<br>Regarding Heathrow Airport. The coach/bus station within the airport<br>is the busiest in the UK (<a href="http://www.milesfaster.co.uk/information/heathrow-airport/heathrow-central-bus-coach-station.htm" target="_blank">http://www.milesfaster.co.uk/information/heathrow-airport/heathrow-central-bus-coach-station.htm</a><br>
) and we will of course map transport interchanges in absurd detail<br>when we run out of other things to do!<br><br>CEN: My experience is that one has to be careful when one doesn't<br>follow standards or ignores them; the old rule, 'if you can't be good<br>
be careful' comes to mind. For sure, there is some nonsense in<br>standards for geopolitical reasons, but transmodel is pretty clean and<br>so is IFOPT. If you cut corners in relation to a CEN standard you can<br>expect to come unstuck in some situation that you hadn't considered<br>
and then you will have to bodge it. For example by assuming that each<br>stopping place has only one Access and one Access is only associated<br>with one Stopping Place. I know that because I have been there and<br>done it!<br>
<br>What we have already is very good - we are not slavishly following<br>CEN, but as far as I am concerned we follow it where appropriate and<br>are now aware of the places where we are not following it and we are<br>confident that we are doing it for a good reason and that it will<br>
work. The only section that has not been reviewed in relation to CEN<br>is the section about Railway Routes, Railway Lines and Line Variants<br>which again is close but we can still learn from CEN and clarify the<br>language.<br>
<br>Ok... Um.... Well... So I have now just looked at the current<br>version of the document and noticed that you have reverted just about<br>all my changes over the past few days. I find that rather unnecessary<br>and I would like to have some clarification about why that was<br>
necessary or useful to do that without consultation. For sure some<br>changes could be challenged, but all of them? No one else had<br>challenged them on the list on the wiki since Saturday. Fyi, Here is<br>the difference between the version just before I made my first changes<br>
and the current version (they are basically the same).<br><a href="http://wiki.openstreetmap.org/index.php?title=User:Oxomoa/Public_transport_schema&diff=280182&oldid=278379" target="_blank">http://wiki.openstreetmap.org/index.php?title=User:Oxomoa/Public_transport_schema&diff=280182&oldid=278379</a><br>
<br>And here is the difference between the last version I touched and the<br>current version. I think it is clear that a huge amount of work has<br>been removed without discussion, including reverting 'loading gauge'<br>
to millimetres when it is most certainly more complex than that as I<br>explained; reverting Stop Place to Stop Area without explanation (a<br>clash with CEN terminology). Removing the alphabetical sort order for<br>the the railways section for no obvious reason. Removing '{{tag|route|<br>
ferry}}' and reverting it to 'non-existent' etc etc.<br><br>Could I politely suggest that we revert the document to the place<br>where Nixim left the document on the 31st having added '{{tag|route|<br>ferry}}'. For sure then make changes from there that you thing are<br>
good, but do build on the previous work as this is the normal way.<br><br>Can I also suggest that we move the page to the general wiki space and<br>out of your user area as this page has now definitely graduated from<br>being just a personal page.<br>
<br><br><br>Regards,<br><br><br><br><br>Peter<br><br><br><br><br>Regards,<br><br><br>Peter<br><br><br><br>>> _______________________________________________<br>>> Talk-transit mailing list<br>>> <a href="mailto:Talk-transit@openstreetmap.org">Talk-transit@openstreetmap.org</a><br>
>> <a href="http://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">http://lists.openstreetmap.org/listinfo/talk-transit</a><br>>><br>><br>><br>><br>> --<br>> Regards,<br>> Thomas Wood<br>
> (Edgemaster)<br>><br>> _______________________________________________<br>> Talk-transit mailing list<br>> <a href="mailto:Talk-transit@openstreetmap.org">Talk-transit@openstreetmap.org</a><br>> <a href="http://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">http://lists.openstreetmap.org/listinfo/talk-transit</a><br>
<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Tue, 02 Jun 2009 18:22:14 -0700<br>From: Paul Johnson <<a href="mailto:baloo@ursamundi.org">baloo@ursamundi.org</a>><br>Subject: Re: [Talk-transit] Public transport schema<br>
To: <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>Message-ID: <<a href="mailto:spvgf6xidh.ln2@ursa-major.network.ursamundi.org">spvgf6xidh.ln2@ursa-major.network.ursamundi.org</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br><br>Thomas Wood wrote:<br>> 2009/6/2 Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>>:<br>>> Hi!<br>>><br>>> Well, I have been en-route the last days and thus did not have time to<br>
>> respond to any of the numerous mails covering almost all aspects of<br>>> the new proposal relating to public transport. But I see the<br>>> discussion sort of loosing sight of the mappers. From my point of<br>
>> view, we should find a good compromise which primarily serves the<br>>> mappers and not the CEN. So, the schema should not be as compliant as<br>>> possible to the standards but as good as possible for the mappers -<br>
>> provided with a reasonable part of standard compliance, of course. We<br>>> do not want to model Heathrow Airport (apart from that, airports have<br>>> never been part of the proposal!) but we want to start with the bus<br>
>> station around the corner!<br>><br>> But by it's nature as the foundation of how transportation stop areas<br>> are represented in OSM, then airports are important as a higher tier<br>> of transportation.<br>
<br>Depends on the part of the world. If you're in the US, the pain in the<br>ass, time required and sheer expense associated with air travel starts<br>making Amtrak, VIARail and booking rooms on transoceanic cargo ships<br>
starts looking like a real attractive option regardless of the distance,<br>relegating air travel to a more useless position than the US NCN...<br><br><br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>
Name: signature.asc<br>Type: application/pgp-signature<br>Size: 260 bytes<br>Desc: OpenPGP digital signature<br>Url : <a href="http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090602/8b78a265/attachment-0001.pgp" target="_blank">http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20090602/8b78a265/attachment-0001.pgp</a><br>
<br>------------------------------<br><br>Message: 6<br>Date: Wed, 3 Jun 2009 10:52:10 +0100<br>From: Thomas Wood <<a href="mailto:grand.edgemaster@gmail.com">grand.edgemaster@gmail.com</a>><br>Subject: Re: [Talk-transit] Public transport schema<br>
To: Paul Johnson <<a href="mailto:baloo@ursamundi.org">baloo@ursamundi.org</a>><br>Cc: <a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.org</a><br>Message-ID:<br> <<a href="mailto:1e14d5320906030252l508eef5y96949ca6bc2a72bf@mail.gmail.com">1e14d5320906030252l508eef5y96949ca6bc2a72bf@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br><br>I am not considering air travel on a national level, international<br>(possibly even inter-continental) routing is an area I'd like to see<br>developed :)<br><br>On 03/06/2009, Paul Johnson <<a href="mailto:baloo@ursamundi.org">baloo@ursamundi.org</a>> wrote:<br>
> Thomas Wood wrote:<br>>> 2009/6/2 Sebastian Schwarz <<a href="mailto:yugo@kahlfrost.de">yugo@kahlfrost.de</a>>:<br>>>> Hi!<br>>>><br>>>> Well, I have been en-route the last days and thus did not have time to<br>
>>> respond to any of the numerous mails covering almost all aspects of<br>>>> the new proposal relating to public transport. But I see the<br>>>> discussion sort of loosing sight of the mappers. From my point of<br>
>>> view, we should find a good compromise which primarily serves the<br>>>> mappers and not the CEN. So, the schema should not be as compliant as<br>>>> possible to the standards but as good as possible for the mappers -<br>
>>> provided with a reasonable part of standard compliance, of course. We<br>>>> do not want to model Heathrow Airport (apart from that, airports have<br>>>> never been part of the proposal!) but we want to start with the bus<br>
>>> station around the corner!<br>>><br>>> But by it's nature as the foundation of how transportation stop areas<br>>> are represented in OSM, then airports are important as a higher tier<br>
>> of transportation.<br>><br>> Depends on the part of the world. If you're in the US, the pain in the<br>> ass, time required and sheer expense associated with air travel starts<br>> making Amtrak, VIARail and booking rooms on transoceanic cargo ships<br>
> starts looking like a real attractive option regardless of the distance,<br>> relegating air travel to a more useless position than the US NCN...<br>><br>><br>><br>><br><br><br>--<br>Regards,<br>Thomas Wood<br>
(Edgemaster)<br><br><br><br>------------------------------<br><br>_______________________________________________<br>Talk-transit mailing list<br><a href="mailto:Talk-transit@openstreetmap.org">Talk-transit@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">http://lists.openstreetmap.org/listinfo/talk-transit</a><br><br><br>End of Talk-transit Digest, Vol 6, Issue 3<br>******************************************<br>
</blockquote></div><br>