[Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-06 Thread John Doe
Stereo and I have been working on a schema that makes it easier to create and maintain public transport route relations. We would like to invite feedback, questions, and suggestions, so it can mature and hopefully gain widespread use.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-06 Thread John Doe
m] then including the > platform in the relation means you need to include ways as relation members. Thank you for pointing that out. The ways it referred to were highways and railways - it has, of course, no objection to platforms as ways or areas. I have reworded the section, hopefully it is clearer.

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-06 Thread John Doe
ything first, then render instead of just > render the route from OSM? Seems so. Is it a significant burden to include a router with a renderer? > Vr gr Peter Elderson > > Op vr 6 mrt. 2020 om 11:08 schreef John Doe < music.kash...@gmail.com > [mailto:music.kash...@gmail.com] >:

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-06 Thread John Doe
06-Mar-2020 20:39:30 Peter Elderson : > > [...] Is it a significant burden to include a router with a renderer? > I wouldn't know. It seems strange to me that established routes have to be > re-routed to display or use them. How can you be sure the re-created route is > the one that is

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-10 Thread John Doe
> > Given that iD still seems to scramble sorted routes in some circumstances, > one should not assume that editors will correctly handle any changes we make. > I might be being unfair to iD here, I didn't check the route was still sorted > before I added a spur, so maybe somebody else doing

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread John Doe
> > I suggest again: Make the route a separate route relation and include it as > an optional member of the PTv3 routing relation as proposed. Everybody happy > (routing lobby AND route lobby), all bases covered including backward > compatibility. > > Thank you for that suggestion,

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread John Doe
Hey, thanks for sharing your views  07-Mar-2020 03:01:41 Phake Nick : > [...] for such renderer to work, access restriction for public transit > vehicle need to be complete, which is rather difficult not just because of > the work it take or the current incompleteness of the amount of keys

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread John Doe
really new. Just a alternative to > > routing which has been around since relations were introduced. > > Definitely not 'PTv3'. The 'via' option appears almost as difficult to > > maintain as including ways. > > > > > > On 08/03/2020 01:41, John Doe wrote: > &g

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-07 Thread John Doe
As mentioned in the Caveats section of the proposal, hail and ride _has_ been in our thoughts.  (Buses operated by NMRTC in Noida are all hail and ride, and so are all share autos in Delhi, making it quite important for me personally.) My idea, initially, was to have this proposal serve as

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-07 Thread John Doe
08-Mar-2020 03:56:45 Joseph Eisenberg : > > > routes without fixed stops can easily be represented using only via points > > and stop positions > > > > I think you mean "bus stops" (or railway platforms), not > "public_transport=stop_position", since those nodes are usually > unnecessary, and