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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se