[Talk-se] Apropå svenska naturreservat i OSM
pangoSE
pangose at riseup.net
Fri Mar 27 11:20:28 UTC 2020
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 <http://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 <pangose at riseup.net
>> <mailto:pangose at 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 <osm at tobias-knerr.de
>> <mailto:osm at tobias-knerr.de>>
>> *Sent:* March 19, 2020 7:44:34 PM GMT+01:00
>> *To:* talk at openstreetmap.org <mailto:talk at 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 list
>> talk at openstreetmap.org <mailto:talk at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk
>>
>> _______________________________________________
>> Talk-se mailing list
>> Talk-se at openstreetmap.org <mailto:Talk-se at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
>>
>>
>> --
>> John Bäckstrand
>>
>> _______________________________________________
>> Talk-se mailing list
>> Talk-se at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>
> _______________________________________________
> Talk-se mailing list
> Talk-se at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-se/attachments/20200327/b6417c13/attachment-0001.htm>
More information about the Talk-se
mailing list