Ja sorry, zoals ik al zei begrijp ik "De lijn" volkomen. Ik denk nu dat ze nog gelijk hebben ook.<div><div><br></div><div>Als het over het principe gaat dat iedereen mag/moet de gegevens van 'de Lijn' updaten, ja dan is het<br>
zinloos de gegevens van de Lijn te gebruiken.</div><div><br></div><div>Het probleem van nodes en relaties is een ook een perfect alibi om niets met de bushaltes te doen.</div><div><br></div><div>Ik denk dat ik aan deze thread verder dan ook niets meer kan toevoegen.</div>
<div><br></div><div><br><br><div class="gmail_quote">Op 18 oktober 2010 16:53 schreef Ben Laenen <span dir="ltr"><<a href="mailto:benlaenen@gmail.com">benlaenen@gmail.com</a>></span> het volgende:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Ivo De Broeck wrote:<br>
> Euh, en waarom zou je geen read-only layer in OSM mogen hebben. Als het<br>
> over het principe gaat dat iedereen mag/moet updaten, ja dan is het<br>
> zinloos de gegevens van de Lijn te gebruiken.<br>
<br>
</div>Welkom in OSM: alles is door iedereen te veranderen. Zit je data in een andere<br>
databank, dan zit het niet in OSM en is het voor ons niets waard. En iets als<br>
layers (laat staan gelockte) bestaat hier niet.<br>
<div class="im"><br>
<br>
> Maar je weet wel wat je exact kan krijgen. Ik vind de houding van de Lijn<br>
> heel logisch. Als je kan garanderen dat hun gegevens niet verknoeid worden<br>
> (aparte gelockte layer) en je kan garanderen dat xx uur na ontvangst van<br>
> updates die in OSM komen zal alles voor hun ok zijn. Ik denk dat ze zelfs<br>
> voor b kunnen helpen (omzetting naar OSM-coordinaten bv).<br>
<br>
</div>Omzetten van coördinaten is echt het allerminste van m'n zorgen.<br>
<br>
Je moet hier een hele infrastructuur opzetten. Hoe maken zij hun data<br>
beschikbaar? Kunnen we dat automatisch ophalen, want zoniet moeten we er niet<br>
echt aan beginnen (dan kunnen we niks van updates garanderen). We hebben een<br>
server nodig die de importscripts op geregelde tijdstippen kan laten lopen,<br>
die controleert op wijzigingen en waar nodig dingen herstelt of ergens een<br>
vlagje zet dat iemand er manueel naar moet kijken.<br>
<br>
Hoe vaak krijgen we die updates van De Lijn? Dagelijks, wekelijks,<br>
maandelijks? Van welke periode krijgen we de data, slechts van de volgende<br>
dag, of de volgende week, of meteen een paar maand? Maakt allemaal uit op<br>
welke manier we dit in OSM zetten.<br>
<br>
Om te zwijgen over de exacte methode om dit in OSM te zetten: zetten we iets<br>
in OSM zoals enkel die dag de bussen rijden (niet aan te raden), of zetten we<br>
alle routes die we over de gegeven tijdspanne gekregen hebben in OSM. Wat dan<br>
met grote wijzigingen waar een buslijn compleet anders gaat rijden vanaf een<br>
zekere datum en dit middenin die tijdspanne valt? Kan vreemde kaartjes<br>
opleveren.<br>
<br>
We moeten scripts schrijven die de data omvormt tot iets bruikbaar, en met het<br>
kleine voorsmaakje van de database die ik gezien heb is dat allesbehalve een<br>
eenvoudig werkje. Daarnaast hebben we scripts nodig die orde houdt in wat we<br>
in OSM zetten. Welke nodes en relaties we hebben geïmporteerd met welke data.<br>
<br>
Wie gaat die server op orde houden of wie gaat die betalen? Wie gaat al die<br>
scripts schrijven en onderhouden?<br>
<div class="im"><br>
<br>
> > Maar hoe bewijzen we dat dan als we de data niet hebben om het te kunnen<br>
> > bewijzen?<br>
><br>
> Daarvoor heb je geen 'real' data nodig. De structuur van de databank en de<br>
> velden van de tabellen zijn toch voldoende?? Maak data aan voor 1 bushalte<br>
> (met zelfs foute data, maakt niet uit) en bewijs dat het werkt.<br>
<br>
</div>Huh?<br>
<br>
Ze vragen garanties dat wat we in OSM hebben steeds up to date is. Ik weet<br>
niet wat dat ermee te maken heeft.<br>
<font color="#888888"><br>
Ben<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Ivo De Broeck<br>Valleilaan 13<br>3360  Korbeek-lo<br>Tel (0)16 43 84 93<br>Gsm +32 486 17 61 13<br>
</div></div>