Cześć 
No właśnie bo się trochę zastanawiałem o losie współpracy mojego softu z OSM (w założeniu ma być komercyjne, bo nie widzę innej sensownej metody utrzymania/prowadzenia projektu). Tyle że ja akurat miałem w planach udostępnić bezpłatnie część licencji osobom najbardziej zaangażowanym w projekt (dziwnie by było, aby ktoś kto przykłada się do edycji publicznie dostępnych danych miałby jeszcze płacić za edytor) - kiedyś to zapowiadałem (przy przystąpieniu przeze mnie do OSM) przy wczesnym etapie projektu i to dalej podtrzymuję. Mam nadzieję, że ludzie ze społeczności nie będą się krzywo patrzeć - że coś jest komercyjne to jest be, bo open-source jest lepsze
A te obiekty - to w sumie ciekawy temat poruszyłeś, bo sam ostatnio się z tym borykałem (dodatkowe obiekty). W programie przewiduję u siebie import danych (np. z DXF, DGN, XML)…itd i w niektórych formatach mamy zdefiniowane obiekty złożone. Z drugiej strony w OSM mamy do czynienia z liniami i punktami - nawet poligony są definiowane raczej ze stylu niż z konkretnego typu obiektu powierzchniowego. Gdybym np. chciał dodać rysowanie okręgów, kształtów, to nagle się okazuje że można je na potrzeby OSM zamienić w “drogi” (łamane / “polyline”), ale w drugą stronę to byłby problem (bo trzeba by zachowywać jakieś dane dot. kształtu, aby móc go odtworzyć jako obiekt a nie linie). Z drugiej strony implementacja OSM jest przez swój format prosta i dzięki temu generuje mniej problemów niż kwestie związane z kształtami (np. prostokąt w projekcji jednego układu w drugi nie musi wcale być prostokątem, podobnie łuki/okręgi… - układy odniesienia potrafią nieźle skomplikować sytuację). Inna kwestia to np. opisy tekstowe (etykiety) - w takim Autocadzie mamy obiekt TEXT - w JOSM nie ma takiego typu - więc sporo racji w tym, że jest to temat na dłużej (szczególnie jeśli chodzi o globalną implementację i zmianę API).
Dobra bo już idę dookoła… chodzi o to, że robiąc pakiet tylko pod OSM ma się tę wolność, że można robić wyspecjalizowaną - dedykowaną aplikację - i nie ma takiego nacisku na różne szczegółowe specyfikacje. I tak powstał JOSM -z najprostszych pomysłów, które z reguły okazują się sprawdzone. Ale np. gdyby geodeta chciał wykorzystać taki program, to nagle pojawia się problem - z kompatybilnością obiektów/układów odniesienia/zastosowaniem…itd Tu z kolei wchodzę ja, bo chciałbym umożliwić choć częściowe przejście z jednych danych na drugie (i vice versa).
Bo np. taka sprawa z mapowaniem - geodeci mają swoje operaty, w których mają zawarte obliczenia jakie doprowadziły do uzyskania odpowiednich współrzędnych. W przypadku OSM nie ma takiego wymogu, a czasem przydałoby się wiedzieć, jakie punkty są oznaczone precyzyjnie (np. bazując na osnowie i dokładnym pomiarze), a jakie mniej dokładnie (i które mogą wymagać kiedyś poprawy). Jak np. w programie udostępniam możliwość wyznaczenia punktów pośrednich z wcięć liniowych lub przecięć, to jeśli z OSM miałbym dane, które punkty mamy określone z jaką precyzją, mógłbym oszacować czy np. obiekt jaki pomierzę - będzie miał wystarczającą dokładność. I fajnie by było gdyby takie dane były dostępne dla każdego, kogo to interesowałoby.
Szczególnie mogłoby to pomóc w sytuacjach, w której nieświadomi początkujący użytkownicy przesuwają już narysowane obiekty, ponieważ “nie pasują do podkładu”. A tak mielibyśmy obiekty “zamrożone” (jakieś tagi typu freezed/fixed position), których nie dałoby się w prosty sposób przesuwać i psuć geometrii. Obiekty te mogłoby służyć także jako referencje / obiekty bazowe do wyznaczania innych (np. elementów w terenie - położenia drzew…itd).
Bo np. ja zakładam, że mając dalmierz laserowy (są coraz tańsze) można zrobić bardzo precyzyjne pomiary - także przydatne w 3D. Precyzja by się przydała także w przypadku gdyby OSM miał służyć do bardziej precyzyjnych celów (np. wspomaganie nawigacji i samoprowadzących samochodów). Większość pewnie i tak nie przykłada wagi do dużej precyzji, ale zakładam, że w przyszłości będzie się to zmieniać (dostępność sprzętu i metod pomiarowych) - i wtedy możliwość osadzenia takich danych byłaby pomocna. Podobnie kwestia pomiarów GPS - dziś można relatywnie tanio zmontować układy do pozycjonowania z dokł. centymetrową co możnaby wykorzystać w przypadku OSM. Nawet jeśli ktoś twierdzi że to mało istotne - to np. tagi dotyczące teksturowania obiektów są już nam bliższe, więc tak czy inaczej API/specyfikacja OSM musi być rozszerzona.