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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
*Sent:* March 19, 2020 7:44:34 PM GMT+01:00
*To:* [email protected] <mailto:[email protected]>
*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
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
Talk-se mailing list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-se
--
John Bäckstrand
_______________________________________________
Talk-se mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-se
_______________________________________________
Talk-se mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-se
_______________________________________________
Talk-se mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-se
