ESRI ogłosiło, że wypuszczają ArcGIS REST API jako otwartą technologię . Mam ISP z systemem Sql Server 2008 z IIS7.
Czy ktoś wie o dobrym przejściu pokazującym, jak mogę napisać C # za pomocą WCF, aby odsłonić tabele przestrzenne zgodne z określoną specyfikacją (najlepiej ESRI)?
Czy ktoś wie, gdzie jest specyfikacja ESRI?
Odpowiedzi:
Wygląda na to, że ESRI właśnie wydało specyfikację REST GeoServices . Wierzę, że tego możesz szukać.
Właśnie użyłem linku, który Jason opublikował powyżej. Nie mogę sobie wyobrazić, kiedy zostanie wydana, oficjalna specyfikacja będzie znacznie inna. Było to głównie zwijanie rękawów, odpalanie Fiddlera, uderzanie w przykładowe serwery 10.0 i rozpoczęcie hakowania przy implementacji. Nie ma nic niemożliwego, po prostu nudne z mnóstwem drobnych problemów, które należy wziąć pod uwagę. Nie zrobimy nawet naszej 100% kompatybilnej, ale obejmuje 85%, a wszystkie api klienta wydają się działać całkiem dobrze (to był jedyny powód, dla którego to zrobiłem)
oto katalog demonstracyjny (jest tam wiele małych błędów :) [bFlood - usunięto stary link]
uruchamiamy go na AppEngine (python) i jest dość ściśle powiązany z podstawowymi strukturami przestrzennymi, ale prawdopodobnie można go przekształcić w porządny projekt WCF .Net. Nie jestem jednak pewien, jak byśmy to rozpowszechnili
na zdrowie Brian
Aktualizacja - 3/8/12 - Właśnie zobaczyłem ten post wyskakujący w stosie wymiany, więc pomyślałem, że zaktualizuję zawartość. Możesz uruchomić FeatureService w kilka minut, jeśli wypróbujesz wersję beta Arc2Earth Sync. backend działa z Google Fusion Tables i CartoDB, ale wkrótce będziemy wspierać innych dostawców. Nie potrzebujesz niczego oprócz ArcView 9.2 lub nowszego ...
oto post na blogu pokazujący, jak rozpocząć zbieranie danych terenowych w kilka minut za pomocą aplikacji mobilnych ArcGIS.com: http://www.arc2earth.com/2012/03/arc2earth-sync-live-mobile-data-collection-in-5 -minuty/
Jedyną znaną mi dokumentacją interfejsu API REST esri jest ich pomoc online tutaj:
http://help.arcgis.com/EN/arcgisserver/10.0/apis/rest/index.html
Jest to napisane bardziej z perspektywy konsumenta niż dostawcy, ale powinno być możliwe do zhakowania.
Istnieją części tego API, które są dość zastrzeżone (niektóre formaty wyjściowe ) i niemożliwe do wdrożenia przez projekt open source, chyba że te specyfikacje formatów również zostaną udostępnione.
Ponadto niektóre interfejsy API REST nie są szczególnie RESTful. Na przykład spójrz na usługę Feature. Wydaje się, że istnieją oddzielne „punkty końcowe” dla dodawania / aktualizacji / usuwania / zapytania zamiast używania standardowych czasowników HTTP do obsługi zasobów. To mnie zastanawia; Wiem, że esri ma tam dość inteligentnych ludzi, którzy rozumieją REST. Domyślam się, że te połączenia są mapowane do pewnego rodzaju interfejsu SOAP i esri uznał, że byłoby łatwiej dla nich i ich klientów, gdyby zachowali spójność między nimi.
Moja opinia? Jeśli patrzysz tylko na udostępnianie danych (nie na konfigurację mapy, metadane itp.) I nie spieszysz się, możesz lepiej poczekać, aż Microsoft zorientuje się, w jaki sposób będą reprezentować typy danych przestrzennych w EDM. Dzięki temu możesz łatwo stworzyć prawdziwie RESTfulalny dostęp do swoich tabel przestrzennych przy użyciu OData i prawdopodobnie OData z obsługą RIA. To jednak może być piekielne niebo, o ile wiem.
Czy chcesz udostępnić tabele przestrzenne z SQL Server 2008 Spatial? ESRI MapIt już to robi i wierzę, że licencjonowanie umożliwia osobom z AGS dostęp do ESRI MapIt.
Niektóre ekrany tego, jak to wygląda, można znaleźć na moim blogu: http://geo.geek.nz/development/hiding-databases-from-unauthorised-users-when-using-esri-mapit/
Nie musisz sam coś pisać? ;)
Twoje zdrowie
Zrobiłem to już w aplikacji. Nie wdrożyłem w pełni pełnego interfejsu API REST, ale wystarczy, aby zadanie zapytania uruchomiło się i poprawnie sformatowało JSON. Użyłem ASP .NET MVC do zbudowania mojego punktu końcowego. Próbowałem to zrobić około rok temu z WCF i wyjście JSON nie zostało sformatowane w taki sposób, aby działało. Sztuką MVC jest upewnienie się, że masz wynik JSONP, który pobierze parametr zapytania zwrotnego i wykona prawidłową odpowiedź jsonp. Spróbuję coś opublikować. Tutaj możesz zobaczyć odpowiedź:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents/query?f=json&where=1%3D1&returnGeometry=true&spatialRel=esriSpatialRelIntersects&outFields= * & outSR = 4326 i zwrotna = dojo.io.script.jsonp_dojoIoScript2._jsonpCallback
Jednak używany jest tylko parametr wywołania zwrotnego:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncident?callback=woot
Edycja: Oto jak zaimplementować wynik JSONP w ASP .NET MVC
/programming/758879/asp-net-mvc-returning-jsonp
Edycja # 2: Oto przykład kodu, który szybko stworzyłem i umieściłem w Dropbox.
http://dl.dropbox.com/u/28924446/EsriGeoServicesExampleMvc3.zip
Wygląda na to, że możesz po prostu zastąpić funkcjonalność ArcGIS. Poleciłbym wykorzystać istniejący projekt open source do wdrożenia takiego systemu, jeśli stanie się dostępny, który obsługuje ten interfejs API, być może napiszę własny adapter do projektu open source. Być może istnieje, ale jeszcze nie wyglądałem zbyt ciężko. Nie jestem pewien, czy wydali już pełną specyfikację API, ale jeśli się spieszysz, możesz po prostu skorzystać z istniejącej dokumentacji API i przetestować swoją implementację pod kątem istniejącego oprogramowania ESRI.
tutaj jest przykład: http://www.arcgis.com/home/item.html?id=6d28a606369c43fd9a6f929541ae7c93
@JasonBirch - myślę, że główną zaletą nawet zrobienia tego jest możliwość integracji z esri apps / apis / arcgis.com. Jeśli esri włączy wtyczkę tanio (za darmo), stanie się to o wiele mniej ważne. Nie jest dla mnie jasne, co zamierzają zrobić z ArcGIS.com, a nawet w jaki sposób jest obecnie licencjonowany. Widziałem to jako centralną lokalizację dla danych / usług, w której można rejestrować aplikacje internetowe, coś w rodzaju sklepu z danymi esri. Firmy zewnętrzne rejestrują aplikacje internetowe dla wielu dzierżawców (chmury), esri robi cięcia, a twoja aplikacja jest natychmiast dostępna dla wszystkich chętnych zgodnych ze specyfikacją reszty interfejsu API. w tym świetle sensowne jest otwarcie interfejsu API reszty i umożliwienie integracji jak największej liczby usług z koncentratorem. wyszukiwanie / przechowywanie danych geoprzestrzennych szybko zbliża się do utowarowienia, więc przenieś je o jeden krok wyżej i spróbuj kontrolować przestrzeń aplikacji.
Myślę, że twój komentarz OData ma sens, ale IMO, to jest daleka sprawa. a co ważniejsze, bez szeroko rozpowszechnionej i kochanej aplikacji klienckiej (coś w Google Earth) każda dobrze napisana specyfikacja może potencjalnie uschnąć na winorośli. Nie twierdząc, że tak jest w przypadku OData, jest wielu deweloperów stwardnienia rozsianego, którzy dostaną to za darmo w VS, ale nie widzę tego w krótkim okresie. moje 2 centy ...
(przy okazji wydaje się, że komentarz jest dość krótki, stąd nowa odpowiedź zamiast tego)