Ik was van plan om mijn controle scripts hier voor te gebruiken. Daarbij loop ik nu echter aan tegen overlappende Netex bestanden, waarbij niet duidelijk is welk bestand de juiste versie bevat. Dat ben ik nu aan het uitzoeken. Kan nog even duren omdat ik inmiddels weer 5 dagen werk.
1 Like
EDIT: Het is gelukt, de route_master zat nog in een relatie van de concessie, die ID voor het gemak niet weergaf. 
Oorspronkelijke vraag
In Utrecht is al enige tijd een nieuwe concessie ingegaan, dank @Leo_Slager voor het aanpassen van de routes. Inmiddels heb ik alle relaties de juiste netwerk, operator, merk en kleur tags meegegeven. Echter kwam ik bus 4 nog tegen die ik al eerder dacht te hebben verwijderd. Na het nog twee keer geprobeerd te hebben blijft die maar niet weggaan. Inmiddels heb ik alle route info verwijderd en toen nog een keer geprobeerd (zie changeset hieronder). Maar helaas zelfde resultaat: bus 4 blijft in OSM staan. Is er iemand anders die het lukt deze route_master met onderliggende relaties te verwijderen?
Changeset:
Changeset: 176340320 | OpenStreetMap
Route_master:
Fijn dat het gelukt is. Met JOSM heb ik hier ook altijd problemen mee, als je 2 relaties die vader en zoon/moeder en dochter zijn wil verwijderen dan lukt dat niet in 1 upload. Ik verwijder dan altijd eerst de route_master, upload, en dan de routes, en weer upload, maar andersom kan ook.
Wat in JOSM volgens mij ook werkt is het uploaden per 1 item aanzetten (kan even JOSM niet aanzetten om te tonen welk veld je precies moet).
1 Like
Daarvoor hanteer ik de werkwijze van hoog naar laag:
- De concessie-relatie openen en de verwijzing naar de hoofdroute verwijderen.
- De hoofdroute openen en de verwijzing naar de twee routerelaties eruit verwijderen.
- Hoofdrouterelatie verwijderen.
- Tenslotte de twee routes verwijderen.
- En dan gaat alles in Ă©Ă©n changeset naar de server.
1 Like
Ik kreeg als reactie op een changeset van mij dat de route van bus 7 schijnbaar niet klopt. Is er iemand in de gelegenheid dit te wijzigen? Bus 7 volgt dezelfde route als 27 door Ondiep: (Nijenoord<->Ondiep<->Van Hoornekade<->Burg. van Tuylkade)
Lijn 7 heeft een (langdurige) omleiding, de route die nu op transdev.nl/NETEX staat is de omleidingsroute.
Hmm bijzonder dan dat deze niet op de U-OV site wordt genoemd.
Alleen onderstaande afwijkingen staan erin voor bus 7:
Op de transdev website zie ik helemaal niets voor Utrecht staan.
Lijn 7 inclusief de omleidingen is aangepast.
Lijkt er dus op dat de route via Ondiep, van Hoornekade permanent is.
Ik heb de afgelopen anderhalf jaar aan deze concessie gewerkt, maar weet de details van de routes niet. Ik weet alleen dat er âeen langdurige omleidingâ is, dus dat zal die thv de Van Heuven Goedhartlaan wel zijn.
Transdev is een beetje vreemd qua omleidingen, we hebben drie soorten omleidingen.
- Acute omleidingen (bijv omdat een waterleiding gesprongen is), die zie je alleen bij de informatie van de specifieke rit
- geplande kortdurende omleidingen met weinig impact (dat kan alles van een uur tot ± twee maand zijn): hierbij blijft de ârouteâ online gelijk, maar vervallen er haltes en worden vervangende haltes in tekst genoemd. Deze zal je altijd zien in het overzicht met omleidingen.
- geplande langer durende omleidingen of omleiding met grotere impact, hierbij is de nieuwe route ook echt in de reisinformatie opgenomen. Het is hier afhankelijk van het logistiek personeel of deze route ook in het overzciht met omleidingen wordt opgenomen, want dit kan ook verwarrend werken. De omleidingsinformatie komt namelijk ook bij de rit, die juist geheel volgens de reisplanner rijdt.
Hoe we daar mee omgaan is een beetje verwarrend, er zijn soms âomleidingenâ van meer dan 2 jaar (waar de route ook echt is aangepast) die wĂ©l ook nog in het overzicht van omleidingen staan, en omleidingen van een maand die niet in het overzicht van omleidingen staan.
Ik heb in Noord-Holland Noord lijn 158 maar even goed gezet⊠Die ging nog van Den Oever tot Anna Paulona. ipv door naar Julianadorp en Den Helder.
Op Den Oever Busstation heb ik het busstation iets anders ingericht:
De perronrand (bijv) (waar men wacht) is een public-transport=platform met alle relevante data en ref:ifopt, en opgenomen in de routerelatie
Op de haltepaal (bijv) heb ik alleen highway=bus_stop, naam, ref (halteletter) en bus=yes gezet, als âlegacyâ om de haltepaal te tonen.
Datzelfde heb ik ook bij 1 nieuw haltepaar gedaan, bij een ander haltepaar was niet te zien waar de haltepaal stond en bij een derde nieuwe haltepaal is en komt waarschijnlijk geen verhoogde perronrand, die heb ik dus alles maar op de âoudeâ manier gecombineerd.
Jammer. Jij bent de enige die op deze manier bushaltes mapt, dus dit is weer een halte met afwijkende taggingâŠ
Zo ongeveer hier (het is een hele discussie) dacht ik dat we toch redelijk tot een concensus waren gekomen om het zo te doen.
Dus:
- Als de halte bestaat uit een halteperron:
-
- way op perronrand met public_transport=platform en alle relevante informatie
-
- node op haltepaal met highway=bus_stop en haltenaam, alleen om ervoor te zorgen dat deze getoond wordt op de mapnik-laag (en public_transport-laag)
- Als de halte geen perron heeft maar alleen een haltepaal (in de berm of op de stoep):
-
- node op haltepaal met zowel public_transport=platform als highway=bus_stop
- Op het perron (zowel public_transport=platform-way als highway=bus_stop node) de âhaltenaamâ en op de eventuele public_transport=stop_position de âplaatsnaam, haltenaamâ.
Dit is volgens mij alleen jouw methode. Ik zie het verder niemand zo doen.
De perronrand i.p.v. het perron als perron (public_transport=platform) taggen vind ik maar raar. Als het perron duidelijk zichtbaar is, zou ik het als vlak intekenen. Dat perron is secundair aan de stop-positie (public_transport=stop_position) en haltenode (highway=bus_stop) die de halte zelf voorstellen en ook in de busrouterelatie worden opgenomen.
Persoonlijk vind ik de stop-positie de beste kandidaat om sowieso in de busrouterelatie op te nemen, omdat je deze kan gebruiken om de relatie te valideren. De stop-posities moeten in de juiste volgorde als nodes in de ways van de routerelatie voorkomen. Ook is de analogie met tram en trein beter, waar de stop-posities als haltes worden gezien. Helaas heeft men vanwege het visuele effect ooit de voorkeur gegeven aan haltenodes naast de weg.
Hoe ik normaal een bushalte tag:
- Minimaal een haltenode met highway=bus_stop en public_transport=platform
- Bij voorkeur ook een stop_positie met public_transport=stop_position
- Eventueel ook het perron als vlak met highway=platform en public_transport=platform
Ik zie niet zo veel verschillen tussen de tagging van @IIVQ en @A67-A67 behalve lijn versus vlak. @A67-A67 lijkt ook nog public_transport=stop_position toe te voegen.
Veel bus tagging heb ik niet gedaan maar wat ik heb gedaan is ook een lijn geweest.
De halte-node en de stop_position worden opgenomen in de routerelatie.
Dat is voor mij dan ook de reden om alle andere tags te handhaven op de halte-node.
Als er een way of een area wordt ingetekend en voorzien van pt=platform, dan ga ik niet alle andere tags verhuizen.
Overigens zou pt-platform uiteindelijk de highway=bus_stop moeten gaan vervangen.
De halte node heeft dan geen hoofd-tag meer en kan dan ook niet meer afgebeeld worden.
M.a.w. highway=bus_stop mag dus niet compleet verdwijnen.
1 Like
In Zeeland is sinds vorig jaar Zeeland-Flex in gebruik genomen en aansluitend wordt de Haltetaxi opgeheven in die gebieden. Inmiddels is dat al het geval op Schouwen-Duiveland, Walcheren, Noord-Beveland en Zeeuws-Vlaanderen.
Op plaatsen waar gĂ©Ă©n normale bus rijdt worden aparte âHub-palenâ neergezet en deze verdienen het mijn inziens om ook in OSM opgenomen te worden en daarna eventueel samen te voegen tot Ă©Ă©n netwerk-relatie binnen de concessie Zeeland. Voorbeeld: Google Maps
Ik ben voor de tagging uitgegaan van de voormalige haltes die aan het begin van de weg stonden:
amenity = taxi
highway = bus_stop
en dan aangevuld met bankje etc. wat er al dan niet meer op bushaltes stond.
Iemand hier nog aanvullingen op?
Tsja, het is een beetje een rare tussenvorm tussen taxi en openbaar vervoer. Ik weet niet zo goed wat ik er van moet maken.
Ik zou highway=bus_stop niet opnemen tenzij het een echte bushalte (bord L1) betreft.
Als je dat wel dout, dan moet je ook public_transport = platform op te nemenâŠ
Ik had op deze changeset een discussie met @A67-A67.
Ik ben van mening dat op een busstation zoals het nieuwe Hilversumse, met een groot eilandperron met 4 halteposities, er langs de verhoogde stoeprand 4 public_transport=platforms moeten zijn, met daarop alle informatie over die halte, en dat het perroneiland verder een highway=pedestrian is.
En daarnaast zijn we volgens mij tot de concensus gekomen dat, om legacy-redenen (het tekenen van haltes op de standaard-kaartlaag) daarnaast nog de highway=bus_stop zĂłnder public_transport=platform op de plek van de haltepalen zou moeten komen.
@A67-A67 is, als ik het goed verwoord, van mening dat het hĂ©le eilandperron Ă©Ă©n groot public_transport=platform is â[want op de wiki] staat toch ook letterlijk dat het perron een area kan zijn?â , en dat op de haltepaal alle informatie moet staan en dat ik de Ă©nige ben die informatie op de perronrand zet.
Daar ben ik het weer niet mee eens, ik gebruik een area voor treinperrons of voor haltes als van de Zuidtangent (bijv De Hoek) waar een perron een zeer duidelijke alternatieve bestrating heeft die geen onderdeel uitmaakt van de normale stoep, maar dat zijn dan ook twee areaâs voor twee verschillende richtingen.
De discussie waar ik de concensus uit las is lang en kwam niet tot een geheel unanieme concensus, maar ik heb het idee dat het vooral A67-A67 is die volhardt in dat informatie op de plek van de haltepaal moet in plaats van op de stoeprand, terwijl volgens mij die stoeprand âthe places where passengers board or alight from public transportâ zijn.
Wat is jullie mening?
PTv1 vs PTv2
Het taggingsschema PTv2 is lang geleden ingestemd. Daarna is er echter veel kritiek op gekomen en veel renderers ondersteunen het niet. PTv2 is daardoor nauwelijks doorontwikkeld en tekortkomingen zijn nooit opgelost. Hierdoor is een situatie ontstaan waarin PTv1 (highway=bus_stop/platform) en PTv2 (public_transport-tags) naast elkaar worden gebruikt. Omdat de schemaâs andere keys gebruiken, is dit ook goed mogelijk. Volgens mij helpt de iD-editor zelfs hierbij, door de tags van het andere schema aan te vullen, bijvoorbeeld public_transport=platform bij highway=bus_stop.
Haltenode: highway=bus_stop
Een grote tekortkoming van PTv2 is dat er geen duidelijk object is voor de bushalte dat kan worden toegevoegd aan de routerelaties. Er zijn stop-posities en perrons, geen halte zelf. De haltenode (met highway=bus_stop) heeft daardoor deze rol behouden. Deze node wordt dus altijd aan de routerelatie toegevoegd en bezit belangrijke algemene informatie over de halte.
@Leo_Slager geeft hierboven aan dat deze node in de routerelatie hoort. @Gertjan_Idema geeft aan dat een duidelijk bushalte-object met ref:IFOPT nodig is voor automatische controle met Netex-data.
Perron of perronrand
PTv2 heeft een tag voor het perron: public_transport=platform. Dit is dus het gebied waar de passagiers wachten. Hieraan wordt ook de PTv1-tag highway=platform toegevoegd. Het gebied waar mensen wachten is een area, geen lijn. Het perron als lijn intekenen is goed als eerste mapping met weinig detail. Daarna kan deze worden uitgelijnd naar een area.
Het is dan erg vreemd om perron als ârand van het perronâ te interpreteren. De tag is platform, geen platform_edge. Het levert ook nog eens plakwerk op met korte ways vastgeplakt aan het perron zelf.
Wijziging bij Busstation Hilversum
Wat mij extra steekt bij het busstation in Hilversum is dat ik dit netjes had ingetekend. Twee maanden later komt IIVQ met een wijziging waarin veel tags worden verwijderd en haltenodes uit de busroutes gehaald. De tags ref en local_ref worden verwijderd van de stop-posities, waardoor het onduidelijk wordt welke stop-positie bij welke halte hoort. Ook de haltenode wordt zo goed al leeggehaald.
Als je graag op je eigen manier mapt, kun je toch het werk van anderen laten staan?
Ik ga niet mee in je aanname dat we PTv2 + PTv1 moeten taggen.
Volgens mij taggen iedereen in Nederland al jaren alles zo veel mogelijk volgens PTv2 en doen we alléén de highway=bus_stop + name=xxx nog op de paal, tbh rendering op osm-carto.
In de routerelatie hoort een public_transport=platform (waar de reiziger wacht) en evt een public_transport=stop_position (plek op de weg waar de bus stopt).
Ik heb beiden netjes in de routerelaties gezet.
Voor wat betreft het perron: Jij lijkt het héle eiland van busstation Hilversum als één perron te beschouwen, maar ik zie dat als 4 aparte platforms, terwijl het eiland als geheel een area (of in dit geval multipoligon, want bloemperken in het midden) van highway=pedestrian is.
Daarmee behandel is de perronrand niet anders dan een perron ergens langs een weg, zoals bijvoorbeeld deze: Way: âȘOude Gemeentehuis⏠(âȘ1467294520âŹ) | OpenStreetMap
De laatste opmerking is een rare: Op Openstreetmap is geen âeigendomâ. Ik heb naar beste weten het busstation aantepast. Jij bent het daar niet mee eens, en dat is prima, daarom gaan we met elkaar in discussie op de changeset. Maar vervolgens pas je het ook gelijk terug aan.
Ik zou op dezelfde manier kunnen zeggen dat je âmijnâ edits op bovengenoemde halte Oude Gemeentehuis in Anna Paulowna op een onjuiste manier hebt aangepast, daar heb je immers per halte twee objecten public_transport=platform gemaakt, anders dan hoe ik het ingetekend heb, maar dat is niet hoe OSM werkt.
Voor de local_ref heb ik excuses aangeboden, ik wist niet dat dat de juiste tag was voor perronletter (ik heb daarvoor altijd ref gebruikt), dus dank (gemeend, niet sarcastisch) voor die les. Overigens is die local_ref niet wat een stop_positie en een platform samenbindt, dat is namelijk het samen opnemen in de routerelatie, er zijn immers voldoende stops zonder local_ref of zelfs 2 haltes (aan beide kanten van de weg) met maar Ă©Ă©n stop_position.
Maar ik had deze discussie geopend niet om jouw argumenten te horen, maar om die van anderen te horen, want alleen met zân tweeĂ«n komen we hier niet uit geloof ik.