[Talk-se] Ang. place=sea och maskinpolygoner
Hej Vi har massor med polygoner och sträckor tex för kattegat https://www.openstreetmap.org/way/648354482 men inga av dem syns på Carto i dagsläget. Jag hittade nyligen: https://github.com/gravitystorm/openstreetmap-carto/issues/2278#issuecomment-473656155 där det framgår varför. Vet nån här hur man skapar dessa polygoner utifrån kustlinjer i PostGIS så som föreslås? Är det tänkt så att vi matar in koordinater/nod-id för start/stop längs en kustlinje i postgis som gör en polygon åt oss? I fallet kattegat föreställer jag mig att minst 6 koordinater/noder behövs. 1 skagen (norrjyllands nordöstligaste spets) 2 sletterhage (mols, under "näsan" på jylland) här emellan ritar postgis ett steck 3 sjællands odde (norrsjällands nordvästligaste punkt) 4 gilleleje (norrsjällands nordligaste punkt) här emellan ritar postgis ett steck 5 vid kullens västra fyr (nordväst om helsingborg) 6 knarrviks huvud (väster om kungälv) Liknade för atlanterhavet skulle två noder/koord på antarktis, 2 på amerika, 2 på grönland, 1 vid norge och en på sydspetsen av afrika. Vad tänker ni? Hur gör vi om strecket som postgis ritar passerar igenom ett objekt som tex en ö? Spelar det någon roll? Allt detta görs för att undvika enorma manuella polygoner och arbiträra etikettplaceringar om jag förstått rätt. Mvh pangoSE / Egil ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej på er Här finns en annan intressant importstrategi med tasking manager-filer som output. https://www.openstreetmap.org/user/itsamap!/diary/152909 Kanske är detta bästa vägen även för denna import? (det möjliggör att ha denna data som underlag under lång tid framöver för folk som vill kartlägga landuse genom att utgå från NMD som grund om dem tycker det är lättare.) Se "merge workflow" som beskrivs här: https://wiki.openstreetmap.org/wiki/Import/Catalogue/US/BingBuildings#Data_Merge_Workflow Mvh On 2019-05-01 00:36, Grigory Rechistov via Talk-se wrote: > Hej! Kolla imports-listan där jag beskriver min nuvarande approach med > masker: > https://lists.openstreetmap.org/pipermail/imports/2019-April/005990.html > Återkommer till talk-se-listan med fler filer, detaljer för de som > vill pröva med nya vektor efter helgen. Trevlig helg! > > > Med vänliga hälsningar, > Grigory Rechistov > With best regards, > Grigory Rechistov > > > ___ > 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] Naturvårdsverkets nya Nationella MarktäckeData
Hej On 2019-04-24 15:00, Mattias Dalkvist wrote: kollade lite kring Vingåker och det ser ur att vara ganska stor variation på data kvalitén. det ser okej ut på håll men när man zoomar in så är det massa små saker som ingen karterare skulle göra. tex way 685231007. Enig den var illa. om Vingåker är representativt för importen så skulle jag rösta på att vänta tills skripten kan göras bättre. Jag tror inte skriptarna kan göras så mycket bättre med tanke på hur låg kvalitet det är på grundmaterialet (10x10 cm) och en kass? AI på det. Jag ogillar att det är skog med en massa vita hål i. Det bliver nog en ful och kantig karta om detta importeras i större skala. Min gissning är att den här kartan bara används för statistiska ändamål hos NV tex för att rapportera om förskogning av åkermark, m.m. och inte för estetiska/praktiska ändamål som en karta att navigera efter. Jag skulle hellre importera LMs vektorkartdata (om den nånsin släpps fri) som ligger till grund för hitta.se - den verkar mycket bättre och snyggare. Om så händer kan vi ju kanske massradera det här skräpet först. Allra bäst skulle kanske vara högupplösta flygfoton över hela Sverige och låta det ta den tid det tar som dem fick i DK när Fugro släppte sina fria. :p Mvh Egil On Fri, 19 Apr 2019, 01:02 Grigory Rechistov via Talk-se mailto:talk-se@openstreetmap.org> wrote: Hej Joel! >Antagligen endast på grund av att skogstypen ändras. >Frågan är om algoritmen fungerar bättre om man behandlar all skog lika? Ja, det verkar vara den mest sannolika anledningen. Din bild bevisar det också. De filer som ligger nu uppladdade hade jag filtrerat för att slänga bort alla vägar kortare än 24 noder. Den processen hade säkert raderat mindre områden med skogstyp som skilde sig från intilliggande större skogsområden. Jag kan generera nya vektorfiler på nytt där alla skogstyper blir sammanslagna. Men då behöver jag starta från början, dvs från det ursprungliga rastern, och det kommer att ta en stund. Några nya resultat ska bli tillgängliga efter helgen, hoppas jag. Glad påsk! Среда, 17 апреля 2019, 22:58 +03:00 от j...@torsson.se <mailto:j...@torsson.se>: Hej! Tack för ditt engagemang Grigory! Jag provade att ladda ned Hjo kommun i version 2. Det som slog mig ganska direkt var att det skapas hål i skogsområden, samt att skogsområden utelämnas. Antagligen endast på grund av att skogstypen ändras. Frågan är om algoritmen fungerar bättre om man behandlar all skog lika? Om valet står mellan att få in ett så korrekt skogsområde som möjligt och att få in skogstypen (barrskog/lövskog m.m.) så tycker jag att det är bättre att få in ett så korrekt område som möjligt. Se skogsområdet i mitten här: http://www.torsson.se/joel/osmpics/nmd2018-osm-hjo.png Mvh Joel Grafström 2019-04-17 11:29 skrev Grigory Rechistov via Talk-se: Hej Karl-Johan! Tack för ditt intresse! >Jag har laddat ner filerna och för Linköpings kommun och det är ganska mycket konflikter Hur stort antal konflikter du ser? Handlar det om hundratals eller tusentals problem? Linköpings kommun är redan väl kartlagd: http://paul7.net/i/2019.04.17/1b0e/linkf6pings-kommun.jpg . Du kanske vill fokusera endast på de södra och söder-östliga delarna som nu är "vita". I så fall radera manuellt alla nya (eller bara konflikterande) objekt utanför dessa delområden. >Ska jag anteckna mig på "Status_per_subarea <https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea>" för de kommuner jag tänker mig ge mig på eller bara på den som jag just nu jobbar på? Det är väl okej att reservera två eller tre kommuner för sig, tror jag. Det är också intressant att se på vad som händer med importdatat vid intilliggande områdens gränser — denna fråga har jag inte tänkt igenom. Kommunerna är ju inte skilda öar i havet... Jag har också släppt v2-versionen på datat. Det är mer filtrerad, så kanske passar det bättre för större subareor. Среда, 17 апреля 2019, 8:24 +03:00 от Karl-Johan Karlsson mailto:karl.johan.karls...@gmail.com>>: Hej! Jag tänkte ta mig an Linköpings och kanske några omkringliggande kommuner. Jag har laddat ner filerna och för Linköpings kommun och det är ganska mycket konflikter så ... det kanske är bättre att börja med någon mindre för att "öva" på. Hur gör vi för att undvika dubbelarbete? Ska jag anteckna mig på https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/S
[Talk-se] Fjällstugor
Hej Jag tänkte gå igenom fjällstugorna och märka upp dem med lämpliga taggar och hemsidor m.m. Jag såg att många ligger dubbelt pga. en norsk import och verkar feltaggade som tourism=cabin (finns ej i wikin) i stället för tex tourism=alpine_hut. Jag tänker massändra till tourism=alpine_hut och ta bort alla förekomster av =cabin om inga har invändingar. Mvh Egil overpass: tourism=alpine_hut or amenity=shelter or tourism=hostel or tourism=cabin in "norrbottens län" ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Changeset 69441387
Tack för heads up här. Jag har börjat jobba med datan för Härnösands kommun. Det finns så många konflikter att jag vald att inte importera delar av den (landuse=forest) som redan täcker 95% av all skog i kommunen och bara ta scrub och annat med. Återstår att se om detta resterande går lätt att importera On 2019-04-22 09:57, Snusmumriken wrote: > Hej listan > > Jag tog och reverterade importen som gjordes i morse > https://www.openstreetmap.org/changeset/69441387 > > Orsaken var de omfattande konflikter som uppstod med befintlig data. > > > ___ > 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] Naturvårdsverkets nya Nationella MarktäckeData
Hej igen Bra jobbat Grigory! Ang. större import kontinuerligt se tex: https://forum.openstreetmap.org/viewtopic.php?id=65563 Jag har lagt in en del skog runt Härnösand och datat som nu är tillgängligt väsentligt bättre än vad jag lagt in. Jag undrar om vi likt bussstoppen i Norge har mera glädje på sikt av att överskriva redan inlagd skog i stället för att lämna några tusen rektangulära hål som manuellt måste fyllas? Vad tycker ni? När det gäller skog så är det min förhoppning att denna data är så bra att vi inte kommer behöva ändra så mkt på den framöver (förhoppningsvis). NKA föreslog i tråden ovan att vid import av samma data överskrivs allt som inte ändrats i OSM mellan importerna. Det tycker jag låter som en bra strategi om den är gångbar i vårt fall givet alla konverteringar och filtreringar hit och dit. Ang. redigeringsergonomi: Visst är det skönt när alla ytor är angränsande multipolygoner som är lagom stora och delar vägar med varann, men det är nog inte realistiskt att kartlägga hela Sveriges yta så tyvärr. Alternativet med NMD kommer visst att betyda stor skillnad både på Carto och i vektorvy, men om vi lär nykomlingar att koncentrera sig på annat än markytor i början så kommer det nog att gå alldeles bra. Det finns mycket att göra som inte är skog på kartan till att vi alla kan ha händerna fulla ändå. On 2019-04-11 19:33, Grigory Rechistov via Talk-se wrote: > Hej Erik! > De är rimliga farhågor. > > >10GB för Kiruna är rätt stor mängd data > Det är faktiskt 1,7 GB, jag mindes fel. Tänk på att a) det är rå > vektordata, jag ämnar gallra det ordentligt som beskrevs tidigare, b) > Kirunaområdet är undantaget, 82% av de 291 kommuner har GML-filer > mindre än 250 MB (också rådata som ska gallras). > > >Jobbet med att jämka det som finns och det som läggs in kommer behöva > göras igen när låt oss säga NMD 2025 kommer. > Låt oss importera först den data som kom år 2018 :-) Men jag har redan > en plan för den \ (•◡•) / Fråga mig om du är nyfiken (annars brukar > jag skriva mejl till denna tråd som är orimligt långa). Kortfattat: > att hitta och beskriva skillnaden mellan två rasterbilder är i princip > enklare än mellan två vektorbildar. > > >Importera påverkar också redigerar ergonomin rätt mycket. > Mitt syfte är att lägga till ny data som inte överstiger den > datavolymen som redan finns i databasen. Det vill säga, upp till 100 > MB ny vektor objekt för varje 100 MB som redan finns där. > Datauppladdningen ska ske genom JOSM-redigeraren. Om man inte kan > hantera ny lagret i JOSM blir det klart kännetecken att dess volym är > för stor. Vi får se i alla fall om det är genomförbart eller inte. > > Jag vill också lägga till att att ha skogar synliga i OSM-kartan är > viktig för mig som kartanvändare. Olika företag (t ex hitta.se) har > rätt bra friluftskartor över Sverige. Jag vill att vi också har ett > öppen alternativ till det för Sverige och andra länder. > > > Четверг, 11 апреля 2019, 11:58 +03:00 от Erik Johansson > : > > Detta var min poäng med att inte importera för mycket terräng > typer och för små polygoner, 10GB för Kiruna är rätt stor mängd > data och kommer höja ribban rejält för att handskas med Sveriges > osm data. > > Jobbet med att jämka det som finns och det som läggs in kommer > behöva göras igen när låt oss säga NMD 2025 kommer. Denna import > kommer göra det jobbet svårare. > > Importera påverkar också redigerar ergonomin rätt mycket. Är jag > ensam om att tycka detta? > > > Den tors 11 apr. 2019 10:44Grigory Rechistov via Talk-se > > > skrev: > > Hej Christian, tack! > > >Det kan vara svårt att få många att sätta upp hela kedjan av > script och program som behövs. > Jo, det är sant. Jag kunde inte föreställa mig att jag skulle > behöva så flera verktyg och skriva så många nya skript innan > jag hade börjat arbeta med datat. Det blir väl jobbigt för > någon annan att upprepa efter mina steg även om jag ordentligt > dokumenterar dem (och det gör jag inte…) > > >men frågan är ifall det inte vore lättast att en person kör > igenom scripten för alla kommuner? > Det är mitt syfte. Jag ämnar förberedda nästan färdiga > OSM-filer för samtliga kommuner själv. Sedan hjälper andra att > rätta till återstående varningar och att ladda upp datat till > OSM-databasen som sista steget. Hittills orkar min hemdator > med beräkningsbelastningen, men ifall den inte räcker till får > jag tillgång till några få starkare datorer för att klara sig. > > >Jag tar gärna på mig min hemkommun och ett par andra. > Tack! Om allt går bra får jag hem färdigställa > OSM-Sverigekarta inför min sommarsemester. > > Sålänge konverterade jag GeoTIFF:erna till GML:erna. Här är > länken: > https://drive.google.com/open?id=1aVqgPf18rlEwuoAzAWHo5EgvPb5CNAb3 (4 > GB) >
Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
On 2019-04-07 17:47, Grigory Rechistov via Talk-se wrote: > Hej, > > >En särskild användare bör skapas. > Sant, det är enligt guidelinjerna: > https://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account > > >Hur vi ska identifiera områden vet jag ej. > > ska man identifiera områden manuellt för import, eller kan man göra > en enda > > import för hela landet? Någon som vet hur det går till? > > Min känsla är att försöka importera hela landet meddetsamma vore > opraktiskt: jättestora filer, många svåra konflikter med befintliga > data att lösa samtidigt osv. Länen är också för stora. Det finns 290 > kommuner; kanske en kommun i taget vore ett lagom stort ärende för att > klara utan överdrivna ansträngningar? Låter som en bra ide att bruta upp importen i mindre bitar. Det ger oss också möjlighet att förbättra algoritmen om så behövs undervägs. ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej Grigory Tusen tack för ditt utförliga svar. Jag är inte längre lika skeptisk längre. Vi får lita på att dem på naturvårdsverket har koll på sina infraröda bilder och AI. Informationen om hur detta data tagits fram skulle jag vilja anges tydligt i planen/var det nu passar bäst. Kul att du lyckats lista ut och jobba runt gdal_sieve.py's konstigheter :) Mvh On 2019-04-07 16:33, Grigory Rechistov via Talk-se wrote: > Hej, > > >dem verkar vara skapad via AI och flygfoto/sattelitbilder . > I ett PDF-dokument som kom med marktäckedatan (den ZIP-arkiv som går > att ladda ner) nämndes det att man också hade tillgång till infraröda > bilder. De bör hjälpa till att skilja på skogstyper i tillägg till de > vanliga bilderna i synliga spektrumet. > > > och inte särskilt pålitliga > En AI är bara ett program, och vi använder redan flertal program för > att bearbeta, validera, skicka och rendera OSM. Varför litar man på > ena program med inte på det andra? Varför lita på den ursprungliga > TIFF-bilden alls? > > Antingen testar man datan/programmet själv (att de motsvarar > verkligheten) eller litar man på dem som skrev programmet och > bearbetade datan. Att testa marktäcktedatan själv borde vara jobbigare > än någon orkar klara i livet. Fast det lär vara skoj att besöka ett > fåtal skogsområden i ens närhet och kolla att skogstypen stämmer med > kartan. > > Om vi har frågor eller misstänker gällande metoder eller noggrannhet > på NMD:n ska vi anlita dess upphovsmän. Tidigare skrev Bernt Rane i > denna tråd att »Om det finns frågor kring datat så kan ni kontakta > camilla.jons...@metria.se > <https://e.mail.ru/compose/?mailto=mailto%3acamilla.jons...@metria.se> > som kan svara direkt eller bolla vidare, hon jobbar på > Naturvårdsverkets uppdrag med just marktäckedatat.« > > >Skulle du kunna göra ett exempel där alla skogstyper slås ihop > > Hittills lyckades jag lösa problemet med `gdal_sieve.py` och nu har en > ny raster TIFF-fil som 1) täcker hela landet, 2) har allt krafs > borttaget, 3) har "DN"-värden sammanslagna som tidigare bestämt. Filen > är 1,2 Gbyte stor, jag ämnar publicera den någonstans i Internet så > att andra kartläggare kan spara lite tid. > Jag kan även slå alla typer på skogar ihop, men det ska ta lite mer > tid och rymd. > > P.S. om någon undrar vad för problemet finns med gdal_sieve.py, är det > så att om man sparar en ny filnamn tappas färgkartan bort. Däremot om > man skriver över den ursprungliga filen då förblir färgkartan i den > och resultatet ser ut normalt. > > > Воскресенье, 7 апреля 2019, 10:55 +03:00 от egil : > > Hej > > On 2019-04-07 09:08, Grigory Rechistov via Talk-se wrote: > > Hej, > > Nyss körde jag mina nya skript på samma Vinön-area som tidigare. > Med nya > > `remap-raster.py` skriptet finns det inte längre några redundanta > > intilliggande skogsvägar, de är nu sammanslagna. > > > > Efter Chaikens utjämningsalgoritm (med 20 meter som > tröskelvärde) körde > > jag dessutom Douglas-Peucker (med 5 meter tröskeln) för att räta > avlånga > > vägar. `process-osmxml.py` används som tidigare. > > > > Resultatet (utan några vidare manuella ändringar) kan du hitta här: > > https://atakua.org/p/nmd/vinon-cdp-2.osm.gz , förhandsvisningsbild: > > https://atakua.org/p/nmd/vinon-cdp-2.png . > > Det här ser mycket bättre ut än dina förre försök i tråden med Gränsö. > > Jag är skeptisk till att importera dem olika skogstyperna eftersom > dem verkar vara skapad via AI och flygfoto/sattelitbilder och inte > särskilt > pålitliga. Underlaget för detta verkar inte vara tillgängligt. > > Skulle du kunna göra ett exempel där alla skogstyper slås ihop som > landuse=forest i vektorer med mindre än 2000 noder som jämförelse? > > Mvh > Egil > > ___ > Talk-se mailing list > Talk-se@openstreetmap.org <mailto:Talk-se@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-se > > > > С наилучшими пожеланиями, > Григорий Речистов. > Med vänliga hälsningar, > Grigory Rechistov > With best regards, > Grigory Rechistov > > > ___ > 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] Naturvårdsverkets nya Nationella MarktäckeData
On 2019-04-06 09:00, Christian Asker wrote: Hej. Jag tycker att planen ser bra ut, även om jag själv inte har några erfarenheter av att skriva sådana planer. En fråga bara: hur går själva importen till rent tekniskt sedan? Vi vill ju lägga in marktäckedata bara där detta redan saknas; ska man identifiera områden manuellt för import, eller kan man göra en enda import för hela landet? Någon som vet hur det går till? En särskild användare bör skapas. Hur vi ska identifiera områden vet jag ej. ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData
Hej On 2019-04-07 09:08, Grigory Rechistov via Talk-se wrote: Hej, Nyss körde jag mina nya skript på samma Vinön-area som tidigare. Med nya `remap-raster.py` skriptet finns det inte längre några redundanta intilliggande skogsvägar, de är nu sammanslagna. Efter Chaikens utjämningsalgoritm (med 20 meter som tröskelvärde) körde jag dessutom Douglas-Peucker (med 5 meter tröskeln) för att räta avlånga vägar. `process-osmxml.py` används som tidigare. Resultatet (utan några vidare manuella ändringar) kan du hitta här: https://atakua.org/p/nmd/vinon-cdp-2.osm.gz , förhandsvisningsbild: https://atakua.org/p/nmd/vinon-cdp-2.png . Det här ser mycket bättre ut än dina förre försök i tråden med Gränsö. Jag är skeptisk till att importera dem olika skogstyperna eftersom dem verkar vara skapad via AI och flygfoto/sattelitbilder och inte särskilt pålitliga. Underlaget för detta verkar inte vara tillgängligt. Skulle du kunna göra ett exempel där alla skogstyper slås ihop som landuse=forest i vektorer med mindre än 2000 noder som jämförelse? Mvh Egil ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] Hur ska vi namnge våra delsträckor på vandringsledarna?
Se https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/Hiking_trails#V.C3.A4sternorrland Mvh pangoSE ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] Fängslen i SE
Hej https://overpass-turbo.eu/s/Grs Dem skulle behöva en genomgång och ges länkar till kriminalvården.se, namn m.m. Lite kärlek med andra ord :) ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] FYI import av laddstationer
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Nordic_Charging_Station_Import Det här ser bra ut. Tack NKA! ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] Liten ordlista för OSM-deltagare
Hej :) Jag har efter några år i OSM börjat fundera lite på hur vi bäst översätter engelska uttryck som förekommer i gemenskapen. Här kommer en liten lista över ord som jag valt att översätta med länkar till den svenska Wiktionary: * **bug** ⇒ fel, [bugg](https://sv.wiktionary.org/wiki/bugg) * **mapper** ⇒ OSM-are, [kartläggare](https://sv.wiktionary.org/wiki/kartläggare) * **render** ⇒ [rendering](https://sv.wiktionary.org/wiki/rendering) * **render bug** ⇒ [renderingsfel](https://sv.wiktionary.org/wiki/renderingsfel) * **tag** ⇒ [tagg](https://sv.wiktionary.org/wiki/tagg) * taggstatus kan vara: i användning, övergett, godkänt, utkast, till diskussion (RFC) Utifrån detta kan ord som dessa skapas: fellagd, felrendering, feltaggat, tagga om, taggdokumentation, ... Vad tycker ni? Kom gärna med förslag och kommentarer. Mvh Egil/pangoSE ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-se] Fwd: Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style
Hej Jag undrar om det är nån som har något emot att jag massändrar sub_station->substation enl. nedan i SE. Totalt 198 objekt. Mvh Egil/pangoSE Forwarded Message Subject: Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style Date: Mon, 22 Oct 2018 10:06:36 +0700 From: Dave Swarthout Reply-To: daveswarth...@gmail.com, Tag discussion, strategy and related tools To: Tag discussion, strategy and related tools It would seem an easy fix to change all power=sub_station tags to power=substation without an individual inspection. The other tag, power=station, is much more problematical because one cannot know for sure if that tag is correct. I think most new mappers already use the newer tagging guidelines but I'm not sure what mechanism you could use to get the message out to all concerned. Dave On Mon, Oct 22, 2018 at 8:22 AM Daniel Koć <mailto:daniel@ko%C4%87.pl>> wrote: Hi, It has been noted that we still render power=station and power=sub_station in OSM Carto, even if they are both deprecated and replacement tags are much more popular by now: https://github.com/gravitystorm/openstreetmap-carto/issues/3305#issuecomment-414058220 I would be happy to get rid of them eventually, but I'd like to take some time before doing that, because they still have some share in a database: - power=station - 5 016 uses - https://wiki.openstreetmap.org/wiki/Tag%3Apower%3Dstation - power=sub_station - 17 514 uses - https://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station Could we reduce their usage further now (or maybe even eradicate them)? -- "Excuse me, I have some growing up to do" [P. Gabriel] ___ Tagging mailing list tagg...@openstreetmap.org <mailto:tagg...@openstreetmap.org> https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list tagg...@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-at] Fwd: Re: [Tagging] Feature Proposal - RFC: Via ferrata simplified
Hallo Ich habe von Richard gehört, dass einige von Ihnen vielleicht daran interessiert sind, Vorschläge für Klettersteig-Tags zu diskutieren. Es gibt jetzt zwei konkurrierende Vorschläge, siehe unten. Grüße Egil / pangoSE, Schweden Vidarebefordrat meddelande Ämne: Re: [Tagging] Feature Proposal - RFC: Via ferrata simplified Datum: Tue, 4 Sep 2018 11:46:14 +0200 Från: egil Svar till: Tag discussion, strategy and related tools Till: tagg...@openstreetmap.org Hi Den 09/03/2018 kl. 02:53 PM, skrev Richard: On Mon, Sep 03, 2018 at 01:25:45PM +0200, egil wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/Via_ferrata_simplified please not a completely new utterly incompatible with everything else proposal. Many elements of the old proposal are in use and rendered by several maps. While the old proposal is controversial, the plan has been to overcome much of the controversy by adding the possibility to tag ferratas as relation of type route=ferrata (added a few days ago). Why would you want to use route=hiking for ferrata if you can use route=ferrata? Do you want to deprecate via_ferrata_scale as well? I responded to Richard here: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Via_ferrata_simplified Feel free to join the discussion. Cheers ___ Tagging mailing list tagg...@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk] How to extract the 12M maritime borders using osmosis?
Hi! I'm working for a project that aims to measure IUU (illegal, unregulated and unregistered) fishing (globalfishingwatch.org). For this I'd like to be able to classify vessel track points as withing various areas, e.g. MPAs, economic zones and national waters, of which OSM contains the last one. I'm trying to extract this dataset and import it into a PostGIS instance for further processing. According to http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dmaritime#Territorial_sea_.2812.C2.A0nm_zone.29 the borders should have these attributes boundary=administrative since so many had a problem with grouping it together with maritime borders maritime=yes to state that this is a maritime border, so it can be rendered correctly/different from land borders admin_level=2 since it is a national boundary border_type=territorial to distinguish it from borders on land I tried extracting these borders using osmosis/bin/osmosis -v \ --read-pbf-fast file=planet-latest.osm.pbf \ --tf reject-relations \ --tf reject-nodes \ --tf accept-ways boundary=administrative maritime=yes admin_level=2 border_type=territorial \ --write-xml file=12M.osm I then imported this into PostGIS using osmosis/bin/osmosis -v --read-xml file=12M.osm.bz2 --write-pgsimp-dump directory=12M and the SQL script osmosis/script/pgsimple_load_0.6.sql. Now to the problem: * I see a bunch of nodes all over the place, some even inland: http://cdb.io/1QjDRGN * I see only 40 ways with nodes, all somewhere on the border of Iran: http://cdb.io/1QjE2Sq I tried the following query to find the number of ways with nodes: select count(*) from (select ways.id, st_makeline(nodes.geom) line from ways, way_nodes wn,nodes where wn.way_id = ways.id and wn.node_id = nodes.id group by ways.id) a where line is not null; Thanks in advance, Egil signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Historical Data in OSM database
If you prefix tag keys of historic elements with past:, it will not interfere with extisting SW conserned with rendering the present state. Examples: past:building=y, past:highway=... At the same time it should be easy to render historic maps based on existing styles. I doubt that historical mapping will add significantly to the OSM database size on the global scale. But if I am wrong, it will certainly add value to OSM, IMHO. (I first thought of historic: prefix, but that can be misunderstood to mean present object of historic interest.) BR/Egil Hjelmeland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How inaccurate was the mapnik distance/scale marker?
Dave F. wrote: Excuse my ignorance, are you saying that it's 2x inaccurate at all zoom levels? At lattitude 60: yes. So one of the mapnik guys could implement it quite easily then? I don't think it is related to mapnik. It is the javascript code served by the web-site that wraps up the map rendered by mapnik, osmarender or what so ever. It is part of the javascript code running in your browser which handles panning, zooming and selection of map-layer. If you are thinking of the map on openstreetmap.org, that would have be done by the maintainers of that site. Cheers Dave F. Egil H ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How inaccurate was the mapnik distance/scale marker?
I assume you are referring to the OpenLayers based slippy map at openstreetmap.org? The Openlayers 2.8 ScaleLine class has the the problem that it does not handle that the map-scale is not constant accoss the map. The slippy map uses mercators projection, where the scale increases with 1/cos(lattiude). So the scaleline is correct at equator, but a over factor 2 off where I am at 62 north. But it is trivial to make a mercator-specific variant of ScaleLine. I have made one here: http://www.egil-hjelmeland.no/kart/mercatorScaleLine.js. Anyone are free to use it. View it in action at my playground: http://www.egil-hjelmeland.no/kart/ . It is also very easy to make measurement functions in OpenLayers. And the good thing is that the OpenLayers Measure class is geodesic aware, it handles mercator out of the box. I think it would be good to include that on the OSM main map, as well. Cheers Egil H There used to be a distance indicator graphic in the bottom left of the map. I believe it was removed because it was inaccurate due to the curvature of the Earth. I can understand the point at low zoom levels, but at say, zoom 13, just how inaccurate, percentage wise, is it? I found it quite useful as a guide. Obviously I didn't do any intricate journey calculations based on it, but as a ball park figure, it came in use. Could it be reinstated for the higher level zooms, 11 maybe? Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 65, Issue 41
I think it does not hurt to define the exact meaning of a line-segment in OSM. And I think that great circle (in wgs84) is the natural choice, in stead of defining line to be straight relative to some arbitrary projection. Since the API (for performance reasons) can not return line segments with endpoint outside the bounding box, we (at least for some time) have to live with adding redundant nodes for every x km for great-circle lines. Then I suggest that the purists may add a tag redundant=y to the redundant nodes. To Frederik's concern about mappers getting confused about what a straight line is: I guess that there is only a tiny fraction of the mappers that ever will come across very long line segments. I suppose more than half of them can do it right in the first place if it is properly described on the Wiki. (Particulary state that a line of lattitude is not a Great circle, except for equator). And the other cases can be corrected by others who understands the concept of a great circle. That is the beauty of wiki-style mapping. Best regards Egil Message: 6 Date: Sat, 09 Jan 2010 09:58:20 -0500 From: Greg Troxel g...@ir.bbn.com Subject: Re: [OSM-talk] New Highways view in OSM Inspector To: Frederik Ramm frede...@remote.org Cc: OSM Talk talk@openstreetmap.org Message-ID: rmiskafl3zn@fnord.ir.bbn.com Content-Type: text/plain; charset=us-ascii We were discussing what exactly a straight line was. There is no such thing as a straight line in the database, because, as you correctly state, the database only stores the end points of a line. If you draw a line from point lat=10;lon=10 to lat=30;lon=30, then it is unclear whether that line visits point lat=20;lon=20. Some might think yes, some might think no. I think this is exactly the key question. When there is a line segment in the database, in WGS84 lat/lon, with points (lon1,lat1) and (lon2,lat2), then we need to have a definition of what that representation means. Obvious candidates are: 1) linear in lon,lat space 2) great circle in wgs84 3) linear in google spherical mercator 4) linear in WGS84 UTM 5) linear in your own country's local grid, or US state plane coordinate system 6) we don't define it, and if any of the above are different in any discernible way, you need more points. In the 10,10 30,30 example above, we are clearly in this state. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Highways view in OSM Inspector
Egil Hjelmeland wrote: Sorry, I forgot to change the subject line. I think it does not hurt to define the exact meaning of a line-segment in OSM. And I think that great circle (in wgs84) is the natural choice, in stead of defining line to be straight relative to some arbitrary projection. Since the API (for performance reasons) can not return line segments with endpoint outside the bounding box, we (at least for some time) have to live with adding redundant nodes for every x km for great-circle lines. Then I suggest that the purists may add a tag redundant=y to the redundant nodes. To Frederik's concern about mappers getting confused about what a straight line is: I guess that there is only a tiny fraction of the mappers that ever will come across very long line segments. I suppose more than half of them can do it right in the first place if it is properly described on the Wiki. (Particulary state that a line of lattitude is not a Great circle, except for equator). And the other cases can be corrected by others who understands the concept of a great circle. That is the beauty of wiki-style mapping. Best regards Egil Message: 6 Date: Sat, 09 Jan 2010 09:58:20 -0500 From: Greg Troxel g...@ir.bbn.com Subject: Re: [OSM-talk] New Highways view in OSM Inspector To: Frederik Ramm frede...@remote.org Cc: OSM Talk talk@openstreetmap.org Message-ID: rmiskafl3zn@fnord.ir.bbn.com Content-Type: text/plain; charset=us-ascii We were discussing what exactly a straight line was. There is no such thing as a straight line in the database, because, as you correctly state, the database only stores the end points of a line. If you draw a line from point lat=10;lon=10 to lat=30;lon=30, then it is unclear whether that line visits point lat=20;lon=20. Some might think yes, some might think no. I think this is exactly the key question. When there is a line segment in the database, in WGS84 lat/lon, with points (lon1,lat1) and (lon2,lat2), then we need to have a definition of what that representation means. Obvious candidates are: 1) linear in lon,lat space 2) great circle in wgs84 3) linear in google spherical mercator 4) linear in WGS84 UTM 5) linear in your own country's local grid, or US state plane coordinate system 6) we don't define it, and if any of the above are different in any discernible way, you need more points. In the 10,10 30,30 example above, we are clearly in this state. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Highways view in OSM Inspector
An other practical alternative: Leave the exact definition of line segments undefined (as Frederik suggests). Then tag straight ways as straight=great circle or straight=lattitude or what ever. And then tag the redundant nodes as redundant=yes. Egil Egil Hjelmeland wrote: Egil Hjelmeland wrote: Sorry, I forgot to change the subject line. I think it does not hurt to define the exact meaning of a line-segment in OSM. And I think that great circle (in wgs84) is the natural choice, in stead of defining line to be straight relative to some arbitrary projection. Since the API (for performance reasons) can not return line segments with endpoint outside the bounding box, we (at least for some time) have to live with adding redundant nodes for every x km for great-circle lines. Then I suggest that the purists may add a tag redundant=y to the redundant nodes. To Frederik's concern about mappers getting confused about what a straight line is: I guess that there is only a tiny fraction of the mappers that ever will come across very long line segments. I suppose more than half of them can do it right in the first place if it is properly described on the Wiki. (Particulary state that a line of lattitude is not a Great circle, except for equator). And the other cases can be corrected by others who understands the concept of a great circle. That is the beauty of wiki-style mapping. Best regards Egil Message: 6 Date: Sat, 09 Jan 2010 09:58:20 -0500 From: Greg Troxel g...@ir.bbn.com Subject: Re: [OSM-talk] New Highways view in OSM Inspector To: Frederik Ramm frede...@remote.org Cc: OSM Talk talk@openstreetmap.org Message-ID: rmiskafl3zn@fnord.ir.bbn.com Content-Type: text/plain; charset=us-ascii We were discussing what exactly a straight line was. There is no such thing as a straight line in the database, because, as you correctly state, the database only stores the end points of a line. If you draw a line from point lat=10;lon=10 to lat=30;lon=30, then it is unclear whether that line visits point lat=20;lon=20. Some might think yes, some might think no. I think this is exactly the key question. When there is a line segment in the database, in WGS84 lat/lon, with points (lon1,lat1) and (lon2,lat2), then we need to have a definition of what that representation means. Obvious candidates are: 1) linear in lon,lat space 2) great circle in wgs84 3) linear in google spherical mercator 4) linear in WGS84 UTM 5) linear in your own country's local grid, or US state plane coordinate system 6) we don't define it, and if any of the above are different in any discernible way, you need more points. In the 10,10 30,30 example above, we are clearly in this state. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging schema
of the rendering A language translation table on literal values: -Key name - Literal value - Language ID (ISO 639) - Localised name for value - Localised description in English Organisation: OSM is a community of volunteers. So neither bureaucracy or dictatorship is probably the way to go. I would guess that forking off a “tagging” mail group with a strict “keep-to-topic” policy would be the way to proceed. It could deal with tagging schema/policy in general, as well as core tagging, and assigning top level keys to other sub level tagging groups. Well, it is time to get some sleep before work calls tomorrow. I am not going to implement any of this. I just hope these ideas can spawn some productive debate. Best regards Egil Hjelmeland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - key:prominence
Here is a proposal for tagging natural=peak with its prominence (prime factor) in meters: http://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence Please comment, preferably on the talk-page. Best Regards Egil Hjelmeland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
