<html><head></head><body>Hej igen đ<br>Tusen tack för dina utförliga svar.<br>Jag Ă€r nu mera positivt instĂ€lld till importen. Jag ska titta nĂ€rmare pĂ„ en fil och Ă„terkommer. <br>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? <br><br><div class="gmail_quote">On January 22, 2020 1:34:35 AM GMT+01:00, Grigory Rechistov via Talk-se <talk-se@openstreetmap.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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>
</blockquote></div></body></html>