Military Symbology Needs Upgrade

While the standard military symbol (MIL-STD-2525B and APP-6A) is well organized, fast to display, easy to learn, and is of course the standard, in my opinion it needs to be upgraded. Check out this poster from AGI. There’s a mix of 3D models for everything from jets to entire cities with materials, jet exhaust, shading, labeling, etc. but right in the middle of the graphic are the typical military symbols. They seem completely out of place in the modern digital military age. It seems to me that there isn’t much of a reason to continue to use these symbols when many of major cities of world are currently being modeled in 3D virtual globes and the ease at which something like a tank can be created. I think the military should invest in developing a new standard based on 3D models that are just as intuitive, easy to learn and perform just as fast as the current standard. While I realize this would be a huge effort and would take years before we see it come to fruition, it would probably be a good idea to start the new standard now because the technology and means to display this kind of symbology is really already here.

Which tank would you prefer?

Also, what about orientation of the symbol? In order to see the standard symbol at all angles you must turn on billboarding otherwise while in a perspective view you might not even see the symbol. Of course this isn’t a problem with fully realize 3D symbols. Another aspect of orientation is when animating the symbols. Because something like a jet has a front and a back it makes since to orient it correctly so you can intuitively determine its heading. It doesn’t make much sense to add a leader line to show the heading of something that naturally has a heading based on its orientation.

In the end it just makes sense to view 3D objects because that’s how we perceive them in the real world but I’m not holding my breath for any big changes to the military symbology.

IGlobeCamera::SetToZoomToExtents

Being able to zoom from one point to another using ArcGlobe is a nice feature. However, in order to zoom around in an animated fashion you need to turn on this feature in ArcGlobe. To do so, just click Tools > Options and then click on the General tab and then check "Animate viewer when using tools and commands." You can also set the speed. But, if you're a developer you might need to set this programmatically. For example, if you've built a Desktop tool you don't want your end user to have to set this in order for the tool to work. Or, if you've built an Engine tool the Desktop software may not even be installed on the client machine. But, how? Unfortunately there doesn't seem to be a way to this via ArcObjects but you can set this via the registry in the following location:

HKEY_CURRENT_USER\Software\ESRI\ArcGlobe\Settings\AnimateTools

Just change the value from 0 to 1. Now, if you need to build a custom tool that zooms to a point, some selected features, or around an entire layer via IGlobeCamera::SetToZoomToExtents, this tool will now zoom in and out in an animated manner.

On being a GIS Developer, Part 3

Here is the last entry on being a GIS Developer. See Part 1 and Part 2.

36. You should realize that you can't do everything. Ask for help.

37. Learn other tools that can help you do your work. Learn tools that help you code, design, debug, communicate (i.e. MS Office), and manage (i.e. MS Project), etc.

38. Always be cognizant of the cost of things. It may sometimes be cheaper to buy what you need as opposed to developing it.

39. Understand licensing issues. Sometimes a solution to a problem may not be feasible just because the way a company has structured their licensing.

40. Learn to evaluate alternatives. A little thinking ahead can save a lot of time. This not only applies to architecting a new GIS, but also in spatial analysis.

41. Always be weary of hype especially from vendors and even from yourself.

42. Remember, under sell and over deliver. Set expectations.

43. Sometimes the performance of your app will be less than desirable but realize that it may be the data or the network, not your code. Or it may be your code and don't be shocked if you have to re-write something.

44. Just because ESRI (or any other vendor) does it this way doesn't mean it's the best way in general or the best way for your organization or for your app, or for you.

45. Always do the best you can with what you have. You may not have the latest version of ArcGIS and have to make due and develop a custom tool that no one else will ever use.

46. Try to be cognizant of how much work you will create for others. Always try to make it easier.

47. Commit yourself to helping the GIS community as a whole. Be a part of GIS day, help other users via online forums, etc.

48. Keep notes of what you've learned and what you must do and share it.

49. Avoid bad mouthing a predecessor. You don’t need to validate yourself by tearing down those that came before you.

50. Sometimes you will be the GIS superstar because everything came together with the right app and right people and at other times you won’t be. Sometime things just won’t work out and there’s not much you can do about it. Sometimes fortune plays a huge role in your success and at other times misfortune is your worst enemy. Hopefully, however, your successes will be more than the failures.

51. Don’t milk a project. You should always get the project done as quickly and efficiently as possible.

52. Realize that the technologies you know now will be replaced in a few years. This not only includes the technology, but also the way in which you implement and develop software.

Continuous or Discrete Raster

Ever needed to know if the raster you're working with is continuous or discrete? If so, you only need to open ArcCatalog and bring up the properties and check out the Source Type. While this is usually something that's pretty obvious given the type of data, there are times when it's good to know programatically whether a raster is continuous or discrete. However, the only problem is trying to determe how to do this. Unfortunately, as of ArcGIS 9.3 Service Pack 1 you won't be able to find the answer because the property needed to do this is NOT documented and it took some effort to find it. The answers is to use IRasterBand::RepresentationType. With this property there is an enumeration called rstRepresentationType which returns DT_THEMATIC (discrete), DT_ATHEMATIC (continuous) or DT_EITHER (both). So, not only is this method not documented, the enumeration's values don't match the wording in ArcCatalog. Truly lame. Anyway, I hope this helps someone else.

On being a GIS Developer, Part 2

Here is this week’s entry on being a GIS Developer. For Part 1 click here.

21. You must be able to think abstractly at one point and with great focus and precision at another point. GIS is by its very nature an abstract proposition. We are always dealing with representation of one form or another. On the other hand, when writing code you must be able to switch to the more logical side of your brain.

22. You should be able to reason and also listen to reason. Pay attention to what people are saying and how they are saying it. Develop your emotional intelligence as well as your rational thinking abilities. Learn to read between the lines. Learn how to spot logical fallacies and effectively respond to them.

23. You should understand that others don't understand GIS like you do. As a developer you understand GIS from a completely different level than most others. When they see a GIS they see a fancy map but you see points, polylines and polygons, vertices, and other complexities.

24. You should be willing to mentor others. Once you’ve gained some experience be willing to help others grow. Not only does this help your team it helps you hone your knowledge and skills because it forces you to really know what you’re talking about.

25. You should understand that your personal gains must sometimes be sacrificed for the goals of the project. Sometimes you’ll have to let your skills lag so that your organization can keep a customer. This is hard one for developers because we’re always trying to stay ahead of the curve.

26. Understand that pride and ego have can be an impediment in this field but are often a great driver behind the motivation of GIS developers and others. Take joy in the benefits you bring to a project. Also, realize that you will work with people that are smarter than you. Don’t feel threatened; learn from them.

27. You should be able to communicate to your superiors how realistic something is or isn’t. You don’t ever want to promise something you can’t deliver. Also, try to help your team not promise something they can’t deliver.

28. You should be fair in your criticism and try not to take something personal when someone else criticizes your work.

29. Always try to improve but also don’t re-invent the wheel just because you can - code reuse, knowing what's already developed, etc.

30. You should be familiar with your organization, its culture, the people and their knowledge, and how you can utilize it in your efforts. Learn the history of what's been done, what was cast aside, who the players are, etc.

31. You should know your customer and/or users. Learn why they do things and what their issues and frustrations are. Gather as much written information as possible but also talk with everyone involved so you can get feel for their views on the project. What do they expect? How do they work? What’s their culture?

32. You should realize that building a new app or new tool isn't always the solution. Sometimes it's just a matter of changing the data or changing the business process.

33. You should always be prepared. Always know the purpose of a meeting and why you're going to be there.

34. You should try to work as closely as possible with the end user. They will be the ones that actually use your software so they should be your focus.

35. You should avoid the politics of the organization if at all possible. There is nothing more corrosive to a successful GIS than politics.