piebro/osm-data huggingface dataset:
pio2_122 (2023-07-08 21:53:48+00:00): Główny ciąg drogi S6 został otwarty, jednak w budowie nadal są drogi serwisowe/lokalne budowane w ramach tej inwestycji. Widać to na nagraniu ze wczoraj https://www.youtube.com/watch?v=TzQ9X0qqbkk (a także na różnych, dzisiejszych nagraniach z przejazdów tym odcinkiem).

Poza tym, czy na pewno ma sens, aby stary ślad DK6, który przebiega praktycznie tylko przez Sianów i nie łączy się z drogami tej samej lub wyższej kategorii (poza węzłami z S6 na jego końcach), miał aż highway=secondary?
1998alexkane (2023-07-09 17:01:18+00:00): reverted in https://www.openstreetmap.org/changeset/138304170
eggie (2024-01-17 14:25:35+00:00): Dag Freek Kijk even hier hoe we in Nederland fietspaden taggen.
bicycle en foot= designated hoort niet op fiespaden. 

G11: mofa=yes, moped=no, traffic_sign=NL:G11 
G12a: moped=designated, mofa=designated, traffic_sign=NL:G12a 
G13: moped=no, mofa=no, traffic_sign=NL:G13 

 

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

MVG
eggie
Xvtn (2023-12-14 20:41:10+00:00): Since you requested a review on this changeset, I looked it over - Looks good to me, as long as you were there in person to verify the trail is really completely gone. It did have the informal=yes tag on it, meaning it may not have been signed or marked.
Xvtn (2023-12-14 20:39:24+00:00): Hi, thanks for your contribution! Since you requested a review, I looked over your changes. That looks good to me, no complaints! Welcome to OSM.
Ferrocarriles de México (2024-02-08 03:45:11+00:00): Acabo de conectar la línea eléctrica que añadiste a otra que yo añadí antes pero había quedado incompleta. Resulta que son 2 tramos de lo misma. Viene desde esta subestación: https://www.openstreetmap.org/way/1181510503

Saludos.
jlambo (2023-07-09 04:43:23+00:00): *deleted buildings and roads that no longer exist
Mateusz Konieczny (2023-07-09 11:03:41+00:00): I created https://www.openstreetmap.org/note/3772141

I think that is a good idea in case of suspect data

Not familiar enough with this bank to judge what should be done with POI without survey
LockOnGuy (2023-07-08 22:58:05+00:00): Hello, in this changeset you removed the Arabic names entirely, from node 8189074617 and 9900646217, and you removed 8 addr:postcode which they are correct. Please stop.. I told you previously many times on not removing names in languages you don't like entirely, if you don't want them in main name tag move them to it's specific language tag, do not remove it entirely and type it in another language only. Also I told you many times to not remove postal codes and you keep removing them.. please stop..
Dodko (2023-07-11 22:14:54+00:00): Dali ste chybnú adresu pošty 4/4 budova má 5/5
Dodko (2023-07-15 19:06:16+00:00): Nemeň dohodnuté názvy pošty.
https://groups.google.com/g/osm_sk/c/afglwDyRtBM/m/KGd1-IjvAQAJ
Dodko (2023-07-11 22:01:16+00:00): Telocvičňa sa nedáva
leisure=fitness_centre
sport=fitness

použite
https://wiki.openstreetmap.org/wiki/Tag:building%3Dsports_hall
https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsports_hall
Mateusz Konieczny (2026-03-17 21:50:32+00:00): Hello! https://www.openstreetmap.org/node/6060490877/history has stone_type = khachkar that was added in this edit
What is here? Boulder with carved khachkar ?

In such case https://wiki.openstreetmap.org/wiki/Tag:stone_type%3Dkhachkar makes sense and should not be marked as deprecated

Or it is it a carved slab? In such case memorial=stele + stele=khachkar would be a better tagging
CurlingMan13 (2023-07-08 23:36:06+00:00): Only things that actually exist should be mapped.  So things with a presence.  I highly doubt there is a railway (abandoned or not) going through the person's bedroom at 3315 Gregory Street.

See more here:
https://wiki.openstreetmap.org/wiki/Good_practice#Map_what's_on_the_ground

This would definitely be good stuff to add to OpenHistoricalMaps where it can live on forever.  Features that no longer exist but once did and have been overbuilt belong on OHM:
https://wiki.openstreetmap.org/wiki/Nonexistent_features#:~:text=Please%20feel%20free,right%20time%20period.

OpenHistoricalMap (OHM) also allows you designate start and end dates for features.  I highly recommend focusing time and energy getting old railways added there so you don't have to worry about them being deleted over time:
https://www.openhistoricalmap.org/
myoungwisc (2023-07-09 00:08:05+00:00): Thanks for the heads up @CurlingMan13. I was unaware of the OpenHistoricalMap option. Interestingly enough, the abandoned spur did in fact exist in the location I mapped it - the houses were constructed after its removal.
Spaghetti Monster🍝 (2024-02-28 03:03:26+00:00): numbers aren't names. https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138280304
mweper (2023-07-09 03:00:50+00:00): Impresionante laburo!! Me saco el sombrero!!
JeroenvanderGun (2023-07-09 10:58:27+00:00): Hello,

Your interpretation of the Peruvian constitution is not correct, or at least does not match what the government of Peru claims. While Peru indeed has a 200 nm maritime dominion, only the first 12 nm of it is territorial sea.

This is clear from the statements made by Peru during the proceedings at the International Court of Justice during the dispute with Chile. Peru has formally stated that the application of the maritime domain is consistent with UNCLOS maritime zones (i.e. max 12 nm territorial sea, 24 nm contiguous zone, 200 nm EEZ).

See this discussion on the forum:

https://community.openstreetmap.org/t/perus-nautical-boundary/100932

Also these comments on Reddit:

https://old.reddit.com/r/geography/comments/14t5v44/why_does_perus_territorial_waters_extend_so_far/jr2zf5a/
https://old.reddit.com/r/geography/comments/14t5v44/why_does_perus_territorial_waters_extend_so_far/jr417if/
ovruni (2023-07-09 16:28:22+00:00): Hola, la constitución política del Perú va mas allá de algún gobierno de turno o de alguna interpretación. En el artículo 54 de la constitución se detalla que cosas comprende el territorio del Perú y sobre donde esta la jurisdicción. [0] Por otra parte, parece que es usted quien realiza alguna interpretación sobre un texto en la corte, cuando la demanda en cuestión se centraba sobre una zona límite entre Perú y Chile, mas no sobre el resto de las 200 millas que van hasta Tumbes, la zona sobre la cual la corte ha dado la sentencia ya fue modificada.
Saludos
[0] https://www2.congreso.gob.pe/sicr/cendocbib/con5_uibd.nsf/22C8580E2F7481F5052586F3000BB1DA/$FILE/CPE-54.pdf
JeroenvanderGun (2023-07-09 17:51:12+00:00): Hello,

The statements made by the government of Peru about its maritime domain obviously apply to the entire maritime domain, not just near Chile. The meaning of the maritime domain is also clearly relevant to that court case, because without the claim of a maritime domain there would be no dispute in the first place. The statement is also not just some interpretation but the court has noted it as an explicit commitment.

If you look at the exact contents of the statement, Peru says the maritime domain is applied consistently with UNCLOS. This means a 200 nm territorial sea is not the current situation on the ground, regardless of what the constitution says Peru is entitled to.

Maybe a different government in the future will successfully claim a territorial sea of 200 nm, based on the constitution, but until that happens the maritime borders should be mapped as they are effectively applied today.
ovruni (2023-07-10 01:38:07+00:00): Hola
La interpretación a la que me refiero es a la que usted le da sobre de que Perú acepte ser parte de la Convemar y de que se le recorte parte de su territorio, tal es así que en ningún momento los gobiernos a los que se refiere han solicitado cambios constituciones para adaptarse a la Convemar, tampoco los gobiernos siguientes hasta la actualidad. Tal vez algún gobierno en el futuro pida ser parte de la Convemar y modificar el articulo de la constitución al congreso, pero hasta que eso suceda, las fronteras marítimas deben quedar como se encuentran ahora.
Saludos
Fizzie-DWG (2023-12-21 04:55:47+00:00): DWG revert

https://www.openstreetmap.org/changeset/145355334
Fizzie-DWG (2023-12-21 04:53:35+00:00): DWG revert

https://www.openstreetmap.org/changeset/145355297
Fizzie-DWG (2023-12-21 04:51:53+00:00): DWG revert

https://www.openstreetmap.org/changeset/145355259
OilStation (2023-11-29 05:50:00+00:00): 通常都是卫星图像畸变造成的视觉错误，不用理会。
HirschKauz (2023-07-10 07:10:28+00:00): Hi!
Small note, please try to keep your changesets in local small areas. Changesets like this one makes it more difficult to keep track of edits to the map generally.

Happy mapping!
silversurfer83 (2023-07-09 15:18:48+00:00): Hi
according to aerial images this "viewpoint" is located on a 4 lane highway which doesn't look like it really is a viewpoint. Can you maybe explain, why you added this?

cheers
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138281789
JakeTheMoose (2023-07-21 21:10:28+00:00): You beat me to it by mapping Dearborn Denim before I could.
ovruni (2023-07-09 02:32:35+00:00): En este conjunto de cambios se coloca " Determine whether road construction is now completed", lo cual no tiene nada que ver con el colegio modificado.
Saludos
ovruni (2023-07-09 02:30:36+00:00): Hola, el uso del a etiqueta de parque esta destinado para vias, no para nodos. [0]
Para cualquier consulta sobre el mapeo de OSM en Perú, puedes realizar consultas por el canal de telegram de la comunidad peruana https://t.me/osmpe
Saludos
[0] https://wiki.openstreetmap.org/wiki/ES:Tag:leisure%3Dpark
ovruni (2023-07-09 02:28:10+00:00): Hola, he notado que en varios de sus conjuntos de cambio se están conectando edificios con calles, ademas de nodos duplicados con vías que los contienen. Por lo que los he retirado. ara cualquier consulta sobre el mapeo de OSM en Perú, puedes realizar consultas por el canal de telegram de la comunidad peruana https://t.me/osmpe
Saludos
ovruni (2023-07-09 02:36:14+00:00): Hola, el uso de la etiqueta nombre se encuentra destinada unicamente para nombres de un objeto, no para descripciones. [0]
Saludos
[0] https://wiki.openstreetmap.org/wiki/ES:Nombres#Los_nombres_no_son_para_descripciones
ovruni (2023-07-09 02:52:09+00:00): Hola, la etiqueta de uso de suelo se encuentra destinada para áreas y no para nodos. [0]
Saludos
[0] https://wiki.openstreetmap.org/wiki/ES:Tag:landuse=residential?uselang=es
ProfAcclaim (2023-10-29 13:09:24+00:00): This has broken all relevant road maps on Wikipedia. They now don't render correctly.
Minh Nguyen (2023-10-29 21:25:55+00:00): That’s a bug in Wikimedia’s geoline service. [1] As a workaround, you can still query for one of these relations, convert it to GeoJSON, and upload it to Commons. The AARoads Wiki (a fork of Wikipedia) has a decent tutorial for creating these maps [2], although Wikimedia’s Kartographer extension is a bit pickier when it comes to bounding boxes: 

[1] https://phabricator.wikimedia.org/T156433
[2] https://wiki.aaroads.com/wiki/AARoads:Maps/Creating_a_GeoJSON_file_from_OpenStreetMap
Pikse (2023-11-26 08:51:32+00:00): With or without geoline service support, why type=route was changed to type=street here? The latter is documented as a complex relation type "to group all the elements that make up a street together" (buildings included). Here all relations appear to include only the road itself which is what type=route is normally used for.

To me it seems that type=street relations could be created in addition to type=route relations if needed. Their purpose is different, and a road without adjacent objects is still its own thing that seem to warrant an individual OSM object (this is what people, including in Wikipedia, probably expect normally if they look for a geometry of a road).

Wikimedia might consider supporting type=street but then it should supported differently from type=route, in a more complex way, as the data in nature is different.
Minh Nguyen (2023-11-26 09:22:10+00:00): I guess the context for this change was https://wikis.world/@samwilson/111084626354658237, which incidentally sparked some discussion in OSMUS Slack: https://osmus.slack.com/archives/C2VJAJCS0/p1695020657752419 .

An individual street isn’t quite the same thing as a route (in the plain English sense of the word). But type=route isn’t just for routes: these days, it’s also used for a variety of routable features, including type=route route=railway for railways, which are analogous to these streets. route=railway causes endless confusion, but it’s very entrenched at this point. At least the previous tagging of type=route route=street kept renderers from getting confused and treating them as highway routes, which require route=road.

The current tagging is technically valid, since type=street also tries to represent the street geometry using the “street” role. This is similar to how type=waterway can include tangentially related members like side streams and springs, but the “main_stream” role is reserved for the main geometry.

That said, I’m not a fan of type=street as documented: it’s basically an attempt to reimplement a geocoder under the false assumption that the technology for data compression or spatial querying hasn’t been invented yet. Taken to its logical conclusion, literally every feature in Fremantle would be part of a street relation.

Another option would be type=multilinestring, which avoids overloading the term “route” while also avoiding the ill-conceived street relation proposal.
Pikse (2023-11-26 11:21:40+00:00): In my experience it's quite common that tag names can be confusing if taken literally, and it's always a good idea to check from documentation to know when to use which tag. In other parts of the world, unlike in US, major roads necessarily aren't named as "routes" either. As both major roads and streets are still roads then route=road tag sort of clears it up, doesn't it?

I guess it's difficult to come up with ideal tag names and generally it's considered more imporant that for ease of use similar kind of data would just have uniform data scheme.

You mention route=street tag, but that doesn't seem to exist really (has 6 uses at the moment). Also are there really renderers that render roads as (major?) routes only based on route=road?

I think waterway relations are similar to route relations as normally they also represent the waterway itself rather than a collection of related stuff.  Objects like the spring or (small) side streams more or less can be considered as parts of the same named waterway.

I'm also not a fan relations that gather related stuff as opposed to represent an individual geographic feature, but this is what they have currently documented for type=street. If objects of this type may return building as well then for me things still seem more reliable with type=route.
Minh Nguyen (2023-11-26 11:41:21+00:00): Tagging for highway routes in Australia is documented at [1]. That section doesn’t discuss route names specifically, but those numbered routes very frequently come with signposted names that are distinct from the names of the streets that carry the route. This is similar to the distinction between roads/streets and routes in many U.S. states.

I mentioned route=street because this changeset had replaced many occurrences of type=route route=street with type=street. As far as I can tell, route=street wasn’t causing any problems, but using route=road for this purpose would dilute an important tag for renderers and routers.

Some renderers such as OsmAnd and OSM Americana display shields based on route=road relations or render certain networks at lower zoom levels. Routers such as OSRM and Valhalla modify guidance instructions when they encounter route=road relations. [2]

This discussion is getting rather unwieldy for a narrow comment box. Perhaps we can take this to the forum if you’re interested in discussing further?

[1] https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines/Roads#Routes
[2] https://github.com/Project-OSRM/osrm-backend/blob/31e31a63d062fb804f5f4695ed3036ca7a269ead/features/car/route_relations.feature#L238-L248
Pikse (2023-11-26 12:39:18+00:00): Earlier I spotted that a couple of relations here used route=road, but indeed now I see that some also used route=street.

If I get this OSRM code correctly then this is specific to some hardcoded US routes not to route=road in general, right?

I see that major roads in Australia are also named as routes, and these should have route relations. In respective guidelines, if I'm not missing something, it also doesn't explicitly discourage the use of route relations for smaller roads, though.

I guess the wiki talk page of respective tag[1] would be the most obvious and convenient place where to comment on how this tag should be used.  Currently route=road wiki page doesn't mention any restictions on which networks (excluding some local network of numbered roads within a city, or local networks in some countries perhaps?) can use this tag nor that the use this tag could somehow dilute the data. If such restictions apply then for me it remains a question what is the alternative for smaller roads (type=street doesn't seem good one due to its documented purpose).

[1] https://wiki.openstreetmap.org/wiki/Talk:Tag:route%3Droad
Minh Nguyen (2023-11-26 23:27:30+00:00): The OSRM code I linked to is a test case proving the existence of behavior that is uniform globally. The code that implements it lives elsewhere.

The Australia tagging guidelines don’t discourage using route=road for ordinary streets because of common sense. Again, the use of “route” for non-routes is a slight perversion of the language, even if it’s one that we live with for historical reasons. The tagging guidelines were overhauled just a few months ago after extensive discussions. If there was any thought to modeling streets as highway routes, one would think the Jacaranda Street example would look a little different.

I should clarify that this distinction between routes and the roads that carry them is not specific to the U.S. (Even in the U.S., some states make a clear distinction while others do not.)

Anyways, I’m not opposed to retagging as route=street if you feel strongly about doing that yourself. But so far I haven’t heard a particularly compelling reason as to why route=road needs to be used here when there are more accurate alternatives.
Minh Nguyen (2023-11-26 23:57:57+00:00): I posted to the Oceania forum to give local mappers an opportunity to chime in:

https://community.openstreetmap.org/t/streets-as-street-relations/106436
Sam Wilson (2023-11-27 01:57:01+00:00): Hi everyone, thanks for this interesting discussion! I seems I was wrong about my newly-learnt idea that type=route was *not* to be used just to collate road parts together. I thought type=street was the way to go, but I'm very happy to switch all these back to type=route with route=road.

There are some slightly odd bits, such as High Street https://www.openstreetmap.org/relation/8536837 which has parts that are pedestrian.

Anyway, happy to continue the discussion on the forum! :-)
Minh Nguyen (2023-11-27 02:02:41+00:00): Honestly I was confused about that too until the other Americans hit me with a cluebat in the thread linked above. 😅 I was aware of railway routes also being an oddball, but I thought that was type=railway, not type=route route=railway.
mavl (2023-07-09 03:43:44+00:00): This changeset has been reverted fully or in part by changeset 138282862 where the changeset comment is:  The changesets are reverted [DWG has the request to revert the changesets. Reason: the edit war].
ТатьянаC (2023-07-10 00:21:18+00:00): Вы что, реально думаете, что создав аккаунт- клон  моего аккаунта вы сможете и дальше вредить? Может пора вести честную конкуренцию. что бы не страдали люди, не имеющие отношения ко всему этому?  Вы хоть представляете, что по навигаторам ездят не только таксисты города! или от жадности вам на все и всех плевать?!
mavl (2023-07-09 03:43:45+00:00): This changeset reverts some or all edits made in changeset 138282775.
5m4u9 (2023-07-11 07:26:29+00:00): Hola, gracias por las mejoras.

Solo tengo observación en el nombre del Barrio, quitaré el texto "zona" porque no es parte del barrio.
Frans S (2023-07-09 09:31:42+00:00): Hello. Thanks for mapping on this project.
You mapped a few lighter colored traces alongside a highway as buildings. Please check that they show a shadow, which proofs it is above ground level. No shadow here, I removed them.
Best regards and keep mapping
user_11609320 (2023-07-09 05:33:55+00:00): If the streams were there, the tribe must have plowed them when they built the homes
UtterClutter (2023-07-09 16:46:56+00:00): Great work once again. At this rate, between us local mappers, we will leave no stone unturned within East Brighton.
Glassman (2023-07-11 23:05:58+00:00): #TIP: Don't forget to update your changeset comment. It's helpful when you want to go back to a previous edit.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/138284342
maraf24 (2023-12-05 21:48:34+00:00): Co z resztą tagów? Prawie wszystkie te przejścia nie są oznaczone w terenie, tej informacji tu zabrakło.
maraf24 (2023-12-05 21:42:00+00:00): Znów błędy. Parkingi, które są niezależne od drogi są oznaczone tagiem street_side.
Edycja na dużym terenie, nie wygląda to na sruvey.
maraf24 (2023-12-05 21:36:24+00:00): Wycofałem calość.
Niektóre z tych krawężników, które oznaczyłeś jako flush, znam i mają one kilkanaście cm wysokości.
gscholz (2023-07-11 10:40:19+00:00): Hi gnoye,
this changeset has created errors in the OSM database regarding self intersecting ways:

https://tools.geofabrik.de/osmi/?view=areas&lon=32.55929&lat=15.56610&zoom=14&baselayer=Geofabrik%20Standard&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways

https://overpass-api.de/achavi/?changeset=138285124

Obviously a neighbourhood area is affected here. Can you please fix this?
Kind regards
Guido
gscholz (2023-07-14 07:12:53+00:00): Hi gnoye, 
this error still exits, can I get your feedback here?
Guido
warkaree (2023-07-09 07:21:10+00:00): overpass turbo wizard query : type:way and highway=* and name!=* and name:mr!=* and alt_name=* and alt_name:mr=*
silversurfer83 (2023-07-09 15:06:25+00:00): Hi there :)

there already was a Penguin Bar at that location so I removed one of the double entries.

maps.me is a nice app but I recommend using a different app i you wish to contribute to the OpenStreetMap database (the source of the data that maps.me uses). The data displayed in maps.me is usually around 3 to 4 weeks older than the live database so it's always possible that a POI you add in the app is already in the database so you create double entries.

Another thing many maps.me users misunderstand is the "add feature to map" option. This is NOT a personal notebook to save your favorite spots. Please use the bookmarks function for that (maybe called different, please check).

If you have any questions, just reply to this mail

save travels
silversurfer83
bxl-forever (2023-07-09 09:15:06+00:00): Hello,

You added "note=peck 47" to this place.

This tag is aimed at alerting other mappers about something peculiar.

Would you please be so kind as to explain what we should do with this?  Wasn’t is meant to be alt_name or anything?
StarWagon (2023-07-09 09:52:27+00:00): Yes, sorry I meant it to be an alt_name 

I will fix it