Op 13 oktober 2010 20:13 schreef Ben Laenen <benlae...@gmail.com> het
volgende:

> Ivo De Broeck wrote:
> > Dus als ik het goed begrijp is die to, from en via nu wel nuttig, maar
> > onbruikbaar bij 1 relatie. Of wordt het dan from Bertem to Bertem via
> > Leuven, Bremt en Bierbeek ?
> >
> > Graag had ik ook de mening vernomen van mensen die busroutes (proberen
> > te) taggen en hun ervaringen laten weten. Ik vermoed dat de 2 relaties
> een
> > algemene tendens is.
>
> Een tendens waar in België alleszins nog niet veel van te merken valt?
>

Totnogtoe hebben we die bus relations aangemaakt zoals we dat deden voor de
cycle route relations. Dat lijkt me ondertussen niet meer de beste wijze. De
reden waarom we die wikipagina willen aanpassen is niet om te beschrijven
hoe het tot nu toe gedaan werd, maar wel om tot een goede oplossing te komen
voor de toekomst. Er kruipt veel tijd in om het allemaal te
beschrijven/mappen en daarom zouden we het liefst van de eerste keer (zo)
goed (mogelijk) doen.


> > In OSM werd voor busroutes voorgesteld bij 'name' snelbus, stadsbus, bus
> in
> > te vullen?
>
> Dat heb ik toch niet gezegd. Vroeger werd gewoon iets als "name=Centraal
> Station - Luchthaven" getagd. Over snelbussen en dergelijke was nog niks te
> vinden.
>

Dat lijkt mij de beste manier, maar het nummer moet er ook voor. Stom dat
die informatie dan zowel in ref als in name zit, maar je die nummers zijn
daar belangrijk genoeg voor.

De reden waarom aan aantal mensen in het verleden (en nu nog) twee relaties
> wou is omdat ze in de war geraken van de forward/backward roles die nodig
> zijn
> in één relatie. Het enige nut hiervan was dus dat ze het makkelijker zouden
> maken voor de mapper. Alleen kan je met één relatie met forward/backward
> net
> zo veel kwijt als met twee zonder roles en dus gaat mijn voorkeur hier uit
> naar één relatie ("het is makkelijker te mappen" valt bij mij onder
> dezelfde
> categorie als "mappen om het mooi te laten renderen"). Daarentegen ga je
> met
> twee relaties problemen introduceren die je met één relatie niet hebt
> (cirkellijnen?) en los je dingen niet op die ook bij één relatie een
> probleem
> vormen (lussen?).
>
> Tot daar de discussie van één/twee relaties.
>

Ik kan op beide manieren mappen en, eerlijk gezegd vind 'k 1 relatie
gemakkelijker. Als je echter wilt 'exact'  wil kunnen aangeven welke
wegsegmenten een bus gebruikt, heeft het geen zin om beide richtingen in 1
relatie te stoppen. Ik denk hierbij aan het stukje Tiensevest over het
Martelarenplein dat door sommige bussen 2x gebruikt, eenmaal om van de
Maria-Theresiastraat naar de terminal te gaan en nadien om van de terminal
naar de Bondgenotenlaan te gaan. Dezelfde situatie bestaat op een rond punt
in Diest waar een kwart vh ronde punt 2x gebruikt wordt door de bussen die
van de Leuvensesteenweg rechts de ring oprijden, maar eerst nog een halte
links op het ronde punt bedienen.

De reden waarom we het voordien met 1 relatie deden, is dat er geen volgorde
aan de segmenten kon worden meegegeven.


>
> Maar nu hebben we ook eens kunnen kijken naar de data zoals die door De
> Lijn
> wordt bijgehouden, en zo leren we dat ze werken met knooppunten
> (belangrijke
> haltes) waartussen de lijnen rijden. Een buslijn bestaat in dat geval uit
> een
> lijst van routes (en een route is een lijst haltes) tussen knooppunten. Een
> schedule zorgt er dan voor dat de stukjes aan mekaar aansluiten en dat je
> bvb.
> in het weekend via route A gaat en in de week via route B.
>
> Leuk, dit houdt steek. Een basisrelatie voor de buslijn die een aantal
> kindrelaties omvat voor elk stukje.
>

Hmm, mijn experiment met child relations houdt dan toch steek. Ik haat het
om informatie te dupliceren, dus ik ben zeker voorstander om het zo aan te
pakken. De tool in JOSM om public transport relations aan te maken,
ondersteunt dat echter niet. En zetten we de haltes op die
gemeenschappelijke stukken/child relations dan wel mee in de relaties voor
de uiteindelijke lijnen? Child relations maken het allemaal wat complexer
voor de mapper, maar maken de data een stuk interessanter om mee te werken,
achteraf. Zowel voor routing, als wat betreft onderhoud.

Ik zou graag zien dat er met child relations gewerkt wordt, maar dan zouden
we dat er toch ook op globaal vlak door moeten krijgen. Zodat heel OSM het
op die manier doet.


> Variantes worden dan ook een stuk overzichtelijker: stel dat je lijn op
> drie
> plekken een variante heeft, dan kan je ofwel 8 relaties aanmaken tussen de
> twee terminussen (maal 2 voor elke richting), en dan heb je wegen waar 16
> keer
> een relatie voor buslijn X op staat. Met knooppunten tussen de variante
> routes
> ga je er niet meer dan 4 hebben op een weg (met de voorwaarde dus dat er
> ook
> knooppunten liggen tussen waar de variantes genomen worden).
>
> Het totaal aantal relaties voor routes zonder varianten stijgt natuurlijk
> spectaculair.
>
> Minder leuk natuurlijk: we kennen helemaal niet de knooppunten die De Lijn
> gebruikt, en we zullen dus een beetje zelf moeten kiezen waar ze zijn zich
> bevinden. En dan zullen enkele slimme mensen hier wel enkel beide
> terminussen
> als zo'n knooppunt maken. So be it, alleen is onze structuur dan duizend
> keer
> beter om met alle soorten speciale situaties rekening te houden zoals
> lussen
> en variantes, en zijn we ook voorbereid voor het geval we ooit wél de data
> van
> De Lijn krijgen.
>
>
>
> tl;dr:
>
> * één relatie = twee relaties = even goed/slecht
> * basisrelatie per lijn + kindrelaties voor routes tussen knooppunten =
> veel
> dichter bij datastructuur De Lijn
>

Hoe pakken we de naamgeving van die child relations aan? Gewoon Leuven
station - Margarethaplein in de name tag? (En dan een andere
relatie Fochplein - Leuven station, voor wie met 2 relaties wil werken?) Zo
zal het hier in Leuven in de toekomst zijn. Geen idee of De Lijn de halte op
het Margarethaplein als 'Fochplein' zal aanhouden, maar stadinwaarts wordt
die halte dus verplaatst.


> > 2) de velden to from en via
> >
> > 3) het facultatief gebruik van text_colo(u)r en colo(u)r en de
> schrijfwijze
> > (persoonlijk zie ik liever color omdat dit ook html-commando-taal is)
> > Als we het daar al over eens kunnen worden, zijn we al een grote stap
> > voorwaarts.
>
> Hier is geen discussie mogelijk: het is colour met een "u". Dat er op de
> wiki
> nog zonder "u" stond komt waarschijnlijk omdat ik(?) het daar jaren terug
> vlug-vlug heb neergezet om iets te hebben, en er achteraf niet meer naar
> gekeken heb.
>
> OSM-tags zijn in Brits Engels, colour dus ook. En zoals vermeld is er al
> eens
> een bot doorheen de data gefietst die alle "color" tags naar "colour" heeft
> omgezet.
>

Volledig mee eens

>
> Andere opmerking die er ook echt bij moet is dat text_colour slechts zeer
> zelden moet gebruikt worden voor De Lijn (ik ken enkel tram 15 (groen op
> wit)
> en 11 (rood op wit) in Antwerpen, en deze hadden eigenlijk ook niet meer
> bestaan moest De Lijn haar zin gedaan hebben, zo was tram 15 al eens enkel
> beige, en 11 iets blauw/groenachtig, maar ze kregen tegenwind van reizigers
> die tram 15 met tram 3 (geel) verwarden, en tram 11 met tram 10 (groen);
> reizigers stappen verkeerde tram op, zijn kwaad tegen chauffeur, vakbond
> wil
> en krijgt oude kleuren terug -- tot zover de petite histoire :-) ).


Ja, het is de background colour die we wensen op te slaan (en eigenlijk
gerenderd willen zien), voor alle bussen behalve die 2 Antwerpse
uitzonderingen dan...

Jo
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be

Reply via email to