Aun existen problemas al mapear elemento de transporte publico... markus pregunta si se puede mejorar las etiquetas...
Abrazos, Marco Antonio On Fri, 26 Apr 2019 at 15:11, Markus <selfishseaho...@gmail.com> 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 > public_transport=stop_position and introducing a new transport_mode=* > tag. -- Advantage: Only one element per stop. Disadvantage: The rather > counter-intuitive public_transport=platform remains. > > 3. Abolishing public_transport=stop_position and > public_transport=platform and introducing a new public_transport=stop > tag (node/way/area) for the waiting area at stops, which can be > combined with railway/highway=platform if the stop consists of a > platform. Besides, introducing a new transport_mode=* tag. -- > Advantage: Only one element per stop, very flexible and clear. > Disadvantage: Much retagging required. > > [1]: > https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations > [2]: > https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport > > Thanks in advance for your replies. > > Best regards > > Markus > > _______________________________________________ > 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
