Głupie pytanie: Dlaczego OSM nie rysuje łuków?

Jak w temacie.
Rozwijając temat - dlaczego nie da się rysować kółek, łuków krzywych, tylko jakiejś mniej lub bardziej kanciasty szereg połączonych odcinków? Przecież świat to nie Minecraft ;).
Rysowanie i odzworowanie łuków, jak np. w Corel Draw, to chyba nie jakiś mega problem. Spotkałem się z tym nawet w darmowym programie do tworzenia map dla biegów na orientację Openorienteering Mapper i działa to tam całkiem dobrze.

Zamiast robić okrąg składający się np. z 20 punktów, by nie wyglądał jak koło z samochodu Flintstonów, łatwiej chyba by było opisać taki okrąg poprzez podanie 3 parametrów: koordynat jego środka i średnicy. Opisanie wzorem łuku też nie powinno być problemem, a pewnie też ładniej by to wyglądało.

W czym więc tkwi problem?
Wiem, wiem, pierwotnie tak się rysowało, ale idąc z duchem czasu i możliwościami sprzętu chyba dałoby się dołożyć krzywe bez większej dramaturgii(?)

To nie takie proste.

Trzeba by dorobić wsparcie w wszystkich edytorach i wszystkim co importuje dane (chociaż jakiś krok pośredni)

Dorobienie osobnego typu dla obszarów byłoby prostsze a i tak jest to na tyle trudne że nikt nad tym nie pracuje

Łamane to najmniejszy wspólny mianownik systemów GIS. Nie tylko OSM nie używa łuków, nie używają go też nasze rządowe mapy jak BDOT.

Ale masz rację w takim sensie, że samo rysowanie łuków mogłoby być ułatwione w edytorach.

W JOSM można zrobić kółko osobną funkcją, a łuk to pewnie przez rozcięcie go.

Dałoby się, ale w wijącego się strumienia już nie zrobisz.

Skoro nie można tego wprowadzić jako elementu mapy, to na pewno wygodniejsze by było, gdyby w edytorze, w momencie tworzenia nowej linii/figury były dostępne narzędzia obsługujące krzywe. Po zakończeniu tworzenia obiektu byłby on szatkowany na odcinki, by było to zgodne z obsługiwanym formatem.
Ewentualnie taki obiekt miałby zapisany jakiś tag, parametr czy cuś, co pozwoliłoby takim edytorom rozpoznać, że to je krzywa i po ponownym otwarciu do edycji odpowiednio to zinterpretować.
Chyba nie powinno z tym być problemu, skoro w OSM są zaszyte dane o kształcie dachu czy materiale:
roof:colour=green
roof:material=metal
roof:shape=gabled
Gdyby ktoś przeedytował taki pokrzywiony obiekt w edytorze nieobsługującym tych krzywych, to takie dane (te o krzywych) musiałyby być kasowane, bo przestałyby odpowiadać zmianom dokonanym na nie-krzywych.

Praca na wielokątach jest dużo prostsza (czytaj szybsza) niż na takich z łukami. Zważ, że każdy taki łuk trzeba by przeliczyć przy wszelkich pomiarach długości, pola itp. Nakładając na to, że w takim przypadku zaczynają się pojawiać liczby niewymierne, z pi na czele, to nagle może się okazać, że z tych samych danych dostajesz różne wyniki i wszystkie są prawidłowe.

Mówiąc krótko – wielokąty może nie są tak eleganckie, ale dużo szybsze w obsłudze i jednoznaczne.

Wbrew pozorom grafika wektorowa nie opiera się na jakichś mega skomplikowanych obliczeniach, z którymi nie poradzi sobie obecny hardware. Odwzorowywana jest w niezbyt skomplikowany sposób. Skoro radzi sobie z budynkami 3D, to z łukami i krzywymi tym bardziej. Znasz format SVG?
Wejdź sobie na stronę, z menu wybierz Viev \ Source…, kilka linijek kodu zastąp poniższym kodem i kliknij Apply Changes.

Nic skomplikowanego.

<svg width="800" height="600" xmlns="http://www.w3.org/2000/svg">
 <g id="Layer_1">
  <title>Layer 1</title>
  <ellipse ry="53" rx="110" id="svg_3" cy="113" cx="636" stroke="#000" fill="#fff"/>
  <path fill="#fff" stroke="#000" opacity="NaN" d="m349,153c0,0 26,-23 52,0c26,23 94,38 75,106c-19,68 -5,139 -101,111c-96,-28 -289,-172 -158,-21c131,151 181,199 89,190c-92,-9 -130,-40 -134,-127c-4,-87 -95,-212 -8,-161c87,51 123,77 140,34c17,-43 -69,-117 -69,-117c0,0 -44,-42 10,-28c54,14 104,13 104,13z" id="svg_1"/>
  <path id="svg_2" d="m558.19992,397.69795l53.47562,0l16.52438,-60.3508l16.52439,60.3508l53.47562,0l-43.26261,37.29842l16.52523,60.3508l-43.26263,-37.29943l-43.26262,37.29943l16.52524,-60.3508l-43.26262,-37.29842z" stroke="#000" fill="#B8D078"/>
 </g>

</svg>

No pewnie, ale wijący się strumień nie jest jednak regularny, a nie każdy zaokrąglony kształt nawet jak jest opisany jakimś prostym wzorem, to od razu koło (np. funkcja kwadratowa). Myślałem głównie o budynkach w tym kontekście.

Oczywiście, samo wykreślenie tego nie jest problemem, czego dowodem są właśnie programy i formaty czysto graficzne.
Ja, wyhodowany jeszcze pod koniec czasów kartografii tradycyjnej (ręcznej), też długo nie mogłem się pogodzić z takim podejściem. Niemniej jednak w GIS się krzywych nie stosuje, a przestrzenne bazy danych, takie jak Postgres, czy MariaDB też ich nie obsługują. Jakiś istotny powód tego musi być.

Rzuć okiem na przykład svg, jaki wrzuciłem? Tam nie ma żadnych wzorów kwadratowych, czy wyższych stopni. Czy jest to łuk, czy wężyk, jak ~, to jest to do narysowania 2 punktami i informacją o zakrzywieniu łuku/wężyka. Bardziej skomplikowana krzywa jest podzielona na punkty dzielące ją na łuki/wężyki, jak w zdaniu wcześniej.

Tylko co tu trzeba specjalnego w bazie danych? Zamiast rysowania łuku, który żeby ładnie wyglądał, trzeba zapisać jako zbiór 55 punktów (sprawdziłem łuk jednej drogi w okolicy), wystarczyłoby tyle: . Proste, prawda?
Baza danych nie ma tu znaczenia, niczego specjalnego do obsługi tego nie trzeba, wszak te dane to zwykłe liczby. Informacje o 3D budynków są zapisywane, a interpretery nie mają problemów z ich wyświetlaniem.

Otóż to. Po prostu dociekliwy jestem :). Na tym chyba można by zakończyć dyskusję.
Miłego dnia :).

Jedno mi jeszcze do głowy przyszło – wyszukiwanie przestrzenne w zadanym obszarze. Przy wielokątach baza analizuje punkty znajdujące się w zadanym terenie, a przy krzywych musiałaby całą bazę orać, czy przypadkiem coś z punktami kontrolnymi spoza niego się nie wygnie w interesujący nas zasięg.
Spróbuję się jednak wywiedzieć od fachowców, czy poza względami historycznymi coś więcej na przeszkodzie stoi. Temat ciekawy :slight_smile:

Dodatkowo - operacje na geometrii (testowanie relacji przestrzennych jak przecinanie, zawieranie, stykanie; generowanie unii i różnicy; przycinanie geometrii) są wystarczająco trudne już na łamanych - z powodu przypadków brzegowych. To wbrew pozorom robota na doktorat :slight_smile: i większość używa gotowych bibliotek jak GEOS.

tak dla ścisłości - baza niczego nie analizuje, jest tylko magazynem danych :-).

no ale teraz obiekty 3D zawierają informacje o np. okręgach.
Select mógłby wyciągać z bazy dane np. z jakimś tam marginesem.
Poza tym mnie bardziej chodzi o przechowywanie danych o krzywych przydatnych(ułatwiających) w edycji, jako dodatkowe tagi, a same krzywe podczas zapisu zmian dokonywanych, w edytorze obsługującym krzywe, zamieniane by były na ciąg odcinków połączonych punktami, tak, by było to zgodne ze starszymi wersjami (Tak jak OSM nie wyświetla domów 3D, tylko robi to np. https://demo.f4map.com/

Byłoby super! Też dla mnie jest to ciekawe zagadnienie, dlatego tak go drążę, poziom czepialstwa = 0, ciekawość = 10 :D.

i pewnie 90% użytkowników to wystarcza i jest zadowolona, dopóki nie przylezie taki jak ja i zacznie drążyć :D.

Moim zdaniem występujące w naturze krzywe na tyle mają w nosie prostotę geometryczną, że przy rysowaniu mapy łukami albo będzie tak jak w terenie, albo szybciej niż narysować łamaną. Bo żeby się dobrze dopasować do tego, co w terenie trzeba będzie zrobić tyle łuków, że już szybciej będzie tę łamaną punkt po punkcie wyklikać.

Bazy normalnie umożliwiają wykonywanie zapytań do danych, a więc akurat całkiem legalne wydaje mi się stwierdzenie, że analizują dane, by zwrócić oczekiwane wyniki.

Jak wyżej: jeśli bazę danych rozumiesz jako plik, który tylko przechowuje dane, a to właśnie wynika trochę z Twoich wypowiedzi, to może i tak. W praktyce jednak w bazach danych chodzi o coś więcej, np. o umożliwienie analizy i przetwarzania tych danych. W przypadku danych geograficznych kluczowe są operacje przestrzenne, o których pisali Marek i Rico. Obsługa krzywych znacząco zwiększa złożoność oprogramowania i zmniejsza jego wydajność, a w wielu przypadkach okazuje się, że nie daje istotnych korzyści - liczą się przede wszystkim wnioski z analizy i okazuje się, że aproksymacja kształtów za pomocą łamanych jest zupełnie wystarczająca. Niektóre narzędzia zdają się - po pobieżnym sprawdzeniu - wspierać krzywe: PostGIS łuki, ArcGIS nawet krzywe Beziera. Ale akurat od OSM trudno by tego oczekiwać, skoro wiele bardziej podstawowych spraw w modelu danych ma rozwiązane inaczej niż 90% zbliżonych baz :smiley:

Gdzie zawierają? Jeśli mówisz o kształtach dachów, to przecież w OSM zapisana jest tylko nazwa tego kształtu (możliwe, że nie rozumiem wywodu).

Może edytory tak robią, ale dane w bazie OSM to lista punktów. A te punkty (krzywe) łączą się z innymi punktami i liniami, więc tak się nie da. Jak połączysz krzywą opisaną w podany przez ciebie sposób z inną krzywą w danym punkcie?

Dwudziestokąt foremny to dobre przybliżenie okręgu w życiu codziennym, na mapie nie zobaczysz różnicy.

Renderery 3D różnie interpretują kształty dachów. A punkt na mapie ma konkretne współrzędne.

Zdaje się, że tego Ci trzeba: :wink:
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Spline-drawing-tool
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Splinex

No i wszystko jasne. Dziękuję.

Fajne! tylko jak je doinstalować? Bo pod F12 na liście ich nie mam.

Dziękuję Kolegom za wyrozumiałość dla upierdliwca i cierpliwość w tłumaczeniu :).

Nie ma głupich pytań, mogłoby być więcej takich dyskusji.

Umożliwienie zapisywania łuków wg podanego przez ciebie schematu () wymagałoby zmiany modelu danych OSM, czyli przeprowadzenia rewolucji. Aż takiej dokładności jak w grafikach wektorowych nie potrzeba, bo mapa też jest tylko uproszczeniem rzeczywistości, a nie modelem 1:x. Poza tym takie gładkie łuki byłoby widać tylko na bardzo wysokich zoomach, jeśli w ogóle ktoś widziałby różnicę. Dla zwiększenia dokładności krzywych, można po prostu narysować więcej punktów.