Följande är vad ID har autoifyllt när man söker på “scrap yard” och är även vida mer använt än industrial=auto_wercker:
industrial=scrap_yard landuse=industrial
Det sistnämnda klingar inte ens särskilt engelskt, så frågan är om man inte borde försöka omvandla alla till industrial=scrap_yard, eftersom det heller inte finns någon skillnad mellan definitionerna. Det verkar vara den problematiske användaren Zluuzki som försöker göra skillnad på de två, men det finns knappast konsenses kring det: Talk:Tag:industrial=auto wrecker - OpenStreetMap Wiki.
Är det lag, regel eller ens rekommendation att postnumren ska sparas med mellanslag i databasen? I min värld känns det som att “postnummer med mellanrum” endast är ett display-format, dvs så som det renderas för användaren för bättre läsbarhet. Inte nåt som ska sparas i databasen.
Om jag kan lita på min egen overpass-sökning ser det ut såhär i redan befintliga taggar på objekt:
Postnummer utan mellanslag (xxxxx): 126154 förekomster
Postnummer med mellanslag (xxx xx): 236177 förekomster
Dvs, om det är lag, regel eller rekommendation att spara mellanslag i databasen så är 35% av de redan existerande objekten feltaggade.
Joho. En scrap_yard tar emot alla sorters metallskrot, medan en auto_wrecker endast tar sig an bilar. Jämför tex “Stena metall” med “Mullhyttans bildemontering”
Justerat så att den även “söker” efter objekt med landuse=industrial och antingenindustrial=scrap_yard eller industrial=auto_wrecker, samt att det visas en kommentar vid avvikelsen med andra möjliga taggningar. 19 avvikelser mindre direkt, samt förhoppningsvis ett gäng som byte från “saknas” till “saknar taggar”.
Jajamen, nu kan man det!
Nu föreslår den istället tourism=theme_park, men en notering om andra möjliga taggningar (tourism=zoo, tourism=water_park).
Man brukar lagra postnummer i display-format. Olika länder har olika regler för sina postnummer. Om man inte lagrar i display-formatet tvingas man lägga in regler för alla länder i presentationslagret.
Jag har jobbat med flera olika stora affärssystem, alla dessa lagrade svenska postnummer med mellanslag.
Förvisso, men det behöver bara göras en gång för varje format i renderaren, sen blir det alltid rätt. Nu har vi istället ett mishmash som kommer av den enskilde karterarens godtycke. Inte optimalt det heller.
Vad som är rätt där är inte nödvändigtvis rätt för OSM.
Det är trivialt att presentera svenska postnummer på rätt sätt oavsett hur det lagras i detta fall, så jag tycker att vi kan hålla vad som är “rätt” till en egen tråd.
Däremot är det nog bra om verktyget i den här tråden kan hantera båda varianterna vid en jämförelse så att den inte försöker skriva över det ena formatet med det andra trots att siffrorna stämmer.
En fråga: punkter som inte ska åtgärdas, kan de taggas på något sätt så man slipper se dem?
Tex i “min” by finns det enligt LM en slalombacke som lades ned på 90-talet. Den dyker ju upp som en punkt men ska ju inte läggas in i OSM.
Inte just nu, väntar på svar från MapRoulette för att lösa det genom integration dit.
Det löser inte problemet (snabbt i alla fall, räkna med någon månad minst), men om det är ett fel i LMs data kan du rapportera det här: https://forbattrakartan.lantmateriet.se/ Om/när det åtgärdats hos dem kommer även avvikelsen försvinna i BJK strax därefter.
Utöver @Hashmush tillägg som gör det möjligt att ladda ned föreslagna geometrier som GeoJSON så har jag den senaste veckan även skrivit om samtliga avvikelsealgoritmer. De är nu mer “tydliga” i vilket källobjekt de matchar med vilket objekt i OSM. Utöver att göra algoritmerna tydligare så går det som bieffekt nu även att se vad som matchar om man går in på datakällans sida (man måste zooma in en bit innan något visas).
Zoomar man in ännu mer får man även pilar som pekar från objektet i datakällan till objektet i OSM, vilket kan hjälpa till att avgöra om matchningen är rimlig (exempel papperskorgar i Gävle):
Gjort en mindre förbättring kring detta, de har nu åtminstone korrekt landskod. Finns fortfarande förbättringspotential (mellanrum etc.), men det är mer hur det presenteras än att det skulle vara funktionellt bristfälligt.
Lite mer relaterat till kontaktuppgifter. Jag har en massa skolor där BJK föreslår contact:*=* där motsvarande kortform redan finns. Det kanske kan vara bra att inte föreslå dem om den kortare redan existerar?
Oj, vilket suveränt verktyg. Har kollat runt lite, testat att fixa lite olika punkter och ser att detta kommer komma till stor användning.
Har en fråga som eventuellt är en bugg. Jag la till en fotbollsplan inne på ett skolområde efter att ha granskat Ortofoto. Nu föreslår BJK att jag ska tagga den med leisure=sports_centre i stället för leisure=pitch. Men för mig känns det fel, det är ju inte en hel sportanläggning. Det måste kunna få finnas pitches som är skilda från sportanläggningar i OSM. Så förmodligen är det uträkningen av “saknade taggar” som måste fixas för den typen.
Är det bättre med issues på GitHub eller går det bra att skriva här i forumet?
Noterade samma även jag. Samt att kyrkogårdar föreslås få landuse=cemetary. De flesta kyrkogårdar i Sverige ligger i anslutning till kyrkor och då ska det vara amenity=grave_yard i OSM.
@02JanDal Även om mycket du får höra är vad som är fel på BJK så är ju 99% rätt och BJK är jäkligt bra, både i sig självt och för OSM i Sverige.
Yep, det lär vara en bugg. I matchningen tittar jag även på bl.a. leisure=pitch och några fler men gör sen inte samma sak för att räkna ut de föreslagna taggarna.
