Ivo De Broeck wrote:
> Kunnen we (als test en om ervaring op te doen) niet ons beperken tot 1
> regio (provincie,arrondissement, of zelfs gemeente?).
Zeker en vast, het moet toch eerst uitgetest worden op kleine schaal vooraleer
we heel Vlaanderen om zeep helpen :-) . Te beginnen met een stad met
Volledig akkoord met Ben.
Ben,
Kunnen we (als test en om ervaring op te doen) niet ons beperken tot 1 regio
(provincie,arrondissement, of zelfs gemeente?).
1) juiste lokatie van alle bushalten
2) vragen dat ze het zone-nummer bijvoegen (kunnen ze zeker in GIS
Als dat lukt
3) bijkomende informa
Daar heb je natuurlijk ook wel een punt...
2010/10/19 Ben Laenen
> Jo wrote:
> > Ik zie echter niet in waarom we bestaande gegevens zouden moeten weghalen
> > uit de OSM DB. Bij de eerste overdracht zal/zullen de verantwoordelijken
> > voor een bepaalde regio zelf geval per geval moeten beslisse
Lees ook hier:
http://wiki.openstreetmap.org/wiki/Talk:Import/Guidelines#Are_imports_bad.3F
2010/10/19 Ivo De Broeck
>
>
> Op 19 oktober 2010 14:24 schreef Jo het volgende:
>
> Wel, deze hele oefening moet dienen om met een gefundeerd voorstel naar De
>> Lijn te kunnen stappen.
>>
>> Ik zie e
Jo wrote:
> Ik zie echter niet in waarom we bestaande gegevens zouden moeten weghalen
> uit de OSM DB. Bij de eerste overdracht zal/zullen de verantwoordelijken
> voor een bepaalde regio zelf geval per geval moeten beslissen of ze de
> coordinaten van De Lijn of die die we al hadden willen aanhoude
Zoals hier ( http://wiki.openstreetmap.org/wiki/Import/Guidelines ) te lezen
staat moeten we ook wel oppassen met imports maar misschien is die discussie
er al geweest. Ik denk dat het sowieso niet verstandig is om dingen te
wissen (haltes) die al aanwezig zijn om te vermijden dat mappers die er nu
Op 19 oktober 2010 14:24 schreef Jo het volgende:
> Wel, deze hele oefening moet dienen om met een gefundeerd voorstel naar De
> Lijn te kunnen stappen.
>
> Ik zie echter niet in waarom we bestaande gegevens zouden moeten weghalen
> uit de OSM DB. Bij de eerste overdracht zal/zullen de verantwoor
Wel, deze hele oefening moet dienen om met een gefundeerd voorstel naar De
Lijn te kunnen stappen.
Ik zie echter niet in waarom we bestaande gegevens zouden moeten weghalen
uit de OSM DB. Bij de eerste overdracht zal/zullen de verantwoordelijken
voor een bepaalde regio zelf geval per geval moeten
Als je wil beginnen dan start het inderdaad enkel met de locatie van de
bushaltes. Dat is ook veruit het eenvoudigste.
Wat je nodig hebt om zover te komen:
* Bijna alle bestaande bus- en tramhaltes in Vlaanderen moeten uit OSM. Maar
er zijn ook haltes van De Lijn in Brussel, Wallonië of zelfs N
Ik wil Oost-vlaanderen wel voor mijn rekening nemen.
Groeten Johan
On 10/19/2010 10:33 AM, Jo wrote:
Ons probleem is natuurlijk dat we bottom up werken. Dus is het toch
handig om per bushalte bij te houden in welke zone ze ligt.
Voor Vlaams-Brabant zijn we al met 2. Ik veronderstel dat Eima
Ons probleem is natuurlijk dat we bottom up werken. Dus is het toch handig
om per bushalte bij te houden in welke zone ze ligt.
Voor Vlaams-Brabant zijn we al met 2. Ik veronderstel dat Eimai Antwerpen
wel onder z'n vleugels wil nemen. Maar dan hebben we nog 3 provincies,
waarvoor we wat mankracht
OK dit lijkt me haalbaar. Noteer me maar als vrijwilliger voor zone Leuven.
Wat die 'zone' betreft. Ik vermoed dat zones geografisch worden opgeslagen.
Misschien moeten we dat ook zo doen in OSM. Alle bushalten in die zone
krijgen dan dat zonenummer. Waarschijnlijk geldt hetzelfde voor de
stadszon
Ik heb het nog al geopperd. Het lijkt er op dat de insteek van OSM te
liberaal/anarchistisch is om een succesvolle samenwerking met De Lijn
mogelijk te maken. Hoe ze er in andere regio's in slagen om wel gegevens los
te krijgen, is me niet helemaal duidelijk.
Wat we blijkbaar nodig hebben is een p
Op 18 oktober 2010 17:12 schreef Ben Abelshausen
het volgende:
> 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
>
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:
-> hiervo
Ja sorry, zoals ik al zei begrijp ik "De lijn" volkomen. Ik denk nu dat ze
nog gelijk hebben ook.
Als het over het principe gaat dat iedereen mag/moet de gegevens van 'de
Lijn' updaten, ja dan is het
zinloos de gegevens van de Lijn te gebruiken.
Het probleem van nodes en relaties is een ook een p
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
datab
Op 18 oktober 2010 16:00 schreef Ben Laenen het
volgende:
> Ivo De Broeck wrote:
> > a) Aparte (gelockte) layer met bushalten is toch mogelijk??
>
> Wat zijn we nu met een aparte database? Het is juist het punt dat dit in
> OSM
> kan worden gezet, en niet zo ergens in een aparte database rondzwee
Ivo De Broeck wrote:
> a) Aparte (gelockte) layer met bushalten is toch mogelijk??
Wat zijn we nu met een aparte database? Het is juist het punt dat dit in OSM
kan worden gezet, en niet zo ergens in een aparte database rondzweeft.
> b) Automatische import is toch oplosbaar?? (met oa conversie v
a) Aparte (gelockte) layer met bushalten is toch mogelijk??
b) Automatische import is toch oplosbaar?? (met oa conversie van
Lambert-coordinaten, omzetting naar OSM-eigenschappen)
WAT is het probleem? Wil je oplossingen zal je moeten bepalen wat mogelijk
is en niet blijven naar "De Lijn" wijzen.
Ivo De Broeck wrote:
> Wat ze bedoelen is wel duidelijk. Ik snap niet waarom we niet kunnen
> garanderen dat de door hun geleverde (en upgedate) informatie over
> bushokjes automatisch zal ingevoerd worden (want dat vragen ze juist). Ik
> zie niet in wat die toevallige mapper daar mee te maken heef
Wat ze bedoelen is wel duidelijk. Ik snap niet waarom we niet kunnen
garanderen dat de door hun geleverde (en upgedate) informatie over bushokjes
automatisch zal ingevoerd worden (want dat vragen ze juist). Ik zie niet in
wat die toevallige mapper daar mee te maken heeft. Zoals je terecht opmerkt
z
Ivo De Broeck wrote:
> Op 18 oktober 2010 11:27 schreef Jo het volgende:
> > Fase1: alle plaatsen waar er een vaste halteplaats voorzien is ingeven
>
> en de informatie up-to-date houden met bv shelter = yes/no (de lijn bouwt
> regelmatig nieuwe bushokjes) en natuurlijk actief=yes/no (dus en fase
Op 18 oktober 2010 11:27 schreef Jo het volgende:
> Aangezien het onmogelijk is om wat zij blijkbaar verlangen, zo maar op
> 1-2-3 te doen, zouden we hen het volgende kunnen voorstellen.
>
> Fase1: alle plaatsen waar er een vaste halteplaats voorzien is ingeven
>
en de informatie up-to-date houd
Aangezien het onmogelijk is om wat zij blijkbaar verlangen, zo maar op 1-2-3
te doen, zouden we hen het volgende kunnen voorstellen.
Fase1: alle plaatsen waar er een vaste halteplaats voorzien is ingeven
Fase2: alle busroutes zoals deze normaal rijden ingeven (en up-to-date
houden)
Fase3: voor all
voor de duideljikheid zal ik hen nogmaals quoten da werkt makkelijker ;-)
"Totnutoe zijn we nog steeds niet overtuigd van de
aansprakelijkheidsgaranties die gebaseerd blijven op basis van best
effort."
Dit is werkelijk een giller :-)
Mss moet je hen eens zeggen dat Belgacom dit principe hanteert
Lees de tweede lijn van het gequote antwoord in de eerste mail van deze
thread nog 's. Best effort doesn' t cut it...
Jo
Op 13 oktober 2010 17:15 schreef Philippe Duthoit <
philippe.duth...@gmail.com> het volgende:
> kun je de Lijn niet voorstellen dat dit onder best-effort kan vallen (net
> zoa
kun je de Lijn niet voorstellen dat dit onder best-effort kan vallen (net
zoals men bij dsl lijnen doet) ?
2010/10/8 Jo
> Het antwoord van De Lijn dat ' k hier gepost heb, komt eigenlijk neer op:
> het ziet er wel interessant uit wat jullie doen, maar wij zien het niet
> zitten om jullie bij jul
2010/10/9 Luc Van den Troost :
> Men zou daarvoor in OSM een systeem moeten hebben dat bepaalde data 'locked'
> voor editeren door om het even wie. Iets wat - denk ik - in OSM nog niet
> bestaat, maar bv. al wel in wikipedia is geimplementeerd.
locked data in OSM is nog al op de internationale mai
Men zou daarvoor in OSM een systeem moeten hebben dat bepaalde data 'locked'
voor editeren door om het even wie. Iets wat - denk ik - in OSM nog niet
bestaat, maar bv. al wel in wikipedia is geimplementeerd.
Op die manier zou 'betrouwbare externe info' kunnen worden geimporteerd in
OSM zonder dat
Het antwoord van De Lijn dat ' k hier gepost heb, komt eigenlijk neer op:
het ziet er wel interessant uit wat jullie doen, maar wij zien het niet
zitten om jullie bij jullie inspanningen te helpen. Ook al zou dat betekenen
dat de informatie waarover jullie beschikken op kortere termijn accurater
zo
Jo wrote:
> Ik heb De Lijn nog 's gekontakteerd ivm informatie over hun haltes en evt.
> busroutes. Ik kreeg dezelfde standaardmail als iemand anders op deze
> mailing list, wat me in eerste instantie wel bemoedigend leek.
>
> Daarin vragen ze echter om 'garanties'. Iets wat we hen gewoonweg nie
Jo schreef:
Hallo,
Ik heb De Lijn nog 's gekontakteerd ivm informatie over hun haltes en
evt. busroutes. Ik kreeg dezelfde standaardmail als iemand anders op
deze mailing list, wat me in eerste instantie wel bemoedigend leek.
Ik vind dit bericht op usenet;
Transport data
Van:
Rad (virgin
Hallo,
Ik heb De Lijn nog 's gekontakteerd ivm informatie over hun haltes en evt.
busroutes. Ik kreeg dezelfde standaardmail als iemand anders op deze mailing
list, wat me in eerste instantie wel bemoedigend leek.
Daarin vragen ze echter om 'garanties'. Iets wat we hen gewoonweg niet
kunnen geve
34 matches
Mail list logo
