Ja, just det, här är den:
https://wiki.openstreetmap.org/wiki/Sweden/Public_transport#Taggningsexempel_busshållplats
Under rubriken “Hur skall vi tagga nu?”
Citat:
“Dock så använder vi viss dubbeltaggning, dessa är: public_transport=stop_position ==> får även highway=bus_stop eller railway=tram_stop etc.”
Detta har varit ett lyckokast. Fastän jag tror personligen inte att det har varit syftet eller ens avsett.
Det är alltså bara att jämföra:
Exempel 1.)
Hållplats “Herrenwasser” (OpenStreetMap)
Taggning så som föreslås highway=bus_stop vid sidan om vägen tillsammans med pt_platform.
Vad det är frågan om är en smygövergång till Ptv1-modellen.
Jag vill påstå att det för karttittaren eller datakonsumenten inte är särskilt attraktivt. Hållplats framgår ungefärligen. Hållplatskartor kan man inte göra här.
Exempel 2.)
Hållplats “Kalkwitz Teiche” (OpenStreetMap)
Likadan taggning som Ptv2 i Sverige! Dvs pt_stop_position+highway=bus_stop samt pt_platform+highway=platform.
Här framgår det tydligt (ok, man valde node istf way för hållplatsserna) var bussen stannar och var hållplatsen är: overpass turbo
Vilket är att föredra: modellen där karttittaren och datakonsumenten får ut mest möjliga information (Exempel 2), eller någon modell som inte medför detta, men som i annat avseende är best lämpad (import?) (Exempel 1)?
Vad det frågan om är rätt enkelt. I en hållplats-moell som följer Ptv2 så “flyttar vi ut” highway=bus_stop till pt=platform.
Och i nästa steg så är argumentationen “vad skall vi till med pt-taggarna på hållplatsen, vi slopar dem, de gör ändå ingen nytta”.
Och wuppsi har vi hållplatsser enl Ptv1 i stället för ursprungliga Ptv2-hållplatser.
Dvs en smygande omvandling till Ptv1-modellen.
Men tyst! Det skall du inte få veta i det här skedet!
En mycket tänkvärd fundering.
gtfs:-taggarna, t ex “gtfs:stop_id” skall efter samtliga tillängliga osm-wiki sidor taggas tillsammans med public_transport-taggar. Jag hittar trots ivrigt letande inte någon wiki-sida som i detta sammanhang gör en koppling till highway=bus_stop eller highway=platform.
Detta är ju helt följdriktigt, eftersom Ptv1-modellen (med highway=bus_stop-taggar) är högst rudimentär i jämförelsen med Ptv2-modellen.
wiki-sidor:
Nu har vi fått en fil som innehåller gtfs:stop_id-data för samtliga hållplatser i Sverige. Den har beretts i Norge… Och den innehåller endast highway=bus_stop för respektive gtfs:stop_id-tagg (alltså en “pairing” highway=bus_stop och gtfs:stop_id).
Jag har kollat lite i tyskland vad gäller gtfs:-taggar och kan där inte hitta någon som helst “pairing” highway=bus_stop och gtfs:stop_id-tagg. Den rådata med gtfs:-taggar från respektive institution innehåller ingen hänvisning till vare sig public_transport eller highway=bus_stop, dvs Ptv1 eller Ptv2. Vilket ju närmast är självklart. Vad bryr de sig om osm och deras taggningsscheman?
Som sagt, överallt där man tittar, där det informeras om gtfs:stop_id och osm, sker detta i sammanhang med public_transport-schemat (=Ptv2). Men det är kanske jag som inte hittat något i den vägen.
Med bakgrund av ovan så hade jag ju antagit att import-filen hade innehållit en pairing public_transport=stop_position och gtfs:stop_id.
Det verkar vara någon som gör nudging åt ett visst håll. Vem kan det vara?
Väldigt kul med alla insinueringar, men vad har GTFS med OSM-tagging att göra? Detta är data från Samtrafiken som visar påstigningspunkter i Sverige och det är deras ID och positioner som kommer fram i filen, som de i sin tur har fått från transportbolagen. GTFS är bara ett format som datan sparas i.
Filen kan användas på det sätt användaren finner bäst för egna behov.
Inga insinueringar, utan ett konstaterande att import-filen utformats till att passa endast Ptv1-modellen. Rådatan kommer från Samtrafiken och filen har beretts i Norge så att det passar Ptv1-modellen … Idel fakta.
Filen har “tillverkats” av en norsk user. Korrekt?
I filen görs kopplingen gtfs:stop_id ↔ highway=bus_stop. Korrekt?
I filen görs INTE kopplingen gtfs:stop_id ↔ public_transport=stop_position. Korrekt?
Rimlig slutsats:
eller
Men vi tackar i alla fall för det mycket storsinta erbjudandet att vi får använda filen (anpassat för Ptv1) hur vi önskar!
This thread seem to drift into a monologue of conspiracies and exotic wiki interpretations.
But to stick to the substance: stop_id’s in GTFS refers to the bus stop (platform), not to the stop position.
According to the gtfs.org reference:
For stops/platforms […], the coordinates must be the ones of the bus pole — if exists — and otherwise of where the travelers are boarding the vehicle (on the sidewalk or the platform, and not on the roadway or the track where the vehicle stops).
According to taginfo, 81% of gtfs:stop_id=* are tagged highway=bus_stop, as well as 90-98% of the other alternative gtfs tags.
All the coordinates in the Swedish GTFS3 feed and used by bus routes refers to bus stops on the side of the highway. These coordinates are used in the file.
The same is true for the Swedish Netex feed and for the public Swedish stop register.
From my experience with many GTFS data sets: GTFS-stops are defined as being located besides the street, not on the street.
So, using PTv2 terms, public_transport=platform should be seen as a valid equivalent to GTFS-stop.
I do not want to make a statement here pro/con hw=bus_stop and where to place that, but want to mention that the note in the OSM-wiki “highway=bus_stop should be placed besides the road” is much, much younger than the original page about highway=bus_stop. In the beginning it was not defined where to place that.
I personally see highway=bus_stop as a legacy key/value pair just to have an icon on the Carto-map, because Carto does not care about public_transport=* (PTv2). And I personally see highway=bus_stop being linked to public_transport=platform.
Just my 2 €-ct
Ok, bra att veta. Coordinaterna anger gtfs:stop_id vid sidan om vägen, där enl Ptv2 platform ligger. Då skall pt=platform ha gtfs:stop_id-taggen.
En annan sak är att den svenska osm-wiki helt tydligt anger att pt=stop_position skall taggas tillsammans med highway=bus_stop, eller rättare tvärtom.
De flesta förespråkare för Ptv2-modellen är medvetna om att highway-taggningen på Ptv2 endast är provisoriskt i avvaktan på att Ptv2-taggarna renderas (detta sägs även uttryckligen i den svenska wiki-sidan.
Sedan kan det vara en personlig åsikt att highway=bus_stop-taggen bör “pairas” med den ena eller andra public_transport-taggen.
Faktum är dock att vi har taggat våra Ptv2-modell hållplatser enl den svenska wiki-sidan.
Jag har påvisat (med hjälp av overpass) att detta även ger ett bättre resultat än om vi hade satt highway=bus_stop på public_transport=platform (hållplatskartor!).
Jag har famhållit denna aspekt gång på gång och har inte fått någon motsägelse i denna del.
Så med tanke på att highway-taggarna på public_transport anses provisoriska och i bästa fall kan komma att kunna slopas helt, bara renderingen för pt kommer, så är det att föredra att den kombination av taggar (som i den svenska wiki-sidan förespråkas) bibehålls när den nu ändå finns och ger bättre result.
Sammafattning:
de svenska Ptv2-hållplatserna har upprättats helt i enlighet med en svensk wiki-sida. @NKA det är bara att ta fram läsglasögonen.
de svenska Ptv2-hållplatserna ger ett bättre resultat (hållplatskartor!).
vid ett val mellan:
a. att följa den svenska-wiki-sidan,
b. det faktiska utfallet, resultatet
c. personliga preferenser
bör det självklara valet vara:
3a. och 3b.
Dvs så som dern svenska-wiki-sidan anger pt=stop_position tillsammans med highway=bus_stop.
Så länge plattformerna sitter ihop med (gång)vägnätet kan resten av hållplatsen se ut hur som helst för min del.
Jag tänkte svara när diskussionen var aktiv, men antalet inlägg och rundgång i diskussionen ledde till utmattning och en allt högre vägg av motstridiga påståenden att bemöta. Efter att på nytt ha läst hela konversationen från början till slut måste jag hålla med NKA om att dina inlägg delvis framstår som konspirationsteorier och insinueringar, men nog om det, för det är inte produktivt att diskutera vidare. Jag ska försöka bena ut alla parallella diskussioner och se om vi kan komma till någon form av konsensus:
Du framhåller gång på gång genom tråden att det skulle vara en enorm kvalitetsskillnad mellan PTv2 och alla andra varianter som presenteras. Detta är inte det diskussionen handlar om. Givetvis ska vi, när vi lägger in nya hållplatser, använda oss av PTv2, med public_transport=stop_position på en nod på vägen och public_transport=platform på en nod, way, eller area vid sidan om vägen. Detta är vi alla eniga om.
Tråden handlar om huruvida vi bör anpassa oss till resten av världen, och därmed kunna dra fördel av bl.a. verktyg som drastiskt förenklar kartering av kollektivtrafiksdata. I dagsläget sticker vi nämligen ut vad gäller taggning av kollektivtrafiksdata i jämförelse med andra länder. Detta faktum är obestridligt.
Det man däremot kan diskutera är huruvida det är ett problem att vi sticker ut, och vad man i så fall ska göra åt det. Jag menar att det är ett problem, dels för att målet med hela projektet måste vara att skapa användbara data, och ju mer standardiserad datan är, desto lättare är den att använda. Det gagnar ingen datakonsument att behöva hålla reda på olika system i olika delar av världen. Dels för att vi sätter käppar i hjulen för oss själva, genom att inte kunna använda standardiserade verktyg som bygger på att de taggningsstandarder som finns följs.
Internationella wikisidor har med tiden evolverat till att (om än inte helt med varandra överensstämmande) förorda att highway=bus_stop taggas på noden bredvid vägen och inget annat. Detta är på intet sätt ett hinder för att kunna ta fram klara och tydliga hållplatskartor, vilket du genomgående påstår. Se t.ex. följande exempel på hur fint det blir, även med highway=bus_stop på samma nod som public_transport=platform:
Det som det däremot medför är att vi nu står inför ett problem: public_transport=platform har hamnat på en nod, men vi har även en linjär plattform eller area att ta hänsyn till. I de fall jag har tittat på har man dubbeltaggat public_transport=platform även på den linjära vägen/arean. Detta är måhända inte den snyggaste lösningen, men det gör heller ingen skada. Skapar man en highway=platform som plattform (den enda taggen som renderas i Carto), vill iD lägga på public_transport=platform, vilket bara är dumt att gå emot eftersom folk ändå kommer att följa iD:s förslag.
Så, då har vi huvudnoden i hållplatsläget, som alltså taggas med
public_transport=platform
highway=bus_stop
name=Exempelvägen
local_ref=A
(bus=yes är redundant när highway=bus_stop redan finns, men skadar å andra sidan heller inte att lägga till. Valet av local_ref framför ref baseras på wikin samt vad som renderas i kollektivtrafikslagret, men jag ställer mig egentligen ganska neutral i frågan och vore nöjd med endera. Det är inte den här taggen vi ska diskutera nu.)
Utifrån detta renderas den fint med referensbokstav i kollektivtrafikslagret på osm.org, går att använda som grund för att lägga till busslinjer i Relatify, och går att komplettera med gtfs_id=* om man så önskar. Det fina här är också att man kan bygga vidare på samma grund för att komma upp i PTv2-standard genom att lägga till stopp-noden (taggas endast med public_transport=stop_position + bus=yes; name liksom ref är helt överflödigt eftersom man om man lägger till stop_position också lägger till hållplatsrelationen) samt hållplats-relationen (taggas som tidigare), men det är inte längre ett krav för att kunna börja lägga till rutt-relationer.
Har du några praktiska invändningar mot detta? Vad är det som hade gått förlorat om vi gjorde på det här sättet? Eller har vi pratat om varandra hela tiden?
Vidare vill jag återkoppla till @Wulfmorns tanke om att public_transport=platform är där man går på bussen, d.v.s. den noden ska sitta fast i highway=platform-vägen (vare sig linjär eller sluten) där de taktila plattorna visar att framdörren stannar (givetvis bortser vi från detta om hållplatsen bara är en stolpe i vägrenen). Då ska det ju också gå en highway=footway längsmed det taktila ståket på plattformen, vinkelrätt mot bilvägen, som slutar i public_transport=platform-noden. Vi slipper med andra ord fiktiva gångvägar ut till centrumlinjen på bilvägen. Detta höjer även kvaliteten på hållplatsdatan, eftersom det blir entydigt var påstigning i framdörren sker och var det taktila stråket finns.
Nå, då tror jag att jag fick med åtminstone det viktigaste för att sammanfatta min ståndpunkt i frågan och förhoppningsvis kunna föra diskussionen framåt, måhända ända in i mål. Jag ser fram emot ett sakligt bemötande och inga “men du måste ju förstå hur mycket sämre kvalitet det blir med det här förslaget!”, för jag har hittills i min fullständiga genomläsning av tråden inte sett någon bevisad kvalitetsförsämring som förslaget skulle medföra. För att återigen påminna och förtydliga: Förslaget handlar alltså endast om att överföra de taggar som beskriver hållplatsläget från public_transport=stop_position-noden på vägen till en public_transport=platform-nod vid sidan om vägen. Alla data finns kvar, alla hållplatslägen finns kvar, alla PTv2-taggar och -relationer finns kvar i en fullständigt karterad hållplats. Skillnaden är bara att vi anpassar oss till de facto-standarden, vilket möjliggör användning av och kompatibilitet med befintliga verktyg och renderare. Vari ligger problemet med det jag har framlagt, som du ser det?
Direkt svar på följande punkter också:
Yep. För mig (personlig åsikt) så är det två saker som ger mest totalvärde.
Att busslinjer är inritade i kartan är fint, men det är ingenting jag själv upplevt som värdefullt. Mest för att jag vet hur snabbt dom kan bli föråldrade i OSM. Sånt slår jag hellre upp på transportföretagens sidor. 
Jag vet heller inte om jag skulle använt OSM för att göra hållplatskartor. Framtiden går ju mot öppna data och API från transportsektorn, och jag tror OSM skulle få svårt att konkurrera med sådana tjänster, såvida den inte aktivt läses in från samma tjänster.
Därför förespråkar jag också hel-, eller delvis automatisering av hållplatsdata (dock inte själva plattformen, den är en del av vägnätet som man måste rita själv).
Håller med fullständigt. Bland de mest tråkiga och trista arbeten i OSM är att laga “trasiga” busslinjer. Jag brukar (försöka) laga sådana i samband jag uppdaterar vägar från NVDB, men inte alltid. Och resultatet blir aldrig helt ok, om man inte kollar på bussbolagets publicerade linjer och kartor. Om ens då. 
Here are all 93k bus stops from Samtrafiken as an OSM file, updated today. Bus stops without any GTFS routes are marked with a note tag. Several thousand of them are not in OSM. They would need a manual import to get a proper location (a few meters adjustment).
What data set is this?
I am of the opinion that the Stops data | Trafiklab would be the ideal data set since it contains mapings to all the others. And seems to be made specifically for this purpose. Det svenska hållplatsregistret | Samtrafiken Some of the mapings are slightly wrong but I believe they will get better. We could even import/add both the regional and national datasets which imo seems like the ideal solution. Since it would work with every avaliable api then.
Having some sort of connection to the scheduled data seems like a good idea given it can be used by journey planners such as OpenTripPlanner 2 to correctly place the stops onto the street network
OpenTripPlanner har hållplatserna internt och skulle isf inte läsa det från OSM. Det OTP behöver är vägnätet, dvs. plattformerna - kopplade till vägnätet med t.ex. footways eller dylikt.
Datasettet NKA har genererat är basert på Samtrafikens data, som du länkar till. Jag har kontaktat Samtrafiken tidigare om kvaliteten på hållplatsdata men kunde inte få ett bra svar eftersom de på den tidspunkten fortfarande var i en övergångsfast med sina data.
Dock vet jag att Samtrafiken har relativt liten påverkningsmakt över hållplatserna. Det är trafikföretagen som sätter koordinaterna i Sverige.
Jag blandade ihop hållplatser (netex stopplace) och hållplatslägen (netex quay) där men värdet av att ha både de regionala idn och och de nationella på hållplatslägen finns fortfarande. Då OTP kan använda dom för att bättre länka till gatunätet.