Ok. Låter logiskt att detta är något som uppdateras av klubben i GIT för att HCP-rundor ska bli rätt. Och då har ju klubben redan knackat in detta i GIT, så att också då uppdatera OSM känns överflödigt, är detta något som kan verifieras på plats med en skylt som beskriver vilka delar som är idag? Precis som jag sagt tidigare, denna typ av väldigt snabb data som lätt blir inaktuell platser inte så bra i OSM. Jag skulle själv vilja lägga en motion på golfförbundets årsstämma nästa år att de gör deras API’r öppna & gratis att använda, och just där skulle en sådan här data hämtas för applikationer som vill komma åt datan. Men tyvärr så tar de hiskeligt betalt för API access för data i GIT tyvärr. Du får gärna mejla hugo@emmabodagk.se om du vill ställa upp och vara med på den motionen tillsammans med mig.

Och la till denna loop-infon i en relation för varje 9-hål grupp i changset changeset/183631592#map=15/58.60485/16.32180

Uppdaterade wikin för hur man taggar loopar i en route=golf: route=golf#Courses%20which%20consists%20of%20different%20%22loops%22%20for%20each%20day

- En relation.

Hej! Okej, då förstår jag. Sådana här konstellationer med dagligt roterande 9-hål har vi inte dokumenterat på wikin, bra att detta kom upp hur man ska representera dessa banor. En komplimentagg för vilken slinga ett hål hör till kanske skulle kunna vara golf:loop="vit" för att fortsätta på namespacet golf:*

Min första tanke är att vi aldrig kommer kunna representera vilken "slinga" som ingår i dagens bana då OSM inte ter sig för sådan dagligt varierande data.

Om du vet hur sådana här konstelationer fungerar, är det bara en 18-hålsbana som är öppen i taget för dagen och en slinga på 9 hål "vilar"? Eller är det öppet en 18-hålsbana och en 9-hålsbana för att styra greenfeegäster till de 18-hålen som är banan? Kan inte så mycket om hur detta fungerar. Hur ksulle detta se ut i GIT/min golf? Är det bara 1 banan som går att boka med samma namn?

Alla taggar som beskriver en specifk bana, såsom golf:par=* fungerar inte heller då jag förmodar att hur banan slopas (Svårighetsgrad för handicapsystemet) påverkas beroende på vilken konstelation man har en specifk dag.

Vi får nog klura på hur vi representerar dessa "underslingor" av hål.

Jag undersöker vidare och lägger upp en rekommendation på wikin. Någon typ av logiska grupper, kanske genom en tagg och eller.

Hej! Du har tyvärr taggat fel på ref= ref ska bara innehålla en siffra som beskriver vilket hål det är.
Likaså använder vi handicap och inte handicap_index för att skriva index. Läs på ref=*
golf=hole
leisure=golf_course
Ett bra och uniformt taggingsystem för tee-färger finns tyvärr inte ännu, något jag kommer jobba på wikin. Sålänge finns tee=* och tee=*
If you need this comment in english, dont hesistate to answer this.
Vilken editor använde du?

”Seems to render correctly” is just wrong on so many levels. Please please don’t go around ”fixing things” if you do not understand what we are doing here in this project called OpenStreetMap. We are building a collection of geographical features into a database that is THEN rendered. There is no such thing as ”renders good” OSM Carto on the main website is just to show of the capabilities of the data. Not the ground truth. Tagging for one specific renderer is not okay just because some tool is saying so. osm.wiki/Tagging_for_the_renderer
The OSM inspector tool is wrong, and can be wrong. There is no ”complete” schema. ALWAYS make your own judgment and not just blame a tool because it says something. If you want it ”clean” please ask the developer of the OSM inspector tool to make a feature where you can skip elements (which I think it can do) for example, in OSMand to name a render there is now a gap between the road and one of the paved area. That does not reflect the real world and that is what we are trying to do here.

I have already discussed this with archie. Just becuase the footway is flagged as wrong my your tools that doesn´t automaticly makes it right. there is NO gap between the pavement and the road and that is then a lie to fit a rendererar, e.g., tagging for the renderer!

This created problems in https://sv.wikipedia.org/wiki/Diskussion:Åsunden,_Västergötland#Identitet
please do not just remove stuff to deem obsolete without checking why it was created in the first place or just search on wikipedia...

Who got the brilliant idea to remove the old relation which had a wikidata tag changeset/174647646 and not link it in this new one?

Why? This was the 99th largest lake in Sweden and now (why wikimedia need this ID is still a mystery to me)

Brickblock1 hjälpte mig reda ut "Duplicate segment" felet som OSMI skriker på. Ser ut som att den klagar på att en multipolygons inre kan ligga med delade noder för den yttre då hela inre måste omslutas av yttre. Det hittades detta på ämnet osm.wiki/Proposal:Relation:multipolygon/validity

Så då har jag tagit och flyttat in skogspolygonen för att den ska ligga mitt i ruffen (vilket är fel från what´s on the ground????) då OSMI utvecklare valde att inte gå efter praxis, eller ja iallfall inte dokumentera detta på osm.wiki/Relation:multipolygon vilket hade gjort att vi slapp sitta här och rätta dataa.

Det är jag medveten om, men om vi går på en tur igenom dokumenationen:
På OSMI´s hemsida du länkar finns det ett "i" där, osm.wiki/OSM_Inspector/Views/Areas
Om man senare läser igenom beskrivningen av Way in >1 rings
finner vi länken: https://github.com/osmlab/fixing-polygons-in-osm/blob/master/doc/problems.md#duplicate-segments
där finner vi stycket
https://github.com/osmlab/fixing-polygons-in-osm/blob/master/doc/problems.md#duplicate-segments:~:text=The%20current%20Osmium%20code%20can%20not%20differentiate%20between%20problematic%20and%20non%2Dproblematic%20duplicate%20segments.%20This%20could%20be%20improved%20for%20better%20reporting%20to%20mappers%20what%20to%20fix.
Det var där jag fick Osmium ifrån.

Kanske använda ordvalen "Enligt detta verktyg anser att du har fel på följande punkter, när jag snabbt kollade igenom ändringar hittade jag detta, vänligen kontrollera berörd data" // @archie

Tack så mycket för tipset men jag är medveten om verktyget men det var en god tanke, men som osmiums dokumenatation beskriver om "The current Osmium code can not differentiate between problematic and non-problematic duplicate segments. This could be improved for better reporting to mappers what to fix." Vilka fel tycker du är fel om vi nu bara understryker att det är ett verktyg?

Om du menar det jag kartlagt vet jag inte inte riktigt vad du menar, skulle du kunna utveckla vad du menar istället för att länka till en random sida. Varför i frågan.