Jako nieco latający (tylko na szmacie ale jednak ) chciałbym zwrócić waszą uwagę na projekt który powstał obok OSM ale korzysta z narzędzi i struktur OSM. OpenAviationMap,org - czyli mapowanie wszystkiego co związane z nawigacja lotniczą.
Projekt dosyć kulawo się rozwija - po 2 latach w ich bazie są w miarę kompletne dane tylko dla Węgier i Niemiec.
A wielka szkoda bo środowisko ludzi latających (przede wszystkim rekreacyjnie) jest tylko w Europie liczone w setkach tysięcy
a chyba nie potrzeba tłumaczyć jakie korzyści OSM mógłaby odnieść (np w postaci fotografii lotniczych) z ich udziału.
W tej chwili nie są dostępne żadne otwarte mapy lotnicze które objemują teren więcej niż jednego państwa.
Główną przyczyną dla której projekt jest robiony obok OSM był dość głośno wyrażony sprzeciw części (głownie niemieckich) mapperów przed
wprowadzaniem do bazy OSM danych nie związanych z istniejącymi obiektami (na ziemi) oraz, że te dane (np granice stref lotniczych) będą “zaśmiecać” bazę i wprowadzać w błąd mapperów. Sugestie były/są takie ( patrz wiki http://wiki.openstreetmap.org/wiki/Aviation ), żeby
dane lotnicze były renderowane na mapach OSM jako overlay z zewnętrznych źródeł. Był również podnoszony problem, że są to dane de facto 3D, co oznacza problemy w trakcie edycji
Takie podejście niestety prowadzi do tego, że:
projekt OVM jest kompletnie niszowy i mała jest szansa żeby szybko wszedł w fazę globalną
społeczność mapująca jest mała a ew chętni mają uzasadnione wątpliwości czy ich wysyłek nie pójdzie na marne kiedy projekt padnie
dane są wprowadzane na osobny serwer, którego koszt utrzymania jest nieproporcjonalnie duży w stosunku do symbolicznej ilości danych które są potrzebne ( kompletne dane dla Węgier zajmują kilka MB )
pokonywanie problemów znanych z OSM (jak np pozyskiwanie danych z zasobów publicznych) jest znacznie utrudnione
Twórcy projekty widzą te problemy i są cały czas otwarci na powrót do koncepcji wspólnej bazy (nie ma żadnych przeszkód technicznych czy konfliktów w tagowaniu z OSM).
Argumenty z drugiej strony są proste:
ilość danych lotniczych jest pomijalnie mała w stosunku do pozostałych a zysk z ich utrzymania w OSM znacznie większy niż ew.
problemy z “dziwnymi” i “wirtualnymi” obiektami w bazie
są mapowane w OSM dane dt np morskich szlaków wodnych które również nie istnieją realnie i nie są widoczne w terenie
właściwe tagowanie rozwiązuje problem (nie)renderowania danych lotniczych na mapach terenowych.
istniejące aplikacje które korzystają z surowych danych OSM (offline lub online) dostałaby możliwości prezentacji danych lotniczych
przez prostą edycję dodanie odpowiednich stylów renderowania.
Zasugerowałem na razie na forum tamtego projektu, żeby opublikować na wiki OSM użytą konwencję tagowania i po dyskusji poddać je pod głosowanie.
Bede dyskutowal z zarzadem OSMF nowa koncepcje glównej strony i OSM w ogóle.
Idea jest taka by wprowadzic warstwy. Pomysl jest dosc stary ale w zupelnosci by sie sprawdzal. Dzialalo by to tak, ze wybiera sie i wlacza lub wylacza dana warstwe iformacji. Jesli jest wlaczona a my pracujemy aktualnie w innej warstwie, to widac te informacje w postaci jasnoszarych punktów lub linii. Tak wiec mozna np. dociagnac linie do jakiegos punktu lub elementu ale nie mozna tego elementu skasowac.
Bardzo pomoglo by to wlasnie projektom takim jak ten o którym piszesz.
Na pewno obsługa warstw jest właściwym kierunkiem działania na poziomie technicznym.
Ale czytając wypowiedzi userów widzę też take podejście: Czy te dane są w ogóle potrzebne w bazie bazie OSM skoro będzie z nich korzystać powiedzmy 0.1% wszystkich użytkowników ?
A to już jest kwestia wyłącznie otwartego podejścia i przekonania, że projekt OSM powinien służyć swoim potencjałem nie tylko większości ale również mniejszościom.
Bylem swiadkiem tych dyskusji, ale nie jestem przekonany, ze taki podzial jaki potem powstal, z oddzielna baza danych jest zly. Oczywiscie trasy promow czy statkow tez mysle, ze maja swoje miejsce w oddzielnej bazie lub na oddzielnej warstwie takiej o jakiej mowi Marek.
Raczej niz niszowy uzylbym slowa specjalistyczny, i to wydaje sie logiczne. Podobnie jest z kilkoma innymi rodzajami danych (opendem.info, openaerialmap, kolej.one.pl). Jak powiedzial jeden mapper (Niemiec oczywiscie), osm to nie jest kosz w ktorym maja mieszac sie wszystkie geograficzne dane swiata jakie uda sie pozyskac. W wypadku danych lotniczych tych obiektow jest tak jak mowisz niewiele, ale sa to duze obiekty ktore beda sie pojawiac w edytorze 99.999% czasu ludziom ktorzy nie maja pojecia co to jest.
Zaleta otwartych projektow jest taka, ze nawet jesli przestaja byc rozwijane, to dane nie znikaja z powodu awarii dysku u kogos i zeby projekt ozyl na nowo wystarczy jedna osoba, wiec tak na prawde nie ma ryzyka padniecia projektu.
Tu sie nie zgodze, zasoby potrzebne takiemu serwerowi maleja z iloscia danych / liczba edytujacych i to nie liniowo a eksponencjalnie. Zwykly desktop z duzym zapasem wystarczy na taki serwer.
To prawda, ze OpenStreetMap to tez marka ktora pomaga w takich rzeczach. W sumie nie ma powodu dla ktorego OSMF nie powinna wspierac “siostrzanych” projektow osm bo jest to tez w jej statucie.
Wlasnie rozwazamy czy podejscie do tematu “warstwowe” nie rozwiazalo by problemu bo jak Balrog pisze, nie sa to az takie ilosci danych a w wersji standardowej warstwy byly by wylaczone tak, by nie byly przeszkoda dla poczatkujacego uzytkownika. Utrzymanie prostoty to jedno z wyzwan projektu. Ma byc on przyjazny dla kogos, kto pierwszy raz chcialby wprowadzic na mape proste informacje z otoczenia które zna. Tak wiec warstwy powinny dzialac jak relacje: Trzeba bedzie dosc dobrze poznac projekt, by sie za nie zabrac, jakkolwiek oczywiscie kazdy moze je tworzyc i modyfikowac.
Akurat podane przykłady są o tyle nietrafne, że dotyczą danych których wrzucenie do OSM jest problematyczne z powodu innego formatu , objętości itp powodów technicznych albo są z definicji nieaktualne.
Każdy specjalistyczny rodzaj danych zawsze będzie niszowy w tym sensie, że jeśli przyjmiemy założenie (które jak rozumiem reprezentujesz): “masz specjalistyczne dane, zrób sobie na boku swoje OSM, od nas masz narzędzia i dobre słowo”
to liczba potencjalnie mapujących/korzystających z tych danych ludzi najczęściej nie przekroczy tej masy krytycznej ( którą już OSM dawno posiada) żeby rozwijać się równie dynamicznie jak główny projekt.
Więc co z tego że mamy gotowe narzędzia, i możemy sobie zrobić na boku świetną mapę (np. lotniczą) świata, jeśli jej doprowadzenie do stanu używalności zajmie tyle czasu (globalnie) że większość potencjalnych użytkowników zajrzy (jeśli w ogóle znajdzie projekt) , zobaczy że na razie słabiutko, i szybko nie wróci.
Takie podejście nie służy rozwojowi OSM który wg mnie rozwija się tak dobrze bo własnie jest otwarty na różne potrzeby ale tworzy de facto jedną dużą społeczność
Choć rozumiem, że dla każdego jest inna granica ile tej różności należy dopuścić.
No wlasnie otwarciu na projekty specjalistyczne oraz pogodzeniu podejscia “klasycznego” wg którego (dla duzej czesci uzytkowników OSM) na zawartosci specjalistyczne nie ma w OSM miejsca gdyz niepotrzebnie komplikuja mape.
Ja bym to zdanie doprecyzował, że zawartość specjalistyczna komplikuje (przy istniejącym schemacie / narzędziach ) jedynie edycje mapy,
bo na używanie danych (te specjalistyczne w dużej części mają marginalną objętość) nie ma to żadnego wpływu.
Nie chodzi tylko o to. Chodzi przede wszystki on “On the ground rule”. Ale tez o wlasnie komplikowanie edycji i o to, ze dopuszczenie wyjatku raz, powoduje powstanie precedensu do dodawania czegokolwiek, rzeczy typu granice dzialek ktore zapchalyby cala baze, czy prywatne dane sluzace jeszcze mniejszej grupie osob (np. jednej firmie).
To, ze OSM posiada mase krytyczna nie powoduje, ze wiecej ludzi dodawaloby dane lotnicze. Moze by tak bylo, a moze nie. Spowodowaloby pewnie to, ze statystycznie latwo byloby o zepsucie takich danych a statystycznie ciezko o naprawienie.
Dlatego oddzielne bazy (czy warstwy, bo to tak naprawde zadna roznica) maja wiecej sensu.
) chciałbym zwrócić waszą uwagę na projekt który powstał obok OSM ale korzysta z narzędzi i struktur OSM.