piebro/osm-data huggingface dataset:
Klioda (2019-02-20 06:16:24+00:00): https://wiki.openstreetmap.org/wiki/RU:Key:addr:suburb
demaniac (2019-02-20 07:54:05+00:00): Добрый день. Я сегодня допишу place на всех домах в этом микрорайоне
Klioda (2019-02-20 08:43:33+00:00): Спасибо =) .
GinaroZ (2019-09-29 13:44:48+00:00): Managed to fix this (after I saw the solution posted on reddit), there was a duplicate section here https://www.openstreetmap.org/way/671167498
marc__marc (2023-05-05 22:01:35+00:00): Bonjour,
https://www.openstreetmap.org/way/671662164
pourquoi un 2ieme chemin au même emplacement que https://www.openstreetmap.org/way/168175538 ?
Cordialement,
Marc
Martin Borsje (2023-05-06 04:53:09+00:00): I don't know what exactly you mean about this 4 yrs old edit; The changeset only gives landuse changes (mergers), not any changes to highways (chemins). But adjust when you deem appropriate. Salut!
superkiria (2019-07-21 16:49:32+00:00): Может дорисовать памятник? Там же ещё постамент есть.
Sowa1980 (2019-07-21 22:59:06+00:00): Я знаю , но пока деталями заниматься лень, чуть позже дорисую.
stevea (2019-02-20 02:35:59+00:00): Why are you editing wheelchair accessibility relations?  These are from official university data and are correct by definition.
Helmchen42 (2019-02-20 08:35:06+00:00): Damn - lost a lengthy answer...

I disagree, various paths that were used in these relations are pretty far from being usable.

Sometimes the geometry is rather off:
  The connection to the parking lot between Science and Engineering Library and ISB would have gone across a wall.

Sometimes the data disregards real obstacles:
  Engineering 2 (when terminating at Baskin Circle next to the bus station) would have crossed stairs [Mapillary photos from 2014] - though I think there is a ramp next to it that would terminate at the south end of Engineering Loop, so that would require an additional [currently missing] footway.
  
Sometimes the usability of the data is impaired when the paths are not connected to streets where they should:
  Parking lot between Biomedical Sciences [The disappearing of that building... should be fixed now..] and Science Lib to Red Hill Road
  Parking Lot between Science Lib and ISB to Red Hill Road
  Parking Lot east of Earth&Marine Sciences to Red Hill Road

Also something I already changed two days ago, the path across the parking lot 139 north of Engineering 2 overlapped the parking aisles. In that place I made sure to add a wheelchair=yes to the respective lanes - something I admit, I should have been more vigilant about when editing in the Science Hill area.

As useful as the data should be, it's usability is impaired if the geometry it is based on is inherently flawed, see points above and also some other strange cases of Engineering 2 near the Communications building

I probably should have kept the entrance of the ISB next to ISB Bridge.
abrensch (2019-09-01 13:42:11+00:00): Hallo Martin,

weisst Du, ob die Brücke an der K1 fertig ist?
ma-rt-in (2019-09-03 09:59:44+00:00): Laut der Mitteilung hier ja:
https://lbm.rlp.de/de/aktuelles/detail/news/detail/News/b-47-bundesstrasse-zwischen-albisheim-und-wachenheim-wieder-frei-befahrbar/

Ich erledige das mal, auch wenn es erst morgen frei ist.
rene78 (2019-02-23 10:48:12+00:00): You flooded Dubai ;)
Fixed it again.
maraf24 (2019-02-20 08:17:24+00:00): Wandalizm. Droga jest zamknięta, most nie jest gotowy.
DaveF (2019-02-20 18:04:53+00:00): I thought spark said Trenchard St was still, mostly, accessible by vehicle.
ndm (2019-02-20 21:32:54+00:00): As I said ask talk-GB -- but removing the signed (suspended) onewayness isn't a great idea. The road will likely just get joined back without adding the oneway back as the normal state is lost.

Maybe: use the temporary: prefix then -- temporary:oneway=no, temporary:access=destination

Or if the end date for construction is known make the oneway happen after that date.
freebeer (2019-02-19 22:01:59+00:00): curse your 'bot.
it added a revision to https://www.openstreetmap.org/node/6288207585
which is obviously not there and almost certainly rubbish.
so i can't purge it from the commandline.

had i been half an hour sooner though...
b-jazz (2019-02-19 22:41:20+00:00): Is this just a general venting of frustration, or are you suggesting I should change the behavior of the bot? Maybe not operate on anything object that is younger than a day or week or something?
freebeer (2019-02-20 16:00:27+00:00): well, yeah.   and i dunno.

do you have an idea how much use it will see, that is, is a manual output review feasible to check for quick errors like the postal code error (i assume) for the high school below or phone format to have caught my eye, or is there just so much cr*p out there given even now i have to manually rewrite http: urls in order to hide what i'm doing, that throughput would drop to effectively zero?

i see your diary entry had no comments about unreviewed automated edit drawbacks that i sort of expected to see.

the idea of a holding time is interesting, although i dont know how much delay typically happens between junk SEO entries or vandalism and their detection and reversion.

note that normal editors won't be bothered by my surly anti-social gripe, and i'm trying to think of a case where some SEO has made mincemeat dragging nodes in an edit that is best reverted in full.

or how much undetected cr*p exists like personal addresses with social media links as well as misplaced or purely spammy adverts for online-only non-storefronts, to be able to guess how many would be given an automated seal-of-approval.

note i whine this because several maps.me entries that never should have been public got automagically modified, but that is in countries much worse behaved from accuracy perspective than most of the us, where you're running your bot.
b-jazz (2019-02-20 19:04:01+00:00): A manual output review for the changes I'm making is not feasible. There have been tens of thousands of changes and they are very focused. Only website tags with http where that url redirects to an https url are changed. And only the website tag is changed. The volume is too high to manually review this and the change is so very specific that it really doesn't need to be reviewed. The fact that there are other things wrong with an entity shouldn't be the concern of the bot. That will happen all the time and can't be avoided.

I imagine that there are tools already out there that look for improperly formatted things like postal codes and phone numbers and put them up for manual review. Maybe something like KeepRight already does this.

As for the drawbacks of unreviewed automated edits, I'm sure there are many, but I think I've done a pretty good job in keeping the types of changes so laser focused and well defined that it is hard to argue that the changes I'm making are in any way a problem.

As for how often this will affect you, I think the chances are pretty low. I'd love to hear otherwise of course. In the future, it will probably run maybe weekly or monthly. So the chances that someone creates a crappy entry that also happens to have a website that is http that will redirect to https and have this get created and caught by the bot script before you get to it is low.

Also, I'm not sure why you can't simply revert the bot's changeset, and then revert the bad SEO edit. You will be reverting a few other of the changes that the bot has made in that particular changeset, but you shouldn't worry about that, it will remake the changes a week or two later when it goes to process everything again.

Also, at some point, this bot will likely be run across the entire planet. So if you have any ideas (like not modifying brand new entries that are less than a week old), we should definitely work those out.
freebeer (2019-02-21 21:05:50+00:00): Yeah, no worries, i figgered it would be a lot more than my slow feeble brane could handle before i forget what i'm doing.

i just noticed that in such a large area here, the number of entries affected was so small that i was able to comfortably review a couple entries without  digging for them.  since i am still at the point where the 'bots i wrangle require manual review and a double-confirmation, well, you get the picture.  that's why i've not finished correcting all the errors and flaws in the canvec import yet, as i should have done by now.

i'm pretty sure i'll never encounter your bot again,  so no need for us to cross the street to be out of each other's way.

the idea of a grace period became a bit more appealing a few minutes ago when i was thinking there might be people or tools out there who make it a point to look at v1 edits of a particular type (maybe those with URLen containing `xxx' like the `hotel' here ;-) on an occasional basis, and  i can't see any urgency in the functions performed by avoiding the redirect in v2.

so just ignore me, it's probably the best overall advice i can give.  cheers
Geofreund1 (2019-05-22 09:31:28+00:00): Hallo BeKri,
der Campingplatz Schloss Kirchberg trägt lt. Website die Adresse Schloss Kirchberg 1, Immenstad. Diese Adresse hast du einem Gebäude am Eingang des Campingplatzes zugeordnet. Dieselbe Adresse gibt es nun dummerweise lt. OSMsuspects! 674 m weiter östlich noch einmal. Dort wird sie auch lt. Maps4BW verortet. Was könnte denn nun richtig sein??
BeKri (2019-05-22 14:45:09+00:00): Servus Geofreund1,
naja genau genommen habe ich den Eintrag der Adresse auf der Fläche
https://www.openstreetmap.org/way/438988296/history auf das Gebäude umgesetzt um zusammen mit dem verschieben von Grenzpunkt https://www.openstreetmap.org/node/2172313924 das bekannt Problem "ich kann mich nicht entscheiden zu welcher Seite der Grenze ich gehöre"
 zu vermeiden. Was richtig ist weiß ich nicht.
streckenkundler (2019-02-20 09:27:46+00:00): Hei,

kleine Frage/ kleiner Tip...Welchen Luftbildhintergrund verwendest du? Bei Josm hat man ja eine recht gute Auswahl.

Ich versuche Objekte möglichst nach Mapbox oder Esri World Imagery (Clarity) Beta (sind die selben) auszurichten. Diese sind hierzulande meiner Beobachtung am lagegetreusten (aus wenn sie älter sind). Gerade bei Straßen und Gebäude und so mache ich das. 

Bing ist zwar neuer, hat aber z.T. einen üblen Versatz. Manchmal erfasse neuere Sachen nach Bing, richte die aber dann nach Esri World Imagery (Clarity) Beta/Mapbox aus.

Grüße aus der Nähe,

Sven
romeoko (2019-02-20 09:56:06+00:00): Hi,
ich benutze sekundär durch umfangreiche GPS-Tracks in JOSM korrigierte Bing-Maps.
Primär nutze ich in diesem Bereich jedoch an meine Tracks ausgerichtete Katasterkarten.
Allerdings muss ich gestehen das ich im Nördlichen Teil Baruths noch nicht allzu weit bin...
Werde mich in den nächsten Wochen um noch einige Details kümmern.
Und ja, die Bing-Maps sind hier in der Gegend unkorrigiert auch stark verschoben. So ungefähr 1,5-2m in Richtung Westen.
Aber du darfst mich gerne im Auge behalten. Ich gehöre ja eher noch zu den Semis...
Ich könnte manchmal auch gut einen Mentor brauchen.
Gruß aus Baruth,
Romeo
streckenkundler (2019-02-20 10:24:20+00:00): Hei.

Der Bing-Versatz ist im Spreewald noch übler..., teilweise 4-6m und mehr.

Ich nutze ja die unterschiedlichen Luftbildquellen dienstlich auch außerhalb von OSM in Gis-Anwendungen (QGis), hauptsächlich wegen Vegetationsvergleiche und so. Deshalb hatte ich für mich mal eine Lageprüfung gemacht. Bei Esri World Imagery (Clarity) Beta/Mapbox habe ich in der Regel kaum Versatz zu den offiziellen Bildern des LGB, weshalb ich für mich auf diese manuelle Korrektur verzichte. In meinen Augen bringt das auch nur was, wenn die Lagekorrektur, die man individuell einstellt, auch 1:1 von dritten nachgenutzt wird. Ansonsten sieht ein Dritter die Objekte an einer nicht nachvollziebaren Stelle und fragt sich 'Hä? was hat der denn da gemacht?'

Bing hat den Vorteil, daß es neuer ist und (da es Sateliten-Bilder sind) Gebäude schön von Oben aufgenaommen sind. Bei Esri World Imagery (Clarity) Beta/Mapbox kippen dagegen die Gebäude gerne mal übel um, ist aber recht gut lagegetreu.

Es ist schade, daß wir die LGB-Luftbilder nicht nutzen können.


Ansonsten, wenn du Fragen hast, kann ich gerne unterstützen. Eine gute Hilfe ist auch immer das Forum: https://forum.openstreetmap.org/viewforum.php?id=14

Grüße,

Sven
Eebie (2019-02-24 23:20:25+00:00): Ik heb Fietssnelweg F79 tussen Jesseren en Hasseltsesteenweg Tongeren op state=proposed gezet, waardoor deze niet meer als bruikbare fietsroute opgenomen is in routeplanners en Waymarked trails. Dat stuk gaat over een spoorwegzate die (nog) niet toegankelijk is voor fietsers en gepland is voor realisatie tegen 2022. Vorige jaar had mijn fietsrouteplanner een stuk over de F24 meegenomen in de buurt van Lovenjoel dat al in OSM stond als gerealiseerd. In plaats van een fietssnelweg kreeg ik heel smal zanderig paadje onder de wielen waar ik moest afstappen bij gebrek aan een MTB. Toen heb ik F24 ook als state=proposed gezet om dat anderen te besparen.
Polyglot (2019-02-24 23:46:09+00:00): Ik ga ze nagenoeg allemaal afrijden. Wat ik dan gewoonlijk doe, is de geplande versie als incomplete aangeven, maar proposed kan daar zeker ook aan worden toegevoegd.

Daarnaast maak ik, waar mogelijk ook een alternatieve route die fietsers vandaag al van de ene stad naar de andere kan brengen.

De eerste week van maart kom ik een paar dagen naar Hasselt, misschien kunnen we 's avonds eens afspreken. Ik heb een AirBNB gevonden in Diepenbeek.
eggie (2019-02-20 08:39:54+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.
eggie (2019-02-20 08:47:33+00:00): Het "vergeten" stukje bij de rotonde  met de "foute" naam is net gecorrigeerd door een andere mapper zie ik.
Rendering duurt altijd even.
MVG,
Eggie
stevea (2019-02-20 02:34:41+00:00): Why are you changing Natural Reserve boundaries?  These are official university shapefile polygons and are correct by definition (or at least they were when they were originally uploaded).
stevea (2019-02-20 03:17:50+00:00): Please read https://wiki.osm.org/wiki/Santa_Cruz_County,_California#Local_Conventions
Helmchen42 (2019-02-20 07:56:56+00:00): "assume it is wooded except where it is tagged otherwise" is the problem. The Natural Reserve areas were/are also tagged with "natural=wood" - and I think I can see why it was supposed to be like that, they are in large parts covered by trees and is probably considered a forest as a whole in regards to laws and other relevant topics.

However the actual outline of area covered by trees is different - "except where it is tagged otherwise" - okay, we are kind of missing fitting area=residential, area=highway, landuse=meadow, natural=scrub to fill the gaps but I wanted the natural=wood to represent the outline more accurately than a shapefile originating from the designation of the protected area.

So what I did was copying the geometry of the protected area to have a starting point, included "natural=wood" and then edited the outline of the copy to more closely resemble reality. Finally I removed only "natural=wood" from the original protected area so there are no overlapping areas of "natural=wood" in the data.

Roughly spoken, a forest without trees should not be tagged as a forest in OSM.
stevea (2019-02-20 18:40:17+00:00): Not a forest, that's where there is logging activity and the natural reserves are certainly not that.  There are no tagged forests at UCSC.

The polygons which ARE tagged forest in this county are "Zoning=TP" (timber production), which matches the OSM defenition.

"More accurately than a shapefile originating from the designation of the protected area?"  How can you get more accurate than that?

The answer is how it is done:  "assume it is wooded except where it is tagged otherwise."  This is one of the most heavily wooded university campuses on Earth.  It is surrounded by state parks and open space preserves which are also heavily wooded.

It is not "considered a forest as a whole" (there is no logging activity) it is considered wooded.  Laws have nothing to do with it.
Helmchen42 (2019-02-20 18:45:57+00:00): As far as Iunderstood it till now:
landuse=forest --> logging activity et cetera This is not what I changed and not what I wanted to specify.

natural=wood --> originally any area littered with trees that is specifically not landuse=forest.

If the campus is "wooded except where tagged otherwise", wouldn't it be better to add natural=wood or anything to /way/670613089 ?
stevea (2019-02-20 19:10:02+00:00): Right, I know you didn't want to change forest, but you said "forest as a whole" (in your text above).  It is crucial that we understand that in OSM, "forest" means "logged land."  The campus and parks are not that.

However, they are wooded and then we begin the endless confusion in OSM regarding landuse vs. landcover.  It is confusing, people tend to tag for the renderer when they shouldn't, et cetera.

The reason the campus boundary is not wooded is that that really IS tagging for the renderer.  It is better, as we say in Local Conventions, "assume it is wooded except where it is tagged otherwise."  This allows its primary purpose of "university" to render.

If we go down your path of tagging natural=wood, now many will want to do that to leisure=park, leisure=nature_reserve and so on.  It gets horribly complex when you bump up against other polygons such as landuse=forest and even landuse=residential, which are often, too, also heavily wooded around here, even with houses and people living there.  Do we really want landuse=residential + natural=wooded?  Simply because "it might look better" on the renderer?  I don't.

As this is PRIMARILY a university campus, and your tag proposal is largely to tag for the renderer, both OSM tenets of not doing that and local consensus has found that not adding natural=wood to the university (keeping its rendering as is, a university) is best.  Yet, to further emphasize that the natural reserve areas are protected and almost exclusively wooded areas, (yes, parts of Lower Moore Creek Natural Reserve are part meadow) we do additionally tag them natural=wood.

I've worked with many university staff, officers, faculty, architect, land steward, transportation officers, etc. as well as developing local consensus over nearly a decade, while still remaining "true" to how OSM does things.  Yes, it's complicated around here.  Yet it's also "as simple as we an make it so most everybody is happy with the results."
abakus_uploader (2019-02-20 23:30:51+00:00): (Wiadomość automatyczna)
Cześć!
Otrzymujesz ten komentarz, ponieważ dodałeś lub zmodyfikowałeś adres, który jest niepełny lub błędny.
Adres powinien zawierać minimum trzy znaczniki: addr:city=[nazwa_miejscowosci] + addr:street=[nazwa_ulicy] + addr:housenumber=[numer_porządkowy].
Wyjątkiem są miejscowości bez nazwanych ulic - wtedy stosujemy znaczniki: addr:place=[nazwa_miejscowosci] + addr:housenumber=[numer_porządkowy].
Bez poprawnego oznaczenia adresów, nie będą one brane pod uwagę przez wyszukiwarki, dlatego warto je dostosować do ww. schematu (w zależności od sytuacji).
Więcej informacji na forum: https://forum.openstreetmap.org/viewtopic.php?id=5632 - a pytania najlepiej zadawać tu: https://forum.openstreetmap.org/viewtopic.php?pid=681873
Pozdrawiamy!
WoodWoseWulf (2019-02-20 03:51:51+00:00): Okay, I'm really going to have to ask here: what's the obsession with changing everything to recreation grounds?
ŋƎŋ (2019-02-28 13:38:43+00:00): Warum hast du so viele Änderungen vorgenommen, die gar nicht richtig sind?
BeKri (2019-03-14 09:05:33+00:00): Hallo,
was ist gar nicht richtig ?
Ich bin bei der Landuse=residential  von Metzgersbrunn aus versehen die O=Kreistaste gedrückt , bin von Seewälder darauf hingewiesen worde,
siehe 
https://www.openstreetmap.org/changeset/67203384
und habe es "zurückgeschoben".
Was stimmt jetzt nicht ?
Gruss und happy tagging derBeKri
DiogoBaptista98 (2019-11-21 10:18:45+00:00): A Subestação https://www.openstreetmap.org/way/544250916 editada por ti nao pertence à EDP e não RER? Cumprimentos
topolusitania (2019-11-22 00:27:59+00:00): Olá
Só corrigi a tag inicial do alentejano93. para substation. Não alterei a tag inicial operator que deixei como REN. Investigado agora o tema, parece que a EDP distribuição diz que é dela  ;-). Podes e deves corrigir, já que estás no tema. Bom trabalho
TL
Nmxosm (2019-02-20 13:11:52+00:00): Hallo Saihttam26,

welchen Zweck hat das Aufteilen der Wege in diesem Änderungssatz? Ich kann spontan keinen erkennen.

VlG Nmxosm
Saihttam26 (2019-02-21 11:53:01+00:00): Vorher konnte man von Norden kommend nicht in die Heisterstraße abbiegen, wenn man eine Route geplant hat. Das habe ich versucht zu beheben, um die Routenplanung zu verbessern. Wenn ich etwas falsch gemacht oder verstanden habe, kann es gerne rückgängig gemacht werden.
Saihttam26 (2019-02-21 12:00:22+00:00): Allerdings habe ich nur versucht die erlaubten Fahrrichtungen zu ändern. Wenn dabei Wege aufgeteilt wurden, war es nicht meine Absicht.
Nmxosm (2019-02-22 12:09:32+00:00): Tatsächlich hast du fast alles richtig gemacht. Das wichtigste war, dass du https://osm.org/relation/1450238 entfernt hast. Damit ist die Abbiegemöglichkeit schon gegeben.

Möglicherweise hat auch der iD Editor ohne dein Zutun die Wege aufgeteilt. Ich habe jetzt die Wege wieder zusammengefügt: https://osm.org/changeset/67463753

VlG Nmxosm
Saihttam26 (2019-02-22 20:36:10+00:00): Das kann sein. Vielen Dank fürs Ausbessern!
vgeorge (2019-02-20 12:46:05+00:00): Olá Gustavo, obrigado por colaborar com o OSM. Sobre esta edição, o ideal é sempre incluir nomes sem abreviação, pois isto facilita algoritmos interpretarem a informação completa. Esta prática ajuda a melhorar os resultados de busca de locais, por exemplo. Abraços, Vitor.
viloan (2019-02-20 02:31:09+00:00): Bem-vindo(a) ao OpenStreetMap e parabéns pela sua primeira edição! :-)

Temos um portal brasileiro sobre o OpenStreetMap, com várias informações úteis em https://wiki.openstreetmap.org/wiki/Brasil

Enquanto você está se acostumando com o OpenStreetMap, é recomendado que sempre pergunte aos usuários mais experientes antes de remover ou modificar objetos do mapa, especialmente aqueles que são aparentemente "estranhos" ou "fora do lugar".

Além disso, pedimos que não copie dados de mapas proprietários (como nomes de ruas do Google Maps, por exemplo) e que mapeie apenas o que existe na realidade.

Se você está mapeando por causa do Pokémon, dê uma olhada em https://blog.openstreetmap.org/2017/12/01/dicas-para-novos-mapeadores-pokemon-go/?lang=pt-pt

Se tiver qualquer tipo de dúvida você pode entrar em contato com a comunidade brasileira através de algum dos canais disponíveis em https://wiki.openstreetmap.org/wiki/Pt:Contact
O canal "Comunidade" do Telegram costuma ser o mais movimentado.

Abraço e boa diversão com suas edições!
JoePlunkett (2020-08-15 20:17:29+00:00): 158 arvitt rd dickson tn 37055
JoePlunkett (2020-08-15 20:28:09+00:00): should be 158 arvitt rd
AndrewSnow (2020-08-22 07:34:36+00:00): Fortunately, the note you had created and closed showing where your house is was still fresh enough I could find it.  In the future, so similar needs, notes are the way to go.  Commenting on a changeset only tells us the thing that needs to be changed is somewhere in a pretty large area.  All the best.
ForstEK (2019-05-21 07:07:45+00:00): Здравствуйте, John77! Исправил объекты из Вашего пакета правок (https://www.openstreetmap.org/changeset/70465914) согласно принятой схеме тэгирования: https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dpipeline
Firefishy (2019-02-20 10:19:01+00:00): Nice first edit! Thank you for helping to improve the map. What is next? ;-)
DomZA (2019-02-20 10:26:24+00:00): Thanks a lot! Going to keep editing the surrounding areas, there are a few parks not completed. :)
mtchk (2019-02-20 09:44:14+00:00): Не стоит править объекты по картам Bing, не используя смещение.
ovruni (2019-02-20 07:30:39+00:00): Hola
¡Cual es la imagen aérea que se esta usando para poder ver si la vía tiene o no un doble sentido?
Cualquier consulta la puedes hacer en https://wiki.openstreetmap.org/wiki/ES:Per%C3%BA#Blog_y_redes_sociales
Saludos
Omar