OpenStreetMap logo OpenStreetMap

Changeset எப்பொழுது கருத்துரை
141439054 over 1 year ago

> Ja jedynie co to staram się unikać kapitalików przy nazwach tablic

Jak myślisz dlaczego tego nie robię i nie powinno się tego robić? Zbieramy dane faktyczne, a nie to co myślimy lub uważamy jak powinno być.

141439054 over 1 year ago

No, dzięki. To jest efekt zbierania danych i umieszczania ich w bazie danych, zamiast „malowania” mapy z krzesełka. Mimo tego, Cypel jest jeszcze nie dokończony, ponieważ brakuje wielu tablic. W ogóle, ta okolica wymaga jeszcze dużo pracy. Jeśli czas i możliwości pozwolą, to może się tego dorobię.

Dla porównania możesz popatrzeć na [Polanę Rekreacyjną „Świętobór”](osm.org/way/1120875360)

141612459 almost 2 years ago

Na czym polega „poprawa” zmiany drogi dojazdowej/ratunkowej Ignacego Daszyńskiego na ścieżkę (`highway=path`)? Zauważ, że nie znacznikujemy drogi według do czego chcielibyśmy ją używać, lecz czym ona jest i jak jest oznakowana w terenie na miejscu. To, że skupiasz się na kartografowaniu infrastruktury rowerowej i że w jakimś miejscu można fizycznie przejechać rowerem, nie jest powodem aby zmieniać typy dróg. Twoja zmiana doprowadziła do tego, że dla służb ratowniczych lub dostawców docierających pojazdami trasa nie będzie prawidłowo wytyczona. Proszę zachowuj szczególną ostrożność przy zmianie typu drogi. Sprawdź typ drogi na miejscu i w najlepszym przypadku udowodnij powód do zmiany. Jeśli droga jest oznaczona znakiem drogowym `PL:B-1`, nie czyni to ją automatycznie `highway=path`. Znak `PL:B-1` wyklucza ruch rowerowy, bez względu na to czy nam się to podoba czy nie, czy można fizycznie przejechać rowerem czy nie. Jeśli chcesz w takich miejscach umożliwić wytyczanie trasy rowerem to używaj `bicycle=dismount` zamiast zmieniać typ drogi.

138137309 almost 2 years ago

Pierwszy i główny problem był, że @B_KSL po prostu usuną relację lecąc „po łebkach” przyjmując, że z zasady wszystkie jednoelementowe relacje są zbędne, a zatem usuną istotne dane, nie sprawdzając ani stanu rzeczywistego ani swojej pracy. Nie zastanowił się, dlaczego jest tak a nie inaczej w tym przypadku, i czy w ogóle może to być uzasadnione. Gdyby przeniósł dane na linię zamkniętą budynku, wynikiem tego była by najwyżej utrata relacji. To da się przeboleć, ale nie utrata wartościowych danych z bazy danych z powodu masowego stosowania błędnych założeń.

> Dlaczego w tym przypadku wszystkie znaczniki nie powinny być na budynku?

1. Ponieważ przyjętym lub potocznym stylem kartografowania — innymi słowy, wybór struktur danych do opisywania zależności między zebranymi współrzędnymi geograficznymi — w tym rejonie polega na znacznikowaniu terenów (działek) szkół odrębnie od budynków. Nota bene, jest to dobry styl (z wielu powodów), właściwie stosowany w większości krajów. W tym przypadku, ponieważ teren jest całkowicie pokryty budynkiem, nic nie stoi na przeszkodzie aby dalej stosować przyjęty styl. Można by w tym celu też użyć dwóch nakładających się linii zamkniętych, budynku i szkoły. Lecz, jest to mniej efektywne niż wykorzystanie już istniejącej linii zamkniętej budynku w relacji, która pod każdym względem jest tańsza niż dodatkowa linia. Po za tym, nałożone linie często prowadzą do błędów logicznych lub zręcznościowych w edytowaniu u nie doświadczonych przyczyniających się w zbieraniu danych.

2. Już wspomniana reguła „jednej struktury danych na jeden obiekt fizyczny” generalnie nadal obowiązuje, z której między innymi wynika powyższy styl kartografowania.

> Dlaczego musi to być multipolygon a nie zwykły landuse?

Nie chodzi tu o typ relacji. Tu chodzi o typ struktury danych. Relacja, obok linii i punktów, jest jednym z typów struktur danych dostępnych lub obsługiwanych w bazie danych OSM. `multipoligon` jest typem relacji. Znacznik `landuse` powinien być stosowany zarówno na relacjach typu `multipoligon` lub liniach zamkniętych, lecz nie np. na liniach otwartych lub punktach, ponieważ zamysłem `landuse` jest opisanie obszaru z określoną granicą.

> W zasadzie jedynym argumentem było, że instytucja to nie budynek - ale przy
> takim podejściu trzeba by wszelkie sklepy, firmy, instytucje dzielić na osobne
> obiekty od budynków - co tylko skomplikowałoby aktualizacje, bo korzyści nie widzę.

I można, a może nawet powinno, by tak robić i nie byłoby w tym nic złego. Korzyść w danym przypadku będą mieli np. ci, którzy będą odczytywać bazę danych OSM maszynowo, algorytmicznie w automatyzowany sposób. Tu nie ma bezpośredniej korzyści, ani dobrego lub złego kartografowania (poza usuwaniem wartościowych danych o istniejących obiektach). Generalnie, zarówno w OSM jak i ogólnie w życiu, nie powinno się wybierać lub wyodrębniać sobie jedną upatrzoną kwestię lub regułę i stosować ją jak z automatu, lecz zawsze rozpatrywać sprawę całościowo. Po to człowiek ma rozum, i dlatego odróżnia się od każdego żywego i martwego stworzenia na ziemi.

119614691 about 2 years ago

Das Problem ist, dass die Zweifel berechtigt sind. Deine Änderungen lassen darauf schließen, dass du entweder nicht vor Ort warst oder einfach mal geraten hast. Ich gehe an den besagten Stellen mehrfach im Monat vorbei und ein Namensschild habe ich dort nie gesehen.

> Im Übrigen guggsdu einfach mal z.B. auf das Geoportal NRW.

So funktioniert OSM nicht. Das ist kopieren von anderen Karten. OSM sammelt den Istzustand.

> Die falsche Schreibweise darfst du gerne ändern. Macht weniger Arbeit als Rumzupöbeln.

Was Mehrarbeit verursacht sind Leute die herumraten und Daten aus anderen Datenquellen sinnfrei kopieren ohne den tatsächlichen Zustand zu kennen.

118664552 about 2 years ago

Woher bist du sicher, dass z.B. der Knoten 9589893069 eine Doline und kein Bombentrichter ist? Warst du vor Ort? Da der Boden dort fast vollständig aus Schiefergestein besteht ist eine Doline sehr unwahrscheinlich. Wenn man sich die Luftaufklärungsaufnahmen der Alliierten nach Bombenangriffen von dieser Fläche anschaut, so ist es deutlich wahrscheinlicher, dass die von dir hinzugefügten Dolinen eher Bombentrichter, und damit nicht natürlichen Ursprungs sind.

Du gibst unter Anderem „North Rhine-Westphalia ALKIS“ als Quelle an. „North Rhine-Westphalia ALKIS“ ist als eine andere Karte einzustufen. Bitte nicht von anderen Karten kopieren.

119614691 about 2 years ago

Woher weißt du, dass die Linie 28142772 den Namen „An den drei Pfosten“ trägt. Hast du ein Namensschild gesehen? Warst du vor Ort? Wenn kein Nachweis vorhanden ist, bitte nicht nach gut dünken herumraten. Auch wenn es so wäre, so hast du den Namen falsch geschrieben. Bitte mehr Sorgfalt walten lassen. OpenStreetMap ist keine Ratespiel gegen Langeweile.

136767854 about 2 years ago

Woher soll der Name „Andachtsplatz“ kommen? Warst du vor Ort? Wo hast du ein Schild oder eine Beschriftung gesehen?

Des weiteren, es ist nicht notwendig einen weiteren Knoten hinzu zu fügen, wenn am selben Ort ein anderer mit bereits anderen Merkmalen vorhanden ist. Man ergänzt den bestehenden Knoten. Bitte die Datenbank nicht zu müllen.

138137309 about 2 years ago

Dobra, widzę że przynajmniej prawidłowo potrafisz przywracać dane razem z historią. 👍
A zatem istnieje jeszcze nadzieja wobec Ciebie.

137685522 about 2 years ago

Mistrzem, Ty się sam nazwałeś, ponieważ to Ty zacząłeś „poprawiać” innych, bez zastanowienia się i bez sprawdzenia stanu rzeczywistego.

Widać też, że na twojej „logice” za daleko nie zajechałeś, ponieważ nie wiesz lub zapomniałeś, że podstawową koncepcją OSM jest [„Jeden obiekt, jeden element OSM”](osm.wiki/Pl:Jeden_obiekt,_jeden_element_OSM). Innymi słowy, unikamy *mieszania* różnych funkcji opisywanego obiektu. Złożoność może być wielowymiarowa. A zatem nie tyczy się ona wyłącznie liczby elementów w jednej relacji ale też rożnych funkcji, zastosowań lub użyteczności obiektu, a to można określić np. stosując relacje opisujące każdą funkcję obiektu. Czasami można lub odpowiedniej jest stosować punkty w zamkniętej linii, które opisują rożne funkcje obiektu.

> Co Ty tu złożonego widzisz? Da się namalować prostym wielokątem to maluj! Nie cuduj. BUZI!

Poza tym, twoje słowa demaskują twoje chłopskie myślenie: Baza danych OSM nie służy do „malowania”. My nie „malujemy” mapy. My zbieramy dane geograficzne i opisujemy je za pomocą wyznaczonych struktur danych. A gdybyś na prawdę czynił pożyteczną robotę zbierając dane i sprawdzając stan rzeczywisty, zamiast bawić się w samozwańczego mistrza poprawiaczy z za biurka, to byś zrozumiał co autor miał na myśli i dlaczego opisał obiekty w taki a nie inny sposób. I, nie rzucaj hasłami jak KISS lub BUZI gdy nie masz o nich pojęcia. Jeśli nie masz nic wartościowego do dodania do OSM, to nie edytuj, nie psuj i nie wymądrzaj się.

137685522 about 2 years ago

Chłopie, przestań się bawić w poprawiacza z za biurka. Takich ludzi jak ty nikt nie potrzebuje. Jeśli nie potrafisz sprawdzić stanu rzeczywistego i nie wnosisz nowych danych, to nie edytuj. Jeszce raz: Nie ma w tym nic dziwnego ani niezwyczajnego gdy relacje posiadają wyłącznie jeden element. Ewidentnie nie rozumiesz co czynisz ani nie sprawdzasz stanu rzeczywistego. Jeśli będziesz postępował tak dalej, będę musiał Cię zgłosić administratorom.

138137309 about 2 years ago

Ta „jednoelementowa relacja” w cale nie jest zbędna, bo szkoła muzyczna istnieje. Instytucja szkoły jest odrębnym obiektem od budynku szkoły. W danym przypadku, teren szkoły jest pokryty całkowicie budynkiem szkoły. Po za tym, nie ma w tym nic niezwykłego gdy relacja posiada jeden element. Trzeba wiedzieć co się czyni zanim zacznie się usuwać rzeczy o których się nie ma pojęcia. OpenStreetMap nie potrzebuje „poprawników”. Proszę przywróć tą relacje.

36732227 over 2 years ago

Right, this should have been `natural=grass`.

67006207 over 2 years ago

“Hawkins Road East” does not seem to have physical divider or barrier. Why did you split it in a dual carriageway?

116518512 over 2 years ago

It is not an attack but a mere observation and statement of fact, followed by a suggestion how you can stop bloating the database and harming others by breaking routing.

For example, you have added multiple, effectively identical and useless, turn restriction relations to many `NY 27` segments with just two members. Turn restriction relations require at least three members in the `from`, `via`, and `to` roles. A `via` member should be a (one) node but can also be mapped with multiple `via` member ways. `from` and `to` members must start or end at the `via` node. In other words, all members have to be connected. Additionally, you do not need to add `oneway=yes` ways to turn restrictions in the `to` role if traffic would flow in the `backward` direction of the way. Furthermore, do not add `restriction=only_*` restrictions unless absolutely necessary. Try to map with `restriction=no_*` restrictions first. And finally, even after you have managed to add three members to turn restriction relations you have fallen into the novice mapper pitfall: You created too many `restriction=no_u_turn` restrictions with identical ways in the `from` and `to` roles. These specific turn restriction relations do not add any value to the map nor to routing, nor do they represent in the OSM database what mappers think they are mapping. Most novice mappers start adding these when they feel or have the impression that their navigation app suggests a u-turn at the strangest places. Then they usually naively assume that there must be something wrong with the map, which in most cases is not. In these cases, usually the routing algorithm is broken. In short; routing algorithms should always calculate loops (or navigate to a `highway=turning_circle` or `highway=turning_loop`) instead of suggesting a u-turn whenever they *think* is necessary.

Long story short; please read about the basic concepts of relations first and then about more complex relation concepts, like turn restrictions on the OpenStreetMap Wiki before adding any new or modifying any existing turn restriction relations.

116518512 over 2 years ago

Please stop adding turn restrictions because apparently you do not understand how they work. You are adding garbage and thus burdening the OSM database and navigation apps unnecessarily.

132187180 over 2 years ago

It’s sad that you lack the resolve to sand up to your mistakes and apparently have no appreciation for other people’s work. If only you would put in the same amount of energy and effort to fix your mistakes that you have invested in obliviously damaging good work that has served many people well, the world would be a better place. From what I can see, your fixing efforts are rather halfhearted at best and you are breaking even more. Apparently, you do not fully understand how `destination:*` tags are supposed to be mapped. Let this be a life lesson to you: Just because you *can* do something it does not mean you *should*, especially when you are unaware of what you are doing. The next life lesson is: Stand up to your mistakes and try to fix them completely not just superficially. So, I would suggest that you better stop mapping `destination:*` tags for the sake of other OpenStreetMap users and contributors because you are doing more harm than good.

You also do not understand how turn restrictions actually work, in other words, what is their meaning to OpenStreetMap and what do they actually map because you have fallen into the same trap like many other new mappers before you. You have started to add `restriction=no_u_turn` relations with identical ways in the `from` and `to` roles. These turn restriction relations DO NOT add any value to the map. They do not fix navigation either. Turn restriction relations map the flow of traffic, not the legal situation on the road. What you are trying to map is the legal situation on the road. For this purpose you should map using the `traffic_sign` tag.

You also apparently do not know when or how to map roads with ways.
1. We do not map lanes with ways.
2. We only map separate ways when there is a physical barrier or divider between road surfaces.
3. We do not delete inaccessible roads, even if they are in decay. We tag them `access=no`.

Final life lesson for the day: Think twice, sometimes even three times before you act because what may seem simple to do can cause a lot of damage when done or done badly. You are still a new mapper. Start with the simple stuff like adding buildings and roads. Learn by observing what others have done, especially very experienced mappers before you touch anything more complex. And, read the OpenStreetMap Wiki before you start learning a new potentially more complex mapping scheme. There is always more than to it than you may think. Thus, you may also want to use a more sophisticated editor than iD before mapping anything more complex, like [JOSM](https://josm.openstreetmap.de "Java OpenStreetMap Editor").

66979450 over 2 years ago

Are you sure CR 111 does not exist?

110994524 over 2 years ago

Oh, I forgot to mention that whenever you add a street name it is probably best to check any existing `addr:street` tag values in the vicinity. For example, I have encountered tags like `addr:street=New York 25A`. Otherwise, address search will not update and will not work correctly.

113062710 over 2 years ago

Great! 👍 You can use the history function to see what the `destination:*` tags looked like before. Thank you!