User Dmytro Ovdiienko kasuje adresy z obrysów w Krakowie, przykład: http://osm.mapki.com/history/way.php?id=121085829
Po przyjrzeniu się bliżej okazuje się, iż dodaje on te obrysy do relacji associatedStreet. Nie mam nic przeciwko tej relacji (bo z założenia jest dobra), ale to nie jest powód, by kasować informację adresową z budynków! W tym momencie, żaden soft chyba nie obsługuje relacji tego typu, więc ogałacając taki adres z informacji o ulicy robimy z niego sierotę. Można przecież dodać taki adres/budynek do relacji i zostawić dane adresowe na budynku - w niczym to nie przeszkadza.
Hello Zbigniew, Sorry for English.
I remove addr::streetname and add house to relation because:
- Relation is more flexible. When government changes name of the street, you make change in one place (in the relation).
- Because when data is duplicated, you can do a typo by accident. In this way your house may not be found by search.
All software I know supports this kind of relation: OSM.org, MapFactor Navigator, Be-on-road, OSM-to-Navitel converter, OSM-to-7ways converter, JOSM. You can search “Józefa Łepkowskiego, 9, krakow” in the http://osm.org and you will find right house. You do not need to add addr:country=PL, because this tag is inherited by node. addr::postindex I do not touch.
I will create Feature request tomorrow to ask Developers of OSM.org to show address of house when you select “Map data” check box.
UPD: Ticket: https://trac.openstreetmap.org/ticket/5253#ticket
UPD2: OSM.org shows all relations assigned to building. In this way you can find to which street building is assigned.
@Dmytro:
Ok, jednak nie przekonuje mnie to co do tego, by kasować jakąkolwiek informację z adresów, które ktoś inny dodał. To można zawsze zrobić później, w sposób mniej lub bardziej zautomatyzowany.
Może się nie znam, niech się inni wypowiedzą, co o tym myślą?
Your arguments are valid, but:
- The name of a street doesn’t change often by any means (It’s always a lot of fuss considering re-issuance of ID cards, to begin with)
- In this particular case not (because of small edit volume), but otherwise - you’re simply inflating OSM history with useless data.
- We avoid any type of relations when it’s possible for a reason. Newbie users happen to break relations ever so often. Futhermore, a relation won’t automagically fix itself when someone deletes an object and adds it again.
- Later on, someone will add addresses using the relation-less schema anyway.
Twoje argumenty są poprawne, ale:
- Nazwa ulicy nie zmienia się wcale tak często (To zawsze dużo zamieszania, choćby mając na uwadze wydanie nowych dowodów osobistych)
- W tym konkretnym przypadku nie (ponieważ objętość edycji jest mała), ale w innym - po prostu zapychasz historię OSM niepotrzebnymi danymi.
- Jest powód dla którego unikamy jakiegokolwiek typu relacji kiedy to możliwe. Nowi użytkownicy psują relacje co jakiś czas. Dalej, relacja nie naprawi się automagicznie, kiedy ktoś usunie obiekt i doda go na nowo.
- Później ktoś i tak doda adresy używając schematu bez relacji.
To może wyciągnę ostatnio pojawiający się temat - adresowanie za pomocą relacji. Sprawy dotyczą dwóch tematów:
-
addr:city na węźle adresowym - w wielu miejscach można to wywnioskować z granicy miasta (i tak robi to Nominatim)
-
addr:street na węźle adresowym - można to wywnioskować relacji associatedStreet, o ile istnieje (i jak rozumiem Dimitrieja) - dużo aplikacji to rozumie
Wydaje mi się, że to by znacząco ułatwiło nam obsługę zmian danych adresowych, kosztem bardziej skomplikowanego przetwarzania danych przez tych, którzy korzystają z danych. Na wiki nigdzie nie znalazłem informacji, które by to porządkowały dla Polski, a pewnie jest to istotna informacja dla dalszego przetwarzania tych danych.
Zastanawia mnie też:
- dodanie do relatedStreet informacji o mieście gdzie się znajduje (by zrobić strukturę drzewiastą adresów, zamiast poszukiwania po granicy, jak również - by było oczywiste, że nie robimy jednej relacji dla wielu miast, mających tą samą nazwę ulicy)
- by od razu przy imporcie zakładać odpowiednie relacje
I jeszcze bym tylko dorzucił interesujące zagadnienie - “historyczne” adresy - tj. po zmianie adresacji, jest pewna bezwładność, i fajnie by było, gdybyśmy potrafili wyszukać po “nowej” nazwie, jak i po “starej”. Dla samych zmian nazw ulic, to wydaje się, że za pomocą relacji można by całkiem sprawnie obslużyć. Gorzej ze zmianą w numeracji.
Ja jestem zwolennikiem KISS - jeśli zaczniemy kombinować z relacjami to a) większość mapowiczów tego nie ogarnie, b) zrobi się bałagan wynikający z punktu a.
Co do starej i nowej numeracji - zawsze można wrzucić starą i nową numerację obok siebie - np. nową przypisać do budynków, a starą dodać/zostawić jako węzły.
Z tą relacją jest więcej problemów. Relacja powinna zawierać co najmniej jedną drogę ale widzę takie relacje bez drogi, co jest bezużyteczne i łatwo prowadzi do powieleń:
http://www.openstreetmap.org/relation/3610683
http://www.openstreetmap.org/relation/3610684
http://www.openstreetmap.org/relation/3610685
http://www.openstreetmap.org/relation/3610686
http://www.openstreetmap.org/relation/3610687
W starych miastach, często mamy do czynienia z kamienicą posiadającą kilka adresów, każda brama oddzielny adres (nawet inne nazwy ulic).
W takich przypadkach dając tylko adres dla obrysu budynku wprowadzamy w błąd szukającego.
Dlatego mamy adres wpisany do węzła/węzłów wewnątrz obrysu budynku.
IMHO. Wstawianie adresów do relacji jest trochę za wcześnie. Może w przyszłości, jak relacje staną się jasne i w powszechnym użyciu.
Najpierw dajmy adresy tak gdzie ich brakuje lub poprawmy istniejące błędy.
Dokładnie, a jak ktoś już chce dodawać relacje - niech pod żadnym pozorem nie usuwa danych które są w formacie który da się używać!
Czyli - tam gdzie nie ma addr:city, tam należy to dodać? Mamy tego ok. 280k do poprawy, jak pisałem tu:
http://forum.openstreetmap.org/viewtopic.php?pid=467363#p467363
Zmiany danych sa niesamowicie zadkie w porowaniu do innych use cases. Poza tym te modele sa w miare rownoznaczne, jedne moga byc latwiejsze do przetworzenia przez kilkulinijkowy skrypt a inne trudniejsze (madrzejszym skryptom to nie robi roznicy) ale nie nalezy modelu zimeniac “pod render”.
To jest ciekawa kwestia, i kiedys zaproponowalem rozwiazanie ktore wydaje mi sie, ze predzej czy pozniej i tak bedzie wszedzie stosowane – oprocz Nominatima, ktory jest narzedziem dla mapowiczow a nie uzytkownikow. Wyszukiwarki musza miec “cache” adresow z ktorego stare adresy sa usuwane dopiero po (na przyklad) kilku miesiacach. W przeciwnym wypadku to tylko kolejny pomysl na obciazenie edytowalnej bazy dla ulatwienia sprawy leniwym programistom 
Oryginalna kwestia byla taka, ze osoby korzystajace z danych adresowych chcialy dodawac do nich redundantne tagi na wypadek gdyby ktos popsul dane (konkretnie chodzi addr:city vs. granice), czyli w efekcie utrudnic zmiany (co, rzeczywiscie, utrudniloby ich psucie), czyli w efekcie po prostu spowolnic tempo edycji. Robiac to po stronie wyszukiwarki nie tylko nie przerzucia sie tego ciezaru na mapowiczow ale tez statystycznie wyszukiwanie jest minimalnie lepsze bo pozwala znalesc i nowa i stara wersje – z ktorych potencjalnie jedna jest juz nieaktualna lub bledna.
Nie tylko w starych miastach. Generalnie jesli adres jest przypisany do budynku to i tag/relacja dotyczy budynku, a jesli do bramy to dotyczy bramy. Tu chyba nie ma zadnych watpliwosci.
Na mój gust, to stary adres jest pewnie używany jeszcze 5 lat po zmianie. Niestety - jak ktoś by chciał zrobic taką bazę na bazie planet.osm, to niestety nie wie, który changeset dotyczył zmiany adresu ze względu na zmiane danych w rzeczywistości, a które są poprawkami błędnie umieszczonych danych.
I tak przy okazji - nie bardzo jestem w stanie wyłapać, jakie jest Twoje stanowisko - zostawić adresy bez addr:city?
Tak, ale pytanie czy to ma znaczenie. Od biedy mozna za bardziej wiarygodne uznawac edycje, ktore nie zostana poprawione przez np. 6 miesiecy.
Tam, gdzie nie potrzebne jest addr:city (jest granica) to oczywiscie nie dodawac.
Tez nie uwazam zeby nalezalo masowo usuwac nadmierne dane.
From the point of view of iD editor user (this is the editor most of casual/new users use):
- iD does not protect relations in any way
- if an object is part of relation you cannot check it in an easy way. To check relations you need to scroll down left menu - and most users, including more advanced ones like me, simply cannot do this without seriously slowing down the workflow. That means this is rarely, if ever, being done, and as a result relations are very easy to break (and we can see it - keeping marked trails relations intact is a sisyphean task).
- address is a very basic feature, just next to road. That means we will see a lot of addresses broken if we move them to relations
I think moving addresses to relations is premature - it cannot be effectively done without seriously redisigning editing tools.
Tylko jest jedno ‘ale’. Czasami jest tak, że dany adres leży w granicach miejscowości A, ale adres ma przydzielony z miejscowości B. Wtedy brak addr:city spowoduje błędne przypisanie adresu do miejscowości.
Czyli w nowych importach uwzględniać granice admin_level=8, i jeżeli addr:city zgadza się z name na granicy, to addr:city nie wrzucać do OSM?
Tam gdzie się nie będzie zgadzać, zostanie addr:city, jako obsługa “wyjątku”.
Przedłużenie ulicy należącej do relacji, podzielenie jej na pół i zmiana nazwy tej nowej połówce nie generuje żadnych ostrzeżeń nawet w JOSM. Jest to jednak najprostszy (a przez to zapewne najbardziej powszechny) sposób na dodanie nowej ulicy na końcu już istniejącej. Jak to się ma do relacji ulicy z adresami (associatedStreet) pozostawia się jako łatwe ćwiczenie dla uważnego czytelnika ;). Nadmiarowość danych (data redundancy) to jedno, ale ich wrażliwość (data vulnerability) to w przypadku OSM chyba nawet znacznie ważniejsza sprawa.
Adding new points to existing street, cutting it and changing name of new half make no warnings even in JOSM editor. It is indeed the simplest (and therefore probably most used) way to add new street at the end of existing one. How can it imply associatedStreet relations is left as an easy exercise for the reader ;). Data redundancy is one thing, but data vulnerability is also a really serious problem, especially in OSM.
Ja bardzo popieram adresy jako relację, ale w okresie przejściowym proponuję nie usuwać tagu addr:street. Myślę, że to nie powinno przeszkadzać, a możemy śledzić jakimś narzędziem czy aby wszystkie addr:street zostały zmienione poprawnie. Dodatkowo myślę, że z tym mógłby sobie nawet JOSM poradzić. Zmieniamy nazwę ulicy i sam zmienia addr:street w członkach relacji
Thank you guys for discussion. I’ve read all answers. Thank you for english translation. I really appreciate this. BTW, I’m learning Polish so I can read Polish as well… however I’m not good in writing 
On subject. In the ideal world both approaches (relation or explicit tagging) are equal. Relation just normalizes database (minimizes duplicates). If you can do something with relation, you can do the same with explicit tagging. Issue, when you have multiple addresses for same building, is not related to this question. You can solve this issue using both approaches.
In the real world we should take into account only one thing. Which tools do we use to create/view address? If tool tools allows to create new street implicitly, I’d prefer to use relations.
For example, in my country we use Cyrillic alphabet. Some letters in this alphabet are very similar to Latin alphabet and sometimes it can be a reason of issue. Accidentally you can write part of the word using Cyrillic letters and another part using Latin. As result you will get two different streets (e.g. “Krakow” and “Кrаkоw” from the computer’s point of view are two different strings). In Polish language this issue is not so actual but still exist. You have “o” and “ó”, “n” and “ń”, “s” and “ś”, “l” and “ł”, small “L” (l) and capital “i” (I).
When you use relations, before create new street you search for existent relation. Therefore you minimize chance of error.
When you use explicit tagging, you can copy/paste (which is the best). But you also can type street name by hands and it can cause an issue.
If tool, before create new street, forces you to find existent street, I do not care how street name is stored. Relation and explicit tagging are both ok.
I don’t think we should use both approaches at same time. For me if building both have addr::street and is part of relation, it is temporal state and should be fixed.
To make a summary, I can use any approach. Just let me know which one? I guess explicit tagging is your way. I will use it.