piebro/osm-data huggingface dataset:
Heideammer (2021-05-18 18:46:07+00:00): Hallo Johannes,
Du hast in OSM südöstl. von Tangendorf viele Industriegebiete mit dem Namenseintrag "von Lütchens beantragtes, geplantes Abbaugebiet" erfasst. Dazu ein paar Fragen/HInweise von mir:
- Sind die bergbaurechtlichen Genehmigungen schon durch?
- Dinden schon Abgrabungen über das Maß der bisher gemappten Flächen statt?
- Abgrabungen sind keine Industriegebiete sondern landuse = quarry.
- Gemappt werden soll in OSM nur das was vor Ort oder auf Luftbildern sichtbar ist.
- Geplante Nutzungen sind nur relevant insofern das Modell dafür Klassifizierungen vorsieht. Für geplante Abgrabungen sind mir keine Klassen/Attribute bekannt,
- Landnutzungen sollten sich in der Regel nicht überlappen (siehe in diesem Fall Wald und Industriegebiet.
- Das Namensattribut ist nur Eigennamen gedacht nicht für Kommentare.

Mein Hauptgrund für die Nachricht ist, dass hier wohl Dinge erfasst worden sich, die vor Ort und auch planungsrechtlich ("geplant") noch nicht umgesetzt sind. Sollte ich mich täuschen, entschuldige bitte meine Nachricht. Wenn ich recht habe, bitte ich die aktuelle Nutzung wiederherzustellen.

Selbst wenn die Genehmigungen für den Abbau vorliegen, können wird der Abbau ja stufenweise erfolgen. Solange würde ich den Wald noch als Wald belassen. Eine Abgrabung ist on the ground dann noch nicht vorhanden.

Gruß, Thorsten
Garstedter (2021-09-03 23:18:24+00:00): Ich bin vor ein paar Tagen erst da gewesen, noch ist der Wald da.

Gruß Garstedter
OEBF_ej (2026-06-26 06:18:13+00:00): Den "gelb markierten Irrweg" gibt es in der Natur nicht. Daher habe ich die Relation hinausgegeben.
desyco (2022-06-22 12:38:00+00:00): De benaming 'Schorren van Branst en het Eiland van Mariekerke' is verwarrend.  Enkel het deel boven aan (in Branst) zijn de Schorren van Branst'.  Het deel onderaan noemt 'het Eiland van Mariekerke'.
janolezab (2021-05-02 11:04:08+00:00): Guten Morgen! Ein Parkplatz sollte hier gesondert als Multipolygon eingetragen werden, mit fee=yes (die Ladestationen haben dieses Tag ja schon). Hier steht mehr: https://wiki.openstreetmap.org/wiki/DE:Tag:amenity=parking
janolezab (2021-05-02 11:08:41+00:00): Habe ich Multipolygon gesagt? Ich meinte natürlich einfach als Fläche.
mueschel (2021-05-06 11:24:09+00:00): Hallo,
diese payment Tags gibt es sonst nirgends. Bitte schau im Wiki nach üblichen Tags und benutze diese.

  payment:App = yes
  payment:Giro-e = yes
  payment:QR-Code = yes
BCNorwich (2021-05-09 08:31:21+00:00): Hi, I just wanted to point out that in the absence of a capacity tag on a parking space the capacity is implied as 1. Therefore the tag capacity=1 is not needed. Please see https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Regards Bernard.
lg188 (2021-05-10 16:55:17+00:00): Ah, I think that was the default when I added them, but i might have made a mistake along the way. I assume I have to correct it by removing the property?
BCNorwich (2021-05-10 17:21:28+00:00): Hi, Yes you're correct just remove those capacity=1 tags. No great problem I left them in so you could see what I meant. I can remove them if you wish.

Regards Bernard.
lg188 (2021-05-11 15:15:01+00:00): If you have the means to update all of them at same time, that would definitely be easier than doing it manually for me. Will take it in consideration for the future
BCNorwich (2021-05-11 15:59:19+00:00): Sure, 84 tags removed.

Regards Bernard.
lg188 (2021-05-21 14:41:22+00:00): Was checking the local issues  on OSM and now it says all of these are incomplete and need a capacity tag.
BCNorwich (2021-05-21 16:28:41+00:00): Hi, amenity=parking_space is singular, and therefore capacity is implied as singular (1).  You've also mapped amenity=parking to which a capacity could be added though it's not necessary, nor incorrect to omit. Indeed for a lot of car parks the individual spaces are not marked out, therefore capacity depends on how the vehicles are parked or their size.

Out of interest what or where tells you there are issues?

Regards Bernard.
lg188 (2021-05-21 16:33:51+00:00): When using the OSM iD editor, there is an issues "tab" (shortcut I) and when selecting Everyone instead of just my own edits, as a source. 

I'm not disagreeing with the logic, but I am getting mixed signals from the website and what makes sense.
BCNorwich (2021-05-21 17:30:20+00:00): Hi, in iD editor you have to click 'ignore this issue' it's OK. The website says the capacity tag is optional therefore not required. 

Regards Bernard
eggie (2021-05-02 12:49:54+00:00): Dag Haas. Je vraagt om feedback. Wanneer je gebied opeens zo groot is heb je waarschijnlijk je pad geplakt aan een grens. In dit geval de landuse=residential van Katwijk. 
bicycle=yes hoeft niet op een fietspad net als oneway=no

MVG
eggie
eggie (2021-05-02 12:53:33+00:00): Verder loopt je fietspad dwars over een sportveld? Ik vraag me af of dit traject echt zo loopt.
Haas16 (2021-05-02 12:58:05+00:00): Dit is een nieuw fietspad, opgenomen met GPS. Dus niet zo nauwkeurig. Wacht op een nieuwe luchtfoto om het pad beter te kunnen intekenen
eggie (2021-05-02 13:01:00+00:00): Heet fietspad heb ik van het sportveld gehaald en ietsje naar het zuiden gelegd conform de BGT
MVG
eggie
eggie (2021-05-02 13:30:49+00:00): Haas wellicht heb je hier iets aan
https://satellietdataportaal.nl/

Wanneer je kies voor superview en dan klikt op het kleine zwarte blokje links in de kantlijn dan kun je een vak opentrekken en dan krijg je onderin vertikale strepen en kun je kiezen voor de sat foto van apri 2021
Ik heb het conform sat april 2021 iets beter gelegd.
gr eggie
Haas16 (2021-05-02 13:39:33+00:00): bedankt voor de info.
Johan
eggie (2021-05-02 13:51:11+00:00): Johan.. Volgens de BGT omtrekgericht heet het fietspad Rijwielpad Vlaggeduin..
Nou heeft de BGT het wel eens meer mis. Wellicht nog uitzoeken. Het wandelpad met de wandelroutes heb ik ook omgelegd over het nieuwe traject aan de noordzijde van het fietspad  en een fietspad toegevoegd vanuit Meeuwenlaan (Noord zuid).. Althans ziet het er uit op de laatste satfoto
Up to you!
eggie
Haas16 (2021-05-02 13:55:47+00:00): Wat is BGT?
Zal naam nog checken.
Johan
eggie (2021-05-02 15:11:43+00:00): Baisregistratie Grootschalige Topografie
https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/basisregistraties-en-stelselafspraken/inhoud-basisregistraties/bgt/

Ik zet bv de transparant van de BGT omtrekgericht op de achtergrond. In edotor JOSM gaat dat het simpelst.
Wat leesvoer.. even rijstebrij in het begin, maar als je vragen hebt stel ze gerust.. 

editor josm stap voor stap 

https://forum.openstreetmap.org/viewtopic.php?id=53710        

 

BGT implementeren  

https://forum.openstreetmap.org/viewtopic.php?id=59021 

Forumdraadje ..  De beste imagery layers om NL OSM te mappen met JOSM. 

https://forum.openstreetmap.org/viewtopic.php?id=64644 

Hier kun je zien hoe je de .jos file kunt gebruiken binnen JOSM.  
https://youtu.be/33EenoZezWg 

Dan gaat er nog een werled voor je open.

Mapse
Eggie


MVG
eggie
SomeoneElse (2021-05-02 11:28:37+00:00): More of "Foss Way near Crayke, from survey "
tastenmensch (2021-10-26 09:18:48+00:00): Seit wann heißt dieser Platz Breitscheidplatz? Wieso kann man das nicht einfach so lassen wie es war, denn es war gut so....1000 Änderungen für nichts und dann seit nem halben Jahr noch falsche Namen.
Rogoyski (2021-06-16 18:21:51+00:00): What way did you come up with the locations of individual trees?
hesdrib (2021-05-02 14:06:56+00:00): Bonjour

Il y a des noms de rue à Bovigny, maintenant ?
Bert Araali (2021-05-03 18:02:27+00:00): Reverted because of deletions of urban trees, not justified.  Most changes recovered like correct use of wikipedia tag. Squared some buildings and resolved overlaps with landuse.
Jean-Marc Liotier (2021-05-03 21:35:44+00:00): Take a look at the Osmose "tree intersects with building" - there are quite a few in Kampala. Also, so many false trees that I usually filter them out and don't even bother.
Bert Araali (2021-05-03 22:15:38+00:00): Might be, so what is the problem moving the tree instead of deleting it.  If it's cut then its very important to know because these are large trees and a stub or the roots might still be there, and will remain there for the next 50 years as we have many hardwood trees, in many cases protected by species., something you can't determine from satellite imagery. Anyway, in this case I added them again, I didn't see the any problem with them, are navigational aids and very significant. So feel free to reference the revert, their is no problem with it.  I stopped using OSmose, the number of false warning their is so extensive that it's hardly usable, especially in areas like ours with again, limitd resources.  I use JOSM, try to solve every warning before uploading and it didn't have any problem with the trees. I also checked them visually before upload and there was nothing wrong with them, shown on all imagery. The reverted changeset is 104073665.
flohoff (2021-05-06 15:30:51+00:00): Moin,
guck dir den hier nochmal an:

highway=footway + foot=yes?

Kann es sein das du da einen path draus machen wolltest?

https://www.openstreetmap.org/way/862124051
czubi (2021-05-02 12:10:03+00:00): Was glaubst du was das ist ?
https://www.openstreetmap.org/node/8598605283#map=19/50.69602/10.83114&layers=N
Warum gibst du ihn nochmal ein?
JeroenHoek (2021-05-02 11:59:06+00:00): Dank je. De bordjes waren al eerder vervangen:

https://www.lc.nl/friesland/fryske_marren/Straatnaambordjes-Burgemeester-Krijgerplein-in-Lemmer-vervangen-door-Markt-26472065.html

De naamswijziging is verder officieel per 1 mei.
coachbob (2021-05-12 16:58:43+00:00): I don't think that adding an access=permissive tag was correct here. The access restriction refers to (according to the wiki page) only legal restrictions. Hence, I'd say that access=yes would be more approbriate. Web applications like e.g. kurviger.de think, that the B 307 is blocked for traffic.
CreCrePL (2021-05-13 13:19:40+00:00): access=permissive removed from said sections.
flohoff (2021-05-06 15:29:10+00:00): Moin,
wie kommt es zu diesem weg? öffentliche straße - also highway=unclassified aber dann ein access=private? Ist das dann nicht vielleicht eher eine private service road?

https://www.openstreetmap.org/way/938039977
flohoff (2021-05-06 15:31:57+00:00): Den hier verstehe ich auch nicht - Wieso bicycle=yes auf einer residential - Das ist doch default oder?

https://www.openstreetmap.org/way/22899573
bus-mt (2021-05-06 15:39:30+00:00): Hallo Flo,
beim ersten hab ich vergessen, das in service zu ändern - ist korrigiert. Der zweite hat ein vehicle=destination, das würde Radfahrer ausschließen (beschildert ist 250 mit Anlieger+Fahrrad frei).
Grüße
Matthias
flohoff (2021-05-06 15:52:25+00:00): 
Ah cool - Jetzt sehe ich es aus - Manchmal stehe ich ja auch auf dem Schlauch. Hatte nur gerade mal wieder Fehlerlisten durchgeklickt :)

Flo
Spaghetti Monster🍝 (2022-04-25 05:44:01+00:00): Ways should not split before there is physical separation.
ChaireMobiliteKaligrafy (2022-04-25 11:00:28+00:00): We decided to split the motorway links at the beginning or end of the dashed line merging area in the Quebec province for better representation for autonomous vehicles and routing, which will be needed soon. We use the placement=transition with width:lanes instead, so it is more realistic. We will create a wiki page soon to explain the rationale for this.
ChaireMobiliteKaligrafy (2022-04-25 11:01:59+00:00): The main problem with merging as soon as the physical separation ends is that more and more routing engines calculates penalties for trucks and buses according to the angle of the road, so these creates artificial angles that add non-existing penalties. Thanks!
rab (2022-04-30 20:58:24+00:00): You ignore our wiki, don't you?
ChaireMobiliteKaligrafy (2022-04-30 22:27:41+00:00): Can you be more specific please?
rab (2022-05-01 09:23:45+00:00): in first place to tweak the data for specific  routing engines for specific vehicles

https://wiki.openstreetmap.org/wiki/Lanes

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

vs

https://www.openstreetmap.org/node/188872028

http://osm.mueschelsoft.de/destinationsign/example/index.htm#way=23911027&namedroutes=1&fromarrow=0&include_sgn=0&include_way=1&country=

http://osm.mueschelsoft.de/destinationsign/example/index.htm#way=947462621&namedroutes=1&fromarrow=0&include_sgn=0&include_way=1&country=SR

no lane assistance here?

what angle would be acceptable for your routing engine?
ChaireMobiliteKaligrafy (2022-05-01 11:05:02+00:00): The goal here is to make the representation of lanes to be as realistic as possible. The main problem we have with usual merging angles is that they are in an angle that no vehicle will follow on the ground and makes it difficult for upcoming automated vehicle to have a good understanding of the real merging distances (I'm a transportation engineer and I teach vehicle automation and I know this is becoming a problem). Also, connecting the exit and enter lanes makes it obvious that there is no segment on which the vehicle can travel in transit between the entering and exit segments. We instead use precise placement=transition with width:lanes:start and width:lanes:end tags, so we are following the wiki for these tags correctly. I don't see how it does not fit the actual wiki for the merging lanes anyway, since it is just a matter of angles, which are not specified in the wiki. The distance between the real physical separation and the merging connection is not explained or precised in the wiki, so we just make the angle smaller to enhance the realism of the lanes on the ground. We want to use the real angle that is followed by vehicles when travelling in these merging lanes. We are currently builing a wiki for Quebec to explain the rationales for this and will publish it soon. I am pretty sure it will become useful for a lot of coutries in the next years anyway, since the vehicle automation softwares will need more realistic representation of the lanes and merging segments in the near future, if we want them to use openstreetmap data instead of private closed data. And this is one of the discussions the automation software companies and car manufacturers are having righ now.
ZeLonewolf (2022-05-02 23:07:09+00:00): I don't understand the rationale here.  There is specific tagging for lanes that's perfectly capable of supporting autonomous vehicles or navigation software.
Spaghetti Monster🍝 (2022-05-02 23:23:24+00:00): A 6 lane highway doesn't have 6 ways to "match reality".
Having used autonomous software for the past 8 months I can say with certainty that less ways is almost always better where no physical separation exists.
Also there is:
https://wiki.openstreetmap.org/wiki/Key:lanes
https://wiki.openstreetmap.org/wiki/Key:turn
ChaireMobiliteKaligrafy (2022-05-03 00:09:00+00:00): HI! Thanks for your input on this. The problem with the actual wiki is that the merging angle is at the discretion of the user editing the data. My method is systematic and always works, and also follow the real movement of the vehicles using the merging: just start the merging as soon as the continuous lane changes to dashed line and connect it as soon as the dashed line finishes. In this exact case, just in the middle when the dashed lines continues into the next split. See this image: https://ibb.co/bJGdFpX, can you tell me which white line (which angle) would be suitable for the merging here?
ChaireMobiliteKaligrafy (2022-05-03 00:13:10+00:00): See this image instead: https://ibb.co/VYwzs6c
ChaireMobiliteKaligrafy (2022-05-03 00:20:43+00:00): Also there is the problem of snow here in Quebec, so if you merge using a sharp angle segment cutting the continuous lines which should not be crossed before the dashed lines the lines may not be visible at all and there could be 3 feet of snow over these lines, so having a merging segment that follow the real path could be safer, isn't it?
ZeLonewolf (2022-05-03 01:38:47+00:00): It is customary to map what is on the ground in OSM, in accordance with global conventions on how to map.  And that convention is not to draw separate ways for road sections that are separated only by painted lines.  If highway ramps are mapped differently in Quebec, that would make navigation software work differently in Quebec than it does in the rest of the world, which is quite undesirable for a global project.

The amount of snowfall in Quebec is quite irrelevant.
Spaghetti Monster🍝 (2022-05-03 01:40:51+00:00): It should merge at the bridge since that's where the ways connect irl.
The lane tags and associated tags solve all issues you've brought up here such as the fact that the on ramp lane and off ramp lane are continuous. 
Having the autonomous software think that the exit starts on the bridge is definitely not the right approach.
Spaghetti Monster🍝 (2022-05-03 01:42:35+00:00): Exit separation*
ChaireMobiliteKaligrafy (2022-05-03 10:13:08+00:00): I moved the merging nodes to the bridge boundaries for now, as you suggest, until we can discuss the issue in detail for the rest of the Montreal motorway network.
Mateusz Konieczny (2022-05-03 12:15:58+00:00): >  for better representation for autonomous vehicles and routing

introducing incorrect data to aid specific data consumer is not acceptable and should be reverted, see https://wiki.openstreetmap.org/w/index.php?title=Incorrect_tagging_for_the_renderer
Mateusz Konieczny (2022-05-03 12:18:31+00:00): > See this image: https://ibb.co/bJGdFpX, can you tell me which white line (which angle) would be suitable for the merging here?
> See this image instead: https://ibb.co/VYwzs6c

two rightside one are clearly invalid and it breaks geometry

mapping presented on that image is also wrong and as explained by you is a case of blatant tagging for renderer
Mateusz Konieczny (2022-05-03 12:23:35+00:00): data partially unbroken in https://www.openstreetmap.org/changeset/120497870
Mateusz Konieczny (2022-05-03 12:24:49+00:00): are there any similarly broken junctions? how widely this editing was applied?

@ChaireMobiliteKaligrafy Has anyone ordered you to make this edits or paid for them? If yes, note https://wiki.openstreetmap.org/wiki/Organised_Editing_Guidelines
Mateusz Konieczny (2022-05-03 12:32:56+00:00): next fixing lanes incorrectly mapped as a separate carriageways in this area is in https://www.openstreetmap.org/changeset/120498153

I have not checked other nearby junctions whether data is broken also there
Mateusz Konieczny (2022-05-03 12:36:38+00:00): > The problem with the actual wiki is that the merging angle is at the discretion of the user editing the data. My method is systematic and always works, and also follow the real movement of the vehicles using the merging: just start the merging as soon as the continuous lane changes to dashed line and connect it as soon as the dashed line finishes.

yes, existing method has a bit of subjectivity and is not ideal for your desired use of OSM data

but it is more or less standard (though it is not rigidly followed in some cases, which do not apply here)

Though your method has the same "not always the same angle" problem and has fundamental issue of redefining widely used method.

OSM tagging has many silly parts, but  unilaterally redefining how things are done and expecting others that they will be obedient is not helpful at all
ChaireMobiliteKaligrafy (2022-05-03 12:51:08+00:00): The tagging scheme we used is not for rendering purposes, but for a better representation of the movement of vehicles on the roads. And also to reduce artificial angles in the roads, since more precise simulations need to be able to penalize turning radii and angles correctly. I have no problem reducing the merging segment lengths, but there must be a precise way of choosing the right distance.
ChaireMobiliteKaligrafy (2022-05-03 13:01:19+00:00): > Though your method has the same "not always the same angle" problem and has fundamental issue of redefining widely used method.

Our method place the merging node at the end of the dashed merging lines, always. And it was used for the whole motorway network of the Montreal region for almost 2 years now. This is just now that we get objections about this mapping choice. The local community did not object this. But I am 100% for a better international consensus here, so I will try to find a better way to do things so we can both be happy with the results. However, I still think that putting artificial angles (angles which vehicles would not follow) in the roads and crossing continuous lines with highway merging segments is questionnable (and that has no relation with mapping for the renderer, it is more "mapping for realistic vehicles movements"). I understand that we should not have more than one way for road with no physical separation, but the exact location of the merging node should be clarified in the wikis and the end of the dashed line is applicable 95% of the time and is systematic, at the cost of having longer merging segments. I did apply the wiki and also added precise placement=transition with width:lanes tags (this work is not done yet, because time consuming), which was explained to me by accute german editors before I started to map the area. I am a bit suprised to get your comments now but I really wish we both can come to a satisfaction.
ZeLonewolf (2022-05-03 13:06:24+00:00): If you're looking to establish an international consensus, it would be best to clearly describe the issue you're trying to solve, how you propose to address it, and post it to the global tagging mailing list: https://lists.openstreetmap.org/listinfo/tagging

Mateusz, Spaghetti, and I are not the ones you need to form a consensus with. What we are describing and defending here is simply the current global status quo.
ChaireMobiliteKaligrafy (2022-05-03 13:56:57+00:00): See https://wiki.openstreetmap.org/wiki/Proposed_features/Add_a_systhematic_location_to_put_the_merging_node_when_merging_exit_ramps_on_motorways_or_other_highways
Mateusz Konieczny (2022-05-03 14:57:29+00:00): > The tagging scheme we used is not for rendering purposes, but for a better representation of the movement of vehicles on the roads.

This phrase has "rendering" in the title as it is the most common issue, but applies also to all other intentional misrepresenting data to achieve better effects for a specific data consumer.

It would cover also mapping fake separate carriageways.
Mateusz Konieczny (2022-05-03 14:58:45+00:00): > See https://wiki.openstreetmap.org/wiki/Proposed_features/Add_a_systhematic_location_to_put_the_merging_node_when_merging_exit_ramps_on_motorways_or_other_highways

Thanks! That is a good opportunity to discuss it and improve existing documentation.

I fully agree with "There should be a systematic location for the merging node" though I strongly disagree with mapping separate carriageways where separate carriageway does not exist.
ChaireMobiliteKaligrafy (2025-02-28 15:56:09+00:00): As a follow-up, we now follow the official wiki on https://wiki.openstreetmap.org/wiki/Tag:placement%3Dtransition and proposal in https://wiki.openstreetmap.org/wiki/Proposal:Placement

So we always join at the end of the theoretical gore. Thanks for flagging this!
aixbrick (2021-05-02 19:26:30+00:00): Hallo,
hast du Vor-Ort-Kenntnisse? Auf Lutfbildern scheint der Weg auch als Zufahrt zu den Feldern zu dienen, was hw=track implizieren würde (daher die Frage im Fixme). Wenn der Weg tatsächlich ein Rad-und Fußweg ist, war hw=path korrekt.
Gruß
LukR (2021-05-02 20:16:09+00:00): Moin,
Ich bin dort letzte Woche lang gefahren. Es ist ein sperat asphaltierter Weg zur L233. Es ist ausgewiesen als Radweg im Wegenetz. Ob es nun auch als Zufahrt zu den Feldern genutzt wird, kann ich nicht sagen.
Die Luftbilder sind aus einer Zeit bevor der Weg fertig gestellt wurde. 
Gruß
aixbrick (2021-05-03 06:06:06+00:00): Danke für deine Rückmeldung. Die PDOK-Luftbilder der Niederländer sind aktuell (letztes Jahr). Für OSM ist die Beschilderung wichtig: Steht dort ein VZ 240 oder ein VZ 260 jeweils mit oder ohne Freigabe für landwirtschaftlichen Verkehr? Oder eine ganz andere Kombination? Die gesamte bauliche Gestaltung deutet darauf hin, dass es nicht nur ein Rad-/Fußweg ist.