Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
++ 08/07/09 13:51 +0200 - Philip Homburg: Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Bij de fouten die ik tegen komt bij het gebruik van route software is juist wel lokale kennis vereist. Om een voorbeeld te geven, het stukje fietspad waarmee je de Holterbergweg kan oversteken ontbrak voor een deel (zie http://tile.openstreetmap.nl/?zoom=18lat=52.3135lon=4.9351layers=B0FF). Dat kom je pas tegen als je daar langkomt. Ik noemde het ik ken de omgeving vooral ook omdat als je weet hoe je van A naar B moet en je krijgt een andere route van de routeplanner terug, je goed kunt beoordelen of de route van de planner een omweg maakt door een missende tag of highway, of dat jijzelf nooit de handigste route genomen hebt. Ik gebruik nog wel eens een routeplanner om te controleren of de gesuggereerde route een goede is - en daarmee of de data in OSM op orde is. Ik vraag me af hoeveel fietspaden die langs andere wegen lopen netjes met oneway getagd zijn. Goed punt. :) -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
keepright hoort eigenlijk in de editor te zitten. In een electronica printplaat teken programma zit bv een rulebase die zorgt dat je geen illegale dingen doet of tenminste erop geattendeerd wordt. Zoiets dergelijks zou je ook in onze editors moeten hebben. Rob Op 8 juli 2009 10:55 schreef Rejo Zenger osm-talk...@subs.krikkit.nl het volgende: ++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBSlRfDwmUCUYh2+/UAQiYzg/+MHsOm0aoQ8hU99lDNqAqfwkzR38rvgFP 1PcueJJ3walydgiqKsCaAFKWESY5hPvDe7+5Xsagm1OzUPKqFFv4a/Iy6zXS/0nm PONRfCpayBv8B/cTCWgH3BGaw/Q5wVSrwosP2kIkkECCEW/cQeD4XzjvGY83LplW btHeGlYzFIehBGq6zY1B0RGJQykzxrxgdM5bswp5hVYsIJpTD21zlTSwlxcFDGl1 +KeKJox9TB7M5jIL0s84YO6odlFx9D8VlC5CWHYPihkwVr3skZSgi8wjzmQVLC3v 6vN2eYScD8CEfOrkSNg3NfNc0D4yJ/21aHq6vZLYBJ6n4bDf5RhWxMeQqpemTJri tpPkr0AGcaezkud9K77TmAsSbltQZ/rsbkCL7IkFtfx/i0P0i7czlIAUzVWr0AQt FspDUrhpl3Zl+So5WyjHLA+BGvp1lCbyovrYZ9dXQgfnEe3c9BGip+TAyKmywYPe YF2pjLbr48RkKb/hgwXBURg2sttpFXznvfI3BL+AiX8JCMO3nOxqrNc+xH0VWmPF /40hj+ECGTW10H3rotnW+ZW069MwfC5Lc+OM8ld3aPyHw8KSBy58dLobydXH60hX tTI+av7LXbsWWHTkpuZpzajlEXkF/EZtzFyglxCjq3M0tO5o0NT/ewbSlIhbO8aC jtvc5JDYI+Q= =X6EA -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. Kun je eens wat voorbeelden noemen? Een paar voorbeelden: - Ik heb gisteren bij mij in de buurt een paar oneway tags weggehaald. Op een of andere manier is de AND data daar erg verouderd. - De tagging standaards zijn gewoon fout. Voor een verboden in te rijden voor motorvoertuigen op meer dan twee wielen staat (op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging): motor_vehicle=no motorcycle=yes moped=yes mofa=yes Dat klopt niet want dan is de weg in beide richting afgesloten. In de praktijk wordt een oneway tag gebruikt, maar wat doe je dan weer met fietsen? - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Kijk, ik kan niet zoveel doen aan het de code van die route planner, dus als daarmee iets verkeerd is houd het op. Maar, als er dingen verkeerd gerouteerd worden omdat de tagging van de straten niet correct is, dan kan ik daar wel iets mee doen. Zeker als in het in een omgeving is die ik ken. Ik fix wat ik tegenkom. Maar ik moet eigenlijk zorgen dat ik altijd GPS logger bij me heb. Want soms kom ik wegen tegen die niet in OSM zitten, en dan is het toch wel handig om een trace te hebben. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Tue, 7 Jul 2009, Philip Homburg wrote: Dat ligt niet aan de routeplanners maar aan de data. Werk aan de winkel dus! Dat klopt niet. Ik heb redelijk veel met http://yournavigation.org/ gespeeld (die natuurlijk gosmore als backend heeft) en recenter met ANDNAV2. En in beide gevallen zie je dat de navigatie software heel veel steken laat vallen. Heb je ook de andere 2 webrouteplanners bekeken? http://www.openrouteservice.org/ Deze is (voor zover ik weet) nog steeds niet helemaal open source ook al is ooit beloofd dat dit binnenkort zou gebeuren, op http://www.freeopenls.org/ De andere is http://www.cloudmade.com/ maar die doet het niet in mijn webbrowser. Met ORS ben ik tot nu toe eigenlijk alleen data fouten tegengekomen voor fietsrouting. Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. [zie volgende mail] Misschien is fiets/voetganger/etc. routing een goede applicatie is als niemand anders dat zo compleet aanbiedt als de osm/web-based routers. Met compleet bedoel ik zowel detail (fietsbruggen etc. die niet in google maps zitten) als geografische dekking (Europa of de hele wereld, terwijl de fietsersbond applicatie hoogstens heel nederland doet). Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. Kun je eens wat voorbeelden noemen? Een paar voorbeelden: - De tagging standaards zijn gewoon fout. Voor een verboden in te rijden voor motorvoertuigen op meer dan twee wielen staat (op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging): motor_vehicle=no motorcycle=yes moped=yes mofa=yes Dat klopt niet want dan is de weg in beide richting afgesloten. In de praktijk wordt een oneway tag gebruikt, maar wat doe je dan weer met fietsen? Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Problematischer om te taggen vind ik een combinatie die ik op dezelfde rit tegenkwam: een onverplicht fietspad bord met daaronder 'uitgezonderd X' (aanwonenden ofzo). Dat is eigenlijk geen access tag maar een conditionele highway tag. - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Sommige dingen zitten al in Validator, maar daar wordt niet vanuit een autorouter oogpunt naar gekeken. Mijn ervaring is dat op dat punt de data gemiddeld genomen behoorlijk goed is. Er zitten wel foutjes in die een validator kan vinden maar het is een relatief laag percentage. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Bij de fouten die ik tegen komt bij het gebruik van route software is juist wel lokale kennis vereist. Om een voorbeeld te geven, het stukje fietspad waarmee je de Holterbergweg kan oversteken ontbrak voor een deel (zie http://tile.openstreetmap.nl/?zoom=18lat=52.3135lon=4.9351layers=B0FF). Dat kom je pas tegen als je daar langkomt. Eigenlijk zou het stuk fietspad aan de noordoostzijde van de Holterbergweg tijdelijk weggehaald moeten worden omdat het op dit moment ontoegankelijk is. Ik vraag me af hoeveel fietspaden die langs andere wegen lopen netjes met oneway getagd zijn. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest de straat ook echt verbodsborden hebben langs één zijde en geen gewone enkelrichtingsborden. - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorieën juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet aanzien wordt als verplicht fietspad door de routeplanner. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is (vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk als je hen alles expliciet laat taggen. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
2009/7/8 Christiaan Welvaart c...@daneel.dyndns.org: - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Vergeet dan niet een foot=yes op het fietspad, want in elk geval yournavigation.org gaat er default van uit dat je op een fietspad niet mag lopen... -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Ben Laenen schreef: Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Volgens de wiki is in dit geval oneway=yes cycleway=opposite ook een oplossing. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorieën juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). In dat geval is foot=no natuurlijk een slecht idee: als voetgangers de weg (of de berm) mogen gebruiken, kan je foot=no weglaten. Maar bicycle=no op de hoofdweg is in dit geval wel de goede tag, volgens mij. Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Een routeplanner kan niet raden of een fietspad verplicht (rond blauw bord met fiets) of onverplicht (rechthoekig zwart bord met FIETSPAD) is. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Slecht idee. Fietpaden die aangegeven worden door het bord onverplicht fietspad zijn ook fietspaden. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Andre Engels wrote: 2009/7/8 Christiaan Welvaart c...@daneel.dyndns.org: - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Vergeet dan niet een foot=yes op het fietspad, want in elk geval yournavigation.org gaat er default van uit dat je op een fietspad niet mag lopen... Met http://yournavigation.org probeer ik de algemene routing regels te volgen totdat Gosmore afwijkende regels per land om kan gaan: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Default ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Eugene van der Pijll wrote: Ben Laenen schreef: Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Volgens de wiki is in dit geval oneway=yes cycleway=opposite ook een oplossing. Maar dan zit je met problemen als ook andere voertuigen tegen de richting mogen (in België bromfietsers klasse A, ofwel moped_A:oneway=no) In dat geval is foot=no natuurlijk een slecht idee: als voetgangers de weg (of de berm) mogen gebruiken, kan je foot=no weglaten. Maar bicycle=no op de hoofdweg is in dit geval wel de goede tag, volgens mij. Alleen mogen die ook de weg op: fietspad onderbroken bijvoorbeeld, of als je moet afslaan. Ook als het verplicht fietspad links ligt hoef je die niet te volgen als je daar een reden voor hebt (wederom Belgische regels, weet niet in hoeverre alles naar Nederland kan gebracht worden). Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Een routeplanner kan niet raden of een fietspad verplicht (rond blauw bord met fiets) of onverplicht (rechthoekig zwart bord met FIETSPAD) is. Dan zorg je ervoor dat die het kán raden door ze anders te taggen. Me dunkt dat er ook nog andere regels zijn die verschillen tussen verplicht en onverplicht fietspad, dus het is sowieso zinvol van dat te doen. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Slecht idee. Fietpaden die aangegeven worden door het bord onverplicht fietspad zijn ook fietspaden. Ik doel vooral op het feit dat een pad vaak als cycleway wordt ingegeven terwijl het geen fietspad is (verplicht of onverplicht). Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest de straat ook echt verbodsborden hebben langs ??n zijde en geen gewone enkelrichtingsborden. Daar ging het hier over, het eerste verbodsbord op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging . Nu maak je de discussie nodeloos ingewikkelder ): - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorie?n juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). In NL moeten voetgangers het verplichte fietspad gebruiken! Dit staat ook op die wiki pagina. Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Dat vind ik te veel werk voor een routeplanner om uit te zoeken. Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet aanzien wordt als verplicht fietspad door de routeplanner. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dit heb ik op de wiki pagina http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging ook zo aangegeven voor het onverplichte fietspadbord. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is (vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk als je hen alles expliciet laat taggen. Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. country specific access tag semantics for routing, dat bestaat al hoor. Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op highway=cycleway, in land Y niet. access=destination is van toepassing op fietsers in land X, en niet in land Y. In België is moped zowel voor bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in je land niet nodeloos moeilijk te maken om het te proberen in te passen in een internationale omgeving, een utopie die niet mogelijk is omdat het al anders is in elk land. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. country specific access tag semantics for routing, dat bestaat al hoor. Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op highway=cycleway, in land Y niet. access=destination is van toepassing op fietsers in land X, en niet in land Y. In België is moped zowel voor bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort. Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor elk land-project want dat noem ik eerder chaos. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. je land niet nodeloos moeilijk te maken om het te proberen in te passen in een internationale omgeving, een utopie die niet mogelijk is omdat het al anders is in elk land. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
In your letter dated Wed, 8 Jul 2009 13:35:28 +0200 (CEST) you wrote: Heb je ook de andere 2 webrouteplanners bekeken? http://www.openrouteservice.org/ Deze is (voor zover ik weet) nog steeds niet helemaal open source ook al is ooit beloofd dat dit binnenkort zou gebeuren, op http://www.freeopenls.org/ De andere is http://www.cloudmade.com/ maar die doet het niet in mijn webbrowser. Met ORS ben ik tot nu toe eigenlijk alleen data fouten tegengekomen voor fietsrouting. Nee, ik probeer zoveel mogelijk opensource te gebruiken. Maar ik zou ze vaker moeten proberen om te kijken of er interessante verschillen zijn. Ik probeerde voor de grap even Amsterdam-Stadskanaal, en ORS gaat via de Afsluitdijk, dus dat is niet optimaal. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Dat zou kunnen, maar persoonlijk zou ik liever zien dat daar een relatie voor komt en dat de routing software het dan uitzoekt. Dat zou ook bij een ventweg de extra naam schelen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: On Wed, 8 Jul 2009, Ben Laenen wrote: En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. Gosmore heeft dat idd niet en volgens mij de meeste niet. Voor zover ik de applicaties bekeken heb zijn er nauwelijks routers die internationaal georienteerd zijn, laat staan de data van meerdere landen kunnen behappen. Maar mijn ervaring is dat dit soort functies ontstaan zodra een grote hoeveelheid data in OSM er klaar voor is wat dus nu ongeveer is. Kijk dus niet verbaasd als land specifieke routing over een half jaar wel redelijk kan. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart schreef: Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dat is volgens mij niet wat designated betekent. Het betekent bedoeld voor, aangewezen voor; in OSM-termen: wat er op het bordje staat. Bijv. een fietspad in NL is designated voor fietsers, en ook te gebruiken voor voetgangers. Heeft niets te maken met het onderscheid verplicht/onverplicht voor fietsers, volgens mij. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. +1. Zelfs als er een andere manier is om hetzelfde te taggen: een bicycle=no tag op de hoofdrijbaan is nooit verkeerd; er mag namelijk niet gefietst worden. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Christiaan Welvaart wrote: Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor elk land-project want dat noem ik eerder chaos. Welja, elk land heeft zijn eigen verschillende regels en dus bestaat het de facto. Of dat nu ergens expliciet in de wiki staat geschreven of niet, impliciet staat het er alleszins op alle landenpagina's. Maar als je het wil proberen veranderen, ik hou je niet tegen. Maar ik denk dat je een utopie probeert te bereiken daarmee. Voertuigtypes ga je nooit kunnen gelijk trekken over de hele wereld. Wat hier onder motorfiets is, is ergens anders een auto, of een bromfiets die een motorfiets is in een bepaald land. Dat is probleem 1 dus. Probleem 2 is dat de verkeersborden net iets andere betekenissen hebben in sommige landen. Neem nu bijvoorbeeld access=destination: in België betekent het dat voetgangers, fietsers en ruiters onverminderd toegang hebben tot die weg. Moeten we dan steeds expliciet foot=yes, bicycle=yes en horse=yes toevoegen enkel omdat die in land X niet de weg inmogen bij access=destination, terwijl zo'n situatie hier niet eens kán voorkomen? En terwijl veel mensen hier niet eens weten dat fietsers en ruiters daar altijd inmogen, en die die extra tags zo zouden vergeten. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. Sorry, ik wou zeggen ... en routers al een lijst *zouden moeten* hebben van regels voor elk land Maar ik zie liever een OSM-library die routers en wat weet ik nog allemaal kunnen gebruiken zodat al die regels op één plaats zijn samengebracht. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Dat zou kunnen, maar persoonlijk zou ik liever zien dat daar een relatie voor komt en dat de routing software het dan uitzoekt. Dat zou ook bij een ventweg de extra naam schelen. Er zijn natuurlijk ook heel veel situaties waar wel een verbodsbord bij de hoofdrijbaan staat, soms overbodig. Hiervoor zal je meestal toch access tags op de weg moeten zetten, wat betekent dat de toegankelijkheid van een weg voor een bepaald voortbewegingsmiddel op minstens 2 manieren beschreven kan zijn. Dit lijkt een voorstel in deze richting te zijn: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Eugene van der Pijll wrote: Christiaan Welvaart schreef: Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dat is volgens mij niet wat designated betekent. Het betekent bedoeld voor, aangewezen voor; in OSM-termen: wat er op het bordje staat. Wel, niemand weet het echt wat access=designated betekent. In Duitsland wisten ze het ook niet meer omdat iedereen het anders toepaste en maken ze het nu nog wat moeilijker met een access=official tag in te voeren. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. +1. Zelfs als er een andere manier is om hetzelfde te taggen: een bicycle=no tag op de hoofdrijbaan is nooit verkeerd; er mag namelijk niet gefietst worden. Kijk, als het fietspad verplicht is, dan is dat een eigenschap van dat fietspad, en moet je dat oplossen met tags op dat fietspad. Voor België is highway=cycleway genoeg om te zeggen dat er een verplicht fietspad is zodat als een router zo'n weg parallel ziet aan een andere weg, die kan weten dat fietsers niet via de weg kunnen (maar ook nog kan weten dat die fietser in bepaalde gevallen ook nog wel de rijbaan opmag moest de situatie daarom vragen -- tenzij er een verbodsbord staat om een of andere reden, waarbij je dus bicycle=no nodig hebt). Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ik probeerde voor de grap even Amsterdam-Stadskanaal, en ORS gaat via de Afsluitdijk, dus dat is niet optimaal. Lijkt idd een fout in de routing app want door waypoints toe te voegen kan ik de reistijd korter maken. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Check deze: http://www.routeware.dk/topology/topologychecker.php Dit zijn functies die je nodig hebt om een netwerk sane te maken. Rob wrote: keepright hoort eigenlijk in de editor te zitten. In een electronica printplaat teken programma zit bv een rulebase die zorgt dat je geen illegale dingen doet of tenminste erop geattendeerd wordt. Zoiets dergelijks zou je ook in onze editors moeten hebben. Rob Op 8 juli 2009 10:55 schreef Rejo Zenger osm-talk...@subs.krikkit.nl mailto:osm-talk...@subs.krikkit.nl het volgende: ++ 08/07/09 10:51 +0200 - ce-test, qualified testing bv - Gert Gremmen: Er moet een programma komen dat systematisch de database controleert op route-onmogelijkheden. Wegen die niet aansluiten op zijwegen, kapotte rotondes, breuken in wegen, tegenstrijdige access rules, rare eenrichtingswegen, kruisingen die elkaar niet echt raken. [...] Dat is er al en dat heet Keep Right. Ik gebruik dat al regelmatig en een van mijn targets op dit moment is het wegwerken van alle fouten in mijn regio die door de verschillende validators worden genoemd. Fixen op basis van ik ken de omgeving is natuurlijk nooit voldoende om alle data op te poetsen, vooral omdat je de fouten vaak niet ziet. Nee, maar wel een begin. :) -- Rejo Zenger . r...@zenger.nl mailto:r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBSlRfDwmUCUYh2+/UAQiYzg/+MHsOm0aoQ8hU99lDNqAqfwkzR38rvgFP 1PcueJJ3walydgiqKsCaAFKWESY5hPvDe7+5Xsagm1OzUPKqFFv4a/Iy6zXS/0nm PONRfCpayBv8B/cTCWgH3BGaw/Q5wVSrwosP2kIkkECCEW/cQeD4XzjvGY83LplW btHeGlYzFIehBGq6zY1B0RGJQykzxrxgdM5bswp5hVYsIJpTD21zlTSwlxcFDGl1 +KeKJox9TB7M5jIL0s84YO6odlFx9D8VlC5CWHYPihkwVr3skZSgi8wjzmQVLC3v 6vN2eYScD8CEfOrkSNg3NfNc0D4yJ/21aHq6vZLYBJ6n4bDf5RhWxMeQqpemTJri tpPkr0AGcaezkud9K77TmAsSbltQZ/rsbkCL7IkFtfx/i0P0i7czlIAUzVWr0AQt FspDUrhpl3Zl+So5WyjHLA+BGvp1lCbyovrYZ9dXQgfnEe3c9BGip+TAyKmywYPe YF2pjLbr48RkKb/hgwXBURg2sttpFXznvfI3BL+AiX8JCMO3nOxqrNc+xH0VWmPF /40hj+ECGTW10H3rotnW+ZW069MwfC5Lc+OM8ld3aPyHw8KSBy58dLobydXH60hX tTI+av7LXbsWWHTkpuZpzajlEXkF/EZtzFyglxCjq3M0tO5o0NT/ewbSlIhbO8aC jtvc5JDYI+Q= =X6EA -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Een routeplanner voor voetgangers, fietsers en automobilisten. De gebruiker kan op meerdere manieren een route samenstellen. Dat kan gebeuren door een tweetal punten aan te wijzen en de korste of snelste weg te genereren, Dat kan door gepreparereerde routes te bekijken en selecteren (fietsroutes, wandelroutes, etc). Op zich ben ik het met je eens dat OSM veel te gefragmenteerd is. Maar wat ik zelf als een veel groter probleem zie is dat veel van de onderliggende infrastructuur nog in de kinderschoenen staat. Mijn ervaring is dat op OSM gebaseerde routeplanners gewoon speelgoed zijn. Heel leuk speelgoed, maar zeker niet betrouwbaar genoeg voor de gemiddelde consument. Hetzelfde geldt voor de database: het is een enorme brei met data waar je maar moeilijk wijs uit wordt. Hoe meer POI's er in een gebied te vinden zijn, hoe moeilijker het wordt om in JOSM (maar ook via de data layer van de website) te begrijpen hoe de wereld in elkaar zit. Het lijkt me heel goed om na te denken hoe OSM zo toegankelijk mogelijk gemaakt kan worden. Maar ik denk ook dat het belangrijk is om aan een groot publiek alleen die delen van OSM te laten zien die echt heel goed zijn. Om een voorbeeld te noemen, ik ben blij met de ANDNAV2 navigatie software voor de Android. Het is, in ieder geval van wat ik gezien heb, de beste route software voor OSM. Maar in vergelijking TomTom is het gewoon helemaal niets. De embedder stelt een eindgebruiker in staat om met een paar eenvoudige handelingen een kaart op de eigen website te plaatsen. De gebruiker moet een track bestand kunnen opgeven, of zelf punten kunnen aanklikken. De gegenereerde code moet volledig zijn. De gebruiker kan dus aan- of uitvinken of een grote of kleine navigator gewenst is en de licentie wordt automagisch goed getoond. Denk niet alleen aan websites, maar ook aan bijvoorbeeld presentaties (markeren van een polygoon area en dat als jpg kunnen opslaan voor gebruik in Keynote). Ik denk dat dit in ieder geval een goed punt is. Zeker in Nederland is de kaart van OSM erg goed. Hoewel er waarschijnlijk eerst wel eens door een Nederlandse grafisch ontwerper naar het kleur gebruik gekeken moet worden. Zelf heb ik m'n eigen scripts (zie bijv. http://stereo.hq.phicoh.net/biking/maps/2009-06-20.shtml voor het resultaat), maar het zou beter zijn als iedereen gemakkelijk zo'n kaartje zou kunnen maken. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
++ 07/07/09 15:27 +0200 - Philip Homburg: Een routeplanner voor voetgangers, fietsers en automobilisten. De gebruiker kan op meerdere manieren een route samenstellen. Dat kan gebeuren door een tweetal punten aan te wijzen en de korste of snelste weg te genereren, Dat kan door gepreparereerde routes te bekijken en selecteren (fietsroutes, wandelroutes, etc). Op zich ben ik het met je eens dat OSM veel te gefragmenteerd is. Maar wat ik zelf als een veel groter probleem zie is dat veel van de onderliggende infrastructuur nog in de kinderschoenen staat. [...] Juist. Daarom schreef ik ook: | Een paar van de doelen die ik mezelf zou zetten zijn het verhogen van | gebruiksgemak, het verhogen van de herkenbaarheid en het verbeteren van | de bekendheid van OpenStreetMap. Belangrijke middelen daarvoor zijn, | IMHO, een interface die eenduidig en uniform is, die de gebruiker met | een beperkt aantal heldere stappen de informatie die gebruiker wil | teruggeeft en die correct is. Het gebruiksgemak gaat over mooie buttons die op een praktische manier in een doordachte workflow gepropt zitten, maar ook over de informatie die teruggegeven wordt. Een routeplanner met een goede interface zal niet aanslaan als deze geen bruikbare route teruggeeft. En, het voorbeeld dat ik gaf was niet meer dan dat: een voorbeeld. Ik zeg niet dat we het zo moeten doen. Als we tot de conclusie komen dat routering geen optie is, laten we dan de rest wel al doen (en goed!). En laten we die rest zo doen dat routering er in een later stadium alsnog bij kan. Hetzelfde geldt voor de database: het is een enorme brei met data waar je maar moeilijk wijs uit wordt. Hoe meer POI's er in een gebied te vinden zijn, hoe moeilijker het wordt om in JOSM (maar ook via de data layer van de website) te begrijpen hoe de wereld in elkaar zit. Juist. Dat is dan ook een van de voornaamste problemen die ik noemde. Er zit veel en waardevolle data in de OSM database, maar de ontsluiting is een ramp. Aan de kant van de editors, maar ook aan de kant van de eind- gebruikers. Zelf heb ik m'n eigen scripts (zie bijv. http://stereo.hq.phicoh.net/biking/maps/2009-06-20.shtml voor het resultaat), maar het zou beter zijn als iedereen gemakkelijk zo'n kaartje zou kunnen maken. Ik heb al eens iets gebouwd dat mensen in staat stelt om hun GPX file op snelle en makkelijke manier te tonen (dat is wat je bedoelde denk ik). Zie https://rejo.zenger.nl/topo/embed-osm-and-track-in-webpage.php voor een uitleg. Basically: https://rejo.zenger.nl/topo/osm/?fn=url-of-gpx-file;. Er zijn nog wel wat dingen die uitgebreid moeten worden, waypoints worden nog niet getoond bijvoorbeeld. Maar, het is misschien leuk dat dat er is, meer dan een quick 'n' dirty speeltje is het niet. Het is gewoon weer een semi-handige interface naar die data van OSM. En dat is niet wat nodig is. Ik wil die dingen graag samenvoegen en verbeteren. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Philip Homburg wrote: Een routeplanner voor voetgangers, fietsers en automobilisten. De gebruiker kan op meerdere manieren een route samenstellen. Dat kan gebeuren door een tweetal punten aan te wijzen en de korste of snelste weg te genereren, Dat kan door gepreparereerde routes te bekijken en selecteren (fietsroutes, wandelroutes, etc). Op zich ben ik het met je eens dat OSM veel te gefragmenteerd is. Maar wat ik zelf als een veel groter probleem zie is dat veel van de onderliggende infrastructuur nog in de kinderschoenen staat. Dat is niet waar, de infrastructuur is best solide. Maar net zo gefragmenteerd als de overige initiatieven. Met name onduidelijkheid over teams die verantwoordelijkheid hebben over bepaalde bouwstenen van de OSM infrastructuur is een probleem. Mijn ervaring is dat op OSM gebaseerde routeplanners gewoon speelgoed zijn. Heel leuk speelgoed, maar zeker niet betrouwbaar genoeg voor de gemiddelde consument. Dat ligt niet aan de routeplanners maar aan de data. Werk aan de winkel dus! Hetzelfde geldt voor de database: het is een enorme brei met data waar je maar moeilijk wijs uit wordt. Hoe meer POI's er in een gebied te vinden zijn, hoe moeilijker het wordt om in JOSM (maar ook via de data layer van de website) te begrijpen hoe de wereld in elkaar zit. Dan moeten we met zijn allen zorgen dat we er beter wijs uit worden ;-) Het lijkt me heel goed om na te denken hoe OSM zo toegankelijk mogelijk gemaakt kan worden. Maar ik denk ook dat het belangrijk is om aan een groot publiek alleen die delen van OSM te laten zien die echt heel goed zijn. De kreet OSM is hierin te algemeen. De OSM database is de kern. Die verantwoordelijkheid ligt bij de OpenStreetMap Foundation. De afgeleide producten zoals de xapi, de tileservers, de extracten en de diverse applicaties liggen NIET bij de OSMF. Hiervoor moet je inderdaad af en toe flink zoeken in het oerwoud. Wij, de stichting OpenGeo, proberen maatschappelijk relevante initiatieven te steunen in de weg naar volwassenheid, vertaling naar het Nederlands en faciliteren middels hosting. Om een voorbeeld te noemen, ik ben blij met de ANDNAV2 navigatie software voor de Android. Het is, in ieder geval van wat ik gezien heb, de beste route software voor OSM. Maar in vergelijking TomTom is het gewoon helemaal niets. Dat ligt er zomaar aan waar op de wereld je bent. Wij zijn in Nederland gewoon tot op het bot verwend met het feit dat TeleAtlas ons land economisch interessant genoeg vindt voor het inwinnen en beschikbaar stellen van data. En TomTom heeft hier van geprofiteerd. Met Garmin Mobile XT en de openstreetmap data van Aruba heb ik een routerings applicatie op dat mooie eiland. En op Aruba heb je met TomTom gewoon helemaal niks. Kwestie van perspectief zullen we maar zeggen. Alles hangt of staat met de data. De embedder stelt een eindgebruiker in staat om met een paar eenvoudige handelingen een kaart op de eigen website te plaatsen. De gebruiker moet een track bestand kunnen opgeven, of zelf punten kunnen aanklikken. De gegenereerde code moet volledig zijn. De gebruiker kan dus aan- of uitvinken of een grote of kleine navigator gewenst is en de licentie wordt automagisch goed getoond. Denk niet alleen aan websites, maar ook aan bijvoorbeeld presentaties (markeren van een polygoon area en dat als jpg kunnen opslaan voor gebruik in Keynote). Ik denk dat dit in ieder geval een goed punt is. Zeker in Nederland is de kaart van OSM erg goed. Hoewel er waarschijnlijk eerst wel eens door een Nederlandse grafisch ontwerper naar het kleur gebruik gekeken moet worden. Zelf heb ik m'n eigen scripts (zie bijv. http://stereo.hq.phicoh.net/biking/maps/2009-06-20.shtml voor het resultaat), maar het zou beter zijn als iedereen gemakkelijk zo'n kaartje zou kunnen maken. Deze kartograaf (Ja, ik mag die titel dragen met een ing. er bij ;-)) heeft even naar jou kaart gekeken maar denkt dat ook daar nog wel iets over de labels kan worden gezegd. Kaarten moeten worden toegespitst op het gebruik en zolang we één generieke kaart renderen waar alle andere initiatieven op moeten worden gedrapeerd is nog niet alles optimaal. Hiervan zijn we ons bewust en er wordt dan ook gewerkt aan b.v.: - Tile omgevingen zonder labels - Tile omgevingen in grijstinten - Tile omgevingen zonder POI's Ik zou zeggen sluit je aan! Denk mee, doe mee. Wellicht kun je helpen om uiteindelijk te zorgen dat zaken écht een succes worden want dat is de kracht van de community. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Beste Philip, Je hebt bepaalde ideëen over wat er mis is, heb je ook gedachten over hoe dit zou kunnen worden verbeterd? Heb je een bepaald onderdeel waarvan jij zegt; als je daar de focus legt, dan wordt het echt een grandioos succes? Philip Homburg wrote: Dat is niet waar, de infrastructuur is best solide. Maar net zo gefragmenteerd als de overige initiatieven. Met name onduidelijkheid over teams die verantwoordelijkheid hebben over bepaalde bouwstenen van de OSM infrastructuur is een probleem. Solide in de zin dat de database zelf niet down gaat, dat klopt (en dat is natuurlijk ook heel belangrijk). Solide in de zin dat er een duidelijk model is hoe je met OSM data om moet gaan is het denk ik niet. Een heleboel dingen moeten duidelijk nog langzaam groeien. Dat is niet erg. Maar je moet dan wel oppassen welke groepen gebruikers je gaat benaderen. Dat ligt niet aan de routeplanners maar aan de data. Werk aan de winkel dus! Dat klopt niet. Ik heb redelijk veel met http://yournavigation.org/ gespeeld (die natuurlijk gosmore als backend heeft) en recenter met ANDNAV2. En in beide gevallen zie je dat de navigatie software heel veel steken laat vallen. Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. De kreet OSM is hierin te algemeen. De OSM database is de kern. Die verantwoordelijkheid ligt bij de OpenStreetMap Foundation. De afgeleide producten zoals de xapi, de tileservers, de extracten en de diverse applicaties liggen NIET bij de OSMF. Hiervoor moet je inderdaad af en toe flink zoeken in het oerwoud. Ik denk dat OSM community meer moet doen dan alleen de database. Het is prima als de OpenStreetMap Foundation alleen de database doet, maar dan moet je een andere wereldwijde organisatie opzetten voor de rest. Juist omdat OSMF geen applicaties doet is het op sommige punten zo gefragmenteerd. Dat ligt er zomaar aan waar op de wereld je bent. Wij zijn in Nederland gewoon tot op het bot verwend met het feit dat TeleAtlas ons land economisch interessant genoeg vindt voor het inwinnen en beschikbaar stellen van data. En TomTom heeft hier van geprofiteerd. Met Garmin Mobile XT en de openstreetmap data van Aruba heb ik een routerings applicatie op dat mooie eiland. En op Aruba heb je met TomTom gewoon helemaal niks. Kwestie van perspectief zullen we maar zeggen. Alles hangt of staat met de data. Ja, ik had het over Nederland. Ik denk niet dat het veel indruk maakt als je zegt dat OSM op Aruba beter is dan TomTom terwijl iedereen die het uitprobeert er achter komt dat in Nederland OSM het veel slechter doet. Deze kartograaf (Ja, ik mag die titel dragen met een ing. er bij ;-)) heeft even naar jou kaart gekeken maar denkt dat ook daar nog wel iets over de labels kan worden gezegd. Kaarten moeten worden toegespitst op het gebruik en zolang we =E9=E9n generieke kaart renderen waar alle andere initiatieven op moeten worden gedrapeerd is nog niet alles optimaal. Hiervan zijn we ons bewust en er wordt dan ook gewerkt aan b.v.: - Tile omgevingen zonder labels - Tile omgevingen in grijstinten - Tile omgevingen zonder POI's Dat is een goed punt. Ik zou zeggen sluit je aan! Denk mee, doe mee. Wellicht kun je helpen om uiteindelijk te zorgen dat zaken =E9cht een succes worden want dat is de kracht van de community. Voor mij is OSM al lang al een succes. Maar een beetje meer focus kan soms geen kwaad. Er zijn in de Nederlandse OSM community heel veel groepjes die allemaal wat anders doen. Op zich niet erg, ieder z'n hobby, maar het gevolg is wel dat het langer duurt voordat bepaalde aspecten echt volwassen zijn. Het alternatief is om te kijken wat haalbaar is en er dan met een zo groot mogelijk groep aan proberen te werken om dat voor elkaar te krijgen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
Hallo Rejo, Nogmaals, wij willen je steunen als Stichting OpenGeo! Is het een idee om eens een sessie op te zetten om te schetsen, uit te werken en ook de in eerdere mail genoemde leek op het juiste moment te betrekken? Rejo Zenger wrote: Hi, Zie mijn posting van een paar minuten geleden voor de context... Een paar van de doelen die ik mezelf zou zetten zijn het verhogen van gebruiksgemak, het verhogen van de herkenbaarheid en het verbeteren van de bekendheid van OpenStreetMap. Belangrijke middelen daarvoor zijn, IMHO, een interface die eenduidig en uniform is, die de gebruiker met een beperkt aantal heldere stappen de informatie die gebruiker wil teruggeeft en die correct is. Een praktisch voorbeeld? Het hoofscherm is een half-transparante kaart, beeldvullend. De kaart toont de regio van de bezoeker (zoals nu ook al gebeurt). Over de kaart ligt een strook met opties voor gebruikers (grote, duidelijk herkenbare iconen). De voornaamste opties zijn de routeplanner, de POI's en de embedder. Er onder in het klein een regel met een link naar de opties voor extra's en een link naar een pagina met informatie over de licentie. De drie grote opties zouden min of meer heilig moeten zijn. De drie opties moeten zo gekozen worden dat nieuwe modules onder een van deze drie (plus een) categorieen past. De drie opties: Een routeplanner voor voetgangers, fietsers en automobilisten. De gebruiker kan op meerdere manieren een route samenstellen. Dat kan gebeuren door een tweetal punten aan te wijzen en de korste of snelste weg te genereren, Dat kan door gepreparereerde routes te bekijken en selecteren (fietsroutes, wandelroutes, etc). De POI's. De gebruiker geeft zijn locatie op (bij een mobiele toepassing zou je dat automagisch kunnen bepalen) en kan vervolgens opvragen waar de dichtsbijzijnde pinautomaat, brievenbus of moskee staat of waar, in een bepaalde regio, de supermarkten of de op zondagochtend geopende bakkers te vinden zijn. De embedder stelt een eindgebruiker in staat om met een paar eenvoudige handelingen een kaart op de eigen website te plaatsen. De gebruiker moet een track bestand kunnen opgeven, of zelf punten kunnen aanklikken. De gegenereerde code moet volledig zijn. De gebruiker kan dus aan- of uitvinken of een grote of kleine navigator gewenst is en de licentie wordt automagisch goed getoond. Denk niet alleen aan websites, maar ook aan bijvoorbeeld presentaties (markeren van een polygoon area en dat als jpg kunnen opslaan voor gebruik in Keynote). De extra's zijn functies die voor de normale gebruiker niet meteen interesant zijn, maar die we wel makkelijk kunnen bieden op basis van de beschikbare dataset. Ik denk dan bijvoorbeeld aan het tonen van alle soorten grenzen (gemeente, land, waterschap, wijk, provincie, etc), maximum snelheden, het overnemen van kaartmateriaal op een GPS en zaken die voor mensen die profesionele GIS'ers interesant zijn. Als een gebruiker een van de opties geselecteerd heeft, wordt de beeld- vullende kaart op de achtergrond op de voorgegrond getoond en is er een aan de zij- of onderkant een uitschuifbaar menu met de opties en functies. De functies moeten elk intuitief, aantrekkelijk, Ik heb genoeg ideeen voor het uitbreiden hiervan. Als de basis er eenmaal is, kunnen we denken aan onder meer mobiele toepassingen (op je PDA zien welke kroegen er allemaal in de buurt zijn), grote winkelketens krijgen een icoontje voor hun winkel op voorwaarde dat ze een lijst van alle vestigingen geven, combineren met wegwerkzaamheden, gebruikers kunnen fouten melden (vergelijk OSB), gebruikers kunnen een account aanmaken en vaste locaties bookmarken. Omdat Nederland betrekkelijk compleet is, zou het project wat mij betreft zich in eerste instantie vooral op de Nederlandse situatie moeten richten. De bovenstaande modules kunnen nu al zo veel als mogelijk met de internationale situatie indachtig geschreven worden. De code moet in het engels, waar mogelijk overeenkomen met de terminologie van OSM, vertaalbaar en modulair zijn. Uiteraard heb ik nog veel meer ideeen over hoe een en ander ingericht zou kunnen of moeten worden, maar dat alles hier spuien lijkt me zinloos. :) Dit moet ik kunnen maken - maar ik kan het niet alleen. Ik ben geen web developer, geen OSM deskundige, geen usability expert. Ik kan wel *wat*. De vraag is vooral, wie wil en kan hier aan meewerken? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
