Hi Martin! A splendid idea, and probably quite feasible to implement within the current architecture. My suggestion for draw order would be (top down) Text > Points > Lines > Regions
But it would of course not solve Christines original question, where she wanted to control the draw order of individual lines in a line layer. Another interesting research project is to find out how MapInfo determines the kind of table when deciding the layer order. As you all know, opening a mix of tables and simply load them into a mapper most often produces a reasonable order of points on top of regions and so on. There is no time to scan each table to find the predominant feature type, so I guess this in some way is an attribute of the table known beforehand. H�lsning/ Best regards Mats.E ________________________ FB Engineering AB S�dra F�rstadsgatan 26 211 43 Malm� Observera att vi byter telefonnummer 1 september! Tel: 040-665 64 80 fr�n 1/9 040-660 2550 Mobil: 0705-27 60 27 �ndras inte Fax: 040-665 69 90 fr�n 1/9 040-660 2599 e-post: [EMAIL PROTECTED] http://www.fbe.se "Martin Higham" <[EMAIL PROTECTED]> 2004-09-01 10:39 S�nd svar till <[EMAIL PROTECTED]> Till "MapInfo-L" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Kopia �rende MI-L Drawing Order What does intrigue me is the issue of layers containing 2 or more types of object. If you're going to allow points, lines and regions to be stored together (sometimes useful though its a no-no from a database point of view), why wouldn't you force points to draw on top of lines on top of regions ? If this "redraw order by object type" functionality was implemented, then it would make multi-object-type layers useful for map annotations. Best Regards, Martin Higham Avantra Geosystems ph (61 3) 8504 0428 0425-730-428 fx (61 3) 9596 7997 www.avantra.com.au > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 1 September 2004 03:38 > > <...cut...> > > As to why we do not have this feature, I would start a different thread on > that. The short answer is that we could but it is unclear how one would > decide what was drawn when. If the criteria was based on data, the > implementation would best do queries just as you can now. If the criteria > was arbitrary, then you have some draw order list, which is only > manageable > for small amounts of data and will be slow because the draw code can't use > the spatial index. --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13160 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 13161
