fredag den 28. marts 2008
Thoughts on the ESRI Developer Summit and OGC in ArcGIS Server
http://www.lizardtech.com/blog/2008/thoughts-on-the-esri-developer-summit-and-ogc-in-arcgis-server/
The Open Geospatial Consortium (of which both ESRI and LizardTech are members) exists to publish freely available specifications that allow geospatial applications to talk to each other. The three most commonly used OGC specifications are:
- Web Map Service (WMS) for serving custom maps into web pages. Typically these are small JPEG image “tiles” that make up your map.
- Web Feature Service (WFS) for serving features (vector data like roads, borders, pizza shops) from your dataset into another geospatial application that can interact with them at much more controlled level than a read-only map. Think of WFS is as serving GML over HTTP. An OGC extension for this is WFS-T (T for “transactions”) which allows remote editing of data.
- Web Coverage Service (WCS). Like WMS, this provides a means of accessing raster data. However, here the service is optimized for sending to another geospatial application, rather than a simple web service.
At 9.3, there is significant support for all of these.
WMS
ArcGIS Server’s WMS support is extended to the current version 1.3 including support for Styled Layer Descriptor (SLD). SLDs are part of the WMS specification and allow customized symbology for features. The demonstration here included an OpenLayers web page client rendering a map (with user-selected symbology) served from ArcGIS Server via WMS. That was pretty good, but really, only a marginal improvement.
WFS
The previous 9.2 Data Interoperability extension will continue to provide WFS support to the Desktop Clients. However, at 9.3, “Simple Features” support comes out of the box (without the extra license). On the server side, 9.3 includes a WFS server and if your back-end store is SDE then this includes WFS-T support. What that means is that if you use SDE, non-ESRI clients (who speak WFS) can edit your geodatabase. Stop for a minute and think about that.
The demonstration here showed again the Open Layers client. This time it accessed the parcel data stored in ArcGIS Server via WFS. It corrected some of the parcel boundaries and this was reflected in the same GDB accessed via ArcMap. Frankly, I was pretty impressed.
WCS
WCS support is totally new in 9.3. The demonstration of server support showed the Open Layers client rendering a 4-banded Modis image served from ArcGIS Server via WCS. More interesting to me was the client demo where ArcMap read a dataset via WCS from ICDES and did some sort of raster-based geo-processing on it (I can’t remember exactly what it was). Very, very cool.
Whether or not you believe “What’s good for the country is good for General Motors, and vice versa,” ESRI’s support for this sort of interoperability can only be seen as good news for GIS and for ESRI.
torsdag den 27. marts 2008
ArcGIS Server Flex API
http://thunderheadxpler.blogspot.com/2008/03/arcgis-server-flex-api.html
Just got back from ESRI's Developer Summit in Palm Spring, where I presented the ArcGIS Server Flex API. You can download my presentation from here. This API is intended to be released post 9.3 and will be based on the REST protocol and is very closely modeled after the JavaScript API. In the presentation, I showcased how to build a map application and how to create dynamic and tiled layers. In addition, I added graphic layers with adjustable graphics and demonstrated how to subclass a GraphicLayer to create a GeoRSS layer.
Just got back from ESRI's Developer Summit in Palm Spring, where I presented the ArcGIS Server Flex API. You can download my presentation from here. This API is intended to be released post 9.3 and will be based on the REST protocol and is very closely modeled after the JavaScript API. In the presentation, I showcased how to build a map application and how to create dynamic and tiled layers. In addition, I added graphic layers with adjustable graphics and demonstrated how to subclass a GraphicLayer to create a GeoRSS layer.
ArcGIS 9.2 Service Pack 5 Released
http://mandown.co.nz/esri/arcgis-9-2-service-pack-5-released/
ESRI has now released ArcGIS 9.2 Service Pack 5.SP5 includes a number of fixes and enhancements. If you missed the announcement along with the list of fixes, this can be found here: http://mandown.co.nz/esri/...
Download locations can be found here:
US
ArcGIS 9.2 Service Pack 5
ArcGIS Image Server 9.2 Service Pack 5
ArcIMS 9.2 Service Pack 5
ArcSDE 9.2 Service Pack 5
ESRI has now released ArcGIS 9.2 Service Pack 5.SP5 includes a number of fixes and enhancements. If you missed the announcement along with the list of fixes, this can be found here: http://mandown.co.nz/esri/...
Download locations can be found here:
US
ArcGIS 9.2 Service Pack 5
ArcGIS Image Server 9.2 Service Pack 5
ArcIMS 9.2 Service Pack 5
ArcSDE 9.2 Service Pack 5
2008 ESRI Developers Summit Roundup
2008 ESRI Developers Summit Roundup
25. marts 2008 10:09:15 (Mountain Daylight Time, UTC-06:00)
Well, after a rough start getting to the ESRI Dev Summit, the rest of the week was fantastic. I had a great time meeting up with old friends and making lots of new ones too. Thanks to the hard working folks at ESRI, the Dev Summit was a great success again this year. If you're a GIS developer, skip the User Conference in the summer and make sure you head to the Dev Summit next year! Tons of other people have already given their wrap-up for this year's Summit so I'll point you to some of the good one's and just provide you with some pictures from the Summit. Cheers to ESRI and everyone involved in making this a great event! See you all next year!
Summit Wrap Ups:
Dave Bouwman's 2008 ESRI Developer Summit Wrap Up
All Points Blog Dev Summit Podcast
Jithen Singh's Wrapping Up the ESRI Developer Summit 2008
James Fee's Reflection on the 2008 ESRI Developer Summit
Albert Pascual's 2008 ESRI Developer Summit
The (official) ESRI Developer's Summit Blog
Bryan Noyle's Agile Conversations at the Dev Summit
Donny V's 2008 ESRI Developer Summit
Clearly Vague's Day by Day Account of the Dev Summit
25. marts 2008 10:09:15 (Mountain Daylight Time, UTC-06:00)
Well, after a rough start getting to the ESRI Dev Summit, the rest of the week was fantastic. I had a great time meeting up with old friends and making lots of new ones too. Thanks to the hard working folks at ESRI, the Dev Summit was a great success again this year. If you're a GIS developer, skip the User Conference in the summer and make sure you head to the Dev Summit next year! Tons of other people have already given their wrap-up for this year's Summit so I'll point you to some of the good one's and just provide you with some pictures from the Summit. Cheers to ESRI and everyone involved in making this a great event! See you all next year!
Summit Wrap Ups:
Dave Bouwman's 2008 ESRI Developer Summit Wrap Up
All Points Blog Dev Summit Podcast
Jithen Singh's Wrapping Up the ESRI Developer Summit 2008
James Fee's Reflection on the 2008 ESRI Developer Summit
Albert Pascual's 2008 ESRI Developer Summit
The (official) ESRI Developer's Summit Blog
Bryan Noyle's Agile Conversations at the Dev Summit
Donny V's 2008 ESRI Developer Summit
Clearly Vague's Day by Day Account of the Dev Summit
Using Web ADF controls in an ASP.NET Web Part and SharePoint 2007
http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2008/02/27/Using-Web-ADF-controls-in-an-ASP.NET-Web-Part-and-SharePoint-2007.aspx
On to working with SharePoint - Building a portal site which uses Web Parts can be time consuming; integrating the site into other enterprise systems can be difficult and inefficient; and lastly, managing the site can be overly complex and convoluted. In an attempt to manage enterprise content, intelligence and search systems effectively, Microsoft has created Microsoft Office SharePoint Server 2007, or MOSS for short. MOSS is good for what it claims to do (be an all encompassing enterprise system for sharing information), but it is not simple. Like many software products, more capability means greater complexity. One option for customizing the presentation of content and providing access to business logic is developing custom ASP.NET Web Parts and deploying them on a SharePoint server. An ASP.NET Web Part can be deployed relatively easily with SharePoint 2007. The SharePoint SDK includes a WebPart class which derives from the ASP.NET WebPart. The SharePoint WebPart class offers a few benefits, such as cross-page and non-WebPart connections, which primarily facilitate backward compatibility with SharePoint 2003. For more information on Web Part development with SharePoint 2007, Scott Guthrie provides a bevy of valuable information and links in his blog post Writing Custom WebParts for SharePoint 2007. You can use Sahil Malik’s walkthrough at the beginning of the post to get started creating a custom ASP.NET Web Part.
There are a few issues to consider when deploying a Web Part that contains Web ADF controls in
SharePoint 2007:
SharePoint 2007 was designed to function using the full page postback pattern. As a result, tools in a Web ADF Toolbar may need to trigger a full postback within a custom Web Part to communicate with other parts in the page. Unfortunately the postback event never gets to the tool, so some additional code is required to raise the post back event to the correct control (e.g. Map). See the sample code for more details.
The SharePoint 2007 server may not have session state enabled, which is necessary for the Web ADF controls to function. If not enabled, SharePoint will return a fairly ambiguous error when attempting to add your custom Web Part to the SharePoint server.
The 9.3 Web ADF will resolve many of the limitations and issues encountered when working with 9.2 Web ADF controls in a Web Part. 9.3 Web ADF controls will be fully supported for use in custom user and composite controls, both of which may be deployed as a Web Part. Multiple Web Parts containing multiple Web ADF controls can function within the same application. The use of ESRIWebADFHiddenFields will be reduced if not removed. And full postbacks initiated by toolbar items will be supported internally.
On to working with SharePoint - Building a portal site which uses Web Parts can be time consuming; integrating the site into other enterprise systems can be difficult and inefficient; and lastly, managing the site can be overly complex and convoluted. In an attempt to manage enterprise content, intelligence and search systems effectively, Microsoft has created Microsoft Office SharePoint Server 2007, or MOSS for short. MOSS is good for what it claims to do (be an all encompassing enterprise system for sharing information), but it is not simple. Like many software products, more capability means greater complexity. One option for customizing the presentation of content and providing access to business logic is developing custom ASP.NET Web Parts and deploying them on a SharePoint server. An ASP.NET Web Part can be deployed relatively easily with SharePoint 2007. The SharePoint SDK includes a WebPart class which derives from the ASP.NET WebPart. The SharePoint WebPart class offers a few benefits, such as cross-page and non-WebPart connections, which primarily facilitate backward compatibility with SharePoint 2003. For more information on Web Part development with SharePoint 2007, Scott Guthrie provides a bevy of valuable information and links in his blog post Writing Custom WebParts for SharePoint 2007. You can use Sahil Malik’s walkthrough at the beginning of the post to get started creating a custom ASP.NET Web Part.
There are a few issues to consider when deploying a Web Part that contains Web ADF controls in
SharePoint 2007:
SharePoint 2007 was designed to function using the full page postback pattern. As a result, tools in a Web ADF Toolbar may need to trigger a full postback within a custom Web Part to communicate with other parts in the page. Unfortunately the postback event never gets to the tool, so some additional code is required to raise the post back event to the correct control (e.g. Map). See the sample code for more details.
The SharePoint 2007 server may not have session state enabled, which is necessary for the Web ADF controls to function. If not enabled, SharePoint will return a fairly ambiguous error when attempting to add your custom Web Part to the SharePoint server.
The 9.3 Web ADF will resolve many of the limitations and issues encountered when working with 9.2 Web ADF controls in a Web Part. 9.3 Web ADF controls will be fully supported for use in custom user and composite controls, both of which may be deployed as a Web Part. Multiple Web Parts containing multiple Web ADF controls can function within the same application. The use of ESRIWebADFHiddenFields will be reduced if not removed. And full postbacks initiated by toolbar items will be supported internally.
The proper way to initialize a resource in the .NET ADF
http://viswaug.wordpress.com/2008/03/24/the-proper-way-to-initialize-a-resource-in-the-net-adf/
If you have ever tried to use the MapResourceManager on a page without a Map Control or use the functionalities directly through the ResourceItems on the MapResourceManager, you must have found that the functionalities do not work as expected. The reason the functionalities do not work as expected is because the resources underlying the resource items should be initialized before use. Reading over the ESRI’s .NET ADF library, there are 2 methods that suggest that they will accomplish the task of initializing the resource, the Initialize method on the IGISResource interface and the InitializeResource method on the GISResourceItem.
But the Initialize method on the IGISResource interface does not do the job right. In order to initialize the resource right use the InitializeResource method on the GISResourceItem. This is not documented anywhere as far as I know. So, if the Query method on the IQueryFunctionality interface returns null for no reason when you expect results, trying initializing the resource using the InitializeResource method on the GISResourceItem.
Update: Heard from some ESRI folks on this issue. IGISResource.Initialize() initializes the resource only. IGISResourceItem.InitializeResource() initializes both the resource and the datasource of the resource. Always to use InitiializeResource(), since there are more logic here for handling initialization errors, validation stuff etc, whereas, with Initialize() it’s dependent on the individual resource’s implementation.
If you have ever tried to use the MapResourceManager on a page without a Map Control or use the functionalities directly through the ResourceItems on the MapResourceManager, you must have found that the functionalities do not work as expected. The reason the functionalities do not work as expected is because the resources underlying the resource items should be initialized before use. Reading over the ESRI’s .NET ADF library, there are 2 methods that suggest that they will accomplish the task of initializing the resource, the Initialize method on the IGISResource interface and the InitializeResource method on the GISResourceItem.
But the Initialize method on the IGISResource interface does not do the job right. In order to initialize the resource right use the InitializeResource method on the GISResourceItem. This is not documented anywhere as far as I know. So, if the Query method on the IQueryFunctionality interface returns null for no reason when you expect results, trying initializing the resource using the InitializeResource method on the GISResourceItem.
Update: Heard from some ESRI folks on this issue. IGISResource.Initialize() initializes the resource only. IGISResourceItem.InitializeResource() initializes both the resource and the datasource of the resource. Always to use InitiializeResource(), since there are more logic here for handling initialization errors, validation stuff etc, whereas, with Initialize() it’s dependent on the individual resource’s implementation.
onsdag den 26. marts 2008
The Closing Q&A
http://www.spatiallyadjusted.com/2008/03/21/the-closing-qa/#comment-33757
Dave Bouwman asked them to stop overselling ArcGIS Server. His comment was well received by everyone out there and those on stage all agreed they need to do a better job giving a realistic picture of what it can do and how quickly you can deploy applications.
There was some worry about the future of ArcIMS. Of course the Web ADF works with IMS, but the picture is pretty clear that you need to start seriously working at migrating to ArcGIS Server. There were quite a bit of ArcIMS folks looking at the RESTful API and the JavaScript API. There is a natural progression from AXL to JSON I believe and being able to see the JSON will better help them understand how it all works. The point is though that you probably need to move on as no new features will be incorporated into ArcIMS.
It was the last chance to enjoy an ESRI Squishee
Dave Bouwman asked them to stop overselling ArcGIS Server. His comment was well received by everyone out there and those on stage all agreed they need to do a better job giving a realistic picture of what it can do and how quickly you can deploy applications.
There was some worry about the future of ArcIMS. Of course the Web ADF works with IMS, but the picture is pretty clear that you need to start seriously working at migrating to ArcGIS Server. There were quite a bit of ArcIMS folks looking at the RESTful API and the JavaScript API. There is a natural progression from AXL to JSON I believe and being able to see the JSON will better help them understand how it all works. The point is though that you probably need to move on as no new features will be incorporated into ArcIMS.
It was the last chance to enjoy an ESRI Squishee
Should you have multiple maps (or dataframes) in your MapServer MXD for ArcGIS Server
http://viswaug.wordpress.com/2008/03/22/should-you-have-multiple-maps-or-dataframes-in-your-mapserver-mxd-for-arcgis-server/
At the ESRI Dev Summit 2008, I managed to get some insights into questions that have been bouncing around in my head from the ESRI folks building ArcGIS server. One such design question was whether it was reasonable to create MXDs with multiple maps in them that can be accessed as different map resources or just create different map services for multiple maps. By creating a map service with multiple data frames in them you can serve both maps with just a single instance of a SOC. When creating different map services for different maps you end up with different SOCs for each map service.
One scenario where you might ask yourself this question is when deciding whether the overview map should be in a data frame on the same map service or have a different map service for the overview map. Obviously, the overview map only has some of the layers from the map itself.
The REST API in ArcGIS Server 9.3 will only support the current data frame in the MXD.
Now to the answers, it is not a bad idea to have multiple data frames in a single MXD and consume them as separate resources as long as the multiple data frames (or maps) in the MXD do not get used simultaneously all the time. When used simultaneously, a single SOC process is going to process the requests for both the maps and thus the concurrent requests are going to slow down the service. If the maps are going to be used concurrently, then it is better to create different map services for each of the maps, this way different process can process the requests and can return faster. That being said, for most cases it is better to create separate map services for each map.
At the ESRI Dev Summit 2008, I managed to get some insights into questions that have been bouncing around in my head from the ESRI folks building ArcGIS server. One such design question was whether it was reasonable to create MXDs with multiple maps in them that can be accessed as different map resources or just create different map services for multiple maps. By creating a map service with multiple data frames in them you can serve both maps with just a single instance of a SOC. When creating different map services for different maps you end up with different SOCs for each map service.
One scenario where you might ask yourself this question is when deciding whether the overview map should be in a data frame on the same map service or have a different map service for the overview map. Obviously, the overview map only has some of the layers from the map itself.
The REST API in ArcGIS Server 9.3 will only support the current data frame in the MXD.
Now to the answers, it is not a bad idea to have multiple data frames in a single MXD and consume them as separate resources as long as the multiple data frames (or maps) in the MXD do not get used simultaneously all the time. When used simultaneously, a single SOC process is going to process the requests for both the maps and thus the concurrent requests are going to slow down the service. If the maps are going to be used concurrently, then it is better to create different map services for each of the maps, this way different process can process the requests and can return faster. That being said, for most cases it is better to create separate map services for each map.
Reflection on the 2008 ESRI Developer Summit
http://infire.uni.cc/reflection-on-the-2008-esri-developer-summit.html
The one thing that scares me and Dave Bouwman did bring it up at the closing session is overselling what you can do with the new REST API and JavaScript API. Have sales staff running around that you can create "rich" JavaScript applications "consuming" ArcGIS Server services using only 12 lines of code is going to put many of us in a bind. JavaScript is easy to pick up, but that doesn’t mean you’ll be adding complex geoprocessing to your Google Maps mashup with one line. The speed that you can develop has increased, but the complexity will still be there. The JavaScript API will increase your productivity, no doubt. But telling everyone all you need is 12 lines of code will result in disappointment.
What now?
Well I’ve got both ArcGIS Server and ArcGIS Desktop installed on my laptop and they seem very stable. Moving forward I think we’ll jump with both feet into the RESTful API and the JavaScript APIs. I think users will want to get their services published via the REST API as soon as possible so Google can start indexing them. What a great way for organizations who want to share their data with the community, just publish and let Google index your services.
The ArcGIS Services Explorer is going to be a great tool to learn what is available out there. I had quite a few ArcIMS developers say that they can finally feel comfortable working with ArcGIS Server. The .NET and Java Web ADFs were too much for them and they were usually used to working with simple HTML pages. Compare the speed of JSON vs the speed of sending XML (AXL) requests to the server and see how fast you get a response. It really does highlight why the community at large has really moved to JSON.
The one thing that scares me and Dave Bouwman did bring it up at the closing session is overselling what you can do with the new REST API and JavaScript API. Have sales staff running around that you can create "rich" JavaScript applications "consuming" ArcGIS Server services using only 12 lines of code is going to put many of us in a bind. JavaScript is easy to pick up, but that doesn’t mean you’ll be adding complex geoprocessing to your Google Maps mashup with one line. The speed that you can develop has increased, but the complexity will still be there. The JavaScript API will increase your productivity, no doubt. But telling everyone all you need is 12 lines of code will result in disappointment.
What now?
Well I’ve got both ArcGIS Server and ArcGIS Desktop installed on my laptop and they seem very stable. Moving forward I think we’ll jump with both feet into the RESTful API and the JavaScript APIs. I think users will want to get their services published via the REST API as soon as possible so Google can start indexing them. What a great way for organizations who want to share their data with the community, just publish and let Google index your services.
The ArcGIS Services Explorer is going to be a great tool to learn what is available out there. I had quite a few ArcIMS developers say that they can finally feel comfortable working with ArcGIS Server. The .NET and Java Web ADFs were too much for them and they were usually used to working with simple HTML pages. Compare the speed of JSON vs the speed of sending XML (AXL) requests to the server and see how fast you get a response. It really does highlight why the community at large has really moved to JSON.
Abonner på:
Opslag (Atom)