Sv:Good practice
OpenStreetMap är ett gratis projekt utfört av volontärer. Vem som helst kan ange vad de vill. Som sagt, en karta fungerar bäst när deltagarna kommer överens om en uppförandekod. Dessa "God praxis" är riktlinjer som kommer att öka kvaliteten och värdet på vår kartdata utan ytterligare ansträngning. Ingen tvingas lyda dem. Det kan finnas fall där dessa riktlinjer inte gäller eller till och med motsäger varandra.
Rätta fel
När OpenStreetMap saknar data eller när saker förändras i den verkliga världen, var inte blyg, utan uppdatera kartan för att den visar verkligheten.
Dina ändringar kan förfinas eller återställas vid behov, så tveka inte att redigera kartan.
Var dock respektfull för det arbete som utförs av andra kartläggare och överväg att konsultera dem, om befintliga taggar känns fel eller är otydliga. Ofta finns det mer än ett sätt att tolka situationer och riktlinjer. Var också uppmärksam när du tar bort data eftersom det är svårare att hitta och återställa borttagen data. Bäst är därför att ändra data, inte ta bort. Förutsatt att objektet fortfarande finns.
Om du är nybörjare, osäker eller redigerar på en avlägsen plats – kontakta andra kartläggare och be dem granska dina redigeringar.
Verifierbarhet
Huvudartikel: Verifierbarhet
OSM-data bör, så långt det är rimligt möjligt, kunna verifieras. Principen gäller för taggar och andra aspekter av datarepresentation, och innebär i att man på platen som är karterad, ska kunna avgöra att data är korrekt.
Kartera vad som finns i verkligheten
Ibland finns det motstridiga uppgifter om till exempel namnet på en plats. En gammal karta kan kalla det en sak, nuvarande kartor en annan, och ortnamnsskylten ytterligare något annat. Personer som använder våra kartor (för navigering) bryr sig inte om stavningen på andra kartor, de måste hitta namnen på lokala skyltar på kartan och vice versa. Det enda undantaget från detta kan vara uppenbara felstavningar på skyltar. Om man antar att folk letar efter den korrekta stavningen, kanske de inte hittar platsen på grund av den felstavade skylten. I dessa fall är det vettigt att data så att de överensstämmer med de felstavade skyltarna. Se även: ground truth
Kartera inte historiska händelser eller historiska platser
Kartlägg inte platser för historiska händelser, eftersom sådana inte kan verifieras på plats. Om ruiner finns kvar (och därmed verifierbara), kartlägg ruinerna (till exempel med historic=ruins). Objekt som inte längre existerar och historiska händelser kan kartläggas på OpenHistoricalMap (se Open Historical Map).
Ange inte regler i lokal lagstiftning om den inte är bunden till specifika objekt
OSM är en geografisk databas, inte en lagstiftningsdatabas. Lokala trafikregler bör endast anges på objekt i den mån de skiljer sig från allmänna regler som aktuell typ av objekt. Ange alltså enbart sådant som inte följer de normala reglerna den typen av objekt. Exempelvis att på en motorväg för man inte cykla eller gå. Det allmän regler och ska inte anges på alla motorvägar.
Kartlägg inte tillfälliga händelser
Kartdata från OSM laddas ofta ner och används offline under en längre tid. För att offlinedata ska vara användbar bör den åtminstone förväntas förbli oförändrad under de närmaste veckorna när den kartläggs. Vissa händelser som inträffar regelbundet (som en veckomarknad) kan kartläggas genom att använda olika öppettider.
Kartlägg inte för renderaren
- Huvudartikel: Tagging for the renderer
Kartlägg som det är i verkligheten! Ange inte felaktiga data eller ta bort korrekta data, bara för att det ska se "snyggt ut" på en genererad karta. Rapportera eventuella problem i en karta till de som ansvarar för genereringen av kartan (exempel för Openstreetmap-Carto-stilen).
Kartera inte tillfälliga händelser
Vår kartdata laddas ofta ner och används offline på olika enheter under flera veckor eller månader. För att offlinedata ska vara användbar bör den åtminstone förväntas förbli oförändrad under de närmaste veckorna när du kartlägger den. Vissa händelser som inträffar i ett vanligt mönster (som en veckomarknad) kan kartläggas genom att använda olika tidstaggar.
Använd inte namn för att beskriva saker
- Huvudartikel: Names
Namntaggen ska användas för namnet på ett objekt. Namnet är inte en beskrivning av objektet. Det är till exempel felaktigt att använda name=skogsväg på en skogsväg. Vägen ska ha det officiella namnet på vägen, om sådana finns. Annars ska name=* inte anges.
Bra kommentarer om ändringar
{{main|
- Huvudartikel: Good changeset comments
Bra ändringskommentar bör vara kortfattade och ska beskriva vad som ändrats. Detta för att undvika missförstånd, och göra att eventuella fel åtgärdas snabbt. Det gör dina redigeringar mer användbara och kan hjälpa till att förstå ändringar om man tittar på historiken för ändringar.
Bra kommentarer om ändringar
- Huvudartikel: Good changeset comments (Bra kommentarer om ändringar)
En bra ändringskommentar bör kortfattat och adekvat beskriva en redigering. Du bör göra detta av artighet mot dina andra kartläggare, för att undvika missförstånd och få misstag åtgärdade snabbt. Det gör dina redigeringar mer värdefulla. Det kan till och med hjälpa dig när du tittar tillbaka på dina redigeringar i framtiden.
Behåll historiken
- Huvudartikel: Keep the history (Behåll historiken)
När saker förändras i den verkliga världen, var djärv och redigera kartan för att återspegla den aktuella situationen. Men var medveten om att OpenStreetMap kan lagra redigeringshistoriken för ett element. Du kan hjälpa till att bevara den här historiken genom att ändra de befintliga elementen istället för att ta bort dem och rita om från början.
Ett enda OSM-element bör dock inte användas för att lagra historiken för flera orelaterade objekt. Se Blanda inte historiken för mer information.
Innan du gör betydande ändringar av större objekt, kontrollera deras historik.
En egenskap, ett OSM-element
- Huvudartikel: One feature, one OSM element (En funktion, ett OSM-element)
Ett OSM-element bör representera en enda funktion på marken en gång och bara en gång. Placera inte noder i identiskt taggade områden bara för att se en ikon visas i redigeraren.
Om du ritar området för ett objekt som tidigare bara fanns som en nod, ta bort noden eller återanvända den i konturen enligt beskrivningen i Behåll historiken, ta sedan bort taggarna från noden och lägg till dem i området.
Se fullständig artikel för anmärkningsvärda undantag från denna regel.
Redigeringsstandarder
- Huvudartikel: Editing Standards and Conventions (Redigeringsstandarder och konventioner)
Justera flygbilder före spårning
- Huvudartikel: Using Imagery (Använda bilder)
Flygbilder kommer, oavsett källa, att ha förskjutningar till de verkliga positionerna för objekt på marken. Även om detta kan vara tillräckligt litet för att ignoreras, kan det vara betydligt mer än typiska GPS-fel (>> 10 meter) och förändringar över små områden (kräver omjustering). Det är obligatoriskt att kontrollera detta innan du flyttar befintlig OSM-data, eller lägger till fler.
Möjliga sätt att justera och kontrollera justering:
- befintliga GPS-spår eller högprecision POI-data
- jämför bilder med befintliga OSM-data
iD, JOSM och Potlatch har [[Using_Imagery#Matching_imagery_using_different_editors|verktyg] som stöder bild injustering.
Just because it is available doesn't mean that aerial imagery is up to date. Be sure to check that the existing OSM data you are about to change or delete is indeed older than the imagery you are looking at by checking the history and changeset comments of the object. The best is to only map areas that you visit and verify yourself.
Spåra inte från föråldrade bilder
- Huvudartikel: Armchair mapping (Fåtöljskartläggning)
Bara för att det är tillgängligt betyder det inte att flygbilder är uppdaterade. Se till att kontrollera att befintliga OSM-data som du ska ändra eller ta bort verkligen är äldre än bilderna du tittar på genom att kontrollera historiken och changeset comments för objektet . Det bästa är att bara kartlägga områden som du besöker och verifiera dig själv.
Genomsnittligt ut GPS-spår
- Huvudartikel: GPS-datas noggrannhet
Noggrannheten för punkterna i en enda GPS-spårning kan vara flera meter borta. Detta beror på många faktorer. Om många spår tas för samma väg, kommer effekten av fel i varje spår att ha en mycket mindre inverkan på den genomsnittliga positionen för dessa spår. Det är användbart att ladda upp alla GPS-spår till servern – även om de täcker vägar som redan finns i databasen. Detta gör att andra kan [Upload#What_happens_to_my_file_after_it_has_been_uploaded.3F|använda dina spår]] för att utjämna felen.
Kartlägg kurvor med ett lämpligt antal noder
Använd ett rimligt antal noder för att kartlägga kurvor och andra icke-linjära funktioner. Det finns ingen hård eller snabb regel om hur många noder som ska användas för att kartlägga kurvor – du måste använda ditt eget omdöme – men det bör finnas tillräckligt mycket så att kursändringen mellan på varandra följande segment av en väg är relativt liten – det vill säga vinkeln mellan intilliggande segment bör vara närmare 180° än 0°. Därför kräver skarpa kurvor många nära åtskilda noder, medan bredare kurvor kan kartläggas med färre, långt åtskilda noder.
Markera uppskattningar med fixme
Ibland är det vettigt att kartlägga uppskattade positioner snarare än att inte kartlägga objektet alls. Men markera alltid dina uppskattningar med en fixme=* så att du eller någon annan kommer tillbaka till det.
Överanvänd inte semikolonseparerade värden
Separator för semikolon kan införas i värden, där samma nyckel måste ta flera värden. Detta kan vara användbart för att lägga in värdelistor i vissa typer av mindre attributtaggar, men det bör undvikas i viktigare taggar på toppnivå som highway=*. I allmänhet bör dessa specialtecken inte överanvändas, eftersom de försämrar märkningssystemets enkelhet och därför ofta är sällsynta och stöds dåligt av datakonsumenter för taggar på toppnivå (medan flera värden separerade med semikolon stöds i allmänhet väl för taggar som har en mer listliknande karaktär som opening_hours=*).
Dokumentera dina anpassade taggar
- Huvudartikel: New Features (Nya funktioner)
- Huvudartikel: Creating a page describing key or value (Skapa en sida som beskriver nyckel eller värde)
När du använder taggar som inte finns på kartfunktioner, ge andra kartläggare en chans att förstå (och kanske adoptera) dem genom att dokumentera dem i wikin. Använd inte kartfunktionssektionen på wikin för detta (inklusive alla wikisidor vars namn börjar med Nyckel: eller Tag:), eftersom dessa är de taggningsrekommendationer som stöds av communityn som är reserverade för väl- etablerade taggar med betydande användning. Istället bör du skapa en föreslagen funktionssida eller lägga dokumentationen på din användarsida eller en undersida till den. Eller nämn taggen på en "Diskussion"-sektion på en wikisida. Att skapa ett förslag är den föredragna metoden för att dokumentera anpassade taggar.
Ta inte bort taggar som du inte förstår
Ibland kommer du att stöta på element med taggar som inte har någon betydelse för dig. Detta betyder inte automatiskt att du bör ta bort dem. De kan ha lagts till för ett specifikt syfte. Om du tror att de kan vara skräp, försök att kontakta författaren. Se även: Chesterton's fence on Wikipedia
Ta inte bort objekt som du inte behöver eller gillar
Var modig i vad du lägger till men försiktig med vad du tar bort. Har någon lagt till en kontaktledningsmast eller en manhål? Och du tycker att det är dumt eller onödigt för att det inte visas på kartan? Felaktig mappning är inte förbjuden, men du ska absolut inte arbeta åt andra hållet och ta bort detaljer som någon annan lagt till. Det är känt att allt inte alltid behövs av alla, men man ska inte ta bort något bara för att man inte behöver det/du tycker det är dumt/valideraren beordrade det så.
Se även
- Redigeringsstandarder och konventioner – Ytterligare en uppsättning rekommendationer om aspekter av kartläggning.
- Bästa praxis för organiserad redigering
- Tagging_samples – Märkning av prover med faktiska foton.
- :Kategori:Taggningsriktlinjer efter land – Dessa landsspecifika wikisidor innehåller vanligtvis bättre förklaringar än huvudwikin.
- Alla taggar du gillar
- Just Map
- Mapbox QA guide
- Begränsningar för kartläggning av privat information
- God praxis i OpenHistoricalMap