Moduldiskussion:Ortsfakta USA WD

Utveckling

@GeMet: Post-Corona har jag haft väldigt dåligt med tid. (Långtifrån femdagarsvecka och sällan 8-timmarsdagar.) Men här har jag nu gjort mitt första försök att göra så att {{Ortsfakta WD}} funkar i USA. Observera att modulen är extremt långtifrån färdig att lägga in i artiklar ännu. Det passar bara att göra förhandsgranskningar för att testa funktionen i. I första draften, så funkar det också bara i artiklar där motsvarande objekt på WD har land=USA och instans av=stad i USA. Det är inte de enda kombinationerna som den här ska funka i, när vi är klara. (land=Puerto Rico och instans av="town i Alaska" ska tex också funka.) Jag har anpassat så långt att det finns stöd för "flagga" och "sigill" men inte vapen. (Det brukar inte finnas stadsvapen i USA, men sigill är vanligt.) Som sagt är det här en mycket tidig version, och du kan testa att byta ut all wikikod i Rochester, New York mot {{Ortsfakta WD}} så ser du var i Sverige Rochester ligger. 62 osv (diskussion) 31 maj 2020 kl. 12.11 (CEST)

@GeMet: Ta gärna en titt i Användare:Sextvåetc/sandlåda och uttryck din åsikt om de två mallar som ligger där just nu. 62 osv (diskussion) 3 juni 2020 kl. 08.26 (CEST) (Men lägg inte in mallen i några USA-artiklar än!)

Bild och Kollage

Jag har nu gjort så att om det inte finns bild bild (P18) så letar modulen efter kollage (P2716). Ska vi föredra andra vägen, att vi först letar Kollage och sedan Bild? 62 osv (diskussion) 31 maj 2020 kl. 12.43 (CEST)

P242

@Larske: För USA finns många filer av samma typ som Fil:Monroe_County_New_York_incorporated_and_unincorporated_areas_Rochester_highlighted.svg. Går det att få någon uppfattning om hur stor del av P242 som inte använder den typen av översiktskartor? 62 osv (diskussion) 3 juni 2020 kl. 19.04 (CEST)

Beror på vad du menar med "den typen av översiktskartor". Jag gissar att du menar "med filnamn som innehåller strängen 'highlighted' ".

• Länk till fråga som räknar antalet objekt som är instans av (P31) stad i USA (Q1093829) (eller någon subklass därtill) (just nu 10 738), hur många av dessa som har egenskapen översiktskarta (P242) (just nu 10 482) och hur många av dessa som har strängen 'highlighted' (skiftlägesokänsligt) i filnamnet (just nu 7 477).

Det är alltså cirka 29 procent översiktskarta (P242) som inte är "av samma typ som".

Om du menade något annat får du beskriva mer i detalj vad som kännetecknar "den typen av översiktskartor".

Om du med "för USA" menar alla 1,35 miljoner objekt med land (P17) lika med USA (Q30) så är det knappt 42 tusen som har översiktskarta (P242) och av dessa är det knappt 20 tusen som har 'highlighted' i filnamnet. Länk till fråga.

--Larske (diskussion) 3 juni 2020 kl. 19.48 (CEST)

Ja, det här är en USA-modul, så bara intresserad av USA här. Det var en förvånansvärt låg andel. 62 osv (diskussion) 3 juni 2020 kl. 20.02 (CEST)

@Larske: Om man tar alla "städer i USA" med P242 och exkluderar "highlighted" och "doton" i filnamnet, hur ser då resten ut? 62 osv (diskussion) 6 juni 2020 kl. 12.13 (CEST)

Det finns en del "highlighting" och "highighted" (förmodad felstavning) som jag också filtrerat bort. Resten visas i följande lista/galleri:

• Länk till fråga som ger ett galleri med översiktskarta (P242) sorterade efter USA:s delstater (Q35657) och engelsk etikett för alla Wikidataobjekt som är instans av (P31) stad i USA (Q1093829) (eller underklass därtill).

Det är som synes mest förekommande med översiktskarta (P242) (som inte har ratats av filtret) i staterna North Dakota (Q1207) och Texas (Q1439). Du kan experimentera med raden "FILTER" i frågan för att modifiera vilka filnamn du inte vill se.

--Larske (diskussion) 6 juni 2020 kl. 13.16 (CEST)

Tack, det gör att jag nog kan komma till den slutsatsen att i samtliga fall där P242 används, kan jag som default nöja mig med en karta som visar var delstaten ligger i USA. Jag behöver ingen karta som visar var i delstaten orten ligger. 62 osv (diskussion) 6 juni 2020 kl. 14.49 (CEST)

Areatyper

@Larske: Man önskar man vore bättre på sådant här själv. Vad gäller "Stad i USA", vilka typer av qualifiers finns det till denna property? area (P2046) 62 osv (diskussion) 6 juni 2020 kl. 12.04 (CEST)

Inte särskilt mycket om jag fått till frågan rätt.

• Länk till fråga som ger en lista över qualifiers som används för egenskapen area (P2046) för Wikidataobjekt som är instans av (P31) stad i USA (Q1093829) (eller subklass därtill) och deras användningsfrekvens.

De är så få så det går bra att se alla i en kort lista:

• Länk till fråga som ger en lista över alla qualifiers med tillhörande värde som används för något Wikidataobjekt som är instans av (P31) stad i USA (Q1093829) (eller subklass därtill).

Det verkar finnas en hel del luckor. Notera dock att det kan finnas ytterligare information i den referens som anges för ett area (P2046)-påstående. Ett utgivningsdatum (P577) för till exempel 2016 U.S. Gazetteer Files (Q32859555) tycker jag dock inte fullt ut kan ersätta bestämningen tidpunkt (P585) för area (P2046).

--Larske (diskussion) 6 juni 2020 kl. 13.43 (CEST)

Storstadsområde

Efter att ha tittat igenom hur {{Ortsfakta USA}} har använts, så används inte invmicro alls. invurban används någon gång, men tveksamt om den används som det är tänkt. Ingen av dessa ser jag därför någon poäng med att ta med i WD-versionen.

invstorstad används dock och jag tittar nu på hur man bäst implementerar den. Någon entydig koppling mellan stad och storstad verkar inte finnas på Wikidata. Därför har jag nu hårdkodat in kopplingen mellan New York City och New York Metropolitan area i själva modulkoden. (Fler är enkelt att lägga till.) Koden nu (som bara är implementerad på area, inte på folkmängd) gör nu så att den länkar vår artikel om storstadsområdet, om vi har en artikel. Har den inte en artikel, så länkas istället vår artikel om amerikanska storstadsområden. Se exemplet New York i min sandlåda. 62 osv (diskussion) 8 juni 2020 kl. 09.41 (CEST)

Delen om invånare/area/täthet i storstad är fixad nu, hoppas jag. 62 osv (diskussion) 9 juni 2020 kl. 11.12 (CEST)

Klar

Mallen ser ut att vara klar att använda i tre delstater: Masssachusets, New York och Wyoming. 62 osv (diskussion) 13 juni 2020 kl. 14.12 (CEST)

Kansas! Men ingen anpassning till Township. 62 osv (diskussion) 13 juni 2020 kl. 20.23 (CEST)

Wisconsin. Även anpassad för "fourth class city i Wisconsin". 62 osv (diskussion) 14 juni 2020 kl. 10.22 (CEST)

Hur klart är Wikidata för att börja använda mallen? I Madison, Wisconsin funderar jag på om det officiella namnet verkligen är bara "Madison", och i din sandlåda visas "New York" och "Boston" som officiella namn. De officiella namnen för amerikanska städer brukar vara "City of X" eller liknande. Om inte det här stämmer, finns det andra fel som inte är lika lätta att se? F.d. 82.212.68.183 (diskussion) 15 juni 2020 kl. 17.46 (CEST)

Ja, det är såhär det blir när man på Wikidata redigerar hellre än bra. Frågan är om man ska begränsa mallen så att officiellt namn bara visas om det finns en "riktig" källa och inte bara "ryskspråkiga Wikipedia" eller liknande. 62 osv (diskussion) 15 juni 2020 kl. 18.10 (CEST)

Jag viftar med en stor varningsflagga för alla uttalanden som har importerat från Wikimediaprojekt (P143) ryskspråkiga Wikipedia (Q206855) som referens. Jag vet inte hur många hundra uttalanden jag rensat bort när det gäller egenskapen sysselsättning (P106) där någon, med ryskspråkiga Wikipedia (Q206855) som angiven källa, har stoppat in den aktivitet (som det inte ska vara) som praktiseras av (P3095) av personer med ett yrke (som det ska vara) som redan fanns i objektet. Till exempel stoppar man felaktigt in biologi (Q420) när det korrekta biolog (Q864503) redan finns eller prosa (Q676) när det korrekta prosaist (Q12144794) redan finns för en person.

Jag har sett liknande problem från andra språk, men känslan är att ryskan dominerar antalsmässigt.

Just nu finns det 4 683 sådana felaktiga uttalanden, varav 276 i objekt som är kopplade till svwp-artiklar. Inga av dessa artiklar använder dock idag mallen {{Faktamall biografi WD}}. Före dagens städinsats dök det upp felaktiga värden på sysselsättning (P106) i faktarutan i 10 svwp-artiklar.

För att kunna göra dessa rättningar i Wikidata lite mer diskret har jag nu lagt till parametern avoid_activity till funktionen sysselsattning i modulen Modul:Faktamall biografi WD/Aux så att den dels undertrycker visning av aktiviteter och dels lägger in artiklar där så skett i åtgärdskategorin Kategori:Wikipedia:Sidor med Faktamall biografi WD där Wikidataobjektet har ett värde för P106 som har egenskapen P3095.

När det gäller officiellt namn (P1448) för städer i USA vore väl det bästa om det gick att hitta en trovärdig och maskinläsbar källa för alla sådana namn och med den som utgångspunkt fylla på dessa namn i Wikidata, med angivande av källan, och samtidigt rensa bort, eller möjligen "orekommendera", eventuellt avvikande namn som har "svaga källor" som till exempel i form av importerat från Wikimediaprojekt (P143).

Även för andra egenskaper skulle det nog vara bra med en systematiskt genomgång/kontroll av vad som egentligen finns inlagt i Wikidata för de amerikanska städerna och vad som är källbelagt, så att det inte är för mycket konstigheter som dyker upp när mallen börjar användas i större skala. Kanske några Listerior kunde vara något att börja med för att få en överblick över vad som finns. Eftersom det handlar om mer än 10 000 objekt går det inte att få in alla i en lista, jag tror att ListeriaBot har satt någon gräns på maximalt 8 000 objekt.

--Larske (diskussion) 15 juni 2020 kl. 23.06 (CEST)

Harva

@Larske: et al. Funktionen harva är egentligen designad för Sverige. Den passar dåligt i USA, främst för att det finns åtminstone två typer av administrativa enheter på nivå 1 i bebodda delar av landet och åtminstone 55 typer i nivå 2 och åtminstone i Samoa är nivå tre relevant att ta hänsyn till i algoritmen. (Se Pago Pago). Tankar? 62 osv (diskussion) 15 juni 2020 kl. 19.35 (CEST)

Det går nog att göra en funktion "USAharva" som hämtar det som ska visas i infoboxen under respektive rubrik. Spontant känns det som en datadriven funktion, alltså med ett antal tabeller som man "slår upp" saker i, skulle passa bättre än att bara fylla på med fler och fler "if-satser" som till slut blir för krångligt att hålla i styr.

Först behövs dock en förståelse för hur man har modellerat egenskapen inom det administrativa området (P131) för alla de objekt som ska kunna använda modulen Ortsfakta USA WD. Tror att jag läst att du skrivit någonstans att för länder som USA, Frankrike, Tyskland gäller en mer strikt hierarki för denna egenskap så att ett visst ortsobjekt alltid har ett och endast ett värde på egenskapen inom det administrativa området (P131), alltså inte som Sveriges landskap, län, tätorter som ibland är gränsöverskridande, men jag kan ha missuppfattat dig. Även om det är så, behöver det kontrolleras att modellen efterlevs. Jag kollade de 9 781 objekt som är instans av (P31) stad i USA (Q1093829). Av dessa finns det 526 som har mer än ett värde för inom det administrativa området (P131). Värst i klassen är städerna Dallas (Q16557) och Fort Worth (Q16558) som båda har fem värden för inom det administrativa området (P131). Det liknar lite "kommuntillhörigheten" för tätorterna Stockholm (Q94385) och Göteborg (Q25287). Även om man skulle tillåta mer än ett värde på lägsta nivån så borde, med principen om "ett och endast ett värde" för inom det administrativa området (P131) för följande (högre) nivåer gälla, på samma sätt som en svensk kommun bara tillhör ett län, men inte heller så är fallet eftersom det finns ett antal stad i USA (Q1093829) som har värden på inom det administrativa området (P131) som i sin tur har mer än ett värde på inom det administrativa området (P131). Exempel på detta är (Q969371) som har just Dallas (Q16557) som inom det administrativa området (P131). Men att inom det administrativa området (P131) för denna stad i USA (Q1093829) är en annan stad i USA (Q1093829) och inte två county i Texas (Q11774097), nämligen Dallas County (Q111168) och Ellis County (Q110130), som det står i en:Glenn Heights, kan nog bara den bot, Lisp.hippie.bot [sic], som importerat detta från turkiskspråkiga Wikipedia (Q58255), se tr:Glenn Heights, Teksas, svara på.

Du kanske kan "rita upp" den bild du har av hur det borde se ut med de två typerna på nivå 1 och och de 55 typerna på nivå 2 så kan vi göra en inventering för att se hur väl verkligheten överensstämmer med den bilden.

Jag kan tänka mig att det behövs en hel del justeringar, som i till exempel (Q969371), för att få sortimentet stad i USA (Q1093829) moget för att skördas av mallen Ortsfakta USA WD.

Exempel:

• Länk till fråga som ger en lista på några objekt som är instans av (P31) något som är underklass till (P279) county i USA (Q47168) som har ett värde på inom det administrativa området (P131) som inte är instans av (P31) USA:s delstater (Q35657). (Objekt som är instans av (P31) (Q3301053) är exkluderade.)

Av listan ser man exempelvis den udda fågeln Oglala Lakota County (Q495201) som har ett inom det administrativa området (P131) som är instans av (P31) indianreservat (Q5398059), samt att man för några fall i New Mexico har "klämt in" ett Combined Statistical Area (Q2985090) mellan nivån (Q13414755) (som i skrivande stund saknar svensk etikett) och delstaten New Mexico (Q1522). Är detta något som vi bör räkna med att det kan dyka upp även för andra av USA:s delstater (Q35657)?

--Larske (diskussion) 16 juni 2020 kl. 06.08 (CEST)

Det är tydligare hierarki i USA, men den spårar ur ibland. Det finns enstaka städer som liknar våra gamla municipalsamhällen, som är självständiga i vissa hänseenden, men lyder under en annan stad i övrigt. Jag återkommer, nu har jag ett viktigt styrelsemöte att förbereda mig till. 62 osv (diskussion) 16 juni 2020 kl. 15.03 (CEST)

Indianreservaten följer sina egna udda regler. De lyder ju i princip inte under delstaterna ens, annat än i rent statistiska sammanhang. Så de är svåra. Jag är inte medveten om att vi har särskilt många artiklar om städer (helt) inom indianreservat, så det är nog ett icke-problem.

En village (kan ibland motsvara våra municipalsamhällen) kan ligga i flera towns och i flera countys. Men jag tror vi struntar i om de ligger i ett town. Återkom om du hittar någon som lagts så i praktiken. Och städer (både towns och citys) kan i princip också ligga i flera countys. CDPer kan också ligga i flera towns och flera countys. (De är en rent statistisk produkt.) Det förekommer också independent citys som ligger utanför alla countys. Det förekommer också att en city och ett county har slagits ihop. (Tänk Region Gotland eller Göteborgs kommun före läns/landstingsreformen.) De kan då ligga som (Q3301053). Bortser man från "consolidated city-county" så ska alla countys i 48 delstater vara av principen "county i 'delstat'" eller "county i USA". Lousiana har istället (Q13410524), som är samma sak som ett county. Alaska har "borough of Alaska", men det finns också boroguh-fria områden. Dessa delas istället in i (Q56064719). Alla dessa ligger i en "delstat i USA". Ingen stad kan officiellt ligga i mer än en delstat. Ligger en stad vid gränsen kan de ha delvis gemensam administration, men rent juridiskt är de alltid två städer.

Sedan har vi Territorium i USA. Det är i princip Guam, Am Samoa, Puerto Rico, Am Jungfruöarna och Washingtond DC. Hela DC ses väl idag som en enda stor stad snarare än ett territorium, så det är nog inget problem. (Hoppas jag.)

Am Samoa är indelat i distrikt och distrikten är indelade i countys. Här har vi den enda tredje nivån jag är bekant med.

Guam och Puerto Rico verkar ha en nivå av kommuner under territoriet. Finns det mindre enheter än så, så har vi nog inga artiklar om dem.

Jungfruöarna har jag inte undersökt så noga än.

Det finns fler territorier, men de har ingen befolkning och där är mallen därför irrelevant.

Jo, just det. Det finns en stad i Alaska som ligger i en municipality istället för en borough. 62 osv (diskussion) 16 juni 2020 kl. 21.32 (CEST)

Ser när jag tittar efter att funktionen "perferqualfiervalue" tillåter att man lägger in flera värden. som "Q1,Q2,Q3". 62 osv (diskussion) 19 juni 2020 kl. 08.38 (CEST)

@Larske: Jag har nu gjort en rekursiv funktion USAharva. Den är tänkt att hoppa över county-nivån i fall som Dallas. Men nu hoppar den över även delstatsnivån. Varför? 62 osv (diskussion) 19 juni 2020 kl. 13.01 (CEST)

 Fixat Det fanns ett villkor som gjorde att USAharva helt gav upp när det fanns mer än ett värde på inom det administrativa området (P131) på en nivå istället för att hoppa över den nivån och fortsätta med nästa nivå. Därför visades aldrig Delstat för Dallas (Q16557).

--Larske (diskussion) 19 juni 2020 kl. 13.54 (CEST)

Riskabelt med strängjämförelser

@Sextvåetc: Såg att du för att sätta rätt värde på variabeln p31 i funktionen USAharva (rad 999 och framåt) jämför etiketten för "entity2-objektets" P31-värde med olika teckensträngar, ibland på svenska och ibland på engelska. Det verkar mycket riskabelt. Om (läs När) någon ändrar etiketten, eller bara lägger till en svensk etikett i ett objekt som idag saknar sådan och där du har jämfört med en engelsk teckensträng, kommer jämförelsen att misslyckas. Jag föreslår att du istället hämtar och jämför med Qid för P31-värdet som antagligen är lite stabilare än etiketten.

Alltså

• jämför inte med "county of American Samoa" utan med "Q55030674".
• jämför inte med "distrikt i Amerikanska Samoa" utan med "Q15618465"
• och så vidare

--Larske (diskussion) 19 juni 2020 kl. 14.49 (CEST)

Jo, risken finns, men det är en lösning så länge. För Am Samoa är det absolut den bästa lösningen. Problemet med qid är att vi har minst 48 olika qid för "county i delstat". 62 osv (diskussion) 19 juni 2020 kl. 14.53 (CEST)

Alla de 48 countytyp-objekten är underklass till (P279) county i USA (Q47168) så en test på detta klarar alla staternas countyn på en gång utan att behöva göra någon strängjämförelse på 'county'.

En annan observation är att det finns massor av städer i Georgia som har två inom det administrativa området (P131) där den ena är ett county och den andra är delstaten. Det behövs därför en finare test än att bara hoppa över nivån om antalet P131 är större än 1. För till exempel staden Acworth, Georgia (Q344933) vill vi ju visa Cobb County (Q484247) som County, eller hur?

Observera att man inte kan förutsätta vilken av de två som är ett county och vilken som är en delstat. I Adairsville (Q346990) är ordningen på P131-värdena den motsatta mot i Acworth, Georgia (Q344933).

--Larske (diskussion) 19 juni 2020 kl. 20.55 (CEST)

Jo, men beroende på hur man ser på saken så är även Parish i Louisiana, Boroughs i Alaska, Distrikt i Am Samoa och Am Jungfruöarna också underklass till (P279) county i USA (Q47168). De är åtminstone ur US Census Bureaus synvinkel county-ekvivalenta. Det kanske inte är angivet så idag. Men om någon på WD tänker som jag, skulle de lägga in det så. För ett Parish i Louisiana har mer gemensamt med ett County i Alabama, än med ett Parish i Portugal. Vad gäller Georgia, så är det nog helt enkelt inlagt fel. Därför måste varje objekt i princip "städas" innan vi kan använda den här mallen här. Ett county i Am Samoa är däremot ur min synvinkel inte ekvivalent med ett county i Alabama. 62 osv (diskussion) 19 juni 2020 kl. 22.40 (CEST)

För att få en uppfattning om städbehovet, det är inte begränsat till enbart Georgia, kan man titta på följande lista.

• Länk till fråga som ger en lista på antal objekt som är underklass till (P279) administrativ territoriell enhet i USA (Q852446) och hur många objekt som är instans av (P31) av respektive typ samt hur många av dessa som har värden på inom det administrativa området (P131) som är instans av (P31) USA:s delstater (Q35657), hur många som har värden på inom det administrativa området (P131) som är är instans av (P31) underklass till (P279) county i USA (Q47168) samt, det viktigaste, hur många som har "både och". Det ser ut att röra sig om cirka 500 objekt som behöver "städas" med avseende på inom det administrativa området (P131).

En åtgärdslisteria för den här typen av felaktig klassificering kanske kan vara till hjälp. Ett utkast till en sådan finns i Sandlådan.

--Larske (diskussion) 20 juni 2020 kl. 08.50 (CEST)

De som är "consolidated city-county" är lite speciella. Där bör vi läsa på ordentligt innan vi gör något tokigt. 62 osv (diskussion) 20 juni 2020 kl. 09.24 (CEST)

Efter att ha läst på lite: De här fallen (consolidated city county) är lite speciella. Det är inte tekniskt fel att säga att de ligger både i delstaten och i ett county, eftersom de tekniskt sett ligger i ett county men att countyt rent tekniskt är en del av staden. Jag tror vi för de här fallen behöver en separat lösning. 62 osv (diskussion) 20 juni 2020 kl. 11.56 (CEST)

Trodde jag var smart

när jag gjorde detta, men det funkade inte. Lite förvånande då att USAharva fungerar. Men det kanske beror på att USAharva är en global funktion medan tidzon är lokal? 62 osv (diskussion) 23 juni 2020 kl. 15.32 (CEST)

Genom att lägga en kodrad som skapar en ny post som är en kopia av en befintligt post efter deklarationen av datastrukturen verkar det fungera.

Så här. --Larske (diskussion) 23 juni 2020 kl. 16.19 (CEST)

Hmm, jag skulle föredra att kunna lägga in delstaterna i bokstavsordning så de blir lätta att hålla ordning på. Kanske kan man definiera de olika tidzonerna som variabler först och sedan lägga in dessa variabler i matrisen? 62 osv (diskussion) 23 juni 2020 kl. 16.23 (CEST)

Vilken tidszon en viss stat använder och vilken offset som gäller för den zonen borde kunna hämtas från Wikidataobjekten för staten och för zonen. Det känns lite onödigt att behöva bygga upp denna information igen i den här modulen och "hålla reda på den" när den finns i Wikidata.

• deltstat/tidszon (P421) → tidszon (Q12143)
• tidsskillnad mot UTC (P2907)
• giltig under tidsperiod (P1264) (normaltid (Q1777301) eller sommartid (Q36669))

Kortnamnen, typ MST och MDT, borde väl kunna läggas in som "kortnamn" tidszonsobjekten i Wikidata.

Är det något annat du behöver kring tidszonerna som inte finns i Wikidata?

--Larske (diskussion) 23 juni 2020 kl. 17.19 (CEST)

Tidzonerna på Wikidata är en mardröm. De går inte att lita på alls. Det är vanligare att man hittar fel där än att man hittar rätt. Jag är ytterst tveksam till att använda det i Kansas också och vill helst hitta en annan lösning. 62 osv (diskussion) 23 juni 2020 kl. 18.25 (CEST)

Ja, det ser rätt rörigt ut vid en första anblick, men det borde väl gå att rätta eventuella fel.

Följande tabell är ett försök att med SPARQL ge lite struktur i denna datamängd. Där det saknades en tidszon (P421) som är instans av (P31) tidszon (Q12143) har jag använt ett objekt som är instans av (P31) IANA-tidszon (Q17272692).

• Länk till fråga som ger en lista över de tidszoner som enligt Wikidata gäller för respektive delstat och vilken offset som gäller för sommartid respektive normaltid.

SPARQL-frågan gör ingenting som inte också går att åstadkomma i Lua.

Förkortningarna, till exempel CST, har jag fuskat lite med och hämtat från engelska alias. Dessa tycker jag borde stoppas in som egenskaper i tidszonsobjekten.

Du kan säkert hitta saker som är fel i tabellen, men är det orimligt att i Wikidata rätta det som är fel så att objekten/egenskaperna relaterade till tidszon (P421) går att använda? En sådan rättning skulle ju vara till nytta för alla Wikipediaspråkversioner, inte bara svwp.

Stämmer det, som tabellen visar, att vissa stater, till exempel Tennessee, har olika tidszoner för olika countyn?

--Larske (diskussion) 23 juni 2020 kl. 21.55 (CEST)

Tidszonerna följer i många fall inte delstatsgränser. Det finns också områden i Arizona som inte har sommartid, d v s två orter i samma delstat har samma tid på vintern och olika på sommaren. Det går inte att bygga en funktion som bara bygger på delstater. --北山 Kitayama (diskussion) 23 juni 2020 kl. 22.01 (CEST)

Notera även i vissa fall kan även ett county ligga i två olika tidszoner. --北山 Kitayama (diskussion) 23 juni 2020 kl. 22.09 (CEST)

Utan att ha kontrollerat Larskes listor än. (På väg att göra kväll.) Det är bara i vissa delstater som hela staten har samma tid. Det finns som sagt exempel på där tidzonerna skär genom countyn och i enstaka fall rakt igenom städer. (de facto och de jure-tid) Arizona är lite av en mardröm. Officiellt kan det vara en sommartid i ett hus och i grannhuset normaltid. Gränsen mellan Navajo och den vita världen är i vissa områden definierad fastighet för fastighet. 62 osv (diskussion) 23 juni 2020 kl. 22.56 (CEST)

Ett annat problem är det det finns många olika typer av objekt för tidzoner. Ja, det kanske går att städa, men i så fall ett objekt åt gången, som jag gör i Norge nu. Men erfarenheten från biografi-mallen säger att det inte sker när det görs av många olika användare. 62 osv (diskussion) 24 juni 2020 kl. 10.33 (CEST)

Lite vågad approach för tidszoner

Jag har nu kodat om den del som skriver ut tidszonerna. Kod som:

		['Q771']   = tzest, -- Massachusetts
		['Q1384']  = tzest, -- New York

väljer vilken tid som gäller för hela delstaten.

Texas däremot har raden:

		['Q1439']  = {time1 = tzmst, time2 = tzcst, set1 = {'Q108494', 'Q110257'}, set2 = 'rest'}, -- Texas

Här har alla countyn i "set1" fått "time1" (MST/MDT) som tid medan resten får "time2" (CST/CDT).

Det går att lista countyn i "set2" precis som de i "set1" är nu. Då får dessa "time2" medan de som eventuellt inte finns i någon av listorna får använda Wikidata. Det vore tex en lösning för Arizona. Då får alla countyn utan sommartid listas i "set1". "set2" får bli en tom mängd och sedan får resten använda Wikidata eller anges manuellt i mallen. Städer som ligger i flera countyn, som Dallas får lita till Wikidata eller skrivas in manuellt. 62 osv (diskussion) 25 juni 2020 kl. 17.19 (CEST)

Flagga för county

Mallen anger flagga för delstaten i mallen. Det går enkelt att fixa så även countyts flagga ritas ut, när det finns (på Wikidata). Är det önskvärt? 62 osv (diskussion) 30 juni 2020 kl. 11.20 (CEST)

En uppenbar nackdel är att county-namnet ofta är längre än delstatsnamnen. 62 osv (diskussion) 30 juni 2020 kl. 11.50 (CEST)

Det är nog väldigt få läsaresom känner igen countyflaggorna. Så de hjälper inte att snabbare känna igen vilket county som en ort ligger i, det räcker att visa countynamnet. Flaggorna blir mest små otydliga färgfläckar i mallen. Jag tycker även delstatsflaggorna kan tas bort. De har samma problem med att inte kännas igen, dessutom är det svårt att se skillnad på dem i så litet format eftersom många av dem är ett blått fält med en liten symbol i mitten. F.d. 82.212.68.183 (diskussion) 12 juli 2020 kl. 12.56 (CEST)

Om syftet är att man ska känna igen flaggorna, så kan vi nog radera alla små flaggmallar. 62 osv (diskussion) 12 juli 2020 kl. 13.03 (CEST)

Vilket är syftet med flaggorna i den här mallen? Jag har inget emot att även andra flaggikoner tas bort. Nationsflaggikoner har till viss del liknande problem. Men betydligt fler använder känner igen fler av dem och i alla fall de enklare sorterna, som korsflaggor eller trikolorer, går att se vad de föreställer i små storlekar. F.d. 82.212.68.183 (diskussion) 12 juli 2020 kl. 21.29 (CEST)

När jag lade in den funktionen så följde jag modellen för hur det ser ut i förelöpare till den här mallen, i exempelvis {{Ortsfakta USA}}.

För mig är väl funktionen att det undervisar om hur flaggorna ser ut. Har jag läst tillräckligt många artiklar om Polen, så kanske jag till slut lär mig skillnaden mellan Polen, Monaco och Malta. Mer tveksamt om jag någonsin kommer lära mig skillnaden mellan Nederländerna och Luxemburg. 62 osv (diskussion) 12 juli 2020 kl. 21.41 (CEST)

Tidszoner till en annan modul?

@Larske: et al. Det vore gott om den här datan jag nu lägger in i modulen om alla countys tidzoner vore tillgänglig även från andra moduler. Tankar? 62 osv (diskussion) 4 juli 2020 kl. 18.17 (CEST)

Det går väl bra att lägga data i en egen modul. Sen får de moduler som vill använda den göra en "Require" på den modulen på samma sätt som när det är funktioner som man vill återanvända.

Men om data finns i Wikidata är det tillgängligt även för moduler i andra språkversioner än svwp. Har du verkligen inget hopp om att det ska gå att få ordning på tidszonerna i Wikidata? Det borde ligga i allas intresse.

--Larske (diskussion) 4 juli 2020 kl. 19.34 (CEST)

Nej, jag har inget hopp om att få ordning på det på Wikidata. 62 osv (diskussion) 4 juli 2020 kl. 20.19 (CEST)

Mummel, det där med require och sådant är jag uppenbarligen ingen hejare på... 62 osv (diskussion) 4 juli 2020 kl. 20.45 (CEST)

Jag tror att du måste "synliggöra" datastrukturen (med p. i stället för local), se hur jag gjort i Modul:Sandlådan/Larske/Testmodul11, på samma sätt som du synliggör en funktion som du vill ska kunna användas "utifrån". (Funktionen test kan du bortse från, den fyller ingen funktion i exemplet nedan.)

Här är resultatet av ett anrop en funktion i en annan modul som använder datastrukturen tidszon i Testmodul11:

Normaltiden i Guam är ChST

--Larske (diskussion) 4 juli 2020 kl. 21.56 (CEST)

Tack! Nu funkar det. 62 osv (diskussion) 5 juli 2020 kl. 08.01 (CEST)

Även om det är fullt möjligt att möjliggöra access till datastrukturer i andra moduler på det sätt jag demonstrerade med "Testmodul11" är det nog en ganska dålig programmeringsstil att göra så. När andra moduler har börjat använda detta sätt att hämta data om tidszoner är du helt låst till den valda datastrukturen och kan inte göra några ändringar av den utan att också göra ändringar i de andra modulerna.

Ett bättre sätt är då att behålla själva datastrukturen som "local" och tillhandahålla en eller flera accessfunktioner, p.nånting(par1,par2,...), som hämtar data. Dessa accessfunktioner måste vara stabila i sitt gränssnitt och erbjuda en bakåtkompatibilitet, det vill säga ett anrop som en gång har fungerat och givit ett visst resultat kommer alltid att leverera samma resultat oavsett om funktionen byggs ut med fler möjligheter. Men den interna datastrukturen kan du ändra på hur mycket du vill så länge accessfunktionerna levererar det de ska. Du kanske kommer på att det vore bättre att ha alla tidsoffset i en lista som indexeras med stat och normal/sommar i stället för att ha dem som nu. Du kan också erbjuda nya funktioner, till exempel en funktion, normaltid(land, stat) för att läsa ut normaltid. Dessutom blir koden mer lättläst i de anropande modulerna vilket underlättar för andra som kommer att använda dina data. Accessfunktionerna kan också utformas så att de kan hantera felaktiga indata och alltid ger ett kontrollerat resultat. Om man läser i data direkt från den anropande moduler blir det skriptfel om (Läs: när) något index pekar fel.

--Larske (diskussion) 5 juli 2020 kl. 08.44 (CEST)

Jag är amatör, jag har aldrig sagt något annat. Tanken här nu är att jag ska skriva en kodsnutt som jag kan lägga in i countymallen, för att detektera felaktigheter som kan ha smugit sig in i listorna. Det är därför jag vill komma åt den här datan utifrån nu. Vad vi har för nytta av den i övrigt ser jag inte direkt. En modul anpassad för countyn är förstås en möjlighet, men de mallarna håller i allmänhet redan ganska god kvalitét. Det har därför ganska låg prioritet. 62 osv (diskussion) 5 juli 2020 kl. 09.49 (CEST)

Land- och vattenarea

@Sextvåetc: Hej! Går det att anpassa mallen så att land- och vattenarea visas? Se exempelvis hur det ser ut med icke-WD faktamallen {{Ortsfakta USA}} i Akutan. Blir nämligen lite märklig befolkningstäthet, i fallen när stora områden av en viss stad råkar bestå av vatten, t.ex. Akutan (55%). Jag noterar att land- och vattenarea kan visas i Tromsø kommun, så kanske går det även i detta fallet. MVH/ YesDi (diskussion) 4 augusti 2021 kl. 21.26 (CEST)

RE:@YesDi, Larske: Den här typen av data lagras lite olika i olika delar av världen, just därför som jag valt låta den här typen av data har olika lösningar i olika del-moduler.

Men just Akutan visar problemet med den här lösningen. I Wikidata finns två data, 383 kvkm och 48,9 kvkm. Gäller 26,7 % vatten den första eller den andra siffran? Det går nog att reda ut i just det här specifika fallet [se källorna], men generellt?

Hade denna property angivits som qualifier, hade det varit mer semantiskt logiskt. Här blir det vilda västern! Kanske bör ta en diskussion om detta på Wikidata?

Jag kan försöka göra något åt den här modulen, men först vill jag se resultatet av en sådan diskussion. Själv har jag inte riktigt tiden att starta något idag! 62 mm (diskussion) 5 augusti 2021 kl. 21.03 (CEST)

@Sextvåetc: 26,7 % vatten gäller ytan om 48,9 kvkm (bägge uppgifterna är från folkräkningen 2010). Jag är själv inte speciellt insatt i Wikidata eller hur sådana här moduler programmeras, så att jag har svårt att kommentera dina andra funderingar. Tänkte inledningsvis att mallen var programmerad för att kunna visa land- och vattenarea och lade därför in dessa uppgifter i Bellevue, Washingtons WD-objekt (wikidata:Q214164). Om man lägger in uppgifterna på det sättet, skulle det gå att anpassa Ortsfakta WD till att visa dessa uppgifter? YesDi (diskussion) 5 augusti 2021 kl. 21.36 (CEST)

Ja, det är ungefär så vi löser det i fallet med Norge. Skillnaden är att i Norge har man data för "havsvatten", "glaciärer", "skog" etc. Det här är mer rakt på! 62 mm (diskussion) 6 augusti 2021 kl. 08.56 (CEST)

@YesDi: Fixat så det funkar med Bellevue. Det finner fler värden än land (Q11081619) och vattensamling (Q15324) som används som qualifier! Säg till om vi behöver lägga in fler... 62 mm (diskussion) 6 augusti 2021 kl. 09.07 (CEST)

Stort tack! Tror enbart att US Census Bureau utger data för land respektive vattenarea, alltså ingen specifik data för floder, insjöar, glaciärer mm. YesDi (diskussion) 6 augusti 2021 kl. 09.55 (CEST)

Nej, men det finns teoretiskt fler objekt på Wikidata för att beskriva "vatten" och "land". 62 mm (diskussion) 6 augusti 2021 kl. 10.13 (CEST)

Högsta och lägsta punkt

Nu finns högsta punkt (P610) eller lägsta punkt (P1589) bara i två artiklar som använder mallen men det funkar inte helt som det ska (Special:Permalink/54017712):

• högsta punkt (P610) och lägsta punkt (P1589) använder unknown value när platsen inte har ett namn. Det ser inte bra ut med engelska i faktarutan och det stämmer kanske inte att det är okänt vilken lägsta/högsta punkten är.
• Med unknown value blir det fel när det inte finns något objekt att hämta höjd och koordinater från (i exemplet verkar koordinater från artikelobjektet själv använts). Höjd och koordinater borde hämtas från kvalificeringarna höjd över havet (P2044) och geografiska koordinater (P625) om de finns.
• Med en känd plats hämtas höjd över havet (P2044) och geografiska koordinater (P625) från den platsens objekt. Men det är inte den platsens högsta/lägsta punkt. Även här borde kvalificeringarna höjd över havet (P2044) och geografiska koordinater (P625) för artikelobjektets högsta punkt (P610) och lägsta punkt (P1589) användas om det går.

90.227.175.218 14 oktober 2023 kl. 11.01 (CEST)