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.
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:
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.
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.
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.
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.
ESRI has replaced the interface to the resource center. It looks better and it's easier to get to the developer links.Once you navigate to one of the individual resource centers just click on the For Developers tab to get the good stuff (i.e. code library, samples, etc.). It's a nice improvement. I just can't figure out why it took them so long to figure out that the old design was pretty bad.
ESRI is targeting April/Map for the release of ArcGIS 9.3.1. They have released a list of the fixes. Here's a breakdown of the total number of bugs and enhancements that were resolved in this upcoming new version:
ArcGIS Desktop - 196 ArcGIS Engine - 11 ArcGIS Server - 99 .NET Manager - 7 .NET Web ADF - 37 Java Manager - 4 Java Web ADF - 6 REST API (Java) - 1 Image Server - 26 ArcSDE - 69 ArcIMS - 2
That makes a total of 458 issues that have been resolved. It would be interesting to compare this to previous releases which could tell us if ESRI is improving over time. Also, notice that ArcGIS Desktop has the most enhancements/bugs that have been resolved. This makes sense because it is the primary product that ESRI users use. But, ArcGIS Server is receiving the most new features as evidenced in my post about the amount of the interfaces that were released in 9.3. Surely all of those new interfaces don't have a proportionate number of new bugs.
For anyone that needs to convert LiDAR data here are a set of tools that may be of interest:
libLAS - a c/C++ library for reading and writing ASPRS LAS files.
and to get the data into ArcGIS use the LAS to Multipoint tool in ArcGIS. Another useful tool is from VLS Software and it's called LIDAR Analyst. Lastly, you can also use LP360 from QCoherent.
I thought I’d share some of the things I’ve learned over the years from being a GIS developer. The following is just a list of things I’ve observed, learned or advice I can give from working on a few dozen projects. Some of the items are specific to GIS while others could be applied to the IT professional and then some others could be applied to life in general.Also, I’ve grouped some of these together and some others aren’t grouped because I think they deserved their own position on the list. When I started compiling this list I realized that I could go on and on so I’ve tried to limit it.Furthermore, these are in no particular order. Lastly, if you’ve been around for a while you will find some of this pretty obvious but if you’re new to this profession some of it may not even make any sense. Regardless, I hope it’s a good start and that you find it helpful. This article will be divided up into 3 parts over the next few weeks.
1. GIS Developers tend to always be thinking about some problem they are having, some new piece of technology or just something they’ve learned about or another way to solve a problem. It’s just the nature of the work and you must be someone that enjoys thinking a lot.
2. You should always try to keep learning and learning fast...learn everything you can. Read GIS books, attend conferences, talk to others, etc. All of this knowledge adds up over the years and makes you even more useful and able to apply your skills and knowledge in different ways.
3. You must be creative and have an entrepreneurial approach. Necessity really is the mother of invention. I never had much of an entrepreneurial spirit until I owned a GIS company. There’s nothing more creative inducing than having to put food on the table. Many a programmer would be better at their job if they just acted like it was their own business.
4. You must have a strong work ethic, excellent problem solving skills, be objective, honest, cope with stress, multi-task, and pro-active, team oriented and/or able to work alone, good interpersonal skills, a strong desire to help people, be willing to share what you know, tenacious, dedicated, open minded and so on.
5. Most of the time you will be more of a generalist than an expert in this field because you will constantly need to go from project to project or from one version of the GIS to another.
6. As a GIS developer you must have a solid knowledge of GIS, cartography, software engineering, databases, remote sensing, Web tools, geography, spatial analysis, etc. The list is long and every year it seems to get longer.
7. You should understand related subjects like computer science, mathematics, operations research, etc. I can’t tell you how much I now need to know now in regards to math as opposed to when I first started in GIS. Even knowing something like photography, physics, or forestry can help.
8. You should understand ESRI and the way it thinks about GIS. You must know ESRI's algorithms or at least know what published algorithms they’ve based their software on. On several occasions knowing what algorithms ESRI uses and how they’ve implemented them has saved my butt.
9. You should understand software development like Rational Unified Process, Agile, etc. You must understand which one to use and it’s highly dependent of the business domain. Also, test, test, and test again. There’s nothing worse than having a user tell you your application doesn’t work.
10. You should be able to work with analysts, subject matter experts, editors, managers, end-users, etc. All of these team members will have different perspectives on GIS and all of them are equally valid.
11. You should be aware of standards and able to apply them. They can sometimes be a real limiting factor but you’ll still have to work with them. They are important and make GIS easier for everyone to understand and use.
12. You should either know about the subject matter domain or learn about it. I’ve now worked in several industries (electric utilities, local government, military, banks, etc.) and each one has a different set of regulations, policies, geographic properties and so on that are unique to them. You must be able to adapt your knowledge of GIS to these domains.
13. You should understand hardware, OS, networks, etc. Sometimes the difference between success and failure is knowing how one OS handles files differently than another. Also, in order to build a workable architecture you should understand the pros and cons on the underlying hardware and network.
14. You should have excellent communication skills: written and oral. Also, you should learn the art of persuasion. Develop your public speaking skills.
15. You should be aware of the GIS market and the tools that are available. Sometimes you won’t be able to develop a tool but you must be able to give management an alternative. Also, understand the relationships between different vendors and who will work with whom.
16. You should be willing to take managed risks. Sometimes you’ll be the only one that understands what needs to be done or that a new piece of technology may provide the solution you need. Hopefully, you’ve built enough trust from others to take this risk to develop it. Of course you must temper this with pragmatism and cost and other factors.
17. You should be an evangelist. You must be willing to promote GIS and new tools to others. Often you will be alone in your endeavors but if you don’t overstep you should be able to persuade others of the benefits of some new technology or approach.
18. You should be able to switch different parts of your mind. One minute working on code and the next giving a demo, and in some cases the next doing marketing. It just depends on the organization you work in and your own abilities.
19. You should understand business process modeling, data modeling, object models, etc. You will come across many of these in your career and some of them will be very complicated and if you understand all the symbols and icons it’ll make your job easier. This is how the GIS professionals communicate conceptual details to each other.
20. You should keep up with the latest research and technology trends. You never want to be caught with your pants down. Learn about new technologies and determine their advantages and disadvantages. Try to determine if and why the GIS vendor has or hasn’t implemented something.
Because your own strength is unequal to the task, do not assume that it is beyond the powers of man; but if anything is within the powers and province of man, believe that it is within your own compass also. - Marcus Aurelius
