piebro/osm-data huggingface dataset:
AlwynWellington (2022-05-18 01:26:57+00:00): There are two issues on the go.
I propose we work through them one at a time.  As the vehicle access tagging issue seems to be simpler, I propose we work at that one first.

Vehicle access tagging

The section from Siberia down to Cross Creek Yard is a track (wide enough for a train back in the day, and now four wheeled vehicles) the only matter to consider is what access vehicles have.  
There is a highway=track from Cross Creek car park across private farm land to Cross Creek Yard.  As might be expected, this is marked as access=private.  And no doubt this is how DoC, as land owner, gains access to the publicly available Rail Trail for whatever maintenance or works they wish to carry out from Siberia down.

I don't think it is for us to speculate how DoC manage the Rail Trail and what types of vehicles they use, when needed.

As Vehicle=yes (open to all) or = no (open to no one) seems inappropriate.  This 5 km not open to all and nor, as far as we can tell, is it closed to all.

The choice seems to be one of permit or private.  

I cannot easily find Wiki descriptions for others in the pop-up list for vehicle access.  You may have better luck.

Which of those two do you suggest?
❤️‍🔥 (2022-05-21 07:11:44+00:00): Sorry for the delayed reply. I'm not sure whether motor_vehicle=private or motor_vehicle=no is better, but motor_vehicle=permit seems wrong according to the wiki (https://wiki.osm.org/Tag:access=permit), since that tag suggests that anyone who asks for a permit will receive one, which is not the case here. The wiki says "If permit is hard to obtain, then it is typically access=private".

You said you struggled to find the wiki documentation - here's the list of values: https://wiki.osm.org/Key:access#List_of_possible_values
Livestock Poultry Farm (2022-05-16 02:38:12+00:00): Ask more info & offer ➜ https://ngyenmbofarm.com/
  sales@ngyenmbofarm.com Whatsapp: ( +27 ) 76 193 2401
nyampire (2022-05-16 04:53:55+00:00): OSMへようこそ！
編集をレビューしました。レストランのノードについてはとてもよく描けていると思うのですが、一緒に編集された道路が、変な位置にドラッグされてしまっているようです。
申し訳ないのですが、道路に関してはいったんリバート（巻き戻し）させていただきたいと思います。レストランのノードは残るようにします。

次は、既存の道路をドラッグせず、少し注意して編集してみてください。
Happy Mapping!
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/121029859
Glassman (2022-05-16 19:57:34+00:00): Question - did you mean to make the trail no access for everyone? If so can you explain why? I'll send you more info on OSM in a message.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/121029878
MxxCon (2022-05-16 04:03:58+00:00): Which OASIS NYC map are you referring to? CUNY one? If so, it shows this street name. Also both streets.planning.nyc.gov and ZoLa show it. However Bing or Streetview don't show any street signs there, but both imagery seem to be pretty old(2014-ish). Cyclomedia is giving me error for now. 🤔
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/121030354
nevw (2022-05-16 06:45:19+00:00): Hi
The Lord Forrest Hotel is already mapped as a polygon. You should add/amend your tags on that instead of creating a new point for the hotel.
nevw (2022-05-21 08:49:50+00:00): now merged
user_5359 (2022-05-22 07:07:53+00:00): Hello! Please have a look on http://www.openstreetmap.org/way/1060405767 (one of three objects). What is the meaning of the foreign keys
ADMIN_UNIT = DISTRICT
DISTRICT = SUJJAWAL
OBJECTID = 145
PROVINCE = SINDH
Shape_Area = 0.7733638397
Shape_Le_1 = 6.4053077111599999
Shape_Le_2 = 6.4053077111599999
Shape_Leng = 14.2919003605
?
What is the source of this information?
user_5359 (2022-05-26 14:35:44+00:00): If I do not receive an answer, I will have to delete this change.
Achyut Kumar Aryal (2022-05-26 16:06:20+00:00): This is the geojson file of the district over there ,not such a big issue .I was learning to add boundary over there and map inside the area
Achyut Kumar Aryal (2022-05-26 16:07:09+00:00): Boundary info from Pakistan survey department
user_5359 (2022-05-26 16:22:53+00:00): Did you know the existing boundaries? For example https://www.OSM.org/relation/6104689 . I assume you add duplicate ways! Please check this!
Read also https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
Mondal (2022-05-16 05:27:30+00:00): The road is not a bridge. on the river part will be bridge
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/121032454
korridor (2022-05-29 18:11:16+00:00): I think you added the tag ref:at:gkz to the wrong element. I removed the tag from Gasthaus Kremstalblick.
gzin (2022-05-29 20:22:01+00:00): Why do you think so? I found the number on the receipt from "Gasthaus Kremstalblick".
But - if you remove the number - it is also OK for me.
gzin (2022-05-29 20:24:22+00:00): I was there on May 14th, see https://www.mapillary.com/app/?lat=48.061084972222&lng=14.136343972222&z=17&pKey=998476751059726
korridor (2022-05-30 09:04:46+00:00): The tag ref:at:gkz should be used for the Austrian municipality identifier (https://en.wikipedia.org/wiki/Community_Identification_Number#Austria). The number you provided is probably the VAT identification number of the restaurant. (https://en.wikipedia.org/wiki/VAT_identification_number)
The municipal identifier should also only be used on a municipal and not on normal entities inside of the municipal.
Mateusz Konieczny (2025-01-23 14:18:07+00:00): Are you sure that https://www.wikidata.org/wiki/Q5617739 should be linked for https://www.openstreetmap.org/node/6942428008/history ?

https://www.wikidata.org/wiki/Q111949119 seems more likely to match

(or maybe some other? or maybe these are the same company?)
❤️‍🔥 (2025-01-23 22:33:59+00:00): See https://github.com/osmlab/name-suggestion-index/pull/7780

Q5617739 was the correct ID until 2023 when that ID was repurposed.

It's a bit annoying, but apparently spliting by country is required for https://alltheplaces.xyz
Mateusz Konieczny (2025-01-26 17:48:56+00:00): per https://en.wikipedia.org/w/index.php?title=Gull_Petroleum&diff=prev&oldid=1092536955 Wikipedia split articles in 2022

And new Zealand part was sold in 2016.

No idea is it really considered as a distinct brand.

For now I created https://www.openstreetmap.org/note/4603025
❤️‍🔥 (2025-01-30 12:21:36+00:00): fixed in https://osm.org/changeset/161935139
user_5359 (2022-05-18 19:27:16+00:00): Welcome to OSM! I have revert your SEO SPAM (mostly no standard keys, no verifiable data, not positive verifiable address data, destroying data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.
user_5359 (2022-05-20 06:47:20+00:00): Welcome to OSM! I have revert your SEO SPAM (mostly no standard keys, no verifiable data, not positive verifiable address data, destroying data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.
kortgodt (2022-05-16 10:39:17+00:00): 10A-10D er udstykket til beboelse
highflyer74 (2022-10-07 13:27:02+00:00): Moin und danke für deinen Beitrag in Bremen!

Wenn du Telefonnummern einträgst, denke daran, auch nach der Ortsvorwahl ein Leerzeichen zu setzen. Das sieht dann am Ende so aus:

+49 xxx xxxxxxxx

Danke dir und viele Grüße!
dtreffenstaedt (2022-10-13 14:12:32+00:00): Moin!
Vielen lieben dank für die Anmerkung und Korrektur, ich werde in Zukunft darauf achten.

Liebe Grüße
flohoff (2022-05-18 09:15:13+00:00): Weil ich den hier gerade gesehen habe:

https://www.openstreetmap.org/way/1060426756

tracktype geht nur auf einem track - das macht so keinen Sinn.

Flo
JuanCarlos80 (2022-05-18 20:01:45+00:00): Den Tracktype hatte DennisBrandt in Änderungssatz 4140949 vor ca 12 Jahren da hingeschrieben, obwohl damals schon "residential" als highwaytyp gesetzt war.

Das liegt wohl daran, dass der westliche Teil eher was für MTBs ist. Der Asphalt oder was davon übrig ist ist völlig kaputt.
antonr (2022-05-27 14:51:19+00:00): Hejsa osmviborg

Det ser ud til at du har gentilføjet greenfield-tag på https://www.openstreetmap.org/way/958846889, som jeg havde fjernet. 

Jeg synes wiki'en om greenfield er rimelig klar: "...where there have been no buildings before." Det svarer også til min intuitive forståelse af ordet: En bar mark, hvor der ikke har være bygget før. Her er bygningerne der jo faktisk stadig... 

Har du en anden opfattelse af "greenfield"?

Hvad er det i det hele taget der er registreret her? En juridisk status for område? Nogens plan for området? Det virker lettere uldent i forhold til osm's princip om "Map what's on the ground".... Det er der også lidt diskussion om på greenfield-wiki'ens diskussionsside.

Du er meget velkommen til lige at skrive til mig i sådanne tilfælde hvor det lader til vi har forskellige opfattelser af hvordan et tag bruges... Ellers ender vi vel bare med en masse redigeringer frem/tilbage, hvilket virker som spild af tid...

Mvh
antonr (2022-05-27 15:16:51+00:00): Som foreslået i wiki-diskussionen kan designation=* måske bruges hvis der er tale om en juridisk afgørelse... Men jeg ville nok bare lade være med at tilføje ting der ikke findes fysisk :-)
osmviborg (2022-05-27 17:32:46+00:00): Du har overset den link til lokalplanen der er på https://www.openstreetmap.org/way/958846889
antonr (2022-05-27 19:47:49+00:00): Nope, den har jeg ikke overset. Men jeg kan ikke se hvordan den har nogen indvirking på mine pointer... Oplys mig gerne.

I området er der huse (stadig). Wiki siger at greenfield er et område hvor der aldrig har været bygget.

Så hvorfor skal der være et område tagget som greenfield her?
parsd51 (2022-05-28 09:02:30+00:00): Hej

“On the ground principle” er fint men dækker ikke administrative tags, som kommunegrænser, lovbestemte områder etc. Disse er dog forankret fysisk ved en grænse eller område i den fysiske verden. Her lokalplanen. Se evt.:
https://wiki.openstreetmap.org/wiki/Ground_truth

Det er ikke altid at tags passer helt, men man vælger det tætteste og mest rigtige i situationen.

Der er en stor gråzone omkring greenfield, som ikke er dækket. F.eks dette tilfælde, planlagte renoveringer etc. Denne findes også omkring brownfield, hvor lokalplanen kan omfatte eksisterende erhverv og ikke kun nedlagt. Her er igen en gråzone, hvor greenfield måske passer bedre samlet set.

Man kunne opfinde et nyt tag, f.eks chequeredfield (ternet område), men hvad ville meningen være? Det vil stadigt være et område til udvikling, dog mere nuanceret.

greenfield er pt. det bedste tag i situationen, uden tag er meningen væk. 

Du er velkommen til at dokumentere wiki og hele processen omkring et nyt tag.

Hilsen
parsd51
antonr (2022-05-28 17:35:44+00:00): Hej parsd51,

Ikke helt sikker på hvem du mener er velkommen til at dokumentere wiki og finde på tags?

Jeg synes wiki er helt klar omkring greenfield: "...where there have been no buildings before", så har ikke noget behov for at ændre.

Jeg fjernede greendfield-tag, fordi området ikke er greenfield (jf wiki og almindelig forståelse af ordet greenfield). 

Jeg lod bevidst den tag-løse way være så det var nemmere forstå historikken (fremfor at slette).

Jeg tænkte at tag-løs way er bedre (enig i at meningen er væk) end way tagget i modstrid med virkeligheden (meningen er værre end væk). På den måde forstyres eventuelle brugere af "greenfield" data ikke af virkelighedsstridige datapunkter.

Det allerbedste ville vel være at dem der gerne vil registrere lokalplaner (ikke mig), udvikler et passende tagging-koncept... Fx med designation=* som jeg foreslog ovenfor (nappet fra diskussion på greenfield-wiki). Så kunne det jo gå hen og blive brugbart data!
antonr (2022-05-28 18:00:56+00:00): Eller hvad med bare at smække proposed[1] foran brownfield/residential/...?

Jeg siger ikke det er en god ide, men i det mindste er det ikke direkte i modstrid med virkeligheden (som jeg mener greenfield er i dette tilfælde)

[1] https://wiki.openstreetmap.org/wiki/Key:proposed
parsd51 (2022-05-28 19:10:49+00:00): @antonr:
På mig virker det som om du har hæftet dig ved en detalje i greenfield og ikke kan se den overordnede mening med tagget. Detaljerne er nuancer ifht meningen.
For mig er nøgleordet for de to field tags: udvikling. 
greenfield/brownfield er netop det rigtige tag for registrering af fremtidig udvikling, hvilket netop er f.eks. kommuneplaner og lokalplaner. Andre (nye) tags forplumrer netop meningen.

greenfield :
“The greenfield describes land scheduled for new development“
“Note that it describes merely legal status of area”

brownfield:
“Brownfield is a land which was previously developed which is not currently in use”

chequeredfield: (forslag, med egen punchline)
“Development of existing area with currently used buildings.”

Når du fjerner tags fjerner du meningen med tagget. Det der bliver tilbage er “usynlige detaljer under overfladen”.

Du er det første der er uenig i brugen af tagget, så jeg forstår ikke du refererer til almindelig forståelse af tagget. At du er forvirret omkring tagget, betyder ikke at alle andre er. Disse tags er mere abstrakte end de fleste osm tags, som er meget fysisk forankret.

Du skriver du ikke er interesseret i det her område. Hvad vil du gerne opnå?

@osmviborg og andre:
Hvad siger du/I, skal vi lave et tag til at nuancere de eksisterende?
antonr (2022-05-28 19:59:53+00:00): @parsd51
Det sidste først: Jeg er interesseret i at vi i venligt og konstruktivt samarbejde får osm til at afspejle virkeligheden så godt som muligt.

Jeg så i forbindelse med andre redigeringer (og rettede efter bedste evne) hvad jeg opfattede et mismatch mellem virkelighed og osm+wiki:
- virkelighed: Område med huse beboet af mennesker
- osm+wiki: Område markeret som aldrig bebygget og udlagt til ny bebyggelse.

Så det var helt bevidst at jeg fjernede tagget (men ikke dets way). Netop for at fjerne (hvad jeg opfattede som) virkelighedsstridigt data.

Mht til almindelig forståelse tænkte jeg på det engelske ord "greenfield", men jeg er helt med på at osm-tags ikke altid betyder det samme som det tilsvarende engelske ord. Derfor kiggede jeg i wiki'en.

Vi har vist forskellig opfattelse af hvad der er detaljer og hvad der er essens i forhold til greenfield-wik'ien: Når du citerer den ene halvdel af første sætningen ville jeg nok vælge det hele eller den anden halvdel: "... where there have been no buildings before." :-D

Grunden til at jeg fokuserer på den del, er jo nok at den er i modstrid med den fysiske virkelighed som jeg primært mapper.

Hvis der er en anden konsensus om hvad greenfield betyder blandt lokalplans-mappere, ville det være fint hvis wiki blev opdateret. På den måde vil jeg (og andre) let kunne slå op at greenfield godt kan omfatte bebyggede+beboede områder (eller hvad konsensus nu er), og dermed lade være med at rette til.

I forhold til bedre måder at tagge lokalplaner på, er jeg mere og mere varm på noget med proposed... Det synes jeg understreger at det objekt der er registreret ikke kan observeres i virkeligheden. Der er også noget relevant diskussion på den tilhørende talk-side https://wiki.openstreetmap.org/wiki/Talk:Key:proposed. Der er blandt andet dette citat som jeg personligt godt kan lide: "Note that generally, OpenStreetMap requires information to be verifiable on the ground. Proposed features that are not visible on the ground should therefore only be mapped in exceptional cases and after a discussion with the relevant OSM community, lest they might be deleted for lack of verifiability"

Mvh

PS at antyde at nogen andre end en selv er forvirret synes jeg er på kanten af god debatstil...
parsd51 (2022-05-28 21:53:12+00:00): @antonr

Virkeligheden er også abstrakt.

Jeg har imødegået dig med et tagforslag chequeredfield, (som jeg selv har observeret, men ikke fundet strengt nødvendigt) du kan gå videre med, som beskriver flere nuancer inden for lifecycle taggruppen greenfield/brownfield etc. Men du ønsker tilsyneladende hele systemet lavet om, hvad du er velkommen til, hvis du kan overbevise de andre brugere. proposed bruges i mange andre sammenhænge om objekter der ikke findes fysisk endnu, men er juridisk forankret. Juridisk forankring er lige så rigtig i osm som fysisk, som jeg har henvist til i tidligere link.

Mht til din PS, er det dig der taler om andres forvirring, hvad opfatter jeg som en projektion, så jeg prøvede at hjælpe, ikke genere, men jeg har nok misforstået dig med det:
“På den måde forstyres eventuelle brugere af "greenfield" data ikke af virkelighedsstridige datapunkter.”
antonr (2022-05-28 22:46:36+00:00): @parsd51

Helt enig i at der findes en abstrakt virkelighed! Jeg er bare personligt mere interesseret i den fysiske i osm-sammenhæng.

Selvom jeg synes at ikke-fysiske objekter (fx juridiske) er en ulden størrelse at putte i osm, er det ikke min anke her. Som skrevet i første indlæg ovenfor fjernede jeg greenfield-tagget fordi det jf wiki implicerer den fysiske egenskab at der ikke har været bygninger på stedet, men der er bygninger på stedet (altså fysisk tag i modstrid med fysisk virkelighed)

Måske er det vanskelige ved den mere generelle diskussion om lokalplaner vi har bevæget os ind i at greenfield/brownfield blander fysiske og ikke-fysiske egenskaber, mens lokalplaner er rent abstrakte?

Jeg sætter pris på dit konstruktive forslag om chequeredfield! Jeg er ikke klar over hvilken af proposed/chequeredfield der laver systemet mest helt om (hvilket jeg ikke tror/håber jeg har givet udtryk for at jeg ønsker?). Som du selv skriver bruges proposed mange andre steder, så det er vel helt indenfor rammerne af det eksisterende at foreslå at registrere lokalplaner med dén nøgle... Fx ser proposed=residential ud til at være populær: https://taginfo.openstreetmap.org/keys/?key=proposed#overview

Hmmm, i din forklaring af at jeg taler om andres forvirring bruger du et citat hvor jeg ikke nævner forvirring??? Nu er jeg faktisk forvirret :-) Jeg vil gerne høfligt men bestemt frabede mig hjælp til at give udtryk for min sindstilstand og mine holdninger, den klarer jeg selv. Så vil jeg lade dig have eneret på at give udtryk for din og dine!

Men egentlig ville jeg jo gerne høre @osmviborgs syn på sagen (som @parsd51 også spurgte til), eftersom det var ham og mig der flippede tagget til/fra/til, og han kunne derfor tænkes at have nogle argumenter der var gode at høre...
parsd51 (2022-05-28 23:57:22+00:00): @antonr 

proposed=residential bruges mest sammen med highway=proposed, derfor er den populær.

proposed=residential du tænker på, er nok en kopi af landuse=construction og construction=residential. Så det ville analogt være landuse=proposed og proposed=residential. Det er også en mulighed, men det fjerner information om det tilstanden af det eksisterende, som brownfield og greenfield inkluderer. Desuden er det en proposed feature, mens greenfield og brownfield er in use og de facto. Ydermere er brugen af landuse=proposed meget begrænset. Det vil sige at dataforbrugerene sandsynligvis ikke har kendskab til det. Det samme vil gælde nye tags som f.eks. chequeredfield, hvor der kan opstå problemer for eksisterende dataforburgere af greenfield/brownfield. 

Det er grundene til at jeg er tilbageholdende med at ændre/tilføje nye tags og rette eksisterende dokumentation. Groft sagt er det hensynet til bagudkompatibilitet og stabilitet.

Jeg har svært ved at forestille mig at dataforburgere af f.eks greenfield er interesseret i om der er bygninger der eller ej, det er den juridiske status der er interessant. Bygningsinformationen for området findes jo allerede tilgængelig.
antonr (2022-05-29 12:21:28+00:00): @parsd51
Dit forslag om landuse=proposed + proposed=residential lyder som en super løsning i dette tilfælde (hvis altså lokalplanen siger der skal være beboelse)! Som du siger fjerner/afkobler den information om tilstanden af det eksisterende, og det er jo lige præcis modstrid med det eksisterende jeg mener er problemet med at bruge greenfield/brownfield på dette sted (hvor der hverken er bar mark eller forladt bebyggelse).

Denne tagning vil så vidt jeg umiddelbart kan se hverken kræve nye tags eller ændring af dokumentation.

Kender du nogen use cases for det jurisdske aspekt af greenfield? Det ville være interessant at høre om! Det ser fx ud til at Carto ignorerer greenfield helt.

Hvis jeg var dataforbruger af greenfield, ville jeg i første omgang forvente at data levede op til den intuitive sproglige betydning eller beskrivelsen på wiki... Men du har jo ret i at dataforbrugeren selv kan se modstriden mellem mappede bygninger/wiki og så bare ignorere wiki. Det mener jeg dog (som professionel dataforbruger) gør livet unødvendigt besværligt for forbrugeren...
parsd51 (2022-06-01 11:52:06+00:00): Det er ikke det jeg skriver:
- landuse=proposed er et forslag (tagstatus er proposed).
- landuse=greenfield har tagstatus in use
- landuse=brownfield har tagstatus de_facto

Ved brug af landuse=proposed, hvis det godkendes vil fjerne sonderingen mellem greenfield og brownfield hvis de helt erstattes. Hvis det kun skal gælde for chequeredfield tilfældene lyder det ikke som en konsistent løsning, idet to taging-medtoder blandes for noget som er gruppemæssigt sammenhørende. Eneste værditilføjelse er den kommende områdetype (kommer med ved construction). Den skriver jeg nu mere præcist i noten.

Hvem kan hypotetisk tænkes at være dataforbruger af greenfield og brownfield?
- Korttegnere, som ønsker et “lokalplankort”, men der findes vist mere valide steder til det. OsmAnd appen renderer proposed veje, men ikke greenfield.
- Anlægsbranchen, nedrivningbranchen og renoveringsbranchen *), men det er for mig usandsynligt af samme årsag som ovenfor.
- openstreetmap.org, renderer ikke greenfield, men brownfield. Brownfield rederes ligesom construction og dermed ikke “beboligt”. Det er derfor jeg bruger greenfield til tvivlstilfælde, som f.eks. det vi diskuterer.
- Jeg kender ikke andre dataforbrugerene, end mig selv og nok osmviborg og nogle andre mappere. Jeg bruger det til at identificere områder med henblik på survey eller follow-up når der kommer nye kort. Jeg ser “ingen” der lægger lokalplaner ind, som ikke kan have en fremtidig faktuel betydning for kortet.

Risikovurdering:
Hvis andre bruger det f.eks de tre ved *, vil det meget afhænge af om om de opdager tagændringer og hvilke tags de kigger på. De fire muligheder:
- landuse proposed:
Ikke konsistent.
- chequeredfield:
Medium risiko, skifte til nyt tag, nogle kan gå glip af noget. Kræver opdagelse af det nye tag
- Fortsat tagning med greenfield:
Medium risiko, nogle kan gå glip af noget, hvis de ikke kigger på greenfield.
- Ikke tagge når bygninger:
Risiko høj, faktuelt mister dem der kigger på greenfield muligheder.

Risikokonklusion:
Så jeg ser valget mellem fortsat tagning med greenfield og chequeredfield, med en lille overvægt til fortsat tagning med greenfield.

Så samlet set jeg ser ingen praktisk grund til ikke at bruge greenfield ved eksisterende bygninger.

Du er velkommen til at forsøge at få godkendt “chequeredfield”, som ikke renderende, alternativt opdatere greenfield dokumentationen. Men jeg ser ikke den store reelle praktiske værdi, udover dem som er i tvivl og vælger at undlade rettelsen, men området findes nok på anden vis: nye adresser, nye vejnavne etc.