piebro/osm-data huggingface dataset:
reedyn (2021-06-23 18:42:05+00:00): Cyklade förbi där nyss. Så här ser skyltningen ut på banvallen längs mossen samt vid Vattenledningsområdet.
https://gustavlindqvist.se/content/images/2021/06/20210623_195603.jpg
https://gustavlindqvist.se/content/images/2021/06/20210623_201301.jpg
leojth (2021-06-24 06:58:04+00:00): Hej! Tack för bilderna, det klargjorde vilken sträcka du menade. Ja, här är motortrafik förbjuden och sträckan är huvudsakligen till för åtkomst till naturreservatet, till fots eller med cykel (kanske även hästar?). Då tycker jag highway=path med attribut speglar verkligheten bättre än highway=track som jag tycker mer indikerar på att det är en traktorväg/bruksväg i första hand. Sträckan är ju också en del i vandringslederna i naturreservatet. Jag funderade även på highway=service fram till rastplatsen eftersom fordon med handikapptillstånd är tillåtna, men landade i att det huvudsakligen är en GC-sträcka, även om det inte finns en GC-skylt. Men tycker du att den tidigare taggningen är bättre så är det fritt att ändra tillbaka.
reedyn (2021-06-24 08:56:21+00:00): Eftersom det är förbjuden motortrafik så håller jag med om att path skulle kunna vara bättre än track. Designated tycker jag dock är fel eftersom det inte finns någon sådan indikation.

Vägen är dock en del av ett skogsvägsnätverk som används för avverkning i området. Det skulle vara konstigt om just den vägen längs banvallen inte var track när resten är det. Alla är märkta med motortrafik förbjuden men används ju för skogsmaskiner.
reedyn (2021-06-24 09:10:51+00:00): Då syftar jag just på biten längs mossen. Den vid vattenledningsområdet är knepigare eftersom den inte används för skogsavverkning eller dylikt. Där skulle path kunna användas men då utan designated för foot/bicycle
tastrax (2021-06-17 03:00:16+00:00): Hi folks FYI - Phone numbers in Australia should be added to OSM according to the following format with the country code +61 x xxxx xxxx, (+61 xxx xxx xxx for mobiles) or use the phone:AU key if a 1300 or 1800 number as per the wiki guidelines https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines - I have just updated a recent addition that you made to OSM – Cheers
FrankOverman (2021-06-13 20:45:44+00:00): Dit is natuurlijk geen 'BAG Update': ik was te snel.

De f261 route langsgefietst van de Grootvensestraat in Tilburg tot in Waalwijk. Onderweg alles genoteerd: veel is fietsstraat gemaakt. Bijna alles is gereed.
user_12625593 (2021-06-15 04:45:06+00:00): Hoi, er zijn een paar opmerkingen bij geplaatst mbt de tagging van fietsstraten.
ZLima12 (2021-06-14 02:33:45+00:00): Hi,

"The Crossining" is a name that is sometimes used to describe this bridge. I live in the area, but had not heard this name before seeing it on the map, and looking it up. Though it isn't a ubiquitous name, it is used.

"Croton River Bridge", on the other hand, is both ambiguous (see Quaker Bridge just up the river), and not used among locals.

Personally, I would advocate for there to be no `name=` tag on this bridge at all, since there is no common name for it that is used in common speech.
KindredCoda (2021-06-14 02:44:34+00:00): Hello,

I have changed the main name back to "The Crossining" simply due to the fact that I could not find an official name for this bridge.

If and when I find out an official name for this bridge, then and only then will I change it.

Thanks,
-Coda
lyctkel (2022-06-08 16:46:15+00:00): Hi fkv,
bei Way 954059461 scheint Dir ein Typo passiert zu sein. Ich nehme mal an, es ist ein Tipi gemeint. 
building=tipi ist zwar nicht dokumentiert, aber es gibt heute rund 200 davon auf OSM :-)
Herzliche Grüsse,
lyctkel
fkv (2022-06-08 22:16:07+00:00): Ja. Ich schätze, ich hatte die Bezeichnung falsch in Erinnerung bzw. mit dem Namen des südamerikanischen Indianerstamms durcheinander gebracht. Ich hab den Fehler hier korrigiert, weiß aber nicht, ob er mir auch woanders passiert ist. Indianerzelte hab ich schon mehrere gemappt.
lyctkel (2022-06-09 07:32:19+00:00): Hi fkv,
danke für die schnelle Lösung.
Ich gehe nicht davon aus, dass Dir der Fehler nochmal passiert ist. Ich konnte nur ein building=tupi finden.
Schönen Tag,
lyctkel
user_12625593 (2021-10-19 15:51:43+00:00): Beste JTnl, graag even aandacht voor deze opmerking: https://www.openstreetmap.org/note/2902242
Een aantal tags staan sinds je laatste wijzigingen niet juist. Dit is een transformationstationsgebouw dat tot je eerdere wijziging twee jaar geleden nog '50/10kV Leiden Noord' heette. Inmiddels is het als een industriegebied en electriciteitscentrale getagd? 
Gaarne deze foutieve tags corrigeren.
pbnoxious (2021-06-14 17:32:37+00:00): Bitte als "Namen" nicht die "Beschreibung" des Ortes eintragen, dass es ein Spielplatz ist, geht ja schon aus dem "leisure=playground" hervor. (siehe auch das Wiki; https://wiki.openstreetmap.org/wiki/DE:Names#name_ist_nur_der_Name )
rasep (2021-06-14 18:09:56+00:00): Danke für den Tipp. Den Namen habe ich entfernt.
Waynesboro (2021-06-13 21:30:02+00:00): The added fields include the hours, outdoor seating and delivery
Pikse (2021-08-07 06:39:44+00:00): Why these relations were removed? Link to discussion or some further background in edit comment would have been nice.

As far as I can see these territorial entities are verifiable using INE data, and they include smaller islands neighbouring the main island, i.e they have different extent than relations of individual islands.
AntMadeira (2021-08-07 15:55:18+00:00): Hi, Pikse.
You can check the approved proposal here:
https://wiki.openstreetmap.org/wiki/Portugal/Propostas/Localidades_e_limites_administrativos

Regards.
Pikse (2021-08-07 19:02:40+00:00): Regretfully I'm Google translating this proposal. Do I get this right that per this page relations were removed as they weren't for administrative entities and also because place=island relations exist as well? I still don't quite get why is that as at the same time some other non-administrative entities were chnaged to boundary=statistical and, as already pointed out above, place=island relations are for individual islands while removed relations per INE data were for island groups (main island + neighbouring islets).
AntMadeira (2021-08-07 20:05:51+00:00): Yes, you got it right.
Non-admin relations were removed, since they're redundant with the islands' limits, which are natural=coastline + place=island, not admin.
About boundary=statistical, they were not official admin boundaries, but statistical ones (NUTS), so they were also changed, like in the mainland.

Regards,
António.
Pikse (2021-08-08 07:29:54+00:00): Well, as said, it isn't true that "they're redundant with the islands' limits". The limits in fact are different, and as far I can see data was simply lost. This can be checked from [1]. Maideira as a statistical territory in addition to Madeira island includes e.g. Ilhas Selvagens and Ilhas Desertas. Porto Santo as a statistical territory in addition to Porto Santo island includes several neighbouring islets, e.g. Ilhéu da Cal, to name the largest one. Other deleted relations also included several islets in addition to the main island. 

I see that briefly before deleting these relations you changed them to boundary=statistical, which made sense if they aren't administrative areas. I understand that they aren't NUTS entities, but nonetheless are also official and verifiable statistical entities by the INE.

[1] https://www.dgterritorio.gov.pt/cartografia/cartografia-tematica/caop
AntMadeira (2021-08-08 12:29:45+00:00): All necessary boundaries still exist as official and verifiable boundaries. 

The CAOP boundaries (official from the link you posted above) are still in place as admin_level=4:
https://www.openstreetmap.org/relation/1629145

The Madeira island is still in place:
https://www.openstreetmap.org/relation/1715038

And then you have all admin_level=7 and admin_level=8 in place (also from CAOP).

You can argue that the statistical boundaries NUTS I, NUTS II and NUTS III [1] are missing, but those boundaries corresponds to the exact relation as the archipelago. I confess I don't remember what was decided or why I did that at the time, but maybe that information can be appended to the archipelago's relation, instead of creating and/or restoring the previous one, which is the same.


[1] - https://pt.wikipedia.org/wiki/NUTS_de_Portugal#C%C3%B3digos_NUTS
AntMadeira (2021-08-08 12:41:07+00:00): I remember now why: you can see that both Açores and Madeira relations already have the NUTS information as ref:nuts=*

- https://www.openstreetmap.org/relation/1629146
- https://www.openstreetmap.org/relation/1629145
- https://wiki.openstreetmap.org/wiki/NUTS_and_LAU#Tagging
Pikse (2021-08-08 15:00:56+00:00): You now refer to relations of autonomous regions that actually also have different extent than the ones that you deleted. Per CAOP boundaries linked above the autonomous region of Madeira consists of two ilhas: Ilha da Madeira (Madeira, the individual island + Ilhas Selvagens + Ilhas Desertas + neighbouring islets), and Ilha de Porto Santo (Porto Santo, the individual island + Ilhéu da Cal + neighbouring islets) . Relations in extent of the latter two statistical entities are currently missing. Similarly, relations for individual islands of Açores are still there, but deleted relations were neither for individual islands nor the entire autonomous region (nor admin_level=7 nor admin_level=8). 

No, I'm not argueing that NUTS boundaries are missing. These deleted entitites are not part of NUTS, but are used by INE (note that they all also had ine:code=* tags with unique values).
Pikse (2021-08-08 15:11:07+00:00): The confusing naming of these 11 statistical territories (ilha) probably contributes to this issue. They are all named after invividual islands, e.g. "Ilha da Madeira", but are in fact not individual islands as outlined above. A couple of months ago, when I fixed some inconsistencies related to tagging and membership of these relations, it took me a little while, too, to figure out the difference between individual islands and corresponding statistical territories.
AntMadeira (2021-08-08 16:19:18+00:00): Ok, I now realized what you're saying about individual islands/islets vs. admin boundaries.
I didn't see that the admin_level=4 were missing the subareas from the old admin_level=5. That must be corrected in all islands/islets of the archipelagos.


As I see it (and I'm also trying to understand this conundrum), INE data is not admin nor statistical, is census data. That's the approach we have on the mainland, where all admin_level=10 (which were based on INE data) are going to be changed to boundary=census, since they're not admin boundaries.
I think that's why there's a difference between Ilhéu de Cima [1] and Ilhéu da Rocha do Navio [2]. Maybe because the first has population and the second doesn't.
If you think that INE codes are important for the individual islands (as defined by INE polygons), maybe it would be ok to add those to the island/islet polygon. 

In short, the Açores and Madeira have the following boundaries:
admin_level=2 - national
admin_level=4 - autonomous region
admin_level=7 - municipal
admin_level=8 - parish

The only statistical data (NUTS) corresponds to admin_level=4, so it can be added to those relations.

Given this, please explain better which boundaries are missing or wrongly deleted.


[1] - https://www.openstreetmap.org/way/121718318
[2] - https://www.openstreetmap.org/relation/9897330
Pikse (2021-08-08 17:05:37+00:00): I think above I already explained quite thoroughly in what way the limits of deleted relations and remaining ones are different. But alright, to put it differently, in case of Madeira, there are are/were three relations, all having different members:

1) https://www.openstreetmap.org/relation/1629145 – autonomous region, includes Madeira, Porto Santo and neighbouring islands
2) https://www.openstreetmap.org/relation/8421421 [deleted] – ilha (INE statistical territory), includes Madeira and neighbouring islets, *excludes* Porto Santo
3) https://www.openstreetmap.org/relation/1715038 – individual island, includes *only* the main island, excludes neighbouring islets

You might as well simply preview the deleted relation in JOSM (or undelete it) to see what it was, and compare it visually to other relations to see the difference.

As these INE statistical territories (ilhas) are not individual islands, then it would be inaccurate to add INE codes to relations of individual islands.

It doesn't matter a lot to me if it's boundary=statistical or boundary=census, as far as the data itself is accurate. Though, I'm not sure I get the distinction. Census data after all is statistical data, too, isn't it? Also, it doesn't look like statistical territories in question are used only for census, e.g. see [1].

As for the relation of Ilhéu de Cima, it seems simply erroneous, and admin_level=*, border_type=* and boundary=* probably can be removed from it.

[1] https://www.ine.pt/xportal/xmain?xpid=INE&xpgid=ine_indicadores&indOcorrCod=0002100&contexto=bd&selTab=tab2&xlang=en
AntMadeira (2021-08-08 19:10:54+00:00): "As these INE statistical territories (ilhas) are not individual islands, then it would be inaccurate to add INE codes to relations of individual islands."

Ok, I've understood the difference you're talking about and I was able to see it via OSMCha.

Do you have a link to the data from INE that corresponds to those deleted relations?
Pikse (2021-08-09 06:49:21+00:00): As far as I can see ilhas listed in INE table on consumption of natural gas, that I linked in last comment, correspond to deleted relations. If you download this table in Excel format, then the same INE codes for each ilha are also shown. Extent (boundaries) of these statistical territories can be verified using CAOP data, where exactly the same territories are given in "Ilha" column in attribute data, as pointed out above.
Pikse (2021-08-17 11:53:38+00:00): So, there isn't a particular reason why relations for these 11 verifiable areas, that are not represented by other existing relations, shouldn't exist, and we should restore them, right?

Given relations already referenced INE and CAOP, so earlier I was able to figure out why they differ from other relations. If it should be more clear, then any suggestions what changes would be necessary?
AntMadeira (2021-08-18 14:23:07+00:00): Sorry, I haven't had the time to look in to this in the last days.

The bottom line is relations that were in place and deleted by me weren't admin relations. If you think they're useful in some other way based on INE website, please, restore them and edit them accordingly. 

Regards,
António.
user_10241830 (2021-06-13 21:34:42+00:00): betroffene Changesets:

106285923,106295475,106295786,106296487,106296807,106296970,106297293,106298022,106298124
user_10241830 (2021-06-13 21:37:05+00:00): betroffene Changesets:

106280292,106282513
martianfreeloader (2023-08-09 09:43:40+00:00): Hi,
Tagging nodes connecting different highways with junction=yes and nothing else is discouraged. I'm thus removing the tag from https://www.osm.org/node/4450443319
lonvia (2021-10-21 08:13:02+00:00): Hi, I'm trying to find the community discussion behind this decision to remove the 'regiao' from the administrative hierarchy. There were complaints that the regions no longer show up in search results (https://github.com/osm-search/Nominatim/issues/2474) and I'd like to point people to the reasoning behind this decision.
AntMadeira (2021-10-21 22:55:52+00:00): Hi, lonvia.
The "regiao" wasn't removed, it was renamed to "região_autónoma" and given the de facto admin level.

You can check the wiki page here:
https://wiki.openstreetmap.org/wiki/Portugal/Propostas/Localidades_e_limites_administrativos

Any doubt, don't hesitate to contact me or in the Telegram channel of OSM Portugal:
https://t.me/OSMPortugal

Regards,
António.
lonvia (2021-10-22 09:06:00+00:00): I was referring to the boundaries that were changed from boundary=administrative to boundary=statistical. This makes them de facto invisible for anybody that processes boundaries. I gather from the wiki page that this was intended. I mean if the 'regiões' and 'sub-regiões' are something that nobody ever uses outside the EU statistics bureau, then the change is perfectly reasonable. If these regions are something in common use and people expect them to show up on maps and/or to be shown in search results as part of the address, then that would be a different matter.
Anyway, thank you for the link. It was exactly what I was looking for. Nice work there from the Portuguese community. I'll close the Nominatim issue as "intentional data change".
AntMadeira (2021-10-22 12:30:21+00:00): Yes, you're right. Those regions are merely statistic regions, without administrative functions, so they were changed. But as you say, there are some that will probably receive the tag place=region, because they're well known due to historic reasons as such. It's something we're still studying and will be announced in the future.
Thanks for reaching out.

Regards,
António.
blackboxlogic (2021-06-26 23:59:26+00:00): This change seems entirely wrong. You delete all of the woods you just added, and you turn all the 'wetland' into 'building', which it certainly isn't. Would you please fix this and ask if you have questions.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/106299619
rthik007 (2021-06-14 03:45:00+00:00): Hi Julie Qi,
I have created a service road to fix the geometry of road way 954116631.
Kindly check with 
https://www.openstreetmap.org/changeset/106303202
Thank you.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/106299755
BCNorwich (2021-06-19 08:29:10+00:00): Hi, Regarding footpath Way: 954089834, is there a bridleway as mapped? If not can the bridleway section be removed?

Regards Bernard.
Wookey (2021-06-20 11:00:30+00:00): Hmm. I see what you mean. There is the field entrance adjacent to the footpath. I couldn't for sure say there was no bridleway but I only remember the coast path sign, and noting that the route was changed (it used to continue along the road another km). The footpath is very narrow and overgrown - too narrow to be a bridleway and I'm not sure that the gat at the northern end was horse-friendly. I checked on the county definitive map and it's a footpath there (and that bridleway across the gold course is indeed not the right route). So yes I'll remove the duplicate bridleway. Thanks for the heads-up. (I'm just trying to fix the remaining connectivity and ordering issues on the whole 'Ceridigion coast path' relation. These major long path relations are tricky!)
gscholz (2021-06-16 04:47:47+00:00): Hi Luis,
this changeset has added errors to the osm database regading overlapping ways (dark blue markers):

http://tools.geofabrik.de/osmi/?view=routing&lon=-89.80726&lat=14.01932&zoom=13&overlays=duplicated_edges,duplicated_edges,duplicated_edges_areas,snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6

Can you please fix this?
Guido
Lee Carré (2021-06-14 11:46:49+00:00): Please keep the areas affected by any single changeset small, rather than global.
jtracey (2021-06-14 17:45:29+00:00): I agree that edits should ideally be kept more local than this, but it is only fair to point out that all these edits were in one country (Russia), and the only reason the bounding box for the edit is global is that it spans the 180th meridian (specifically, this way is on the other side of it from where most of Russia is: https://www.openstreetmap.org/way/129096772 ).
Lee Carré (2021-07-01 03:40:32+00:00): Ah, I see. Fair enough, then; that's more of a technical glitch (or shortcoming) than human-error 🙂.
tastrax (2021-06-17 02:59:06+00:00): Hi folks FYI - Phone numbers in Australia should be added to OSM according to the following format with the country code +61 x xxxx xxxx, (+61 xxx xxx xxx for mobiles) or use the phone:AU key if a 1300 or 1800 number as per the wiki guidelines https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines - I have just updated a recent addition that you made to OSM – Cheers
neuhausr (2021-06-14 14:25:54+00:00): Hi, I noticed that you added areas for the Sonic and Iberia Bank businesses but tagged them as buildings. 1) since the actual buildings were already mapped and tagged, these area don't seem especially necessary so you might consider removing them, but 2) if you want to map those areas, it'd probably be best to tag them as landuse=commercial. Happy mapping!
adrianojbr (2021-07-28 21:48:10+00:00): Buenas! Cuidado com o CTRL+C e CTRV+V. Abraço!
gscholz (2021-06-16 04:53:44+00:00): Hi Bipin,
your recent changesets have addes several errors to the OSM database regarding not connected ways (red dots):

http://tools.geofabrik.de/osmi/?view=routing&lon=-87.36615&lat=15.16928&zoom=12&overlays=duplicated_edges,duplicated_edges,duplicated_edges_areas,snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6

As you probably know, not connected ways can not be used by routing software.

Can you please fix this?
Guido
Bipin Paudel (2021-07-04 01:25:50+00:00): Thank you for your response. I had fixed it.
gscholz (2021-06-16 04:53:40+00:00): Hi Bipin,
your recent changesets have addes several errors to the OSM database regarding not connected ways (red dots):

http://tools.geofabrik.de/osmi/?view=routing&lon=-87.36615&lat=15.16928&zoom=12&overlays=duplicated_edges,duplicated_edges,duplicated_edges_areas,snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6

As you probably know, not connected ways can not be used by routing software.

Can you please fix this?
Guido
Bipin Paudel (2021-07-04 01:24:57+00:00): Thank you for your response. I had fixed it.
cserpell (2021-06-14 15:00:34+00:00): Hola! En este cambio también corregí lo de layer=-1, y además separé las áreas (escuela, plazas), de las calles o vías.
U+1F98C (2021-06-14 17:50:14+00:00): Gracias por ambas correcciones!

Separar areas de vías también aplica en casos como el de la plaza, donde efectivamente llega hasta la vereda? Asumí que quedaba mejor combinarlo con las vías para no crear nodos "innecesarios" en el mapa; ahora voy a corregir otros edits que he hecho con el mismo error. Gracias de nuevo!
cserpell (2021-06-15 00:16:01+00:00): Gracias a ti por el mapeo, yo antes hacía las mismas cosas. Lo de las vías es porque después alguien se pone a modificar las calles y no se da ni cuenta que pasa a llevar los objetos. Si quieres puedes unirte al canal de telegram de la comunidad en Chile, donde siempre hay aportes y responden consultas https://t.me/OSMcl , si es que no estás ya.
mueschel (2021-06-15 10:08:10+00:00): Hi,
please check this way, it has no valid tags:
https://www.openstreetmap.org/way/954111730
willkmis (2021-06-25 01:14:49+00:00): Hi, and thanks for improving OpenStreetMap! These are apartments rather than houses. One tagging recommendation: for an apartment building, even if it's part of a larger complex, you want to tag it building=apartments. If the entire complex has a name, you can draw a separate area around the complex and tag that landuse=residential and residential=apartments. It's a little confusing, but we want to keep buildings tagged as buildings. I'm going to change the buildings to building=apartments, but feel free to let me know if you have any questions!
user_5359 (2021-06-16 06:01:54+00:00): Welcome to OSM! Please notice: the minimum keys for an address is addr:street and addr:housenumber! Please move your node from the street to main building!
BCNorwich (2021-06-14 06:52:22+00:00): Hi, Welcome to OpenStreetMap.

It's OSM practice to have mao one feature as one element, please see:- https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

Thus I've removed the POI as it duplicates data held on the building outline, I've kept all new data and tweaked the address.

Regards Bernard.