[OSM-talk-be] samenwerking met De Lijn: zij zien dat NIET zitten

[Ben Abelshausen]

 Ik volg Ben Laenen volledig als die zegt dat in OSM geen vaste of
niet-editeerbare layers kunnen bestaan. Dan zijn er echter nog maar 2 opties
over:

- Of een aparte database/website met als basis layer OSM en daarboven dus
buslijnen.

- Of een manier uitwerken om alles te automatiseren:
-> hiervoor hebben we echter inderdaad infrastructuur nodig en iemand om al
die scripts te maken.
-> hiervoor moeten we duidelijke afspraken maken over de structuur van de
data in OSM.

Aan de andere kan denk ik ook niet dat OSM gemaakt/ontworpen is om op deze
manier met vluchtige data om te gaan. Als de routes van de lijn relatief
stabiel blijven is er natuurlijk geen probleem...

Infrastructuur kan ik niet leveren maar ik ben ondertussen wel zeer bedreven
geworden in het verwerken/editeren van OSM data. Ik heb niet heel de
discussie gevolgd maar ik wil misschien de technische kant van de zaak wel
verder uitzoeken... heeft er iemand meer concrete informatie over de manier
waarop de lijn hun data willen doorsturen?

Groeten,

Ben

2010/10/18 Ben Laenen <benlaenen at gmail.com>

> Ivo De Broeck wrote:
> > Euh, en waarom zou je geen read-only layer in OSM mogen hebben. Als het
> > over het principe gaat dat iedereen mag/moet updaten, ja dan is het
> > zinloos de gegevens van de Lijn te gebruiken.
>
> Welkom in OSM: alles is door iedereen te veranderen. Zit je data in een
> andere
> databank, dan zit het niet in OSM en is het voor ons niets waard. En iets
> als
> layers (laat staan gelockte) bestaat hier niet.
>
>
> > Maar je weet wel wat je exact kan krijgen. Ik vind de houding van de Lijn
> > heel logisch. Als je kan garanderen dat hun gegevens niet verknoeid
> worden
> > (aparte gelockte layer) en je kan garanderen dat xx uur na ontvangst van
> > updates die in OSM komen zal alles voor hun ok zijn. Ik denk dat ze zelfs
> > voor b kunnen helpen (omzetting naar OSM-coordinaten bv).
>
> Omzetten van coördinaten is echt het allerminste van m'n zorgen.
>
> Je moet hier een hele infrastructuur opzetten. Hoe maken zij hun data
> beschikbaar? Kunnen we dat automatisch ophalen, want zoniet moeten we er
> niet
> echt aan beginnen (dan kunnen we niks van updates garanderen). We hebben
> een
> server nodig die de importscripts op geregelde tijdstippen kan laten lopen,
> die controleert op wijzigingen en waar nodig dingen herstelt of ergens een
> vlagje zet dat iemand er manueel naar moet kijken.
>
> Hoe vaak krijgen we die updates van De Lijn? Dagelijks, wekelijks,
> maandelijks? Van welke periode krijgen we de data, slechts van de volgende
> dag, of de volgende week, of meteen een paar maand? Maakt allemaal uit op
> welke manier we dit in OSM zetten.
>
> Om te zwijgen over de exacte methode om dit in OSM te zetten: zetten we
> iets
> in OSM zoals enkel die dag de bussen rijden (niet aan te raden), of zetten
> we
> alle routes die we over de gegeven tijdspanne gekregen hebben in OSM. Wat
> dan
> met grote wijzigingen waar een buslijn compleet anders gaat rijden vanaf
> een
> zekere datum en dit middenin die tijdspanne valt? Kan vreemde kaartjes
> opleveren.
>
> We moeten scripts schrijven die de data omvormt tot iets bruikbaar, en met
> het
> kleine voorsmaakje van de database die ik gezien heb is dat allesbehalve
> een
> eenvoudig werkje. Daarnaast hebben we scripts nodig die orde houdt in wat
> we
> in OSM zetten. Welke nodes en relaties we hebben geïmporteerd met welke
> data.
>
> Wie gaat die server op orde houden of wie gaat die betalen? Wie gaat al die
> scripts schrijven en onderhouden?
>
>
> > > Maar hoe bewijzen we dat dan als we de data niet hebben om het te
> kunnen
> > > bewijzen?
> >
> > Daarvoor heb je geen 'real' data nodig. De structuur van de databank en
> de
> > velden van de tabellen zijn toch voldoende?? Maak data aan voor 1
> bushalte
> > (met zelfs foute data, maakt niet uit) en bewijs dat het werkt.
>
> Huh?
>
> Ze vragen garanties dat wat we in OSM hebben steeds up to date is. Ik weet
> niet wat dat ermee te maken heeft.
>
> Ben
>
>
>
> _______________________________________________
> Talk-be mailing list
> Talk-be at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-be/attachments/20101018/21e1c13c/attachment.htm>