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 <pang...@riseup.net>: > 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 <pang...@riseup.net> 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 vi tappar kopplingen till tex >> wikidata (WD). Dock går det ju att lägga till alla naturreservat i WD med >> ett NV namn id som man kan slå upp på i stället för ett Qid från en OSM >> etikett. WD är mycket lättare att uppdatera eftersom datan förändras än OSM >> objekt som inte meningsfullt kan observeras på marken eftersom dem >> definieras av människor genom en rättsprocess och gränserna märks sällan ut >> ordentligt tex vid vattenskyddsområden. >> >> Några andra nackdelar? >> >> Detta frigör kraft till annat, tex mera kärlek till vandringsleder som >> helt än inte finns i ett auktoritativt statligt dataset. Vandringsleder är >> också synliga via skylter, m.m. och mera komplexa än Naturreservat pga >> etapper, länk till externa webbsidor och kartor. Detta data skulle iofs >> lika väl kunna sparas i Wikidata också och dras in på kartan. I dagsläget >> finns redan vandringsleder på WD, men många tex på Kungsleden >> https://www.wikidata.org/wiki/Q59780 saknar etapper. >> >> Mvh >> pangoSE >> >> ------------------------------ >> *From:* Tobias Knerr <o...@tobias-knerr.de> >> *Sent:* March 19, 2020 7:44:34 PM GMT+01:00 >> *To:* t...@openstreetmap.org >> *Subject:* Re: [OSM-talk] OSM is not the place for dissemination of >> authoritative data sets >> >> On 19.03.20 17:54, Jóhannes Birgir Jensson wrote: >>> >>> So - why are authoritative data sets an unwelcome addition? >> >> >> At its core, OSM is a platform for collaboratively editing geodata. So >> the following would be strong reasons not to import a dataset: >> >> - other mappers should not edit it (because the dataset is the official >> source and changing it would just make it wrong) >> - other mappers cannot meaningfully edit it (because we cannot see the >> object in the real world and don't have access to useful sources). >> >> The way you describe it, collaborative editing doesn't seem to be a net >> benefit to your scenario, and in fact makes it harder to sync updates >> with the authoritative source. >> >> So as a thought experiment: Why not just convert your dataset to the OSM >> format to make it compatible with the OSM ecosystem, but skip the import >> into the main OSM database? >> >> In practice, I guess part of the answer for that is discoverability: Who >> wants to hunt down datasets scattered across various servers and >> portals? So it's tempting to put it all into a single big database. And >> I guess that's ok as long as it doesn't get in the way of the main >> purpose of that database too much – which is collaborative editing, not >> data distribution. But surely, with a decent implementation of >> compatible data layers tracked in some central repository, authoritative >> data could be used *with* OSM without being *in* OSM. >> >> Tobias >> ------------------------------ >> talk mailing >> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk >> >> _______________________________________________ >> Talk-se mailing list >> Talk-se@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-se >> > > > -- > John Bäckstrand > > _______________________________________________ > Talk-se mailing > listTalk-se@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-se > > > _______________________________________________ > Talk-se mailing > listTalk-se@openstreetmap.orghttps://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
