Re: [Talk-se] Hur justera höjdprofil för vandringsled - rutt med "oordnade" delar

[Daniel Westergren]

En annan tanke angående vandringsleder. Det nämndes höjdkurvor tidigare.
Höjddata från Waymarked Trails ska man ta med en stor nypa salt. Deras
algoritm och den DEM  (Digital Elevation Model) som de använder gör att
antalet höjdmeter kraftigt underskattas.

Läs t.ex. https://www.openstreetmap.org/user/Robhubi/diary/392875

Vad gäller Huddingeleden har jag för övrigt gått igenom del 1-4, sorterat
vägarna i relationerna, fixat glapp och laddat upp.

Webbsidan som hänvisas till för Huddingeleden är en Facebooksida. Jag tror
att https://naturkartan.se/sv/huddinge/huddingeleden-80-km är mer officiell
och beskriver leden bättre.

@Mikael Branting: De sju delar som huvudrelationen nu är uppdelad, är de
samma som sju etapper? Vad jag förstår innehåller Huddingeleden 11 etapper.
Om de 7 underrelationerna bara är en manuell uppdelning av en längre
relation så bör de ju sammanfogas i en relation istället för att vara
artificiella delar. Eller att man som sagt delar in i en officiell
etappindelning.

MVH /Daniel

Den sön 10 maj 2020 kl 14:16 skrev Daniel Westergren :

> Tjenare,
>
> Jag gick just åter med i Talk-se, men såg i arkivet en annan tråd nyligen
> som jag ville svara på, om vandringsleder.
>
> Huddingeleden är nu taggad som lwn, men bör i högsta grad vara rwn, alltså
> regionalt vandringsnätverk. Den må bara sträcka sig inom Huddinge kommun,
> men är av betydelse utanför kommunens gränser och av betydande längd. Jag
> kan fixa det lite snabbt.
>
> Och en fråga om superrelationer och vandringsleder. Om man gör en
> huvudrelation för hela vandringsleden och en underrelation för
> huvudsträckningen och en annan för avstickare, eller en underrelation för
> varje etapp, bör då huvudrelationen taggas som superrelation (alltså
> type=route_master)? Dvs. en huvudrelation är alltid att betrakta som
> superrelation?
>
> Jag behöver nog i så fall korrigera t.ex. Utvandrarleden, Sigfridsleden,
> Torsåsleden mm.
>
> MVH /Daniel W
>
>
> Hej!
>
> En gång till, men nu till hela mailinglist:
>
> En stig är två gånger med i relationen: 
> https://www.openstreetmap.org/way/147671979
> Dessutom finns husnummer 109 på Myrstuguvägen med i relationen (som
> förmodligen inte har något att göra med vandringsleden).
>
> "Superrelationen" är av fel typ, ska vara "type=route_master" (i st. f.
> "type=route") och "route=hiking" ska vara "route_master=hiking".
>
> Bästa metoden att justera ordningen på en relations medlemmar är att
> använda JOSM, där det är bara ett musklick.
>
> Om du vill kann jag försöka fix problemet -- säg bara till.
>
> Hartwig
>
>
> On 24.04.20 19:52, M Branting wrote:
> >>* Hej
> *>>* Jag har avslutat uppläggningen av vandringsleden Huddingeleden (en
> *>* superrelation) söder om Stockholm, men vill nu få höjdprofilen i
> *>* waymarked trails att fungera, och tänkte ta delsträcka efter
> *>* delsträcka. Det tycks vara besvärligare än vad jag trodde. Jag har
> *>* ändrat riktning för alla stigar och vägar i delsträcka 1 men problemen
> *>* kvarstår. Det krävs tydligen att man även ändrar ordningen på delarna
> *>* som leden skapats med.
> *>>* Vilken är den bästa metoden att justera ordningen på en leds delar,
> *>* utan att behöva ”lägga upp alla delar manuellt” en gång till?
> *>>* Länk till delsträcka 1
> *>* https://hiking.waymarkedtrails.org/#route?id=5973832 
> 
> *>>* Mikael Branting
> *>>* Skickades från E-post  >
> *>* för Windows 10
> *>>>* ___
> *>* Talk-se mailing list
> *>* Talk-se at 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] Hur justera höjdprofil för vandringsled - rutt med "oordnade" delar

[Daniel Westergren]

Tjenare,

Jag gick just åter med i Talk-se, men såg i arkivet en annan tråd nyligen
som jag ville svara på, om vandringsleder.

Huddingeleden är nu taggad som lwn, men bör i högsta grad vara rwn, alltså
regionalt vandringsnätverk. Den må bara sträcka sig inom Huddinge kommun,
men är av betydelse utanför kommunens gränser och av betydande längd. Jag
kan fixa det lite snabbt.

Och en fråga om superrelationer och vandringsleder. Om man gör en
huvudrelation för hela vandringsleden och en underrelation för
huvudsträckningen och en annan för avstickare, eller en underrelation för
varje etapp, bör då huvudrelationen taggas som superrelation (alltså
type=route_master)? Dvs. en huvudrelation är alltid att betrakta som
superrelation?

Jag behöver nog i så fall korrigera t.ex. Utvandrarleden, Sigfridsleden,
Torsåsleden mm.

MVH /Daniel W


Hej!

En gång till, men nu till hela mailinglist:

En stig är två gånger med i relationen:
https://www.openstreetmap.org/way/147671979
Dessutom finns husnummer 109 på Myrstuguvägen med i relationen (som
förmodligen inte har något att göra med vandringsleden).

"Superrelationen" är av fel typ, ska vara "type=route_master" (i st. f.
"type=route") och "route=hiking" ska vara "route_master=hiking".

Bästa metoden att justera ordningen på en relations medlemmar är att
använda JOSM, där det är bara ett musklick.

Om du vill kann jag försöka fix problemet -- säg bara till.

Hartwig


On 24.04.20 19:52, M Branting wrote:
>>* Hej
*>>* Jag har avslutat uppläggningen av vandringsleden Huddingeleden (en
*>* superrelation) söder om Stockholm, men vill nu få höjdprofilen i
*>* waymarked trails att fungera, och tänkte ta delsträcka efter
*>* delsträcka. Det tycks vara besvärligare än vad jag trodde. Jag har
*>* ändrat riktning för alla stigar och vägar i delsträcka 1 men problemen
*>* kvarstår. Det krävs tydligen att man även ändrar ordningen på delarna
*>* som leden skapats med.
*>>* Vilken är den bästa metoden att justera ordningen på en leds delar,
*>* utan att behöva ”lägga upp alla delar manuellt” en gång till?
*>>* Länk till delsträcka 1
*>* https://hiking.waymarkedtrails.org/#route?id=5973832

*>>* Mikael Branting
*>>* Skickades från E-post
>
*>* för Windows 10
*>>>* ___
*>* Talk-se mailing list
*>* Talk-se at 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] Apropå svenska naturreservat i OSM

[Essin]

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 med Tobias?
>>
>> Finns det konsensus för att radera våra undermåliga naturreservat och i
>> stället skapa et centralt ställe där det beskrivs hur datat från NV kan
>> läggas till en karta?
>>
>> Problemet med detta som jag ser det är att 

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[Essin]

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äller du dig till place= på områden?
>

Place-taggar på polygoner testades i Sverige för ett antal år sen men blev
inte etablerat. Jag var inte inblandad i diskussionerna runt det och kommer
inte ihåg varför det ansågs som misslyckat, någon som var med då kanske kan
fylla i? Personligen är jag tveksam eftersom det finns flera möjliga sätt
att avgränsa