A functioning Public Transport plugin

Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

A functioning Public Transport plugin

JOSM Development mailing list
Currently, mapping public transport routes is extremely tedious.

 Firstly, you have to select all the ways in order, and add them to the relation. This is usually not that difficult, however if it is a long distance route then downloading data becomes a problem. (The best solution to this I can find is using the continuous download plugin and suppressing dialogues).

In my area, ways are already mapped in PTV1, so all I have to do is download the relation and reselect all the ways so that they are in order again.

Afterwards, you have to add stops one by one. This is the tedious part. In the UK, we have access to the website https://bustimes.org , which gives bus timetables and stops that a route takes. (It is all open data). This makes finding and adding stops to a route relation relatively easy.

However, even with this website, adding stops to a relation is very, very slow.

The last tedious step is adding "opening_hours" and "interval:conditional" tags. (Note that the wiki is unclear about using these tags for pt routes, so I am going to ask about this in the tagging mailing list.)

All of this is very difficult and more importantly, slow. So naturally I searched for methods of speeding this up. Of course, the only way to map pt relations at a decent speed is in JOSM (you can use id, but it is far too slow).

Looking at the list of plugins, I found two plugins:

1. "pt_assistant"
2. "public transport"

"pt_assistant" is simply a validator.

"public transport", however, seemed to do exactly what I wanted. The documentation on the wiki page was long and sort of difficult to understand, however eventually I got the hang of it.

It gives options to create bus routes from GPX tracks you have recorded, as well as sort routes and "suggest stops".

Taking an entire bus journey to map it in OSM is impractical (often impossible for long distance routes).

However, the other two options seem incredibly useful. I tried sorting routes - however it didn't seem to work: it would break them up and completely mess up the order.

However, the final feature, "suggest stops", turned out to be a godsend - when it worked. You have to indicate which side of the road the stops will be on, and it would suggest stops on that side of the road (within reasonable distance).

Sadly, the catch with this addon is that it is written in an outdated public transport scheme (the "oxomoa scheme"), meaning that it uses "forward" and "back" roles to determine which side of the road to check. When these roles aren't present, it simply checks using the direction of the way, in other words often it gives stops on the wrong side of the road.

The JOSM relation editor, however, can tell whether a way is "forward" or "backward" without needing those roles explicitly mentioned by looking at the previous and next way.

A similar problem occurs with the "sort ways" function: it adds "forward" and "backward" roles (as well as ruining the order).

Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".

So, my request to any JOSM developer who is interested:

Can this addon be rewritten as an open-source addon that supports PTV2 and actually works?

This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.

I don't know how difficult this is, it could be that this is very difficult and no-one has the time to fix this, which would really be unfortunate.
Thanks for your consideration,

IpswichMapper
Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
Hi all,

thank you for the feedback.

> Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".

The plugin is open source, see
https://github.com/openstreetmap/josm-plugins/tree/master/public_transport

The problem is that maintaining the plugin is a lot of work. I abandoned
the development long ago because public transport v2 would have meant
too much work, because the scheme has inherent flaws. Any such flaw does
fall on the developer multiple times, for implementation, for developing
test cases for all the undefined corner cases, for a UI that explains
what the software actually does.

By contrast, updating to a single different set of tags for stop poles
is not a substantial problem.

> This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.

Since writing this plugin, the relation editor has superseded most of
the way sorting features. Thus, it no longer makes sense to duplicate
the sorting capabilities in a distinct plugin.

I would nowadays add buttons to the relation editor rather than a
separate relation editor.

There is also an unfinished routing algorithm in the plugin. I never had
found a reasonable UI to exhibit that to the end user.

Best regards,

Roland

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

Dirk Stöcker
In reply to this post by JOSM Development mailing list
On Fri, 13 Nov 2020, ipswichmapper--- wrote:

> Can this addon be rewritten as an open-source addon that supports PTV2 and actually works?

Why should we rewrite it? It's already open source like most (all?) official plugins.

https://josm.openstreetmap.de/browser/osm/applications/editors/josm/plugins/public_transport

As for improvements, feel free to help yourself if you think a topic
important enough. Patches are always welcome.

Otherwise all JOSM contributors developing stuff in their free time and
they naturally choose tasks which are important or interesting to
themself.

We're happy to help everybody who wants to help but does not yet have
enough knowledge if the willigness to learn is visible.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
In reply to this post by JOSM Development mailing list
Great! This should hopefully simplify the improvement of this addon.

1. What inherant flaws did the sudtem have?
2. How easy is it to determine if a way is "forward" or "backward" automatically?

Also, it seems that the relation editor can sort ways, so a rewrite of this addon can remove this feature.
--



13 Nov 2020, 20:53 by [hidden email]:

> Hi all,
>
> thank you for the feedback.
>
>> Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".
>>
>
> The plugin is open source, see
> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
>
> The problem is that maintaining the plugin is a lot of work. I abandoned
> the development long ago because public transport v2 would have meant
> too much work, because the scheme has inherent flaws. Any such flaw does
> fall on the developer multiple times, for implementation, for developing
> test cases for all the undefined corner cases, for a UI that explains
> what the software actually does.
>
> By contrast, updating to a single different set of tags for stop poles
> is not a substantial problem.
>
>> This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.
>>
>
> Since writing this plugin, the relation editor has superseded most of
> the way sorting features. Thus, it no longer makes sense to duplicate
> the sorting capabilities in a distinct plugin.
>
> I would nowadays add buttons to the relation editor rather than a
> separate relation editor.
>
> There is also an unfinished routing algorithm in the plugin. I never had
> found a reasonable UI to exhibit that to the end user.
>
> Best regards,
>
> Roland
>

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
In reply to this post by Dirk Stöcker

Thanks. I didn't find the source code for this plugin after searching for it online.

I don't think I have the programming expertise to actually contribute to this progeamming. The most I can do in Java is writing some programs that run in the console. 

That was why I was suggesting this to any devs who are interested, as "suggest stops" could really streamline the public transport process.--
 


13 Nov 2020, 21:00 by [hidden email]:

> On Fri, 13 Nov 2020, ipswichmapper--- wrote:
>
>> Can this addon be rewritten as an open-source addon that supports PTV2 and actually works?
>>
>
> Why should we rewrite it? It's already open source like most (all?) official plugins.
>
> https://josm.openstreetmap.de/browser/osm/applications/editors/josm/plugins/public_transport
>
> As for improvements, feel free to help yourself if you think a topic important enough. Patches are always welcome.
>
> Otherwise all JOSM contributors developing stuff in their free time and they naturally choose tasks which are important or interesting to themself.
>
> We're happy to help everybody who wants to help but does not yet have enough knowledge if the willigness to learn is visible.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
In reply to this post by JOSM Development mailing list
Sorry, I meant to say "what inherant flaws does PTV2 have".
--
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
 https://tutanota.com


13 Nov 2020, 21:04 by [hidden email]:

> Great! This should hopefully simplify the improvement of this addon.
>
> 1. What inherant flaws did the sudtem have?
> 2. How easy is it to determine if a way is "forward" or "backward" automatically?
>
> Also, it seems that the relation editor can sort ways, so a rewrite of this addon can remove this feature.
> --
>
>
>
> 13 Nov 2020, 20:53 by [hidden email]:
>
>> Hi all,
>>
>> thank you for the feedback.
>>
>>> Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".
>>>
>>
>> The plugin is open source, see
>> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
>>
>> The problem is that maintaining the plugin is a lot of work. I abandoned
>> the development long ago because public transport v2 would have meant
>> too much work, because the scheme has inherent flaws. Any such flaw does
>> fall on the developer multiple times, for implementation, for developing
>> test cases for all the undefined corner cases, for a UI that explains
>> what the software actually does.
>>
>> By contrast, updating to a single different set of tags for stop poles
>> is not a substantial problem.
>>
>>> This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.
>>>
>>
>> Since writing this plugin, the relation editor has superseded most of
>> the way sorting features. Thus, it no longer makes sense to duplicate
>> the sorting capabilities in a distinct plugin.
>>
>> I would nowadays add buttons to the relation editor rather than a
>> separate relation editor.
>>
>> There is also an unfinished routing algorithm in the plugin. I never had
>> found a reasonable UI to exhibit that to the end user.
>>
>> Best regards,
>>
>> Roland
>>
Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

Jo-2
Hi,

I'm not sure why you think PT_Assistant is simply a validator. It has many
features to help you create bus routes and recently I added some features
to help with conversion from PTv1 to PTv2. Those are not in the released
version yet though, because I'm also adding some other features
(experimental). For the past few years I mentored students to develop the
plugin. This meant it only got developed 3 months per year though. So
recently I started learning Java and  now I'm doing some development on it
myself. Something I wanted to figure out for a long time, is whether it
would make sense to have the itineraries as superroute relations that
contain route relations for the 'bundles'. Work in progress...

Would you have time for a Google Hangout this weekend? I would like to
demonstrate how converting route relations to PTv2 works.

Jo (Polyglot)



On Fri, Nov 13, 2020 at 10:10 PM ipswichmapper--- via josm-dev <
[hidden email]> wrote:

> Sorry, I meant to say "what inherant flaws does PTV2 have".
> --
>  Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
>  https://tutanota.com
>
>
> 13 Nov 2020, 21:04 by [hidden email]:
>
> > Great! This should hopefully simplify the improvement of this addon.
> >
> > 1. What inherant flaws did the sudtem have?
> > 2. How easy is it to determine if a way is "forward" or "backward"
> automatically?
> >
> > Also, it seems that the relation editor can sort ways, so a rewrite of
> this addon can remove this feature.
> > --
> >
> >
> >
> > 13 Nov 2020, 20:53 by [hidden email]:
> >
> >> Hi all,
> >>
> >> thank you for the feedback.
> >>
> >>> Furthermore, this plugin is closed-source (as far as I know), so it
> cannot be "fixed".
> >>>
> >>
> >> The plugin is open source, see
> >>
> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
> >>
> >> The problem is that maintaining the plugin is a lot of work. I abandoned
> >> the development long ago because public transport v2 would have meant
> >> too much work, because the scheme has inherent flaws. Any such flaw does
> >> fall on the developer multiple times, for implementation, for developing
> >> test cases for all the undefined corner cases, for a UI that explains
> >> what the software actually does.
> >>
> >> By contrast, updating to a single different set of tags for stop poles
> >> is not a substantial problem.
> >>
> >>> This would mean you could immediately add all the stops in the click
> of a button, and sort broken relations in a click of a button.
> >>>
> >>
> >> Since writing this plugin, the relation editor has superseded most of
> >> the way sorting features. Thus, it no longer makes sense to duplicate
> >> the sorting capabilities in a distinct plugin.
> >>
> >> I would nowadays add buttons to the relation editor rather than a
> >> separate relation editor.
> >>
> >> There is also an unfinished routing algorithm in the plugin. I never had
> >> found a reasonable UI to exhibit that to the end user.
> >>
> >> Best regards,
> >>
> >> Roland
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
Hi Jo,

I installed and played around with pt_assistant yesterday, and yes you are right it seems a lot more than just an validator. For example, if I reverse a relation it lets me find and replace the ways which are one way and in the wrong direction. However, I find the bright colours and paint styles a bit over the top - it makes it difficult to see which ways I have selected.

Considering this, is it possible to add the "suggest stops" feature to pt_assistant, (from the "public transport" plugin)? This would make it so that only this add-on is needed for public transport relations, you don't need the other addon.

> It has many features to help you create bus routes

I already know it can help modify errors in routes, but what does it do to specifically build a new route from scratch.

> recently I added some features to help with conversion from PTv1 to PTv2

What features? Before pt_assistant, to upgrade from PTv1 to PTv2, I would duplicate the PTv1 relation. Then I would select all the ways in the order the bus follows them and add those ways to the relation (and delete the old ones). I would then add stops by downloading the area around the stop and adding it (you can see stops on the carto map when downloading, or by looking at https://bustimes.org ). I would repeat this in full for the other direction.

Now, I have sped up the process a bit.

Firstly I download the PTv1 relation, and then select all the ways in the correct order, like before, and add them to the relation, removing the old one. Then, I add the stops manually, again.

However, now I have done one side, I duplicate this, and fix any segments that go over a oneway road in the wrong direction using pt_assistant's "route_helper".

 I then download the area surrounding the route by selecting it and "File--> Download along". Then, I select all the members of this new relation, select only stops from the members, and mark all the stops with the tag "test=test". I then use the "suggest stops" feature of the "public transport" plugin, but check "stops appear on both sides". This way stops on the left and right side of the road are added to the relation.

From here, I can select all the stops with "test=test" and remove them from the relation. Finally, I check this new relation against the https://bustimes.org version to check if it is correct.

What advantages would the "experimental pt_assistant features" that you are talking about bring?

> For the past few years I mentored students to develop the plugin. This meant it only got developed 3 months per year though.

What do you mean by this?

> whether it would make sense to have the itineraries as superroute relations that contain route relations for the 'bundles'.

What do you mean by this?

> Would you have time for a Google Hangout this weekend? I would like to demonstrate how converting route relations to PTv2 works.

Sorry, I don't even have a personal google account, let alone one for mapping purposes. I don't have a microphone either.

Regardless, I would prefer to stay anonymous.

>  I would like to demonstrate how converting route relations to PTv2 works.

Feel free to add any tricks I missed in my description of converting PTv1 to PTv2.

Thanks,

IpswichMapper
--

14 Nov 2020, 10:56 by [hidden email]:

> Hi,
>
> I'm not sure why you think PT_Assistant is simply a validator. It has many features to help you create bus routes and recently I added some features to help with conversion from PTv1 to PTv2. Those are not in the released version yet though, because I'm also adding some other features (experimental). For the past few years I mentored students to develop the plugin. This meant it only got developed 3 months per year though. So recently I started learning Java and  now I'm doing some development on it myself. Something I wanted to figure out for a long time, is whether it would make sense to have the itineraries as superroute relations that contain route relations for the 'bundles'. Work in progress...
>
> Would you have time for a Google Hangout this weekend? I would like to demonstrate how converting route relations to PTv2 works.
>
> Jo (Polyglot)
>
>  
>
> On Fri, Nov 13, 2020 at 10:10 PM ipswichmapper--- via josm-dev <> [hidden email]> > wrote:
>
>> Sorry, I meant to say "what inherant flaws does PTV2 have".
>> --
>>  Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
>>  >> https://tutanota.com
>>
>>
>> 13 Nov 2020, 21:04 by >> [hidden email]>> :
>>
>> > Great! This should hopefully simplify the improvement of this addon.
>> >
>> > 1. What inherant flaws did the sudtem have?
>> > 2. How easy is it to determine if a way is "forward" or "backward" automatically?
>> >
>> > Also, it seems that the relation editor can sort ways, so a rewrite of this addon can remove this feature.
>> > --
>> >
>> >
>> >
>> > 13 Nov 2020, 20:53 by >> [hidden email]>> :
>> >
>> >> Hi all,
>> >>
>> >> thank you for the feedback.
>> >>
>> >>> Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".
>> >>>
>> >>
>> >> The plugin is open source, see
>> >> >> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
>> >>
>> >> The problem is that maintaining the plugin is a lot of work. I abandoned
>> >> the development long ago because public transport v2 would have meant
>> >> too much work, because the scheme has inherent flaws. Any such flaw does
>> >> fall on the developer multiple times, for implementation, for developing
>> >> test cases for all the undefined corner cases, for a UI that explains
>> >> what the software actually does.
>> >>
>> >> By contrast, updating to a single different set of tags for stop poles
>> >> is not a substantial problem.
>> >>
>> >>> This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.
>> >>>
>> >>
>> >> Since writing this plugin, the relation editor has superseded most of
>> >> the way sorting features. Thus, it no longer makes sense to duplicate
>> >> the sorting capabilities in a distinct plugin.
>> >>
>> >> I would nowadays add buttons to the relation editor rather than a
>> >> separate relation editor.
>> >>
>> >> There is also an unfinished routing algorithm in the plugin. I never had
>> >> found a reasonable UI to exhibit that to the end user.
>> >>
>> >> Best regards,
>> >>
>> >> Roland
>> >>
>>

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

JOSM Development mailing list
> We are also working on a renderer that gives something like a metro map diagram

OMG yes. I was looking for something like this. Problem is what you showed doesn't show numbers nor overlay the routes over a roadmap, but it is good start. I wanted to create a map like this?

https://www.ipswichbuses.co.uk/wp-content/uploads/Ipswich_Buses_Network_Map_WEB.pdf

(Just search "Ipswich Buses Map" if this link stops working)

The problem with this map is that it only shows buses from the "Ipswich Buses" company, however there are multiple companies operating buses in Ipswich.

> With the latest version of the plugin it will ask you whether you want to remove oneway roads and split roundabout ways from the route relation. If there are forward_stop/ backward_stop or _platform in the route relation (as there were in Talinn where I was testing this) then it will also keep all the forward or all the backward versions in each variant and rename the roles.

Is this taking about the JAR file you sent me or the latest release?
> If you choose to sort the stops in the route relation on a route relation that doesn't have the public_transport:version = 2 tag, it will propose to duplicate the relation and create a route_master. Unfortunately with the released version, it causes an exception / error while trying to determine whether there is right or left hand traffic.

> You are right, we should add functionality to stop all the stops that are either on the left, or on the right where the itinerary passes. We're working on that too.

Personally, my suggestion is that you should focus on improving "adding stop" facilities. Ways can be added manually pretty quickly. For example, I added Bus 70 last week with the jar you sent me last week. The duplicate route thing doesn't work, I don't think. I'm pretty sure it just removed oneway ways? However, this isn't of much use because if the outbound route takes a different direction to the inbound route, then not all of the ways of this different direction is oneway. You then have to find and remove these remaining ways.

It is simply much, much quicker to just re-add all the ways in order manually. For example, for bus route 70 (a rural route), it took 5 minutes, even though this route is 35km long. Adding shorter urban routes should be even easier. Adding ways is really quick: if it were down to that, I could simply create both inbound and outbound relations in just 10 minutes. The advantage with PT assistant is that if I have created the outbound route (for example) I can fix the inbound route by finding places where it follows a oneway road in the opposite direction.

However, I don't think it can, or will be able to tell which ways are part of the outbound and which ways are part of the inbound route when the PTV1 route contains both inbound and outbound ways.

Also, PTV1 routes also are broken, so much so that the sort function fails to fix them. It is simply much quicker and easier to do them main

The real problem was stops. This took be 30+ minutes. Now it takes more than an hour to add routes in both directions (compared to 5-10 minutes when just adding ways).

A big portion of this time is aligning stops on the road, renaming stops, adding "local_ref" tags, (etc.) however some of this time could be slashed by adding a suggest stops feature. So, in my opinion, the focus should really be on that, not on trying to make adding ways faster.

I have created a github issue for this, and it seems like one of the devs self-assigned to solve this problem, which is great.

> That's the result for Ipswich. It chopped up all the route relations into subroute relations. I think it goes in the direction of what you were asking in the other thread.

???

What is the purpose of chopping these relations into smaller "subrelation"? A single relation is meant to represent a single route taken by a bus.

IpswichMapper

P.S. Your previous email doesn't show up on the mailing list archive. Is it because it contains images?
--


15 Nov 2020, 11:54 by [hidden email]:

> Hi,
>
> If you choose to sort the stops in the route relation on a route relation that doesn't have the public_transport:version = 2 tag, it will propose to duplicate the relation and create a route_master. Unfortunately with the released version, it causes an exception / error while trying to determine whether there is right or left hand traffic.
>
> I'll add a jar file with the latest version of the plugin. It's not ready for release yet, but you can test it, if you like.
>
> Gmail doesn't allow me to send it, so I renamed it. Remove the text in allcaps from the file name and copy it to your JOSM plugins folder.
>
> If you want to go back to the released version, simply delete the file and JOSM will download it again for you. JOSM might also ask you to update your plugins when it starts, if you want to use this version, you shouldn't do that for that session.
>
> With the latest version of the plugin it will ask you whether you want to remove oneway roads and split roundabout ways from the route relation. If there are forward_stop/ backward_stop or _platform in the route relation (as there were in Talinn where I was testing this) then it will also keep all the forward or all the backward versions in each variant and rename the roles.
>
> What it also does, is create a GPX layer with the shape of the original route relation. I found this helpful, because often after removing all the oneway ways, nothing much was left.
>
> Then I use the routing helper to fix the gaps for each direction of travel.
>
> We are working on improving the routing helper functionality, refactoring it, but it's difficult and takes quite a lot of time to get it right .
>
> You are right, we should add functionality to stop all the stops that are either on the left, or on the right where the itinerary passes. We're working on that too.
>
> If you want to see what I'm experimenting with. Select some route relations that are already converted to PTv2. And choose Split selected route relations into segments. Don't upload the result...
>
> After this select Public Transport/Enable/Disable coloured route segments diagram renderer.
>
>
> That's the result for Ipswich. It chopped up all the route relations into subroute relations. I think it goes in the direction of what you were asking in the other thread.
>
> It doesn't work exactly the way I want  it yet though and I still need to create a proposal for it. A proposal that stands very little chance of being accepted... Anyway, that's what I've been working on for the past month or 2, 3, after thinking about it for several years now. I'm mostly using it as a way to get used to programming in Java.
>
> We are also working on a renderer that gives something like a metro map diagram:
>
>
>
> I added some colour tags to your route_master and route relations. This renderer is in a different branch, so it's not included in the jar file I sent you.
>
> Let me know if you want that version as well. It's not ready for prime time yet though.
>
> Cheers,
>
> Jo
>
> On Sun, Nov 15, 2020 at 9:53 AM <> [hidden email]> > wrote:
>
>> Hi Jo,
>>
>> I installed and played around with pt_assistant yesterday, and yes you are right it seems a lot more than just an validator. For example, if I reverse a relation it lets me find and replace the ways which are one way and in the wrong direction. However, I find the bright colours and paint styles a bit over the top - it makes it difficult to see which ways I have selected.
>>
>> Considering this, is it possible to add the "suggest stops" feature to pt_assistant, (from the "public transport" plugin)? This would make it so that only this add-on is needed for public transport relations, you don't need the other addon.
>>
>> > It has many features to help you create bus routes
>>
>> I already know it can help modify errors in routes, but what does it do to >> specifically>>  build a new route from scratch.
>>
>> > recently I added some features to help with conversion from PTv1 to PTv2
>>
>> What features? Before pt_assistant, to upgrade from PTv1 to PTv2, I would duplicate the PTv1 relation. Then I would select all the ways in the order the bus follows them and add those ways to the relation (and delete the old ones). I would then add stops by downloading the area around the stop and adding it (you can see stops on the carto map when downloading, or by looking at >> https://bustimes.org>>  ). I would repeat this in full for the other direction.
>>
>> Now, I have sped up the process a bit.
>>
>> Firstly I download the PTv1 relation, and then select all the ways in the correct order, like before, and add them to the relation, removing the old one. Then, I add the stops manually, again.
>>
>> However, now I have done one side, I duplicate this, and fix any segments that go over a oneway road in the wrong direction using pt_assistant's "route_helper".
>>
>> I then download the area surrounding the route by selecting it and "File--> Download along". Then, I select all the members of this new relation, select only stops from the members, and mark all the stops with the tag "test=test". I then use the "suggest stops" feature of the "public transport" plugin, but check "stops appear on both sides". This way stops on the left and right side of the road are added to the relation.
>>
>> From here, I can select all the stops with "test=test" and remove them from the relation. Finally, I check this new relation against the >> https://bustimes.org>>  version to check if it is correct.
>>
>> What advantages would the "experimental pt_assistant features" that you are talking about bring?
>>
>> > For the past few years I mentored students to develop the plugin. This meant it only got developed 3 months per year though.
>>
>> What do you mean by this?
>>
>> > whether it would make sense to have the itineraries as superroute relations that contain route relations for the 'bundles'.
>>
>> What do you mean by this?
>>
>> > Would you have time for a Google Hangout this weekend? I would like to demonstrate how converting route relations to PTv2 works.
>>
>> Sorry, I don't even have a personal google account, let alone one for mapping purposes. I don't have a microphone either.
>>
>> Regardless, I would prefer to stay anonymous.
>>
>> >  I would like to demonstrate how converting route relations to PTv2 works.
>>
>> Feel free to add any tricks I missed in my description of converting PTv1 to PTv2.
>>
>> Thanks,
>>
>> IpswichMapper
>> --
>>
>> 14 Nov 2020, 10:56 by >> [hidden email]>> :
>>
>>> Hi,
>>>
>>> I'm not sure why you think PT_Assistant is simply a validator. It has many features to help you create bus routes and recently I added some features to help with conversion from PTv1 to PTv2. Those are not in the released version yet though, because I'm also adding some other features (experimental). For the past few years I mentored students to develop the plugin. This meant it only got developed 3 months per year though. So recently I started learning Java and  now I'm doing some development on it myself. Something I wanted to figure out for a long time, is whether it would make sense to have the itineraries as superroute relations that contain route relations for the 'bundles'. Work in progress...
>>>
>>> Would you have time for a Google Hangout this weekend? I would like to demonstrate how converting route relations to PTv2 works.
>>>
>>> Jo (Polyglot)
>>>
>>>  
>>>
>>> On Fri, Nov 13, 2020 at 10:10 PM ipswichmapper--- via josm-dev <>>> [hidden email]>>> > wrote:
>>>
>>>> Sorry, I meant to say "what inherant flaws does PTV2 have".
>>>> --
>>>>  Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
>>>>  >>>> https://tutanota.com
>>>>
>>>>
>>>> 13 Nov 2020, 21:04 by >>>> [hidden email]>>>> :
>>>>
>>>> > Great! This should hopefully simplify the improvement of this addon.
>>>> >
>>>> > 1. What inherant flaws did the sudtem have?
>>>> > 2. How easy is it to determine if a way is "forward" or "backward" automatically?
>>>> >
>>>> > Also, it seems that the relation editor can sort ways, so a rewrite of this addon can remove this feature.
>>>> > --
>>>> >
>>>> >
>>>> >
>>>> > 13 Nov 2020, 20:53 by >>>> [hidden email]>>>> :
>>>> >
>>>> >> Hi all,
>>>> >>
>>>> >> thank you for the feedback.
>>>> >>
>>>> >>> Furthermore, this plugin is closed-source (as far as I know), so it cannot be "fixed".
>>>> >>>
>>>> >>
>>>> >> The plugin is open source, see
>>>> >> >>>> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
>>>> >>
>>>> >> The problem is that maintaining the plugin is a lot of work. I abandoned
>>>> >> the development long ago because public transport v2 would have meant
>>>> >> too much work, because the scheme has inherent flaws. Any such flaw does
>>>> >> fall on the developer multiple times, for implementation, for developing
>>>> >> test cases for all the undefined corner cases, for a UI that explains
>>>> >> what the software actually does.
>>>> >>
>>>> >> By contrast, updating to a single different set of tags for stop poles
>>>> >> is not a substantial problem.
>>>> >>
>>>> >>> This would mean you could immediately add all the stops in the click of a button, and sort broken relations in a click of a button.
>>>> >>>
>>>> >>
>>>> >> Since writing this plugin, the relation editor has superseded most of
>>>> >> the way sorting features. Thus, it no longer makes sense to duplicate
>>>> >> the sorting capabilities in a distinct plugin.
>>>> >>
>>>> >> I would nowadays add buttons to the relation editor rather than a
>>>> >> separate relation editor.
>>>> >>
>>>> >> There is also an unfinished routing algorithm in the plugin. I never had
>>>> >> found a reasonable UI to exhibit that to the end user.
>>>> >>
>>>> >> Best regards,
>>>> >>
>>>> >> Roland
>>>> >>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: A functioning Public Transport plugin

Jo-2
If the PT_Assistant routing_helper has to help you 'reassemble' the ways on
a turn-by-turn basis, it is indeed relatively slow. If however there are
already other routes that contain the way you start from and the way after
the gap, then it will propose this whole sequence of ways that's present in
that other route relation and that makes it very fast for fixing route
relations.

I realise that the other thing I'm working on, the splitting in subroute
relations is rather revolutionary and atm it's experimental at best. I
thought you had mentioned something similar on another mailing list. Anyway
coding it is harder than I expected, but the real difficulty will be in
doing a proposal and getting it accepted by the community. It's definitely
not the way we map bus routes at present.

I do think  it would be an advantage to fix 1 subroute relation when it
breaks and have all the superroutes it's a member of being fixed at once,
but working with all those lego-blocks of sub route relations might prove
to be more complex. Anyway, it's a way for me to get into learning Java,
doing actual programming, and it's also something I have been thinking
about since I started mapping public transport in my own region.

The reason why adding stops along an itinerary wasn't a priority up till
now is that I have first added all the stops with their identifiers (over a
course of about 2, 3 years). After that I had access to data of the Belgian
operators and I could auto-generate route relations that contained the
stops in the correct order. So adding the ways was the more time consuming
part there (and adding the stops and moving them to their actual
locations). Also adding stops alongside the itineraries is the one thing
the old public transport plugin was useful for.

Now, the next thing I should do is create something that allows me to do
'integration' based on GTFS (or DB dumps), to see if all the lines are
still represented by route_master relations and all the itineraries are
still represented by route relations. (By comparing the stop sequences in
the operators' data and OSM). I'm doing that with Python and Pandas, but it
still needs more work.

Jo

On Sat, Nov 21, 2020 at 8:54 PM <[hidden email]> wrote:

> > We are also working on a renderer that gives something like a metro map
> diagram
>
> OMG yes. I was looking for something like this. Problem is what you showed
> doesn't show numbers nor overlay the routes over a roadmap, but it is good
> start. I wanted to create a map like this?
>
>
> https://www.ipswichbuses.co.uk/wp-content/uploads/Ipswich_Buses_Network_Map_WEB.pdf
>
> (Just search "Ipswich Buses Map" if this link stops working)
>
> The problem with this map is that it only shows buses from the "Ipswich
> Buses" company, however there are multiple companies operating buses in
> Ipswich.
>
> > With the latest version of the plugin it will ask you whether you want
> to remove oneway roads and split roundabout ways from the route relation.
> If there are forward_stop/ backward_stop or _platform in the route relation
> (as there were in Talinn where I was testing this) then it will also keep
> all the forward or all the backward versions in each variant and rename the
> roles.
>
> Is this taking about the JAR file you sent me or the latest release?
>
> > If you choose to sort the stops in the route relation on a route
> relation that doesn't have the public_transport:version = 2 tag, it will
> propose to duplicate the relation and create a route_master. Unfortunately
> with the released version, it causes an exception / error while trying to
> determine whether there is right or left hand traffic.
>
> > You are right, we should add functionality to stop all the stops that
> are either on the left, or on the right where the itinerary passes. We're
> working on that too.
>
> Personally, my suggestion is that you should focus on improving "adding
> stop" facilities. Ways can be added manually pretty quickly. For example, I
> added Bus 70 last week with the jar you sent me last week. The duplicate
> route thing doesn't work, I don't think. I'm pretty sure it just removed
> oneway ways? However, this isn't of much use because if the outbound route
> takes a different direction to the inbound route, then not all of the ways
> of this different direction is oneway. You then have to find and remove
> these remaining ways.
>
> It is simply much, much quicker to just re-add all the ways in order
> manually. For example, for bus route 70 (a rural route), it took 5 minutes,
> even though this route is 35km long. Adding shorter urban routes should be
> even easier. Adding ways is really quick: if it were down to that, I could
> simply create both inbound and outbound relations in just 10 minutes. The
> advantage with PT assistant is that if I have created the outbound route
> (for example) I can fix the inbound route by finding places where it
> follows a oneway road in the opposite direction.
>
> However, I don't think it can, or will be able to tell which ways are part
> of the outbound and which ways are part of the inbound route when the PTV1
> route contains both inbound and outbound ways.
>
> Also, PTV1 routes also are broken, so much so that the sort function fails
> to fix them. It is simply much quicker and easier to do them main
>
> The real problem was stops. This took be 30+ minutes. Now it takes more
> than an hour to add routes in both directions (compared to 5-10 minutes
> when just adding ways).
>
> A big portion of this time is aligning stops on the road, renaming stops,
> adding "local_ref" tags, (etc.) however some of this time could be slashed
> by adding a suggest stops feature. So, in my opinion, the focus should
> really be on that, not on trying to make adding ways faster.
>
> I have created a github issue for this, and it seems like one of the devs
> self-assigned to solve this problem, which is great.
>
> > That's the result for Ipswich. It chopped up all the route relations
> into subroute relations. I think it goes in the direction of what you were
> asking in the other thread.
>
> ???
>
> What is the purpose of chopping these relations into smaller
> "subrelation"? A single relation is meant to represent a single route taken
> by a bus.
>
> IpswichMapper
>
> P.S. Your previous email doesn't show up on the mailing list archive. Is
> it because it contains images?
> --
>
>
> 15 Nov 2020, 11:54 by [hidden email]:
>
> Hi,
>
> If you choose to sort the stops in the route relation on a route relation
> that doesn't have the public_transport:version = 2 tag, it will propose to
> duplicate the relation and create a route_master. Unfortunately with the
> released version, it causes an exception / error while trying to determine
> whether there is right or left hand traffic.
>
> I'll add a jar file with the latest version of the plugin. It's not ready
> for release yet, but you can test it, if you like.
>
> Gmail doesn't allow me to send it, so I renamed it. Remove the text in
> allcaps from the file name and copy it to your JOSM plugins folder.
>
> If you want to go back to the released version, simply delete the file and
> JOSM will download it again for you. JOSM might also ask you to update your
> plugins when it starts, if you want to use this version, you shouldn't do
> that for that session.
>
> With the latest version of the plugin it will ask you whether you want to
> remove oneway roads and split roundabout ways from the route relation. If
> there are forward_stop/ backward_stop or _platform in the route relation
> (as there were in Talinn where I was testing this) then it will also keep
> all the forward or all the backward versions in each variant and rename the
> roles.
>
> What it also does, is create a GPX layer with the shape of the original
> route relation. I found this helpful, because often after removing all the
> oneway ways, nothing much was left.
>
> Then I use the routing helper to fix the gaps for each direction of travel.
>
> We are working on improving the routing helper functionality, refactoring
> it, but it's difficult and takes quite a lot of time to get it right .
>
> You are right, we should add functionality to stop all the stops that are
> either on the left, or on the right where the itinerary passes. We're
> working on that too.
>
> If you want to see what I'm experimenting with. Select some route
> relations that are already converted to PTv2. And choose Split selected
> route relations into segments. Don't upload the result...
>
> After this select Public Transport/Enable/Disable coloured route segments
> diagram renderer.
>
> [image: image.png]
> That's the result for Ipswich. It chopped up all the route relations into
> subroute relations. I think it goes in the direction of what you were
> asking in the other thread.
>
> It doesn't work exactly the way I want  it yet though and I still need to
> create a proposal for it. A proposal that stands very little chance of
> being accepted... Anyway, that's what I've been working on for the past
> month or 2, 3, after thinking about it for several years now. I'm mostly
> using it as a way to get used to programming in Java.
>
> We are also working on a renderer that gives something like a metro map
> diagram:
>
> [image: image.png]
> [image: image.png]
> I added some colour tags to your route_master and route relations. This
> renderer is in a different branch, so it's not included in the jar file I
> sent you.
>
> Let me know if you want that version as well. It's not ready for prime
> time yet though.
>
> Cheers,
>
> Jo
>
> On Sun, Nov 15, 2020 at 9:53 AM <[hidden email]> wrote:
>
> Hi Jo,
>
> I installed and played around with pt_assistant yesterday, and yes you are
> right it seems a lot more than just an validator. For example, if I reverse
> a relation it lets me find and replace the ways which are one way and in
> the wrong direction. However, I find the bright colours and paint styles a
> bit over the top - it makes it difficult to see which ways I have selected.
>
> Considering this, is it possible to add the "suggest stops" feature to
> pt_assistant, (from the "public transport" plugin)? This would make it so
> that only this add-on is needed for public transport relations, you don't
> need the other addon.
>
> > It has many features to help you create bus routes
>
> I already know it can help modify errors in routes, but what does it do to
> *specifically* build a new route from scratch.
>
> > recently I added some features to help with conversion from PTv1 to PTv2
>
> What features? Before pt_assistant, to upgrade from PTv1 to PTv2, I would
> duplicate the PTv1 relation. Then I would select all the ways in the order
> the bus follows them and add those ways to the relation (and delete the old
> ones). I would then add stops by downloading the area around the stop and
> adding it (you can see stops on the carto map when downloading, or by
> looking at https://bustimes.org ). I would repeat this in full for the
> other direction.
>
> Now, I have sped up the process a bit.
>
> Firstly I download the PTv1 relation, and then select all the ways in the
> correct order, like before, and add them to the relation, removing the old
> one. Then, I add the stops manually, again.
>
> However, now I have done one side, I duplicate this, and fix any segments
> that go over a oneway road in the wrong direction using pt_assistant's
> "route_helper".
>
> I then download the area surrounding the route by selecting it and
> "File--> Download along". Then, I select all the members of this new
> relation, select only stops from the members, and mark all the stops with
> the tag "test=test". I then use the "suggest stops" feature of the "public
> transport" plugin, but check "stops appear on both sides". This way stops
> on the left and right side of the road are added to the relation.
>
> From here, I can select all the stops with "test=test" and remove them
> from the relation. Finally, I check this new relation against the
> https://bustimes.org version to check if it is correct.
>
> What advantages would the "experimental pt_assistant features" that you
> are talking about bring?
>
> > For the past few years I mentored students to develop the plugin. This
> meant it only got developed 3 months per year though.
>
> What do you mean by this?
>
> > whether it would make sense to have the itineraries as superroute
> relations that contain route relations for the 'bundles'.
>
> What do you mean by this?
>
> > Would you have time for a Google Hangout this weekend? I would like to
> demonstrate how converting route relations to PTv2 works.
>
> Sorry, I don't even have a personal google account, let alone one for
> mapping purposes. I don't have a microphone either.
>
> Regardless, I would prefer to stay anonymous.
>
> > I would like to demonstrate how converting route relations to PTv2 works.
>
> Feel free to add any tricks I missed in my description of converting PTv1
> to PTv2.
>
> Thanks,
>
> IpswichMapper
> --
>
> 14 Nov 2020, 10:56 by [hidden email]:
>
> Hi,
>
> I'm not sure why you think PT_Assistant is simply a validator. It has many
> features to help you create bus routes and recently I added some features
> to help with conversion from PTv1 to PTv2. Those are not in the released
> version yet though, because I'm also adding some other features
> (experimental). For the past few years I mentored students to develop the
> plugin. This meant it only got developed 3 months per year though. So
> recently I started learning Java and  now I'm doing some development on it
> myself. Something I wanted to figure out for a long time, is whether it
> would make sense to have the itineraries as superroute relations that
> contain route relations for the 'bundles'. Work in progress...
>
> Would you have time for a Google Hangout this weekend? I would like to
> demonstrate how converting route relations to PTv2 works.
>
> Jo (Polyglot)
>
>
>
> On Fri, Nov 13, 2020 at 10:10 PM ipswichmapper--- via josm-dev <
> [hidden email]> wrote:
>
> Sorry, I meant to say "what inherant flaws does PTV2 have".
> --
>  Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
>  https://tutanota.com
>
>
> 13 Nov 2020, 21:04 by [hidden email]:
>
> > Great! This should hopefully simplify the improvement of this addon.
> >
> > 1. What inherant flaws did the sudtem have?
> > 2. How easy is it to determine if a way is "forward" or "backward"
> automatically?
> >
> > Also, it seems that the relation editor can sort ways, so a rewrite of
> this addon can remove this feature.
> > --
> >
> >
> >
> > 13 Nov 2020, 20:53 by [hidden email]:
> >
> >> Hi all,
> >>
> >> thank you for the feedback.
> >>
> >>> Furthermore, this plugin is closed-source (as far as I know), so it
> cannot be "fixed".
> >>>
> >>
> >> The plugin is open source, see
> >>
> https://github.com/openstreetmap/josm-plugins/tree/master/public_transport
> >>
> >> The problem is that maintaining the plugin is a lot of work. I abandoned
> >> the development long ago because public transport v2 would have meant
> >> too much work, because the scheme has inherent flaws. Any such flaw does
> >> fall on the developer multiple times, for implementation, for developing
> >> test cases for all the undefined corner cases, for a UI that explains
> >> what the software actually does.
> >>
> >> By contrast, updating to a single different set of tags for stop poles
> >> is not a substantial problem.
> >>
> >>> This would mean you could immediately add all the stops in the click
> of a button, and sort broken relations in a click of a button.
> >>>
> >>
> >> Since writing this plugin, the relation editor has superseded most of
> >> the way sorting features. Thus, it no longer makes sense to duplicate
> >> the sorting capabilities in a distinct plugin.
> >>
> >> I would nowadays add buttons to the relation editor rather than a
> >> separate relation editor.
> >>
> >> There is also an unfinished routing algorithm in the plugin. I never had
> >> found a reasonable UI to exhibit that to the end user.
> >>
> >> Best regards,
> >>
> >> Roland
> >>
>
>
>
>