Akkoord, alleen willen we ook weten of het over een nachtbus of reguliere
bus gaat. De operator zou ik eruit laten (die staat al in een apart veld).
Korter (en duidelijker misschien) zou zijn 'Nachtbus 8 (to) Bierbeek'. Het
intern nummer 3008 in ref???
Op 14 oktober 2010 09:33 schreef Jo <winfi...@gmail.com> het volgende:
> Ik begrijp, eerlijk gezegd, niet waarom de name stadsbus e.d. moet zijn.
> Waarom mag dat geen duidelijke beschrijving zijn van welke bus het is en van
> waar naar waar dat hij rijdt?
>
> De Lijn 3008 Bertem - Leuven - Lovenjoel - Bierbeek Bremt - Bierbeek De
> Borre
> en terug:
> De Lijn 3008 Bierbeek De Borre - Bierbeek Bremt - Lovenjoel - Leuven -
> Bertem
>
>
> Dat eerste cijfer is een intern nummer dat elke buslijn van De Lijn op
> unieke wijze beschrijft. Die nummers kunnen we achterhalen op de displays
> die aan de busterminals hangen, zodat de chauffeurs weten of ze mogen
> vertrekken.
>
> Jo
>
> Op 14 oktober 2010 09:03 schreef Ivo De Broeck <ivo.debro...@gmail.com>het
> volgende:
>
> Eindelijk komen we nu een stapje vooruit. Voor de parent-relaties zouden we
>> dan ref=8 en name=stadsbus en ref=8 en name=nachtbus kunnen hebben (beide
>> bestaan).
>> Vraag blijft nog altijd dan de to en from (1 of 2 relaties) en het
>> probleem van de bus_stops (waar de ene richting een iets andere route volgt
>> dan de andere richting).
>> Misschien moeten we (voor de duidelijkheid) bij een parent-relatie het
>> veld direction bijvoegen forward/backward ? Dat betekent dat bus 8 forward
>> wordt from Bertem to Bierbeek en bus 8 backward als from Bierbeek to Bertem
>> (dus 2 aparte relaties?)
>>
>>
>> Op 13 oktober 2010 23:15 schreef Jo <winfi...@gmail.com> het volgende:
>>
>>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Ivo De Broeck
>> Valleilaan 13
>> 3360 Korbeek-lo
>> Tel (0)16 43 84 93
>> Gsm +32 486 17 61 13
>>
>
>
--
Ivo De Broeck
Valleilaan 13
3360 Korbeek-lo
Tel (0)16 43 84 93
Gsm +32 486 17 61 13
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
