Wypowiedzi
-
Witam,
Na pewno nie możesz przerysowywać komercyjnych źródeł danych
Obrysowywanie danych satelitarnych jest już bardziej dyskusyjne, ale np. projekt Open Street Maps obrysowywania takich map zabrania, ponieważ są wątpliwości czy jest to zgodne z prawem. W TOS Google Maps, znajduje się zapis, że jest to zabronione.
Dane z Open Street Maps są dla Polski są bardzo dobre, często lepsze niż w Google Maps. Możesz z nich korzystać za darmo pod warunkiem, że stworzona przez mapy będą odpowiednio opisane i licencjonowane [1]. Ogólnie nie jest to problem w przypadku wydawnictw papierowych (wystarczy jedna adnotacja na całą książkę), ale polityka niektórych wydawnictw może wykluczać użycie takich materiałów.
Projekt ShareMap.org (w którym biorę udział) ma na celu udostępnienie narzędzia Web GIS, które umożliwia tworzenie map, import danych z OSM i publikację na wiele kanałów w tym wektorowy SVG i użyte w druku albo na stronie internetowej - przykład użycia takiej mapy, to np. na tej stronie na dole [2]. Na GIS Loung znajduje się artykuł na ten temat mojego autorstwa [3].
Polecam też filmiki kanał na YouTube [4]
[1] http://wiki.openstreetmap.org/wiki/Legal_FAQ
[2] http://olsztynskietramwaje.pl/trasa/
[3] http://gislounge.com/creating-maps-for-wikipedia-and-p...
[4] http://www.youtube.com/user/ShareMap -
W tym artykule poruszona jest problematyka tworzenia dokumentów map, które mogą być użyte potem w programach biurowych.
http://gislounge.com/creating-maps-for-wikipedia-and-p... -
Trochę spam, ale moim zdaniem warte zajrzena- promocja umożliwiająca zakup książek za pół ceny w księgarni Traffic - http://www.groupon.pl/oferty/warszawa/trafficclub-wars...
- 23.10.2011, 02:30
-
Witam,
jestem jednym ze współtwórców projektu ShareMap mającej w zamierzeniu ułatwiać tworzenie wektorowych map, które mogą być później publikowane na licencjach Creative Commons. Jednym z naszych celów jest ułatwienie procesu tworzenia map tematycznych na potrzeby projektu Wikipedia.
Cały projekt zaklasyfikowaliśmy jako WebGIS, co oznacza że chcemy stworzyć coś więcej niż rysowanie map na poziomie Google Mapsów. Dlatego staramy integrować się jak najściślej z geo danymi Natural Earth, danymi z Open Street Map oraz różnymi systemami lokalizacyjnymi. Naszym celem jest też wytworzenie rastrowych teł i warstw.
Stronę projektu znajduje się tutaj [1]
Strona projektu w aspekcie Wikipedii znajduje się tutaj [2]
Jako odprysk projektu powstały dosyć ciekawe skrypty z użyciem GDAL, który jest używany na potrzeby robienia teł (na razie eksperymentalnjie) [3]
Wszelkie uwagi i komentarze ze strony społeczności mile widziane.
[1] http://sharemap.org/
[2] http://commons.wikimedia.org/wiki/User:ShareMap
[3] http://commons.wikimedia.org/wiki/User:ShareMap/Hillsh...
Przykład mapy:
-
Witam, dzięki za uwagi, cały czas pracujemy nad ulepszeniem poradnika
Poradnik był pisany na podstawie, kilku wypraw na tereny Saharyjskie (Egipt, Tunezja, Maroko), pustyń bliskowschodnich i pustyni Gobi. Inne pustynie mogą mieć trochę inną specyfikę i tutaj liczymy na czytelników, że nam pomogą.
Co do rozszerzania haseł to:
1. Część haseł można rozszerzyć - jak naprzykład te o filtrach, tak jak było wspomniane tylko najdroższe filtry działający na zasadzie odwróconej osmozy są w 100% bezpieczne, ale większość ludzi będzie raczej bazowało na tańszych lekkich filtrach i tabletkach odkażających. Konkretny sprzęt chcemy opisywać mając go ręce, a nie przepisując informacje z internetu. Być może dostaniemy egzemplarz do testów od dystrybutora. Oprócz filtrowania bardzo interesująca jest funkcja odsalania, bo zasolone studnie przynajmniej na Saharze są dużym problemem.
2. Co do zwierząt - to wejście w szczegóły gatunków i sposobów radzenie sobie z ich ukąszeniami byłoby bardzo ciężkie wobec zupełnie różnej fauny na różnych pustyniach. Zresztą i tak w większości przypadków
Co do oczywistości haseł, to dla większości osób, które były na pustyniach będą one pewnie w miare oczywiste, które powtarzają się w większości podręczników. Tyle, że poradnik kierowany jest też do osób, które jeszcze takich doświadczeń nie mają. -
Jako współautor zapraszam do lektury i dyskusji
Poradnik przetrwania na pustyni
Jakub Kaniewski edytował(a) ten post dnia 06.06.11 o godzinie 16:34 -
Polecam uzupełniony poradnik przetrwania na pustyni mojego autorstwa
http://www.jakprzetrwac.pl/Poradnik_przetrwania_na_pus...- 30.05.2011, 15:35
-
Nie wiem jakiego rodzaju komunikaty miałeś ale jest to dosyć dziwne. Robiliśmy u nas firmie swingowego klienta. Był testowany pod Linuxem (w trakcie tworzenia) i pod Windows XP (wdrożenie) - działał i wyglądał ok. Jakiś czas później z ciekawości odpaliliśmy go na Mac OS X 10.4 z Applową javą 1.5 i aż byliśmy zaskoczeni efektem - zero problemów, dobry wygląd (dzięki skórce Apple bardzo zbliżony do natywnych aplikacji Macowych, menu na górze itp.)
-
Strasznie mylicie pojęcia, jeżeli używa się rozwiązań J2EE to zarówno w przypadku cienkich klientów (web) jak i grubych JMS jest dobrym rozwiązaniem. Problem moderacji rozwiązuje się po prostu tworząc topici "zmoderowane", "czekające na moderację" i odpowiednią logikę przerzucania wiadomości między nimi.
Co do użycia Swinga, to po prostu w większych i bardziej skomplikowanych projektach aplikacja webowa ma następujące wady :
-Niższa prędkość działania (rysowanie w przeglądarce)
-Większy zajmowany bandwidth
-Konieczność kodowania przez AJAX'a czynności asynchronicznych
-Trudniejsze kodowanie niektórych bajerów interfejsów użytkownika (drag and drop, skalowane panele, zakładki)
Zamiast Swinga można stosować Flexa który przez BlazeDS bardzo łatwo integruje się z logiką serwera aplikacyjnego. -
Na parleyu jak zwykle materiały na najwyższym poziomie :D Ze swojego doświadczenia powiem że połączenie EJB 3 - BlazeDS - Flex to wyjątkowo wdzięczy i bezproblemowy układ.
-
Witam, sprawa jest bardzo prosta. BlazeDS jest sposobem wystawiania interfejsów Javowych do Flexa przy użyciu protokołu AMF (bądź innego). Ze strony serwera masz normalną aplikację webową w postaciu pliku WAR. Taki plik możesz bez trudu zdeployować na każdym serwerze aplikacyjnym. Jedyne czego ci jeszcze potrzeba to mostek EJB-BlazeDS - http://www.adobe.com/cfusion/exchange/index.cfm?event=...
Dokładny opis łączenia znajdziesz tu - http://biemond.blogspot.com/2008/07/using-ejb-in-flex-... -
Jeżeli aplikacja ma być desktopowa (nie przez WWW) i wieloplatformowa to w grę wchodzą dwa rozwiązania
1) Java z interfejsem Swing
zalety : sprawdzona technologia, dużo dodatkowych bibliotek, bozpośrednia komunikacji z serwerami aplikacyjnymi
wady : problematyczna obsługa multimediów, trudność w robieniu skórek/fajerwerków graficznych
2) Adobe AIR
zalety : środowisko wywodzące sie z Flasha/Flexa, łatwa modyfikacja wyglądu, dobra obsługa multimediów, integracja z systemem operacyjnym (pulpit, widgety, drag and drop)
wady : krócej na rynku niż Swing, konieczność korzystania z warstw pośrednich do łączenia z serwerem aplikacyjnym (np. BlazeDS)
Jeżeli chodzi o platformy do oba rozwiązania są na Windows/Linux/Mac OS X. Java jest jeszcze na kilka innych egzotycznych systemów (np. Solaris), ale jest to raczej pomijalne. Oba rozwiąza umożliwiają automatyczną instalację i aktualizację programów przez internet. Dla rozwiązań multimedialnych AIR jest dobrym wyborem. -
Nie mają szans w czym?
Sądzisz, że przeciętny użytkownik skompiluje program lepiej niż profesjonalny deweloper danej dystrybucji? Tym bardziej, że aby faktycznie zyskać coś na wydajności trzeba by analizować flagi każdego pakietu a nie korzystać z make.conf i lecieć po wszystkim emerge.
Z tym "przecietnym uzytkownikiem" to jest tak, ze on jednak zawsze bedzie preferowal prostote ponad wydajnosc - wiec tutaj sie w pelni zgodze. Jednak Linuxy na typowo domowych komputerach to jest nisza. Spojrzmy teraz na cos innego - jest biblioteka 30 komputerow (takich samych) i administrator. Komputery nie sa archaiczne, ale tez nie sa demonami predkosci. Administrator ma czas na dokladna konfiguracje systemu (wszakze robi to raz). Na takim komputerze ma dzialac kilka aplikacji MPlayer, OpenOffice, Firefox. Gwarantuje ze instalujac cokolwiek ze zrodel albo Gentoo uzyska stabilniejszy, mniejszy i szybszy system, pozbawiony niepotrzebnego mu balastu - rzeczy mu niepotrzebnych dziwnych charsetow wkompilowanych w glibc itp. A to byl tylko administrator prostych konfiguracji desktopowych - pomyslmy teraz o administratorze serwerow produkcyjnych.
nawet obecnie zalecana i supportowana jest instalacja ze Stage3.
Prawda - to byl uklon w strone uzytkownika desktopowego (podobnie jak graficzny instalator), ktoremu nie chce sie czekac. Kompilacja od Stage 1 zajmuje nieco czasu i mimo ze nie jest supportowana caly czas dziala tak samo dobrze. A po instalacji Stage3 i tak mozna wszystko przekompilowac.
Kiedys uzywalem FC2, ale od kiedy zaznajomilem sie z Gentoo nie mam ochoty do niej wracac. Przy systemach budowanych z RPM zawsze i tak konczylo sie na tym, ze brakowalo mi akurat najnowszej wersji jakiegos softu i i tak musialem kompilowac ja ze zrodel. Wiadomo co sie dzieje jak takich swobodnych make'ow zrobi sie za duzo (bez odpowiedniej dyscypliny) - system zaczyna sie rozjezdzac. Oczywiscie w Gentoo tez zdarza sie ze brakuje najnowszych wersji w emergu, no ale tam zawsze bardzo prosto mozna dopisac swojego ebuilda.
Jakub Kaniewski edytował(a) ten post dnia 21.12.06 o godzinie 14:18 -
Za korzystam z KDE i zgodzę się ze stwierdzeniem że kopiowania CTRL-C/V działa, ale nie zawsze czasami przy kopiowaniu między aplikacjami QT i GTK są zgrzyty i np. aplikacje GTK widzą jeszcze poprzednią zawartość ... no ale to są raczej marginalne problemy
A co do głównego pytania to moim zdaniem Linuxy przekompilowanych pakietów (RPM) nie mają szans z tymi gdzie każda rzecz jest kompilowana ze źródeł na bieżąco (np. Gentoo).
Jakub Kaniewski edytował(a) ten post dnia 20.12.06 o godzinie 22:44