Det er en fejl der skal rettes i Mapnik-renderen, som bare tilfældigvis er den render der bruges på openstreetmap.org.

Vi skal ikke tilpasse vores data efter hvordan der bliver rendered.

Vi skal ikke mappe efter hvordan tingene bliver rendered. openstreetmap.org bruger Mapnik renderen, men den er bare én slags render og i en anden render kunne tingene se helt fine ud.

Hvis man vil have den fejl rettet, så skal det gøres i Mapnik-projektet. Jeg gætter på man skal have noget programmørerfaring dér.

Så trækker jeg lige kløerne lidt tilbage igen :D

Jeg ved ikke om JOSM kan lave den slags fejl :)

endnu engang ingen covered=yes under broer - og veje der går under broen skal helt specifikt ikke forbindes til selve broen

Unødvendig note egentlig, da railway blot betegner skinner og ikke nødvendigvis hvad der kører på skinnerne.

En jernbane hvor der kun kører skinnecykler, ville heller ikke nødvendigvis behøve en særskilt note.

På disse skinner kører der små vogne som tilfældigvis bærer på både, som du også skriver i noten.

veje under broer skal ikke være covered=yes

veje under broer skal ikke være covered=yes

veje under broer skal ikke være covered=yes

som jeg også har kommeteret i et andet changeset, så skal veje der går under broer, helt specifikt, ikke tagges med covered=yes

osm.wiki/Tag:covered=yes

Der skal helt specifikt ikke bruges covered=yes under broer.

"Do NOT use this tag:

For objects in tunnels or passing under bridges where vertical ordering is established by layer=* in combination with a suitable tag such as bridge=* or tunnel=*."
-- osm.wiki/Key:covered

Lad venligst være med at slette hele veje, blot for at erstatte dem med tilsvarende veje. Det smadrer hele historikken for de enkelte ways/nodes.

I stedet, lav ændringer til de eksisterende ways/nodes.

It needed no consistency. It actually represented reality. Please don't edit if you dont know what you are doing.

:)

Hvad blvier det næste?

At vi sætter highway=trunk + foot=yes på en landevej der har 90 km/t begrænsning og hvor cykler ikke er tilladt?

Jeg synes der er fornuft i at følge hvordan vejdirektoratet og kommunerne har sat vejklassifikationerne - det er trods alt dem trafikanterne følger ude i den virkelige verden.

Derefter kan vi være så uenige i hvorvidt en vej "burde" være klassificeret på en bestemt måde eller ej som vi lyster - men igen, vi skal ikke mappe efter hvordan vi mener vejen skal bruges, men efter hvordan virkeligheden ser ud.

På samme måde skal vi heller ikke sætte kunstige hastighedsbegrænsninger/-anbefalinger på, bare fordi en vej virkelig ikke lægger op til at man kører hurtigere end 30 km/t. Hvis det ikke er markeret ude i virkeligheden, så er begrænsningen der ikke.

Hvis man skulle følge logikken med at angive vejtypen ud fra dens bredde, så skulle følgende gælde ve Aarhus:

Ringgaden (O1) skulle gøres til primary, mens Ringvejen (O2) skulle være secondary, da O1 er væsentlig bredere end O2 de fleste steder.

Læsevejen er der heller ikke meget bredde over :D

Der er dælme ikke meget bred vej over Vesterhavsgade og Morsøgade :D

Jeg kan sagtens følge dig i at en vej som Fiskerihavnsgade skal forblive tertiary

osm.wiki/Da:Map_Features#Veje_.28Roads.29

Ifølge det danske communitys retningslinjer, er det kun primærruter der bør være highway=primary ... og at så længe Adgangsvejen/H.E. Bluhmesvej ikke er gjort til en primærrute (altså et vejnummerskilt med gul baggrund), så bør den forblive tertiary.

Uanset hvor meget den oprindelige mapper bor i Esbjerg, så ændrer det ikke på at vejen ikke er en primærrute.

Hvis staten ville gøre denne vej til den primære rute gennem byen, ville de have lavet en særskilt nummerering af den.

Det er ikke op til os som mappere at afgøre hvilken vej VI synes folk skal tage.

Faktisk så ved at opgradere vejen til primær, så fortæller vi routeren at uanset hvad den ellers kunne have af idéer, så bør prioritere denne rute - og dermed kan valget af orimary gøre at folk ledes den vej, selvom deres endemål er rundkørslen mellem Hjertingvej og Frodesgade - hvilket jo er helt hul i hovedet.