Ook namens mij heel veel dank voor al het harde werk!
Ik weet hoe arbeidsintensief het is.
Voel me een beetje beschaamd dat ik de afgelopen tijd helemaal niet aan mappen ben toegekomen terwijl ik dit onderwerp heb aangedragen.
Heb net weer eerst stappen gezet (survey gedaan op net geopend fietspad tussen 41 en 71 en dat op de kaart gezet en verder ook nieuwe wandelknooppunten toegevoegd). Probeer komende week een rondje Voorschoten/Wassenaar/Katwijk/Oegstgeest te maken om te kijken hoe het zit met de paar verschillen tussen PDOK en OSM die nog te zien zijn (oude routes verwijderd?).
Of is voor jou al helder hoe het zit of heb je hier nog andere aandachtspunten die nog op je lijstje staan waarbij ik nog iets kan doen?
ps. die beoogde route bij Oude Wetering / Leimuiden is inderdaad hardnekkig, er is zelfs al een paal geplaatst, maar toen ik er laatst was (rond dezelfde tijd als Google) leip je toch echt vast op een erf op het eind van de Molenkade. Op veel papieren kaarten zag je 'm steeds weer terugkomen… https://goo.gl/maps/gngfWnFoxiQ2
Ik heb al een tijdje hier niets meer gedaan.
Momenteel vraagt de Veluwe alle aandacht. En verder de wijzigingen in Salland en Twente.
Zodra ik mogelijkheden heb, wil ik nog wel eens kijken
Ik ben wel een stuk verder gegaan dan die tussenstand aan gaf.
Vooral aan de oostkant, Leiderdorp, Zoeterwoude, Koudekerke
Door de grote afstand heb ik een relatie aparte 50-50 gemaakt
Ik zou graag jullie hulp willen vragen:
-Zou iemand misschien even willen meekijken of ik de routerelaties zo goed heb gemaakt?
-Is het bij een verspringende kruising (dicht bij elkaar) nodig om op beide splitsingen een knooppunt aan te maken (omdat anders de route niet goed kan worden gevalideerd), of kan je volstaan met 1 knooppunt op de plek die het meest overeenkomt met de plek waar de paal is geplaatst?
-Idem bij verder uit elkaar gelegen dubbelen knooppunten (niet in zichtafstand)
Voor mij is het belangrijkste punt, accepteert vmarc het? http://osma.vmarc.be/nl/overview
Dat klinkt waarschijnlijk als taggen voor de renderer, maar dat is voor mij noodzakelijk. Als je dingen laat staan, die vmarc fout vindt, dan is het op het laatst lastig uit te vinden wat echte fouten en “onechte” fouten zijn. En vmarc is voor mij de enige bron om snel echte fouten op te sporen. Daarom is het ook belangrijk om - door vmarc aangegeven - sorteerfouten asap op te lossen, anders zie je andere fouten in de route niet meer.
En verder zijn er volgens mij geen applicaties, die echt gebruik maken van de routerelaties zelf. Wel van de ingevoerde data. OFM gebruikt het fkp om te routeren en er zijn een aantal bedrijven, die voor hun routes het fkp in OSM gebruiken.
Maar het relatiemodel voor fkp met tentakels wordt volgens mij niet echt gebruikt.
Echter de validatie in vmarc is wel gebaseerd op het tentakelmodel, dus soms worden sorteerfouten gemeld, die je dan weer met enig gepruts moet oplossen. Voorbeeld in 08-08 in Koudekerk, waarbij vmarc sorteerfouten meldde. Toen ik de volgorde omdraaide, waren de sorteerfouten weg.
Zelf wijk ik vwb knooppunten af van wat in het tentakelmodel staat. Ik zet knooppunten daar waar iets te beslissen valt. Het tentakelmodel hanteert de eerste afslag, maar als je daar niet kunt beslissen, is het naar mijn idee niet zinvol een knooppunt te leggen. Voorbeeld, je rijdt een rotonde op, die een knooppunt is. Volgens het tentakelmodel zou dan het knooppunt liggen op het punt dat je de rotonde oprijdt, terwijl je daar niet kunt afslaan. Ik leg dan het eerste knooppunt bij de eerste afslag van een route.
Je kunt dus zelf kiezen.
Ik tentakel ook niet altijd meer, zeker in ingewikkelde situaties niet en gebruik inderdaad bij lang uitgestrekte knooppunten een relatie van knooppunt-knooppunt, waarbij beide dezelfde zijn.
Wel maak ik relaties op een kruising of rotonde vaak “rond” zodat ze in het relatievenster er heel uitzien.
Infopanelen.
Volgens de wiki zou je die in het netwerk kunnen opnemen, maar dat geeft fouten.
Ik zet gewoon een kaart neer en in de description Informatiepaneel voor knooppunt xx
Even specifiek kp 50. vmarc meldt geen fouten en ik vind het er prima uit zien
Even om het scherp te krijgen:
Is de reden dat het hier OK is om bij de verspringende kruising aan de oostkant (Noordbuurtseweg) op beide punten een knooppunt aan te maken omdat er
-op beide punten een knooppuntbord staat met knooppuntnummer
(zie het zuidelijke bord op https://www.mapillary.com/app/?lat=52.12616111111112&lng=4.498349999999959&z=17&pKey=4XsktHULz4NydSDojTjJ7A&focus=photo - zat nog niet in mijn vorige post)
-of omdat er in de routering twee keuzepunten zijn?
Als er slechts één paal had gestaan, tussen de twee wegen in (Noordbuurtsehof / Dirk van Santhorstweg),
zou je dan maar een knooppunt aanmaken (want staat zo in het veld) of toch 2 (twee verschillende keuzepunten)?
Ja, dat is het betreffende Wiki artikel. Het voorbeeld daar is in het veld niet meer terug te vinden. Dat heb ik al om zeep geholpen.
En je kunt ook zien aan de diverse discussies, dat het een uitermate lastig gebeuren is. Probeer dat wiki artikel maar eens te volgen. Ik loop er in vast. De bedenker heeft het goed bedoeld, het is ook heel knap, maar je moet iets werkbaars hebben. In OSM is het hele fkp model al arbeidsintensief genoeg.
En als je ziet dat ik inmiddels vele km’s fkp in OSM heb ingelegd en dat dat allemaal foutloos is momenteel, dan denk ik dat ik een werkbaar model heb gevonden. En belangrijk ook, mijn routes zien er in het relatievenster goed uit, iets wat je van dat tentakelwerk niet altid kunt zeggen. Kijk maar eens naar de plaatjes in het wiki artikel. En dat vind ik belangrijk, dat je snel ziet dat iets goed is. En niet dat je eerst een hersenkraker hebt, van oh ja, dit is een tentakel, dat er fout uit ziet, maar toch goed is.
En dan het lastige punt, waar wel en waar niet een rcn_ref.
Belangrijk zijn de borden. Als die aangeven dat het een afslagpunt is, dan zeker.
Maar ook de situatie ter plekke. Die borden houden soms geen rekening met eenrichting fietspaden. En zeker bij fietspaden aan beide kanten van een drukke weg, kan het handig zijn om een rcn_ref te plaatsen, die ook weer op de kaart zichtbaar is.
Anderzijds kan het ook zijn dat de afslagpunten zo dicht bij elkaar liggen, dat het vrijwel onzin is om 2 punten te maken.
Als je wat rondsnuffelt in het Leidse gebied kun je wel voorbeelden vinden hoe ik het heb gedaan, waarbij ik uitdrukkelijk de disclaimer plaats, dat ik niet de wijsheid in pacht heb. In tegendeel.
Wat zeker niet moet, zijn rcn_refs op de plek van het infopaneel. Ook daar zijn voorbeelden van te vinden in OSM. De rcn_ref ligt dan net na/voor het kruispunt.
Daarnaast zijn er een aantal netwerken, Zuid Limburg is een berucht voorbeeld, waar 2 routes kilometers gelijk op lopen en ergens op een punt ieder hun eigen weg gaan zonder dat daar een knooppunt bord staat. In zo’n geval kun je geen rcn_ref plaatsen, want er is geen knooppunt. Bij de FB wordt daarvoor een splitspunt gebruikt, maar dat is ook discutabel, want aan de bordjes buiten is niet altijd te zien dat je daar kunt overstappen op een andere route. Maar goed dat ligt ook aan het fundamentele verschil tussen fkp bij FB en OSM. Bij FB is fkp een kenmerk van de weg en bij OSM een routerelatie.
Ik heb vanmorgen 3 routes gesplitst, ben deels kwijt welke. Als ik me goed herinner, betrof het een nieuw kp 51, 66 en 56
In ieder geval nieuw kp betekent altijd route splitsen
Maar vanmorgen flinke lijst fouten in vmarc, dus even door pakken en dan onthoudt ik niet alle details en voor de duidelijkheid, fouten waren landelijk; er zat ook een fout van mij bij.
Dank je, Dick!
Bij 56 wist ik dat ik de validatie om zeep had geholpen door het invoegen (vandaar mijn post hierzo, dat leek me beter dan onbedoeld de forwards/backwards te slopen, eerst maar eens in verdiepen),
bij 51/61 ben ik het domweg vergeten, excuus!
Bij 53/54 (beide ingevoegd tussen 17 en 52) heb ik er wel aan gedacht, hopelijk is dat goed gedaan en gaven die vanochtend geen validatiefouten?
Heeft Vmarc een vaste verversingsfrequentie? (het lijkt op eens per dag?)
Vrijwel direct na het invoeren van routerelaties zie je ze wel gevisualiseerd op Waymarkedtrails, maar de validatie op Vmarc was niet meer op tijd.
Heb in ieder geval nu wel een flink lijstje “feiten” op mijn naam staan die ik snel moet corrigeren:
ben bezig met een nieuw deel van een wandelnetwerk dat vrolijk knooppunten heeft tussengevoegd in een verbinding die reeds twee verschillende andere netwerken verbindt… (en de markeringen in het veld zijn daardoor ook niet meer consistent)
VMarc ververst om de 2 uur en dan de even uren. Het beste kun je VMarc met met rust laten in de eerste helft van de even uren. Dan is ie druk met verwerken.
Er zijn nu wel een stel routes uit het netwerk Groene Hart gekiepert. Ik kan zo niet zien wie dat gedaan heeft. Mogelijk alphensebezorger, die heeft het netwerk bewerkt en die heeft nu een knooppunt op een route gemikt zonder te splitsen.
Jouw routes zijn goed gegaan. Alleen voor 07-09 wordt een bijkomend knooppunt gemeld.
Ach, allemaal niet zo erg. Kan allemaal vlot hersteld worden.
Zaterdagmorgen was het anders. Bij kp 77 had iemand - met de beste bedoelingen - hele stukken uit routes geknipt. “Ja, maar routes lopen buiten niet door na het knooppunt!” Klopt, maar is het heel lastig met eenrichting fietspaden, geen oversteek bij 77 en ik moet de routes “rond” krijgen. Was flink puzzelen van hoe had ik dat ook weer gedaan?
Forward/backward:
Als je eenrichting stukken hebt, begin je met de heenrichting. Forward en backward slaan op de tekenrichting van de weg. Als de heenrichting klaar is, begint de terugrichting en… dat is even lastig, vanaf het splitspunt, dus tegen de rijrichting in. Dus je moet even andersom denken. Maar het kan eigenlijk niet fout gaan, je ziet in het relatievenster onmiddelijk of iets niet klopt, dan geeft ie rechts een niet passend lijnsymbooltje. De heenrichting is de linker lijn, de terugrichting de rechterlijn. Soms kan het wel zijn dat de terugrichting pas goed wordt als alle wegen erin zitten.
Dit is een oude quote van mijzelf. De situatie is dus nog steeds zo onduidelijk als boven beschreven. En ook al betreft dit niet Holland-Rijnland maar de eerder genoemde fietsroutenetwerken, zie ik dat bij de Goverwellesingel (brug) , Gouda ook nog door niemand de nieuwe verbindingsknooppunten gemapt zijn. Nee ook niet door mezelf omdat een fkp-relatie stukje lastiger is dan een wkp-relatie.
Daarbij weet ik ook nu niet welke knooppuntnummers het daar waren. Misschien dat ik binnenkort nog een survey doe.
Anyway, met weer zoals nu is een survey een goede aansporing om achter de computer vandaan te komen en lekker naar buiten te gaan (-:
Maar er zal vast weer meer werk uit komen dan je verwacht…
Inmiddels, wel een week geleden heb ik de survey gedaan. Ik heb voor nu = 14-04-17 even alleen de 2 fietsknooppunten ingevoegd, 51 - (Reeuwijkse Plassen) en 41 (Krimpenerwaard). Ik heb ze op dit moment nog niet met elkaar verbonden, en ook niet de routes 35-40 in tweeen geknipt en dit geldt ook voor de route 09-12 (Krimpenerwaard) die aan beide kanten van de Provinciale weg ligt.
Ik heb de routes 09-12 en 35-40 beide gesplitst in 09-41, 12-41, 40-51 en 35-51
Ik reduceer graag het aantal foutmeldingen in VMarc
En omdat een connection route 41-51 voor de hand lag, die maar gelijk ingetekend.
Dank je Dick, en ik hoopte al dat iemand anders het verder aanpaste :).
Beetje offtopic omdat dit om wandelknooppunten gaat. In Vmarc probeerde ik dat ook te voorkomen met Gouwe-Wiericke, maar ja als de prov. ZH 1 jaar later een deel Rijn- en Veenstreek gaat maken wat eerst Gouwe-Wiericke was dan wordt het wel heel lastig
Daarbij vind ik imho dat het ook nog verspilling van materiaal is om al die metalen plaatjes weer te vervangen.
Voordeel is wel dat je verplicht survey moet doen.
Misschien hebben jullie het al gelezen in dit draadje over het Veluwenetwerk, maar ik meld het hier ook maar even, ipv de fietsroutes van het Pdok kan je in JOSM nu beter de WMS laag van routedatabank.nl van het Fietsplatform halen, die worden maandelijks ververst. Pdok krijgt ze vooralsnog 4x per jaar van het Fietsplatform. Op de BTM kaart heb ik de WMS laag al vervangen voor die van routedatabank.nl. Fouten in deze data kan je het beste rechtstreeks melden bij Jon Rietman van het fietsplatform, hij zal dat zeer op prijs stellen.
Liep ook hier tegen wat grensproblematiek tussen twee netwerken aan (merkte dat pas helemaal op het laatst, aantal knopen aan de westkant rond Leiden bleken Duin- en Bollenstreek te zijn).
Kon adhv mijn eerder foto’s aantal keer zaken duidelijk krijgen, zal nog eens een rondje fietsen voor de onduidelijke situaties en eventuele fouten die ik heb gemaakt herstellen. Kritische blik is welkom, excuus…
Bij route 04-16 was het fietspad langs de Morsweg onderaan de relatie terecht gekomen, die heb ik op zijn plek gelegd. Vervelender was dat iemand in het verleden dat fietspad net boven het splitspunt van de Morsweg had aangesloten ipv precies op het splitspunt. Kweste van goed mikken fietspad heb ik nu wel goed aangesloten en in de route op de juiste plek gezet. Bij nader inzien, lijkt dat niet helemaal de goede plek. Volgens Streetview en ook op de luchtfoto te herkennen, lopen de twee rijbanen langer gescheiden door.
Verder zie ik op de luchtfoto een fietspad aan de zijde van de parkeergarage, dat staat nog niet OSM. Volgens Streetview lag het er in september 2016 nog wel. Is het nu weg of moet het nog ingetekend worden?
Probleem van die grenscorrecties is dat de tag expected_route_relations niet meer goed werkt. Die werkt alleen maar goed als een rcn_ref in 1 netwerk ligt. Dus aantal expected_route_relation tags verwijderd
Bij route 07-99 zat een overbodig stukje, route ging over 99 heen. Stukje verwijderd.
Dank voor je grote geduld met toelichten en corrigeren, Dick!
Het onderaan de relatie plaatsen had ik gister in twede instantie gedaan nadat Vmacr een foutmelding bij mijn eerste poging (die achteraf bezien qua opzet goed was -terugweg invoeren na voltooien van het sub-lusje ipv na voltooien hele traject- maar qua uitvoering dus misliep door de onopgemerkte verspringing tussen splitsing weghelften en fietspad…)
De situatie zoals je die op de luchtfoto ziet is nog steeds de actuele situatie (in ieder geval twee weken geleden, en geen reden om aan te nemen dat dat nu anders is). Ik zal dat morgen wel verder aanpassen, samen met de operators van de knooppunten die ik vanavond ben langsgefietst (drielandenpunt netwerken Groene Hart / Duin- en Bollenstreek / Haaglanden).
Nog een leuke variatie: bij knooppunt 99 staat op de paal “Groene Hart” vermeld, maar het infopaneel er direct naast is dan weer van Duin- en Bollenstreek… (knooppunt dus gewoon operator:rcn Groene Hart, lijkt me)
Ook interessant:
Tussen 99 en 7 is voor langere tijd (geen datum vermeld) een weg afgesloten -ook voor fietsers- , positief is dat ook de knooppunten zijn vermeld bij de omleidingsroutes. Wat is gebruikeljk het afgelsoten stuk weg voor nu op highway=construction" zetten, of iets anders?
Behoeft de route-relatie daar nog aanpassing op, bijvoorbeeld een comment?
Daarnaast zag ik bij 87 geen enkel spoor in het veld / op de borden van deze relatie (alleen de te verwachten verwijzing naar 89 en 99) https://www.openstreetmap.org/relation/1184087/history
De relatie dus maar verwijderen? Want een lcn is het ook niet
Ik werk nu al jaren, eerst alleen voor FB, nu ook met OSM, met fietsknooppuntennetwerk en LF en ik blijf het leuk werk vinden. Soms zijn er wel eens momenten, dat je het even niet meer ziet zitten, maar ik ben er altijd weer uit gekomen.
Ja, die bordjes…
In mijn buurt is het netwerk Salland gewijzigd en daarbij zijn ook een aantal routes van de Achterhoek mee gewijzigd. Dat heeft men keurig gedaan met bordjes met onderregel Achterhoek, maar op een paar plekken is het mis gegaan en zit er ineens een Salland bord tussen.
En wat infoborden betreft, Veluwe is nu net gewijzigd en op sommige grensknooppunten staan nu Achterhoek en Veluwe infoborden broederlijk naast elkaar.
Ach ja, de uitvoerder is in vele gevallen toch dezelfde, Folkersma. Dat is inmiddels een grote speler geworden.
Die afgesloten weg tussen 99 en 7 kun je op construction zetten. VMarc heeft er geen problemen mee en ik heb het idee, maar weet het niet zeker, dat OFM er niet over routeert. Eventueel iets in description zetten, kan nooit kwaad
Die route bij 87 kun je - naar mijn idee - gewoon verwijderen. Hij doet momenteel niks, maar een nieuwe routerelatie is ook zo gemaakt.
Dat heb ik al om zeep geholpen.