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

Grigory Rechistov ggg_mail at inbox.ru
Wed Jan 22 00:34:35 UTC 2020


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
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-se/attachments/20200122/01a67faf/attachment-0001.htm>


More information about the Talk-se mailing list