piebro/osm-data huggingface dataset:
Henosb (2022-01-05 00:25:55+00:00): I added the `motor_vehicle=private` tag because it is connected to a gate and service highway with the same tag. Without any additional restrictions, the `oneway=yes` tag forces any vehicle into this private area. The image you linked shows a vehicle facing west. Do you think it would be most appropriate to remove the `oneway=yes` tag?
literan (2022-01-05 11:05:00+00:00): Yes, I think it's a good idea. There is no road signs for 'oneway' here on yandex
pkoby (2021-12-27 19:44:40+00:00): Thanks for adding this to the map. It came in handy for me today!
عثمان ਉਸਮਾਨ bgo_eiu (2021-12-27 22:57:57+00:00): Glad it was helpful!
Swedneck (2021-12-25 15:47:17+00:00): Hi.
I see you're making multipolygons where normal areas would be sufficient, it would be preferable to only use multipolygons when strictly necessary since they make it more difficult to edit things and maintain the map.

Merry Christmas!
archie (2021-12-25 16:09:46+00:00): Jag hävdar motsatsen. Av erfarenhet vet jag att det är jobbigare att efteråt editera när det inte är mp.
NiLaKol (2021-12-26 15:21:45+00:00): I'm not part of the Indonesia community, so please apologize, if my assumption is wrong. This change seems to be part of a semi-automatic edit, that removes the admin_level=provinsi tag. But there it seems common that government buildings have a admin_level tag.
So, what is the main reason for this change and was this discussed with the Indonesian community?
Friendly_Ghost (2021-12-26 16:38:11+00:00): Hi there. Thanks for having a look at my edit. 

It's not common as only a few dozen of these buildings had the tag. This use is not what admin_level=* is intended for, so I cleaned it up. I looked at each individual case, and they are many years old, so the tag doesn't seem to be actively used.
NiLaKol (2021-12-26 17:46:42+00:00): Thanks for your answer. Looking on taginfo for admin_level=* + building=* gets 9882 results. An Overpass query with way[admin_level][building=yes]; has ~4118 results in Southeast Asia. You say "This use is not what admin_level=* is intended for" you might be right on an european point of view. Maybe on a local point, this use is intended in Indonesia, I don't know that as european. Therefore my concerns.
Friendly_Ghost (2021-12-26 20:03:44+00:00): I wouldn't call my POV European per se, as I'm just following the documentation relevant to admin_level=*. The tag I removed wasn't a number or in English, as is customary in OSM, it's not consistently used and it's undocumented, which is why I am treating it as a tagging mistake, as so many tags in OSM. If you know about an alternative tag that would fit in its place I would be happy to add it.
adiatmad (2021-12-28 01:29:17+00:00): Hello NiLaKol and Friendly_Ghost. Hope you both don't mind if I jump here.

I'm Indonesian and did a survey for the government building in the past.
The previous editor tried (i.e https://pewu.github.io/osm-history/#/way/140477843) to describe this government building at for Province level.

The alternative tag is "admin_level:4" to describe Province Level government building, even though it is primarily used for the borders of territorial political entities as Wiki OSM said (https://wiki.openstreetmap.org/wiki/Key%3Aadmin_level).

Would love to know another suggestion.
Cheers.
Friendly_Ghost (2021-12-28 02:19:13+00:00): Hello and thank you for joining the conversation. 

I just read the documentation a bit better (which I should have done sooner), and I found that https://wiki.openstreetmap.org/wiki/Tag:office%3Dgovernment mentions admin_level=* as a useful combination with office=government "to indicate the administrative level (national, provincial, etc)."

With that bit of information and the OSM convention to give numbers to admin_level=* tags (https://wiki.openstreetmap.org/wiki/Key:admin_level), I'll make an effort to restore the tags and change them to admin_level=4, which corresponds to the provincial level, if that's okay with you.

My apologies for my inconsiderate deletions of this tag, but I hope the restoration that I plan to do tomorrow will make up for it. I might also update some Wiki pages once I've done more research following NiLaKol's information that many more buildings contain an admin_level tag. 

@adiatmad May I ask you to look for more admin_level=* tags in Indonesia that are not a number? I've seen on Taginfo that there are a few and I suspect that some of them are also in this country, so we might be able to improve those tags as well.

I hope we can settle the matter this way together. Good day to both of you :)
adiatmad (2021-12-28 14:40:18+00:00): @Friendly_Ghost
Thank you for your detailed information. 

Sure, I have to take a look (https://overpass-turbo.eu/s/1ezT) and found many questionable values for tag "admin_level=*". My plan is to fix them starting from my hometown. Hope more local people join to improve the map as well.

Anyway, I don't see any trouble from this edit so no need to apologize, we can still improve our mapping's way together. Thank you for your kindness.
Cheers.
Friendly_Ghost (2021-12-29 10:21:49+00:00): Hi again. I've restored admin_level tags for all 30 governments for which I had removed the tag earlier. admin_level=Provinsi is now admin_level=4. 
Have you been able to make any progress with the other questionable values yet?
adiatmad (2022-01-03 07:44:36+00:00): Hi Casper. Thank you for restoring them. 
Yes, I modified some questionable values. But more data need to confirm with further ground check or information.
tlconrd (2021-12-25 03:54:13+00:00): see this page if you don't believe me https://www.nps.gov/deva/learn/nature/wilderness.htm

"Everyone is free to hike or ride horses throughout the wilderness"
user_5359 (2021-12-25 16:50:06+00:00): Welcome to OSM! Please explain the node which was named with F!
mariotomo (2021-12-26 17:36:40+00:00): tu no sabes qué es un service=driveway, ni quieres saberlo.  que le vamos a hacer.  continuiamo cosí, facciamoci del male.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/115351927
SherbetS (2022-03-14 16:51:27+00:00): Hey Hiausirg,

why did you reclassify these roads as track?
https://www.openstreetmap.org/way/1015192508
https://www.openstreetmap.org/way/9309955

it looks like people live on these roads, so I think that they should be residential instead.
Kovoschiz (2021-12-25 10:31:34+00:00): Can you at least transfer tags completely even if you are deleting to re-draw. It's a very low requirement for your undesirable practice.
mosstreet (2021-12-25 10:04:32+00:00): Вот не пойму зачем в Брянске улицу на украинском указывать, это что по русски окраинцы читать не умеют или еще какая новая возжа у них, да и с белорусским мне не понятно
mosstreet (2021-12-25 10:09:05+00:00): в ПКК  улица Имени Сергея Андреевича Халаева
iWowik (2021-12-27 08:25:19+00:00): Про Халаева это к Кремлёвскому штурману.
https://www.openstreetmap.org/way/258249013/history
iWowik (2021-12-27 08:36:41+00:00): Пересмотре правку, ничего про украинский не нашел.
user_5359 (2021-12-26 16:56:47+00:00): Hello! Please check my correction of this change set , see https://www.osm.org/changeset/115393061
trial (2024-08-18 11:11:28+00:00): Bonjour :
https://www.openstreetmap.org/node/8662774718
https://www.openstreetmap.org/node/2125707539
possiblement à combiner : la plaque est sur la fontaine. J'hésite, c'est le duplicat sur la carte qui m'a amené à ce doute.
Cleveland steamer (2022-01-12 16:14:54+00:00): highway=motorway is wrong
maraf24 (2022-01-30 23:19:16+00:00): Wycofane w https://www.openstreetmap.org/changeset/115374337
Kettendehner (2021-12-25 12:48:38+00:00): Hallo abrensch,

danke für die Mitteilung. Leider bin ich im Zuweisen von Tags nicht unbedingt gut bewandert, deswegen kann es durchaus sein, dass einer falsch zugewiesen ist. Die Verortung der Punkte und Straßenführung stimmen aber bei mir immer. Was nichtmehr hingehört, kommt weg und was neu ist, kommt (notfalls auch nur mit Oberfläche und einfacher Eigenschaft) dazu.

Aber um auf Deine Frage zurückzukommen: Ja, der südliche Teil ist fertiggestellt, der nördliche Teil ausser Betrieb bzw. schon weggefräst. Auch das Stück B10 bis zur Ausfahrt Burlafingen existiert gerade nicht mehr (deswegen 'construction'...)

Wenn ich mir die aktuellen Daten anschaue, ist das, was ich aus diesem Grund geändert habe nun wieder auf dem alten, falschen Stand.
Deswegen wäre es doch ganz nett, wenn Du das wieder reparieren würdest (ich weiß nämlich nicht, wie das geht und habe keine Lust, mir die betreffenden gpx-Daten aus meinem GPS rauszusuchen) und evtl. nächstes Mal erst mal vor Ort schaust (wenn Du schon weißt, dass dort im Moment alles im Fluss ist)?

Danke. Frohe Weihnachten und einen guten Rutsch.

Matthias
maraf24 (2022-01-30 23:18:26+00:00): Wycofane w https://www.openstreetmap.org/changeset/115374324
user_5359 (2021-12-26 08:47:43+00:00): Hallo! Kleiner Hinweis zu Weg http://www.openstreetmap.org/way/1015229054. Sprachen werden mit zwei Kleinbuchstaben abgekürzt. Also name:de anstatt name:deutsch(2). Das Komma am Ende des Wertes von name:deutsch(3) ist mit Sicherheit ein Kopierfehler. Ich würde zu einem alt_name:de tendieren.
habi (2021-12-28 10:02:17+00:00): Ciao Thrhosm
Du hast in diesem ersten Änderungssatz [1] einen Knoten ohne jeglichen Tag hochgeladen.
Der Kommentar 'car' zum Änderungssatz macht leider auch nicht klar, was du eintragen oder beitragen wolltest.
Kannst du mir das erklären, dann können wir gemeinsam die Daten verbessern.

E liebe Gruess usem Liebifäud,
habi



[1] Herzlich Willkommen bei OpenStreetMap, schön bist du dabei!
habi (2022-01-11 17:18:46+00:00): Da nach gut zwei Wochen keine Rückmeldung kam, habe ich den Knoten hier gelöscht: https://www.openstreetmap.org/changeset/116033030
maraf24 (2022-01-30 23:17:44+00:00): Wycofane w https://www.openstreetmap.org/changeset/115382791
Andrea Musuruane (2021-12-27 17:12:40+00:00): Ciao Walter, l'osmc:symbol inserito su questa relazione è errato. Ciao, Andrea
KennethSui (2021-12-28 03:33:17+00:00): Dear sunxinyue2001, please adhere strictly to the editorial norms and use the native language of the region for labeling purposes.
请严格遵守编辑规范，使用该地区的母语进行标注。
편집 규칙을 엄격히 준수하고 이 영역에 한국어 추가를 중지하십시오.
Herman Lee (2021-12-28 03:41:32+00:00): 现在将您的更改退回
Nonexhudlix (2021-12-26 21:00:33+00:00): Die Johann-Philipp-Reis-Straße (way/1015232792) ist meiner Meinung nach keine Einbahnstraße und hat auch keinen Gehweg links (das wäre ja an der Mittelinsel).
Andrea Musuruane (2021-12-27 17:15:29+00:00): Ciao Walter, l'osmc:symbol inserito su questa relazione è errato. Ciao, Andrea
noelbov (2021-12-25 21:52:18+00:00): Waarde Lieky,
Kan je aangeven (om andere mappers te helpen) wat je precies hebt ge-updatet en welke uw bron is (eigen survey of website of iets dergelijks).
Ik stel namelijk vast dat de fietsknooproute 53-80 onderbroken is door die updates (zie https://www.knooppuntnet.nl/nl/analysis/route/214314 ). Misschien is die enkelrichting in Heymansstraat en Pastorijstraat niet bedoeld voor fietsers (en lichte brommers).
Bedankt voor antwoord.
noelbov
Lieky (2021-12-29 17:40:05+00:00): Momenteel worden de Heymansstraat en het begin van de Pastorijstraat opnieuw aangelegd en die zullen voor auto's éénrichtingsverkeer zijn, voor fietsers is dat nog niet duidelijk maar ik verwacht dat deze in beide richtingen kunnen rijden. Ik woon zelf in de aansluitende Vendelmansweg en ik heb de plannen van de heraanleg kunnen inkijken.
noelbov (2021-12-30 11:41:19+00:00): U hebt de tag oneway:bicycle=no toegevoegd zie ik, waarvoor dank.
noelbov
Andrea Musuruane (2021-12-27 17:12:51+00:00): Ciao Walter, l'osmc:symbol inserito su questa relazione è errato. Ciao, Andrea
artuuurs (2021-12-28 21:06:20+00:00): Diemžēl tas ir ārprāts, ko Jūs šeit esat izdarījis. Salīdziniet trases pēc Jūsu izmaiņām šeit https://openskimap.org/#13.75/56.83133/26.17678 ar trasēm pirms izmaiņām - https://failiem.lv/u/x5hu4q69g
Apmēram puse no posmiem ir izdzēsti.
UrSuS (2021-12-28 21:30:09+00:00): Vismaz tagad tie sakrīt ar karti kura ir pieejamā oficiālā mājaslapā. No kurienes bija iepriekšējie dati nebija norādīts
artuuurs (2021-12-29 13:56:48+00:00): Vai tas, ka nebija norādīts, no kurienes ir iepriekšējie dati, ir iemesls tos vienkārši izdzēst? Es pats izslēpoju visus trases posmus, ielādēju GPS Traces un uzzīmēju no tiem. Jūsu avotā ir vienkārši daži no apļiem, bet tur nav visi trašu posmi, tur arī netiek apgalvots, ka tās ir visas trases. Es tiešām nesaprotu, kāpēc kaut kas bija jādzēš ārā, ja trases tur ir - aizbrauciet un apskatieties! Ja bija vēlme izveidot Routes ar oficiālajiem apļiem - lūdzu, dariet tā - man nav nekādu iebildumu, ja Jūs pievienojat jaunas lietas. Manuprāt, ja Jūs vēlaties kaut ko no kartes izdzēst, Jums ir jābūt pārliecinātam, ka tas objekts dabā vairs neeksistē. Es esmu zīmējis šīs slēpošanas trases - tas ir n-to stundu darbs un man ir ļoti nepatīkami, ka kāds tās ņem un vienkārši izdzēš. Turklāt sistemātiski (arī Salaspils botāniskā dārza trasē). Kā mēs risināsim šo situāciju? Laimīgu Jauno gadu!
artuuurs (2021-12-29 14:02:02+00:00): Smeceres silā ir marķēti krāsu apļi - šie 5, kas ir pdf failā. Ir vēl arī melnais, kurš nav pdf, bet ir marķēts dabā ar plāksnītēm. Piekrītu, ka tas ir svētīgs darbs izveidot jaunus Routes ar šiem apļiem, lai cilvēkiem, kuri vēlas izslēpot tieši šos apļus, būtu iespēja tos aplūkot kartē. Bet, lūdzu, saprotiet - ja Jūs atrodat kaut kādu maršrutu kaut kur internetā, tas absolūti nenozīmē, ka šis maršruts ietver pilnīgi visus posmus. Tāpat kā mežā var būt miljons taku, bet ir arī kāds konkrēts pastaigu maršruts ar daiļskanīgu nosaukumu - tas nenozīmē, ka citas takas ir jādzēš ārā :)
artuuurs (2021-12-29 14:04:28+00:00): Turklāt Jūsu avots - pdf fails - ir vecs, 2021. gada februāris :)
UrSuS (2021-12-29 14:13:22+00:00): Vecs gan :( bet diezgan svaigs/aktuāls nekā dati bez avota. Labākais variants jūsu gadījumā slēpošanas laikā nofočēt ar Mapillary un ielādēt. Un pēc tam OSMā vismaz norādīt source Mapillary. Un vēl nevajag likt papildus ways tiem posmiem kuri iet pa ceļiem vai takām. Tos jāliek relationā. Atvainojos par izdzēstiem datiem, jo cenšos tīrīt OSM no šāda tipa datiem kuri izskatās nepārbaudīti :(
Cristoffs (2021-12-25 14:59:41+00:00): Tak się takich miejsc nie oznacza. Proszę zapoznaj się z wiki i popraw w zależności od tego zo chciałeś oznaczyć
maraf24 (2021-12-26 14:36:42+00:00): Tu już nic nie ma i nie będzie
https://www.openstreetmap.org/node/9365349358
https://www.openstreetmap.org/node/9365349357
maraf24 (2021-12-26 14:39:41+00:00): Kształ tego budynku się zmienił:
https://www.openstreetmap.org/way/1015240193
To jest budynek w budowie:
https://www.openstreetmap.org/way/1015240191
https://www.openstreetmap.org/way/1015240192
charl3s (2021-12-26 14:45:39+00:00): No nie będzie, ale później gdzieś te adresy się plączą, a tak już są w OSM i nie przeszkadzają.
charl3s (2021-12-26 14:46:02+00:00): Budynki później sprawdzę
maraf24 (2021-12-26 17:15:40+00:00): Adresy przeszkadzają, raz, że są już nieaktualne, dwa, że są błędne - mają nieprawidłową nazwę miejscowości.
Dodam, że ja je już dwa razy stąd usuwałem.
charl3s (2021-12-26 17:23:24+00:00): a, to sorki, nie wiedziałem.
charl3s (2021-12-26 17:26:11+00:00): A o którą nieprawidłową nazwę miejscowości Ci chodzi? Zahajki? Wygląda, że jest dobrze. Tak czy siak usunąłem te dwa adresy.
charl3s (2021-12-26 17:52:09+00:00): Co do https://www.openstreetmap.org/way/1015240191
to na 99% już nie jest w budowie, bo w 99% przypadków adres jest nadawany po odbiorach budynku, a wcześniej tam nie było innego domu, a jeszcze adres jest z końcówką B.
A ten kolejny tak - jest w budowie.
maraf24 (2021-12-28 20:49:14+00:00): Adres jest często nadawny w trakcie budowy, a zdarza się, że nawet przed jej rozpoczęciem.
Informacja o budowie pochodzi wprost z GUGIK, bo tak jest tam ten budynek oznaczony.
charl3s (2021-12-28 21:34:02+00:00): Ja się nie spotkałem z nadawaniem adresu przed budową, w trakcie też niezbyt często, a głownie po wybudowaniu gdy ktoś myśli o wprowadzeniu się.
GUGIK to chyba tego WMSa z ewidencją tylko hostuje, a danymi zajmuje się starostwo. 
np. w lubartowskim dane od 3 lat są średnio aktualizowane, dużo budynków brakuje, niektóre są przerywaną linią jakby były w budowie, a ktoś tam już mieszka.
maraf24 (2021-12-28 21:54:34+00:00): Może tak jest przy pojedynczych domach, przy osiedlach adresy potrafią się pojawić w różnych momentach. Nawet obrysy budynków mogą się pojawić przed rozpoczęciem budowy. Oczywiście im wcześniejszy etap tym mniejsze prawdopodobieństwo, jednakże jest to na tyle częste, że ja się tym nie kieruje przy mapowaniu.
W budynku, który formalnie jest w budowie, może ktoś normalnie mieszkać, i nawet nie mieć nadanego adresu.
Ja wolę mapować to co widzę - więc jak nie widzę gotowego budynku, tylko w budowie, to go oznaczam jako w budowie (choć może i w tej chwili jest już skończony i zamieszkały-ale tego nie wiem).
maximaximax (2025-01-13 16:41:22+00:00): Привет, откуда тут взялась ЛЭП, да еще на 220 кв? На космоснимках ничего такого нет
hwak1 (2025-01-13 16:48:44+00:00): на osm довольно старые снимки. ЛЭП и подстанцию увидите на снимках яндекса и гугла.
maximaximax (2025-01-14 09:46:59+00:00): Спасибо, действительно на гугле вижу. Но разве можно использовать гугл для рисования? Риторический вопрос :(
bxl-forever (2021-12-25 15:57:41+00:00): Hello,

Mechanical edits are a bad thing in OSM.

Sure, there is a general rule in Belgium that a cycle path is mandatory but it does not mean you must add "bicycle=use_sidepath" every time you see a cycle track on the map.

Routers will understand it as bicycle=no for the main road and will remove it from the grid for all queries involving bicycles.  We can only do this once we are sure we will guarantee all possible moves will be possible with cycle tracks.

For instance, if I want to cycle from Sint-Martinusweg to Hoge Wei, it won’t let me do it because the only way to connect them is by using the main road.
If I start from Sint-Martinusweg and I want to turn left on Leuvensesteenweg it won’t let me do it because the road does not connect the eastbound cycle track there.

This changeset broke a lot of stuff here.
Der Bierpuncheur (2021-12-26 05:39:29+00:00): I understand the point of the router (GPS unit) avoiding this road, which would be a good thing, since the bicycle paths that do exist are in poor shape and incomplete. Furthermore, they don’t even connect completely Leuvensesteenweeg between Mechelsesteenweg and Sterebeekstraat…

But, that aside, how should it be annotated? Meaning, syntax or tag. With respect to “mechanical edit,” are you referring to tagging the permission set differently than the default for that road type?
czubi (2021-12-25 15:57:37+00:00): Hallo, was genau wolltest du hier darstellen? 
https://www.openstreetmap.org/way/1015245306
Sind die Geleise noch in Betrieb?
Aranc (2021-12-25 20:38:35+00:00): Welcome back:)
Marych_ (2022-08-09 04:28:39+00:00): Построили?
Может уже стоит контуры дома обозначить и адрес?
ZeLonewolf (2022-01-14 21:59:08+00:00): DWG revert requested; ticket #Ticket#2022011410000126 due to quality & conflation issues with undiscussed fire station import.
jcarlson (2021-12-25 15:40:57+00:00): What was the conflation process, exactly? Oswego, IL, for example, has 4 existing fire stations, all of them in OSM already, and none in the location imported by this changeset. Aurora, IL also had a duplicated station node, and that's just things within a few miles of me. I have to assume with a 2-changeset country-spanning import like this, there are going to be a lot of similar situations.
zluuzki (2021-12-25 17:33:36+00:00): It was the JOSM plugin. https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation 
I just noticed that the range in which was searched for already existing fire stations was set too low. (30 meters) I have now run the whole thing again with 300 meters, about 1000 already existing stations were found, and I removed these in https://www.openstreetmap.org/changeset/115360162 I have also manually checked numerous stations (at least more than 800) and found no more duplicates, so this should be fixed now.
zluuzki (2021-12-25 17:34:17+00:00): Wrong link, i meant https://www.openstreetmap.org/changeset/115366806
Zol87 (2022-01-04 06:59:20+00:00): The Chicago Fire Department ones you added are no longer stations They have moved to newer facilities.
zluuzki (2022-01-06 12:31:43+00:00): Then feel free to delete them.
G1asshouse (2022-01-14 13:42:44+00:00): Please, revert this import and follow the Import Guidelines.
https://wiki.openstreetmap.org/wiki/Import/Guidelines

There are two stations in my area that have moved less than a mile away. They are now double mapped. I picked a random firestation and Node: Somerset Volunteer Fire Department (9365469104) appears to be a sign and t-shirt shop. Obviously, these issues are on-top of the Oswego, Chicago, and Spokane issues.

Also, copying the name field of the USGS database directly into OSM may have been a bad choice. It appears that some of those names do not exactly adhere to OSM's naming conventions. Following the Import process would have given the community an opportunity to help you make a much more useful and less error prone import. As of this moment, the wider community now has work they didn't ask for in cleaning up your import that is spread all over the US.

Thank you and happy mapping.
zluuzki (2022-01-14 17:11:22+00:00): So then we have 2 options:

a) I revert it: We may no longer have 10, 30 or - let's be pessimistic - 100 wrong stations. But the price would be 30000 missing stations, which then must be added manually.

b) I leave it as it is: We may have 30 or 100 wrong stations, but we have mapped (almost) all stations in the US.
I am obviously in favor of b). NOTHING that has ever been imported here is error-free. Absolutely nothing. TIGER, NHD, land use in Atlanta, GNIS (from early 2000s) - everything has errors - tons of errors. The few outdated fire departments are nothing compared to the other nonsense that has been imported everywhere and still needs countless hours of cleanup.
Thats my opinion on that.
G1asshouse (2022-01-14 18:55:53+00:00): Just so that we are clear. You are comfortable with defending your estimated error of 100 bad poi based on nothing but wishful thinking. I’ll remind you that you have already received 8 confirmed bad pois, which is awfully close to your lowest estimate of 10.

You both find this data important enough to import and are comfortable with shouldering the OSM community with correcting your erroneous data. I assume are not planning on  informing the community that they now have 30,000 pois to check. You are not bothered by all by 30.000 pois that most likely have names that do not conform to OSM’s agreed upon naming scheme. Technically, that would bump up the number of erroneously imported pois to 100%.

You are begrudgingly willing to revert this valuable data but you refuse to revisit this import if it requires you to abide by the wishes of the greater OSM community and follow the import process.

You feel that because other OSM contributors imported erroneous data against the wishes of the OSM community that it makes further poor quality imports acceptable. You feel that because there have been times where the OSM community has willingly accepted a certen level of bad data from imports that this somehow means that you are grated the same green light for your import yet without needing an acknowledgment or agreement from the OSM community. You feel that repeating bad behavior and adding to poor quality data is preferable to presenting your import to the community.

I hope I captured what you are saying correctly.