Re: [Talk-transit] Several stations in a stop_area
Would stop_area_group be a solution here? That was proposed a while back but I'm not sure if it was officially accepted. On Sat, Jan 22, 2022, 07:36 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 > > Best regards, > Alexey Zakharenkov > ___ > 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] [Talk-GB] Mapping train services in Great Britain
On Tue, 1 Jun 2021 at 13:34, Philip Barnes wrote: > On Tue, 2021-06-01 at 13:07 -0400, Jarek Piórkowski wrote: > > On Tue, Jun 1, 2021, 12:38 Dave F via Talk-transit < > > talk-transit@openstreetmap.org> wrote: > > > On 01/06/2021 16:11, Christopher Parker wrote: > > > > On 6/1/2021 10:54 AM, Dave F via Talk-transit wrote: > > > > > What's wrong with consulting a timetable? > > > > > > > > To consult a timetable you need to know what station to use. > > > > > > Then map the stations! > > > > So we've mapped the stations Windsor and Eton Central and Windsor and > > Eton Riverside, now how do we know which station timetable to consult > > to find out how to get to Paddington? Riverside is marginally closer to > > Paddington as the bird flies. > > Traveline https://www.traveline.info/ > > Uses OSM and includes walking and buses, so will calculate the best > station to walk to for the quickest journey. Other options are > available. Well the question was about knowing which timetable to consult off of station(s) ref/ID tagged in OSM, based off a claim that all that's needed in OSM are the refs. If we're going to just use Traveline, why bother mapping any transport at all? ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Talk-GB] Mapping train services in Great Britain
On Tue, Jun 1, 2021, 14:15 Dave F via Talk-transit < talk-transit@openstreetmap.org> wrote: > > > On 01/06/2021 18:07, Jarek Piórkowski wrote: > > On Tue, Jun 1, 2021, 12:38 Dave F via Talk-transit < > talk-transit@openstreetmap.org> wrote: > >> On 01/06/2021 16:11, Christopher Parker wrote: >> > >> > On 6/1/2021 10:54 AM, Dave F via Talk-transit wrote: >> >> What's wrong with consulting a timetable? >> > >> > To consult a timetable you need to know what station to use. >> >> Then map the stations! >> > > > So we've mapped the stations Windsor and Eton Central and Windsor and Eton > Riverside, now how do we know which station timetable to consult to find > out how to get to Paddington? Riverside is marginally closer to Paddington > as the bird flies. > > > > You use a 'timetable' https://www.nationalrail.co.uk/ a make a sentient > decision based on what you discover. > Why bother with OSM at all then? Just look at a Ordnance Survey map and use your sentience to find what you're looking for. You appear to assume OSM should contain all the data in the world and make > you tea & toast each morning. It doesn't, & can't. > Sorry, what's the tag for toast, is it highway=toast_shop? ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Talk-GB] Mapping train services in Great Britain
Without route relations, OSM shows where you can get on the train/vehicle, but not where you can go On Tue, Jun 1, 2021, 10:58 Dave F via Talk-transit < talk-transit@openstreetmap.org> wrote: > What's wrong with consulting a timetable? > > Maps show you where you can go, timetables tell you when . > > DaveF > > On 01/06/2021 01:18, Michael Tsang wrote: > > > I think you are missing the point that GB is not a city. > > > Cities are densly pack and urban transport systems reflect this. In > London tube trains simply stop at every station. > > > This structure will not work when it comes to rural stations, and what > we have works very well. It would not be efficient to stop every trains > at stations which only have a few dozen passengers in a day. > > Other European countries are doing it much better. The routes are > numbered. There are designated express services with stops only in big > cities. The rural stations have only local stopping services which call at > every stop en-route. > > We don't even have a useful route map from train companies that can work > out which train I should take without consulting the timetable. > > > ___ > Talk-transit mailing > listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit > > > ___ > 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] A bus stop with multiple gtfs:stop_id
On Thu, 28 Jan 2021 at 05:57, Janko Mihelić wrote: > I'm wondering how other mappers are solving this problem. The gtfs of my > public transport provider (Zagreb) has stops that have one gtfs:stop_id when > it is used as a middle stop in a rute, and a different gtfs:stop_id when it > is the last stop in a route. They have the same name, and there is only one > stop there in the real world. There aren't a lot of stops like this, but I'm > wondering how to tag those. Do I put a semicolon, gtfs:stop_id=158;1758, or > do I put in two stops, each with its own gtfs:stop_id? The first solution > with the semicolon sounds better to me, but I think it's better to solve this > the way everyone else solves it, so that future router makers don't have 100 > edge cases. Hello, I would not duplicate a stop node where there is only one physical stop in reality (one spot where buses stop, one bus stop sign, etc). I am not aware of an already-defined scheme for this particular case. But we should be able to invent a tag scheme that matches existing OSM norms. For example, a stop that is served by more than one operator and has different refs or IDs for each (or more generally given a ref by more than one entity) can be disambiguated by operator by adding keys like ref:ttc=2139 + ref:miway=9007. In this case we could do something like gtfs:stop_id=158 + gtfs:stop_id:exit_only=1758 (reusing the exit_only value from PTv2 schema), or postfix with the route number, so if the route passing the stop is 509 and the route ending at the stop is 343, use gtfs:stop_id:509=158 + gtfs:stop_id:343=1758... or gtfs:stop_id::=*. --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] station=tram in Berlin
Personally I wouldn't recommend this tagging (especially on the linked stop where service is no better than every 20 minutes), but the Berlin and German tagging community is large enough that IMO this is something they may well decide to do internally - so could also ask on a German list? --Jarek On Mon, 7 Dec 2020 at 11:10, Alexey Zakharenkov via Talk-transit wrote: > > Hello, mappers! > > I’ve noticed that some objects with > > railway=halt/station + station=tram > > tagging were created recently in Berlin. I know it's uncommon to tag tram > stops as railway stations. Overpass query > > [out:xml]; > nwr[station=tram]; > out geom; > > reveals only 109 such objects worldwide, half of which were created recently > in Berlin by two users. Typical example is the node > https://www.openstreetmap.org/node/8178939810/history#map=19/52.50528/13.61336 > > Please give your judgement about the situation. > > — > Best regards, > Alexey [ azakh-world ], > Maps.me team > ___ > 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] Talk-transit Digest, Vol 104, Issue 1
On Thu, 15 Oct 2020 at 18:58, Alex Dhawan wrote: > Would defiantly have to be a ballpark figure for any some of capacity metric. > Could maybe also do capacity:peak/offpeak or > capacity:morning/afternoon/evening/night? Not quite as elegant, but in OSM tagging scheme this could be `capacity:conditional=20 @ peak; 10 @ offpeak`. If hours could be specified or reasonably estimated, `capacity:conditional=20 @ (07:00-19:00); 10 @ (19:00-23:00)`. This would follow existing syntax from https://wiki.openstreetmap.org/wiki/Conditional_restrictions (If a route is always minibus you just need `capacity=10`) (To be honest I would suggest that if a route is sometimes minibus and sometimes bus, just map it as bus) ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Bus routes in Málaga: Should we add "stop_area" relations?
On Sat, 18 Jul 2020 at 13:17, Daniel Capilla wrote: > When we started mapping the bus routes in Málaga, Alan Grant and I came > to the conclusion that it was not necessary to add "stop_area" relations > due to the type of bus stops in Málaga, [2] where there are no actual > stop areas (only a stop position in the own road and a pole on the > sidewalk usually). > > Is that solution correct? Should we add "stop_area" relations at every > bus stop position? I would have to create a lot of additional relations, > only with the stop position and the platform features. I am not sure if > that would be reasonable/useful for any purpose. What do you think? > > [2] > https://wiki.openstreetmap.org/wiki/ES_talk:Rutas_de_bus_en_M%C3%A1laga#Uso_de_la_relaci.C3.B3n_.22stop_area.22 > (in Spanish) stop_area does not seem necessary for support in many popular OSM transit data consumers (OsmAnd and öpnvkarte/openbusmap come to mind). You probably don't have to add them unless something is really unclear without it. In particular it doesn't seem very necessary for simple cases like 2 stops on either side of the road. (It won't hurt, but it's not necessary.) Reading through (autotranslated) wiki discussion, it does make some sense that stop_area is more useful in areas where a number of physical halt points share one ref ID. If that's not the case for you, probably don't need to bother. --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Long bus routes
On Tue, 6 Aug 2019 at 06:23, Dave F via Talk-transit wrote: > On 06/08/2019 07:08, Janko Mihelić wrote: > > An app would route from one station to the other, and show status as if you > > were driving. There could be a tag that would say if the route goes through > > motorways, tolled roads, ferries and so on. That would help the app > > determine what would be the route. > > No, it wouldn't. That would just be guessing The currently mapped Flixbus routes are just guessing as well - buses can deviate as long as they make the scheduled stops. They don't usually deviate, because the mapped route is by far the fastest, and that's the point. --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Long bus routes
Fundamentally this isn't that different from long-distance train services. In practice, at least in Germany, Flixbus is one of very few bus operators that have 1) daily/weekly schedules and 2) tickets they sell to anyone (rather than a charter service). However I am aware elsewhere this might not be the case. Further, it might not actually be a problem in practice since most communities will probably not be as thorough in mapping intercity buses in OSM as the Germans ;) Suggestions that come to mind are: - not mapping the route highways for long-distance PTv2 routes and only including the stops (should still be usable for PT routing between stops); or - creating a sort of "meta-routes" for "buses along A13 between Dresden and Berlin" and "buses along A24 between Berlin and Hamburg" that would then be assembled into full routing by routes like Prague->Hamburg, Dresden->Warnemünde, or Dresden->Berlin (requires new software support, but then only one relation along the piece of A13). --Jarek On Fri, 2 Aug 2019 at 09:35, Janko Mihelić wrote: > > A user in Europe started adding long bus lines some time ago. These routes > are crossing several countries and mostly drive along motorways. Here is a > piece of motorway between Berlin and Dresden: > > https://www.openstreetmap.org/way/313980637 > > it has two road routes, and 13 Flixbus bus routes. I think this can't be > sustainable. If all bus companies started adding these routes, we could have > a hundred or more relations on motorway ways. > > Are there any recommendations about routes like this on the wiki? I think > they should be mapped as relations with only stations in the relation. > > What are your thoughts? > > Janko Mihelić > ___ > 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] Adding highway=bus_stop to nodes with public transport=platform bus=yes
On Tue, 28 May 2019 at 07:24, Mateusz Konieczny wrote: > In this bot edit: > > * Editing is limited to Poland > * Editing is limited to nodes with public_transport=platform bus=yes > * Nodes with nearby (within 250 meters) highway=bus_stop are ignored[1] > * Elements with highway tag are skipped > * To remaining highway=bus_stop is added This seems like a good plan. I would maybe suggest checking if the platform is a member in a stop_area and if that stop_area already includes a highway=bus_stop. But I don't know how widely stop_area has been used in Poland. > I just noticed during writing a post to this thread about this bot edit that > https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Document_and_discuss_your_plans > has > "and if your edit affects a specialist subject, such as oil rigs or public > transport > which has its own list then you should also discuss your plans on that > mailing list." > ... > PS What is the name of mailing list about oil rigs? I am unable to find it on > https://lists.openstreetmap.org/listinfo Presumably that should be "a specialist subject which has its own community such as a mailing list" or something. I guess you could ask the editor of https://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct=prev=1186355 and https://wiki.openstreetmap.org/w/index.php?title=Automated_Edits_code_of_conduct=next=1186548 I did see editors focused on drawing pipelines (though I wonder about verifiability sometimes) and there is a guideline for maritime stuff like seamarks so I guess there might be a sub-community interested in oil rigs somewhere. --Jarek ___ 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 Mon, 13 May 2019 at 11:49, Dave F via Talk-transit wrote: > If Philip really wants a router to tell him where the nearest > shelter (surely you can just look around you), You're joking?! The entire OpenStreetMap could be waved away with the phrase "surely you can just look around you". Why tag speed limits, just look as you're driving. Why map shorelines, just walk around til your feet get wet. Why map bus stops, just look around you. To give just one obvious counter-example: exact locations of shelters, in particular of bus stop shelters, could be very useful for those with visual disability (e.g. severe shortsightedness). --Jarek ___ 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 Mon, 13 May 2019 at 03:50, Snusmumriken wrote: > On Sun, 2019-05-12 at 20:55 +0200, Tijmen Stam wrote: > > It is not uncommon for key/values to be misnomers in OSM. Clearest > > example is private-access ways being tagged as highway=* (plus > > access=no) which is a misnomer in British English (which we use) > > Misnomers should clearly be avoided if at all possible. And here it is > quite possible, by calling a bus stop a bus stop. Calling a bus stop a bus stop is fine, but if we want to avoid misnomers, why is it under the "highway" category, along with expressways and speed bumps and toll gantries, and not a "public transport" category? ___ 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 Sun, 12 May 2019 at 09:57, Jarek Piórkowski wrote: > I can imagine calculating correct stop position being challenging in > case of multi-lane bus stations like > https://www.openstreetmap.org/way/37096072 (looks like > https://en.wikipedia.org/wiki/File:Islington_TTC_Bus_Barns.jpg in > reality) or https://www.openstreetmap.org/way/617387384. Follow-up: I've just re-read your other message where you mentioned that with correct relation tagging, you would take a projection of platform/bus_stop onto the nearest vehicle way which is in the route relation. In my experience the vehicle ways are included in route relations more often than the stop/platform details, so it seems fair to expect that if platform is mapped in detail, the routes using that platform will have ways also included in the route relations. Of course route relations are a bit prone to breaking, but so is detailed station mapping. A requirement would be having one direction per relation, otherwise vehicles going in opposite directions might still be mapped to an incorrect stop_position if 2+ trip directions pass through a station. The possible edge cases I'm coming up with (trips where a vehicle serves the same station twice _in one trip_ but on different platforms) seem like they'd be incredibly rare so I am alright ignoring them. So I would agree that a strong case can be made for stop_position not being necessary, provided we have a requirement that platform/bus_stop/equivalent is not on the vehicle way, and that we have only one trip direction in a route relation. --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Old railways
On Sun, 12 May 2019 at 07:54, Tijmen Stam wrote:
> In my environment, some people are adding old ("razed" railways to
> openstreetmak, of which no trace is visible in the field.
> It concerns both old railways which have been gone since 1933, e.g.
> https://www.openstreetmap.org/way/592259029 (Note that this piece still
> is somewhat visible, as it is now a road and partially a cycle path).
Hi Tijmen,
The "canonical" answer is that things that no longer exist in real
life and there is no trace of them do not belong in OpenStreetMap.
How strict you want to interpret this probably depends more on local
community consensus than on talk-transit guidance.
Tagging of removed railways that are now paths _in the same alignment_
seems relatively uncontroversial. https://osm.org/way/583243933 is an
example local to me. Your example of way 592259029 seems to me a bit
ambitious in that it traces alignment where it is no longer evident,
such as over houses, and https://osm.org/way/592259043 is a bridge
that no longer exists... I would not include this in OSM.
> Another example is a tram line in Amsterdam that has been gone for a
> year now , the area has
> been completely redeveloped, no trace of the old tram tracks remains.
IMO this should not be in OSM.
> I only recently found out about openrailwaymap, but I can't find much
> information about it. It seems it gets its data from the OSM database.
>
> Is there a way to store "razed" railways somewhere else, so they will
> show up on openrailwaymap but not on OSM (they are rendered on some
> renderers, e.g. OSMAND)
There does exist
https://wiki.openstreetmap.org/wiki/Open_Historical_Map which is a
separate database intended for things that used to exist but don't
anymore.
Although this would be technically and legally possible, I doubt that
OpenRailwayMap currently integrates data from OHM.
IMHO if they want to show historic railways they should also include
OHM data, to support not having undesirable data in OSM. But I realize
it'd be quite a lot of technical work.
> Funny anecdote: OSMAND showing abandoned railways has on one occasion
> led me to a detour because I thought I saw a footpath cross a canal
> where a razed railway has a very similar rendering.
Arguably this is a bug in OsmAnd - things that are explicitly tagged
as no longer existing should probably not be rendered by a
general-purpose renderer.
However this also depends on the tagging being correct - for instance
OSM-carto renders railway=disused (there is a clear sign of a railway
but it is no longer used) but not railway=razed (no railway exists) or
railway=abandoned (tagging seems inconsistent [1] so I guess they err
on side of not showing disused things).
--Jarek
[1] P.S. I just realized 3 months ago I tagged railway=abandoned on
stretches where there is no trace of track but its past presence can
be derived from track remaining on either end of the cleared stretch.
I currently find my past decision questionable, but I imagine there
was tagging guidance somewhere that made me choose this over
railway=razed.
___
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 Thu, 9 May 2019 at 17:04, Markus wrote: > Could you please give some examples where the stop position can't be > calculated from the waiting area? I'd also like to know for which use > cases the stop positions are necessary. I can imagine calculating correct stop position being challenging in case of multi-lane bus stations like https://www.openstreetmap.org/way/37096072 (looks like https://en.wikipedia.org/wiki/File:Islington_TTC_Bus_Barns.jpg in reality) or https://www.openstreetmap.org/way/617387384. In case of Islington the individual stops/platforms are currently not mapped, but if they were added, calculating the correct stopping position will also require the router knowing if traffic in the region is left hand or right hand - that is, on which side the buses have doors, and thus in which lane they will be. Then there is the weird case of https://en.wikipedia.org/wiki/Harvard_station#Harvard_Bus_Tunnel where buses run on the off-side, and some buses have doors on the off-sides for historical infrastructure reasons. Arguably the exact stopping position doesn't matter very much - does it matter if you show the bus route on the next lane, 3 m over? But it does complicate absolute correctness. --Jarek ___ 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
As far as I understood it, there are no practical pedestrian routing concerns with any of the currently used schemes for pedestrian+PT routing/directions. If this is incorrect can someone provide a specific example? On Tue, 7 May 2019 at 16:18, john whelan wrote: > > So if we connect a bus_stop to a highway with a path would that address the > routing concerns? Or is that idea too simple? > > Thanks John > > On Tue, May 7, 2019, 3:53 PM Jarek Piórkowski, wrote: >> >> Sorry, crossed my wires while editing at one point: >> >> > 9a. Because we must retain hw=bus_stop per #3 and #5, any >> > accommodation of these cases must either be initially of tags, or >> > guidance on how to place highway=bus_stop tags >> >> make that: >> >> 9a. Because we must retain hw=bus_stop per #3 and #5, any >> accommodation of these cases must either be new tags, or guidance on >> how to place highway=bus_stop tags >> >> And just to be clear: >> >> > 11b. stop_area is currently mentioned but not recommended in the wiki [2] >> >> make that: >> >> 11b. stop_area is currently mentioned, but not specified as required, >> in the wiki [2] >> >> ___ >> 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 ___ 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
Sorry, crossed my wires while editing at one point: > 9a. Because we must retain hw=bus_stop per #3 and #5, any > accommodation of these cases must either be initially of tags, or > guidance on how to place highway=bus_stop tags make that: 9a. Because we must retain hw=bus_stop per #3 and #5, any accommodation of these cases must either be new tags, or guidance on how to place highway=bus_stop tags And just to be clear: > 11b. stop_area is currently mentioned but not recommended in the wiki [2] make that: 11b. stop_area is currently mentioned, but not specified as required, in the wiki [2] ___ 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
Hi all,
I wrote some point-form notes of the discussion so far for people to
refer or respond to. I asked questions in 7a, 7c, 8c, 10c, 11c, 13b,
14.
1. Majority of world's public transit is buses
2. Majority of world's bus stops are simple signs (or sometimes no
signs at all) and will never [1] have a designated "platform"
structure
3. Many editors feel that highway=bus_stop is sufficient tagging for these
4. We should also support other transit modes which may more often
have more details
5. Proposals that suggest to change existing widely-used tags such as
highway=bus_stop for semantic reasons are unlikely to succeed
6. I am unaware of any successful proposal which successfully rolled
back a previously accepted proposal. To those disliking PTv2 I suggest
either ignoring it, or adapting it into a PTv3 keeping in mind the
issues it tried to address, some of which are below.
7. For public transit routing, it appears that having highway_bus_stop
nodes ("locations where people wait for buses") arranged in order in a
relation is sufficient, per the comments about OsmAnd in Stockholm
7a. Correct me if I'm wrong but I haven't read a lot of opposition to
this "Stockholm-like" lightweight route/route_master relation scheme
7b. This bus stop node does not have to be placed on the way that
buses travel on
7c. From what I'm understand, this bus stop node does not have to be
connected to a pedestrian highway either, with routers presumably
jumping from the nearest highway?
8. A stop_location (to use ptv2 terminology) on the way that vehicles
travel on could help with things like calculating and showing the
likely route the bus will take, but this can also be calculated
without the stop_location node by projection of other stop objects
onto the way
8a. stop_location is specified as optional in current wiki description
of PTv2 [2]
8b. Stephen initially said "we need stop positions so routers can get
people from stop to stop on the buses/trains"; a subsequent message at
06 May 2019 13:53:10 -0500 (if I understood correctly) said that
stop_position can be optional in cases of simple geometry (which is
presumably vast majority of them)
8c. What changes would people like to make? Clearer guidance as to
when stop_position and stop_area might be needed for buses - in cases
like ambiguous geometry due to multiple parallel highways? Or would
people prefer to ignore routing of buses between stops and advocate
for removal of stop_positions in all cases?
9. There are some cases that do not cleanly fit into hw=bus_stop
"PTv1" tagging, for example a sign-only stop served by both buses and
trams, or a waiting platform served by both buses and trams
9a. Because we must retain hw=bus_stop per #3 and #5, any
accommodation of these cases must either be initially of tags, or
guidance on how to place highway=bus_stop tags
10. Meaning of public_transit=platform tag is dependent on context, it
unifies/duplicates some existing tags, arguably it sometimes describes
imaginary things, and it is disliked by many editors
10a. Some of the dislike is due to disagreements as to what "platform" means
10b. Please remember that OSM's British English naming conventions are
in a foreign language or dialect to vast majority of editors
10c. public_transit=platform does not appear to be needed for walk+PT
routing. It could be replaced with bus_stop, tram_stop,
railway=platform, highway=platform as appropriate. Please correct if
I'm wrong.
11. stop_area is disliked by many editors as being pointless in
majority of cases involving surface transit
11a. stop_area relation was recommended by the OsmAnd blog post
introducing their public transit support, but evidently OsmAnd works
without it in Stockholm
11b. stop_area is currently mentioned but not recommended in the wiki [2]
11c. Would anyone like to see changes here? Should we explicitly
*discourage* stop_area except where needed, and what would be the
criteria for needing it? [3]
12. Many of the currently mapped tram systems have a railway=tram_stop
+ public_transport=stop_position node on the rail, so we should
probably not change this scheme either without good reason
13. There is currently no clear way for tagging stops that also have
physical platforms, except for PTv2
13a. This exists as physical feature in real world and should be
supported, in a manner compatible with platform-less stops
13b. Should we add bus_stop/tram_stop on one of the nodes of the
platform way [4]? Next to the platform? As pointed out by Markus, we
can't do what might be the most intuitive method of the platform
way/area sharing bus_stop tag because the platform is also a highway=
tag.
14. Discussion hasn't really touched much on railways or subways.
Should we take this to mean that people are generally happy with PTv2
tagging on those? If we change the guidance for surface transport,
PTv2 for subways doesn't necessarily have to change.
[1] Or at least not in the timeframe we should concern ourselves with.
As mentioned
Re: [Talk-transit] Ideas for a simplified public transportation scheme
On Sun, 28 Apr 2019 at 10:04, Markus wrote: > I've tested the bus routes from Stockholm in OsmAnd. They seem to work > perfectly despite not having any public_transport=platform tags and > public_transport=stop_position nodes. Oh cool - with routing and time estimates and all? > Tram stops often have platforms (and bus stops sometimes too). For > such stops, two PTv1 elements are necessary because railway=tram_stop > can't be used on the same area (or way) as railway=platform (they use > the same key). With a new tag for stops (such as the suggested > public_transport=stop tag) or a new tag for platforms, this were > possible. However, much retagging were needed. Alternatively, > railway=tram_stop (or highway=bus_stop) could be placed on the > platform area (first suggested solution). In some cases I've seen (https://osm.org/way/395511322 comes to mind), the duplicate tagging when platforms are present is handled by having hw=bus_stop tag on one of the nodes of the platform way, and then the platform way has hw=platform (pt=platform in this case but it would work with hw=platform as well). That helps to compute "these are part of one logical stop" without needing a relation. My other observation is that perhaps the relatively relation-rich PTv2 came around in years when relations were cool and a solution to everything. I haven't been around OSM much, but reading through some historical conversations I get the sense that there's been a bit of a swing back with many people now disliking relations for things that are geographically close (and thus computable as belonging together). Does this perhaps explain the stop_area origin and why it currently seems not as useful? Thanks, --Jarek ___ 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 Sat, 27 Apr 2019 at 10:35, Jarek Piórkowski wrote: > ... it might make sense to check what they absolutely need and > what is a nice to have. Do we know of any other major consumers of > public transit relations? Responding to myself, I remembered that of course Maps.me also does offline routing on subway/LRT/city rail. As I understand the supported systems are those in http://osmz.ru/subways/ I would guess those systems are a little better mapped than bus routes, but would be good to hear what the Maps.me router requires: stop_positions? platforms? Going by the YAML files and validator messages on the site above, perhaps it is only railway=station and their entrances. --Jarek ___ 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
Hi all,
I noticed that OsmAnd has recently introduced support for some public
transit routing: https://osmand.net/blog/guideline-pt . Has anyone
used it or is familiar with the implementation? I would guess it would
make them one of the bigger consumers of public transit relations in
OSM and it might make sense to check what they absolutely need and
what is a nice to have. Do we know of any other major consumers of
public transit relations?
For example, do consumers need the ways to always connect for
routing/time calculation, or is it only for display on map? If it is
the latter, it makes relations breaking due to way splits less
crucial.
Here's my point of view as a mapper who is interested in adding
transit and having the information suitable for basic offline transit
routing. Note that I've mostly done surface routes so far, and don't
have a good sense of how PTv1/PTv2 works for underground.
- Standard PTv1 not supporting directions makes it not very useful
except for visual inspection by a human and as a way of keeping track
of stops as base for upgrade to machine-readable PTv2
- My understanding of
https://wiki.openstreetmap.org/wiki/Public_transport is that
stop_position is optional ("If you choose to add a stop position
node..."). If it is in fact optional for data consumers as well
(OsmAnd?), it could be skipped when it would be too much effort.
- I am personally not that bothered by "platform" for PTv2 - as a
speaker of non-British English I am used to some terms in OSM not
meaning what I use them to mean. I am a;sp not bothered by bus=yes on
platform (IMO pretty clear from context and comparable to "emergency"
tag) but I see from talk page for the [1] proposal that Zverik isn't a
fan.
- Regarding Markus's suggestion #3 for introducing
public_transport=stop, wouldn't it be simpler to redefine
highway=bus_stop / railway=tram_stop to mean the same thing? It might
be simpler to redefine public transport relations to allow use of
hw=bus_stop / rw=tram_stop for waiting area at stops that don't have a
defined platform - and that many data consumers already use them is a
plus. As far as I can tell this is basically what the Stockholm
example linked does, isn't it? I don't know the history of
introduction of PTv2 so perhaps I'm missing some disadvantages of
hw=bus_stop tagging.
Thanks,
--Jarek
On Fri, 26 Apr 2019 at 11:11, Markus wrote:
>
> Hi all,
>
> I've added, updated and corrected several dozen public transportation
> routes in the past few years using the PTv2 scheme. As is the case
> with most route relations, they often break (e.g., because the course
> of a road or rails is modified, a new roundabout is built, a stop is
> displaced or simply by accident). However, with all the stop_positions
> and stop_areas, maintaining these routes and stops is very much
> time-consuming.
>
> There have been several ideas to simplify and improve public
> transportation mapping (e.g. [1] or [2]), however they either faced
> too much opposition or are inactive. Therefore I've worked out three
> different drafts for an improved public transportation scheme and
> would like your opinion. After that, i plan to write a full proposal
> for the option that got the most support.
>
> In order to better understand how I came up with the ideas below, I
> have first listed the deficiencies of the current public transport
> schemes:
>
> Deficiencies of PTv1:
>
> * No separate route relation per direction and route variant.
> * Platforms at stations cannot be added to route relations, which
> prevents a better routing.
> * Stops (highway=bus_stop/railway=tram_stop) are often placed on the
> road or rail, which is not optimal for routing.
>
> Deficiencies of PTv2:
>
> * public_transport=stop_position and public_transport=stop_area make
> mapping and maintaining complicated and time-consuming. Besides,
> public_transport=stop_position is unnecessary, as it can be calculated
> from public_transport=platform (which provide a more exact routing).
> * Counter-intuitive public_transport=platform: its meaning depends
> on whether used on way/area (where it means a platform) or on node
> (where it means a waiting area w/o platform).
> * Not possible to add transport mode tags (e.g. bus=yes) on
> public_transport=platform because they are also used to set access.
>
> Now for the possible solutions:
>
> 1. Sticking to PTv1 tags, but with separate route relations per
> direction/variant and by placing stops at the point where passengers
> wait. A stop with a platform get a railway/highway=platform way/area
> and a railway=tram_stop/highway=bus_stop node. (Except at stations, a
> stop_area relation is not required because the stop node is placed on
> the platform.) -- Advantage: Widely used tags, least retagging
> required. Disadvantage: A stop with a platform needs two elements (as
> railway/highway=platform + railway=tram_stop/highway=bus_stop can't be
> combined).
>
> 2. Sticking to PTv2 tags, but abandoning
Re: [Talk-transit] Defining service on railway=tram
On Sun, 10 Mar 2019 at 17:28, Markus wrote: > I still find service=siding to be inappropriate for irregular tracks > and would prefer a new tag, such as usage=irregular. I am willing to > prepare a proposal for it as soon as i find some time. No worries, I agree a dedicated tag with proper values would be great to have once a proposal makes its way through the process. Were you thinking of also integrating light rail in this, or keeping it limited to trams for now? Thanks, --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Defining service on railway=tram
On Mon, 11 Feb 2019 at 11:33, Jarek Piórkowski wrote: > In tram systems, some of the tracks might not be used regularly for > passenger service. Some might be garage or work area tracks, and > others might be used only for detours or emergency service. > ... > Please see > https://wiki.openstreetmap.org/wiki/User:Jarek_Pi%C3%B3rkowski/Key:service > for the suggested addition and > https://lists.openstreetmap.org/pipermail/tagging/2019-January/042313.html > for more background including a survey of existing tagging. Hello, In the spirit of being bold and keeping things relatively uncomplicated, I have changed Key:service to add suggested interpretations of railway service values for tram tracks: https://wiki.openstreetmap.org/w/index.php?title=Key:service=prev=1820049 Please feel free to revert this change if you strongly disagree, and comment if you have ideas. Thanks, --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Defining service on railway=tram
On Sun, 17 Feb 2019 at 13:43, Stephen Sprunk wrote:
>
> 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.
Hi Stephen,
The problem I was initially trying to solve initially was lack of
definition or standardization. Similar types of tram track
("non-revenue", "auxillary", "irregular" - as you wish to call them)
are being tagged inconsistently as service=spur, service=siding, or
service=yard, even within the same city, because a standard was never
suggested.
I wanted to tag some non-revenue track and there wasn't a
specification of how it should be tagged. As I wrote in the initial
message to tagging list, on-ground difference might be that standing
street-side, on regular track one might see a tram go by every 5
minutes, whereas on non-revenue trackage at least hours and possibly
days might go by between trams. Relations can indicate this, but
service tag was already used and rendered - just not used
consistently.
It is true that usage is a more correct word for this, but in looking
at several dozen cities I saw hardly any tram track currently tagged
with usage. If making a new tag/value, using usage might be a good
idea.
thanks,
--Jarek
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Defining service on railway=tram
On Sun, 17 Feb 2019 at 10:55, Markus wrote:
> detour seems a bit unsuitable for turn tracks or connections because afaik it
> implies a longer route, but the tracks i have in mind are rather shortcuts.
> Maybe deviation doesn't have this meaning?
Right, I withdraw the detour suggestion. Irregular is still best so far I think.
> But don't you also want to include tracks that are only used for drives to
> the depot? If so, auxiliary/irregular/secondary seems like a better fit
> anyway.
Tracks that are only used for drives to depot would have service=yard
in my mind.
>> I chose "siding" because I didn't want to invent new tag value, to
>> avoid too big and slow of a change. But maybe we should do it, what do
>> you think?
>
> Imo if a tag or key doesn't fit it's better to invent a new. It would be nice
> though to hear opinions from other mappers.
>
> Besides, are you sure that siding tracks for trams similar to those for
> trains don't exist somewhere? If they exist and we use service=siding for
> auxiliary tracks, there won't be a distinction anymore (or a new tag would
> have to be invented for real tram siding tracks).
Honestly - I've looked through many of the systems and there isn't
much that functions like a real siding in railway sense. Wiki
describes railway siding as "These tracks are used by slower trains to
be overtaken or to let passengers enter/leave the train if the main
tracks do not have platforms." which doesn't really apply on tram
systems I've seen. The wiki even notes "These tracks might be hard to
differ from the main tracks in some cases." ... if unsure, we could
just leave the tracks with no service.
The closest thing that comes to mind for tram sidings are tracks for
parking or bypassing trams that aren't being used right now, usually
near route termini (e.g. https://osm.org/way/46140380,
https://osm.org/way/69049487). But I've tried to come up with a
description of these that wouldn't also include other tracks not used
in regular service, and was unable to do so. I am leaning towards
deciding it's not really worth drawing the distinction where it's
difficult to actually articulate one. I was able to explain
non-revenue/irregular, yard, and crossover; I don't know if I can
define more categories well.
Regarding input from other mappers, I have also gotten a response from
User:Tigerfell on the wiki at
https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dtram#service.3D.2A_for_tram
- maybe that gives you more ideas.
While we think some more, I might try to look into what the current
tagging is on light rail systems (in the Porto Metro sense, not the
Berlin S-Bahn sense...) to see if it makes sense to include them in a
proposal together with trams, what with trams and light rail forming a
kind of a continuum ("Service classes on street-crossing passenger
rail transport networks"?).
Thanks,
--Jarek
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Defining service on railway=tram
On Sat, 16 Feb 2019 at 11:39, Markus wrote: > > Hi Jarek, > > I'd welcome a tag for tram tracks that normally aren't used except for > diversions (in case of breakdowns, accidents, road/track works, events etc.) > or for drives to the depot. However, i'm unsure whether service=siding is a > good fit for these tracks. I'm not an expert in trams/trains, but wouldn't > service=spur fit better? Otherwise it might make sense to invent a new tag, > maybe service=irregular/auxillary/minor/secondary? Hi Markus, Thanks for your input. I agree with you that "siding" is not a good description, but it seemed the least-wrong one of the 4 railway values in use. "Spur" to me sounds like something that branches off and ends (as illustrated for railways). Meanwhile with service=siding I am looking for a description for tracks that connect two stretches of regular tracks. I do like your suggestions - "irregular" should be clear enough, and I like "auxillary" as well except I don't know if its meaning is commonly-enough understood. "Minor" seems like it could be misunderstood: if you have two lines, one of which runs more frequently than the other, are the tracks of the less-frequent line "minor"? Or how about service=detour? I chose "siding" because I didn't want to invent new tag value, to avoid too big and slow of a change. But maybe we should do it, what do you think? Existing values are used: - in editor presets, including iD and JOSM presets for tram tracks - both have "Spur", "Yard", "Siding", and "Crossover" in a dropdown for tram tracks, so matching the railway ones. Arguably it would be good to update those values for tram anyway, e.g. if we were to recommend that "spur" not be used on trams - in rendering: default layer hardcodes 3 current values for tram service (excluding crossover) - though if I'm understanding it right, it should be easy enough to change in https://github.com/gravitystorm/openstreetmap-carto/blob/dd096af4f566eb9c31e50ac447215f68e45b563f/project.mml#L514 - transport layer seems to render service=siding thinner, but presumably also updateable; openrailwaymap doesn't seem to render tram service tags in a special way so no problem there Or how about if we were recommend that of the current options, siding should be used (to attempt to standardize what we have); and in parallel launch a formal proposal process for adding more proper tram service=irregular? Thanks again, --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Defining service on railway=tram
Hello, In tram systems, some of the tracks might not be used regularly for passenger service. Some might be garage or work area tracks, and others might be used only for detours or emergency service. The `service` key seems a natural match for tagging this, but its values specified for railways aren't a close fit for trams (a railway "yard" is somewhat different from a tram "yard", trams rarely have "spurs", etc) and tram-specific values were never defined. I have looked into various values currently used in tagging systems around the world and would like to suggest tram-specific guidelines to add to Key:service on wiki. Please see https://wiki.openstreetmap.org/wiki/User:Jarek_Pi%C3%B3rkowski/Key:service for the suggested addition and https://lists.openstreetmap.org/pipermail/tagging/2019-January/042313.html for more background including a survey of existing tagging. Any thoughts are welcome, in particular if someone has an opinion on whether this warrants a formal proposal process. Thanks, --Jarek ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
