Nadmiar tagów - (do kasacji)

W miarę mapowania przybywa tagów na jednym obiekcie co spowalnia mapowanie, kontrolę oraz generuje pomyłki przy dodawaniu nowych tagów albowiem lista robi się coraz dłuższa, nie mieści się w bocznym okienku, można kliknąć do skasowania w nie tę linijkę itd.

Wiele tagów było importowanych czy dodawanych w trakcie importu bo to nie kosztowało czasu a miało nieść jakąś informację.
Nie przeszkadza, że jest dużo tagów na oddziale leśnym bo tam poza zmianą geometrii nikt nie będzie grzebał.

Jednak budynki mają tagi dotyczące samego budynku, funkcji jakie pełnia a często jeden kompleks budynków ma rozmaite funkcje przypisywane do name (nawet na obrysach) jak rozmaite biblioteki, świetlice , izby pamieć, POI jak nazwy knajp ,bankomatów.

Wiele z tych tagów powinno pozostać na nodzie od POI więc generalnie niepotrzebnie ludzie scalają POI z budynkami bo sam budynek ma wiele atrybutów .
Te atrybuty to podziały na części budynków aby właśnie wskazać gdzie są jakie funkcje albo do wykazania różnic wysokości do mapowania w 3D .
Można nawet przypisywać rożne kolory fasady która może mieć różny kolor z każdej strony.
Działanie takiego budynku na części wiąże się z przypisaniem pewnych tagów do głównego obrysu jak np name czy adres a do części wysokości,kątów spadków dachu czy adresów jeśli te są wyodrębnione.

Generalnie w miastach zaleca się zatem aby adresów nie łączyć z obrysami a stawiać je np. blisko wejścia. Błędem jest wg mnie łączenie adresów z wejściami, bo sobie z tym wtyczki nie radzą np. tracer kasuje wejścia.

Czyli należy starać się unikać oczopląsu i nie łączyć danych jeśli można je podzielić w sposób czytelny na różne obiekty/funkcje w ramach jednego obiektu

Widzę pewną tendencje jakby ludzie nie wiedzieli co mapować i do renderujących się czytelnie obiektów dodają tagi bliskoznaczne. Problem zaczyna się tam gdzie trzeba wykonać sporą pracę na gęsto usianych obiektach i strata czasu na przeszukiwanie wzrokiem się sumuje a zmęczenie prowadzi do błędów.

Można założyć ze dane będziemy “prostować” a także dodawać nowe dane w oparciu o importy a te z reguły niosą wiele tagów choćby opisujących źródło danych zaimportowanych. Szkoda że w OSM tagi opisowe jak daty źródeł czy zródla nie są grupowane poza tagami głównymi lub nie są wizualizowane w JOSM na końcu listy tagów a alfabetycznie.Wszak w tych danych nie grzebiemy.

Już dziś jest nadmiar tagów które kiedyś wydawały się ze będą nieść ważne informacje,bo w source podawano rodzaj podkładu czy to bing czy geoportal a dziś każdy to kasuje bo ta informacja nic nie niesie a często jest błędna bo maperzy poprawiali obiekty bez zmiany źródła. reszta dziś historia obiektu przechowuje numer changeseta a w nim jest zapisane źródło danych z jakiego zwykle korzystamy.

Pewnie jest już pora aby wyrzucać dane których sens jest dziś inny niż w momencie dodawania tzn informacja się zdewaluowała lub jest błędna i nie chodzi tu o porządki czy odchudzanie bazy a o zahamowanie procesu wydłużania listy tagów na jednym obiekcie bo to staje się uciążliwe.
Szczególnie rozumieją to ci co do jednego obiektu muszą dodać kilak tagów , często poprawiać swoje tagowanie przeliczając wysokości czy dopasowując je wizualnie z proporcji jakie oczyma odczytują z serwisów 3D.
Tam często trzeba klonować obrysy bywa ze jest kilka w odległości kilku cm (realnie) .Trzeba pilnować aby to się nie sklejało bo JOSM kompresuje pozycje GPS (traci kilka ([4] miejsc dokładności na geopozycji) . Trzeba dla podobnych obrysów dzielić te zbyt licznie pogrupowane tagi.

Wyraźnie wtedy widać ze przydałyby się tagi np aktualności danych a inne tagi kompletnie nic nie dają i to od samego początku ich zaimportowania.
Jeśli tagi dotyczą rozmaitych podkładów geodezyjnych a były potem zmieniane do orto to stanowią nawet dezinformację.Zapewne też maperzy boją się prostować czy aktualizować do rozbudowy bo nie wiedzą jak zapisać że dane nie są już zgodne ze źródłem. Zresztą właściciele danych tez często zmieniali sposób ich prezentacji więc podanie źródła jako wojewoda czy UM dziś już nic nie znaczy, bo trudno dopasować podkład gdy jest ich wiele z różnymi datami i rozsiane po rozmaitych serwerach.

Podam przykład najchudszego tagowania budynku z mojego miasta bez integracji z adresami i POI i bez mapowania w 3D za wyjątkiem zgrubnego.Zapewne znalazłyby się obrysy z prawie 20 tagami.

OBJECTID_height_lidar=134140
WroclawGIS:building:ID=157795
WroclawGIS:building:date=2011-02-25
WroclawGIS:building:layer=podklad_d/3
building:colour=#ffe0a0
building=yes
height=39.76
roof:colour=#787878
roof:shape=flat
source:building=WroclawGIS
source:height=lidar_ALS-2015_UM_W-w_height-max
source=WroclawGIS

Na pierwszy rzut oka rzuca się nic nie wnoszący WroclawGIS:building:layer=podklad_d/3
Następnie zdublowana informacja source:building=WroclawGIS oraz source=WroclawGIS
Nikt nigdy nie korzystał też z ID budynku.
Co oznacza i w czym pomaga WroclawGIS:building:date=2011-02-25, bo przecież nie datę budowy a dubluje to historię?

Zresztą połowa budynków zmieniła już geometrię, bo importy zawierały mikro-budynki typu dylatacje, balkony, gzymsy.W efekcie okrajania i łączenia też często zmieniło się id budynku

Może stwórzmy wątek gdzie będziemy pytać, które tagi czy obiekty są jeszcze potrzebne na OSM.Zatem pytam co mogę wyrzucać z wymienienionych bo mi one utrudniają pracę

Rozumiem, że POI nie powinny być połączone z budynkami (z wyjątkiem dużych budynków pełniących tylko jedną funkcję, np. kościoły, galerie handlowe (shop:mall)). Przypisywanie adresów do punktów usługowych także jest zbędne - adresy te występują już jako osobne POI lub są przypisane do budynków; co jeżeli znam numer lokalu punktu usługowego? Dodawać pełny adres, pominąć tę mało istotną informację, czy może dodać tylko ‘addr:door’? Znaczniki ‘source’ rzeczywiście można usunąć - źródło danych podajemy w komentarzu edycji.

Ja nie widzę potrzeby dublowania adresu na POI skoro można w wyszukiwarce odnaleźć budynek z adresem.
Coraz częściej powtarzają się sytuacje że importując od operatorów obiekty są importowane z adresami np. bankomaty, jakieś automaty do sprzedaży.
Powodowało to że podczas integracji adresów z obrysami budynków bankomaty wchłaniane były przez obrysy wielkich sklepów jak supermarkety a przez to ich lokalizacja się gubiła. Mogło się zdarzyć że duży sklep przyjmował wtedy name od operatora bankomatu, bo render preferował operatora nad name co ma miejsce zdaje się na mapie podstawowej.

Natomiast adres przy automatach sprzedających był czymś w rodzaju ref w bazie operatora.
Operator chciał w ten sposób odróżnić maszyny które nie miały numerów czy refów.
Nie przejmowała się gdy maszyna została przesunięta choć adres nadał z pierwotnej lokalizacji gdy automat stał najpierw bliżej innej bramy.I jeśli taki automat trafił po dach to miał adres sąsiedniego budynku choć zawierał się w budynku z innym adresem .A ze mapa podstawowa preferowała name przed adresem tzn ukrywała adres na dużych budynkach jak hipermarkety czy DH to ktoś mógł przenosić adres z POI na budynek. Na szczęście mapa podstawowa nie renderuje adresów z POI i przez to nie prowokuje do takich mylnych sprostowań ale co będzie gdy się rendery nauczą renderować adres łącznie z name/brand itd?

Inny problem to adresy rożnych punktów usługowych np. nr 44f szczególnie ulokowanych na piętrach jak dentyści są wymyślane przez najemców aby odróżnić skrzynkę na listy lub przycisk na domofonie.mA to sens przy numerowaniu np pawilonów handlowych gdzie obrys stanowi jeden sklepik.
Na budynkach może się przydać tylko wtedy gdzie jest to jakiś długi budynek z całym parterem oddanym pod wiele punktów albowiem wtedy firmy się zmieniają i name na OSM może być nieaktualne a klient wie z mapy po adresie pod który koniec czy stronę budynku podjechać (warunek adres nie jest połączony z POI). Ale takie obiekty zwykle maja adresy nadane przez zarządcę i są one w bazie urzędowej miasta.Trudno mi się wypowiadać na ile dublowanie adresów na budynku i POI może zaburzać wyszukiwanie czy funkcje jeszcze niezaimplementowane .
Życie uczy że każda komplikacja z czasem przechodzi kolejne mutacje i wkrada się chaos stad róbmy jak najprościej.

Jeśli POI mieści się w obrysie z adresem to i naocznie jak i automat wyszukujący da sobie radę.
Są sytuacje, że najpierw jest jedno POI a z czasem dochodzą kolejne.Przy jednym kogoś może zachęcić do integracji POI z obrysem a potem problem z dodaniem kolejnych oraz render nie wie gdzie umieścić adres a gdzie ikonę.

Czyli generalnie im częściej rozdzielamy adres,obrys, POI, tym łatwiej sterować ręcznie gdzie co ma się wyświetlić, a name czy ikony wycinające adres to poważny problem.
Zatem jeśli adres dodatkowy jak 44f nie był zaimportowany ja bym go dodał blisko wejścia ale oddzielił od POI to renderowi będzie łatwiej rozsunąć czy wyświetlać naprzemiennie (wraz ze zmianą zooma) a często jedno wejście jest i do POI jak i na klatkę mieszkalną.

Ponieważ wtyczki są ułomne i kasują wejścia na obrysach ja adresów nie dodaje do wejść.
Integracja adresu z POI może spowodować, że gdy POI się zmieni na inną firmę to ktoś może taki sklep wywalić do kosza wraz z adresem.
Znam też wiele przypadków gdzie POI zmienia lokal w ramach tego samego budynku na większy lub lepiej usytuowany wtedy można przeciągnąć adres w niewłaściwe miejsce.

Inne problemy, które są w gestii renderu to wyświetlanie adresów osadzonych na częściach budynku jak building:part lub wg szablonów związanych z Indoor.

Czyli rowers2 jak tak pobieżnie zrozumiałem:

• powinniśmy tagować budynki jako budynek, nie dodajemy do niego żadnych tagów w stylu szkoła bo leży on na terenie szkoły który ma już tag odpowiedni tag - jeśli nie ma go to dodajemy ten tag do terenu szkoły nie do budynku. Tak tez postępujemy z budynkami na terenie szpitala który ma kilka budynków - leżą one na terenie należącym do szpitala jeśli teren nie jest opisany - opisujemy go.

Obecnie większość nowych budynków posiada rozbudowane podziemne części na potrzeby garaży wykraczające poza obrys budynku potrzebujemy tu używać odpowiedniego tagu; w części nadziemnej mamy budynek a często przed nim zabudowane przedsionki wejścia do tegoż budynku wysokości 1 piętra o określonej wysokości ten “obiekt” też rysujemy oddzielnie - przyklejając go do budynku?

Do tagów budynku dodajemy tylko opcjonalnie name o ile budynek takową posiada i dane adresowe.

Punkty POI dodajemy jako węzły w obrysie budynku bez danych adresowych - te oprogramowania powinny same wyciągnąć z bazy danych osm. Tu podpisze się pod pytaniem Malvolapukulo o sytuację kiedy mamy faktycznie cały parter (+ I piętro) przeznaczone w budynku XI piętrowym na działalność usługowo handlową - jak to sensownie dobrze dodawać. Jest też opcja że lokale handlowo usługowe prócz parteru budynku wysuwane są z budynku poza jego obrys - https://www.openstreetmap.org/#map=19/53.43271/14.51619&layers=N - Szczecin ul. Witkiewicza 60 - 68 https://goo.gl/maps/jdrbLBpgBaK2

Przydałby się taki mały dobry prosty rysunek instruktażowy jak otagować dobrze taki budynek z garażami podziemnymi, lokalami usługowymi na parterze (czasami taki parter budynku obrysem jest mniejszy niż obrys części powyżej parteru. W takim budynku istnieje przejście w parterze budynku i w nim chodnik/przejście lub podjazd na podwórko. Jak poprawnie wyrysować taki budynek jak w tym miejscu: https://www.openstreetmap.org/#map=19/53.42493/14.48771&layers=N - Szczecin ul. Kazimierska 4 (tu jako jeden budynek) i ul. Kazimierska 2 - oba wyglądają tak samo zewnętrznie; jak “zrobić poprawnie” taki budynek: https://www.openstreetmap.org/node/3905175646#map=19/53.43205/14.51553&layers=N - Szczecin ul. Witkiewicza 49 - 59 https://goo.gl/maps/VQxh8FMSWeB2 .

building=school czy building=hospital można dodać.

Takich garaży raczej się nie mapuje. Tylko część nadziemną.

Wiele z takich wejść to są pełnoprawne budynki. Z kolei schody przed budynkiem nie powinny być rysowane jako budynek.

Jeśli adres jest na obrysie to może nie być w POI. Ale dodanie to nie błąd, a wielu mapperów dodaje zawsze adres, bo zachęcają ich do tego edytory (iD, maps.me).

A gdzie tu jest problem? Do POI możesz dodać level= dla wskazania piętra. Jeśli parter jest większy i chcesz przekazać tę informację, zrób budynek z użyciem building:part.

Kurcze własnie że są mapowane w wielu miejscach :(. Budynki sa rysowane po fundamentach które wychodza daleko poza obrys właściwego budynku - jego części nadziemnej.

IMHO garaż podziemny jest to część budynku i nie widzę powodu dla którego miała by nie zostać wyrysowana zwłaszcza jeśli znane są dokładne dane co do jego kształtu. Co najwyżej należało by dany fragment budowli oznaczyć layer=-1

Możesz rysować jako budynki wewnętrzne i podawać undeground lub layer=-1 a na tym rysować trawniki czy drzewka to przecież nikt nie będzie miał wątpliwości. Może kiedyś render podziemnych budynków się poprawi to nie trzeba będzie przerabiać.

Bardzo często te parkingi nie są podziemne a tylko przysypane ziemią i wyniesione podwórko jest kilka metrów w górę .Na obecnym etapie każde rozwiązanie jest dobre a przy 3D się doprecyzuje wysokość.

Dla mnie ważniejsze jest jak renderować takie bryły tzn jak obkładać z boku nasypami ziemnymi aby te ukosy ładnie wyszły w 3D. Nie ma sposobu, bo serwisy 3D renderują tylko bryły z kluczem building.

Znalazłem jeden sposób ukrycia “budowli”, które nie są budynkami i nie powinny być widoczne w 2D ale zaraz ktoś by się czepiał, że to mapowanie pod render.

Bardzo na tym cierpi mapowanie 3D w tych częściach miast gdzie są różne poziomy ziemi np. wzdłuż nabrzeży rzek, estakady i dworce kolejowe.Mosty i wiadukty,nasypy obwodnic drogowych.
Mapa gdzie nie można uwzględnić poziomu gruntu a rysuje się wysokościowo?

1. nie widać na orto, poza szczęśliwymi przypadkami, gdy zdjęcie uchwyciło moment budowy
2. nie ma dostępnych obrysów podziemnych części możliwych do użycia (licencja) w OSM
3. https://wiki.openstreetmap.org/wiki/Pl:Budynki wspomina o rysowaniu obrysu na poziomie ziemi

Są to bardzo dobre powody, by ich nie rysować. I tak właśnie jest- rysowane są sporadycznie.

location=underground obowiązkowo

no i co? Wiesz można mapować nie tylko siedząc na krześle

Prywatne garaże podziemne są prawie zawsze dostępne tylko dla właścicieli. Trudno, by mnie tam wpuścili. Natomiast próba dostania się za wjeżdzającym pojazdem może być potraktowana jako wtargnięcie na ogrodzony teren (art.193 kk)

Ale mamy masę budynków typu Office Center gdzie poniżej poziomu gruntu mamy jeden i więcej pięter podziemnych parkingów dostępnych w mniejszym lub większym stopniu dla klientów.

Mamy taki budynek Piastów Office Center http://www.litwiniuk-property.com/piastow-office-center-i13 gdzie budynek od strony południowo-wschodniej ma kondygnacji 6 + 2 pietra na minusie parkingu, po stronie północno-zachodniej tylko 5 pięter nadziemnych. Na OSM jest wyrysowany jako jedna bryła ale nad poziomem 0 - (choć nie wiem czy to nie jest poziom -1) z 5 piętrami,a w sumie stoją tam 3 “oddzielne” budynki. Dorysowałem te 3 budynki ale prosiłbym aby to ktoś zweryfikował (moje błędy jeśli jakieś popełniłem).

https://www.openstreetmap.org/changeset/47739091#map=19/53.41803/14.53174&layers=N

W prawym panelu mam otwartych kilka okienek.Niektóre można zmniejszać zmniejszając czcionkę jak we wtyczce Measurement, ale JOSM po zamknięciu nie pamięta rozmiaru okien i trwa walka aby parę mm uzyskać aby okno z tagami pokazało więcej niż 7-10 tagów.
Operacja na tagach obiektu nie powinna zajmować więcej niż 1-3 s aby szybko sprawdzić poprawność tagów lub czy dodał się nowo dodany tag np. ze schowka.
Jak znaleźć ten tag jeśli lista zawierać będzie 20-30 tagów ?
To jest bardzo męczące i prowadzi do pomyłek.

Trzeba przewijać listę i notorycznie wyszukiwać mozolnie wzrokiem.
Załóżmy że będzie ok. 20 tagów.
Przy modelowaniu 3D nie odgraniczamy się do jednego obrysu budynku czyli nie lustrujemy tagów na jednym obiekcie.
Musimy stworzyć minimum 3 obiekty tzn poszerzyć fundament aby objął wszystkie części budynku w tym wystający dach.Musimy stworzyć obrys dachu jeśli jak to zwykle bywa jest on szerszy niż obrys ścian. Josm pozwala nam szybko takie obrysy stworzyć przez klonowanie.Cały zysk z automatyzacji JOSMEM pryska jeśli z tych 20 tagów z obrysu ścian budynku musimy dokonać selekcji i część tagów np. adres czy name przenieść na największy obrys fundamentu. Koszmar jeśli budynek jest w relacji bo w JSOM-ie nie da się skopiować tagów ani grupowo ani nawet pojedynczo. Funkcje, jeśli budynek pełni ich kilka np POI czy przez name trzeba porozdzielać na rozmaitych partiach budynku co powiększa ilość obrysów z 3 do więcej.
Z obrysu stanowiącego wystający dach trzeba pousuwać wszystkie tagi które mogłyby się dublować na obrysie fasady, częściach budynku czy “fundamencie”. Pewne tagi musza się powtarzać jak np. maksymalna wysokość fasady budynku i minimalna wysokość dachu.

Zatem trzeba mozolnie wyłuskać, które z tych 20- tagów mają trafić na który obrys, przy czym część może a nawet powinna się dublować.
A najmniejszy błąd rozwala cały model zaś nie da się tego wyłapać i poprawić od ręki , bo na render trzeba czekać dobę.

Przykładowo ID budynku jeśli trzeba go podzielić na dwie części lub połączyć dwie części zaimportowane które stanowią jednak jeden funkcjonalny budynek, raz trzeba zdublować a kiedy indziej połączyć do jednego value używając średnika aby ID części składowych nie utracić.
Takich podziałów lub łączeń dokonuje się na “ścianach” ale jeszcze częściej łączy się lub dzieli obrys związany z dachem bo np zdefiniowany spadzisty kształt dachu ma przykryć kilka klatek schodowych z których każda ma swoje POI często na obrysie, oraz adresy (często na obrysie).

Skomplikowane budynki typu kościoły robi się w 3D tak długo, że te kilka minut straty na porozdzielanie tagów na właściwe części budynku to nie problem. Ale gdy się mapuje proste kamienice stojące koło siebie co 10-15 m to trafia szlag gdy trzeba wytężać wzrok podczas przewijania listy czy aby się dobrze porozdzielało i czy jakiegoś tagu nie brakuje.

Najlepiej jeśli zanim się zacznie robić w 3D wywali się niepotrzebne tagi to potem jest mniej roboty aby nadmiarowe tagi usuwać lub przenosić z klonów.

Zatem prośba aby przy importach nie mnożyć tagów bo trudno przewiedzieć jakie grupy tagów będą w przyszłości łączone na obrysie ale już 10-15-20 zniechęca nowych do poprawiania osm.

Tagów 3D jest bardzo dużo, bo opisują rozmaite kształty, opisują wysokosci wielu płaszczyzn tych górnych i dolnych oraz skośnych gdzie nie wystarczy podać wysokosci jednej krawędzi płaszczyzny
Także prześwitów czyli np bram przejazdowych.Wysokości rozmaitych części jak wieżyczek, maszynowni, kominów, świetlików,lukarn. Do typowych kształtów dachów dochodzą wysokości, kąty pochylenia, kierunki skierowania, kolorystyka, rodzaj materiału budowlanego. Potem można kolorować fasady, dorysować drobne elementy architektoniczne które na szczęście zwykle nie są przyklejone do fasad czy innych części mających wiele tagów. To jeszcze czasem trzeba zwielokrotnić gdy się rysuje każde piętro oddzielnie a potem skleja identyczne obrysy.

Zatem do wspomnianych danych dotyczących obrysu, które często są z importu, druga grupa tagów to adresowe, trzecia 3D, czwarta funkcjonalności, name i POI itd.

Wiadomo, że adres nie może być tylko numerem policyjnym choć to z winy OSM musi zawierać dodatkowe tagi, ale u mnie pierwszy lepszy budynek ma taki adres:

WroclawGIS:addr:date=2011-03-13
WroclawGIS:addr:id=41822
WroclawGIS:addr:layer=search/0
WroclawGIS:addr:postcode:id=43257
WroclawGIS:addr:postcode:layer=odniesienie_k_lite/1
addr:city=Wrocław
addr:country=PL
addr:housenumber=3
addr:postcode=50-456
addr:street:sym_ul=04434
addr:street=Dworcowa
source:addr=WroclawGIS

Dwanaście tagów dodanych do innych 10-15-20 to jakiś obłęd.
Ile z nich mogę wywalić, bo znacznie spowalniają mapowanie na dużej ilości obiektów?

Na wsi wystarczają 3 tagi więc w mieście pewnie wystarczyłyby 4.
addr:housenumber=3
addr:street=Dworcowa
addr:postcode=50-456
addr:city=Wrocław
addr:country=PL

Na wioskach bez ulic był problem z wyszukiwaniem więc dodano addr:place.
Nie mam pojęcia czemu służą addr:city i country ale pewnie są potrzebne.
Dziwne, że jeśli te tagi są konieczne to nie są one dodane jako sufiks do tagu addr:housenumber czyli po dwukropku.
Wydaje mi się, że źródła pozyskania wartości jakiegoś tagu też mogłyby być dodawane na końcu tego value, a jeśli nie to po jaką cholerę JOSM wyświetla je łącznie tagami fizycznymi? Nawet mogłyby być ukrywane jak autor czy historia.Powinien być jakiś filtr do ukrywania nadmiarowych tagów a nie tylko obiektów.

Gdyby udało mi się usunąć z tych 12 tagów adresowych np. 7 plus kilka z importów budynków (o czym pisałem kila dni wcześniej) to na każdym obiekcie miałbym kilkanaście zbędnych tagów mniej. Jeśli to pomnożę przez 150.000 budynków które chciałbym zrobić w 3D i wiele z nich miałoby podzielone czy skopiowane obrysy to ubyłoby mi do przeglądania czy przenoszenia milion tagów, bo naprawdę bolą mnie od tego oczy gdyż łatwo o literówki przy pośpiechu i zmęczeniu, przy tagach wieloczłonowych, a takich w 3D jest sporo.
Chyba przeniosę okienko z tagami na lewą stronę ekranu, bo chyba stracę cierpliwość z tym ciągłym przewijaniem listy tagów po każdym kliknięciu w inny obiekt. Nawet mapując jeden budynek w 3D złożony z kilku do kilkudziesięcioleci brył ciągle trzeba czytać te tagi, bo np. fundamenty sąsiednich budynków muszą na siebie nachodzić i to samo dotyczy dachów.Zatem wykonując setki operacji często na ten sam obrys wchodzimy po wiele razy aby sprawdzić co to jest, tak że trudno ocenić stratę czasu na czytanie tysiąca razy jakiś tagów które niczemu i nikomu się nigdy nie przydadzą.
Jakieś numery podkładów, jakieś daty stworzenia tych podkładów czy importów, jakieś id w bazach gdy my nie utrzymujemy spójności z tymi bazami czyli łączymy i dzielimy obiekty olewając ID źródłowe.

Ludzie marnują czas odpalając MapRoulette pod pozorem ujęcie ułamka promila danych w bazie, a tu człowieka po godzinie mapowania boli głowa i daje sobie spokój. Straszne marnotrawstwo czasu i energii, a dla nowych oglądających taką długa listę w Potlachu zapewne zapala się lampka aby w tak trudną zabawę nie zaczynać się bawić.

Prosiłbym o wypowiedź szczególnie importerów aby nie było, że zaczynam sam wyrzucać.

Temat jest dużo szerszy, bo przy importach były wymyślane tagi. Potem ktoś je modyfikował starając się przez zmianę zapisu jakoś je pogrupować. Część starych tagów jest już po konwersji a cześć nie.
Na szczęście ta mnogość rodzai zapisu tego samego atrybutu nie zwiększa ilości tagów na jednym obiekcie.