Re: A functioning Public Transport plugin

2020-11-21 Thread Jo
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  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 

Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread andrzej zaborowski
Hi,

On Sat, 21 Nov 2020 at 15:24, Mateusz Konieczny via dev
 wrote:
> Is there some existing code/library/tool for generating obvious
> short_name / alt_name from other tagged data?

https://github.com/balrog-kun/shrtnms is a very basic version I've
been using at the osm2pgsql stage to add short names when not in the
data.  The renderer prefers name over short_name over shortest_name
(West Fulton Street -> W Fulton St -> Fulton)

Best regards

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: A functioning Public Transport plugin

2020-11-21 Thread ipswichmapper--- via josm-dev
> 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 winfi...@gmail.com:

> 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 

Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Mateusz Konieczny via dev
It is not a proposal for an automatic edit, it is intended as an opposite -
so I will be able to generate names locally and will have no need to add them 
to OSM database.


I am aware of 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
and anyway that this thread would not be sufficient to cover this requirements


Nov 21, 2020, 17:02 by si...@poole.ch:

>
> By definition if you can generate it mechanically, you shouldn't  be 
> adding it to OSM.
>
> Am 21.11.2020 um 15:20 schrieb Mateusz  Konieczny via dev:
>
>> Is there some existing code/library/tool for generatingobvious 
>> short_name / alt_name from other tagged data?
>>
>>
>> I am implementing it right now for one of my programs  
>> and I would prefer help in existing project rather thanimplement yet 
>> another
>> version of the same.
>>
>> ___dev mailing list>> 
>> dev@openstreetmap.org>> https://lists.openstreetmap.org/listinfo/dev
>>

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Roland Olbricht via dev

Is there some existing code/library/tool for generating obvious
short_name / alt_name from other tagged data?


Specifically for shortened names, this list of common abbreviations
could help: https://wiki.osm.org/Name_finder:Abbreviations


Thank you for the pointer. At least for German (and for French as far as
I can judge) please take it with a grain of salt:
- The by far fast common practices to shorten names are to resort to
KFZ-Kennzeichen (district codes), i.e. "K-Süd" is the short_name for
"Köln-Süd"
- In 95% of Germany (everywhere except Berlin), the abbreviaton of
"Bahnhof" is "Bf"
- the suffix "straße" resp. "Straße" is shortened to "str." resp.
"Str.", everything else is uncommon
- French street names are shortened by entirely removing the generic
parts, i.e. "Place Victor Hugo" has short_name "Victor Hugo"

I would not be surprised if the other languages have regional or
personal biases, too.

Cheers,
Roland

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Tobias Knerr
On 21.11.20 15:20, Mateusz Konieczny via dev wrote:
> Is there some existing code/library/tool for generating obvious
> short_name / alt_name from other tagged data?

Specifically for shortened names, this list of common abbreviations
could help: https://wiki.osm.org/Name_finder:Abbreviations

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Simon Poole
By definition if you can generate it mechanically, you shouldn't be 
adding it to OSM.


Am 21.11.2020 um 15:20 schrieb Mateusz Konieczny via dev:

Is there some existing code/library/tool for generating obvious
short_name / alt_name from other tagged data?


I am implementing it right now for one of my programs
and I would prefer help in existing project rather than implement yet 
another

version of the same.

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Komяpa
Hello,
For Russian, English, Ukraininan there is
https://github.com/AMDmi3/streetmangler

On Sat, Nov 21, 2020 at 5:23 PM Mateusz Konieczny via dev <
dev@openstreetmap.org> wrote:

> Is there some existing code/library/tool for generating obvious
> short_name / alt_name from other tagged data?
>
>
> I am implementing it right now for one of my programs
> and I would prefer help in existing project rather than implement yet
> another
> version of the same.
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>


-- 
Darafei "Komяpa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


[OSM-dev] Automatic generation of short_name / alt_name where missing and obvious

2020-11-21 Thread Mateusz Konieczny via dev
Is there some existing code/library/tool for generating obvious 
short_name / alt_name from other tagged data?


I am implementing it right now for one of my programs  
and I would prefer help in existing project rather than implement yet another
version of the same.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev