piebro/osm-data huggingface dataset:
StC (2024-01-18 18:27:54+00:00): Concernant les décalages, dans la zone des Civières j'avais eu la chance d'y aller au printemps et de voir en même temps les pistes de ski et les pistes forestières, c'est assez difficile à reconstituer à partir des orthophotos seules ou des plans des pistes. Je ne me fierais pas trop au GPS, dans cette zone forestière.

Concernant les relations c'est une zone de réseau de carrefours, donc les relations sont assez nombreuses. Nous utilisons l'outil Knooppuntnet pour détecter les erreurs, et ce qui m'a attiré là est la relation Les Echallées - Les Civières (https://knooppuntnet.nl/fr/analysis/route/12434635) mais cela vaudrait le coup de regarder plus généralement toutes les relations avec "network=lwn" lors des modifications. Voir https://knooppuntnet.nl/fr/analysis/network/12409335 pour une vue d'ensemble.

Un groupe de contributeurs "plein air" (rando, ski, vélo, etc) se retrouve sur le canal Telegram OSM Plein Air et tente d'assurer le suivi des itinéraires, nous serons ravis d'apporter plus d'aide si utile.

À bientôt,

St.
RobMazc (2024-01-24 00:37:41+00:00): Bonsoir,

Mes excuses j'ai raté votre réponse jusqu'à aujourd'hui. Les données GPS sont assez constantes, elles viennent directement des dameuses, avec un facteur de vérification important puisqu'on a des nombreux enregistrements depuis le début de saison. 

Merci d'avoir d'avoir attiré mon attention sur les relations network=lwn ainsi que sur l'outil knoopuntnet, très utile ! Je vais m'assurer de bien vérifier le suivi d'itinéraire pédestre / plein air lors d'éventuelles modifications liées au ski de fond. 

À bientôt,
Rob
StC (2024-01-24 09:37:02+00:00): Bonjour,

et merci pour votre intérêt concernant la continuité des itinéraires pédestres. C'est important de nous assurer que les contributions d'une pratique sportive ne viennent pas casser celles de l'autre (et réciproquement, d'autant que dans ces régions ce sont souvent les mêmes personnes qui pratiquent les deux)

Concernant les traces GPS, je pense que nous avons un vrai problème à traiter : celui de sources contradictoires entre l'été et l'hiver, et du choix de mutualiser ou pas les ways entre ces deux périodes. Il me semble qu'il y a des endroits où la mutualisation s'impose (chemin encaissé ou bordé d'arbres) et dans ces cas là je proposerais que ce soit l'été qui l'emporte (car le chemin d'été est plus précis que celui d'hiver, grâce en particulier aux orthophotos). Et puis il y a des endroits où il n'y a pas de sens à la mutualisation, et alors il faudrait clairement distinguer les deux ways. Mais c'est tout un débat à avoir, peut-être pourrions-nous ouvrir un sujet sur le forum pour cela ?

A bientôt,
St.
pyrog (2024-01-30 18:31:07+00:00): Je confirme, les traces GPS en forêt et/ou en montagne sont un vrai problème.

Les récepteurs bi-fréquences en cinématique temps réel (RTK) sont plus appropriés et commencent à être abordables.

Cf. https://centipede.fr/
Fizzie-DWG (2023-11-13 06:46:15+00:00): Please see https://www.openstreetmap.org/user_blocks/15374
Matt_ (2023-11-13 04:59:24+00:00): Please see: https://wiki.openstreetmap.org/wiki/US_National_Inventory_of_Dams
Matt_ (2023-11-28 18:35:14+00:00): Also: https://maproulette.org/browse/challenges/42285
tastrax (2023-11-13 06:25:04+00:00): Is this actually a tree row or a path to somewhere?
rodbissett (2023-11-13 08:55:57+00:00): It is public land that appears to be private as it is well maintained by adjacent landowners. There is no definitive path so I did not know how to describe it, feel free to correct.
tastrax (2023-11-15 00:02:10+00:00): No worries - I have taken out the tree row and adjusted the residential boundary to better reflect the block titles (from the LIST Background layer). I have also extended the vegetated area.
Natfoot (2023-12-03 23:04:10+00:00): Belbay is a reference to the location between the S bay trail which is an old railroad line and what was once the Great Northern Railroad.  Unfortunately, Google doesn't allow us to use their imagery, even for validation.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143955859
Miles R (2023-12-03 23:28:56+00:00): Hi! I'm not the only one to have brought up issues with Belbay, there is a comment on the changeset that added it with another confused user. https://www.openstreetmap.org/changeset/63363399
I live nearby, and if you can point me to a physical location I can visit and see if there is any reference to Belbay, I'd be happy to stop by.
dcapillae (2023-11-13 05:20:42+00:00): También se han añadido algunos bancos para sentarse.
MxxCon (2023-11-15 01:02:46+00:00): Hello.
This lane count doesn't appear to be accurate. Satellite imagery shows that it's 2 lanes in one direction and 1 in the other, so should be 3, not 2.
Could you please elaborate on why did you put 2?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143956345
mrmhack (2023-11-15 01:12:50+00:00): Yeah that was a mistake on my part. Should be 3 lanes for that section of the road.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143956345
Vinber-Pro (2024-01-17 08:50:20+00:00): bonjour,
tu as ajouté la mairie comme office=government, il me semble plus "approprié" que cela soit amenity=townhall (https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dtownhall).

ton avis ?

bonne carto
clay_c (2023-11-15 01:45:00+00:00): Are the roads within parks really considered toll roads? Typically we use toll=yes if you have to pay each time you pass through the booth, and fee=yes if you purchase a duration-based permit to enter.
SD Mapman (2023-11-15 07:11:42+00:00): Good to know, I'll get that updated. Someone had added the toll=yes tag to just the Devils Tower entry booth area so I just... extended it.
Mateusz Konieczny (2023-11-13 08:15:17+00:00): Thanks for review and checking!
Warin61 (2023-11-19 01:50:18+00:00): Hi
This adds a house number but without a street name. Without the street name it may make 'navigation' difficult.
BushTel (2023-11-21 00:18:13+00:00): Thanks for the feedback but unfortunately Warruwi doesn't have any street names.
Warin61 (2023-11-21 07:12:43+00:00): The is this really a 'house number' or is it a 'lot number'? Might be better to use addr:full?
Kovoschiz (2023-11-13 10:10:21+00:00): Please don't add not yet opened features directly.
Tommybara (2023-12-22 08:39:13+00:00): Cái này là vẽ sai rồi bạn nhé. Dự án cầu Đại Ngãi điểm đầu tại xã Hùng Hòa, huyện Tiểu Cần; điểm cuối là xã Long Đức, huyện Long Phú. Còn dự án làm mới QL 60 đi thẳng từ Càng Long đến đường dẫn cầu Đại Ngãi thì chưa có kế hoạch nên cũng chưa biết hướng tuyến.
MxxCon (2023-11-15 01:17:25+00:00): This is not a correct way to map traffic lights.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/143957116
MxxCon (2023-11-15 01:21:22+00:00): Please see https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#How_to_map on how to correctly map and position traffics lights.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/143957116
pachpora (2023-11-16 13:07:34+00:00): Hi,
Thank you for reviewing the edit and making the corrections. These changes were done by the editors in accordance with our internal SOP. We apologize for the incorrect edits flown into OSM from our end.
We are re-examine all of the changesets in which the team has updated traffic signal/stop sign attributes, and rectify them by 11/16. We will also work on updating the SOP to be followed while adding these attributes on public OSM which align with the community guidelines/OSM wiki.
Thanks,
pachpora
Zandu (2023-11-15 05:11:10+00:00): This was a huge modification of my early learning and many duplicate ways.  This change created relations from ways to reuse the single way methodology.  Primary tags were moved to relations.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143957167
pantufla (2023-11-13 07:53:15+00:00): gracias, error de tipeo! :D
Ahmadalhajahmad (2023-11-14 07:15:01+00:00):  ميدان الحاج أحمد
ftcat (2023-11-13 07:18:48+00:00): Revert bad mass import changeset 143955349. Data imported included non existent amenities such as amenity= health post - rural as well as being tagged with population figures . Many data points were clustered in small areas with different names and different district addresses which is not possible.
eggie (2023-11-13 08:06:15+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

MVG, 

Eggie 

Namens de OSM Community
eggie (2023-11-13 08:14:00+00:00): Dag YanniX  Je kunt hier
https://bagviewer.kadaster.nl/lvbag/bag-viewer/?searchQuery=pannenberg&objectId=0917100000008143&theme=BRT+Achtergrond&geometry.x=192717.41999999998&geometry.y=325828.989&zoomlevel=15&bijbehorendeAdressen=Pand

een terugmelding doen naar het Kadaster met de mededeling dat de vorm niet klopt, wantmet een periodieke update komt de verkeerde vorm gewoon weer terug in OSM.

MVG
eggie
YanniX92 (2023-11-13 08:40:46+00:00): Dag Eggie,

Bedankt en duidelijk. Het leek me al te makkelijk om dat zo aan te passen. Deze appartementen zijn een tijd geleden gerenoveerd met voor een deel ervan nieuwe ingangen aan de andere kant (driehoekjes).
Timmy_Tesseract (2023-12-09 10:17:15+00:00): Hello Danny. Thanks for mapping so many street names in Mauban. 

For place names like the one added in this changeset you can add a place=neighbourhood/quarter/village node instead of mapping it as a street name. 

Did it already for Sitio 6: https://www.openstreetmap.org/node/11405052187

PS: Please also make sure to always add the complete street names, no abbreviations and capital letters at the beginning of words ;)
Kovoschiz (2023-11-13 10:10:51+00:00): Please don't add descriptor labels. `name=` is for proper names only.
Mateusz Konieczny (2023-11-13 08:13:57+00:00): Per https://www.openstreetmap.org/note/3892774. it sounds rather like https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfarm

I changed it to shop=farm, feel free to change back
impiaaa (2023-11-13 17:18:08+00:00): Way 1223146051 is incorrect. Only physically separate roads can be separate ways. Lanes, connectivity, and turn restrictions should use their appropriate relation types.
Black_Diamond (2023-11-13 17:58:17+00:00): While that is true, I couldn't find a restriction that could leave the left turn lanes alone on Stevens Creek. The only restriction is that you can't have a vehicle go from North Tantau to South Tantau. The bicycle route goes both ways. You can turn left and right from Stevens Creek on to South Tantau. There is also an island blocking this only  vehicle route from north to south Tantau. All other routes are unblocked.

Also you don't go through 2 traffic signals when going between north and south. So those were moved to their respective streets at the stop line.

If you have a more specific suggestion on how to model this very specific restriction, I'd appreciate to know a different solution.
impiaaa (2023-11-13 18:18:37+00:00): Turn restriction relations can restrict going straight through an intersection, and can restrict specific types of vehicle: https://wiki.openstreetmap.org/wiki/Relation:restriction

If the tags on a node in a way only apply to one side or one direction, that can be indicated with a suffix on the key: https://wiki.openstreetmap.org/wiki/Forward_%26_backward,_left_%26_right

Mapping traffic signals at the way intersections is valid: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
Black_Diamond (2023-11-13 18:40:27+00:00): How do you apply the restriction on a path through 2 nodes instead of a single node? The only alternative that I could think was to merge both Stevens Creek connections on Tantau into a single point, but that makes the route no longer follow the flow of traffic. The current paths do model the flow of traffic.
impiaaa (2023-11-13 19:13:44+00:00): The restriction relation page has examples of how to use the "via" member role: https://wiki.openstreetmap.org/wiki/Relation:restriction#Members
Black_Diamond (2023-11-13 21:36:03+00:00): So apparently in the editor, here is what I had to do:
1) Select all relevant nodes and lines. You will have to use the shift key when selecting them.
2) Select "add to a relation".
3) Sort all nodes and lines from start to finish. A member may be included more than once, and those should be deleted.
4) Add member type "from", all of the "via" in the middle, and a final "to" to all of the members.

I didn't know that I could do #1, since it was only allowing me to select 3 members by default. This intersection has been updated accordingly.
impiaaa (2023-11-14 05:57:37+00:00): Thanks!
Minh Nguyen (2023-11-15 09:31:00+00:00): Regarding the traffic signals: I’ve also been moving traffic signals to the stopline lately. This is a reversal from what I had previously done. Both styles are valid, and both come with tradeoffs for renderers and routers. But this area has so many unusual intersections where only the stopline style can accurately describe the traffic control on each inbound way, so I figured it’s better to be consistent.

One downside of the stopline style is that many intersections around here have staggered stop lines, so the highway=traffic_signals node is actually at an arbitrary location. I’ve been using road_marking=stop_line road_marking:stroke=solid ways to clarify that situation, at least to mappers; no software recognizes them yet.
jeslop (2023-11-13 09:06:48+00:00): You are marking as finished sections of road that are not really finished. Please let the local communities do this work as they are the ones with the knowledge on the ground. Many of the sections you have changed do not appear on Bing or any other map as completed.

Jesús López
OpenStreetMap Foundation
Data Working Group
YellowSoul (2023-11-13 09:48:47+00:00): Hi, I'm mostly trying to remove inconsistencies such as highway=construction tags that do not have a matching construction tag and instead just a proposed tag. Feel free to revert my changes.
bxl-forever (2023-11-13 11:00:28+00:00): Hello,

Sorry but I had to revert this.

Adding an ATM is fine.
Fixing the geometry of about 100 buildings is different, especially here because those geometries are the official UrbIS reference (provided by the authorities which offer them under a compatible licence).  Some buildings in this area have a fuzzy shape, that is true, but that was not a mistake, this is really how they look.

Have a nice day.
pootriarch (2023-11-13 08:26:24+00:00): this will eventually be a large undertaking. south los robles lacks the 'south' designator; i'm not clear on whether it stops being called 'south' at some point. i renamed only two blocks that can be confirmed from business websites
eggie (2023-11-13 08:48:22+00:00): Welkom bij OSM,

Wanneer het niet een bedrijf met een bezoekadres betreft hoort deze vermelding niet in OSM thuis.
https://wiki.openstreetmap.org/wiki/NL:Good_practice

..
https://wiki.openstreetmap.org/wiki/NL:Verifiability


MVG
eggie
SatsVault (2023-11-13 09:10:41+00:00): Klanten kunnen op afspraak producten afhalen op dit adres. Bij de KVK is dit adres vermeldt als bezoekadres.

Op basis hiervan zou het volgens mijn in aanmerking moeten komen als een bedrijf met bezoekadres.

Bedankt, Wenze
eggie (2023-11-13 09:17:11+00:00): Beste Wenze,

Wanneer er een bezoekadres is dan ook een officetag toevoegen.
Je ziet anders geen naam in OSM.
Bv office=company
Probeer ook bij te taggen op de bestaande adresnode.
Blijft het bezwaar dat iets verifieerbaar 'moet' zijn. Bv een bord op de gevel. Vermelding KvK is niet genoeg.

MVG
eggie
eggie (2023-11-13 11:59:31+00:00): Bedrijf voorlopig verwijderd
SekeRob (2023-11-13 09:33:35+00:00): As per the note, https://www.openstreetmap.org/relation/285964 should be relatively easy to split since large zones have hardly any 'inner' objects such as the NE branch.
osmviborg (2023-11-13 08:59:54+00:00): Hænger ikke sammen
maxspeed=30
maxspeed:type=DK:urban
kortgodt (2023-11-13 09:34:30+00:00): Så må vi have slettet maxspeed:type=dk:urban
kortgodt (2023-11-13 09:35:30+00:00): True ligger i 30 km/t zone
osmviborg (2023-11-13 10:36:08+00:00): maxspeed=50
maxspeed:advisory=30
kortgodt (2023-11-13 14:46:01+00:00): det er maxspeed 30!!!
osmviborg (2023-11-13 15:00:26+00:00): https://fdm.dk/nyheder/trafik/2016-02-disse-vejskilte-forstaar-vi-ikke
kortgodt (2023-11-13 15:02:09+00:00): Det er maxspeed 30!!! Jeg kan godt læse en færdselstavle.
osmviborg (2023-11-13 15:05:14+00:00): Så er det maxspeed:type=sign
SpinOff (2023-11-16 22:26:19+00:00): Żeby zmienić nawierzchnię wystarczy edytować tagi na już istniejącej linii. Ty narysowałeś nową linię idealnie na starej przez co się zdublowały. Poprawiłem już mapę.
habi (2023-11-13 14:22:05+00:00): Ciao Pirmin

Willkommen bei OpenStreetMap, schön hilfst du hier mit die Kartendaten zu pflegen.
Ich habe die noch bestehenden Migros-Eigenschaften entfernt und die von dir eingegebenen Öffnungszeiten maschinenlesbar gemacht.
E Gruess us Bärn,
habi
Patchanka (2023-12-08 20:06:08+00:00): coucou @EvaMap40
Tu as rajouté plein de noms sur les bâtiments, mais cela correspond au nom d'entreprise. Il faut donc impérativement indiquer un tag lié à cette activité, a minima office=compagny (pour dire que c'est une entreprise "lambda") et voir le wiki pour plus de détail. Ça peut aussi être des magasins shop=*, des artisans craft=*
Pour l'ESAT, ce n'est pas une entreprise mais un équipement social, il y a un tag pour cela aussi !
Je vais faire quelques corrections (n'hésite pas à les modifier si besoin).
bonne soirée :-)
Warin61 (2026-02-06 07:11:18+00:00): Hi,
Multipoygon relation 16692138 track is not correct!
Rule 1: outer ways cannot share segments. 
Secondly .. what is being mapped and an 'outer' - the outside of the track and an 'inner' the inside of the track. It should be 2 ways - not toughing the outside should have the role 'outer' and the inside way should have the role 'inner'. 
More? Read https://wiki.openstreetmap.org/wiki/Relation:multipolygon

A simpler method is the have a single way - this does not map the track width.
Warin61 (2026-02-11 02:08:34+00:00): No communication.
mgerken (2023-11-15 23:25:13+00:00): Moin,

danke für die Änderung! Bei den Öffnungszeiten steht 089:00 morgens als Öffnung, das wird ja nicht stimmen. Ich würde jetzt auf 9 Uhr tippen, aber das wissen sie sicherlich zuverlässiger.

Beste Grüße
NorthCrab_upload (2023-11-13 09:40:28+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy.
https://www.openstreetmap.org/node/2984897045
https://www.openstreetmap.org/way/548190506

Pozdrawiam! 🦀
eggie (2023-11-13 09:44:16+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 
Feedback....  Alle begin is moeilijk. Je hebt de weg die je hebt verplaatst geplakt op een andere weg. We noemen dart duplicated ways.  Dat routeert niet van harte.

MVG, 
Je edits https://overpass-api.de/achavi/?changeset=143962100
Eggie 

Namens de OSM Community
eggie (2023-11-13 09:56:28+00:00): De opgeplakte wegen heb ik verwijderd.
MVG
eggie
Nielkrokodil (2023-12-28 13:25:50+00:00): Hallo SKald! 
Achtung bei Kreisverkehren! Hier hast du viele Bus-Relationen zerstört. 
Kannst du das korrigieren? 
LG Nielkrokodil
SKald (2023-12-28 14:54:36+00:00): Ich vermute du meinst den Kreisverkehr mit dem Dürer-Hasen...

Normalerweise passe ich schon auf, dass keine Relationen kaputtgehen :), resp. schau, dass die Relationen, die dann über das eingefügte Teil vom Kreisverkehr gehen auch die sind die vorher drüber gegangen sind. Das hab ich auch hier gemacht. 
Das Problem ist, dass einige Linien-Relationen schon vorher teilw. gegen die Einbahn vom Kreisverkehr angelegt waren. Man sieht bei Brunnerstr. und Raiffaisenstr. alle Routen-Relationen nur am jeweils nördlichen Ast, d.h. die sind schon mind ein Jahr kaputt.

Ich werde natürlich trotzdem versuchen das zu entwirren und zu richten.
Nielkrokodil (2023-12-28 15:08:44+00:00): Oh. Entschuldige bitte, dann habe ich nicht genau geschaut und dich zu unrecht beschuldigt, wenn das vorher schon kaputt war. Danke jedenfalls für Richten!
SKald (2023-12-28 20:11:09+00:00): Kein Problem. Hätte mir auch damals schon auffallen können. 

Das eigentliche Problem ist irgendwann beim Aufteilen der Fahrbahnen zum Kreisverkehr entstanden. Für die Bus-Linien hätte ich das mal hier und für den Kreisverkehr westlich davon repariert.
Baloo Uriza (2023-11-13 17:05:12+00:00): That's the name of the mall, which is already tagged; not the name of the parking aisles inside thr mall, none of which are named.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/143962299
MaryiaKuklis1111 (2023-11-14 07:04:04+00:00): Hey! Thanks for your message! Unfortunately, this edit was made in error. I'll be more careful in the future. Regards
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/143962299
gscscnd (2023-11-13 13:50:47+00:00): W podlinkowanym artykule jest mowa o otwarciu pobliskiego wiaduktu, otwartego w zestawie zmian:
https://www.openstreetmap.org/changeset/143859936

Ten most ZTCW jeszcze nie jest otwarty.
Tomek | Yanosik (2023-11-13 14:01:36+00:00): Dziękuję, poprawione.
Endres Pelka (2023-11-23 13:32:48+00:00): In this changeset, you moved the entire way 1169436681 (razed railway between Letanovce and Vydrník) 203 meters east. I'm fixing it now.
aleixstw (2023-11-13 11:05:34+00:00): Syncing issues from the app, apologise for the big area used.
Cucazer (2025-08-06 17:48:36+00:00): Hi,
I also don't get the motivation for the tag changes done by the previous changeset https://www.openstreetmap.org/changeset/112092128. According to https://wiki.openstreetmap.org/wiki/Lv:Latvian_tagging_guidelines, the P-roads should be highway=primary, exactly how this highway was tagged initially.
The reference code remains P66, so there wasn't any official highway category downgrade. So I think, it should be fixed back to highway=primary.
HellMap (2025-08-06 18:13:30+00:00): Hi,

While I personally don't know the situation here and was just fixing invalid values, I should note that A/P/V to trunk/primary/secondary is the recommendation and starting point, but it is not necessarily the final decision. OSM classification is based on function and logical road network, while A/P/V are just the codes used by LVC that happen to mostly match. But frequently in Latvia P and V roads are not actually used in real-life how classification would suggest - a lot of them were assigned historically and internally and LVC doesn't really make major changes to codes even when real-life situation changes. So someone with better local knowledge might retag them higher and lower to build a more logical hierarchical network for navigation. I have myself previously surveyed roads and retagged them seeing how in real-life the P/V/x values were old, outdated, rerouted, etc. If this P66 is a gravel/compacted road and in practice all people use P68, then I can see how this might actually be secondary or even tertiary compared to P68. Based on OSM road network principles, you generally want road classification to decrease as the roads branch away and people don't use it as the main way for travel/navigation. Anyway, I'm just noting that it's possible this to be secondary and P, but as I said I don't know the local situation. You would have to ask the original editor who adjusted it. I didn't want to change the classification here because I would just be guessing and it looked okay at a quick glance.