Re: [Talk-transit] Public transport validator+generator from Maps.Me
This is great! Can you expand it to modes besides subway? S > On May 29, 2019, at 10:35, Alexey Zakharenkov via Talk-transit > wrote: > > Hello everybody! > > I'm a part of team who worries about public transport status in OSM database, > especially rapid transit transport. I want to represent a public transport > validator+generator that somebody might find a useful facility. It's open > source: > > https://github.com/mapsme/subways > > Given a list of transport networks it generates output suitable not only for > rendering PT routes but also for routing. Meanwhile it finds errors like gaps > in rail/road sequence in a route, absent/doubling station at a stop, etc. We > run the validator daily and publish the results at > > http://osm-subway.maps.me > > The page shows that even large and important subway systems (like New York > Subway) in OSM DB are currently corrupted and therefore unusable for > practical purposes. Difficulties occur not only due to negligent mapping but > also due to misalignment how to map PT. I call you, who is interested in PT, > to use this instrument, evaluate it and give feedback. We're ready to improve > this tool for the community sake and take into account worthwhile suggestions. > > Thank you for your attention. > I'm ready to answer any questions. > > Best regards, > Alexey > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On 2019-05-03 12:09, Dave F via Talk-transit wrote: On 30/04/2019 18:34, Stephen Sprunk wrote: A platform is where people wait to board; if they stand at a pole (typical for buses), then the pole is logically the platform. This reinforces my point about misappropriation of tags. A platform is a physical construction higher than the surrounding ground to allow easier boarding. It's a logical platform whether it physically exists or not. It's pretty well established that using a platform node for a mere pole is valid. People wait there to be picked up, regardless of the actual surface type (which can change over time anyway). A platform: https://s0.geograph.org.uk/geophotos/04/76/30/4763016_2416f5ee.jpg Not a platform: https://i.pinimg.com/originals/38/90/a0/3890a0f451e1a6900d174b29125b3c80.jpg If (& I believe it's a big if), a separate tag is required to as you & Markus suggest, one with a unique, non-confusing value should be used. Many public_transport=platform are tagged on the same node as highway=bus_stop. They have no raised construction Therefore they're redundant - routing can use the bus stop tag for the "stop node beside the road" as Markus described it.: https://www.openstreetmap.org/node/469760546#map=19/51.51026/-0.18630 I'd be fine with saying that highway=bus_stop implies public_transport=platform, except that some mappers put bus stops on the way instead of beside the way and argue with anyone who tries to fix them, so in those areas, separate nodes for the platform had to be added. Ditto for railway=platform implying public_transport=platform, and it doesn't seem to have the same problem. I'm not sure for other modes since I've never dealt with them. If we could all agree on this, we'd just need to change the documentation--and go fix thousands of bus stops that are in the wrong place. That's easily distinguished from large platforms because it's a node rather than a way/area. Not really. To save time, contributors occasionally combine tags onto a single object: litter_bins, shelters, benches *&* raised platforms in the case of bus stops. I'm not saying it's the correct/best way to map, but it happens. It doesn't make a difference for routing. If a platform is large enough that it matters for rendering, then someone needs to go back and draw the platform as an area. Same as any other structure where someone puts a node as a "temporary" marker. It's better than nothing, but it can be improved. If you're trying to construct a route that involves walking to a bus stop, riding the bus to another stop, and then walking some more, then you need a linkage connecting the bus route (using stop positions) with the walkways (using platforms). I'm not saying that's the only way to do it, but it's the only way that was proposed. Do you have an example as I'm unsure what you mean by 'walkways' and platforms are disconnected from the bus routes, as are bus stops, so, as I said above, PT can use bus stops. Walkways as in places where people walk. The router needs to give me directions down the sidewalk or whatever to where I wait for the bus. If the only node is on the highway, am I supposed to stand in the middle of the highway until I get hit by the bus? No, it should route me to the platform beside the highway. But the bus stays on the way, so it can't stop at a platform correctly off the way. That's where the stop position comes in, and the supposed need to link the two together. Markus previously said "OsmAnd Is able to navigate with routes consisting only of highway=bus_stop beside the road." I assuming they're calculating the stop position based on geometry, which should work fine in most cases. But if an explicit stop position does exist, they should use that instead. So, to be absolutely sure we're singing from the same hymn sheet, are we agreed that 'public_transport=platform' tag to represent a place where vehicles stop to allow passengers to alight, is redundant in PT as another, existing, more prevalent tag - 'highway=bus_stop' can be used instead? Notice what you did there: the platform tag "represent[s] a place where vehicles stop". That's the entire argument over bus stops in a nutshell, which led to the redundant tagging. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On 2019-04-30 05:50, Dave F via Talk-transit wrote: On 29/04/2019 19:39, Markus wrote: On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk wrote: Part of what seems to have started the PTv2 mess is that bus stops were sometimes mapped on the way and sometimes beside the way, and both cases were tagged the same. PTv2 tried to separate those into "platform" and "stop_position", to bring uniformity across modes. It would have been a lot easier to just recommend placing stops beside the road. :) If there is a problem on the OSM database I believe sorting that problem is beneficial rather than 'papering over the cracks' by adding extra tags. It may seem quite laborious, but just as quick as adding those tags. I agree. We need platforms beside the way so routers can get people to/from the stop on foot. This is a big deal because trains are long and can usually be boarded along their entire length, unlike buses where a node often suffices. OTOH, we need stop positions so routers can get people from stop to stop on the buses/trains. Routers just need the platforms (the places beside the road) because the journey begins and ends there. Please clarify what you mean by 'platforms'? Many UK bus stops are merely signs clamped to telegraph poles. In rural areas there may not even be a pavement, let alone a raise platform. Please remember that we should be mapping the physical world. PT schema should fit in with what's actually there. A platform is where people wait to board; if they stand at a pole (typical for buses), then the pole is logically the platform. That's easily distinguished from large platforms because it's a node rather than a way/area. Stop positions (on the road) are irrelevant for routing. If someone, for whatever reasons, needs the stop positions, they can be calculated (projection of the stop node or centroid of the platform to the highway or railway way). Wouldn't a stop position be easier to locate if it's a node on the highway, rather than an imaginary, offset 'platform'? Please show me a router which uses platforms as I'm struggling to see the benefits atm. I think the idea was that nobody _could_ build routers with the data we had, which was inconsistently tagged between areas and sometimes even between mappers in the same area. If you're trying to construct a route that involves walking to a bus stop, riding the bus to another stop, and then walking some more, then you need a linkage connecting the bus route (using stop positions) with the walkways (using platforms). I'm not saying that's the only way to do it, but it's the only way that was proposed. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On 2019-04-28 09:04, Markus wrote: On Sun, 28 Apr 2019 at 13:47, Dave F via Talk-transit wrote: Are Stop_Areas required? What are they for? Are they in use?/Who uses them?/Will they ever be used?* If there is a purpose for them, what should they consist of? I've seen shops, bike racks, litter bins included. Surely they're irrelevant? At least, stop_areas are required for underground stations (if footways have not been mapped yet) to link the railway=subway_entrance with the station. Including other elements than station, platform and entrances IMHO is useless and makes the relations unnecessarily confusing. Stop areas are supposed to link stop positions to platforms, so a router knows which platform you need to take a route that only stops on a particular track. In most cases, this can be inferred by proximity, but in some it can't, particularly at very complex stations. If an entrance serves a subset of platforms (i.e. you might have to leave and re-enter via a different door to change trains), then it might make sense in a stop area, but otherwise, it's just part of the station. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On 2019-04-28 06:46, Dave F via Talk-transit wrote: Are Stop_Areas required? What are they for? Are they in use?/Who uses them?/Will they ever be used?* If there is a purpose for them, what should they consist of? I've seen shops, bike racks, litter bins included. Surely they're irrelevant? Remove public_transport=station/train=yes & public_transport=platform/train=yes from railways. They are purely duplication of the existing, much used railway=station/railway=platform respectively. They provide no additional information. Duplication is wasted effort. It leads to confusion & errors. Agreed. The use of 'platform' seems to have been hi-jacked by PT to represent a stopping place instead of it's original true meaning of a physical raised area above road level to aid vehicle boarding. Part of what seems to have started the PTv2 mess is that bus stops were sometimes mapped on the way and sometimes beside the way, and both cases were tagged the same. PTv2 tried to separate those into "platform" and "stop_position", to bring uniformity across modes. We need platforms beside the way so routers can get people to/from the stop on foot. This is a big deal because trains are long and can usually be boarded along their entire length, unlike buses where a node often suffices. OTOH, we need stop positions so routers can get people from stop to stop on the buses/trains. Where things went off the rails (pun intended) is creating redundant mode-neutral tags (probably so routers would work regardless of mode) when mode-specific tags already existed. Is public_transport=platform required at all on bus stops? As with railways, use existing tags. Agreed. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Line colour, text colour and background colour
The route and route_master relations have a documented "colour" key that can be used. However, that seems to be intended for the line itself, and I'm not aware of any renderer that uses it. If they did, they'd probably use it for the label background too. Relation:destination_sign has attributes colour:back and colour:text, so it makes sense to reuse those here, but if renderers aren't even using colour for the line/label today, I wouldn't count on them doing anything special with the text either. S On 2019-04-27 06:03, Héctor Ochoa wrote: > Hi, > Yesterday Zaragoza City Council unveiled its new bus network design. It gives > each line a distinct text and background colour, as seen here: > https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-9.jpg > > https://i2.wp.com/detalier.com/wp-content/uploads/2019/04/autobuses-urbanos-zaragoza-detalier-8.jpg > > > I am asking if https://wiki.openstreetmap.org/wiki/Key:ref:colour could be > adapted to use it in public transport routes, or something similar that > complements https://wiki.openstreetmap.org/wiki/Key:colour > > Thanks in advance! > Héctor > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Defining service on railway=tram
The current four service values are based on physical characteristics of the track that are easily observed on the ground and unlikely to change.This proposal seems to overload that with an indication of how the track is used, and we already have a tag for that: usage. Granted, none of its existing values seem like a great fit, but if we're going to add new values, wouldn't that be the right place?I can't recall having seen a tram siding, but I have seen light rail sidings. Given the fuzzy line between the two, it seems unwise for any of their (many) common tags to have different meanings.Also, does this problem even need solving? With route relations, consumers can easily deduce that a given track is not normally used, so why have a redundant method of indicating the same thing? They're certainly more work to create and maintain, but they also provide more benefits, so that seems fair.S___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] New wiki article about network-relations: please review section about public transport
My main problem with this page is that it doesn't actually define the term "network", and the only mention that a network relation is one with "type=network" is buried down in the section on electric networks. It does mention route relations, but it doesn't explcitly call them out as being "type=route", which would have been a great place to put such a clear and useful distinction. The page for Key:network is also sadly lacking a clear definition of "network". There are a couple of references that seem to indicate it's a coherent numbering scheme (i.e. network denotes the namespace for the ref tag), which would be clear and useful at least for numbered routes and seems to be what is done in practice, but the section on public transit implies it might instead be for fare systems, which is entirely orthogonal. Also, it isn't clear what "features" should be members of a network relation. Routes? Route Masters? Stations? Platforms? Stop areas? If you include too many features, when the number of members grows to impractical levels, can you have a hierarchy--such as the "super"-relations used for long highway routes? S On 2018-08-31 03:04, User 30303020 wrote: > Dear subscribers, > > quite recently a new wiki article about network-relations was created [1]. It > features a section about network-relaitons in public transport mapping. > Please review this section as there may be more approaches to this topic than > mentioned in the article. Just to clarify the notion of a network-relation, I > copied the definition here: > > _A network-relation groups features as members of a network, marks them as > being part of a certain network and represents this network itself. A > route-relation with the network=* tag is therefore not a network-relation._ > > Thanks and kind regards > U30303020 > > > Link: > [1] https://wiki.openstreetmap.org/wiki/Relation:network > > - > FreeMail powered by mail.de [1] - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov Links: -- [1] https://mail.de___ 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
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 : > > 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
stop_position is even worse for trains, which might be hundreds of meters long with dozens of doors. The wiki says to map it as the "center" of the train, but I'm not sure that's useful other than to explicitly indicate which track the train uses, which could probably be deduced from the route relation anyway. It's also not necessarily a fixed point; at stations here where all passengers enter/exit a platform at one end, trains always stop with their front/rear at that end of the platform, so the center depends on the train's length. Heck, even the platform a route uses is not necessarily fixed; at many large stations, different trains on the same route can show up on different platforms or tracks, and that case doesn't seem to be mappable at all today. It seems a bit simpler for buses, where the front generally stops in the same place every time and folks generally enter the front door, though there are always exceptions. The location of exit-only doors doesn't seem like something that needs mapping. S On 2018-04-16 13:26, Jo wrote: > Here in Belgium, we have normal buses and longer ones, either can have 2 > doors or 3 doors. There is no way of knowing which of those buses is going to > serve which stops at a given time. The only thing we do know for sure, is > that we are supposed to get on in front, except for wheelchairs and parents > with strollers. I fail to understand why stop_positions are considered to be > that important. Especially for buses. For trains I might understand, but even > there it's impossible to predict where exactly the doors will be when the > train stops. And it's not important, what matters is when there are zones on > the platforms, those we can map by splitting those platforms. > > Jo > > 2018-04-16 20:17 GMT+02:00 Ed Loach <edlo...@gmail.com>: > >> Stephen wrote: >>> If a consumer doesn't care about stop_position members, it's trivial >>> to >>> ignore them. If the current spec says they're mandatory, then >>> propose >>> making them optional; I would support that. I don't support >>> prohibiting >>> or removing them. >> >> They are optional in the current spec. I don't bother with them in bus route >> relations as physically a bus has to stop on a relation member way close >> enough to the bus stop (platform) node for passengers to get on (with the >> exact stop position depending whether the particular bus has doors at front, >> middle or rear). >> >> Ed >> >> ___ >> Talk-transit mailing list >> Talk-transit@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-transit [1] > > ___ > Talk-transit mailing list > Talk-transit@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-transit___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposal for simplification of mapping public transport
On 2018-04-16 08:11, Philip Barnes wrote: On 16 April 2018 07:46:13 BST, Jo <winfi...@gmail.com> wrote: Anyway, you're right in that the main point of my proposal is to get people to add 1 object per stop to the route relations. I think this is a good idea for bus routes as they are quite simple. There is a sign, the passengers wait thereabouts, the bus stops so the door is at this point and the passengers can then board, pay or show their pass to the driver. Making this too complicated will deter mappers from adding public transport. If mappers want to add additional information then they should be free to do so but it should not be compulsory. To me, this is the crux of the debate. If mappers have put in additional data or detail that you don't care about, then you should ignore it rather than remove it (or demand that they do so), because some other consumer may want that additional data. Ignoring data that is present but not needed is always easier and more reliable than trying to deduce data that is needed but not present. If a consumer doesn't care about stop_position members, it's trivial to ignore them. If the current spec says they're mandatory, then propose making them optional; I would support that. I don't support prohibiting or removing them. If a consumer only wants a node for the platform but it's mapped as a way/area, then it's trivial to detect that and compute the centroid. I don't support replacing existing ways/areas with nodes or prohibiting new ways/areas in the future. If the current spec says they must be ways/areas, then propose making nodes allowed too; I thought that was already the case, but if not, I would support fixing that. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Uploading public transport data on OSM
AFAIK, GTFS feeds do not themselves have any sort of unique ID. However, as previously noted, it's a reasonably safe assumption that an agency_id will be unique across GTFS feeds within its geographical area. I know that's not a guarantee, but I don't see what else we could do here given the source. S On 2018-01-19 04:40, Wiklund Johan wrote: But then how would an outsider know what the operator code or ID is, and where this operator+id is unique? If GTFS data is the source of your OSM stops, I would say a dataset reference is far more relevant than operators or network since the ID is unique in a GTFS dataset, but only in that dataset. Overlapping datasets always cause problems of course, but only if they are not properly referenced. Johan Wiklund Data manager johan.wikl...@entur.org www.entur.org -Original Message- From: Andrew Davidson [mailto:thesw...@gmail.com] Sent: fredag 19. januar 2018 04.12 To: talk-transit@openstreetmap.org Subject: Re: [Talk-transit] Uploading public transport data on OSM On 19/01/18 01:32, Stephen Sprunk wrote: Agreed; ref:gtfs just won't work, and ref:OPER probably would. I had always thought that ref was the public facing reference that is used (ie: what's on the bus stop sign) and in the GTFS scheme this is stop_code. The stop_id is supposed to be unique and is not necessarily the same as stop_code. Looking at taginfo the most common way to tag stop_id seems to be gtfs_id. So if there is more than one stop_id for a stop (ie: appears in more than one GTFS feed) I would have thought something like: gtfs_id:OPERATOR= I have read elsewhere that some mappers prefer to use NETWORK, rather than OPERATOR, because their systems get put up for tender for operation on a regular basis so NETWORK is more persistent. I was wondering if there are more than one stop_id is it worthwhile tagging something like this: gtfs_id=A1;B1;C1 gtfs_id:A=A1 gtfs_id:B=B1 gtfs_id:C=C1 So that the data consumers will find multiple values under gtfs_id and know to look for an operator or network value. Or is it better to leave it blank? I guess it would depend on whether or not you have put qualified gtfs_id's on everything or just the shared stops. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Uploading public transport data on OSM
Agreed; ref:gtfs just won't work, and ref:OPER probably would. I was originally thinking in terms of some gtfs:key tags for imported data, similar to tiger:key tags. Once you consider multiple objects could be merged, though, that would likewise need to change to gtfs:OPER:key. But do we need such import tags if we can directly put the data directly into normal tags, such as your ref:OPER? My first thought was no, but perhaps it could help OSM edits survive future imports of lower-quality GTFS data? >From the other side, how can we design this so that stops removed from one or more GTFS feeds can be properly updated in OSM? I was thinking a gtfs:OPER:importdate tag, and once you're done adding/updating all the objects in the latest GTFS feed, you can then query for objects still showing a previous import date. But there is probably a better way. S On 2018-01-16 15:17, Jo wrote: > That is why I think it's important not to go with ref:gtfs, but use > ref:operator1, ref:operator2. Where operator1 and operator2 are the names or > short names for the different operators. In many cases you'll find that these > refs are also what the public sees on the stops (if the operators decide to > put it there) or in internet urls when using the operator's website. > > Here in Belgium, we have 3 operators extending into the other operator's > mostly served area and some lines extend into neighbouring countries, so we > had to namespace the ref tag a few years ago, already. > > Polyglot > > 2018-01-16 22:07 GMT+01:00 Stephen Sprunk <step...@sprunk.org>: > >> AFAIK, the operator ID is only guaranteed to be unique within a single GTFS >> feed, but it's reasonably safe to assume they'll also be unique between >> feeds with overlapping geographical areas. It's probably not safe to assume >> that's transitive. >> >> Where operators don't cooperate and produce a single joint feed, you'll >> inevitably face the "same" stops appearing in multiple feeds. Imagine a >> single roadside bus stop pole with signs from two or three different bus >> operators on it, and that pole would have a different ID and probably even >> different lat/long in each feed. Ideally, a local OSM editor would be able >> to merge them into a single stop object--and that merger would survive later >> bulk imports from all those GTFS feeds. This would cut down on map clutter >> and allow routing apps to more easily recognize transfers, but I'm not sure >> how to design such a schema. >> >> It's been a while since I read the spec, but I think GTFS also has a similar >> concept to stop_areas, and that will probably have similar problems to >> stops. >> >> Routes appear simpler to deal with since they're unique to each operator, >> but they're inherently built on top of stops (or stop_areas), so they may >> present new problems when we get there. >> >> S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Uploading public transport data on OSM
AFAIK, the operator ID is only guaranteed to be unique within a single GTFS feed, but it's reasonably safe to assume they'll also be unique between feeds with overlapping geographical areas. It's probably not safe to assume that's transitive. Where operators don't cooperate and produce a single joint feed, you'll inevitably face the "same" stops appearing in multiple feeds. Imagine a single roadside bus stop pole with signs from two or three different bus operators on it, and that pole would have a different ID and probably even different lat/long in each feed. Ideally, a local OSM editor would be able to merge them into a single stop object--and that merger would survive later bulk imports from all those GTFS feeds. This would cut down on map clutter and allow routing apps to more easily recognize transfers, but I'm not sure how to design such a schema. It's been a while since I read the spec, but I think GTFS also has a similar concept to stop_areas, and that will probably have similar problems to stops. Routes appear simpler to deal with since they're unique to each operator, but they're inherently built on top of stops (or stop_areas), so they may present new problems when we get there. S On 2018-01-16 14:35, Jo wrote: > Is there a common pattern to these GTFS IDs? Are they guaranteed to be unique > across operators? > > Or is that not important and is it only important that they are stable > between versions of GTFS files for a region? > > Adding a ref:gtfs tag would not be very hard to do, but I would prefer a > scheme with ref:OPERATOR, because some stops may be served by multiple > operators and thus be present in multiple GTFS feeds. > > Polyglot > > 2018-01-16 21:07 GMT+01:00 Stephen Sprunk <step...@sprunk.org>: > On 2018-01-16 08:30, Mike N wrote: > On 1/16/2018 7:37 AM, Yash Ganthe wrote: > What caught my attention is a project called Go Sync > https://wiki.openstreetmap.org/wiki/GO-Sync [1] > The description indicates that it is for syncing GTFS with OSM. But I am not > sure what type of account is needed for that. > > From what I recall, Go-Sync only synchronizes stops but not the GTFS > route paths with OSM route relations. > > The routing samples on the OpenStreetMap web site will not > automatically give public transport trip routing because the full GTFS > schedule information is not in OSM. It would require a separate > local site such as OpenTripPlanner which automatically combines full > GTFS with OSM data. There are some companies providing large scale > instances of OpenTripPlanner which may cover your area. What I'd like to see is some sort of tag on OSM objects (stops, routes, etc.) listing the GTFS ID numbers so that tools can more easily connect the two; that should be easy enough if someone defines a scheme and gets the few relevant tools to use it. The lat/long for stops in GTFS data is often questionable, so it would be good to have some way for folks to be able to fix the stop locations in OSM and not get overwritten by another import later. In many places (especially in the US), GTFS data will change every few months, so if we want it in OSM at all, we need a scheme that can deal with regular bulk imports without losing quality where local OSM editors have improved things by hand. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit [2] ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov Links: -- [1] https://wiki.openstreetmap.org/wiki/GO-Sync [2] https://lists.openstreetmap.org/listinfo/talk-transit___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
On 2016-10-31 07:54, Greg Troxel wrote: Felix Delattre <felix-li...@delattre.de> writes: I also like them. Thanks, Jo! But isn't "line" an European wording? Would an English native speaker intuitively understand the concepts of "line" and "itinerary"? I always For me (en_US), I find it awkward. I (en_US) find it a bit awkward, but mainly because I think the general public uses "route" to refer to both, and which they're referring to (if they even make that distinction) can be inferred from context--something a computer can't do. thought a "line" is more likely to understand as a network or public transport operator for US boys and girls - but (hopefully) I might be wrong. "line" often refers to a company that operates routes, like a "cruise line". Like many English words, the meaning of "line" depends on context, to the point it's both clearly right and clearly wrong to different people. I should point out that "bus lines", "cruise lines", "air lines", etc. are plural when talking about one company (e.g. American Airlines) because they operate a collection of individual lines between specific locations, such as New York-Los Angeles. It is illogical to think of a line as going in only one direction, whereas a route does have a direction, so logically a line must be a collection of two (or more?) routes, right? Overall, I think this is the best one can come up with for this concept. Unfortunately, "line" alone is too generic to use in OSM, which is probably where "route_master" came from. itinerary is usually a set of places that a person or group is going to, often including cities/hotels on multi-day trips and sometimes including flights. If someone said "please send me your itinerary for your trip to France" they would expect a list of "this night we are at this hotel, address and phone, and this night". Exactly; one speaks of the itinerary for a specific trip. I'm still not 100% following. In the wiki table, is concept number 1 just a name for the collection of route variants, and basically the name that the bus company (agency/whatever) uses? I would call that "bus_route_name" then, with a name, and perhaps bus_route_ref for just the numberish part, along with bus_route_operator. This is making it like highway ref tags. Incidentally, this drives me nuts about transit. If the agencies actually published the names that way (e.g. variants 42A and 42B, perhaps with the shared portions just labeled 42), it'd make their services a lot easier to use; today, it's very easy to accidentally get on a "42 to Foo Street" when you actually needed a "42 to Bar Avenue". When "via"s get involved, it's even worse. Who came up with this nonsense and thought it was a good idea? I think "route_variant" is a good name, in that it captures the sense that all of the route_variants of a route are similar somewhow but not quite. The only awkwardness is that sometimes there will be only one route_variant in a route. If one is trying to avoid the word "route" for this, but not a specific trip, then the only term coming to mind is "service pattern", but a layman would need a bit to work out exactly what you're referring to. I doubt many have ever thought of the formal distinctions that we need. Overall, though, I would try very hard to just reuse the GTFS terms for the GTFS concepts, and to put a comment in the source or docs clarifying what they mean. I think the benefit of clearer terms will be outweighed by having more to learn. Finally, I think osm2gtfs is going to want to use information that isn't in OSM. I'm not sure what the plan is, or if one can produce a GTFS version that is just missing the fine-grained schedule information, and if that's what you want to do. Indeed, if we can get more information on the desired use, we may be able to provide more specific guidance. But I've been thinking more in terms of how to get GTFS data into OSM and/or match the two together, rather than OSM data into GTFS. Since GTFS already has ID numbers for each entity and OSM is free tagging, the former are fairly straightforward, whereas the (current) policy of not putting schedule data in OSM makes that latter seemingly impossible. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
On 2016-06-25 00:53, Jo wrote: Darya (a GsoC student) is actually working on a project to help with the routing. We haven't included conversion from GTFS and I'm not sure there will be time for that. What's most time consuming, especially because of changes/breakings caused by other mappers and PT itineraries subject to change, is to keep the routing up to date and that's what the new plugin aims to solve. Import of GTFS is what I'm most interested in, particularly due to the "subject to change" part of that. Other mappers in my area (a metro area of 5+ million) don't seem interested in transit routes; I'm interested, but it's a monumental task for one person, hence my desire for as much automation as possible. I have to imagine there are others like me elsewhere, and it's the kind of thing that can have huge impact on non-mapping users by providing high enough quality data that developers will add transit functionality to apps that currently ignore it, e.g. OsmAnd, and that will in turn generate more people willing to improve the data. I'll admit my interest is more rail transit than buses, and rail doesn't change much, but even rail routes aren't well done in many places--and the standard map renderers seem to ignore rail almost entirely, perhaps because the tagging isn't consistent. That could be improved as well, even if one ignores the GTFS import part, just by analyzing the existing data in OSM and fixing its tags. I"m willing to work on bus data too, even though I rarely ride buses, for that reason, but that's a much longer-term project due to the sheer number of stops. Part of my interest in importing them is I suspect other mappers (or users with apps with feedback buttons) are more likely to improve existing stops that are part of a network but not in exactly the right location than create new ones in complete isolation. At the moment it hooks mostly into the validator (so less routes would be broken due to other changes made to the geometry of the ways), but it's still work in progress. That's roughly what I was thinking: import the data, create a bunch of new nodes/ways/routes, merge them with existing ones where certain tags (e.g. gtfs:stop_id) match, and then let the validator scream about any remaining suspected errors (e.g. a stop with gtfs:stop_id and one without it within 400m). The first time would likely be a mess, particularly in places with preexisting data, but future imports should only generate errors where there have been legitimate changes in the imported data, e.g. a new stop is added. If you like, you can help with beta testing, of course. It does already help with routes going against one way traffic flows. It's called PT_assistant. I'm happy to help test if it provides functionality that's useful. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
n the pole override a "name" tag on the stop_position, or vice versa? What about a "name:en" tag on a stop_position versus "name" on a platform? It seems the current behavior is to render the name for each element independently, except that some (not sure it's deterministic) seem to get dropped entirely if they'd overlap. Within each element, which name to render (if any) should be straightforward. - Should "Hbf" be expanded to "Hauptbahnhof", or the suffix "(Westf)" to "(Westfalen)"? A renderer shouldn't have to know such things, and when people try to add such clever tricks, it usually ends up making things worse, e.g. a rule to correctly change "N Foo Ave" to "North Foo Avenue" also incorrectly changes "Ave N" to "Avenue North". - Have the tracks in the station "Vaugirard" this name or the name "Montparnasse"? Or the platforms or stop positions. I've been trying to figure out what to do on that front myself; so far I've simply left everything but the station itself unnamed because otherwise the current rendering output is unusable except at the highest zoom levels. And that's for far simpler cases than what you describe, e.g. a station named "Akard" with a pair of platforms named (as signed) "North" and "South"! S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
On 2016-06-21 15:12, Paul Johnson wrote: On Tue, Jun 21, 2016 at 2:02 PM, Stephen Sprunk <step...@sprunk.org> wrote: I found a couple transit-specific apps, but they refuse to work until I'm within some minimum distance of a stop. ... 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. I was going to say "at least they tried", but after a year, I agree. Plus it's basically one of those lame "browser in an app" deals, and it _still_ doesn't work all that great in Chrome. I don't get why so many folks waste money on that, other than to tell clueless execs that "we have an app" when all they really have is the same old website with a app-like shortcut. Building a custom app probably isn't cheap, but there _must_ be decent off-the-shelf apps out there that can work from a standard GTFS feed. Or they could just make their regular web site work well on mobile devices too; few riders would care it's not an "app". ... 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. *boggle* Here, they publish a 24x7 customer service phone number that works for both trip planning and any other questions/complaints from riders. Their web/app trip planner isn't bad, but it doesn't seem to be any better than Google Maps, which indicates it's using the exact same data that's in the GTFS feed (maybe the feed itself). [Cross-streets is] how nearly all bus stops here are named, aside from those part of complex bus/rail stations that tend to have multiple bays/platforms. I don't see the problem with that. It's when you get to those complex stations that you run into questions of naming the individual pieces vs the station as a whole, but it still doesn't seem that difficult until you get to rare cases, e.g. multiple stations that have grown together into one confusing, amorphous blob. The transit renderer doesn't seem to like to consider the same stop running different directions through the same intersection unless you bang the name up. A stop might be 41st and Yale in one direction, and Yale and 41st going the other way through the intersection, for example. I'm not sure what you're referring to; the only bus stops I see in all of Tulsa are the ones at or near Denver Avenue Station, and only one of DAS's bays seems to be labeled. Here, there'd be four distinct stops named something like "41st NB @ Yale", "41st SB @ Yale", "Yale EB @ 41st" and "Yale WB @ 41st". The only rendering challenge I see is if they're so close at low zoom that the names would overlap, but since they're all pretty much the same name anyway, it doesn't matter in practice. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS, tools and pt tags generally
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.
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.
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 (and reliable
route/schedule data to feed into them) is to hide this sort of
complexity from users.
Or obviate it. Sight unseen, just trying to make sense of the
situation based on just a map and what stops are handy, there's no way
I'd figure this out for Tulsa's 101 Suburban Acres route. Every other
trip alternates which way the route goes through the eponymous
neighborhood, so depending on which half hour it is, you might need to
walk to one end of the neighborhood or the other to catch the bus. Or
wait up to an hour instead. And then some trips make side trips to a
clinic (during it's business hours) and some trips make an additional
side trip to a alzheimer's treatment community (based on some
arbitrary criteria, possibly when the patients are allowed to come and
go).
Exactly. While a regular rider of the route can figure it out, or may
pick up a map/schedule for offline planning, the casual or tourist rider
will be baffled and is likely to end up in the wrong place. Most
drivers I've talked to are very helpful, but there's only so much they
can do if you get on the wrong bus aside from leave you on the side of
the road praying for the right bus to come along before you get
heatstroke, frostbite, etc. One simple mistake can easily cost you an
extra hour or two of travel time.
- How to obtain a name of a station?
How is this complicated?
A lot of cities name stops without signposting the name, often in the
form of "The Street The Route Is On at The Cross Street We're Stopping
At", such as "South Memorial Drive at East 56th Street" or some
similar pattern.
Oh, sorry. I was assuming a decent GTFS feed, where every stop
should have an official name, even if it's only cross-streets (typical
for bus stops). I thought the question was where to put that it in
OSM and/or where renderers should look for it.
Yeah, GTFS assumes every stop is named, even though this assumption is
outright broken even in GTFS's hometown of Portland beyond just naming
the intersection or block number ("6300 Block Southwest Murray
Boulevard" as a hypothetical name example of a stop not near a
corner).
That's how nearly all bus stops here are named, aside from those part of
complex bus/rai
Re: [Talk-transit] GTFS, tools and pt tags generally
On 2016-06-20 16:18, Paul Johnson wrote: On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk <step...@sprunk.org> 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. Same here and many other cities I've looked, so I didn't think it was that big of a deal. 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. *facepalm* I have plenty of complaints about the transit agencies where I live, but at least they manage to post signs properly and provide proper maps/schedules. Their GTFS data isn't as accurate as I'd hoped, but it's obvious they're _trying_ to get it right. 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). Really? I've looked at a couple dozen feeds for major US and European cities, and they seem to be reasonably complete and accurate. Then again, all of the ones I've looked at so far are ones that offer rail services, and the nature of rail implies a high enough level of funding that one can probably take things like a decent GTFS feed for granted. A small, bus-only agency can run on a shoestring budget where such things may be seen as "unnecessary" or "too much effort". 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? 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. 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. Another example are route relations. While there are wild constructions called route_master and ne
Re: [Talk-transit] GTFS, tools and pt tags generally
ough if the solution works fine in your local area and hopefully works somewhere else, more or less untested. We need an algorithm to do the right thing in 95% or better 99% of all places around the world. Of course. Transmodel tries to be right 100% of the time, but that means ridiculous complexity; GTFS isn't right quite as often, but it seems to be good enough for the vast majority of places and with a lot less complexity. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
