Assessment 1: Hints and Tips


There is no prefered solution to this assessment.


This project is about exploring the API and locating data. The core algorithm shouldn't be too bad. but there's one or two bits that might take some thinking about and exploring around to get perfect. As the core of this is somewhat simpler than the other project, I'm not going to give you much in the way of pointers - just to say start with the data hierarchy we saw in the lectures, and check out the methods available as you drill down through them in the API, and to check out the examples on our website and the ESRI site. Each feature is stored as a Polyline object (i.e. it will have nodes at the ends, but also bends in it along the way which are not nodes unless other features connect to them). Each Polyline will have a unique OID which can be used to identify it.


Planning your project

  1. First, think through roughly how your project will look and work. Draw and annotate short descriptions of how a user will use the tool. Think "would I find this easy to use" and "from the user's point of view, is each step there for a reason". Then think through what can go wrong -- and this is right from the beginning when the user opens Arc, through to what happens if they send a document to someone else. Having thought through these two aspects, draw up a UML of the classes and methods, but annotate it with rough ideas of what each class or method has to achieve. Your project will change as you go through and learn the capabilities of the classes, so you will need to revisit this plan, but you definitely need to start with something in place.
  2. Break the project into tasks ('essential', 'ideal', 'nice-to-have') and do the essential ones first. There is no point spending weeks getting an addin to save somewhere really clever (ideal) if it doesn't appear on the screen (essential). Start with something simple, like getting the x coordinate of a node.
  3. When you come to start coding, remember the first rule of coding: Baby steps. Write a few functional lines at a time, and test them when you've written them. There is no point in ploughing on passed issues. Sort them out before you move on. If something is really stopping you moving forward, ask Andy for help.
  4. Finally, persevere. One thing you'll find with the API is that you can drill quite a long way down into the data structure, and suddenly have to undo a bunch of work and start again higher up the hierarchy -- don't let this put you off, it's just the nature of the beast. As you get closer to some data types things can break down and not work as the API says they will - again, this is just something you have to backtrack from and work at again.