Re: [Talk-se] Diverse frågor kring öar
Hej! Ett delsvar på fråga 2: place=locality som används för Jättholmarna nu är på sätt och vis en generell "i brist på bättre"-tagg. Den renderas i standardrenderingen på osm.org men bara med liten text från zoomnivå 16 och uppåt. En multipolygon för de ingående öarna med taggen place=archipelago [1] är en mer specifik taggning för det här fallet. place=archipelago renderas inte alls i standardrenderingen för närvarande, men det kommer antagligen att ändras förr eller senare. [2] Objekten kommer däremot upp i sökresultaten, se t ex [3]. Ett sidospår till fråga 3: Du har kanske redan märkt att kustlinjerna renderas om långsammare än andra OSM-objekt. Mer info om det finns på [4]. [1] https://wiki.openstreetmap.org/wiki/Tag:place=archipelago [2] https://github.com/gravitystorm/openstreetmap-carto/issues/3394 [3] https://www.openstreetmap.org/relation/10692170 [4] https://wiki.openstreetmap.org/wiki/Coastline Vänliga hälsningar Essin Den tors 23 juli 2020 kl 20:55 skrev Aron Bergman : > Hej, > Har under sommaren tagit båten till några lokala öar och passade på att gå > lite > stigar med OSMTracker och har suttit och lagt in det nu. Det har uppstått > en del > frågor som jag hoppades att någon här skulle kunna svara på, hade säkert > kunnat > sökt mig till infon, men det känns bättre att fråga personer som har > erfarenhet av > OSM. > > 1. På Gran finns en fyr och i närheten av denna finns som en träplatta > byggd. Min > far påstod att den skulle fungera som helikopterplatta, förmodligen > för att serva > fyren, men hittar ingen information om det online. Jag lade in plattat > i OSM, men > den är helt omärkt. Hur tycker ni att den ska mappas? Ska den mappas över > huvud taget? Hittade inte något sätt att märka den som just träplatta och > helikopterplatta kändes inte riktigt rätt heller (jag kan ju inte med > säkerhet säga att > det är det som den ska användas till). Plattan finns här [1], men hittas > inte av > "Query here", syns dock i JOSM. > > 2. Var också ut på Jättholmarna och gick en sväng och noterar nu när > jag lägger in > stigen att det inte står Jättholmarna någonstans på OSM-kartan, endast > Österön > och Västerön. Jag ser i JOSM att det finns en nod med namnet Jättholmarna, > men det renderas inte. Finns det något sätt att komma runt det? > Känner inte någon som har stuga på någon av ödelarna som säger att de har > stuga på Öster/Västerön. [2] > > 3. När jag lade in stigen på Jättholmarna så märkte jag att kustlinjen > ligger lite fel > på en del ställen, så det ser ut som att stigen går ut en bit i > vattnet ibland. Jag ska > ut dit igen och mappa en brygga som vi byggt om efter att isen > förstörde den förra, > så tänkte passa på att fixa kustlinjen då. Har funderat på att försöka > "flygfota" själv > med en drönare. Jag tänkte att om man kan få in ett par fasta föremål > (typ utmärkande stenar i vattnet) så borde man kunna lägga in de i JOSM och > sedan tracea bryggan utifrån fotona. Är det någon här som testat någonting > liknande innan? Det kanske inte är så lätt som jag tänker mig. > > [1] https://www.openstreetmap.org/way/828923027 > [2] https://www.openstreetmap.org/node/919814869 > > Hälsningar > Aron Bergman > > ___ > 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
Re: [Talk-se] Kartlägga kollektivtrafik på vatten
Hej! Tycker att alla dina synpunkter låter vettiga. Jag håller med om att olika färjelinjer som separata ways är alldeles för gyttrigt. Med förbehåll för att jag är landkrabba tycker jag egentligen att alla relationer som följer samma farled borde samlas på samma way, analogt med hur det fungerar på land där långfärdsbussar och stadsbussar kan följa samma gator, men det skulle kräva samråd med mappare i andra länder och förmodligen också datakonsumenter, så det kanske är ett rimligt första steg att samla en operator/network. Om du inte redan har sett det finns det ett försök till sammanställning av de linjer som redan är inlagda/påbörjade [1]. [1] https://wiki.openstreetmap.org/wiki/Sweden/Public_transport#Waxholmsbolaget //Essin Den sön 21 juni 2020 kl 13:52 skrev Erik Åman : > Hej! > > Jag funderar på att försöka förbättra hur båtlinjer i Stockholms skärgård > är kartlagda. Det vore intressant att få flera personers syn på hur det > görs bäst innan jag sätter igång. Det finns nog få områden i världen som > har ett lika komplicerat kollektivtrafiksystem på vatten, så jag tror att > detta är relevant att diskutera på den svenska listan. > > Det vanliga i OSM är att färjelinjer modelleras med alla attribut på en > way. I detta fall tror jag dock att man bör använda relationer (enligt > Public Transport Version 2), även om wiki-sidan [1] varnar att stödet för > det är begränsat. Försöker man rita ut varje färjelinje separat, blir det > på tok för gyttrigt (vilket är tydligt exempelvis runt Vaxholm). > > Vad jag undrar är till att börja med vilka relationer som bör utnyttja > samma way. Långdistanstrafiken med stora fartyg över Östersjön är redan > till största delen i from av relationer, se exempelvis way 140517501 [2] > och relationerna som använder sig av den. Min intuition säger mig att även > om de mindre skärgårdsbåtarna till viss del går i samma farled, bör nog > inte deras relationer använda sig av samma way (som ju räknas som en del av > Europaväg 20). Men var drar man gränsen? > - När det är olika värden för vilka som får åka med båten, exempelvis > motor_vehicle=yes/no > - När "operator" eller "network" har olika värden? > En relaterad fråga är vilka attribut som man bör lämna på en way för att > möjliggöra för datakonsumenter som inte har stöd för relationer. > > En annan fundering jag har är var man kan och bör ha förgreningspunkter. > Bara vid bryggor eller även ute i vattnet (som redan nu är fallet med > långdistanstrafiken). Mellan Kymmendö och Dalarö [3] finns exempelvis två > punkter där man kanske eller kanske inte vill ha förgreningar ute på > vattnet. Söder om Kymmendö (öster om Ornö) finns en färjelinje som > trafikerar många bryggor, medan den andra bara stannar vid vissa av > bryggorna, vilket också kan föranleda förgreningspunkter ute på vattnet. > > Det finns också fall där olika färjelinjer utan uppenbar anledning > kartlagts på olika sidor av mindre öar som inte trafikeras, exempelvis > nordväst om Sandhamn [4]. Förmodligen beror det på väder, > trafikförhållanden eller annat just den dag då någon lade till just den > linjen i OSM. Ska man slå ihop sådana fall till en gemensam sträcka som går > antingen den vanligaste eller den kortaste vägen? Kanske jämförbart med att > vid dubbelspårig järnväg lägger man relationen för en riktning på det spår > som oftast används, även om det inte finns någon garanti för att tåget > alltid går på det spåret. > > > [1] https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry > [2] https://www.openstreetmap.org/way/140517501 > [3] https://www.openstreetmap.org/#map=14/59.1227/18.4663 > [4] https://www.openstreetmap.org/#map=14/59.2951/18.9097 > > > /Erik Åman > ___ > 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
Re: [Talk-se] Administrativa gränser
Hej! Tycker att det verkar rimligt att göra något i den här riktningen. Jag började titta på det här problemet för flera år sedan men kom aldrig riktigt nånvart. Jag upptäckte då att i Sundsvalls kommun är nyckelkodsområden inlagda på nivå 9 (öppna data enligt http://sundsvall.se/kommun-och-politik/fakta-om-sundsvalls-kommun/psi-data-oppna-data/ ), men det är kanske ett fall för boundary=census? Ett mindre problem är att vissa kommundelar med administrativ funktion (som Stockholms stadsdelsområden) är större än distrikt, andra mindre. Jag tycker att det är rimligt att betrakta båda som aktuella administrativa enheter, så vi får helt enkelt leva med att vissa nivå 9-enheter omfattar flera nivå 8-enheter. När det gäller stadsdelar har vissa kommuner flera nivåer, t ex Lund där Lunds stad (den del av kommunen som är indelad i stadsdelar) för närvarande är nivå 8, "stadsdelsområden" (fem grupper av stadsdelar) är nivå 9 och de egentliga stadsdelarna är nivå 10. Går det att passa in i det här systemet? För att skilja på olika typer av historiska enheter vore det bra att även med boundary=historic använda admin_level (eller en motsvarande tagg med annat namn). På så sätt skulle man kunna ha en hierarki för landsdelar-landskap-(härader?)-socknar-fjärdingar/rotar/andra mindre enheter. När man pratar om "socknar" när det gäller t ex fornminnen har jag fått intrycket att det är jordregistersocknar som avses. Jordregistersocknarna, som blev historiska i och med fastighetsdatareformen 1976-1995 (olika tidpunkter i olika län), sammanföll inte alltid helt med kyrksocknarna/församlingarna, men skillnaderna är ofta så små att med de källor som vi har tillgång till idag är det nog inte meningsfullt att ha separata OSM-objekt för jordregistersocknar och distrikt utom där det skedde församlingssammanslagningar före 2000 som inte påverkade jordregistersocknarna. Jag har sett några sådana fall mappade i Västergötland. Hälsningar, Essin Den ons 10 juni 2020 kl 12:53 skrev Andreas Vilén : > Hej! > > Bra genomgång! > > Håller med om det mesta av vad du skriver. Angående de roten du hittat i > Lund syftar de på det som beskrivs här: > https://sv.wikipedia.org/wiki/Rote#Stadsdel_och_folkbokf%C3%B6ringsdistrikt. > De är historiska och kan nog ändras till en sådan taggning. De används dock > då och då i dagligt tal. Indelningen används även i > https://sv.wikipedia.org/wiki/Lunds_stadsk%C3%A4rna. Man kan dock notera > att källorna är från 60- och 80-tal. > > MVH Andreas > > On Wed, Jun 10, 2020 at 10:29 AM wrote: > >> Hej! >> >> Jag har tagit en titt på de administrativa gränser >> (boundary=administrative) som förekommer på OSM i Sverige. Dels vill >> jag ifrågasätta användningen av landsdelar som administrativ >> indelning, dels vill jag ha en mer konsekvent användning av >> admin_level för nivå 8, 9 och 10, det vill säga indelningar mindre än >> kommuner. >> >> I första frågan så finns det relationer för Norrland, Svealand och >> Götaland definierade på nivå 3, mellan Sverige som land (nivå 2) och >> län (nivå 4). Vad jag vet så är indelningen i landsdelar högst >> inofficiell om än allmänt accepterad, men absolut inte något som >> förekommer som administrativ indelning. Jag föreslår att admin_level=3 >> tas bort och att relationerna ändras till boundary=historic på samma >> sätt som landskapen. >> >> I andra frågan har jag med Overpass hämtat hem stora delar av Sverige >> och undersökt vilka indelningar som finns på nivåerna 8, 9 och 10. På >> OSM-wikin finns en sida >> ( >> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries) >> som dokumenterar vad som till stor del är sant, men en hel del avvikelser >> förekommer. >> >> Enligt den ska följande gälla: >> Nivå 2 är Sverige som land. >> Nivå 3 är landsdelar. >> Nivå 4 är län. >> Nivå 5-6 används ej. >> Nivå 7 är kommuner. >> Nivå 8 används ej. >> Nivå 9 är stadsdelsområden/stadsdelsnämndsområden/stadsdel (Umeå). >> Nivå 10 är stadsdelar/primärområden/stadsdelsområden (Umeå). >> >> I praktiken förekommer följande: >> Nivå 2-7 stämmer. >> >> Nivå 8 används för tätortsgränser i ett antal städer (Gävle, Göteborg, >> Lund, Skellefteå, Umeå, Åhus). En del också tillsammans med place=city >> eller place=town. De flesta har en kommentar i stil med >> "note=Tätortsgränsen följer inte LMs polygon slaviskt eftersom att >> denna inte täckte alla områden ordentligt" eller >> "description=Approximation of Lund city limit, fixme=refine". I >> Sundsvall/Västernorrland används istället nivå 8 till >> distriktsindelning och även till församlingar. I Stockholmsområdet &
Re: [Talk-se] Namnsättning av "dubbel-ö" i Vänern
Det här är ett intressant ämne, och jag tror att det finns flera möjliga
lösningar. Jag har mappat enligt alternativ 3 ibland, även om jag inte
heller är helt övertygad om att det är riktigt renlärigt. Om den ena ön är
tydligt större än den andra kanske man kan utgå från att det är den som har
gett namn åt den sammanvuxna ön, och betrakta den andra ön som en halvö. I
alternativ 1 skulle jag inte sätta place=islet på den sammanvuxna ön,
eftersom det ändå framgår av en inner-ring i en multipolygon (eller en ring
av ways med natural=coastline). Som det står på
https://wiki.openstreetmap.org/wiki/Key:place är place-taggarna för
namngivna platser, alltså betyder place=islet "det här är en namngiven
plats, mer specifikt en namngiven holme/liten ö".
//Essin
Den tis 2 juni 2020 kl 11:17 skrev Lennart Romberg <
lennart.romb...@gmail.com>:
> OK, ändrade enligt förslaget. JOSM-validatorn hade i alla fall inga
> invändningar. Får se om osmose klagar, men det brukar ta nån dag innan man
> ser.
> / Lennart
>
> Den tis 2 juni 2020 kl 10:39 skrev Lennart Romberg <
> lennart.romb...@gmail.com>:
>
>> Mm, funderade även på detta men på wikin står "An *island* is any piece
>> of land that is completely surrounded by water" och jag antog att samma
>> gäller "islet". Men visst, om man inte måste hålla strikt på "completely
>> surrounded" så köper jag gärna detta. Invändningar, någon?
>> / Lennart
>>
>> Den tis 2 juni 2020 kl 10:03 skrev Tomas Marklund <
>> tomasmarklun...@gmail.com>:
>>
>>> Jag tycker det ser ut som två öar som har växt ihop mer och mer
>>> såtillvida att det idag bara finns blötmark som sammanbinder dem. På
>>> flygfotona ser det inte ut att finnas nåt egentligt "vatten" mellan dem.
>>> Egentligen bara en ö, men de båda tidigare öarnas namn lever kvar på
>>> respektive "del" av ön.
>>>
>>> Så, här kommer alternativ 3 :-)
>>>
>>> Jag skulle göra två multipolygoner av dem, där var och en av MParna är
>>> en place=islet, och att de har en gemensam sträcka i mitten (svart) där de
>>> möts. MP1 (röd och svart sträcka) är place=islet, name=Näbben och MP2 (blå
>>> och svart sträcka). är place=islet , name=Näthall.
>>>
>>> I den stora multipolygonen "vänern" ingår då röd och blå sträcka som
>>> "inner".
>>>
>>> [image: image.png]
>>>
>>> /Tomas
>>>
>>> Den tis 2 juni 2020 kl 09:46 skrev Lennart Romberg <
>>> lennart.romb...@gmail.com>:
>>>
>>>> Hej!
>>>>
>>>> Noterade att en av Sättersholmarna utanför Hammarö i Vänern saknade
>>>> namn i OSM.
>>>> https://www.openstreetmap.org/edit?editor=id#map=16/59.3049/13.6137
>>>>
>>>> Kollar man på LM så har nord- och syddelen olika namn ("Näbben" resp
>>>> "Näthall"). Verkar inte finnas något namn på "hela ön". Tittar man noga så
>>>> verkar det finnas något smalt vattendrag (utan flödesriktning) mellan
>>>> halvorna. Har inte kollat på plats hur det ser ut. Nu funderar jag på olika
>>>> metoder att få in dessa namn på något vettigt sätt.
>>>>
>>>> En fråga är om det är en eller två öar. Finns antagligen nån ö-databas
>>>> som ger det officiella svaret men har inte lyckats snoka upp den.
>>>>
>>>> 1) En ö. Behålla place=islet och inte ge denna ett namn. Sätta
>>>> punktnod natural=peninsula + name=xx på respektive halva. Missbruk av
>>>> peninsula?
>>>>
>>>> 2) Dela ön i två. Rita om till två separata place=islet och sätta namn
>>>> på dem. Det smala utrymmet mellan dem ("vattendraget") får höra till Vänern
>>>> (som ett supersmalt sund). Fast är det verkligen två öar?
>>>>
>>>> Duger något av dessa, eller finns bättre förslag?
>>>>
>>>> / Lennart
>>>> ___
>>>> 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
>>>
>> ___
> 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
Re: [Talk-se] Problem med ortnamnsimporten
Hej! För att få en fingervisning om kvaliteten på själva datamängden som helhet har jag gjort ett stickprov bestående av ett område där jag har god lokalkännedom, nämligen Norbergs kommun. Kommunen omfattar ungefär 0,1 % av Sveriges yta och 0,05 % av befolkningen. Kommunen är kanske inte helt representativ -- det finns inga fäbodvallar eller större fritidshusområden och inte särskilt mycket lantlig bebyggelse överhuvudtaget -- utanför centralorten är det ärligt talat mest skog. Dessutom var i stort sett alla byar och många mindre platser redan utsatta. Det är alltså ett ganska litet urval (osäkert resultat) med huvudsakligen place=isolated_dwelling (antagligen sämre data än place=hamlet) och få obebodda platser (vilket borde dra upp kvaliteten jämfört med rikssnittet). Med Overpass Turbo [1] sökte jag efter alla place-noder i kommunen som redigerats de senaste fyra veckorna (för några dagar sedan, så det kanske borde vara fem veckor nu). Sedan jämförde jag med Topografiska och Ekonomiska kartan samt med Maxar Premium. Tyvärr är ju Ekonomiska kartan-TMS:en otillgänglig för tillfället så jag har sökt ut kartbladen från Lantmäteriet [2] vilket tar längre tid. I stort sett alla noderna sitter lite vid sidan av objektet de syftar på, vilket i många fall lätt hade kunnat justeras utifrån satellitbilder eller Topografiska kartan själv. Topografiska kartan har ju inte riktigt samma principer för nodplacering som OSM. Två platser har taggats som place=hamlet: Källtorp och Sågtorpet. De verkar vara okej enligt Topografiska och Ekonomiska (även om Sågtorpet historiskt har hört till Örbäck). En stor grupp är isolated_dwelling-noder som verkligen syftar på en isolerad bostad. Det är kanske något av en smaksak om man i stället ska sätta namnet på en farmyard- eller residential-polygon, vilket är vad jag oftast har gjort. Ibland finns en sådan (namnlös) polygon redan, ibland inte. Farmyard ska väl strikt taget bara användas för aktiva bondgårdar och taggas om till residential om jordbruket har lagts ner eller arrenderats ut -- jag har förmodligen brukat vara lite för generös med farmyard. (Fiskarstugan, Flöarna, Hagby, Lindvreten och Rökedalen där polygon finns, samt Fårbo, Källbo och Sjöänget där polygon ännu saknas). Två tveksamma fall, Ekorrbo och Gruvan, ser ut att ligga mitt ute i skogen på satellitbilder, men det är byggnader utsatta på Topografiska så det skulle kunna vara korrekt. Sen om nån faktiskt bor där är svårt att veta... Två isolated_dwelling-noder, Leonardsberg och Brogården, ligger inne i samlad bebyggelse och borde ersättas med place=farm eller name= på en residential= eller building=. I de här fallen gick det att avgöra med Ekonomiska kartan vilken tomt som avsågs, men jag vågar inte tro att det funkar i allmänhet. En isolated_dwelling-nod, Kapellbacken, verkar syfta på en samling av flera hus (som finns redan på Ekonomiska men utan namn). Jag kan inte helt avfärda möjligheten att det är ett av husen specifikt. Slutligen det största misstaget: Högfors bruk är taggad som place=farm. Bruket ägde visserligen jordbruksmark men i huvudsak är det en nedlagd och delvis bevarad industri. Bruksområdet utgör de centrala delarna av byn Högfors (sedan tidigare taggad som place=hamlet). Jag har inte hittat några namn som är uppenbart oanvända idag, men de flesta ensamgårdarna känner jag inte till bättre än som namn på en karta. Om vi antar att alla namnen används och att Ekorrbo och Gruvan kan räknas som isolated_dwelling snarare än locality är det alltså en träffsäkerhet på 12/16 = 75 %, och även de hyfsade 75 % är slarvigt gjorda. En överslagsräkning utifrån Andreas användaruppgifter (93 intensiva redigeringsdagar med cirka 1000 redigeringar per dagsverke) och en Overpass-sökning efter alla place-noder i Sverige som redigerats de senaste fem veckorna (som tuggade länge innan den kom fram till 117 172 noder) ger båda vid handen att ungefär 100 000 noder importerats, give or take. Norbergs kommun har alltså, jämfört med sin andel av ytan och befolkningen, en ovanligt liten del av importen, och man kan misstänka att "svåra fall" var överrepresenterade i de saknade namnen. På riksnivå skulle kanske 90 % i själva verket kunna vara någorlunda korrekta. Det innebär fortfarande att 10 000 mer eller mindre felaktiga noder tillförts på kort tid utan att någon vill ta ansvar för dem. Även om felprocenten är jämförbar eller något bättre än genomsnittliga nybörjare blir slutresultatet värre eftersom redigeringstakten är så hög. Jag är verkligen inte emot att använda Topografiska kartan som _en_ källa vid OSM-arbete, men att använda den som _ensam_ källa utan någon form av urval och ordentlig manuell kontroll blir inte bra. Jag förespråkar att dessa redigeringar återställs om inte importorganisatörerna erbjuder sig att städa väldigt snart. Vänliga hälsningar Essin [1] https://overpass-turbo.eu/s/U8q [2] https://historiskakartor.lantmateriet.se/arken/s/advancedsearch.html Den mån 18 maj 2020 kl 18:51 skr
Re: [Talk-se] Problem med ortnamnsimporten
Hej! Det slog mig att det här kanske inte är det importprojekt som planerades i vintras, utan ett separat projekt med samma/liknande mål. Om det var en förhastad slutsats att det är samma projekt får jag be Atakua om ursäkt. Oavsett hur det är med den saken är det problem med den import som nu genomförs. Hälsningar Essin Den lör 16 maj 2020 kl 16:59 skrev Andreas Vilén : > Hej! > > Jag och Essin har diskuterat detta lite under den senaste veckan och jag > har också tittat på datan här och där. För det mesta ser den väl hyfsad ut > på det sättet att den lyckats med att kopiera av (ja, vilken källa > egentligen, se längre ner) rätt så slaviskt (som jag förstått det). > Däremot, i tråden som föranledde den här importen, varnade jag vid flera > tillfällen för att datan inte är bra nog för att importera till OSM rakt > av, delvis för att den inte visar den typ av data som importörerna trodde. > Se tråden som Essin länkar till. Exempelvis verkar källan ha kopierat > Ekonomiska kartan, vilket lett till att platser dubblerats vid > kartbladsbyten i Ekonomiska kartan, bara för att ta ett exempel. Att > importera data som en gång redan importerats från en annan databas är skit > in skit ut skit in skit ut. > > Se mina inlägg > https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003791.html > > https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003793.html > > https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003797.html > > > Ännu ett konto som verkar ha bidragit till importen, men grupperat sina > edits lite bättre, är https://www.openstreetmap.org/user/operaman/history. > > De invändningar jag hade verkar dessa konton inte ha tagit till sig av. > Åtminstone är det väldigt svårt att avgöra när datan är så svår att > analysera. Jag tycker också det är problematiskt att ett antal nya konton > utan koppling till ordinarie användare på OSM plötsligt dyker upp för att > genomföra en import som denna. Om det handlar om användare som den som > skapade wikisidan rekryterat, bör han ha varit öppen med detta och uppmanat > dem att skriva något på sina användarsidor. > > Jag tycker definitivt att detta ska tas till DWG för revert. Vill man > titta på kartan som importerats kan man titta på den. Jag ser ingen > anledning att okritiskt importera data från den källan (eller någon annan > källa) till OSM. > > MVH Andreas > > PS: En cliffhanger från högre upp, vilken källa har egentligen använts? > Den tråd som Essin länkar till, och även importsidan på wikin, handlar om > Terrängkartan, men i kontonas källhänvisning står det Topografiska kartan. > > On Sat, May 16, 2020 at 3:39 PM Ture Pålsson via Talk-se < > talk-se@openstreetmap.org> wrote: > >> Gah, tusentals changesets med en nod per changeset. Och användaren >> tomas471 har en avatar som föreställer Bob Ross. >> >> Är det någon idé att dra in DWG så här långt efteråt? Det är ju frestande >> att säga ”reverta allt av de här användarna” bara för att importen är så >> illa genomförd, även om datat i sig är ok (jag har inte tittat så noga). >> >> 16 maj 2020 kl. 12:39 skrev Essin : >> >> Hej! >> >> För några dagar sedan började jag lägga märke till redigeringar som bara >> bestod av place-noder [1]. Efter ett tag insåg jag att de är en del av >> importen som diskuterades här i vintras [2]. Utifrån redigeringarna verkar >> det som att de är gjorda utan större hänsyn till vad som redan finns och >> utan större kontroll av den valda place-taggens rimlighet >> (place=isolated_dwelling på bondgårdar som ligger inne i byar och därför >> borde ha place=farm eller namnet på en landuse=farmyard-yta, dubbletter med >> befintliga landuse=farmyard- eller landuse=residential-objekt, place=hamlet >> som borde vara place=neighbourhood mm). Jag har letat, men inte hittat >> något sätt att enkelt se vilka redigeringar som ingår i importen. Det finns >> ingen hashtag eller annan standardiserad formulering i >> redigeringskommentarerna, det står inget på deltagande användares >> användarsidor, redigeringarna görs inte från separata importkonton, det >> finns inga import=yes-taggar på importerade noder, och det finns ingen >> lista över deltagare på wikisidan [3]. Dessutom lägger många användare in >> endast en nod per ändringsuppsättning, vilket gör det ännu mer >> svåröverskådligt. Finns det någon fungerande plan för genomgång och >> städning i efterhand? Det som står på wikisidan om samordning på denna >> mejllista och kontroll av enskilda användares redigeringar med Osmose >> verkar inte ha följts. >> >> Hälsningar >> Essin >> >> [1] https://www.openstreetmap.org/user/zag_abss/hi
[Talk-se] Problem med ortnamnsimporten
Hej! För några dagar sedan började jag lägga märke till redigeringar som bara bestod av place-noder [1]. Efter ett tag insåg jag att de är en del av importen som diskuterades här i vintras [2]. Utifrån redigeringarna verkar det som att de är gjorda utan större hänsyn till vad som redan finns och utan större kontroll av den valda place-taggens rimlighet (place=isolated_dwelling på bondgårdar som ligger inne i byar och därför borde ha place=farm eller namnet på en landuse=farmyard-yta, dubbletter med befintliga landuse=farmyard- eller landuse=residential-objekt, place=hamlet som borde vara place=neighbourhood mm). Jag har letat, men inte hittat något sätt att enkelt se vilka redigeringar som ingår i importen. Det finns ingen hashtag eller annan standardiserad formulering i redigeringskommentarerna, det står inget på deltagande användares användarsidor, redigeringarna görs inte från separata importkonton, det finns inga import=yes-taggar på importerade noder, och det finns ingen lista över deltagare på wikisidan [3]. Dessutom lägger många användare in endast en nod per ändringsuppsättning, vilket gör det ännu mer svåröverskådligt. Finns det någon fungerande plan för genomgång och städning i efterhand? Det som står på wikisidan om samordning på denna mejllista och kontroll av enskilda användares redigeringar med Osmose verkar inte ha följts. Hälsningar Essin [1] https://www.openstreetmap.org/user/zag_abss/history https://www.openstreetmap.org/user/tomas471/history https://www.openstreetmap.org/user/bob_curse_isaac/history https://www.openstreetmap.org/user/Sivia1811/history mfl [2] https://lists.openstreetmap.org/pipermail/talk-se/2020-January/003790.html ff [3] https://wiki.openstreetmap.org/wiki/Import/Catalogue/Lantm%C3%A4teriet_GSD-Terr%C3%A4ngkartans_ortnamnsimport ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Apropå svenska naturreservat i OSM
Hej! Jag håller inte riktigt med om att OSM:s naturreservat skulle vara undermåliga. Ja, de är dåligt uppdaterade, men i vissa andra avseenden är datasetet i OSM bättre än "originalet". Jag och några andra har gått igenom de ursprungliga importerna reservat för reservat och åtgärdat en del problem som fanns. Detta arbete är nu (åtminstone för min del) avslutat och har lett till bl a följande förbättringar: * De flesta (alla?) reservatsgränserna är resultatet av digitaliseringsprojekt som genomförts län för län. Vid länsgränserna var naturreservatsgränserna inte harmoniserade, utan grannreservat i olika län kunde överlappa varandra eller åtskiljas av en smal remsa. Detta är nu åtgärdat i OSM. * Där reservatsgränser sammanfaller med kommun-, läns- och riksgränser är de sammanslagna till en enda geometri som ingår i flera relationer. Reservatsgränserna är oftast de bästa geometrierna vi har för administrativa gränser. * Ibland är en naturreservatsgräns den bästa definitionen vi har av strömfåran i ett vattendrag. I sådana fall har reservatsgeometrin återanvänts för vattendraget. (Omvänt finns det kommungränser där den bästa definitionen av geometrin är ett vattendrag, eftersom Topografiska kartan inte är helt precis alltid.) Jag är medveten om att detta inte är helt okontroversiellt. * Ur ett mer OSM-internt perspektiv har reservat med flera åtskilda delar slagits ihop till multipolygoner, och en del taggar som duplicerar information som numera finns på annat sätt i OSM (t ex is_in= och lst:kommun=) har tagits bort. Jag är positiv till en nyimport av ändrade gränser, om den inte förstör det arbete som lagts ner på att förbättra befintliga data. Hälsningar, Essin Den fre 27 mars 2020 kl 12:21 skrev pangoSE : > Hittade just denna diskussion: OBF file for fuel price from > http://prix-carburants.economie.gouv.fr > https://github.com/osmandapp/Osmand/issues/5658 > > Här finns scripts för att skapa en obf utifrån extern data och det verkar > som att det kan fungera i tandem med OSM datan som ett lager uppepå OSM > https://github.com/cbosdo/osmand-fuel-price > On 2020-03-27 12:02, pangoSE wrote: > > Hej John > > Jag är helt enig. Om detta skal funka då måste vi se till att det är > busenkelt att koppla på/av källor med olika lager. > > Kanske är inte openstreetmap.org rätta stället för detta? Utvecklarna > verkar väldigt konservativt inställda till ändringar, så det är nog för > mycket att hoppas på. Att få dem att erbjuda upp till ett tiotal WMS-lager > där per land ser jag inte som troligt i första laget. > > Jag tänker att detta kanske kommer hända på openstreetmap.org samtidigt > som vi byter från raster tiles till vektor tiles. Vad jag vet är det inga > bra argument för att fortsätta med raster tiles när nu teknologin för > vektor tiles finns. OsmAnd är helt vektor, Thunderforest har bytt, Mapbox > har bytt. > > Raster tiles har dem 2 stora nackdelar att dem fyller en massa på disk och > kräver mycket resurser att generera. Vektor kan serveras direkt från en > databas (se detaljer https://www.thunderforest.com/blog/) > > Ang. OsmAnd så tänker jag mig att tex för Sverige så kommer det finnas en > extra fil för naturreservat, och extra för skyddsområden (eller båda i en > fil). Denna data dras från NV regelbundet (källa här > https://wiki.openstreetmap.org/wiki/Sweden/Open_data/Naturv%C3%A5rdsverket#Boundary). > Den måste konverteras till först osm/pbf (via ogr2ogr) och därefter *.obf > format via (https://wiki.openstreetmap.org/wiki/OsmAndMapCreator). Vad > jag vet kan OsmAnd bara tugga en obf åt gången i dagsläget för ett givet > område ( > https://android.stackexchange.com/questions/141666/how-to-import-an-obf-map-file-into-osmand) > vilket betyder att för att få med nationalparker/reservat så måste dem > flätas in i osm datan först (via osmium) och därefter konverteras > resultatet till obf. > > Om detta ligger flera år ut i framtiden så är frågan om vi ska vänta med > att radera dem områden vi redan har inne och bara vara tydliga med att vi > inte uppdaterar dem längre. > > WDYT? > On 2020-03-20 10:48, John Bäckstrand wrote: > > Jag håller principiellt med, men "discoverability" är så oerhört viktigt, > så det enda system som "drar in data från flera ställen" som duger, i min > mening, vore ett centralt system som fungerar auomatiskt på > openstreetmap.org och de vanliga tile:sen. Allt annat kommer ju försämra > upplevelsen och jag vet hur lat jag själv är, att få allt serverat för sig > är en viktig faktor. Tar det 5 minuter att få till en vettig karta istället > för 10 sekunder så räcker det för att gå någon annan stans. > > Men det är mitt perspektiv. > > /John Bäckstrand > > On Fri, Mar 20, 2020 at 10:42 AM wrote: > >> Hej på er. >> >> Är det nån här som håller m
Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta
Hej! Till att börja med vill jag be om ursäkt för att svaret har dröjt. Jag ville skriva ett genomtänkt svar, och under tiden har jag haft mycket att göra utanför OSM. Den ons 12 feb. 2020 kl 13:30 skrev pangoSE : > On 2020-02-08 13:13, Essin wrote: > > Hej! > > > > PangoSE, kan du till att börja med be SCB att uppdatera sin hemsida? För > > närvarande står det visserligen att tätortsgeometrierna är öppna data > > [1] men också att deras öppna data är CC-BY-licensierade [2] vilket inte > > är tillräckligt för OSM [3]. Det är ingen bra idé att ladda upp data med > > oklar licens. > > Som jag skrev i min epost: > "LM har släppt alla tätortspolygoner som CC0 så det är bara att importera. > (Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)" > > Eftersom det är SCB som definierar tätorternas avgränsning [1] är jag starkt tveksam till att LM har rätt att släppa datamängden under en öppnare licens än den SCB använder. Det här måste verkligen redas ut _innan_ fler tätortsgränser läggs in i OSM -- i värsta fall får vi be DWG om en redaction om det visar sig att SCB inte vill släppa dem som CC0. > > > > Tätortsavgränsningarna ritas om från grunden vart tredje år. Vem tar > > ansvar för att det hålls uppdaterat någon längre tid? Vi har fortfarande > > kvar mera begränsade tätortsuppgifter som blev inaktuella 2015, t ex > > [4], och eftersom ändringar i tätortsindelningen inte är direkt > > observerbara på marken kan det dröja länge innan någon märker att något > > är fel, om det inte kontrolleras systematiskt. Ett liknande fall är > > naturreservaten, som importerades runt 2010. Jag har under en längre tid > > sysslat med att gå igenom naturreservaten för att slå ihop överlappande > > gränser, och där finns det många fall av gränsförändringar och nyskapade > > reservat som inte har uppdaterats trots att naturreservaten har mer > > stabila gränser än tätorterna. > > Va bra! Jag är medveten om att detta är ett stort jobb. Jag föreslår att > vi automatiserar det som jag skrivit tidigare. > > > > > Tätortsavgränsningarna har ingen som helst administrativ funktion och > > det är därmed direkt fel att tagga dem som boundary=administrative. > > Tätbebyggda områden (som kommunerna använder för att avgränsa t ex > > 50-begränsningar och tomgångskörningsförbud) har en viss administrativ > > funktion och är indirekt observerbara på marken genom vägskyltar när man > > passerar deras gränser, men det är en annan sak. Möjligtvis skulle > > boundary=census [5] fungera för tätortsavgränsningarna, om de trots alla > > invändningar ska finnas i OSM. > > > > > Jag blir ännu mer skeptisk när jag ser hur tätortsavgränsningarna har > > lagts in hittills, som i Malmö [6]. Relationen har note=Tätortsgränsen > > följer inte LMs polygon slaviskt eftersom att denna inte täckte alla > > områden ordentligt. Vad är överhuvudtaget meningen med att rita ut > > tätortsgränser separat på OSM om det inte är de av SCB definierade > > tätorterna? Den dataanvändare som vill använda OSM-data för att få en > > uppfattning om bebyggda områden får ett bättre resultat av att aggregera > > urbana markanvändningstyper som landuse=residential, industrial, retail > > etc, eller i välmappade områden (som Malmö!) genom att analysera > building=*. > > > Jag gillar ditt argument här. Jag la första gång in en > boundary=administrative när det behövdes för att få > https://maposmatic.osm-baustelle.de/ att funka som tänkt för svenska > tätorter. Detta kan ju uppfattas som tagging for the renderer vilket jag > inte är tillhängare av. > Det går bra för mig att vi ändrar till =census och jag håller med om att > vi då bör bevara polygonformerna som dem kommer från LM (eller SCB om > nån lyckas övertycka chefledet om det tokiga med valet CC-BY, se > https://se.wikimedia.org/wiki/%C3%84mne:Vavz1c9h6p2kc1l5) > > Tyvärr innebär detta att maposmatic/myosmatic inte kommer ha med alla > vägar inom tätorten Malmö som jag som användare skulle förvänta mig om > jag söker på Malmö och gör en karta över denna stad. Det innebär att > verktyget kanske måste ändras till att göra den analys du föreslår för > att själv hitta avgränsningar för tätorter via en algoritm. > "Tagging for the renderer" är ju inte bara tillämpligt på renderare utan även på andra användningar av OSM:s data. Utvecklarna av Maposmatic kanske främst har byggt upp det utifrån förhållandena i Tyskland, och inte tänkt på att det kan vara annorlunda i andra länder. Om Maposmatic inte tar hänsyn till boundary=census är det den tjänsten som borde förbättras. > > Det finns f.ö. över en miljon place=city som är ritad som area i > databasen, hur ställ
Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta
Hej! PangoSE, kan du till att börja med be SCB att uppdatera sin hemsida? För närvarande står det visserligen att tätortsgeometrierna är öppna data [1] men också att deras öppna data är CC-BY-licensierade [2] vilket inte är tillräckligt för OSM [3]. Det är ingen bra idé att ladda upp data med oklar licens. Tätortsavgränsningarna ritas om från grunden vart tredje år. Vem tar ansvar för att det hålls uppdaterat någon längre tid? Vi har fortfarande kvar mera begränsade tätortsuppgifter som blev inaktuella 2015, t ex [4], och eftersom ändringar i tätortsindelningen inte är direkt observerbara på marken kan det dröja länge innan någon märker att något är fel, om det inte kontrolleras systematiskt. Ett liknande fall är naturreservaten, som importerades runt 2010. Jag har under en längre tid sysslat med att gå igenom naturreservaten för att slå ihop överlappande gränser, och där finns det många fall av gränsförändringar och nyskapade reservat som inte har uppdaterats trots att naturreservaten har mer stabila gränser än tätorterna. Tätortsavgränsningarna har ingen som helst administrativ funktion och det är därmed direkt fel att tagga dem som boundary=administrative. Tätbebyggda områden (som kommunerna använder för att avgränsa t ex 50-begränsningar och tomgångskörningsförbud) har en viss administrativ funktion och är indirekt observerbara på marken genom vägskyltar när man passerar deras gränser, men det är en annan sak. Möjligtvis skulle boundary=census [5] fungera för tätortsavgränsningarna, om de trots alla invändningar ska finnas i OSM. Jag blir ännu mer skeptisk när jag ser hur tätortsavgränsningarna har lagts in hittills, som i Malmö [6]. Relationen har note=Tätortsgränsen följer inte LMs polygon slaviskt eftersom att denna inte täckte alla områden ordentligt. Vad är överhuvudtaget meningen med att rita ut tätortsgränser separat på OSM om det inte är de av SCB definierade tätorterna? Den dataanvändare som vill använda OSM-data för att få en uppfattning om bebyggda områden får ett bättre resultat av att aggregera urbana markanvändningstyper som landuse=residential, industrial, retail etc, eller i välmappade områden (som Malmö!) genom att analysera building=*. Hälsningar Essin [1] https://www.scb.se/vara-tjanster/oppna-data/ [2] https://www.scb.se/vara-tjanster/oppna-data/oppna-geodata/tatorter/ [3] https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ [4] https://www.openstreetmap.org/node/1779070277 [5] https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dcensus [6] https://www.openstreetmap.org/relation/10663667 Den tors 23 jan. 2020 kl 14:39 skrev pangoSE : > Hej. > > Jag tycker att vi skal tolka tätortsområden som administrativa gränser för > våra städer. Det är den bästa källa vi har, alternativet är att göra dem > subjektivt själva som jag ser det. > > Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock bara > släppt dem som CC-BY varför jag föreslår att vi tar dem från LM. Jag ser > inte det som ett problem att gränserna uppdateras när byn byggs ut eller > stadsdelar rivs. > > Dem används inte bara av rendere också av tex > https://maposmatic.osm-baustelle.de där det inte i dagsläget går att göra > en karta över tex Malmö av skälet att staden inte är definerad som område. > > Se skillnaden när du söker här på härnösand vs malmö: > https://maposmatic.osm-baustelle.de/new/# > > Vi saknar altså vettiga admin boundaries på våra städer. Alla svenska > städer jag testade utom Härnösand och Umeå kunde inte lätt hittas. > > När man skapar bykartor då är det vettigt att bara ta med gatunamn inom > byområdet och detta gör verktyget om vi har definerad gränserna. > > Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en bilaga > där området utanför tätorten är grått och gator som ligger utanför > byområdet inte tas med i indexet, se: > https://maposmatic.osm-baustelle.de/maps/100341/qlPljYcLvFQNZKTI > direktlänk till pdfen: > https://maposmatic.osm-baustelle.de/results//100342_2020-01-23_14-30_umea.pdf > > mvh > > pangoSE > On 2020-01-23 13:49, Andreas Vilén wrote: > > Tätortspolygoner ändras varje gång det görs en ny uppdatering, ett område > byggs eller liknande. Det finns ingen etablerad taggning för detta och jag > tror inte det är lämpligt att lägga in. > > Tätorter är inga administrativa enheter och har normalt inga gränser mer > än rent statistiska. > > /Andreas > > Skickat från min iPhone > > 23 jan. 2020 kl. 13:18 skrev pangoSE : > > Hej > Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. (se > https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964 > ) > > På större zoom nivåer saknas städer i SE pga att dem endast är inritade > som noder. tex > https://nominatim.openstreetmap.org/details.php?place_id=133125 > > I Danma
Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej! Åre kommun blev inte heller så bra, åtminstone inte den del jag känner till i detalj, se min changesetkommentar [1]. Jag tror att en del av problemet är att NMD är just marktäckedata (landcover), medan OSM i första hand innehåller markanvändning (landuse). Distinktionen mellan markanvändning och marktäcke är ett återkommande ämne på Tagging-mejllistan och jag är inte så pigg på att ta upp den debatten igen, men jag skulle vilja påpeka att just landuse=grass har varit särskilt omdiskuterad i de sammanhangen eftersom den trots namnet egentligen är en marktäckestagg (om man inte anser att "gräsmatta" i sig är en markanvändning). I både Åre och Åstorps kommuner märks det att det fortfarande finns många omappade hus i Sverige, så att undvika områden runt hus hjälper bara en liten bit på vägen. Jag utgår från att ni som importerar själva tar ansvar för att städa upp de första omgångarna innan importerna fortsätter. Vänliga hälsningar Essin [1] https://www.openstreetmap.org/changeset/70936570 [2] https://lists.openstreetmap.org/pipermail/tagging/ Den mån 30 sep. 2019 kl 16:58 skrev Eva Lindberg : > Hej! > > Jag läste mailet nedan från Grigory. Angående gräsmarker: Vet ni att det > finns tilläggskikt till NMD med markanvändning? Se här: > > https://gpt.vic-metria.nu/data/land/NMD/NMD_Produktbeskrivning_tillaggsskikt_Markanvandning_v1_2.pdf > Där finns golfbanor, koloniområden, kyrkogårdar osv som kan tänkas bli > klassade som gräs. Det kanske är användbart. > > Dessutom kan det vara bra att känna till att NMD är baserat både på > satellitbilder och laserdata, där den senare datakällan ger information > om höjd och täthet hos vegetationen och alltså i princip är bra på att > skilja på skog och icke-skog. Det borde nog stå på wiki-sidan så att > ingen tror att skog bara är klassat från satellitbilder eftersom det > skulle bli ganska dåligt. > > Vänliga hälsningar > Eva Lindberg > > > On 2019-09-28 03:05, Johan Emilsson wrote: > > Hallå, > > > > Finns det någon uppdatering att ge kring importen? > > Hojta om det finns behov av hjälp. Kan tänka mig att samköra någon > > av de > > > > större kommunerna kring Åre. > > > > /Johan > > > > On Thu, 13 Jun 2019 at 12:54, Grigory Rechistov via Talk-se > > wrote: > > > >> Hej på er alla! > >> > >> Förlåt mig för längre tystnad på den här listan, var upptagen > >> med livet/jobbet > >> och orkade bidra till OSM endast sent på kvällarna då var det > >> inte bästa tillfällen > >> att kolla/svara mejl. > >> > >> Låt mig svara på alla förfrågor/kommentarer som nyligen samlades > >> i tråden. > >> > >>> Jag såg att Åstorps kommun laddades upp. Det blev inte så bra: > >>> > >> > > > http://grillo.users.openstreetmap.se/a1dd1280bc521ca2725f8b8daaee11f993800871.jpg > >> > >> Nej, det gjorde det inte. Hoppas att det inte skapade för mycket > >> besvär att > >> rätta till. > >> > >>> Jag håller på att städa och önskar att du kunde låta bli att > >> importera så nära tätort. > >> > >> Jag försöker alltid städa bostadsområden eftersom man > >> förväntar sig > >> att se bättre objektsuppställning där, och det går enklare att > >> manuellt rita där > >> med renare slutresultat. Men ibland slippar ändå någonting över > >> byggnader. > >> > >>> Dessutom önskar jag att du hade någon form av varningssystem så > >> du inte laddar upp överlappande data. > >> Om ett område är omringat med "landuse=residential" undvikas det > >> helt i mina skript. Ifall det inte finns en sådan polygon (vilket > >> sker ganska > >> ofta men inte är något fel på det) raderar jag datat runt orten > >> manuellt om jag > >> ser det. > >> Jag vill nu också inkludera en tiotal meter "buffert" runt enstaka > >> byggnader > >> på ett liknande sätt hur det nu är med vägar och järnvägar. > >> Detta ska hjälpa > >> förhindra tätorters nedsmutsning även om någonting inte är > >> omringat med "residential". > >> > >> Åstorps kommuns import var ett försök att lära mig hur det gick > >> med på att importera NMD-datat i en kommun som huvudsakligen var > >> täckt av > >> åkermark och som redan var 50%-kartlagd. > >> Jo, det visade sig att bli jobbigt att justera polygoner längs > >> flera långa vägar > >> och att se till att alla små detaljer läggas rätt. Men det var > >> möjligt i alla fall, > >> fastän med fler misstag än önskades. > >> I fra
Re: [Talk-se] Ang. källor för korrigering av mindre sjöar/skogstjärnar
Hej! Yahoo syftar på gamla satellitbilder [1] så namnet kommer ändå från någon annan källa (inklusive local_knowledge). Om man får tro wikin [2] är det numera att föredra att sätta source-taggar på ändringssetet, bland annat just eftersom det är jobbigt och ibland otydligt att ange vilken info om ett objekt som kommer från vilken källa. [1] https://wiki.openstreetmap.org/wiki/Yahoo!_Aerial_Imagery [2] https://wiki.openstreetmap.org/wiki/Key:source Hälsningar Essin Den 6 januari 2018 15:36 skrev Christian Asker <christian.as...@gmail.com>: > Hej. Ekonomiska kartan har ju ofta sjönamn med. Hur ser det ut för ditt > fall? > > Mvh Christian > > "Jimmy Utterström" <jim...@outlook.com> skrev: (6 januari 2018 13:20:51 > CET) > >> Hej! >> Jag sitter och ser över mappningar som gjorts i södra lappland och håller >> bland annat på att korrigera lite större skogsytor som ser ut att ha lagts >> till utan att skapa multipolygoner så att de inomliggande sjöarna renderas >> korrekt. Jag har dock upptäckt en inkorrekt mappning där en mindre >> skogstjärn har givits samma namn som en större intilliggande. Jag funderar >> dock lite kring vilka källor som är acceptabla att ange som "source" när >> jag senare checkar in min korrigering. Det är nämligen så att den användare >> som lagt till den (gunnar1m) har angivit "Yahoo" som tidigare källa. Jag >> skulle därför vilja ange en ny källa så att den person som utförde den >> ursprungliga mappningen kan kontrollera varifrån jag fått uppgifterna från. >> >> I detta fall skulle jag kunna använda "local knowledge" eftersom det är >> mina hemtrakter och jag har hyfsad koll på området, men bäst vore ju om >> det gick använda exempelvis SMHIs sjöregister som källa. För där finns det >> korrekta uppgifter för tjärnen. Men som jag förstått det så är inte CC BY >> 4.0 (som SMHI använder?) helt kompatibel med OSM, stämmer det? Finns det >> några andra bättre datakällor för sjöar jag kan titta i? >> >> Med vänliga hälsningar, >> Jimmy Utterström >> > > -- > Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet. > > ___ > 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
Re: [Talk-se] Församlingshem: vilka taggar finns och hur ska man använda dem?
Den 30 december 2017 01:22 skrev Erik Johansson <erjo...@gmail.com>: > 2017-12-28 22:02 GMT+01:00 Essin <user.es...@gmail.com> >> >> När jag tog upp det här i #osm på IRC kom några invändningar mot den >> första taggningen, för det första eftersom församlingshemmens verksamhet >> kanske inte är tillräckligt utåtriktad för att räknas som community_centre, >> för det andra för att "parish hall" i Storbritannien ofta syftar på något >> snarare motsvarande sockenstuga, alltså den icke-kyrkliga betydelsen av >> "parish", och för det tredje för att ordvalet passar dåligt på samfund som >> inte har territoriella församlingar. Det visade sig också att den är >> ifrågasatt på wikin [5]. Frågan är då: ska man anse att taggningen ändå är >> en förbättring och använda den med förhoppning om att den ersätts av något >> ännu bättre senare, eller ska man avstå från att använda den? >> >> > Jag är av den fasta åsikten att OSM taggar måste vara generella och > specifika, därför är community centre den bästa taggningen, med extra > taggning som särskiljer det från andra sådana ställen. Församlingshem, ABF > hus och bygdegårdar fungerar som knutpunkter i många samhällen alltså ett > community, man vill dessutom gärna kunna hitta dit men inte till > organisationen som driver det. > Kontroversen om amenity=community_centre rör som jag förstår det huvudsakligen inte nyttan med en sådan övergripande tagg, utan namnet: taggen hade en snävare betydelse förut. Men det är kanske en mindre fråga om man är beredd på att det kan bli massomtaggningar i framtiden. Kör event_venue om du verkligen måste ha något som redan är definierat, om > inte det så tycker jag det kan vara en bra idé att köra på den svenska > termerna som värde till communit_centre= eftersom de är någorlunda > väldefinierade i vår kulturellasfär. Det med lite Wiki dokumentation är > perfekt. > Kan du utveckla lite varför events_venue skulle vara den lämpligaste taggen? De flesta aktiviteterna i de församlingshem jag känner till är sådant som barn- och ungdomsverksamhet, böneluncher och liknande. Dokumentationen av community_centre=events_venue säger "A community-driven space for holding events. See also amenity=events_venue for places where events are commercially organised." och amenity=events_venue exemplifierar "events" med "formal dinners, dinner-dances, weddings or other celebrations". Sådana evenemang förekommer i mindre utsträckning i församlingshem -- principiellt sett visserligen kanske den del som är mest tillgänglig för icke-medlemmar, men missionerande religioner brukar välkomna även icke-medlemmar till sina aktiviteter. Taggar på svenska riskerar att är bara motiverade om fenomenet "församlingshem" verkligen är unikt för Sverige, och inte går att beskriva på (brittisk) engelska. Utifrån de diskussioner jag har haft på IRC och sett på wikin verkar det som att något i vart fall mycket liknande finns i andra länder. office=* känns helt fel, förutom när det verkligen är ett kontor som är > huvudfunktionen (vilket jag aldrig stött på vilket naturligtvis färgar min > åsikt). > Jag håller med om att kontorsverksamheten inte är den huvudsakliga i ett församlingshem (till skillnad från en renodlad pastorsexpedition, som är sällsynt nuförtiden men går att hitta), men om den finns där tycker jag ändå att den är tillräckligt viktig för att taggas _tillsammans med_ taggar för den sociala verksamheten. Det hade varit en annan sak om kontoren bara var för driften av själva församlingshemmet. Hälsningar Essin ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Vertikala förbindelser
Vertikala förbindelser är kluriga, särskilt hissar och spiraltrappor där utgången på olika nivåer leder åt samma håll. Jag har en tendens att fuska genom att förskjuta ways rakt ovanför varandra lite i sidled (inom brons/korridorens/etc fysiska bredd och flygbildernas osäkerhet). Ett par exempel som jag har jobbat lite med, helt utan anspråk på att nuvarande lösning är den optimala: http://www.openstreetmap.org/#map=19/55.58594/13.04595 http://www.openstreetmap.org/#map=19/55.70695/13.18646 http://www.openstreetmap.org/#map=19/56.35526/12.80156 Hälsningar Essin Den 9 december 2017 21:03 skrev Ture Pålsson <t...@lysator.liu.se>: > Jag vet i alla fall ett ställe där det finns en förbindelse som borde vara > antingen abstraherad till en rent vertikal förbindelse (två noder på samma > punkt, vilket antagligen skulle ge flera renderare hicka), eller > detaljkarterad som en rätt komplicerad sak i 3D (om man ska modellera hur > det verkligen ser ut) (vilket förmodligen också skulle ge flera renderare > hicka), men som är karterad som ett mellanting som egentligen inte har > mycket med verkligheten att göra, nämligen trappan från Sankt > Eriksgatan/Sankt Eriksbron ner till Norrbackagatan: https://www. > openstreetmap.org/?mlat=59.33795=18.03512#map=19/59.33795/18.03512 > > Så det finns i alla fall ”prior art” för att göra en fullösning… > > — T > > 9 dec. 2017 kl. 18:49 skrev Bo Lindbergh <b...@stacken.kth.se>: > > Nyombyggda Roslags Näsby station: http://liveevents.nu/sl/sl_1_1280u.jpg > https://www.openstreetmap.org/#map=18/59.43531/18.05764 > > Hur taggar man att: > a) vänthallarna har ingång från gång- och cykelbron > b) vänthallarna är förbundna med respektive plattform via trappa, > rulltrappa och hiss? > > Man vill ju att ruttplanerare skall kunna producera "trappan upp till bron; > halvvägs över bron; genom vänthallen; trappan ner till plattformen". > > > /Bo Lindbergh > > > ___ > 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 > > ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Ändra linknummer på E-vägar
Hej! Ingår verkligen grenvägar i vägen de fått sitt nummer efter, eller är det bara en bieffekt av hur NVDB är uppbyggd? Jag har inte kollat alla vägkungörelser [1] nu, men åtminstone en del av dem listar grenvägar/anslutningsvägar/förbindelsevägar som vilka andra vägnummer som helst, utan att underordnas huvudvägen. I skyltningen är det IMHO vanligare att grenvägar inte nummerskyltas alls än att de skyltas med huvudnummer -- E 4.26 är antagligen ett undantag för att den är så kort. Har Trafikverket dokumenterat detta någonstans? Jag har letat men bara hittat mycket kortfattade beskrivningar. I närheten av grenvägens anslutning till sin huvudväg är det kanske snarare destination:ref= [2] än ref= som huvudnumret borde taggas som. Sedan tror jag att du överskattar hur mycket manuellt jobb som skulle krävas. Overpass Turbo [3] är väldigt användbart i såna här sammanhang. Man kan t ex göra en sökning på alla vägar med ref= inom ett givet område som innehåller en punkt, ladda ner detta som en fil, göra en sök-och-ersätt, och ladda upp filen till OSM. Hälsningar, Essin [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/List_of_roads [2] https://wiki.openstreetmap.org/wiki/Proposed_features/ Destination_details#destination:ref [3] http://overpass-turbo.eu/ Den 11 oktober 2017 15:31 skrev David Olsson <da...@davido.me>: > Hejsan, > > Känner mig relativt säker på att jag använde fel termer också alt bara > blandade ihop saker. En ny "TL;DR" hade varit att inte använda undernummer > i "ref" istället för att börja snacka om linknummer osv och bara använda > benämningen huvudnummer och undernummer (termer som används i NVDB). Så det > är inte enbart påfarter och avfarter som har undernummer som är taggade med > huvudnummer+undernummer. > > T.ex E4.26 har "E4" som huvudnummer i NVDB och 26 ligger i en annan kolumn > vid namn undernummer. Så i exemplet med E4.26 så är det i dagsläget: > "ref" : "E4.26" - huvudnummer+undernummer. > Förslag till ändring: > "ref" : "E4" - huvudnummer > "official_ref" : "E4.26" - undernummer > > Uttrycket att det är rådande praxis att använda skyltade nummer (E4 och > inte E4.26) inuti "ref" är jag inte så säker på mer än jag hörde det från > Minh (Mapbox-OSRM) som finns i en kommentar på github-issuen i trådstarten. > Samtidigt finns det runt 1800 saker som har undernummer i Sverige inuti > "ref". > > Har eventuellt möjlighet att be några bekanta att hjälpa mig tagga om ref > som innehåller undernummer, men det är inget jag vill göra utan att ha en > diskussion kring det först. > > Mvh > David > > 2017-10-11 15:12 GMT+02:00 Essin <user.es...@gmail.com>: > >> Hej! >> >> Först en terminologifråga: Inom OSM brukar link användas om påfarts- och >> avfartsramper, t ex motorway_link. Det som diskuteras här kallas i en >> otydligt skriven och dåligt källbelagd Wikipediaartikel [1] för "grenväg", >> så jag använder den termen i brist på bättre. >> >> På ramper taggas normalt inte ref= i OSM även om numret skyltas utan >> streckad ram och det står så i NVDB. Undantaget är när man måste följa >> rampen för att passera trafikplatsen längs vägen med ett visst nummer. Ett >> alternativ för att tagga hur det skyltas är destination:ref= och >> destination:ref:to= [2] (den senare motsvarar streckad ram). E 4.26 är så >> kort att det är möjligt att hela sträckan skyltas som en ramp. >> >> Jag är ganska övertygad om att nummer på grenvägar samt sekundära och >> tertiära länsvägar bör finnas i OSM (se [3]), men jag är mer agnostisk om >> hur de ska taggas. "Tagging for the renderer (and routing software)" [4] är >> en aspekt som är relevant i sammanhanget. Det finns ju också andra saker i >> OSM som har namn eller nummer som inte skyltas, till exempel små >> vattendrag. När den stora skogsbranden i Västmanland pågick sas det på >> nyheterna att branden var på väg att korsa väg 668 i riktning Norberg, och >> då var det praktiskt att snabbt kunna kolla i OSM vilken väg det var. >> >> Om en omtaggning ska göras vore det bra om den kan göras mekaniskt på en >> gång för hela Sverige, så att vi inte hamnar i ett läge där olika delar av >> landet tillämpar olika konventioner. >> >> [1] https://sv.wikipedia.org/wiki/Grenv%C3%A4g >> [2] https://wiki.openstreetmap.org/wiki/Proposed_features/Destin >> ation_details >> [3] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/List_of_roads >> [4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer >> >> OSM-hälsningar, >> Essin >> >> Den 28 september 2017 10:37 skrev David Olsson <da...@davido
Re: [Talk-se] Ändringsset: 52111741
Nu fixat, det gick lätt med https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter /Essin Den 11 oktober 2017 13:38 skrev Essin <user.es...@gmail.com>: > Hej! > > Har detta åtgärdats än? Annars kan jag göra ett försök. JOSM-validatorn > (över)reagerar ofta på byggnader som verkar vara korrekt taggade enligt > Simple 3D buildings-systemet, så det är antagligen där problemet ligger. > > OSM-hälsningar, > Essin > > Den 19 september 2017 18:55 skrev Tobias Johansson <tj771...@gmail.com>: > >> Hej >> >> Såg att en byggnad i Göteborg har oturligt ändrats (enligt mig fel). Jag >> tror inte det är pga av någon elak anledning utan bara pga inte kännedom om >> hur buildings 3d funkar. >> >> https://www.openstreetmap.org/changeset/52111741#map=19/57.70132/11.91397 >> >> Jag vet inte riktigt hur man kan gå till väga för att reverta ändringen >> men någon annan kanske har koll. Jag har lagt till en kommentar på >> ändringssettet i fråga. >> >> -- >> MvH Tobias Johansson >> E-Post: tj7712...@gmail.com >> >> ___ >> 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
Re: [Talk-se] Ändra linknummer på E-vägar
Hej! Först en terminologifråga: Inom OSM brukar link användas om påfarts- och avfartsramper, t ex motorway_link. Det som diskuteras här kallas i en otydligt skriven och dåligt källbelagd Wikipediaartikel [1] för "grenväg", så jag använder den termen i brist på bättre. På ramper taggas normalt inte ref= i OSM även om numret skyltas utan streckad ram och det står så i NVDB. Undantaget är när man måste följa rampen för att passera trafikplatsen längs vägen med ett visst nummer. Ett alternativ för att tagga hur det skyltas är destination:ref= och destination:ref:to= [2] (den senare motsvarar streckad ram). E 4.26 är så kort att det är möjligt att hela sträckan skyltas som en ramp. Jag är ganska övertygad om att nummer på grenvägar samt sekundära och tertiära länsvägar bör finnas i OSM (se [3]), men jag är mer agnostisk om hur de ska taggas. "Tagging for the renderer (and routing software)" [4] är en aspekt som är relevant i sammanhanget. Det finns ju också andra saker i OSM som har namn eller nummer som inte skyltas, till exempel små vattendrag. När den stora skogsbranden i Västmanland pågick sas det på nyheterna att branden var på väg att korsa väg 668 i riktning Norberg, och då var det praktiskt att snabbt kunna kolla i OSM vilken väg det var. Om en omtaggning ska göras vore det bra om den kan göras mekaniskt på en gång för hela Sverige, så att vi inte hamnar i ett läge där olika delar av landet tillämpar olika konventioner. [1] https://sv.wikipedia.org/wiki/Grenv%C3%A4g [2] https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details [3] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/List_of_roads [4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer OSM-hälsningar, Essin Den 28 september 2017 10:37 skrev David Olsson <da...@davido.me>: > Streckade skyltar är inte samma sak i.o.m det är var man är på väg till om > man fortsätter på vägen (men lite OT). T.ex E4.26 är fortfarande Europaväg > 4 inuti nvdb. Hittade även flera streetviewbilder där skyltarna längst > rutten stod som E4 (inte streck) > > OSRM (Open Source Routing Machine) använder "ref" (och vägnamn, vilket > ledde till min undermåliga formulering tidigare) för att skapa > instruktionerna till användarna. Och då är det viktigt att användarna får > instruktioner som matchar informationen i verkligheten (som skyltar och > dess nummer). Så när man kör på en Europaväg så behöver det stå numret och > inte nummer + undernummer i.o.m skyltarna enbart visar huvudnumret. (Det > var här jag blandade ihop med vägnamn, osrm använder vägnamn och/eller > 'ref' för att bygga instruktionen). > > Det verkar också ha varit standard att tagga skylt-info som ref (Med > skyltinfo menar jag att i detta fall enbart skriva E4 och inte E4.26) och > sedan lägga till hela numret, inkl undernummer, i official_ref. Det känns > mest naturligt att lägga det i official_ref då undernumret är hos nvdb. > > "The prevailing practice in OpenStreetMap is to reserve the ref tag for > signposted route numbers. " > > Så ta bort undernummer på vägar inuti 'ref' och sedan lägga till en tag, > official_ref som inkluderar undernummer. Så blir det väl perfekt? Vill > givetvis inte gå rogue och börja tagga om utan att fråga här först. Men iom > det är rådande praxis att 'ref' ska vara skyltade vägnummer så borde vägar > vars nummer inkluderar undernummer taggas om, och man bör ha detta i åtanke > vid nya vägar. > > Hoppas jag förtydligade mig lite. > > 2017-09-28 1:07 GMT+02:00 Andreas Vilén <andreas.vi...@gmail.com>: > >> Fast de vägar som är länkvägar är väl inte skyltade E4 osv med ifyllda >> ramar utan streckade? Då dessa vägsträckor inte är en del av själva e-vägen >> utan har ett internt nummer bör dessa nog inte skyltas med huvudnumret. >> >> Jag tror att skälet till att dessa nummer, liksom de sekundära >> länsvägarna, börjat användas mer i media är för att de renderas på osm och >> även här och där på eniro och andra kartor. Det vore då i min mening synd >> att åter dölja dessa. Men det är egentligen helt rätt att de passar bättre >> i official_ref eller unsigned_ref. >> >> /Andreas >> >> Skickat från min iPhone >> >> 25 sep. 2017 kl. 09:35 skrev David Olsson <da...@davido.me>: >> >> Lekmanna-miss av mig. Jag syftar såklart på vägnumret och vad som finns i >> ref-taggen. Och förstår jag allt rätt så ska "ref" vara i princip det som >> står på skylten. (E4 i detta fall). >> Så ändra ref : E 4.26 till enbart ref: E 4 och sedan lägga till en >> "official_ref : E 4.26" tycks vara den bästa lösningen, likt 1ec5 nämnde i >> kommentaren på github. >> >> Ber om ursäkt för missen, jag som tyckte E4 är namnet på vägen när det >> ege
Re: [Talk-se] Ändringsset: 52111741
Hej! Har detta åtgärdats än? Annars kan jag göra ett försök. JOSM-validatorn (över)reagerar ofta på byggnader som verkar vara korrekt taggade enligt Simple 3D buildings-systemet, så det är antagligen där problemet ligger. OSM-hälsningar, Essin Den 19 september 2017 18:55 skrev Tobias Johansson <tj771...@gmail.com>: > Hej > > Såg att en byggnad i Göteborg har oturligt ändrats (enligt mig fel). Jag > tror inte det är pga av någon elak anledning utan bara pga inte kännedom om > hur buildings 3d funkar. > > https://www.openstreetmap.org/changeset/52111741#map=19/57.70132/11.91397 > > Jag vet inte riktigt hur man kan gå till väga för att reverta ändringen > men någon annan kanske har koll. Jag har lagt till en kommentar på > ändringssettet i fråga. > > -- > MvH Tobias Johansson > E-Post: tj7712...@gmail.com > > ___ > 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
Re: [Talk-se] Mekanisk redigering: uic_ref på busshållplatser
Eftersom det inte kom några invändningar genomförde jag omtaggningarna. 5126 noder med uic_ref=74n men inte railway=* eller train=yes taggades om till gtfs_id=7400n. 153 noder och relationer med nat_ref=7400n taggades om till gtfs_id=7400n. 98 noder och relationer med stop_id=74n och stop_url= http://reseplanerare.resrobot.se/bin/query.exe/sn?start=1=74n taggades om till gtfs_id=7400n och url= http://reseplanerare.resrobot.se/bin/query.exe/sn?start=1=7400n. 34 stop_area-relationer med uic_ref=74n sorterades för hand i busshållplatser, som taggades om till gtfs_id=7400n, och järnvägsstationer, som fick behålla uic_ref men även fick gtfs_id=7400n. Busshållplatsernas uic_name= byttes i förekommande fall ut mot nat_name=. 1 nod (Docksta busstation) taggades om från gtfs_id=74n till gtfs_id=7400n. Vänliga hälsningar Essin Den 27 maj 2017 12:40 skrev Essin <user.es...@gmail.com>: > Jag upptäckte att det finns en mer specifik tagg för Samtrafikens (och > motsvarande) referensnummer: gtfs_id=* [1][2]. Jag modifierar därför mitt > förslag: uic_ref=74n och stop_id=74n ska ändras till > gtfs_id=7400n i stället för nat_ref, och ett antal > public_transport=stop_position och =stop_area där jag redan har hunnit > ändra för hand ska ändras från nat_ref=7400n till gtfs_id=7400n. Om > det inte kommer några invändningar genomför jag antagligen detta i början > av nästa vecka. > > Vänliga hälsningar > Essin > > [1] http://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification > [2] https://taginfo.openstreetmap.org/keys/gtfs_id#overview > > Den 25 maj 2017 16:53 skrev Essin <user.es...@gmail.com>: > >> Hej listan! >> >> Jag har jobbat en del med busshållplatserna i Trafikverkets statliga >> CC0-vägdata, en beskrivning finns på [1]. Jag har bland annat lagt in >> hållplats-ID, som i Trafikverkets data är ett tal på formen 74n, som >> uic_ref= eftersom UIC-nummer också har det formatet (74 är landskoden för >> Sverige) [2]. Efter att ha lusläst dokumentationen (detaljer på [1]) har >> det visat sig att numren är tänkta att motsvara Samtrafikens hållplats-ID, >> men att Samtrafiken/Trafiklab för något år sedan ändrade sina hållplats-ID >> till formen 7400n (som inte följer UIC-standarden och alltså definitivt >> inte är en uic_ref) utan att Trafikverket följde med i det. Jag skulle >> därför vilja ändra uic_ref=74n till nat_ref=7400n. Trafiklabs egna >> data är _inte_ släppta under OSM-kompatibel licens, men jag har svårt att >> tänka mig att transformationen 74 -> 7400 i sig skulle vara katalogskyddad. >> >> En ändring av uic_ref berör 5126 noder som har highway=bus_stop och/eller >> bus=yes och jag skulle därför vilja göra det som en mekanisk redigering, >> men vill först kolla att ingen har invändningar, i enlighet med Automated >> Edits code of conduct [3]. Det finns även 34 stop_area-relationer som är >> taggade med uic_ref men de kommer jag att gå igenom för hand eftersom en >> del är järnvägsstationer som rimligtvis både har Samtrafiken-nummer och >> UIC-nummer. Av samma anledning kommer jag inte att röra noder (och vägar) >> som har någon railway-tagg eller train=yes. >> >> Det finns också äldre data med busshållplatser (36 noder och 63 >> relationer) som är taggade med stop_id=74n. Även dessa skulle kunna >> taggas om mekaniskt på liknande vis. >> >> >> Förslag till arbetsgång för mekanisk redigering: >> 1. Hämtning av busshållplatser med uic_ref med följande Overpass >> API-anrop i JOSM: >> >> [out:xml][timeout:122]; >> area >> [boundary=administrative] >> ["admin_level"="2"] >> ["name"="Sverige"] >>-> .a; >> >> ( >> node["uic_ref"][!"railway"]["train"!="yes"](area.a); >> ) ; >> (._;>;); >> out meta; >> >> >> 2. Resultatet sparas som en OSM-fil och redigeras i Notepad++ genom att >> ersätta "'uic_ref' v='74" med "'nat_ref' v='7400" och "timestamp=" med >> "action='modify' timestamp=". >> >> 3. Filen öppnas i JOSM igen och laddas upp. >> >> >> Vänliga hälsningar, >> Essin >> >> >> [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/trafi >> kverket/bussh%C3%A5llplatser >> [2] https://wiki.openstreetmap.org/wiki/Key:uic_ref >> [3] http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct >> > > ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Mekanisk redigering: uic_ref på busshållplatser
Jag upptäckte att det finns en mer specifik tagg för Samtrafikens (och motsvarande) referensnummer: gtfs_id=* [1][2]. Jag modifierar därför mitt förslag: uic_ref=74n och stop_id=74n ska ändras till gtfs_id=7400n i stället för nat_ref, och ett antal public_transport=stop_position och =stop_area där jag redan har hunnit ändra för hand ska ändras från nat_ref=7400n till gtfs_id=7400n. Om det inte kommer några invändningar genomför jag antagligen detta i början av nästa vecka. Vänliga hälsningar Essin [1] http://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification [2] https://taginfo.openstreetmap.org/keys/gtfs_id#overview Den 25 maj 2017 16:53 skrev Essin <user.es...@gmail.com>: > Hej listan! > > Jag har jobbat en del med busshållplatserna i Trafikverkets statliga > CC0-vägdata, en beskrivning finns på [1]. Jag har bland annat lagt in > hållplats-ID, som i Trafikverkets data är ett tal på formen 74n, som > uic_ref= eftersom UIC-nummer också har det formatet (74 är landskoden för > Sverige) [2]. Efter att ha lusläst dokumentationen (detaljer på [1]) har > det visat sig att numren är tänkta att motsvara Samtrafikens hållplats-ID, > men att Samtrafiken/Trafiklab för något år sedan ändrade sina hållplats-ID > till formen 7400n (som inte följer UIC-standarden och alltså definitivt > inte är en uic_ref) utan att Trafikverket följde med i det. Jag skulle > därför vilja ändra uic_ref=74n till nat_ref=7400n. Trafiklabs egna > data är _inte_ släppta under OSM-kompatibel licens, men jag har svårt att > tänka mig att transformationen 74 -> 7400 i sig skulle vara katalogskyddad. > > En ändring av uic_ref berör 5126 noder som har highway=bus_stop och/eller > bus=yes och jag skulle därför vilja göra det som en mekanisk redigering, > men vill först kolla att ingen har invändningar, i enlighet med Automated > Edits code of conduct [3]. Det finns även 34 stop_area-relationer som är > taggade med uic_ref men de kommer jag att gå igenom för hand eftersom en > del är järnvägsstationer som rimligtvis både har Samtrafiken-nummer och > UIC-nummer. Av samma anledning kommer jag inte att röra noder (och vägar) > som har någon railway-tagg eller train=yes. > > Det finns också äldre data med busshållplatser (36 noder och 63 > relationer) som är taggade med stop_id=74n. Även dessa skulle kunna > taggas om mekaniskt på liknande vis. > > > Förslag till arbetsgång för mekanisk redigering: > 1. Hämtning av busshållplatser med uic_ref med följande Overpass API-anrop > i JOSM: > > [out:xml][timeout:122]; > area > [boundary=administrative] > ["admin_level"="2"] > ["name"="Sverige"] >-> .a; > > ( > node["uic_ref"][!"railway"]["train"!="yes"](area.a); > ) ; > (._;>;); > out meta; > > > 2. Resultatet sparas som en OSM-fil och redigeras i Notepad++ genom att > ersätta "'uic_ref' v='74" med "'nat_ref' v='7400" och "timestamp=" med > "action='modify' timestamp=". > > 3. Filen öppnas i JOSM igen och laddas upp. > > > Vänliga hälsningar, > Essin > > > [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/ > trafikverket/bussh%C3%A5llplatser > [2] https://wiki.openstreetmap.org/wiki/Key:uic_ref > [3] http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct > ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] Mekanisk redigering: uic_ref på busshållplatser
Hej listan! Jag har jobbat en del med busshållplatserna i Trafikverkets statliga CC0-vägdata, en beskrivning finns på [1]. Jag har bland annat lagt in hållplats-ID, som i Trafikverkets data är ett tal på formen 74n, som uic_ref= eftersom UIC-nummer också har det formatet (74 är landskoden för Sverige) [2]. Efter att ha lusläst dokumentationen (detaljer på [1]) har det visat sig att numren är tänkta att motsvara Samtrafikens hållplats-ID, men att Samtrafiken/Trafiklab för något år sedan ändrade sina hållplats-ID till formen 7400n (som inte följer UIC-standarden och alltså definitivt inte är en uic_ref) utan att Trafikverket följde med i det. Jag skulle därför vilja ändra uic_ref=74n till nat_ref=7400n. Trafiklabs egna data är _inte_ släppta under OSM-kompatibel licens, men jag har svårt att tänka mig att transformationen 74 -> 7400 i sig skulle vara katalogskyddad. En ändring av uic_ref berör 5126 noder som har highway=bus_stop och/eller bus=yes och jag skulle därför vilja göra det som en mekanisk redigering, men vill först kolla att ingen har invändningar, i enlighet med Automated Edits code of conduct [3]. Det finns även 34 stop_area-relationer som är taggade med uic_ref men de kommer jag att gå igenom för hand eftersom en del är järnvägsstationer som rimligtvis både har Samtrafiken-nummer och UIC-nummer. Av samma anledning kommer jag inte att röra noder (och vägar) som har någon railway-tagg eller train=yes. Det finns också äldre data med busshållplatser (36 noder och 63 relationer) som är taggade med stop_id=74n. Även dessa skulle kunna taggas om mekaniskt på liknande vis. Förslag till arbetsgång för mekanisk redigering: 1. Hämtning av busshållplatser med uic_ref med följande Overpass API-anrop i JOSM: [out:xml][timeout:122]; area [boundary=administrative] ["admin_level"="2"] ["name"="Sverige"] -> .a; ( node["uic_ref"][!"railway"]["train"!="yes"](area.a); ) ; (._;>;); out meta; 2. Resultatet sparas som en OSM-fil och redigeras i Notepad++ genom att ersätta "'uic_ref' v='74" med "'nat_ref' v='7400" och "timestamp=" med "action='modify' timestamp=". 3. Filen öppnas i JOSM igen och laddas upp. Vänliga hälsningar, Essin [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/trafikverket/bussh%C3%A5llplatser [2] https://wiki.openstreetmap.org/wiki/Key:uic_ref [3] http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Naturreservat
Nu har jag gått igenom föreskrifterna för de tolv naturreservaten i området där jag har ritat skog i större skala [1]. Åtta av dem förbjöd allt skogsbruk, med lite olika formuleringar. Två reservat (Komossen och Givorna) kunde jag inte hitta föreskrifter för. Två (Hemshyttan och Klackberg) verkar tillåta viss avverkning om det är i enlighet med skötselplanen. Åtminstone de två sista borde väl då strikt taget mappas om. Jag hittade också några andra saker som kan vara relevant för importen. Föreskrifterna för Daladelen av Bredmossen [2] verkar beskriva det som ett reservat i två län (och med två ansvariga myndigheter) snarare än två reservat med samma namn i olika län. På liknande sätt är Hemshyttan [3] ett reservat i tre åtskilda delar snarare än de tre reservat det är mappat som nu. För övrigt har jag inga större invändningar mot det tidigare framförda förslaget att avveckla grupprelationerna för respektive län helt. Innan det görs borde det dock kontrolleras att länsgränserna är ritade så att alla reservat ligger i rätt län. Jag upptäckte till exempel att länsgränsen gick på fel sida om Olkosröjningen [4], eftersom gränsen flyttades här i samma veva som Ekonomiska kartan och därför är lite otydligt ritad. När den kontrollen är gjord kan man använda Overpass och liknande tjänster för att hitta alla naturreservat inom ett län. Vänliga hälsningar Essin [1] http://www.openstreetmap.org/#map=10/60.0851/15.8615 [2] http://www.lansstyrelsen.se/Dalarna/SiteCollectionDocuments/Sv/djur-och-natur/skyddad-natur/Naturreservat/Bredmossen/beslut-skotsel.pdf [3] http://www.lansstyrelsen.se/dalarna/SiteCollectionDocuments/Sv/djur-och-natur/skyddad-natur/Naturreservat/Hemshyttan/beslut-skotsel.pdf [4] http://www.openstreetmap.org/way/43189846 Den 22 maj 2017 23:21 skrev Mattias Dalkvist <matt...@dalkvist.se>: > > > 2017-05-22 21:57 GMT+02:00 Henrik Lundqvist <h.lundqv...@gmail.com>: > >> ... >> Gränserna som ligger som CC0 i VIC-natur på NVV, är de geometrier som >> ligger till grund för besluten så "rättare" gränser finns inte. >> ... >> /Henrik >> > > För utom när de är fel ;) > Hittade ett exempel (undantag?) där två reservat har gemensam gräns efter > en å men de har använt olika kartmaterial att digitalisera från så > gränserna överlappar med 5-10 m. http://i.imgur.com/Asiu6i1.png Den > markerade linjen är den västra gränsen för reservatet österut > > >> >> Den 22 maj 2017 8:47 em skrev "Essin" <user.es...@gmail.com>: >> >>> Jag har på några ställen avsiktligt låtit naturreservatsgränser utgöra >>> gräns mellan landuse=forest (utanför reservatet) och natural=wood, utifrån >>> argumentet att det är reservatsgränsen som definierar vilken skog som >>> brukas och vilken som "bara står där". Jag ska dock erkänna att jag inte >>> har läst exakt vilka skötselföreskrifter som gäller för varje reservat -- >>> skogsbruk förekommer väl i vissa reservat. Sedan jag gjorde detta har >>> dessutom som bekant renderingen strömlinjeformats, och även om man inte ska >>> tagga för renderaren har jag svårt att bli riktigt uppbragt om dessa taggar >>> skulle försvinna -- särskilt om det skulle innebära ytterligare krångel vid >>> uppdateringen. >>> >>> Vänliga hälsningar >>> Essin >>> >>> Den 22 maj 2017 16:14 skrev Mattias Dalkvist <matt...@dalkvist.se>: >>> >>>> >>>> >>>> 2017-05-22 14:55 GMT+02:00 Micke <mia...@hotmail.com>: >>>> >>>>> Jag såg att T-udden i Gävle saknades. Är inte det ett naturreservat? >>>>> Har för mig jag sett sådana skyltar när jag varit där. >>>>> >>>>> >>>>> Jag missade att lägga in den >>>> >>>> >>>>> Jag har manuellt lagt till saker i vissa naturreservat. T.ex. >>>>> snowmobile=no där det gäller i hela reservatet. Hur blir det med dom >>>>> taggarna? >>>>> >>>>> >>>>> Sådan info finns inte med i filerna tyvärr, så man behöver läsa >>>> reglarna för varje enskilt reservat men det kanske vore bra att ha med. >>>> Finns det några taggar för tältning och eldning? För det brukar ju >>>> också vara reglerat. >>>> >>>>> För övrigt, se mina svar nedan i lila färg. >>>>> >>>>> >>>>> >>>>> Mvh >>>>> >>>>> >>>>> Anders Andersson >>>>> >>>>> >>>>> -- >>>>> *Från:* Mattias Dalkvist <matt...@dalkvist.se> >>>>> *Sk
Re: [Talk-se] Vägnamn från NVDB
Jag har använt NVDB för att lösa kartanteckningar, och på det sättet upptäckt en del märkligheter. Detaljer finns nedan, men först en sammanfattning: * Namn på skogsbilvägar håller generellt låg kvalitet och är svåra att verifiera "on the ground", med många texter som inte är namn, namn som inte skyltas och misstänkta felstavningar. * I tättbebyggda områden är kvaliteten generellt bättre, men även här förekommer enstaka felstavningar och gatunamn på stickvägar. * Jag har inte tillräckligt med lokalkännedom för att bedöma hur det ser ut i kommuner som använder vägnamn för landsbygdsadresser, men förhoppningsvis är det som i de tättbebyggda områdena. Om vi ska plocka in vägnamn från NVDB i större skala -- och jag är inte övertygad om att det är en bra idé -- måste en människa (gärna någon med lokalkännedom) göra en rimlighetsbedömning av varje enskilt namn. När det gäller skogsområden är det antagligen inte ens värt att försöka. Sen finns också det mer principiella importdilemmat: en stor förbättring direkt med import, eller en större förbättring på sikt genom att OSM-aktiva kollar upp vägnamn själva, och under tiden hittar en massa andra saker att mappa? Det är förstås en avvägning av hur mycket längre tid det skulle ta, men vi får inte glömma att OSM inte bara är kartan utan också människorna och processen som skapar den. Om vi inte tar det försiktigt från början riskerar vi att hamna i en liknande situation som svenskspråkiga Wikipedia. Där pågår nu ett jätteprojekt https://sv.wikipedia.org/wiki/Wikipediadiskussion:Projekt_alla_platser-st%C3%A4dning med att rensa upp robotskapade geografiartiklar som visade sig vara baserade på databaser och algoritmer av för låg kvalitet. Däremot kan vägnamnen i NVDB vara till stor nytta för att lösa kartanteckningar om felaktiga vägnamn (ofta från MapBox https://www.openstreetmap.org/user/PlaneMad/diary/34758 ) och som stöd för kartläggning i områden där man har lokalkännedom men är lite osäker på detaljerna. == TLDR: Enskilda exempel på konstigheter i NVDB == (länkar till maps.openstreetmap.se, aktivera NVDB-namnlagret till höger): http://maps.openstreetmap.se/#14/60.0983/16.0492 I skogarna utanför Norberg är många vägar namnsatta, men bara vissa av dessa namn är skyltade. De används inte för adresser (i stället används by- eller gårdsnamn), och verkar inte ha fastställts av kommunen. I vissa fält verkar information som inte hör till namnet ha kommit med, t ex "S:a vägen (bidrag 2430 m)" och "Hästevägen Östra". Liknande mönster verkar finnas i många andra skogsområden, med förbehåll för att jag inte vet hur de skyltas där. http://maps.openstreetmap.se/#16/59.6471/17.9384 Vid Arlanda har många vägar namn som snarare verkar vara någon typ av ref=. http://maps.openstreetmap.se/#15/60.3811/16.4870 En annan typ av icke-namn verkar snarare vara operator=, t ex "Ak-vägens VF" (AK-vägens vägförening?) i södra Gästrikland. http://maps.openstreetmap.se/#16/60.3603/16.6024 I samma område möts Högalångvägen och Högalångsvägen. Antagligen är den ena en felstavning, men det är svårt att veta utan att kolla på plats. http://maps.openstreetmap.se/#16/60.1175/16.0032 Utanför Norberg finns Övstjärnsvägen och Öftjärnsvägen på varsin sida om de sjöar som på Ekonomiska kartan heter Stora och Lilla Öfstjärnen. Om de inte skyltas (vilket är troligt) är det omöjligt att veta om två separata vägar verkligen har så liknande namn. http://maps.openstreetmap.se/#17/60.04075/16.07648 Sedan finns också uppenbara felstavningar, till exempel "Hyvalarvägen" i Karbenning som jag är ganska säker på egentligen heter Hyvlarvägen. http://maps.openstreetmap.se/#18/59.98894/15.82644 Inne i samhällen händer det ofta att små stickvägar (oftast highway=service ur OSM:s perspektiv) får samma namn som sin "förälder", t ex Sjövägen och Fogdvägen i Västanfors. OSM-hälsningar Essin (PS: Började skriva detta inlägg innan Andreas postade sina, men de tar upp olika aspekter så jag postar det oförändrat. DS) Den 15 maj 2017 19:15 skrev Andreas Vilén <andreas.vi...@gmail.com>: > För att inte tala om att geometrin på osm och nvdb ofta är helt olika. Hur > ska en import ta hänsyn till när en väg plötsligt byter namn utan att byta > way? > > Fått splitta många vägar och hittat en hel del gc-vägar/uppfarter med > vägnamn alternativt vägar som helt saknas bara under mappning av Mölle och > Arild. > > För mycket kan gå fel. > > /Andreas > > Skickat från min iPhone > > > 15 maj 2017 kl. 14:36 skrev Per-Olof Norén <pero...@gmail.com>: > > > > Jag håller med Tomas här. Det kan i princip bara bli bättre. > > > > Så länge NVDB-sträckan är längre än OSM dito, så ser jag inget problem. > Flera OSM-ways med samma namn. > > > > Det är om OSM-sträckor inte bryts, medan NVDB bryts och byter namn som > man behöver göra tolkning. > > > > m
Re: [Talk-se] Naturreservat
Hej! Bra initiativ! Jag tittade lite på något liknande för några månader sedan men kom inte särskilt långt, det var kanske precis i övergången mellan länsstyrelsernas och Naturvårdsverkets ansvar. Några funderingar: Hur skiljer man på när naturreservat har fått ändrade gränser IRL och när gränserna justerats i OSM? Gränserna har i allmänhet hög noggrannhet men runt länsgränser blir det ibland överlapp eller smala luckor, och där har jag och säkert andra arbetat med att slå ihop gränserna. Går det att programmera något sätt att bara ladda upp nya gränser om de ligger mer än säg en meter från de gamla? En annan fråga är group-relationerna för naturreservat i ett visst län, t ex http://www.openstreetmap.org/relation/303952 (som säkert kunde få ett tydligare namn, t ex "Naturreservat i Dalarnas län"). Om ett naturreservat beskrivs av en multipolygon borde väl bara multipolygonrelationen ingå i group-relationen, inte ingående ways? Jag har försökt fixa det ibland när jag delat upp reservatsgränser för att återanvända dem som kommungränser och liknande men har säkert glömt det i vissa fall. Ett kvarvarande problem i harmoniseringen av gränser är det här området vid norska gränsen: http://www.openstreetmap.org/#map=14/62.1540/12.2638 Ska man anta att reservatsdata har högre precision än CIA (som riksgränsen tydligen kommer från)? Reservatsgränserna verkar stämma bättre med var rågången ligger på Bing-bilderna, men det kan ju vara offset där också. Ett par kartanteckningar som den nya importen skulle kunna fixa: http://www.openstreetmap.org/note/1290 http://www.openstreetmap.org/note/196526 Vänliga hälsningar Essin Den 4 april 2017 14:08 skrev Mattias Dalkvist <matt...@dalkvist.se>: > Jag snubblade över ett nytt naturreservat som inte vi hade med. Efter lite > efterforskande så är det många reservat som inte är med och flera som > ändrats sedan importerna gjordes 2009-2011 (enligt wikin). > > Vidare så har länsstyrelserna överlåtit ansvaret till naturvårdsverket > och naturligtvis så har de inte samma fält och id:n som länsstyrelserna > hade tidigare =/ > > Jag har gjort ett första utkast för omvandling från NVV > till protected_area: https://wiki.openstreetmap. > org/wiki/WikiProject_Sweden/Nature_conservation#Nytt_initiativ_2017 > > > -- > Dalkvist > > ___ > 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
Re: [Talk-se] Busslinjer - 3 changesets i Västerås, vad har jag missat?
ÖPNVkarte verkar inte uppdateras så ofta som de säger nä, men nu verkar den ha uppdaterats delvis åtminstone. Jag får dessutom rätta mig själv när det gäller hur ÖPNVkarte hanterar plattformar: stop_area verkar bara behövas för korrekt hållplatslistning om name= är satt på public_transport=platform. En rendering som ger bra översikt är för övrigt Openmap.lt:s kollektivtrafiklager[1]. Tyvärr verkar det bara renderas om med ungefär två månaders mellanrum, nu senast för ett par dagar sedan. Thunderforests transportlager finns ju också på osm.org,[2] men det kanske du har sett? [1] https://openmap.lt/#l=59.62453,16.58325,10,MT [2] http://www.openstreetmap.org/#map=12/59.6217/16.5698=T Vänliga hälsningar Essin Den 28 januari 2017 09:29 skrev Christoffer Holmstedt < christoffer.holmst...@gmail.com>: > ÖPNVkarte verkar inte fungera för Västerås. Nya tilläggen har inte laddats > över sedan jag ändrade. Däremot insåg jag i veckan att de kartor som > används på Västeråsbussarna laddas direkt från Thunderforest [1]. Där är > allting uppdaterat enligt mina ändringar. > > [1] https://www.thunderforest.com/maps/transport/ > > Den 22 januari 2017 09:17 skrev Christoffer Holmstedt < > christoffer.holmst...@gmail.com>: > >> Perfekt. Tackar för tipset om ÖPNVkarte. Det står att datan ska laddas >> över inom några minuter men får se senare i veckan om det fungerar eller, >> än så länge har mina nya rutter inte laddats in till kartan. Kanske ska se >> över möjligheten att generera öpnvkarte liknande tiles själv lokalt. >> >> -- >> Christoffer Holmstedt >> >> >> Den 21 januari 2017 22:56 skrev Essin <user.es...@gmail.com>: >> >>> Ja det stämmer, ordningen spelar roll både för hållplatserna och >>> sträckningen. Om linjen går i en slinga på vägen från start- till >>> ändhållplats kan samma OSM-objekt till och med förekomma flera gånger i >>> ruttrelationen. En tjänst som använder ordningen på hållplatserna är >>> ÖPNVkarte [1] -- testa att klicka på en hållplats och sen en av linjerna >>> som trafikerar hållplatsen! (Det verkar dessutom som att ÖPNVkarte bara >>> räknar ihop stop_position och platform om de tillhör samma stop_area, en >>> anledning så god som någon att vara noga med stop_area-relationer.) >>> >>> [1] https://öpnvkarte.de/#16.5782;59.6135;12 >>> <https://xn--pnvkarte-m4a.de/#16.5782;59.6135;12> >>> >>> Vänliga hälsningar, Essin >>> >>> Den 21 januari 2017 23:01 skrev Christoffer Holmstedt < >>> christoffer.holmst...@gmail.com>: >>> >>>> Tack för tipsen. Ska gå igenom allt i detalj när jag får tid nästa >>>> gång. Men en snabb fråga angående relationer, ordningen spelar alltså roll? >>>> >>>> I JOSM så råkade jag trycka på "reverse the order of relation members" >>>> en gång men hade för mig att jag korrigerade detta så det såg rätt ut men >>>> antagligen inte. >>>> >>>> -- >>>> Christoffer Holmstedt >>>> >>>> >>>> Den 21 januari 2017 17:16 skrev Essin <user.es...@gmail.com>: >>>> >>>>> Hej! >>>>> >>>>> Vad kul att kartvisningen på bussarna leder till återkoppling och >>>>> förbättring av OSM! Det jag har ritat i Västerås är mest baserat på >>>>> Mapillary, vilket kanske förklarar en del konstiga luckor, till exempel >>>>> vid >>>>> Centralen. >>>>> >>>>> Huvuddragen i det system som används i större delen av Sverige, bland >>>>> annat Västerås, finns dokumenterade på [1]. Jag ska försöka undvika att >>>>> upprepa vad som redan står där, men några ytterligare kommentarer: >>>>> >>>>> name= på public_transport=platform ska i första hand användas för >>>>> hållplatslägesbeteckningar (ofta A, B, C etc, VL skyltar dem vid större >>>>> hållplatser). Jag tänker ibland att det hade varit bättre att fortsätta >>>>> använda local_ref= för det ändamålet för bättre bakåtkompatibilitet, men >>>>> det är lätt att vara efterklok. Hållplatsens namn framgår av >>>>> stop_area-relationens name=, och för bakåtkompatibilitet av >>>>> stop_position-nodernas. (Jag har ofta varit för lat för att skapa >>>>> stop_area-relationer, men det betyder inte att jag ogillar dem.) >>>>> >>>>> ref= på public_transport=platform eller public_transport=stop_area >>>>> syftar på bussbolagens interna hållplatskoder och är antagligen inte så >>>&
Re: [Talk-se] Busslinjer - 3 changesets i Västerås, vad har jag missat?
Ja det stämmer, ordningen spelar roll både för hållplatserna och sträckningen. Om linjen går i en slinga på vägen från start- till ändhållplats kan samma OSM-objekt till och med förekomma flera gånger i ruttrelationen. En tjänst som använder ordningen på hållplatserna är ÖPNVkarte [1] -- testa att klicka på en hållplats och sen en av linjerna som trafikerar hållplatsen! (Det verkar dessutom som att ÖPNVkarte bara räknar ihop stop_position och platform om de tillhör samma stop_area, en anledning så god som någon att vara noga med stop_area-relationer.) [1] https://öpnvkarte.de/#16.5782;59.6135;12 <https://xn--pnvkarte-m4a.de/#16.5782;59.6135;12> Vänliga hälsningar, Essin Den 21 januari 2017 23:01 skrev Christoffer Holmstedt < christoffer.holmst...@gmail.com>: > Tack för tipsen. Ska gå igenom allt i detalj när jag får tid nästa gång. > Men en snabb fråga angående relationer, ordningen spelar alltså roll? > > I JOSM så råkade jag trycka på "reverse the order of relation members" en > gång men hade för mig att jag korrigerade detta så det såg rätt ut men > antagligen inte. > > -- > Christoffer Holmstedt > > > Den 21 januari 2017 17:16 skrev Essin <user.es...@gmail.com>: > >> Hej! >> >> Vad kul att kartvisningen på bussarna leder till återkoppling och >> förbättring av OSM! Det jag har ritat i Västerås är mest baserat på >> Mapillary, vilket kanske förklarar en del konstiga luckor, till exempel vid >> Centralen. >> >> Huvuddragen i det system som används i större delen av Sverige, bland >> annat Västerås, finns dokumenterade på [1]. Jag ska försöka undvika att >> upprepa vad som redan står där, men några ytterligare kommentarer: >> >> name= på public_transport=platform ska i första hand användas för >> hållplatslägesbeteckningar (ofta A, B, C etc, VL skyltar dem vid större >> hållplatser). Jag tänker ibland att det hade varit bättre att fortsätta >> använda local_ref= för det ändamålet för bättre bakåtkompatibilitet, men >> det är lätt att vara efterklok. Hållplatsens namn framgår av >> stop_area-relationens name=, och för bakåtkompatibilitet av >> stop_position-nodernas. (Jag har ofta varit för lat för att skapa >> stop_area-relationer, men det betyder inte att jag ogillar dem.) >> >> ref= på public_transport=platform eller public_transport=stop_area syftar >> på bussbolagens interna hållplatskoder och är antagligen inte så >> högprioriterat. Jag har inte sett att VL skyltar dem överhuvudtaget, men >> det är möjligt att de står i finstilt på hållplatstidtabellerna. Ett bra >> exempel på hur de kan se ut är [2]. >> >> route_ref= behöver bara läggas in på public_transport=platform-objekt >> och är egentligen inte nödvändigt där heller om man kan lägga in >> hållplatsen i rätt ruttrelation direkt. Det skadar inte att lägga in det >> ändå, men är mer ett sätt för mappare att kommunicera med varandra än något >> som renderingar eller andra verktyg använder. >> >> public_transport:version= är en tagg som jag egentligen inte tycker om >> eftersom den infördes av JOSM-programmerarna när de inte lyckades få >> validatorn att skilja på de olika systemen för kollektivtrafikrelationer. >> Jag har motvilligt accepterat den eftersom den underlättar mycket när man >> redigerar kollektivtrafik i JOSM, men den har ingen effekt på annat än >> route-relationer. >> >> [3] hade fått hållplatserna listade baklänges, men det var kanske bara av >> misstag? >> >> >> [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Publi >> c_transport#Hur_skall_vi_tagga_nu.3F >> [2] https://www.openstreetmap.org/relation/2255483 >> [3] https://www.openstreetmap.org/relation/5673052 >> >> Vänliga hälsningar, Essin >> >> >> Den 21 januari 2017 00:28 skrev Christoffer Holmstedt < >> christoffer.holmst...@gmail.com>: >> >>> Hej >>> I Västerås så visar alla bussar en OSM karta om vart bussen är och jag >>> har lagt märke till att busslinjerna inte alltid är kompletta. Nu har jag >>> fixat till busslinje 2 och 4 i Västerås till att börja med. >>> >>> Hur ser ändringarna [1,2,3] ut? Något jag bör fixa till? >>> >>> Sedan undrar jag vad som är praxis när busstopp ska placeras ut, gjorde >>> ett försök med [2]. Finns det någon "best practice" för svenska >>> förhållanden? >>> >>> [1] https://www.openstreetmap.org/changeset/45337608 >>> [2] https://www.openstreetmap.org/changeset/45338360 >>> [3] https://www.openstreetmap.org/changeset/45339920 >>> >>> Med vänlig hälsning >>> -- >>> C
Re: [Talk-se] Busslinjer - 3 changesets i Västerås, vad har jag missat?
Hej! Vad kul att kartvisningen på bussarna leder till återkoppling och förbättring av OSM! Det jag har ritat i Västerås är mest baserat på Mapillary, vilket kanske förklarar en del konstiga luckor, till exempel vid Centralen. Huvuddragen i det system som används i större delen av Sverige, bland annat Västerås, finns dokumenterade på [1]. Jag ska försöka undvika att upprepa vad som redan står där, men några ytterligare kommentarer: name= på public_transport=platform ska i första hand användas för hållplatslägesbeteckningar (ofta A, B, C etc, VL skyltar dem vid större hållplatser). Jag tänker ibland att det hade varit bättre att fortsätta använda local_ref= för det ändamålet för bättre bakåtkompatibilitet, men det är lätt att vara efterklok. Hållplatsens namn framgår av stop_area-relationens name=, och för bakåtkompatibilitet av stop_position-nodernas. (Jag har ofta varit för lat för att skapa stop_area-relationer, men det betyder inte att jag ogillar dem.) ref= på public_transport=platform eller public_transport=stop_area syftar på bussbolagens interna hållplatskoder och är antagligen inte så högprioriterat. Jag har inte sett att VL skyltar dem överhuvudtaget, men det är möjligt att de står i finstilt på hållplatstidtabellerna. Ett bra exempel på hur de kan se ut är [2]. route_ref= behöver bara läggas in på public_transport=platform-objekt och är egentligen inte nödvändigt där heller om man kan lägga in hållplatsen i rätt ruttrelation direkt. Det skadar inte att lägga in det ändå, men är mer ett sätt för mappare att kommunicera med varandra än något som renderingar eller andra verktyg använder. public_transport:version= är en tagg som jag egentligen inte tycker om eftersom den infördes av JOSM-programmerarna när de inte lyckades få validatorn att skilja på de olika systemen för kollektivtrafikrelationer. Jag har motvilligt accepterat den eftersom den underlättar mycket när man redigerar kollektivtrafik i JOSM, men den har ingen effekt på annat än route-relationer. [3] hade fått hållplatserna listade baklänges, men det var kanske bara av misstag? [1] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Public_transport#Hur_skall_vi_tagga_nu.3F [2] https://www.openstreetmap.org/relation/2255483 [3] https://www.openstreetmap.org/relation/5673052 Vänliga hälsningar, Essin Den 21 januari 2017 00:28 skrev Christoffer Holmstedt < christoffer.holmst...@gmail.com>: > Hej > I Västerås så visar alla bussar en OSM karta om vart bussen är och jag har > lagt märke till att busslinjerna inte alltid är kompletta. Nu har jag fixat > till busslinje 2 och 4 i Västerås till att börja med. > > Hur ser ändringarna [1,2,3] ut? Något jag bör fixa till? > > Sedan undrar jag vad som är praxis när busstopp ska placeras ut, gjorde > ett försök med [2]. Finns det någon "best practice" för svenska > förhållanden? > > [1] https://www.openstreetmap.org/changeset/45337608 > [2] https://www.openstreetmap.org/changeset/45338360 > [3] https://www.openstreetmap.org/changeset/45339920 > > Med vänlig hälsning > -- > Christoffer Holmstedt > > ___ > 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
Re: [Talk-se] Mälaren
Jag kapade bort bitarna som korsade vattenytan, men datorn höll på att krascha när jag körde validatorn, så jag håller med om att multipolygonen är för stor för sitt eget bästa... Frågan är vad man ska göra åt det. //Essin Den 11 augusti 2016 14:52 skrev <t...@lysator.liu.se>: > Är Mälaren riktigt frisk för ögonblicket? Nod 36133314 ingår i fyra olika > sträckor (402495884, 402495885, 407814287, 16360970) som alla är med i > outer-rollen för relation 1433877, och det känns inte riktigt rätt. Jag > vågar inte ge mig in och redigera sådana där hisklo-polygoner själv... > > > ___ > 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
Re: [Talk-se] Edsviken och svenska kusten
Jag misstänker att Tomas har rätt. Numera är natural=bay[1] (som nod, area eller multipolygon) ett bra sätt att tagga vikar, men det var kanske inte så etablerat när Edsviken mappades från början. MichaelCollinson[2] mappade ursprungligen Edsviken med note=really this is coastline, but Mapnik does not have it men tog sedan bort det själv. Om inte han följer den här listan kanske Jan kan kontakta honom via OSM-meddelandesystemet för att höra vad han menade? Ett liknande fall är Ångermanälvens mynningsvik, där brackvattnet egentligen börjar redan vid Hammarsbron[3]. Strandlinjen är dock mappad som riverbank ända ner till Höga Kusten-bron, och det stämmer kanske bättre med vad som uppfattas som en del av älven lokalt. //Essin [1] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbay [2] http://www.openstreetmap.org/user/MichaelCollinson [3] http://www.openstreetmap.org/way/75263747 Den 2 augusti 2016 00:27 skrev Tomas Marklund <tomasmarklun...@gmail.com>: > Nu kommer jag här snett från sidan utan nån egentlig kunskap i ämnet, utan > har bara en gissning. En orsak jag kan tänka mig är för att på ett enkelt > sätt kunna ge en samlad vattenmassa (i det här fallet Edsviken) ett namn > som både är sökbart och renderas på kartan. Vilka andra bättre sätt finns > det att åstadkomma samma sak utan att låta coastline:en hoppa över ett > stycke kustlinje? > > Nyfiken fråga: Vad är ett OSMOSE-larm och hur funkar sådana? Verkar > användbart. > > /Tomas > > Den 31 juli 2016 11:05 skrev Jan Johansson <j...@wenf.org>: > >> Hej! >> >> Utifrån ett OSMOSE-larm tänkte jag ansluta Igelbäcken[1] till >> havet dock så undrar jag om inte Edsviken[2] borde vara en del av >> den svenska kusten som idag slutar i vikens mynning i höjd med >> [3]. >> >> Jag har tittat runt på en del andra vikar som alla verkar vara en >> del av kusten, hur vet man ifall en vik skall vara med eller >> inte? >> >> Vänligen, >> Jan J >> >> [1] http://www.openstreetmap.org/way/5359587 >> [2] http://www.openstreetmap.org/way/125625989 >> [3] http://www.openstreetmap.org/way/98330096 >> >> >> ___ >> 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 > > ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Stockholms läns regionala cykelstråk
Hej! Dessutom vill jag ta bort Åkersbergastråket ifrån E18, där det är lagt > idag. Även om det har state=proposed så är det fel. Politikernas > funderingar handlar om att bygga en helt ny snabbcykelväg som förvisso > delvis går längs med E18 men aldrig på den. Dessutom handlar det > fortfarande mer om drömmar än några konkreta planer och sträckningen är > långt ifrån fastlagd. Jag tycker det är vilseledande att rita ut föreslaget > cykelstråk på motorvägen. > > -- > Björn Det finns flera kartanteckningar som visar att state=proposed som det används nu är förvirrande för en del användare: http://www.openstreetmap.org/note/358395 http://www.openstreetmap.org/note/492494 och http://www.openstreetmap.org/note/354206 . Är det tänkt att state=proposed ska användas för vägar där cykeltrafik kan vara förbjuden eller annars olämplig, där den fysiska cykelvägen alltså ännu inte existerar, eller bara för vägar som redan är lämpliga för cykling men inte ännu ingår i ett stråk? Hur gick diskussionerna när taggen skapades? Det står inte i teckenförklaringen på http://wiki.openstreetmap.org/wiki/OpenCycleMap vad streckade linjer betyder, och den sidan är inte länkad direkt från cykellagret. http://wiki.openstreetmap.org/wiki/Cycle_routes nämner "Routes are sometimes not official routes pending some negotiation or development -- the opencyclemap rendering shows these routes dotted." där "development" kanske skulle kunna tolkas som "bygge av en cykelväg". Vänliga hälsningar Essin ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
