Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Line Diagram. Stops are shown twice. #190
Maybe around https://github.com/drolbr/Overpass-API/blob/master/src/pt_diagrams/processed_input.cc#L354, you can process input to just select the nodes which are in the relation with the tag "stop" ?
I belief that the problem lies within
A fix could be to ignore the stop if its tagged on a platform. My best guess is that one would need to change Line 739 from
This would leave a gab if there is a node with "highway=bus_stop" + "pt=platform" but no node with "pt=stop_position". But that is IMHO more acceptable because it would result in a missing stop due to incomplete data.
Here is a patch which may provide better results (hope so) :
Rationale : I assume the relation is written either in PTv1 style or in PTv2 style.
This algorithm will break in two cases :
But it does solve the problem of double display, and helps to " not mapping for render "
This is not a problem of "mapping for render" but preserving compatibility where there are tags preserving v1 compatiblity even if there are also v2 tags for newer agents that are PTv2 aware.
So there will remain v1 stops still referenced by both v1 and v2 relations (for different lines not built compeltely at the same time with the same schema, but sharing the same stops): these v1 stops (bus_stop) are normally nodes beside the highway route and usually are given the v2 role "platform", but there are also cases where the v1 stops are nodes on the highway itself and given the v2 role "stop": this mixed case occurs because its difficult to migrate all lines at the same time from v1 to v2 including all the stops they may (and will frequently) share.
Yes a v1 relation should look for v1 nodes members only (with role "stop" only) which may thermselves have both a v1 tag (like highway=bus_stop) and v2 tag (public_transport=stop+others)
And yes a v2 relations should look for v2 nodes/ways/relations members (with roles "stop" or "platform" and their suffixed variants) which may also have both a v1 tag and a v2 tag...
What is essentially different between v1 and v2 is not these stops of platforms, but the fact that v2 routes (way members with empty/forward/backward roles) are normally not creating a bidirectional loop like in v1 but these routes are grouped in a route_master relation containing the various variants and directions.
But not also that forward/backward roles are still needed in v2 (single direction) because of tricky cases like lines that perform a local loop and return back by the same way they used before
(note that I have not figured any stop/platform here, only the route effectively followed, along which there will be stops. These 2 cases is independant of the v1 or v2 schema used.
Using the roles "backward" and "forward" still allow reconstructing the complete route even when ways are not ordered (e.g. editing with iD), and then to know when stops/platforms may be reached along the route. Without these roles for route members, neither v1 or v2 will be abel to solve the problem, and you don''t know in which order the stops/platforms will be reached, and the addition on them of "entry_only" or "exit_only" is also insufficient to reply correctly.
Finally note that there exists routes that perform a circular travel: the start and end nodes of route member ways (when you reorder them correctly with the forward/backward roles which is easy in v2 but difficult in v1) are the same, and it is normally located near the first and last stop/platforms, which may be the same (no entry_only/exit_only) or different (but also they may not be restricted to entry_only/exit-only: people may remain in the bus to continue on the next loop circuit after its designated "terminus").
In summary, we need the coexistence of v1 and v2, even if v2 is more powerful and allows better disambiguation and more efficient automation (in v2 you can effectively know which stops will be deserved along the route, something impossible in v1 which mixes different services of the same "line" in a complex graph difficult to orient)
note also that even with v2, the case of circular loops does not allow to easily determine the direction of the line if nodes are unordered (as produced by the iD editor which does not preserve the order when editing).
Specifying a start node and end node on the route is not enough, you need to specify 3 nodes: one node should be the terminus, but you need two other nodes not located at the terminus (at start and end of the route) to specify the direction correctly. These three nodes may be chosen arbitrarily along the circular route and in fact do not need to be stop positions.
When there's a local loop (figures above) you need to specify the nodes of convergence/divergences and at least two nodes on that loop. But even in that case, nodes for stop positions will not say if it is used to service the platform on one side or the other (along the common part of the route taken twice). The only way is to append a numeric suffix (:1, :2, the exact value does not matter, only their relative numeric order...) to specify the exact order of platforms desserved. If you don't want that, then the routes with local loops/branches will need to be split in several unidirectional parts and you'll need to have a v2 "route" whose members are "route_section" relations.
Note that route_sections are also needing for tagging properties such as tarifings/zoning, or change of operator or responsible public network (e.g. in France we have RER train routes operated partly by SNCF or by RATP, and tarifing sections by "zone"; zoning also occurs on long distance lines where they go from one city (managed by a given local authority) to another (managed independantly by another authority, both authorities sharing the costs of exploitation, but allowing a section of the line to be used with their own tickets or subscriptions, and other sections requiring the purchase of additional tickets to the operator of the line)
So I we could expect new member types in v2 "route" relations to solve the last remaining problems, and "route section" relations would be useful to really indicate specific tagging for part of the roujte or solve geometric problems such as local branches and loops, or circular routes could be split in at least two sections with a clear direction.
But even with route sections (defined the same way as existing "route" relations, except that they cannot have any subdivision again in subsections), we need to number them to reconnect them correctly if their start (or end) node has more than 2 sections connected to them (starting or ending on that node). The role for including them in a "route" relation should be "section:1", "section:2"... (the value of the suffix does not matter, only their relative order, and the given indices should all be distinct and comparable as "lower than" or "greater than").
To avoid this numbering, the simplest way is to avoid splitting sections at their nodes of convergence/divergence, and allow distinct sections to have common ways. For example the route:
can be represented as these two sections:
because you know the order followed if you specify the node starting the first section as being the start of the route.
But this trick will not work with circular route where you need to specify 3 distinct ordered nodes to determine the direction (with roles "from", "via1", "via2", given that the "to" node is generally the same as "from"). Note that these roles for ordered nodes does not mean they are necessarily stop positions with associated platforms.
In all cases
With these definitions (based on the addition of sections), we can now represent all routes, and we are no longer restricted to maintain a specific order for any members in any relation, and we facilitate the work in editors that won't need to worry about that when we split ways, or modify them locally, without even knowing anything about the current PT schema requirements (which are difficult to maintain and frequently broken): all relations within this schemes are unordered, only some roles are used to order sections when needed. We have all what is needed to manage zoning for travel prices/subscriptions, because sections can have their own tags (including dedicated names, operators, or change of accessibility tags, or changes of vehicle capacity for trains where some wagons will stay in the station and passengers must go to the remaining wagons).
Finally a "route" can contain a mix of:
All these tricky cases have been currently ignored in the current PTv2 specs, this will require documentation. As they are needed in the cases the PTv2 schema does not work, there's no compatibility problem, it can remain in version 2 as a simple extension for these complex cases which are otherwise not representable, but a version 3 would focus on saying that the PTv3 schema no longer requires any strict ordering of members in "route" relations (no longer needed because PTv3 would necessarily support these sections), with PTv3 also adding the restriction: never twice the same member with the same role (and never twice the same member if "from", "via1" and "via2" nodes are distinct from stop positions, but just any nodes along the route which don't need any specific tagging). PTv3 would also deprecate the tags "from=name", "to=name" and "via=name" from routes (no longer needed at all, replaced by node members, and generally only one node member with role "from" for non-circular routes).
For rendering the routes in Overpass-API, the "from=name", "to=name" and "via=name" are also not needed: Overpass can infer them by following each route in the correct order and find all the effective stop positions through which the route goes, including the first and last one, and then taking the names of these stop positions (if not found there, the name of the associated "stop_area" relation, otherwise the name of the nearest "platform").