Det virker oplagt at bruge den information til at forbedre OSM! Jeg foreslår at vi diskuterer hvordan man bedst går frem i denne tråd.
Så vidt jeg kan se er det laget “Unmatched infrastructure GeoDK” der er interessant, og jeg har nu lavet min første rettelse i mit lokalområde på baggrund af værktøjet: Changeset: 150384077 | OpenStreetMap. Luftfotos og Mapillary var tilstrækkeligt i dette tilfælde. LIDAR terræn kan også give en ide om hvorvidt der er kantsten, og dermed om der skal være track eller lane.
Forslag til fremgangsmåde:
Find strækninger med “Unmatched infrastructure GeoDK”, fx i dit eget lokalområde.
Brug SDFI luftfotos, Mapillary, og SDFI terræn til at afgøre hvilken infrastruktur der faktisk findes og kortlæg.
Brug hashtag #bikedna_webmap på changeset. Så har vi lidt samling på udviklingen, og kan fx hurtigt se om andre allerede har rørt et givet område i denne sammenhæng.
Hvis vi kunne få fra @_ane_rv en GIS fil filteret på “Unmatched infrastructure GeoDK” AND “cykelbane langs vej” - så der er sorteret ud og der kigges på de problematiske (se anden debattråd) fra GeoDanmark. Så er det relativt let at lave en Maproulette udfordring - samt man kan få Maproulette til at sætte automatisk hashtag og ad den vej kan der følges med i hvor langt der kommet.
Det ser ud til at der er en del vejstrækninger med dette, hvor samme problem med tagging som diskuteres i Er dette en cykelsti? nok vil opstå igen i en Maproulette.
Altså veje med tydeligt markerede kantbaner, der dog ser smallere ud end egentlige cykelbaner/stier (og er uden skiltning eller cykelsymboler på asfalten). Geodanmark kalder det åbenbart alligevel for ‘Cykelbane langs vej’. Dette virker ikke acceptabelt for OSM. Så måske det vil være nyttigt, at vi før en evt. Maproulette finder ud af, hvornår vi kan tagge disse kantbaner som cycleway=shoulder?
I wikien for Key:cycleway lyder det dog nu til, at man godt kan bruge ’ cycleway=shoulder’ selvom den er for smal til at være et nødspor for biler. Men kan ikke se om der er en minimumsbredde for cycleway=shoulder. Så er det mon muligt at vi kan blive enige om, hvornår vi bruger det?
Mange tak for forslag til fremgangsmåde; manuel håndtering fungerer fint for mig og BikeDNA værktøjet virker også fint – og åbner en helt ny verden Undskyld min uvidenhed: repræsenterer BikeDNA et øjebliksbillede, eller vil resultatet ændre sig dynamisk? Eller skal man/nogen aktivere softwaren igen for at få et nyt resultat?
Der er to perspektiver som vi kan beskrive, et juridisk og et fysisk:
Det fysiske er i princippet nemt nok at konstatere og registrere: hvor bred er kantbanen? Hvilken overflade har den (asfalt i 99% af tilfælde?)
Hvis der er tydelig skiltning er den juridiske måske[1] også nemt nok: Kantbanen er cykelsti, reserveret til cyklister, og skal bruges af cyklister.
Opgaven er måske så at kombinere disse to grupper information i passende tags. Og især afgøre hvordan gråzoner håndteres…
Her kommer nogle forslag af variende kvalitet. Jeg har ikke overblik over praksis hverken i DK eller verden, så tag dem med et gran salt…
For klart skiltet cykelsti, hvor motortrafik altså ikke er velkommen, kunne vi fx vælge én af:
(A) Den oplagte: cycleway=lane + diverse præciseringer med cycleway:*=*. Den kritiske er nok cycleway:lane=exclusive, men det er egentlig mit indtryk at den er implicit i DK, hvilket også afspejles i at den bruges forholdsvis sjældent.
(B) En udgave baseret på shoulder=*: shoulder=yes + shoulder:bicycle=designated (for at signalere at motortrafik ikke er velkommen, sjældent anvendt) + præcisering med shoulder:width=* og shoulder:surface=*
For ikke cykel-skiltet/malet kantbane (uanset bredde) kunne vi vælge én af:
(C) cycleway=lane + cycleway:lane=advisory + præciseringer med fx cycleway:width=* + cycleway:surface=*
(D) shoulder=yes + cycleway=shoulder om hvilken wiki siger “Used to indicate that a road has no designated infrastructure for cyclists, but shoulders (a.k.a. breakdown lanes) are navigable and legal to cycle on.” + shoulder:width=* og shoulder:surface=*
Kombinationen A+C (altså med cycleway=lane i begge tilfælde) er dejligt selvkonsistent, og helt fin når der er tale om cykelsti. Den er til gengæld lidt underlig i tilfældet med simpel kantbane. Kantbanen er jo netop ikke en cykelsti så cycleway=lane + cycleway:lane=advisory bliver lidt af et troll tag. Og hvordan beskrives de fysiske egenskaber for kantbanen i dette tilfælde? På shoulder:*=* eller på cycleway:*=*? Siden kantbanen ikke er betragtet som cykelsti, vil det være måske naturligt at placere dem i shoulder-familien hvor motortrafik også kigger.
Kombinationen A+D er måske bedre? Den er mere tro mod afgørelsen af at kanbanen ikke er cykelsti og dermed tagges som hvad den er (shoulder=*) ikke som cykelinfrastruktur (cycleway=*).
Måske kan C og D blandes?
[1] Jeg siger måske, fordi jeg ikke har forstået om bredde <1.2m ophæver skiltningen… Det ville være mærkeligt hvis den gør, men jeg synes teksten i Er dette en cykelsti? - #24 by osmviborg er ulden.
Jeg gætter på at det der vises på Bicycle Infrastructure in Denmark teknisk set sagtens kan opdateres løbende, men måske ønskes beholdt statisk fordi det betragtes som en del af en publiceret videnskabelig artikel.
BikeDNA er statisk et tidsdump af OSM DK - så der kommer ikke løbende nye ændringer fra OSM ind i den visualisering - Jeg ved ikke om forskerne bag har planlagt med bestemte intervaller (kvartal, årlig mm) at opdatere så det afspejler en nyere version af hvad OSM DK har kortlagt.
Tænker at det vil være dumt at kæmpe imod StreetComplete. Så vidt jeg kan se, kan man i den app, i Danmark, vælge mellem bl.a. nedenstående relevante muligheder. Dem synes jeg bare vi skal følge.
“cycle lane”
illustration i app er fuldt optrukket linje og malet cykel (altså vores skiltede/bemalede cykelsti):
cycleway=lane + cycleway:lane=exclusive. Den sidste er vigtig. StreetComplete ignorerer cycleway=lane uden den præcisering, og så kan vi jo lave meget dobbeltarbejde… Alternativt spørge om StreetComplete kan have exclusive som default for lane i dk? Det lader til at kunne lade sig gøre.
“advisory bicycle lane”
illustreret med stiplet linje, intet cykelsymbol (hvilket ligner de danske 2-1 veje…)
cycleway=lane + cycleway:lane=advisory.
“none, but shoulder is usable for cyclists”
illustreret med fuldt optrukket linje, intet cykelsymbol
cycleway=shoulder
“sidepath or protected cycle lane”
illustreret med kantsten og røde fliser
cycleway=track
“lane shared explicitly with other traffic”
illustreret med cykel og vinkel-symboler (chevron), ingen stribe.
cycleway=shared_lane + cycleway:lane=pictogram (Men DK wiki siger cycleway=shared_lane skal bruges til 2-1… SC ignorerer den hvis alene.)
En enkelt bemærkning til ‘advisory bicycle lane’ og 2-1-veje:
Ifølge Da:Cykelstivejledning: "Veje hvor biler og cyklister deler vejen, “2 minus 1 veje”, tagges highway=*, cycleway=shared_lane, lanes=1, og oneway=no.
Resultatet er dog fra sidste år, men måske KL har nyere data? De har brugt samme matchings-metode som os.
Det skal dog siges at vi, som nævnt, har forsøgt at matche tilsvarende kategorier (dvs. cykelstier og baner), så GeoDK vil være ‘umatchet’ selvom der er tilføjet f.eks. en shoulder i OSM.
Hej @_ane_rv Mange tak for at sende datadump - virkelig en god hjælp
ATT: alle andre - der skal lige laves rensning af data - Så vi kun får en geometri per vej/stisegment. - Hvis I åbner den 440 MB GeoPackage filen fx i QGIS så vil I se dubletter (se næste billede)
Det nemmeste for rense er smide alle data i PosgreSQL/PostGIS og lave en ny tabel med CREATE TABLE AS - SELECT DISTINCT X,Y, Z (tager kun 1 objekt af en unik værdi) og dermed bliver datasæt mindre > åbne nye tabel i QGIS og så “Save As” > NN.gpkg og så smide datasæt ud et sted alle kan downloade fra.
Jeg har ikke tid før i weekenden til sådan en operation - skal bruges nok 1-2 timer på dette.
Super at du måske har mulighed for at arbejde med de delte data, @AE35! Jeg tænker ikke det haster at få sat en MapRoulette op… Jeg er i hvert fald ikke endnu helt sikker på hvordan vi skal tagge, og det ville nok være smartest at have på plads inden.
Undskyld min uvidenhed: repræsenterer BikeDNA et øjebliksbillede, eller vil resultatet ændre sig dynamisk? Eller skal man/nogen aktivere softwaren igen for at få et nyt resultat?