tag:blogger.com,1999:blog-90009041131278053482008-03-22T16:41:24.869-07:00misc-gisJames Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-9000904113127805348.post-242952885902018532008-03-21T11:25:00.000-07:002008-03-22T16:41:20.250-07:00Stuck with a view of the PacificNot yet home- I've been bumped twice (Easter, snow in O'Hare), so I'm spending the afternoon in SF- the tragedy of it all :) .<br /><br />Anyway, my final dev summit opinions<br /><br />One big benefit of the Dev Summit is that the session have all been recorded with screenshots; by all means, listen to <i>any</i> session you have the slightest interest in- it will be worth your while.<br /><br /><h3>Building a 3-D City</h3><br />9.3 is supporting 3-D in a big way. An "Import 3-D Model" tool was shown, with both Sketchup & COLLADA types, among others listed. The geometries supported by multi-patch (rings and triangle networks) were described, and enough relevant examples were presented to show when you'd want a ring (flat surface) or one of the two triangle sets (accommodate a continuous surface in 3-D). There's programmatic access to multi-patch, so a quick color/texture scheme can be easily applied. <br />Aside from that, ESRI is focusing on storing and managing 3-D models- not necessarily bulk creation- that's partner-space (though tools for individual buildings will be deployed, though it may be more sensible to use Sketchup or another 3-D design tool).<br />The Question & Answer was interesting. Among other things, it confirmed the role of ESRI's business partners in bulk (programmatic) 3-D creation, as well as some idea of what they're thinking about for 9.4- perhaps an architectural style symbol library and other ease of using existing 3-D data. ArcScene & ArcGlobe will continue in the foreseeable future. <br /><br />Some tips that should have been obvious from the star (i.e., obvious to me but not):<br /><ul><li><b>Use Scale dependencies!</b> The presenters recommended at most 5-6 different layers for use in a 3-D environment, with more complex models (kml, sketchup, multi-patch) being limited to the closest features. Use extrusion for slightly farther away, and footprints for even farther.</li><br /><li><b>Use multiple footprints for a building to extrude properly.</b> Most skyscrapers (or even mid-rise blocks) have differing elevations. Instead of making one solid building footprint, create a series of rings that complete the footprint and specify elevation information for each ring (separate the footprint component ID from the building ID).</li><br /></ul><br /><br /><h3>Designing Map Caches</h3><br />This was a session that I had planned to listen to after the conference, but decided to sit in. Aside from the ArcGIS Server guys, they also had a representative from ArcWeb Services (i.e., the guys who have done the most caches to date).<br />A lot of good take-away tips on building caches, including what image type to use (JPG for backgrounds, PNG8 for vector overlays) and what datasources to use (use a local GDB for tile creation; we can always repoint the data to an SDE afterwards). <br />The 9.3 interface for cache creation & maintenance looks pretty good; it'll be a lot more flexible (we're not hit too badly by it- our base background is generated in 8-20 hours, depending on image format). <br />This session also drove home to me the ESRI philosophy on map services: cache <b>EVERYTHING</b> that doesn't need to be more current than the time in which you can recache it (up to the hour or day can be cached, depending on your hardware). I'll bet this is going to result in a number of setups where a second(ary) server will be brought online to do constant caching, with maybe some excess capacity for hosting additional web serving SOC clients.<br /><br /><h3>Effective Geodatabase Programming</h3><br />Another session where the slide deck will become a great reference. I don't do too much programming against our database; however, the information at the session was pitched just low enough that I understood the concepts & reasons for their recommendations. I'll at least be able to be conversant with people I work with who do this stuff to convey the issues raised. One of the nice things about the Dev Summit is there was ample time in the schedule to take a session or two in topics that weren't my area of expertise- I honestly like cross-training in other areas.<br /><br /><h3>Closing session</h3><br />Basically, a good forum for feedback. A lot of hand-voting for what worked and what didn't (the intro sessions seemed to have helped, sit-down vs. boxed lunches was a draw). Some future directions were talked about; at this point, ESRI has nearly backed themselves into a corner to release a functional SDK for the File Geodatabase. Anything less then full access to it (without a ESRI DLL to be deployed in addition) was met with tepid response. Two other takeaways from the Q & A:<br /><ul><li>VB6 is moribund (if not dead), get over it</li><br /><li>IMS is moribund (if not dead), get over it</li></ul>James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-63514702181959461412008-03-19T20:41:00.000-07:002008-03-19T22:00:15.687-07:00Dev Summit Wednesday Sessions<h3>Architecting ArcGIS Server Solutions for Performance and Scalability</h3><br />A series of tidbits, a few of which were useful (depended on your experience with serving map services). I wish they would have spent more time on computer/network architecture for hosting web services & apps- for me, the computers are the relatively scarce resource (especially when licensing per computer comes in), so we need to be able to figure out the best use of our computers.<br /><br /><h3><a href="http://www.adobe.com/products/flex/">Flex</a> API Preview</h3><br />Due to demand, this got moved over to a conference room, as opposed to a demo theater. I stayed a little while, but got enough of a gist: it looks to be pretty much a Flex wrapper for the REST API (I'm willing to be corrected if they showed stuff beyond the standard REST capabilities; I was in the session for all of 10 minutes because it was during a <i>sit-down</i> lunch.<br /><br />This session re-enforced the big takeaway from the conference- <b>Clients are whatever platform you want them to be with ArcGIS Server 9.3.</b> By now, I'm sure there's some interface for ALGOL that can take advantage of the REST API (there better be, since it's http-based). The challenge for a development shop is to identify the 2-4 platforms (depending on the size of the shop) that they'll use to develop and actively keep the others out-of-bounds; otherwise, you can't adequately develop depth of programming to do good apps.<br /><br /><h3>Building .NET Applications Using the ArcGIS Server Web ADF and ASP.NET AJAX</h3><br />I was really excited to go to this session (I haven;t been to previous incarnations). Picking up from <a href="http://feeds.feedburner.com/~r/DaveBouwman/~3/254320368/ArcGISServerNETADFPart1.aspx">Dave Bouwman's comments</a>, it really felt like REST let the air out of the room on this. The .NET Web ADF still allows pretty good access out of the box to heftier web services, but it's just about obvious that a lot of the energy is going to be over in the Javascript side of the camp. Still, the improvements in 9.3, which uses the Microsoft AJAX framework are pretty significant and much appreciated.<br /><br /><h3>Building and Extending Tasks for ArcGIS Server .NET Web Applications</h3><br />This session left me feeling more positive about the .Net Platform. I haven't developed any tasks yet, so the walkthroughs provided were extremely helpful. It also showed how the .Net ADF can continue- it provides a nice near-WYSIWIG interface for organizations with no programmers to continue to create & support (with outside code help) web mapping applications. Also, at 9.3, creating a task on a one-off basis becomes a lot easier by creating a web control & loading it as a tool, which will lesson the onus of developing a tool & Visual Studio configuration & web configuration interfaces.<br /><br /><h3>Other</h3><br />I had a good talk with ESRI Staff on geocoding; since I work for a local government, we're interested in maintaining our own, very particular address locators and had some problems tweaking them. I also got a good amount of time with the <a href="http://www.esri.com/arcpad">ArcPad</a> team- I already love ArcPad as a mobile client (our people can be out in the field with no telecom access easily available), and it's only going to get better with 7.2.James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-29949244304104936752008-03-19T20:25:00.000-07:002008-03-21T11:37:50.639-07:00Dev Summit Wednesday KeynoteApparently a <a href="http://www.cooper.com/">Cooper</a> nowadays designs the UI to programs, not barrels. Alan Cooper's talk was informative, especially to people who are (or want to) manage geeks. Talking points:<br /><ul><br /><li>Making money moving atoms vs. making money moving bits- a little bit tired at this point to people who are used to computers; the key to remember with this point is that there are still many people who don't understand the difference.</li><br /><li>Things like finance are now commodities/utilitarian in nature- having it (or having good implementations) don't help; not having hurts. Rejoinder: if that's the case, why do so many public companies still have bad financial practices?</li><br /><li>Software isn't a commodity; it's a craft. My response: It isn't, yet. One of the <a href="http://serverx.esri.com/ArcGISJavaScriptAPI/SuperTuesday.html">big things</a> Dev Summit has shown is that the bar for making really good online mapping applications <i>with custom data</i> is going to be lowered, quick. With other projects allowing for easy creation of mini-apps (<a href="http://pipes.yahoo.com/">Yahoo Pipes</a>) and the mapping projects only being a part of software development), the bottom of the programming market is going to drop even faster as every high school sophomore is going to make their own app 'cause they can</li><br /><li>The distinction between interface engineers, design engineers and production engineers is important. Controlling the UI (both software & human side), sketching out the functionality and finally making the code so it doesn't break are three separate tasks; I certainly can't do them equally well.</li><br /><li>Finally: an Eisenhower quote: <i>"In preparing for battle I have always found that plans are useless, but planning is indispensable."</i></li><br /></ul><br /><br />A good keynote speaker, but probably not what every attendee was looking for (aside from reassurance that they're a special class of worker, for now).James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-13348716466467077552008-03-18T21:52:00.000-07:002008-03-18T22:03:02.532-07:00Developing Geoprocessing on ServerOr, how to do geoprocessing & make it work.<br /><br />Despite being good with creating analysis processes, I'm still not completely comfortable with the Model Builder environment- it's not a complete scripting solution, and getting a model to run in a server environment has generally had problems. This session (admittedly partially given before over the web) was pretty much a best practices for developing to server (or developing a model in general) with an eye to what additional functionality is coming along in 9.3 (like layer transparency, to begin with). The slide deck (hopefully up soon) will definitely be a great reference.<br /><br />Mentioned throughout the presentations today is the fact that pretty much any client, be it ArcMap, ArcExplorer, a Web ADF site, or even a mashup or python (or ruby, php, and pretty much any other language) program will be able to utilize a geoprocessing task- that really puts the onus on getting the task designed correctly in the first place.James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-67123268956699545982008-03-18T21:19:00.000-07:002008-03-18T22:07:02.905-07:00REST & Mashups<h3>REST</h3><br />It was packed, and naturally <a href="http://www.spatiallyadjusted.com/2008/03/18/2008-esri-developer-summit-using-the-arcgis-server-rest-api/">people</a> more <a href="http://blog.davebouwman.net/2008/03/18/GettingSomeREST.aspx">vocal</a> than me have already posted (the first link, James Fee's, is especially good at explaining the technology).<br /><br />Some notes:<br /><ul><li>The structure to access layers is well-defined, but a little human-unreadable (admittedly, it's a programming interface). It'd be nice to address a layer by an alias (and possibly not have to worry about a reordering of the map document breaking everyone's programs)</li><br /><li>One of the things I'm interested in is a possible replacement for the <a href="http://www.esri.com/software/arcgis/arcims/about/metadata-services.html">IMS Metadata Service</a>. I haven't taken a look at the metadata delivered, but I'll bet any replacement simply leverages the information published through the REST service.</li><br /><li>The 9.3 release will be read-only, with writing probably(?) in 9.4</li><br /><li>True curves (i.e. arcs) are densified (changed to line segments) when served out. While I wasn't completely clear on it, it sounded like that was standard across the ADF (or I'm being wishful; it currently causes a small failure).</li><br /></ul><br /><br /><h3>Mashups</h3><br />Another good session. Dave Bouwman has another <a href="http://blog.davebouwman.net/2008/03/18/ArcGISServerJavascriptAPIs.aspx">good review up</a>. I'd say it's even simpler than what Dave makes it out to be, but then again, I started off programming for money as a webmaster in grad school. I will need to dive into <a href="http://dojotoolkit.org/">Dojo</a> some more- I haven't done complex sites very recently. Dave's point about simple sites is right- and the biggest message I'm hearing from my clients- we need specialty apps that get the data across clearly.<br /><br />A lot of the Q & A was taken up trying to nail home the fact that javascript is <i><b>a client-side language!</b></i> Once the data is transferred to the user, the server doesn't touch it unless it's uploaded back (which isn't completely out-of-the box).James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-58161843185331026962008-03-18T20:53:00.000-07:002008-03-18T22:08:01.574-07:00ESRI Dev Summit Plenary<ol><li><a href="http://www.spatiallyadjusted.com/2008/03/18/2008-esri-developer-summit-plenary/">Spatially Adjusted</a></li><br /><li><a href="http://blog.davebouwman.net/2008/03/18/JumpingIntoTheKoolaidDevSummitPlenaryNotes.aspx">davebouwman.net</a></li><br /><li><a href="http://myesri.blogspot.com/">Rise & Shout</a></li><br /></ol><br /><br />Check the above for very thorough descriptions. Rather than regurgitate the same, here are some thoughts:<br /><br /><ul><li>The javascript frameworks are going to generate a ton of new apps- it's an opportunity for any organization that has ArcGIS Server running to serve their data & have everybody else use it without messing with it.</li><br /><li>More importantly, the web client support lessens the need to host both mapping applications & services on the same ArcGIS Server box (app vs. data).</li><br /><li>I'll talk about it in the mashup post, but the javascript libraries look to be dead simple if you've done a mashup before (or even some moderate DHTML use & read through the google maps examples)</li><br /><li>ArcGIS Mobile- I agree with Dave on wanting to try it out. The presentation they gave was a very good intro walkthrough.</li><br /><li>Deployment to mobile devices is a lot easier- we can download from ArcGIS Server (makes it a lot easier to do a quick install). Even a quick "view the map on the cellphone" app would help us at this point (Parks people out in the field).</li><br /><li>ArcGIS Explorer is maturing- I'm going to look forward to the future releases they showed.</li><br /></ul><br /><br />So there's probably a reality distortion field set up in Palm Springs (the servers responded WAY too quickly), but from a programmer's standpoint, 9.3 looks to be a good release.James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-15048427042080186402008-03-18T06:50:00.001-07:002008-03-18T07:02:18.923-07:00'Pre-conference'I'm at the <a href="http://www.esri.com/events/devsummit/index.html">ESRI Developer's Summit.</a> Yesterday was the pre-conference. I was able to have some nice conversation with ESRI employees about ArcGIS Server; we were able to solve some issues with a web application. ESRI is naturally showing a bunch of Server 9.3 demos; they have some pretty nifty examples using the Javascript API- I'm really eager to learn more & get the beta.<br /><br />The weather is gorgeous. The <a href="http://www.esri.com/events/bpc/index.html">Business Partner Conference</a> ended yesterday as well; it snowed for at least part of their time here. It was really interesting to talk with some of the attendees to that conference; it's a bit too bad there isn't more overlap between the two conferences.James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.comtag:blogger.com,1999:blog-9000904113127805348.post-84538546004131517052008-03-18T06:43:00.000-07:002008-03-18T22:08:44.690-07:00Apparently, 'kosher-style' means...Being able to offer a ham & cheese omelet for breakfast.<br /><br />I'm a ways away from NYC.James Tedrickhttp://www.blogger.com/profile/09727083592602514056noreply@blogger.com