piebro/osm-data huggingface dataset:
ChaireMobiliteKaligrafy (2023-05-29 09:39:35+00:00): En fait, si les noms de rues ne sont pas ajoutés aux trottoirs, les indications pour un piéton seront très imprécises:
- Continuer tout droit
- Tourner à gaucher
- Tourner à droite
...
au lieu de:
- Continuer sur Rue Saint-Urbain
- Tourner à gauche sur Rue Mont-Royal
- Tourner à droite sur Rue Saint-Denis

ce qui est beaucoup plus clair, et semblable aux indications pour les voitures.

Quand les trottoirs ne sont pas dessinés séparément aux rues, ça va, mais quand les trottoirs sont dessinés séparément (ce qui est beaucoup plus courant de nos jours pour plus de précision), c'est nécessaire de nommer les trottoirs et pistes cyclables aussi. Le mieux serait d'avoir des relations qui lient les trottoirs aux rues, mais aucun standard n'a encore été proposé à ce sujet.
ivanbranco (2023-05-30 14:27:27+00:00): Hi 5R-MTF, thanks for the edit

something went wrong with this wikimedia_commons value: https://www.openstreetmap.org/node/10933401182/history
could you check it out?

p.s. also there's a second statue without other tags nearby, is it a duplicate?
ivanbranco (2023-05-30 14:29:40+00:00): This element also: https://www.openstreetmap.org/way/166917021/history

I tried to complete the link myself but it goes nowhere
https://commons.wikimedia.org/wiki/File:Wehrstrasse_19_M%C3%BChleberg.jpg
5R-MFT (2023-05-30 16:15:59+00:00): Hi,
both updated. First was mistake between Osmand App und Mapcomplete. Now looks good.

The second one didn't copy the link correctly. Already updated

Sorry
woodpeck (2023-06-09 13:57:56+00:00): What is the provenance of the "Geojson data file" mentioned in the sources?
zluuzki (2023-06-12 04:50:23+00:00): This is public domain HIFLD data which I use as reference.
save2desk (2023-06-05 17:57:09+00:00): Отменил удаление большей части троп.
Glassman (2023-05-28 16:03:16+00:00): I think those residential roads you added are all driveways. At least according to Skagit County iMap. https://www.skagitcounty.net/Maps/iMap
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136644264
Heptazane (2023-05-29 05:52:04+00:00): I'm not sure the county cares about private residential roads vs driveways.  My rule of thumb is to mark it as residential if it leads to multiple houses as it is usually a shared private road.  But if you know better, feel free to change.
gscholz (2023-05-29 06:39:30+00:00): Hi abdelrahman144,
your recent changesets have created several errors in the OSM database e.g. regarding self intersecting ways, wrong way types etc.:

https://tools.geofabrik.de/osmi/?view=geometry&lon=30.81568&lat=28.65003&zoom=13&baselayer=Geofabrik%20Standard&overlays=self_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way

Can you plese fix this?

May be you also like to educate yourself about meaningful changeset comments:

https://wiki.openstreetmap.org/wiki/Good_changeset_commen

Kind regards
Guido
nyampire (2023-05-31 08:56:58+00:00): OSMへようこそ。

編集ありがとうございます、が、すみません、OpenStreetMapは、GoogleMapsを始めとする、著作権などの権利が保護された地図からの情報利用は行うことができません。
利用が許諾された情報源を利用するか、あるいは自身で調査された内容を入力いただく必要があります。

今回入力された３つの変更セットについては、申し訳ありませんが、巻き戻しします。

利用可能なデータの例: https://wiki.openstreetmap.org/wiki/JA:Available_Data
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136645060
map per (2023-05-28 10:44:11+00:00): Wegen "Meine Änderungen überprüfen":
Sieht gut aus, danke!
watmildon (2023-05-30 23:05:35+00:00): Hello!

Can you help me understand why some of the features have been grouped into multi-polygon relations when I would expect the already existing tagged ways are preferable? For example this: https://www.openstreetmap.org/relation/15912391

In general, my experience is that grouping things like this just makes edits more cumbersome for other mappers and I don't see how these areas of scrub are logically "one feature".

There's also this relation that previously was a simple way https://www.openstreetmap.org/way/968226915 ... the benefit is unclear.

Any clarity you can provide is appreciated. 

Thanks!
tms13 (2023-06-04 18:23:20+00:00): The duplicated edges tend to fall out of sync when edited so that abutting areas end up overlapping or not quite meeting.  This particular area was highlighted by OSM Inspector due to touching rings, so I fixed up some of its duplicated boundaries whilest editing.
tms13 (2023-06-04 18:24:25+00:00): It's a judgement call whether the scrub is a single feature or not - feel free to separate into smaller relations if necessary.
watmildon (2023-06-04 21:27:22+00:00): Thanks for the reply. My general feeling is that having multi-polygons with only outer members (https://www.openstreetmap.org/relation/15912390) (https://www.openstreetmap.org/relation/13951181) achieves very little and makes it more difficult for other editors. Entangling too much geometry into relations creates a burden down the line in my experience. 

In the interest of having a more concrete discussion, I've submitted my preferred way to map things like this and would appreciate it if you could take a look and let me know if you think any nuance is lost. If I've damaged things then I can revert and will have learned something interesting.

https://www.openstreetmap.org/changeset/136948759

Thanks!
Woazboat (2023-06-04 22:47:08+00:00): > The duplicated edges tend to fall out of sync when edited so that abutting areas end up overlapping or not quite meeting.

I assume by 'get out of sync' you mean that the two closed way areas that used to perfectly share an edge are no longer identical along that edge and there are either holes or overlaps where one of the ways has some extra nodes/is missing some nodes somewhere in between?

I'm not quite sure I follow that argument. Deleting or moving a node always affect all parent ways and cannot make them go out of sync. When adding a new node into a way, pretty much all editors simultaneously add them to all overlapping ways that share the same way segment so that they are still in sync and attached (and if they don't, they shouldn't be anywhere near users who don't know exactly what they are doing). Detaching the ways from each other is actually harder than keeping them overlapping and really has to be done intentionally.
The one way that overlapping or not quite seamless areas can happen is if they are created that way and were never attached in the first place. Often there is a reason why there's a gap in between and if there isn't, they can simply be attached by merging the nodes to make them overlap.
tms13 (2023-06-07 06:26:02+00:00): Yes, that's exactly what I mean about ways that start off identical and then diverge.  I've not used an editor that adds to multiple ways simultaneously - I didn't know that there are some that can do that.  I'm certainly seeing unintended overlaps and gaps between areas.  And also linear features that clearly ought to be the delineation between areas (fences, walls, hedges, etc) getting out of sync with their respective areas.  I always understood it to be best practice to use these boundary ways to form the areas.
Having multiple ways sharing the same nodes certainly makes it very difficult to select the way you actually want to edit much of the time.
watmildon (2023-06-07 22:30:30+00:00): For folks using iD and JOSM, having a bunch of relations in the editing area can make things quite frustrating to edit.

I totally hear you about selecting can be a bother. iD has '\' as a hotkey for "select the next way that shares this node" and JOSM has the rather cumbersome "middle click to cycle through coincident objects". It's also not helped by iD trying pretty hard to hide that relations are a thing or JOSM pulling all relation selection/editing into it's own side interface. And don't get me started on relations of relations ha.

I'll have to fire up Merkaartor sometime, differences in editors definitely can make "best practice" more difficult.
Woazboat (2023-06-08 00:21:54+00:00): >  I always understood it to be best practice to use these boundary ways to form the areas. 

It's certainly not how the overwhelming majority of editors do things. Simply because it doesn't really offer any benefits and only complicates things. Multipolygons should only really be used when they are necessary (e.g. when there's a hole in the area).

> For folks using iD and JOSM, having a bunch of relations in the editing area can make things quite frustrating to edit.

Normal editing operations such as changing tags or moving the outline around a bit work more or less fine and you won't even necessarily notice that you're editing a multipolygon. Even iD has that rudimentary level of support. Anything that involves creating new areas or deleting (parts) of areas is going to be more of a hassle than it needs to be though.
More problems start to pile up when you want to do things that are a bit more advanced, such as joining or splitting areas, etc... Editor support for operations on multipolygons simply is not as good as it is for simple closed ways. E.g. splitting multipolygon areas wasn't supported in josm and had to be done manually until I implemented it recently while it has been available for normal closed way areas for ages. These problems might not be as noticeable for users of editors that don't have these features in the first place and where doing things manually is the only way anyway, but it's a big annoyance and slowdown for users of advanced editors.

> Having multiple ways sharing the same nodes certainly makes it very difficult to select the way you actually want to edit much of the time.

> JOSM has the rather cumbersome "middle click to cycle through coincident objects".

You can select areas as normal by double clicking in them (josm), so selecting different closed way areas even when the ways are partially overlapping is a non-issue and you won't even notice it. If there are multiple linear ways overlapping, you can select them by cycling through them by holding the alt modifier key while clicking or selecting them from the popup list that appears when middle clicking on them.

> JOSM pulling all relation selection/editing into it's own side interface. And don't get me started on relations of relations ha.

Editing multipolygons works just like for any other objects. You _can_ select and edit them using the relation editor if you want to, but that is rarely necessary. Using the dedicated relation editor interface for other relations is a good thing since the properties of relations are so different to other objects and the normal editing interface is not intended for that (e.g. you need to be able to edit the member objects somehow).
Relations of relations are not relevant for multipolygons or areas that are the topic here.


Anyway. The multitude of issues with overlapping or not quite joining ways here in this area seem to have been here since they were created by a user who apparently didn't care too much and were not created by subsequent edits. This is not something that is an inherent fault of simple closed way areas.

https://www.openstreetmap.org/changeset/108889099
Woazboat (2023-06-08 00:28:10+00:00): > It's certainly not how the overwhelming majority of editors do things.

By 'editors' I mean users/humans in this instance
azakh-world (2023-05-31 08:19:56+00:00): Hi.
Why have you deleted so many objects? It doesn't seem to be true.
Leemyeonghan (2023-06-07 00:47:53+00:00): I try to some project. just editing.
eggie (2023-05-28 09:24:07+00:00): Beste Ivo  
Welkom bij OSM.
De camping Duinoord staat al gemapt in OSM?
Waarom 2x?

Is dat een aparte camping met een afwijkende naam?
MVG
eggie
Ivo vd Werk (2023-05-29 11:33:39+00:00): Hallo Eggie,

Het is een deel van Duinoord Zuid waar en bedrijf een glamping runt gedurende het jaar. De website heb ik toegevoegd.

Dus ik weet niet of dat ook op openmaps wordt toegevoegd. Hij staat bv wel bij Google Maps erin.

Mvg,
Ivo
eggie (2023-05-29 11:45:08+00:00): Hoi.. Ze staan er in ieder geval allebei in.
Eén op het vlak en de ander als node.
Je hebt alleen kans dat iemand het gaat verbeteren. 
Camping in camping triggert mappers die fouten opsporen.
Zou het voorlopig maar zo laten.
Groet..
eggie
complete_gth (2023-06-04 19:23:17+00:00): Hallo ttobi,
du gibst in deinen Changesets "TH Orthofoto; TH Hausnummer" als source an. Sollten diese Daten/Luftbilder aus dem Geoportal von Thüringen kommen, dürfen wir die Daten in OSM eigentlich nicht benutzen, da die "Datenlizenz Deutschland – Namensnennung – Version 2.0" unter die die Daten stehen, nicht kompatibel mit der Lizenz von OSM ist. Oder hast du eine andere Datenquelle in Thüringen (gefunden) die kompatibel mit OSM ist?
VG aus Gotha
ttobi (2023-06-05 04:10:42+00:00): Guten Morgen, dies war mir so nicht bewusst. Danke für den Hinweis! Ich nutze dies, um meine Feststellungen vor Ort nochmal zu "prüfen".

Viele Grüße aus Ilmenau
SherbetS (2023-07-29 14:39:27+00:00): Hi John,

Trunk in Louisiana are defined at:
https://wiki.openstreetmap.org/wiki/Louisiana/Highway_Classification

I've changed the roads you edited to be trunk, since they don't meet the local definition.
lipuma (2023-05-30 11:50:37+00:00): Hi NKA,

In this changeset you added the tag `motor_verhicle:=no' to this way:
https://www.openstreetmap.org/way/1176855093

There's a typo in this tag, notice the colon (:).

Also, on satellite imagery I can see its a BUS and TAXI lane. I could be wrong, but is the motor_vehicle=no correct in this case? I'm curious, please let me know.

Happy mapping!
NKA (2023-05-30 13:41:31+00:00): Yes, it is a typo, thanks for spotting.

I believe motor_vehicle=no + psv=designated is correct, otherwise normal cars would be permitted to use this lane.
sohrabkardi (2023-05-28 07:30:22+00:00): بهترین آموزشگاه فنی حرفه ای در تهران
https://fanamoozan.com/
silversurfer83 (2023-05-28 10:16:13+00:00): Gude :)

kleiner Tip: Wenn du in Hessen (oder NRW) mit JOSM arbeitest kannst du dir auch die jeweiligen Katasterkarten einblenden und gleich die fehlenden Adressen abschreiben.

Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136645990
TrickyFoxy (2025-05-22 00:36:36+00:00): Reverted

https://www.openstreetmap.org/changeset/166590084
NorthCrab_upload (2023-05-28 08:20:16+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Klucz addr:place oznacza brak nazwy ulicy. Kombinacja z addr:street (który definiuje nazwę ulicy) jest błędna.
https://www.openstreetmap.org/way/253150805

Pozdrawiam! 🦀
bxl-forever (2023-05-28 08:25:27+00:00): This look like a fake hospital node near an existing hospital.
https://www.openstreetmap.org/node/10933561605

"Dfff temp", "Temp vg" and "Temp1" do not seem to be real names.
silversurfer83 (2023-05-28 10:19:42+00:00): Hi vijay770017,

it looks like you mistook a feature in maps.me for a personal "favorite" feature.
When you hit "add feature to map" you save those elements to the OpenStreetMap database which is used by millions of people every day. So please be very careful with that and find out how you can save POIs for yourself in another way.
Should you wish to help map the world, don't hesitate to reach out. We'll gladly help you find the right app for that :)

cheers and save travels
silversurfer83
silversurfer83 (2023-05-28 12:49:24+00:00): as all objects save the motorcylce parking looked pretty bogus I took the liberty of remving them.
As I said before: please watch out which feature of the app you're using :)
eggie (2023-05-28 09:10:18+00:00): Dag Pieter
Het gebouw heb je nu verwijderd. Ik zal het even terugtoveren.
leisure= sports_centre met sport=soccer    ontbreekt nog.
gr eggie
eggie (2023-05-28 09:14:07+00:00): De naam staat nu op een transparant eigen vlak. Gebouw is weer terug.
Op de adresnode zou de naam van de sportclub op kunnen.
Even ctrl=f5 een paar keer voor het effect.
Masyas (2023-06-02 16:06:18+00:00): 武进站旁已经拆除干净，不用再添加信息了
silversurfer83 (2023-05-28 10:36:11+00:00): Moin Radar :)

ist denn absehbar ob der Boden IMMER feucht ist?
Wenn nicht, würde ich als Oberfläche (surface) eher "ground" nehmen. Ist ja ggf. Wetterabhängig.

Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136647784
lipuma (2023-05-30 09:09:17+00:00): Hi, welcome to OSM! I see you created a node with the name `Morris Garages'. However, this node is missing a tag which specifies what kind of amenity it is. Maybe check out the wiki for tagging garages:
https://wiki.openstreetmap.org/wiki/Garage

And are you sure it's in the right location? I don't see any service roads going to this garage.
user_177389 (2023-05-28 10:01:43+00:00): Hi,

subunits of https://www.openstreetmap.org/relation/1529146 (admin_level=8) cannot have admin_level 6, only admin_level greater than 8 -> now 10 as before.
Tomas Straupis (2023-05-28 10:48:05+00:00): Well but that is the reality in Lithuania now (that is how official data looks now). Is there anything actually technically breaking because of this?
Tomas Straupis (2023-05-28 11:00:52+00:00): I've only changed Vilnius exactly to check if something actually breaks because of it.
user_177389 (2023-05-28 11:16:19+00:00): No hierarchical evaluating software expects that districts of vilnius should now have admin_level 6 like regions.
Tomas Straupis (2023-05-28 11:26:25+00:00): Ok, so some validation routines are failing. You're suggesting to alter the reality in order to satisfy rules. This looks backwards :-) But I do see your point here. I will think about it and consult Lithuanian mappers.
eggie (2023-05-28 09:27:45+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 
Feedback  Je bijdrage lijkt een grote vernieling van de kaart. Wat was je bedoeling?
Je bijdrage:
https://overpass-api.de/achavi/?changeset=136648013

MVG, 

Eggie 

Namens de OSM Community
eggie (2023-05-28 09:32:31+00:00): reverted by changeset #136649183

Geef svp aan wat je bedoeling was en wat je hebt gedaan in je commentaar.
De kaart is inmiddels weer hersteld.
Mocht je nog vragen hebben stel ze gerust.
MVG
eggie
silversurfer83 (2023-05-28 10:34:28+00:00): moin
aus der Änderung werde ich nicht ganz schlau. Warum hast du die Umrisse der Piers entfernt?
Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136648319
bleistift2 (2023-05-28 16:22:04+00:00): Hi,

die Umrisse waren meine Ergänzungen, die ich rückgängig gemacht habe. Die Fußwege (Linien) waren bereits vorhanden und hatten mehr Informationen, die ich nicht übertragen wollte.

VG
bleistift2
literan (2023-05-28 15:13:45+00:00): Магазин продуктов это не название
BaghdadiMapper (2023-05-30 17:03:03+00:00): Thanks to your contribution to OpenStreetMap, but there may be a few problems with your edits

https://www.openstreetmap.org/way/1176870804
https://www.openstreetmap.org/way/1176870807
These two bridges are physically blocked, I think adding access=no is appropriate.

https://www.openstreetmap.org/node/8851569747 https://www.openstreetmap.org/node/10933617492

The tag public_transport=station
 seems to only apply to trains public_transport=station

https://wiki.openstreetmap.org/wiki/Tag:public%20transport=station
>amenity=ferry_terminal is a much more commonly used tag specific for ferry terminals
https://wiki.openstreetmap.org/wiki/Public_transport#Ferries
>The tags public_transport=platform and public_transport=station are generally not used for ferries

ferry=yes seems to be a duplicate of amenity=ferry_terminal
https://wiki.openstreetmap.org/wiki/Key:ferry
>With public_transport=*, this tag states whether a ferry stops at this location, using ferry=yes or ferry=no. However, amenity=ferry_terminal is much more frequently used for this feature
user_12523467 (2023-05-30 17:20:23+00:00): Hello BaghdadiMapper; thanks for checking these edits. for the two ways :
https://www.openstreetmap.org/way/1176870804
https://www.openstreetmap.org/way/1176870807

you can see there is a Gate with tag (access=permissive) that leads to the 2 ways.  hence they open these gates in some occasions.

and about the "public_transport=station" tag , is being added automatically when choosing "amenity=ferry_terminal" for the nodes, you can check this by using ID editor.

best regards
Shoorick (2025-01-05 17:56:53+00:00): Классы дорог в OpenStreetMap определяются их назначением, а не тем, кто обычно по ним перемещается, поэтому дороге https://osm.org/way/783369225 возвращён тип service (https://wiki.openstreetmap.org/wiki/RU:Tag:highway%3Dservice) — она явно используется как подъезд к опоре канатной дороги.
Flynn Marquardt (2023-06-01 12:40:03+00:00): Hello,

there is no type traffic_separation_scheme defined in the OSM wiki. Please use defined and more precise types, e.g.

https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dseparation_boundary
https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dseparation_lane
https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dseparation_line
WarmSeaboots (2023-06-01 15:31:27+00:00): tI assume youre referring to the relation tag:
type = traffic_sparation_scheme

youre correct,  however there are a significant number of relations with a type of either
"traffic separation scheme" or "traffic separation scheme".

I have a feeling i didnt actually change the type tag for the relation for this, but if i did was only following an established precedent to ensure the data was consistent.

in fact the relation "In the approaches to Hook ..." uses "type = site" and then "site = 'traffic separation scheme'" - this in itself is an outlier in terms of commonly used convention - and describing a traffic separation scheme as a "site" seems inconguous (and in fact its the only one describe this way).

I did write a long email to someone in the OpenSeaMap community regarding the "standards for describing traffic separation schemes - as yet I have had no response.

I'd prefer a consistent use of one value for traffic separation schemes rather than the current variety, but there seems little purpose in making a change (that possibly goes against convention) that has not yet been agreed as a "standard" approach.

In fact the issue is wider than merely traffic separation schemes and the sub-types used for the components of a scheme. really the discussion should be widened to include maritime routing measures in general of all varieties.

I'm always happy to contribute, but I did spend some considerable time reviewing the wiki and existing practice in the database - as far as possible i've tried to avoid introducing anything new in the way of convention, while adhering to what seems to be the most common existing practice.
silversurfer83 (2023-05-28 10:31:52+00:00): Moin
du hast darum gebeten, dass sich jemand die Änderung ansieht.
Ich verstehe nicht so ganz, was du versucht hast hier zu ändern. Die Brücke war in OSM (leider) nie gesperrt, daher war keine Änderung nötig.
Dann würde mich interessieren, woher der Name stammt. Steht der so an einem Schild vor der Brücke?

Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/136649763
Tomas Straupis (2023-05-28 11:23:51+00:00): Can you provide more information on what is breaking because of such admin data? As this IS the actual situation on the ground.
eggie (2023-05-28 11:51:59+00:00): Dag Shut.. Svp op de adresnode bijtaggen Niet op de gebouwomtrek.
Dubbele adressen geeft vervuiling en werkt ook niet goed bij een zoekslag.
MVG
eggie
eggie (2023-05-28 11:55:12+00:00): Alle info heb ik van de gebouwomtrek naar de node verplaatst.
De format van openingstijden klopt niet. Ge bruik anders deze 'tool'openingsuren-tool 
 
http://projets.pavie.info/yohours/ 
 

Je edits
https://overpass-api.de/achavi/?changeset=136649882
eggie (2023-05-28 11:56:59+00:00): Je hebt hier al eerder vragen over gesteld.
In OSM Nederland gebruiken we niet de gebouwomtrek, maar de reeds bestaande adresnode.
Die zoek je op en vervolgens kun je dan regels toevoegen
Succes,
eggie
Comino (2023-05-28 12:39:19+00:00): Zal eraan denken geen gebouwomtrekken meer te gebruiken. 
Openingstijden format aangepast. Bedankt voor de tip/link.