ESRI anunció que lanzarán la API REST de ArcGIS como tecnología abierta . Tengo un ISP que ejecuta Sql Server 2008 con IIS7.
¿Alguien sabe de un buen recorrido que muestre cómo puedo escribir C # usando WCF para exponer tablas espaciales que cumplan con una especificación particular (idealmente ESRI)?
¿Alguien sabe dónde está la especificación de ESRI?
Respuestas:
Parece que ESRI acaba de lanzar su especificación REST GeoServices . Creo que esto es lo que puede estar buscando.
Acabo de usar el enlace que Jason publicó arriba. No puedo imaginar cuándo se lanzará, la especificación oficial será muy diferente. En su mayoría era una camisa de manga corta, enciende Fiddler, golpea los servidores de muestra 10.0 y comienza a piratear la implementación. No hay nada imposible, solo tedioso con muchos pequeños problemas a tener en cuenta. Ni siquiera haremos que el nuestro sea 100% compatible, pero cubre el 85% y todas las API del cliente parecen funcionar bastante bien (esa fue la única razón por la que lo hice para empezar)
aquí hay un catálogo de demostración (muchos pequeños errores allí :) [bFlood - enlace antiguo eliminado]
lo estamos ejecutando en AppEngine (python) y está bastante unido a las estructuras espaciales subyacentes, pero probablemente podría convertirse en un proyecto decente .Net WCF. Aunque no estoy seguro de cómo lo distribuiríamos
saludos Brian
Actualización - 8/03/12 - Acabo de ver esta publicación emergente en stackexchange, así que pensé que actualizaría el contenido. Puede ejecutar su FeatureService en minutos si prueba la versión beta de Arc2Earth Sync. el backend funciona con Google Fusion Tables y CartoDB, pero pronto brindaremos soporte a otros proveedores. No necesita nada excepto ArcView 9.2 o superior ...
Aquí hay una publicación de blog que muestra cómo comenzar a recopilar datos de campo en minutos usando las aplicaciones móviles de ArcGIS.com: http://www.arc2earth.com/2012/03/arc2earth-sync-live-mobile-data-collection-in-5 -minutos/
La única documentación que conozco para la API REST de esri está en su ayuda en línea aquí:
http://help.arcgis.com/EN/arcgisserver/10.0/apis/rest/index.html
Esto está escrito más desde la perspectiva de un consumidor que un proveedor, pero debería ser pirateable.
Hay partes de esta API que son bastante propietarias (algunos de los formatos de salida ) e imposibles de implementar por un proyecto de código abierto a menos que estas especificaciones de formato también estén disponibles.
Además, algunas de las API REST no son especialmente RESTful. Por ejemplo, mire el Servicio de funciones. Parece que hay "puntos finales" separados para agregar / actualizar / eliminar / consultar en lugar de usar verbos HTTP estándar para operar en los recursos. Esto me desconcierta; Sé que esri tiene algunas personas bastante inteligentes que entienden REST. Supongo que estas llamadas se asignan a algún tipo de interfaz SOAP, y esri sintió que sería más fácil para ellos y sus clientes si mantenían la coherencia entre ellos.
¿Mi opinión? Si solo busca compartir datos (no configuración de mapas, metadatos, etc.) y no tiene prisa, es mejor que espere hasta que Microsoft descubra cómo van a representar los tipos de datos espaciales en EDM. Con esto en su lugar, puede crear fácilmente un acceso verdaderamente RESTful a sus tablas espaciales usando OData y probablemente OData habilitado para RIA. Sin embargo, esto puede ser un pastel en el cielo por lo que sé.
¿Está buscando exponer tablas espaciales de SQL Server 2008 Spatial? ESRI MapIt ya lo hace y creo que la licencia permite que las personas con AGS tengan acceso a ESRI MapIt.
Algunas pantallas de cómo se ve esto se pueden encontrar en mi blog: http://geo.geek.nz/development/hiding-databases-from-unauthorised-users-when-using-esri-mapit/
¿No necesitas escribir algo tú mismo? ;)
Aclamaciones
Ya he hecho esto en una aplicación. No implementé completamente la API REST completa, pero sí lo suficiente como para obtener una tarea de consulta para ejecutar y formatear el JSON correctamente. Usé ASP .NET MVC para construir mi punto final. Intenté hacer esto hace aproximadamente un año con WCF y la salida JSON no estaba formateada de tal manera que funcionara. El truco con MVC es asegurarse de que tiene un resultado JSONP que extraerá el parámetro de consulta de devolución de llamada y hará la respuesta jsonp correcta. Intentaré publicar algo. Puedes echar un vistazo a la respuesta aquí:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents/query?f=json&where=1%3D1&returnGeometry=true&spatialRel=esriSpatialRelIntersects&outFields= * & outSR = 4326 & callback = dojo.son.s._2.
Sin embargo, solo se utiliza el parámetro de devolución de llamada:
http://www.ci.austin.tx.us/GIS/TrafficViewer/Home/JsonpIncidents?callback=woot
Editar: Aquí se explica cómo implementar un resultado JSONP en ASP .NET MVC
/programming/758879/asp-net-mvc-returning-jsonp
Editar # 2: Aquí hay un ejemplo de código que hice rápidamente y puse en Dropbox.
http://dl.dropbox.com/u/28924446/EsriGeoServicesExampleMvc3.zip
Parece que puede terminar reemplazando la funcionalidad de ArcGIS haciendo eso. Recomendaría utilizar un proyecto de código abierto existente para implementar dicho sistema si hay uno disponible que admita esa API, quizás escriba su propio adaptador para un proyecto de código abierto. Quizás exista uno, pero aún no he buscado mucho. No estoy seguro de que hayan lanzado una especificación API completa todavía, pero si tiene prisa, podría usar la documentación API existente y probar su implementación contra el software ESRI existente.
Aquí hay un ejemplo: http://www.arcgis.com/home/item.html?id=6d28a606369c43fd9a6f929541ae7c93
@JasonBirch: creo que el principal atractivo para hacerlo es la capacidad de integrarse con esri apps / apis / arcgis.com. Si esri desconecta el uso de estos de forma económica (gratis), se vuelve mucho menos importante. No me queda claro qué planean hacer con ArcGIS.com e incluso cómo tiene licencia en este momento. Lo vi como una ubicación central para datos / servicios donde las aplicaciones web podrían registrarse, algo así como una tienda de aplicaciones para datos de Esri. Los terceros registran aplicaciones web (en la nube) para múltiples inquilinos, esri se corta y su aplicación está disponible instantáneamente para todos los usuarios compatibles con el resto de especificaciones de API. En este sentido, tiene sentido abrir el resto de la API y permitir que se integren tantos servicios como sea posible. La búsqueda / almacenamiento de datos geoespaciales se está convirtiendo rápidamente en un producto básico, así que muévalo hacia arriba y trate de controlar el espacio de la aplicación.
Creo que su comentario de OData tiene mérito, pero en mi opinión, eso está muy lejos. y, lo que es más importante, sin una aplicación cliente ampliamente distribuida y muy querida (algo de Google Earth), cualquier especificación bien escrita tiene el potencial de marchitarse. No digo que ese sea el caso con OData, hay muchos desarrolladores de MS por ahí que lo conectarán de forma gratuita en VS, pero no lo veo a corto plazo. mis 2 centavos ...
(por cierto, parece que hay una longitud de comentario bastante corta, de ahí la nueva respuesta)