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