<HTML><BODY><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: http://overpass-turbo.eu/s/PY3 .<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>
</BODY></HTML>