Chodziło mi o zacięcia naszych serwerów z osmapą i z wizualizacjami.
Raz aktualizacje są co godzinę a kiedy indziej miesiąc nie wystarcza.Dla pewnych danych serwer nadgania kilkudniowe spóźnienia ale robi to już chyba ze 2 tygodnie i ciągle nie może dogonić diffów.
Wrocław udostępniał mapę budynków3D (dla centrum) zrobioną lidarem czyli 4-6 pomiarów na m2.
Udostępnił przy tym odczyt wysokości choć to było odczytywane z bardzo zaszumionych danych i nie bardzo wiem jak to uśredniali, bo mi nie pasowało z innymi źródłami więc to może brak korekty dla niwelacji gruntu.
Niestety profile wysokościowe już nie działają a zawsze można było te wysokości szybko uzyskać a resztę interpolować z proporcji odczytywanych ze zdjęć.
Widocznie coś było lipnego w tych danych skoro ukryli a może pozazdrościli OSM, bo ze 2 lata temu zrobiłem ok 9000 obiektów 3D we Wrocławiu.
Gdyby chcieli udostępnić dane czyli gdybyśmy połączyli z nimi siły to może byłoby czym się pochwalić.
Ciekaw jestem jak ten model GISowski wygląda i jakie są te klasy dokładności.
Szkoda, że to wszytko nie służy prezentacji a inwigilacji przez Wydziały Budowlane czy ktoś np. zabudowy tarasu nie zrobił.
Witam! Potwierdzam. Ostatnio miałem trochę nerwów i straconego czasu wysyłając zmiany na serwer( Nie jestem pewien do końca czy moje modyfikacje się “przyjęły”
) Również kilka innych drobnych błędów na stronie, jednak bardzo szybko naprawianych, wielkie brawa dla administratorów!.
Dane trzeba już wysyłać częstej i w mniejszych porcjach.
Zauważyłem, że na stronie https://www.openstreetmap.org zmiany przeze mnie wysłane wczoraj, przedwczoraj nie się wyświetlanie(jak wchodzę w tryb edycji są widoczne, ciekawe). Wcześniej zmiany były widoczne po kilku minutach.
Nie bardzo wiem, po co tworzyć takie wielkie porcje danych do wysłania
Ankieta dotycząca MapRoulette. Można powiedzieć co chcielibyśmy ulepszyć. https://goo.gl/forms/J8yhWC3IBsUZmTjS2
W opisie API v0.6 jest już poprawione, że changeset może zawierać tylko 10.000 zmian ale w artykule porównującym v0.5 i v0.6 jeszcze jest po staremu
http://wiki.openstreetmap.org/wiki/API_changes_between_v0.5_and_v0.6
Ciekawe ze Skandynawii. Bazuje na mapach OSM:
frikart.no
Openstreetmap.no
Fragmenty map do wydrukowania za friko:
kartverket.no
Przy ichnim odwzorowaniu poziomym nawet 3D staje się zbędne
Całkiem niezłe poziomice dla Topo-letniego
http://frikart.no/garmin/velgkart.html
Szkoda, że tylko na Garmina
Próba częściowego zautomatyzowania wyrysowania dróg w OSM poprzez Facebook. Jak na mój gust jak zawsze górę biorą absurdalne zarzuty przy których te rzeczywiste problemy stają się jedynie marginesem w dyskusji.
https://lists.openstreetmap.org/pipermail/imports/2017-March/004840.html
https://forum.openstreetmap.org/viewtopic.php?id=57387
Dąb Józef został wybrany drzewem roku
https://www.treeoftheyear.org/ETY-2/Uvod.aspx?lang=pl-PL
Co ciekawe, twierdzą, że poprawili iD do poziomu zbliżonego do JOSM’a i chcą to udostępnić.
Przypominam, że dwie poprzednie próby wprowadzenia takich danych do OSM zakończyły się wycofaniem tych danych na prośbę Facebooka, który sam przyznał, że w ostatnim etapie coś mu nie zadziałało.
Nie można się więc dziwić społeczności, że wyraża obawy związane z nowym importem. Przynajmniej tym razem Facebook zaczyna dyskusję przed jego dokonaniem, a nie po.
Generalnie, myślę że ich korporacyjna organizacja pracy dała trochę o sobie znać - tak jak np. prośba żeby pytania kierować na maila (i to co powiedzieli, że importy w jakimś tam kraju dyskutowali w PW z członkami lokalnej społeczności), albo okrągłe formułki w odpowiedziach w dyskusji. My cenimy transparentność.
Tak samo korporacyjne wydaje się włożenie pracy po to, aby ulepszyć iD rzekomo do poziomu JOSM (coś w to nie wierzę, chociażby wydajnościowo) - bo dla nich to żadne pieniądze i nieważne czy praca pójdzie na marne.
Nie mówię, że jest szczególnie źle, tyle że do naszej (w teorii) merytokracji i stylu pracy trzeba się trochę dostosować. Mapboxowi jakoś się udaje.
To jak ktoś coś zrobił w przeszłości nie zmienia to faktu że te maszynowo uzyskane dane są w wielu przypadkach lepsze niż w niejednym wypadku ręcznie wprowadzone. Nie zliczę ile poprawiłem dróg idących w poprzek miejscowości przez środek budynków np. ostatnio w tej okolicy http://www.openstreetmap.org/#map=14/50.7719/21.8785 a mimo wszystko nikt nie miał pretensji by takie dane w OSM istniały. Jak wspomniałem część zarzutów jest absurdalna a wymagania jak na przykład to by opublikowali kod na podstawie którego dane uzyskali czy nazwiska wszystkich co przy tym pracują (ostatecznie opublikowali pełną listę pracowników) jest co najmniej niepoważny. To tak jak by wymagać nazwiska wszystkich urzędników zbierających dane adresowe czy kod programu którym wprowadzają te dane do urzędowej bazy, gdyż w ten oto magiczny sposób będziemy pewni poprawności danych. Skoro nie wymaga się tego w innych przypadkach to nie widzę żadnego obowiązku by wymagać tego i w tym przypadku.
Na tyle ile ja zrozumiałem ich przekaz to wprowadzili do iD pewne usprawnienia znane z walidatora JOSM i raczej nie ma mowy o odwzorowaniu pełnej funkcjonalności czy wydajności.
https://lists.openstreetmap.org/pipermail/imports/2017-March/004890.html
· roads crossing waterways.
· roads with repeating node IDs.
· roads with possible connections after a short extension.
Zresztą kod mają na dniach opublikować także dość szybko się okaże o jakich zmian dokonali.
Pewnie i tak choć jak dla mnie ta praca to najlepszy dowód na to, że nawet w takiej organizacji (ominę tu całą listę stosownych aczkolwiek mało pochlebnych przymiotników którymi można by opisać korporację odsyłam jedynie to stosownego dokumentu na ten temat https://www.youtube.com/watch?v=KMNZXV7jOG0) można wykonać pracę, która może być przynajmniej w założeniach jak najbardziej chwalebna.
Tego akurat nie wiemy, bo Facebook nie może udostępnić zdjęć, których użył, a dostępne nam zdjęcia są słabej jakości.
Widocznie nie wiesz, co było poprzednio. Facebook zrobił problematyczny import dróg ze zwykłego konta, w opisie zestawu zmian nie podał, że to Facebook, ale za to podał źródło danych - akurat takie, które nie jest licencjonowane dla OSM. Trzeba się było dopytywać w zestawie zmian o co chodzi.
Wymóg podania nazw kont jest właśnie po to, by było wiadomo, co jest z Facebooka a co nie, bo po nazwach tych kont się nie zorientujesz. I widnieje ten wymóg na Import/Guidelines
Nie pamiętam czy żądali od nich podania nazwisk pracowników, choć by mnie to nie zdziwiło, bo taki wymóg jest choćby przy Automated_Edits_code_of_conduct
Wiem co było. Ponad rok jestem na tej liście mailingowej. Sytuacja jest odmienna obecnie. Lubię historię, ale zbyt często się nią żyje.
No i co? Konta są znane więc w czymś jeszcze problem? Zresztą jak go widzisz możesz z powodzeniem zabrać głos w dyskusji na liście
Na czym ma polegać obecne zbieranie danych przez facebooka, bo trudno mi się tłumaczy?
Ok. Musiałem się więc pomylić i nieprawidłowo odebrałem Twoje wypowiedzi jako negatywnie nastawione wobec DWG i jako brak świadomości zasad przyjętych w OSM dla importów.
Musiałem się mętnie wyrazić. Ja nie widzę problemu w wymaganiach wobec Facebooka, dlatego nie zabieram głosu na tej liście. Moje wyjaśnienia wobec wymogu podawania kont dotyczyły wprost Twojej wypowiedzi: “nazwiska wszystkich co przy tym pracują (ostatecznie opublikowali pełną listę pracowników) jest co najmniej niepoważny”. Uznałem, że to zdanie oznacza, że Ty widzisz w tym problem, tym bardziej, że poruszasz go po tym, jak już tę listę kont opublikowali. Możliwe, że nie zrozumiałem sensu tej wypowiedzi.
Mówiąc wprost to chodziło mnie o to, że zdecydowana większość tych wymagań to jakieś banały które można załatwić tudzież załatwiono jednym ruchem i bardziej wyglądają na szukanie powodu by czegoś nie robić (patrz podobne przypadki przy zmianach w carto) niż to co powinno mieć miejsce czyli znalezienie sposobu by jednak wykonaną przez FB użyć.
Praktycznie pozbyliśmy się z bazy wielokątów starego typu:
https://lists.openstreetmap.org/pipermail/talk/2017-May/077938.html