But with the two Geoms solution, I see that creating pokable labels is way beyond where I can go right now. I sort of feel like a ping pong ball that just got swatted into a basketball court. I am definitely in the wrong place, now.
I can see that. But that's what happens when you try to use any sophisticated program without first taking the time to learn the basics of the program and how to operate it. To learn Release 9 you need to invest a solid day or two of fairly intense learning. Skip that and you only spend far more time thrashing around with tons of frustration that people who learned the basics have completely avoided. Start with the first topics and read them in order - actually read them without skimming - at least through the Getting Started and Basics books. Mix in careful reading of Examples topics and repeat examples yourself. Beginners at GIS do well with that approach because they don't know any better than to follow instructions, so quite often they actually do read the topics as recommended above. Experienced GIS people sometimes have a far harder time of it because they won't invest into that initial learning phase. Instead, they try to reasonby analogy from what is already familiar to them, augmented by occasionally diving into various topics that seem relevant. That may not be a bad approach for a system which is very similar to what is already well-known, but it is a terrible approach for something genuinely new. Ifyou fail to learn the basics, yes, for sure you will feel totally lost and confused because not knowing very basic, simple things causes a cascade of frustrations that prevent effective workflow. What is totally easy and fast for somebody who learned the basics first becomes a hall of mirrors and endless frustration for you. Sure! Why didn't I think of using two Geoms?
That you've missed the opportunity to accomplish sophisticated things in a snap is not something to mock, it is something to correct by investing into your own education. Investing into your own skills is never a waste of time. The most valuable asset you will ever own is your own education and skills. That you didn't think of using two geoms is not a surprise given you're a beginner, you didn't read the topics that tell you want a geom is, and you haven't read the Example topics where more advanced uses of geoms, such as having more than one geom field, are demonstrated. No problem, as that's the sort of thing you can learn by coming to this forum. Because I have an extremely limited idea of what a geom is. It seems to be an amorphous container for all the secret graphical intrinsics I can no longer see. There are tons of references to geom in the voluminous manual, but a quick survey of them did not reveal a helpful definition.
Hopping around with a quick survey of what topics you think might be relevant is not as effective for learning as investing the time to learn the basics in the first place. All those tons of references assume you've read the basics. They don't repeat those basics, that defined and described the thing in the beginning. Geoms are simple and are well defined using clear language in the Tables topic and in the Drawings topic found in the Basics chapter. The Tables topic and the Drawings topic are almost painfully explicit, taking nothing for granted about a reader's understanding or prior experience. Examples: The shape and locations of objects in drawingsare stored in geometryfields in a table, using a Manifold data typecalled a geom.
and Each point, line or area is a recordin a table from which the drawing draws data. Each such record at least has a geometryfield that specifies the location and shape of the point, line or area, and each such record may in addition have other fieldsthat provide additional data for each object. [...] By geometrydata we mean the collection of coordinates that specify the location of a point (a small collection, just one coordinate...), the shape and location of a line, or the shape and location of an area.
If you missed the above,then sure, you might come away with thinking a geom is some amorphous container and encounter totally unnecessary frustration. The missed opportunity to learn what a geom is at the beginning cannot be recovered so easily by browsing all the additional discussion that mentions geoms based on the assumption you know what those are. I get no credit for the 15 step process I innumerated, but I catch crap for not going into the details of pushing the single Add Component button. I sort of thought clicking on a button was in everyone's knowledge background, but apparently I need to explain how I did it. - I selected the transform,
- selected Add Component, and
- clicked on it (the Add Component button).
You're not being fair, neither to yourself nor to others. You did get credit for the 15 step process you enumerated., because your enumeration of the 15 step process made it clear you were taking a wildly wrong approach that indicated you were missing all sorts of basic notions. Providing a simple, five second process is one way to try to show you that learning the basics really does enable you to use simple and fast procedures instead of wildly wrong, time-wasting stuff. As to clicking buttons, your sarcasm appears to have missed the point that blind clicking of buttons without having first learned what those buttons do and how to use them sensibly is not the way to getting it right the first time, saving time and frustration. Consider your three step process and the information you did not provide: 1. What transform? What was the window that was open? Was it a drawing, a table, a labels component, an image? A map? What layer? What was the schema for the table? 2. What were the options you used? What did you intend? What did you expect? 3. What did you do with the components that appeared in the Project pane? If you know what the thing does (well documented) the above are simple questions that for the most part take care of themselves during informed workflow. If all of this is alien for lack of learning, well, sure they may seem confusing. Walk a mile in my shoes.
Happy to do that to help you find your way, but to walk a mile in your shoes I have to know where you are, in what direction that mile is and what the shoes are you are wearing. Start with an overall description of your task. Then we can help. It sounds like your task is given a parcel ID to see the parcel. Fine... that's the task to focus on. I ask them in a targeted way hoping the answer will provide that one precious missing step I can use to extrapolate my base of knowledge to make this program work. Notwithstanding the premise for the original post here, I usually don't need to reread stuff I think I already know. The questions I ask are hopefully 5 or 10 steps into a process.
That's not going to work in a situation where your approach is wildly wrong because you never learned the basics of the thing. Trying to fix step 6 or 11 when the first step took you 180 degrees in the wrong direction cannot give you a solution. It's like getting on a forum asking for an explanation how to shift from P for Park to D for Drive so you can get moving without mentioning you are on a sailboat and for some reason you think there should be a shift lever to operate the sails. It sounds like your end task is that in a parcels layer you want to see info on a specific parcel. You want to do that with 9 without spending the time to learn the thing from the very beginning. Your approach, therefore, is to reason by analogy to what you know in 8. So, you're asking questions based on presumption that stuff in 9 works close enough to 8 that you can wing it without really making the effort to first learn 9. To zero in on the parcel you apparently want floating labels to guide you, labels that switch on and off. But 9 is a very different product, for all the right reasons, than 8, so reasoning by analogy with 8 takes you into wildly wrong workflow. Doing that just causes frustration and takes a hundred times longer to get nowhere. Learn 9 and use the simple stuff in 9. For example, if you want to find a parcel you don't need SQL. That's what a simple Ctrl-F (for Find, a pretty universal shortcut that is easy to remember) is for. Leave a table open so you can use it when you want. Find the parcel record with a Ctrl F, select it, and you get a bright red dot in the map in what otherwise is a sea of densely packed black. Easy to zoom to that. Don't like the table presentation of attributes? No problem. Alt-click the parcel to see fields in Record - values format. Now, since you haven't really told us all the ins and outs of what you want to do the above, of course, is not the same comprehensive, everything you might want to do spelled out description. It's just an example that you don't need to use SQL to find a parcel. But don't mock SQL when for lack of a few hours learning SQL you waste hundreds of hours doing things manually that you could have done in seconds. The ability to use SQL is cool because you can use queries to automate routine tasks. It's a huge time saver. It's also cool because tiny, really simple snippets of SQL can help you build simple layers and other helpful infrastructure that let you put together a project to save yourself time and hassles. For example, I don't know if having guide layers is a good idea for your task. But if it is, may as well do them right, and SQL can help you create them very quickly and effectively. For example, if parcel numbers have some sort of regional ordering you could create groups of parcels with the same leading edge of most significant numbers, put a dot there and make a label. Then you'd have a great layer for zoomed out guidance. Like I say, depending on what you want to do almost always there is an easier, better way of doing that in 9 than in 8. But you must commit to learning 9, master the basics, and then use 9 methods to make it easy.
|