I think that the basic problem here is that QGis is GIS "in development" (note it is a 0.x version!), providing a good system for displaying and editing geospatial data (although there are few features still having to be integrated in the current version) and a python platform (a unique and promising characteristic of QGis that is perhaps overlooked by some users but that provides the basis for an extraordinary interfacing capability with other tools), but now almost completely relying on the raster-based GIS GRASS for any GIS analysis. The fact that QGis is not being able to do the join operation that you need is an strong indication that QGIS must have some analytical capability on its own, and actually this particular operation is a critical one, as you, on a purely user-oriented approach, have contributed to point out.
The problem is that QGis developers cannot do everything at the same time and are now focusing on the display and edit tools, trying to get an stable version with no bugs. Putting pressure on them will just cause not having well finished tools. But I do think that the users must start to make a list of basic processing and analytical tools for QGIS. Without this (at least basic) processing and analytical capability, QGis cannot be considered really as a GIS. So, in fact, Tom is contributing to QGis development. Perhaps the current incompleteness of QGis as a GIS system should be stated on the web page along with a roadmap of its development. Getting back to your problem, in practice you have to: 1. Get your joining done in another software. 2. Make your display with QGis 3. Don't expect that tasks can be done while remaining in the ignorance. I do agree that we tend to abuse of jargon, and apologize, but you must get you some text book on GIS if you want to work in (or even with) GIS in the long term. One of the many things lacking in QGis are GIS tutorials explained using QGis tools, and it will take a while until we have them, I'm afraid. Agus tom sgouros escribió: > Micha Silver <[EMAIL PROTECTED]> wrote: > >> tom sgouros wrote: >> >>> Thank you again for your help (in my new neighborhood). I guess I >>> somehow had the idea that data corresponding to a town *was* >>> geo-referenced, since I also have the coordinates of that town's >>> outline, and maybe that was where I was driving myself crazy. >>> >> What do you mean when you say you "have the coordinates of the town's >> outline"? Surely each town's outline must be hundreds of coordinates? > > Yes, I meant the vectors of coordinates that are the towns' outlines. > >> Editing a shapefile's dbf using a spreadsheet is definitely *not* the >> GIS approved way. It was suggested as a "quick and dirty fix" for the >> problem you described. At first it sounded like: "I have a nail and >> two boards. What tool can I use to connect them?" But now it turns out >> you that you actually plan to build a house. So you'll surely want to >> resupply your toolbox! > > Yes. The analogy is a good one. My problem is that everyone gives me > manuals with words like soffit and stringer and fascia while I need a > manual or tutorial that uses words like board and hammer. I'm sorry to > seem so dumb about this (believe me, I am sorry), but I'm just having a > hard time translating the abstract high-level ideas into the > nitty-gritty of how do I actually do this. > > To be more concrete, I already know that what I need to do to make the > maps I crave is to associate my town-level data with the towns in my > shape files, and then map it. What I need to know, and what I haven't > been able to glean from all the reference documentation that has been > shown to me, is what software do I actually use to do that? Honestly, I > thought that's what GIS systems are for, and QGIS is a GIS system, so I > thought it followed logically that this is the kind of thing it does. > But it isn't, apparently, so what is? > >> other data particular to each individual island. You might best choose >> to give a town code (or town name) to each section that is part of a >> town, and use that code or name to link to a database table of other >> town data. This would most efficiently be done in PostGIS, of course. > > Hmmm. "Of course"? This may be obvious to you, but finding a way to > understand what software does what part of these tasks is the whole > point of my questions. I'll take this as a suggestion that perhaps what > I need to do is to acquire some expertise making joins like these. > Maybe I should start with PostGIS. > > In my blundering about with QGIS, I see that QGIS seems to have some a > couple of dialogs that seem SQL client-like. Is QGIS the PostGIS client > of choice for this kind of work, or is there some other client that is > more complete or intuitive? Does PostGIS come with its own? > >>> Say I have another pile of shape data, like zip-code outlines or census >>> tracts. If I want to map those outlines to my town shapes, and come up >>> with a list of zip codes or tracts that overlap each town, what would I >>> use? I don't mind being pointed at something with a shallow learning >>> curve, so long as I know that it will, in fact, have what I need >>> somewhere up the slope. My problem so far has only been that from as >>> far down here as I am, I can't tell what's on which slope. >>> >>> >> Again, these are spatial queries that QGIS alone can't do. The GRASS >> v.overlay module would do the trick. > > Is this something you run via the GRASS buttons of QGIS, or do you run > it separately? You say "again". Do you mean that GRASS could do the > data join I described above? > > Many thanks for your help and patience. > > -tom > > -- Dr. Agustin Lobo Institut de Ciencies de la Terra "Jaume Almera" (CSIC) LLuis Sole Sabaris s/n 08028 Barcelona Spain Tel. 34 934095410 Fax. 34 934110012 email: [EMAIL PROTECTED] http://www.ija.csic.es/gt/obster _______________________________________________ Qgis-user mailing list Qgis-user@lists.qgis.org http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-user
