Hade det gått att sätta upp en WMS-tjänst som uppdateras periodiskt (dvs. efter hand tar bort namn som redan finns i OSM)? Alla som kan sina områden och känner sig säkra på hur man genomför en import kan jobba med OSM-filerna. Övriga/andra kunde sedan använda WMS-tjänsten som källa eller dubbelkoll-tjänst.
Kan förvisso bli ett problem med att inte visa place-noderna som av någon tidigare förkastats som otjänliga. @Grigory: Finns det nåt sätt vi som jobbar med kartan effektivt kunde ge feedback på datasetet? Både till dig och till Lantmäteriet. T.ex. tagga dålig data i filerna och skicka tillbaks till dig? Johan / <https://www.openstreetmap.org/user/Wulfmorn> On 22 January 2020 at 10:58:02 +01:00, pang...@riseup.net wrote: > Hej igen 😃 > Tusen tack för dina utförliga svar. > Jag är nu mera positivt inställd till importen. Jag ska titta närmare på en > fil och återkommer. > 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? > > > On January 22, 2020 1:34:35 AM GMT+01:00, Grigory Rechistov via Talk-se > <talk-se@openstreetmap.org> wrote: > > > 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> >
_______________________________________________ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se