Re: [Talk-transit] Several stations in a stop_area

[Paul Johnson]

On Sat, Jan 22, 2022 at 6:38 AM Alexey Z via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
> Hello.
>
> Let me raise a question/appeal about stop_area relation. PTv2 is very
> disputable and imperfect, so I tried to touch a narrow and practical aspect
> to solve a specific problem. I really hope for your help to make the OSM PT
> data truly useful for data consumers.
>
> This is the description of the problem with pictures:
>
> https://wiki.openstreetmap.org/wiki/Talk:Tag:public_transport%3Dstop_area#Several_stations_in_a_stop_area
>
> This is the problematic stop_area:
> https://www.openstreetmap.org/relation/7672142
>

I'm generally inclined to believe Trimet (who had been developing transit
data feeds for at least a decade before their data format became the GTFS
standard) more or less knows what they're doing with a resource they
created, and PT2 is largely based on that.  Within that context, can you
give the cliff notes on what your proposal is that is substantively
different?
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Multiple ref=* on route=train

[Paul Johnson]

On Wed, Nov 20, 2019 at 5:27 PM Michael Reichert 
wrote:

> Hi Tijmen,
>
> Am 20.11.19 um 23:08 schrieb Tijmen Stam:
> > In the Netherlands, there are no train route numbers like this.
> > Internally (and among hobbyists) we speak of a "series 2900" train which
> > goes from Enkhuizen to Maastricht, but those train numbers are somewhat
> > hidden to the public - they aren't on the timetable boards or digital
> > board, available only on a mouseover in the train planner.
>
> These numbers refer to the type of vehicle (not service) what is called
> "class " in Great Britain, isn't it?
>

I believe so, kind of similar to how Portlanders refer to "Type I, II, III,
IV and V" series MAX cars, or New Yorkers refer to various "R"-series
subway cars.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] USA

[Paul Johnson]

On Wed, Sep 25, 2019 at 8:32 PM 80hnhtv4agou--- via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> that OSM,
>
> is a product of the united kingdom,
>
> are there any united states bus editors out there ?
>

I'm here working on Tulsa Transit.  I'd actually be surprised if there
weren't at least one or two people from Trimet in Portland lurking.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Paul Johnson]

If any.  Seems there's so many unanswered questions about mapping transit
in OSM that nothing solidly uses it yet.

On Fri, Aug 17, 2018 at 2:44 PM, Kevin Dalley  wrote:

> And then we need to look at all of the mapping programs, which need to
> interpret the new info.
>
> I'll do ref for now. It's fairly common in the AC Transit space.
>
> And most stops are single agency, with other agencies stopping nearby.
>
> On 08/17/2018 11:52 AM, Stephen Sprunk wrote:
> > ref:NS, where NS is some sort of namespace code, seems like the right
> > solution.  I see two problems:
> >
> > 1. Consumers only looking at ref will see nothing.  Perhaps it should
> > contain a semicolon-list of all the values in the suffixed tags?  Now
> > we're duplicating data, which introduces the risk of the tags getting
> > out of sync, but that's easy to automate.
> >
> > 2. It creates a new meta-namespace for namespace codes, which could have
> > its own collisions.  This is probably only a problem in practice if
> > collisions are nearby, though, so it may not be worth worrying about.
> >
> > S
> >
> >
> > On 2018-08-17 07:18, Wiklund Johan wrote:
> >
> >> It doesnt really matter if the country is organized if a bus comes
> >> from abroad and uses the stop (such as FlixBus). Organized world would
> >> fix it.
> >>
> >>
> >>
> >> *From:*Jo [mailto:winfi...@gmail.com]
> >> *Sent:* fredag 17. august 2018 10.05
> >> *To:* Public transport/transit/shared taxi related topics
> >> 
> >> *Subject:* Re: [Talk-transit] Revisiting the use of ref in bus stops
> >>
> >>
> >>
> >> We have 3 operators here in Belgium. I started by adding stops for 1
> >> first, so I used ref.
> >>
> >>
> >>
> >> Then I started working on the other operator and some stops are indeed
> >> shared. The other operator has 5 subdivisions and annoyingly they all
> >> assign their own identifiers, those stops also overlap.
> >>
> >>
> >>
> >> For a while I added 2 nodes, sometimes 3, but that really doesn't work
> >> well.
> >>
> >>
> >>
> >> So I merged them and now it's like this:
> >>
> >>
> >>
> >> ref:De_Lijn for stops of De Lijn
> >>
> >> ref:TECB for stops of TEC Brabant-Wallon
> >>
> >> ref:TECC for stops of TEC Charleroi
> >>
> >> ref:TECH for stops of TEC Hainaut
> >>
> >> ref:TECN for stops of TEC Namur
> >>
> >> ref:TECL for stops of TEC Liège
> >>
> >> reft:TECX for stops of TEC Luxembourg
> >>
> >>
> >>
> >> It's a bit messy, so I hope they'll change that at some point in the
> >> future.
> >>
> >>
> >>
> >> and the stops in Brussels could simply use ref, but I don't think we
> >> know their identifiers.
> >>
> >>
> >>
> >> In The Netherlands they are now using
> >>
> >>
> >>
> >> ref:IFOPT=NL:Q:78400680
> >>
> >>
> >>
> >> That would be better, but you need an organised country like The
> >> Netherlands to assign them.
> >>
> >>
> >>
> >> So, I'd say yes use ref:OPRTR, but not OPRTR:ref. You want them to
> >> sort together in the list of tags.
> >>
> >>
> >>
> >> I also use route_ref:OPRTR
> >>
> >>
> >>
> >> Polyglot
> >>
> >>
> >>
> >> Op vr 17 aug. 2018 om 05:33 schreef Paul Johnson  >> <mailto:ba...@ursamundi.org>>:
> >>
> >> On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  >> <mailto:ke...@kelphead.org>> wrote:
> >>
> >> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC
> >> Transit.
> >>
> >> For AC Transit, the gtfs_id, or stop_code, can be used to
> >> identify the
> >> stop. That's the number on the sign, and can be as a phone code.
> >>
> >> For example,
> >>
> >> stop code is 56669
> >>
> >> stop_name is: "MacArthur Blvd:Randolph Av"
> >>
> >> stop name does not appear on the sign, though variations of
> >> this name
> >> appear on the schedule, usually with a "&" rather than ":".
> >>
> &

Re: [Talk-transit] Revisiting the use of ref in bus stops

[Paul Johnson]

On Thu, Aug 16, 2018 at 5:55 PM, Kevin Dalley  wrote:

> I am using GO-Sync, gtfs-osm-sync, to synchronize data for AC  Transit.
>
> For AC Transit, the gtfs_id, or stop_code, can be used to identify the
> stop. That's the number on the sign, and can be as a phone code.
>
> For example,
>
> stop code is 56669
>
> stop_name is: "MacArthur Blvd:Randolph Av"
>
> stop name does not appear on the sign, though variations of this name
> appear on the schedule, usually with a "&" rather than ":".
>
> stop_code does appear on sign.
>
> I agree with previous users that, at least for AC Transit, stop_code
> should translated to "ref", which a defined meaning for bus_stop.
> GO-Sync does not do this, though it would be easy to patch my version,
> at least for AC Transit.
>
> and use stop_name as name, which is what GO-Sync does.
>
> Are there recent thoughts on this issue?


 I'm thinking ref on the stop needs to be entirely revisited, given stops
may be used by more than one network and therefore have more than one ref.

Maybe something like, say, trimet:ref=* for TriMet's stops, and
tillamook-wave:ref=* for Tillamook County's The Wave, which share the same
stop bays at Sunset Transit Center and several locations in downtown
Portland, for example.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Imports] National Transit Map (US)

[Paul Johnson]

Spot check against Tulsa Transit seems to suggest that this is matching a
dump of the GTFS stops.  Use caution with this data if you're going to try
to map from this, as the official GTFS is known to be wrong in Tulsa.

On Wed, Sep 7, 2016 at 4:51 AM, Andrew Guertin 
wrote:

> The (US) Department of Transportation recently[1] released the National
> Transit Map (http://www.rita.dot.gov/bts/ntm), a compilation of transit
> information from a wide list of regional transit providers. I'm not
> proposing an import myself, but I want to make sure it's widely known and I
> wonder if anyone is looking into an import of it.
>
> It appears the data collected (or at least presented on the online map) is
> transit stops only, with no route information.
>
> Not all transit providers are represented, though the press release says
> "74 percent of the top 50 agencies, and approximately one-third of all
> urban transit agencies with fixed route service".
>
> This seems like a valuable data set if we can use it.
>
> [1] http://www.rita.dot.gov/bts/press_releases/bts045_16
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Bus routes forward/backward

[Paul Johnson]

On Mon, Jul 11, 2016 at 1:08 AM, Hans De Kryger 
wrote:

> If i remove the forward/backward tag on a section of a way (part of the
> bus route) does that signify the bus goes both ways?
>

I would advise against this; and instead use a separate relation for each
direction of a route as it greatly simplifies maintenance of the route.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] GTFS, tools and pt tags generally

[Paul Johnson]

On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk <step...@sprunk.org> wrote:

> On 2016-06-21 00:27, Paul Johnson wrote:
>
>> On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <step...@sprunk.org>
>> wrote:
>>
>>> On 2016-06-20 16:18, Paul Johnson wrote:
>>> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk
>>> <step...@sprunk.org>
>>> wrote:
>>>
>>>> The situation with GTFS data itself is so bad that Google stopped
>>>> offering Navigation for the transit mode in it's own Maps service.
>>>>
>>>
>>> It's still available where I live and several other major cities I
>>> checked, so perhaps they just disabled it in your area because they
>>> recognized the GTFS data there was so bad?
>>>
>>
>> I mean the realtime, stop-by-stop navigation that was formerly
>> offered.  Even in areas with really good GTFS feeds, this
>> functionality is Just Gone.  ... it doesn't follow you in realtime
>> or take into account when your trip's fallen off schedule and won't
>> make a transfer now.  Nor will it warn you your stop is coming up.
>>
>
> Ah, I never thought to try that since transit here is reliable enough to
> set your watch by, so a static schedule is all I've ever needed.
>
> I found a couple transit-specific apps, but they refuse to work until I'm
> within some minimum distance of a stop.  In particular, they won't tell me
> when I need to be _at_ the nearest P station until after I'm _already
> there_, and with off-peak headways of up to an hour, I don't want to arrive
> too early.  Google Maps will tell me when the next few trains are leaving
> (and how long it'll take to drive there in current traffic) so I know
> _when_ to leave home.


RideSystems (and yes, I'm calling them out on this, since I reported the
problem a year ago via Google Play) won't even get past the "select your
transit system" thing.  Plus it's basically one of those lame "browser in
an app" deals, and it *still* doesn't work all that great in Chrome.
Especially versus holding the paper timetable in hand...seriously MTTA only
charges 25¢ for the quarterly timetable, but they could probably charge $25
and they'd still sell just as fast simply because their online route
planner and the RideSystems app is so horrible.

Though having the timetable and being able to text a stop-ID to a shortcode
and wait a few seconds for which bus will show up first at the stop you
already know is convenient is better than their old trip planner by a lot:
 Tear out page 4 of the timetable, fill out the form printed on it, *then
mail it to the transit system's office and wait for them to mail you the
answer*.  No joke.  Also, that option's still available as of the Winter
2016 timetable I have in my glovebox, for situations where my friends miss
their bus and call me up so I can basically track down their route looking
for them if they're not sure where they are.

I'm not sure what the solution is, though, so I've been putting the
>>> stop positions at the center of the platform until someone tells me
>>> better.  FWIW, that seems to be what folks in other cities have
>>> done--if they mapped any stop positions at all.
>>>
>>
>> Portland tends to put the stop position where the lead cab of the lead
>> car will line up.  However, Portland hits me as a little odd (in terms
>> of west coast light rail systems) in that there
>>
>
> Here, at stations where passengers either enter the platform from both
> ends or from the middle, trains stop so the center of the train is in the
> center of the platform, which means the cab's position varies with the
> train's length.  At stations where passengers enter the platform only from
> one end, trains stop so the front or rear (depending on direction) of the
> train is at that end of the platform.
>
> For the former, it makes sense to put the stop_position in the middle.
> For the latter, perhaps I should put it at/near the relevant end instead?
> If it matters at all.
>

I think Portland did this because everyone's device will pass through that
point if they're remaining on the train, since regardless of whether it's a
1 car or 2 car MAX train, or a vintage streetcar (back when the Historical
Society still had timetable slots), you'd touch that point on departure
regardless.  I can't test this hypothesis since I'm not aware of any app
that'll provide realtime navigation on that system anymore, and I'm like,
2000km away now.


> It's always baffled me that so many agencies are willing to give the
>>> same designation to different routes just because they share several
>>> stops.  ...
>>> Part of the reason we _need_ transit navigation apps

Re: [Talk-transit] GTFS, tools and pt tags generally

[Paul Johnson]

On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk <step...@sprunk.org> wrote:

> On 2016-06-20 16:18, Paul Johnson wrote:
>
>> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <step...@sprunk.org>
>> wrote:
>>
>>>
>>> The situation with GTFS data itself is so bad that Google stopped
>> offering Navigation for the transit mode in it's own Maps service.
>>
>
> It's still available where I live and several other major cities I
> checked, so perhaps they just disabled it in your area because they
> recognized the GTFS data there was so bad?
>

I mean the realtime, stop-by-stop navigation that was formerly offered.
Even in areas with really good GTFS feeds, this functionality is Just
Gone.  Closest you can get now amounts to basically a static listout of
your trip similar to the paddle used by transit drivers in to familiarize
themselves with the route and schedule; it doesn't follow you in realtime
or take into account when your trip's fallen off schedule and won't make a
transfer now.  Nor will it warn you your stop is coming up.  I remember
this abruptly going away with the last version that had it was Google
Navigation 6.9...


> One example is the dissent on whether the bus stop should be a
>>>> node on the vehicle's way or a node where the passengers wait. You
>>>> will find all solutions implemented, because each local community
>>>> decided different. The "approved scheme" will allow any variant.
>>>>
>>>
>>> ...
>>>
>>
>> I'm a proponent of it being the location where passengers wait for bus
>> service, and the center of the position the train stops for rail
>> halts, for what it's worth.
>>
>
> Unfortunately, that could create problems if navigation tools think that a
> person has to walk to the center of the platform to actually board the
> train, whereas trains often run the full length of the platform but are
> often shorter (or even longer!) than the platform.
>
> Worse, some trains only allow boarding for mobility impaired persons at
> certain points along the platform, and they may not be able to make it from
> the center to that location within the dwell time.
>
> Worse still, a short train may not even be _present_ at the center of the
> platform if it's short and stops at one end or the other.  While
> improbable, in theory that could lead a vision-impaired person to walk off
> the platform and fall onto the tracks.
>

Most stations I've seen have a canonical tactile map and seeing impaired
users are not putting total faith in either the official tactile map nor
any electronic aid they're using.  Mostly because people and furniture
move, maintenance closes areas, pavement buckles, etc.


> I'm not sure what the solution is, though, so I've been putting the stop
> positions at the center of the platform until someone tells me better.
> FWIW, that seems to be what folks in other cities have done--if they mapped
> any stop positions at all.
>

Portland tends to put the stop position where the lead cab of the lead car
will line up.  However, Portland hits me as a little odd (in terms of west
coast light rail systems) in that there


> Another example are route relations. While there are wild
>>>> constructions called route_master and network which are basically
>>>> collection relations, the problem that bothers most people in
>>>> practice has never been tackled: We would like to see per way segment
>>>> only one or very few relations and need a construction to assemble
>>>> itineraries from that. That would greatly reduce maintenance.
>>>>
>>>
>>> I'll admit I was a bit annoyed at having to duplicate way data for
>>> several routes where some trips run A-B-C-D, some A-B-C and some
>>> B-C-D; it would have been handy to create segments A-B, B-C and C-D,
>>> and then just include the right ones in each route.  But then I
>>> realized my real complaint was that I had to do this _at all_ when
>>> there's a GTFS feed that has _all_ of that information and could
>>> easily be used to create/update all the relations.  If it's
>>> automated, only developers should have to care how complicated or
>>> repetitive it is; the important thing is that individual mappers
>>> don't, at least in the general case.
>>>
>>
>> Hadn't learned of Route Master before, but this frustration with some
>> routes not going full length or having optional loops or changed route
>> based on time of day or whether or not it's snowing without changing
>> the route name or number actually hit me as one of those, "are you
>> actually kidding me?" kind

Re: [Talk-transit] GTFS, tools and pt tags generally

[Paul Johnson]

On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk  wrote:

> On 2016-06-20 02:07, Roland Olbricht wrote:
>
>> There had been a group that was very vocal for making a textbook
>> example of design by committee, and the result is now known as
>> "approved public transport scheme". They did not ask for input from
>> experienced mappers or developers. I decided to consider it a waste of
>> time and stopped developing.
>>
>
> I wasn't around at the time, so I can't speak to how it happened, but the
> result seems to be a partial implementation of Transmodel, which
> distinguishes a _lot_ of different things (and the complex relationships
> between them) in excruciating detail because the real world is, in fact,
> that complicated.
>
> If one is putting data in by hand, it certainly seems unwieldy.  It took
> me over a week to do just a few rail routes in my area, and I'm still not
> completely sure I got them right.  I can't imagine trying to do the
> hundreds of bus routes too.
>

I really wonder how TriMet ultimately accomplished this, since that would
seem like a decent-ish starting point since that system is in charge of a
fairly multimodal system with above and below ground stations, split-level
stations, and transit centers of almost every description.

One thing that breaks things badly for me in the Tulsa area is the vast
overwhelming majority of stops in the Tulsa Transit (and presumably other
transit systems in the region) GTFS have...literally zero indication on the
ground, there's no way to tell if there is an actual bus stop (which is
typically just a signpost with a bus stop sign on it), and if it is,
whether or not that's verifiable because the sign's gone missing.  Or the
more likely case with mass transit in the southern midwest, no amenities
whatsoever are provided, you just need to know the bus runs on that street
and stand about a bus length after the downstream side of an intersection
that doesn't have a signposted stop and flag down the driver to catch the
bus (likewise, you have to be unusually precise at pulling the stop cord as
the driver will automatically assume immediately after the next
intersection, regardless of how minor).  Worse, there's a large number of
duplicates with more than one stopID for the same stop position (this is a
GTFS data issue, Tulsa Transit's feed is a hot mess to start with), and
there's a significant portion (perhaps to the point of "almost all") major
transfer points that fall into the category of totally unsigned stops, and
another rash of locations that have no GTFS entry but are considered to be
valid, totally unposted bus stops.

My completely shitty answer to this problem right now is to map only
signposted stops I've verified.  I have no idea how many there actually
are, nor do I have any reason to believe that Tulsa Transit has any clue
how many there are in actuality either.  I'm also a big fan of the V1
tagging scheme as it's substantially easier to deal with.

On the ground mapping should become easier with time as Tulsa Transit's
starting to get more funding (Finally!), though focus right now is on
getting more safe vehicles on the road more frequently, longer hours and to
more places (currently any trip requiring more than one transfer, or even a
particularly long trip involving no transfers and only one possible route,
is a major test of patience, as it's annoyingly common for a scheduled bus
to be cancelled completely without warning due to lack of usable equipment
that has things like an intact floor that hasn't rusted out to the street
below).  I would hope that the GTFS feed improves as ridership increases
and stops get signposted, but I'm really not counting on the GTFS improving
or bus stops to get maintained, much less posted more formally than someone
scratching something like MTTA 3421 on a handy streetlamp or telephone pole
at unposted stops frequented by people who figured out the stop ID for that
location independently to look up when the next bus arrives via text
message...


> Also, like it or not, Google Maps (and hence GTFS) has set a bar for what
> users expect from online maps.  I'd certainly like OSM to be better, of
> course, but the current situation is that OSM is generally far, far worse.


It doesn't help that the only implementations of GTFS that actually are
anywhere near complete are basically the reference implementations Google
did in cooperation with TriMet and Tillamook County Transit, and adjacent
systems that asked TriMet how they did that (like Clark County Transit, aka
C-Tran).  The situation with GTFS data itself is so bad that Google stopped
offering Navigation for the transit mode in it's own Maps service.  Which
was actually a pretty slick thing, and I actually used it a lot for the
last few months that feature was even available, since if your route
suddenly became impossible to make a transfer because of a delay or the
GTFS Live feed indicated there was a problem, it would 

Re: [Talk-transit] different interpretations of v2 PT scheme

[Paul Johnson]

On Fri, Jul 3, 2015 at 4:58 PM, Janko Mihelić jan...@gmail.com wrote:

 I see no reason to group objects in stop_area_groups, unless maybe if
 there is a name or ref that only makes sense to give to a collection of
 stops, and they all have different names. But if you are talking about a
 station, we have the tag public_transport=station.


Station might be overblowing a situation where you have a generic
streetcorner, two bus routes crossing and a stop on each side of the
intersection; stops going East and West might be called First and Main
Street, whereas the cross street would have Main and First Avenue, and not
all four of those stops have any physical presence other than that's where
the bus regularly gets flagged down (or signaled from onboard) to stop.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Paul Johnson]

On Sun, Feb 22, 2015 at 12:55 AM, Jo winfi...@gmail.com wrote:

 Hi Paul,

 How do passengers know where to go and stand if there are no physical
 markers? I think a bus stop should be able to be defined by the fact the
 driver knows where to halt and the passengers know where to wait.


In our case, this is published in the schedules and (occasionally) on the
billboards on the outside of the bus.  You can flag a bus about a bus
length after any intersection with no marked bus stop within a one-block
radius.


 Isn't that 'convention' also some sort of ground truth? Im sure this case
 happens in many countries around the world, although in some of those
 countries it may be the case a bus can be flagged at any point on its
 itinerary.


Does word-of-mouth essentially count as ground truth?  I'd like to know if
there's some accepted key=value for this situation that can be used with
highway=bus_stop, if one exists.


 Of course, as soon as roads become busier, that's not possible/practical
 anymore.


Despite the fact that Tulsa ended up largely flat enough to put major
thoroughfares along the lines of survey for range and township, the side
streets within those sections often wind around and dead end uselessly for
no reason, even where there's no creek or other obstruction.  This makes
many of the section line thoroughfares rather congested, particularly
during key times (the Advent shopping season, rush hour in general but
especially on a Friday evening, etc), but in our case, this meme applies
http://i2.kym-cdn.com/entries/icons/original/000/004/965/174740_127063750695194_3264526_n.jpg.
Tulsans drive obnoxiously close to each other but you can tell who is from
out of town (we have too many different license plates for that to be a
reliable indicator) based on who follows close to a bus.


 I've been working a few years adding almost 7 stops for a small
 country. That was a lot of work, of course. But now I notice that adding
 and maintaining the routes is even more work, hence the creation of the
 script to automate the process where possible.

 One of the problems I faced is that when I needed to fix a route, I had to
 apply the same fix to all the variations of that route, over and over
 again. Now I do it once, creating a 'golden  route', then letting the
 script take care of the others. It's still some work, as I need to check
 manually if the code got it right, route by route.


Still, I'm laying the initial groundwork to get to the point where we have
a golden route for each route (or in the 101 Suburban Acres case,
actually eight routes).


 Concerning the roles, I guess they may help JOSM and iD when people split
 ways, although I think JOSM gets that right without them already. A bigger
 problem is people joining ways, which results in stumps that are not
 connected to the next way anymore. And of course, deleting ways,
 potentially replacing them by new ones.


I've been noticing a trend towards shorter ways, to the point where people
are a little worried about merging ways now.  This is generally a Good
Thing, since joining ways generally breaks a lot more than relations (lane
tagging comes immediately to mind, and because of the tag conflict, this
often sets off warning bells).
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Paul Johnson]

On Sat, Feb 21, 2015 at 3:48 PM, Jo winfi...@gmail.com wrote:

 Hi Paul,

 I see what you mean now. I dropped the forward/backward roles on the ways
 a few years ago. Recently I thought that they should be a help for the
 sorting algorithm, but your example proves they aren't.


Well, they do help for sorting out which way a route should be going and in
which order to some extent.  Though I'm starting to wish we had a way to
number the sequence.  Role wouldn't do it since we still need forward and
backwards...


 I've been developing a script, which tries to use other good relations to
 fix the one it's currently run on.

 For that script to be able to work, you'd need the stops in the correct
 order though.

 It works like this:

 For a sequence of stops it tries to find other relations which have the
 same sequence. The other relation with the longest sequence in common
 'wins'.

 Then it finds the ways adjacent to the stops on each end of the sequence,
 then uses the sequence of ways that connects the stops.

 We can work that way, because we have received the stops and the
 timetables from the operators, but it's the opposite of what you start
 with, when you have to get on the
 bus to create a GPX to get an idea about one the variation routes of a
 line. (After that you'd use the unstable plugin to add the stops that are
 already mapped).


Well, the GPX would gather the itinerary.  I still need to go back through
and doublecheck about 1600 stops, since there's a very high number of stops
that aren't signed in any way, shape or form that Code for America Tulsa
received from Tulsa Transit.  And, as far as I'm aware, we expect some kind
of permanently fixed marker recognizable as such to be able to map it as a
bus stop.  If we *do* have some way to tag this situation despite a lack of
ground truth in the physical sense, then, by all means, someone please let
me know now, so I can back out of tagging stops for a minute, revert and
repull.  In which case, I'll have the opposite problem I do now, which
would be *adding* a large number of stops that *aren't* in the data we got
from Tulsa Transit (which, IMO, is the less worse problem to have, even
though that's a bigger project).

The script works quite well, as long as you have some 'golden' routes it
 can grab way sequences from.


 Ouch!  Yeah, I'm not entirely sure that's going to be readily done given
Tulsa's situation.  I wish this situation were unique, but I somehow think
I'm going to be beating my head against the wall when I start working with
the OK Coders to pull in Oklahoma City's transit systems.  And maybe in the
future, the Iowa Pacific Railroad's upcoming regional transit system, the
Eastern Flyer Express and it's associated bus network...
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Mapping bus routes with doglegs and loops

[Paul Johnson]

Is there an easy way to map these?  In JOSM, I run into problems with
trying to sort when I edit that pretty much complicates the situation to
the point where I end up having to start over if I get the order wrong, and
the public transport plugin isn't the most stable thing in the world.
Starting to bang my head into the wall with this.

Several of many examples I'm running into can be found (as I've mapped them
so far) with [route=bus][ref=101] in bounding
box -96.0084915,36.1395383,-95.9528732,36.2658677
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Mapping bus routes with doglegs and loops

[Paul Johnson]

On Sat, Feb 21, 2015 at 2:31 PM, Jo winfi...@gmail.com wrote:

 Hi Paul,

 It helps, when you select a subset of ways and only let JOSM sort those
 automatically.


True, but if you've had to edit a section of a dogleg to add another, sub
dogleg, this breaks, too.  The ground truth is breaking the tool.


 Can you select one of the relations, then do Ctrl-Shft-h, then copy that
 url.


No problem, one such example is the 101 Suburban Acres southbound via
Denver  49th and Westview
https://www.openstreetmap.org/relation/4614100/history.  Towards where it
heads off MLK to Osage Casino along East 63rd North Street, it has a dogleg
with two branching doglegs, two of those doglegs also have a loop.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Talk-us] I've been workin' on the railroad (in California)

[Paul Johnson]

On Thu, Jan 15, 2015 at 10:38 PM, stevea stevea...@softworkers.com wrote:

 And here is what I've learned.

 This is tedious work, especially a state at at time.  It is slow, but that
 is because it is a whole (large) state.  This is not impossibly large work,
 not by a long shot.  Yet for one person, a whole state is a lot of work.
 For one railroad (elephants are eaten best one forkful at a time) this sort
 of effort is not difficult, and the rewards in new renderings are available
 tomorrow.


Break it down by county (possibly by county district, given some of the
really large ones like San Bernardino, or the real rail dense ones along
the coast).  Do the rail yards first, the rest becomes a cakewalk.


 It is important to use the name= tag to unambiguously (assert) a name for
 an aggregation of rail segments into a Subdivision or Line (or Lead if
 usage=industrial or service=spur).  This is especially true as OSM now
 often has messy rail around yards and regarding whether there is
 single-track or double-track in many or most places.  What I am saying is
 that we work to do to be more accurate.  And, this work is doable.


When in doubt, I move the TIGER-imported name to operator (since it often
is) and leave name blank if I don't know the lead or subdivision or line.
There seems to be some confusion about this since I've noticed people will
rename segments of TriMet's MAX system to Metropolitan Area Express after
I've attempted to put the proper name of the line (and not the whole
system) on the lines (and some folks keep adding oneway=yes to MAX lines
despite it's dual line running and operation on one-way streets, the only
place where one-way operation is always true is the loop on Fifth and Sixth
avenues and one track of the Steel Bridge based on my knowledge of TriMet's
rail operations rulebook and confirmed by repeated ground observation
seeing trains operate on opposite the usual track circa when the Green Line
opened).


 Both tags on ways and tags in relations are supported, but it appears tags
 on ways supercede.  I find that in the USA, because of the way that TIGER
 tags have put much rail into parts of North America, adding usage= tags to
 ways is often how things begin.  Then these get aggregated into type=route,
 route=railway relations.  I have not yet explored the multiple possible
 options of how tagging might supercede except as above.


Annoyingly, the Transit layer also seems to be exceptionally bus-oriented
and doesn't render routes on rail lines, as well.  This has led to some
locales, such as folks interested in mapping the IRT and BRT in New York
City, to tag for the renderer, putting routes in parenthesis in the name
tag on stations.  The renderer also ignores line color, which can be
defined in the tagging (and is often, such as in Portland, which uses red,
yellow, green, blue, and plans to use orange, brown and used to use black,
the only way to identify the line).


 That said, a much richer branching structure certainly exists (requiring
 appropriate tagging).  Sidings, yards and signalling are crude or virtually
 nonexistent, though there in some measure.  Speed limit data are virtually
 nonexistent.


To some extent, given that signs, signals and speed orders, change more
often along rails than along roads, tends to be rather fluid, and are often
located in places where, unless you're a frequent rider of a passenger
service or work for the line, aren't readily verifiable legally
(trespassing on a railroad is srs bsns, both legally and in terms of
personal danger).


 Private corporation rail data are not likely compatible with our ODBL,
 though it doesn't hurt to ask (for explicit permission). Public rail data
 from a state with generous public record laws (such as crossing
 spreadsheets) can be quite helpful to identify names (based on road
 crossings, city/county and/or lat/long data) of Subdivisions, Lines and
 Leads.


I wish I had this.  Though there gets to be overkill, too, for example,
every speed limit in Oregon is published, from the smallest alleyway to the
largest segments of I 5, and everything in between.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposal for a new transport tag

[Paul Johnson]

On Wed, Feb 29, 2012 at 8:03 AM, Bryce McKinlay bmckin...@gmail.com wrote:

 Secondly, GTFS is already a good, widely used, open format for transit
 schedules. Introducing a new set of tags for this stuff in OSM would
 be like reinventing the wheel. In many cases GTFS data is provided and
 kept up-to-date by the transit providers themselves.  How about tags
 that link public transport relations to the appropriate GTFS URL
 instead?


I agree; IIRC, GTFS data is available on the agency's website in a standard
location.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] totally abandoned rails

[Paul Johnson]

On Tue, 27 Jul 2010 20:59:53 -0400, Greg Troxel wrote:

 For tagging the status of rail infrastructure there are in use:
 
 I usually think it's good to look at existing practice by others.
 
 On USGS maps, and in US legal usage:
 
   out of service: rails still exist, but no trains.  shown as regular
   rail on USGS maps.  OSM has no  aparent term for this.

This would also be disused.
 
   abandoned: this is a legal distinction, where ICC has approved
   abandonment.  shown as dashed rails.  tracks may or may not be
   present, but typically some track remnants.  OSM says disused

Tracks are always present for disused.

   old railroad grade.  Definitely legally abandoned, definitely no
   rails.  often just traces of embankment.  shown as dashed line, no
   hashes, but there are definite signs on the ground that there used to
   be a railway (obvious to any train fan).  OSM says abandoned

Yes.




___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] totally abandoned rails

[Paul Johnson]

On Wed, 28 Jul 2010 11:31:53 +0200, Michał Borsuk wrote:

 On 28 July 2010 11:26, Ed Loach e...@loach.me.uk wrote:
 
  Something like http://forum.openstreetmap.org




 Definitely. Forum is way better than a mailing list, a threaded forum is
 even better.

[citation needed].  There's nothing a forum does better; personally given 
the centralized, rigid nature of forums that prevent thread management 
and offline use, the forum should be abandoned.


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] totally abandoned rails

[Paul Johnson]

On Wed, 28 Jul 2010 11:03:59 +0200, Michał Borsuk wrote:

 Just a technical note, we'd need a server with some proper Forum-like
 software, so that posts like the one below could be pinned.

Why not just update the wiki?  Why needlessly complicate things with a 
forum?


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] totally abandoned rails

[Paul Johnson]

On Tue, 27 Jul 2010 16:56:22 +0200, Heiko Jacobs wrote:

 So this words don't satisfy me ...
 I'm searching something like traceless, virtual, very, really very
 abandoned, ...
 
 Does anybody has an idea?

How about omitting the line entirely?  If it's no longer part of the 
ground truth, why try to map it?  OSM is in the now, after all.


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Monorails

[Paul Johnson]

On Thu, 2009-09-03 at 22:02 -0400, Bill Ricker wrote:
 On Thu, Sep 3, 2009 at 4:46 PM, Frankie
 Robertofran...@frankieroberto.com wrote:
  Fulfilling a very small niche, I've added a (very short) page for monorails
  (in the UK): http://wiki.openstreetmap.org/wiki/United_Kingdom_monorails
 
 we should build more monorails so we can map more monorails ...

We are, in the US.  The Las Vegas Express is a MAGLEV monorail that
Amtrak's building between Los Angeles and Las Vegas.  Which begs the
question:  Who, of sound mind and greater than room temperature IQ,
would /ever/ /want/ to go to Los Angeles in the first place, much less
as quickly as possible?  There's also the Seattle Monorail, which was
poorly designed and shoddily built quickly for the World's Fair, with
track curves close enough together that two trains will collide head on
if they round the same curve on parallel tracks, though they've been
talking about fixing that problem and expanding the system.



signature.asc
Description: This is a digitally signed message part
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Multiple tracks

[Paul Johnson]

On Sat, 2009-06-20 at 12:18 +0100, Richard Mann wrote:
 While I like the idea of marking individual railway tracks as separate ways, 
 I foresee a problem for the renderers if we don't tell them how many tracks 
 are adjacent. If a renderer makes a distinction between tracks=1 and 
 tracks=2, and we've marked two separate adjacent ways with tracks=1, then 
 we'll just end up with two single tracks on top of each other at medium zooms.

It seems like OSM is already quite well-suited to handling this problem
with the tools already available.  See the Metropolitan Area Express
system in Portland, here's a particularly good example from the
neighborhood by the high school I went to growing up.
http://www.openstreetmap.org/?lat=45.5107lon=-122.8481zoom=14layers=0B00FTF




signature.asc
Description: This is a digitally signed message part
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit