[Talk-se] Ortnamnsimport från Lantmäteriets GSD-Terrängkartan

Wed Jan 22 13:52:57 UTC 2020

Vad tusan, skulle det inte finnas nån OSMare som kommer norrifrån? Vad är
det här för fördomar? 😉

Men oavsett om man har lokalkännedom eller inte så tror jag faktiskt inte
att det BEHÖVS så mycket lokalkännedom, utan det som behövs är helt enkelt
ett mänskligt öga som spanar på noderna och med lite sunt förnuft jämför
med ekonomiska kartan och topografiska kartan. Jag kan garantera att det
inte finns nån i den här församlingen som har besökt *alla *noderna IRL
ändå, så det löser sig nog ändå, även om man inte pratar lokalbefolkningens
dialekt 😊

/Tomas

Den ons 22 jan. 2020 kl 10:58 skrev <pangose at riseup.net>:

> Hej igen 😃
> Tusen tack för dina utförliga svar.
> Jag är nu mera positivt inställd till importen. Jag ska titta närmare på
> en fil och återkommer.
> Jag tror det går bra att vi med lokalkännedom laddar upp för ett område vi
> känner. Frågan är hur vi skal göra för dem delar av landet (i norr) där
> ingen av oss har lokalkännedom?
>
> On January 22, 2020 1:34:35 AM GMT+01:00, Grigory Rechistov via Talk-se <
> talk-se at openstreetmap.org> wrote:
>>
>> Hej Ture, Andreas, Anders, pangoSE och andra,
>> Längst ner följer mina kommentarer till dina svar.
>>
>> > Jag har för mig att LMV publicerade textlagren i två uppsättningar: en
>> ”kart”-uppsättning med snygga avstavningar, radbrytningar och så, och en
>> ”GIS”-uppsättning där namnen sitter ihop. Vilket av dem är det du tittar
>> på?
>>
>> Jag använder den "GIS"-uppsättningen, men, som du lagt märke till...
>>
>> > Sedan misstänker jag att även ”GIS”-uppsättningen lider lite av att vara
>> > ”en karta i shapefile-format”, snarare än en geodatabas — namnen är
>> placerade
>> > där det blir snyggt på en 50k-karta
>>
>> ...det har jag också märkt. Därför finns olika förkortningar och
>> radbrytningar
>> i källfiler vilka jag har kunnat åtgärda. Jag har i planer att kontakta
>> Lantmäteriet med en lista på ortnamns korrigeringar som jag samlat.
>> Kanske blir
>> någon intresserad i att uppdatera deras kartinformation för framtiden.
>>
>> > För herrgårdar kanske man kan passa på att lägga till historic=manor
>> samtidigt.
>> Jag har också tänkt på detta, men vågade inte räkna varje herrgård som en
>> plats
>> av historiskt värde.
>> Då kanske missförstår jag "historic=manor":s betydelse. Den taggen används
>> förresten inte mycket i Sverige, enligt detta:
>> http://overpass-turbo.eu/s/PY3 .
>> Endast 77 träffar.
>>
>> > Vi har ju även en hel del ställen som har ett namn, men där det är
>> ödehus
>> > eller sommarstugor eller fäbodar. Dessa borde även de klassas som
>> locality.
>> Det är precis den ursprungliga meningen bakom "place=locality". Att
>> importen
>> använder den taggen för herrgårdarna var en kompromiss som jag tillät
>> eftersom
>> jag inte kunde hitta ett bättre alternativ för något mindre än
>> "isolated_dwelling".
>> Då ansåg jag att "historic=manor" vore för specifikt. Men att bara kasta
>> iväg
>> noderna ville jag inte heller.
>> Låt mig tänka på det lite mer, hur det bästa lösningen skulle se ut.
>> Kanske skulle
>> jag omtagga dem till "isolated_dwelling", kanske till "manor", kanske
>> kasta bort.
>>
>> > Stadsdelar bör väl inte vara hamlet, utan neighbourhood?
>> Nej, "neighbourhood" är visst bättre för dem. För varje kartruta som
>> ligger nära
>> en större stad ska en uppladdare se till att "hamlet" blir till
>> "neighbourhood".
>> Det skulle vara uppenbart att upptäcka visuellt och fixa manuellt.
>> Det skulle inte finnas många sådana rutor som täcker stora städer. Stora
>> städer
>> brukar dessutom vara mer färdigt kartlagda vilket betyder mindre nya
>> noder att
>> importera runtom dem.
>> Jag kunde kanske ha löst problemet genom att tagga de noder som finns
>> inom städers
>> gränser på ett annat etikettsschema... Men det skulle ha varit för
>> beräkningsintensivt, och jag är inte redo att skriva en sådan algoritm
>> (ännu).
>>
>> > även om jag själv hade föredragit en adress-import.
>> Det skulle jag ha också föredragit, om jag hade tillgång till en öppen
>> databas
>> för ortnamn/adresser.
>>
>> > Gissar att merparten av de nya namnen inte längre används i vardagen.
>> Här kan vi endast tro på Lantmäteriets kompetens att hålla sina kartor
>> aktuella.
>> Men det gäller även själva OSM-projektet. Man litar nämligen på att andra
>> OSM:s
>> bidragsgivare har ritat något som stämmer i verkligheten. En gång hade
>> jag cyklat
>> till en skogsväg som visade sig vara ett dike på marken ¯\_(ツ)_/¯
>> Det är kanske också en ständig fråga för OSM: när blir historiska data
>> irrelevanta och bör suddas ur OSM-databasen? Jag är till exempel lätt
>> irriterad
>> att man tillåter ha "abandoned=railway" (drygt 256 tusen sträckor enligt
>> Taginfo!)
>>
>> > Vissa platser ser mer ut som "locality" medan några namn har helt klart
>> > felaktigt blivit "hamlet" fast det bara är en gård, om ens det.
>> Det finns sådan risk som jag skrivit i importplanen. Jag bedömer att ett
>> sådant
>> fel, om tillåtet vid importen, är av mindre vikt. Man kan väl strida om
>> "rätta"
>> etiketter till världens slut. Att det finns en plats med ett namn skulle
>> dock hjälpa
>> att upptäcka platsen och sedan att bedöma dess storlek och sedan rätta
>> till
>> "place=hamlet" till "locality" eller tvärtom.
>>
>> > Är det i såna fall möjligt att genereras nya filer efterhand, så man
>> ser vad
>> > som blir till övers på slutet?
>> Att generera ny filer efter jag korrigerat skript/input tar liksom 20
>> minuter
>> eller ännu mindre. Det är bara cirka 100 000 noder i hela landet vi talar
>> om.
>> Den nuvarande uppdelningen beror på Lantmäteriets eget schema. Men jag
>> kan enkelt
>> skära de nuvarande "regionerna" i bitar som täcker enstaka kommuner eller
>> till
>> någon annan nivås administrativa gränser som nu finns.
>>
>> > Jag rekommenderar att du sätter dig in i hemmansbegreppet och de olika
>> > skiftesreformer som gjorts i Sverige.
>> Tack, det ska jag göra. Angående de dubbletter som troligen skapas vid
>> kartbladens kanter, kan de åtgärdas genom att märkas som tveksamma eller
>> till och med raderas bort för säkerhets skull. Någonting var inte kartlagt
>> förut, och det blir inte tillagd efter, right?
>>
>> > Nej, så ska vi inte tagga. Ett objekt ska taggas en gång. Detta är en
>> grundläggande osm-regel
>> Ja, det är rimligt att importer följer denna regel. Då modifierar jag
>> skriptet att
>> vara mer aggressivt med att radera de nya noder som står i konflikt med
>> gamla lika
>> nämnda sträckor. Skriptet behöver även ta hänsyn till fler befintliga
>> etiketter
>> både på sträckor och noder så att det undvikas så många dubbletter som
>> möjligt.
>>
>> > Några fler exempel som är fel är Skanörsgården, Falsterbo vång och
>> > Falsterbohus. Den förstnämnda är namnet på ett bostadsområde, den andra
>> är
>> > knappt i allmänt bruk och den tredje syftar på ett känt före detta
>> > badhotell: ...
>> > Jag har tittat i Malmö, Lund, Landskrona och Helsingborg. Samtliga
>> > stadsdelar där är felaktigt angivna, och dessutom redan taggade på
>> annat sätt.
>>
>> Framförallt är jag imponerad hur väl landets södra delar är kartlagda.
>> Det vore
>> kul om de norra delarna blir lika bra en dag.
>>
>> > Tittar jag i din exempelfil ser jag att Ropsten är inlagd som isolated
>> > dwelling, vilket naturligtvis är fel (det är snarare ett
>> industriområde).
>> > Jag är inte tillräckligt bekant med Stockholm för att kommentera större
>> > delen av exemplen där, men samtliga ligger i tätbebyggt område och där
>> > använder vi inte place=hamlet över huvud taget.
>> > ...
>> > Ärtholmen (koloniområde), Söderkulla, Jägersro
>> > villastad, Stenkällan, Virentofta, Hohög, Kungshälla (namn som fallit ur
>> > bruk), Riseberga, Bulltofta, Valdemarsro, Segevång och "Västra
>> Hamnområden"
>> > (inte en etablerad term). Jag tror de flesta kan se bara på namnen att
>> > dessa inte är lämpliga att tagga som hamlet.
>> Tack för din utförliga feedback!
>> > Vad som är officiellt namn är mindre viktigt för vad som är taggat på
>> OSM.
>>
>> Nu undrar jag hur stor andel platser är där officiella och allmänna namn
>> inte
>> stämmer med varandra.
>>
>> > och inte sällan har platsnamn helt tolkats fel av lantmäterianställda
>> som
>> > inte förstått lokala dialekter.
>> När någon felstavar mitt namn (och det händer ofta) kan jag ändå oftast
>> begripa
>> att det verkligen handlar om mig. Det gör inget, för man kan rätta det
>> till senare.
>> Om någon inte känner till mitt namn blir det svårare att urskilja mig
>> från alla
>> andra personer vilkas namn är okända.
>>
>> > Då officiellt namn skiljer sig från det populärt använda namnet kan man
>> > använda sig av sidotaggen official_name
>> Och det finns också alt_name, name:sv, name:sju och dylika etiketter för
>> att
>> förvara så många namn. Mitt skript använder även dem för att hitta
>> dubbletter.
>> Visst kan det hända att Lantmäteriets data innehåller ett namn som är
>> såpass
>> dåligt stavat att dess närvaro på kartan är uppenbart skadligt, men tror
>> man att
>> det kan bli såpass farligt?
>>
>> > Vi bör inte importera data om vi inte kan vara säkra på att den är bra.
>> Nej, vi bör inte importera några noder *blint*. Därför poängterar
>> importplanen
>> på manuella granskningens stor roll. Därför delas importfilerna i små
>> rutor med
>> 200-400 noder (kan enkelt bli till ännu färre). En person skulle kunna
>> göra
>> översikt på en ruta i taget, utan att det blir för påfrestande. För varje
>> ruta
>> beslutar uppladdaren om några redigeringar/rensningar behövs, eller att
>> till och
>> med hela rutan är värdelös.
>>
>> > Att data är inhämtad av myndigheter är ingen garant för att den är bra.
>> Inget är något garanti att det nuvarande OSM-innehållet är aktuellt
>> heller. Vi
>> bara tror på andra användares vett och välvilja.
>> Vad man kan dock garantera att den "vita rymden" på OSM-kartan aldrig
>> stämmer
>> mot verkligheten.
>>
>> > Nej, införda fel kan aldrig rättfärdigas av att det redan finns fel i
>> databasen
>>
>> Jag anser två typer fel. Att en nod har ett fel namn eller position är
>> fel sort 1.
>> Om en nod motsvarande till en fysisk plats inte finns är fel sort 2. När
>> man
>> importerar (blint, utan redigeringar för enkelheten) data händer följande:
>> A. Gamla fel sort 1 stannar kvar
>> B. Gamla fel sort 2 tas bort
>> C. Nya fel sort 1 läggs till
>> D. Nya fel sort 2 läggs till
>> Hela balansen beror på att man tror att antal B-händelser är mycket
>> större än
>> C-händelser, och att D är litet.
>> Om man dessutom granskar och redigerar rutor innan uppladdningen kan man
>> även
>> minska A och C. Att minska D är det svåraste för att det kräver 100%
>> aktuell
>> kännedom på verkligheten.
>>
>> > att den totala andelen fel kanske minskar något för att den mängd data
>> som
>> > importeras är extremt omfattande.
>> Min beräkning var jätteenkelt och hade en variabel vilken var 1%
>> andel fel dolda i nya data. Även om andelen höjs till 20% förblir det
>> resulterande förhållandet bättre än utan importen. Man måste dock tycka
>> att
>> felen sort 1 och sort 2 har samma vikt, det vill säga att de är lika
>> dåliga att ha.
>>
>> > så undrar jag om vi inte ska byta strategi och i stället sätta upp en
>> server
>> som via MapWithAI serverar datan per område för manuel bearbetning?
>> Man kan alltid pröva! Det låter lovande för mig, fast jag inte har använt
>> detta
>> hittills. Jag undrar om dess RapiD-redigerare kan tolka noder, eller att
>> fokusen
>> ligger endast på gator/vägar. Hursomhelst, de importfiler som jag
>> publicerar är
>> öppna för alla att använda som kartunderlag eller på vilket sätt.
>> Jag vill dock fortfarande fokusera mig på att förbättra taggvalet och
>> namnjämförelseprocessen. Syftet är fortfarande att hjälpa förenkla
>> manuellt
>> arbete för varje ruta.
>>
>> Tack!
>>
>> Med vänliga hälsningar,
>> Grigory Rechistov
>> With best regards,
>> Grigory Rechistov
>>
>>
> _______________________________________________
> Talk-se mailing list
> Talk-se at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-se/attachments/20200122/a162bda8/attachment-0001.htm>