RE: MI-L MapBasic question - Style override
Hi Greg. You can use LayerInfo( n, LAYER_INFO_DISPLAY) to determine if an override is set. Check out the LayerInfo() function in the help file for the return codes. Regards, Tim Nuteson Target Corporation -Original Message- From: Driver, Greg 9434 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 5:41 AM To: '[EMAIL PROTECTED]' Subject: MI-L MapBasic question - Style override This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Listers, Is there anyway when switching a layer on in MapBasic to know whether a global style override has been set? The reason I ask is that we have a small MapBasic application that switches loaded raster images on and off. The only problem is when an image has been switched off and a style override has been set for the layer, when it's switched back on again it displays as default (without the style override). Looking at the MapBasic reference guide it's only possible to switch a layer on as either GLOBAL (with style override) or GRAPHIC (as default). So if you use GRAPHIC it ignores any previous style overrides that had been set or if you use GLOBAL this displays with style override regards of whether it was set previous to being switched off. Any ideas on how I can get round this and know when a style override has been set? Thanks in advance. Greg Internet communications are not secure and therefore Surrey Police does not accept legal responsibility for the contents of this message. This email and any attachments may be confidential. They may contain privileged information and are intended for the named addressee (s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and delete the message and any attachments from your computer, do not disclose, distribute, or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender, and not of Surrey Police. We believe but do not warrant that this e-mail and any attachments are virus free. You must therefore take full responsibility for virus checking. Surrey Police reserves the right to monitor all email communications through their networks. ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put unsubscribe MapInfo-L in the message body. ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put unsubscribe MapInfo-L in the message body.
MI-L Label boxes missing from PDF files
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. I just upgraded to Mapinfo Pro 6.5, and now when I create PDF files with Adobe PDFWriter 4.0, the white boxes behind my labels don't show up in the PDF file. This has always worked before (in MI 5.5), so there must be something different in 6.5. Does anyone have any idea? When I use Acrobat Distiller, the label boxes show up, but the red tops of my interstate shields are missing. So Distiller is not really an option either. If anyone has any suggestions how I might fix either of these problems, I'd appreciate it. Thanks in advance. Tim Nuteson Target Corporation [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put unsubscribe MapInfo-L in the message body.
RE: MI-L Pennsylvania 250K drgs
Hi Dan. Check here: http://edcwww.cr.usgs.gov/glis/hyper/guide/1_dgr_demfig/index1m.html Regards, Tim Nuteson Target Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 8:27 AM To: [EMAIL PROTECTED] Subject: MI-L Pennsylvania 250K drgs Hello Listers, The GISdataDepot has spotty coverage for Pennsylvania 250K drgs. Is there an alternative site? I searched the web but could only find 24K quads. In particular, I need to obtain the Warren and Williamsport quadrangles. Thanks in advance, Dan -- --- Daniel P. Laux Geologist MagmaChem LLC Apache Jct., AZ www.magmachem.com ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put unsubscribe MapInfo-L in the message body. ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put unsubscribe MapInfo-L in the message body.
MI-L MB: Fastedit on?
I have Fastedit On set for a table, yet as soon as edits are made the Save button on the toolbar lights up. When I click on the Save button, the FastEdited table is listed as one that needs saving. If I instead just close the table WITHOUT saving it, I am not prompted to save it. 1. If Fastedit is ON, why does MI Pro think the table has unsaved edits (i.e. the Save button lights)? 2. If the Save button is lit, why am I allowed to close the table without being prompted to save it? Can anyone explain this? Using MI Pro 6.5. Thanks Tim Nuteson Target Corporation
RE: MI-L MB: Fastedit on?
Peter Horsbøll Møller, GIS Udviklingskonsulent / GIS-Developer Kampsax A/S - GIS Software Solutions Rugaardsvej 55, 5000 Odense, DK tel: +45 6313 5013, dir:+45 6313 5008, fax: +45 6313 5090 mailto:[EMAIL PROTECTED] www.kampsax-gis.dk and www.kampsax.dk Authorized MapInfo Partner Distributor in Denmark and Norway. Se mere om Dansk MapInfo Brugerkonference på http://www.kampsax-gis.dk/Default.asp?ID=296 Klik ind på http://www.kortal.dk og se det hele lidt fra oven! Check http://www.kortal.dk and have a look at Denmark from above! - Videresendt af Peter Møller/Kampsax - 31-07-2002 15:53 - Tim.Nuteson Tim.Nuteson@tTil: [EMAIL PROTECTED] arget.comcc: Vedr.: MI-L MB: Fastedit on? 30-07-2002 17:57 I have Fastedit On set for a table, yet as soon as edits are made the Save button on the toolbar lights up. When I click on the Save button, the FastEdited table is listed as one that needs saving. If I instead just close the table WITHOUT saving it, I am not prompted to save it. 1. If Fastedit is ON, why does MI Pro think the table has unsaved edits (i.e. the Save button lights)? 2. If the Save button is lit, why am I allowed to close the table without being prompted to save it? Can anyone explain this? Using MI Pro 6.5. Thanks Tim Nuteson Target Corporation - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2282 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2284 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2285 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 2292
RE: MI-L SQL
Depending on your version of MapInfo, the MapBasic reference guide, which details all of these functions, is included in PDF format on the MapInfo install disk. I have MapInfo 6.5 and the file is here: d:\pdf_docs\mb_ref.pdf Tim Nuteson Target Corporation -Original Message- From: Justusson Christer [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 1:22 AM To: 'Jeff Card'; [EMAIL PROTECTED] Subject: SV: MI-L SQL Hi! Someone pointed me to this website some time ago: http://www.spatialplus.com/quests/qsql009.htm There is a list of all SQL functions in MapInfo and some have really helped me in tight situations like AreaOverlap(object1,object2). I hope it is of any help. But it would be nice to have examples for each function also cause some I can't figure out how to use. Other source for me has been KnowledgeBase at http://testdrive.mapinfo.com/kbase_by_product Regards Christer Justusson Uppsala -Ursprungligt meddelande- Från: Jeff Card [mailto:[EMAIL PROTECTED]] Skickat: den 18 september 2002 19:00 Till: [EMAIL PROTECTED] Ämne: MI-L SQL Can anyone give me an idea where I could find an in depth reference on SQL commands and using them in Mapinfo. Jeff Card Research/GIS Analyst The Weitzman Group (214)720-6612 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3110 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3124 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3136
RE: MI-L point labels - losing alignment
Hi Darrin. This problem is most likely due to a bug in the label position calculations within MapInfo. Eric Blasenheim, MapInfo Software Architect, explained the problem and its workarounds in a post to Mapinfo-L years ago, which I have quoted below. I have been experiencing the same issue for years. It shows up mainly when putting highway numbers inside highway shields (any slight error in alignment is glaringly obvious), but also when labeling points on large plots. Bottom line: zoom in really tight (800%) on your layout, go back to the mapper, turn the labels off, turn them back on, and return to the layout. All should be well. They need to fix this. Tim Nuteson Target Corporation [From Eric Blasenheim]: It is not entirely clear to me that all the recent questions on label plotting all relate to the same issue. Some may be a result of misunderstanding how dynamic labels are composed. In particular, many people still think that labels in the Layout are supposed to be the same as those in the Map window. This is not correct. The labels, which are always sized using paper (Points) units, fit differently in the Layout paper space than they do in the Map Window which has only the screen connection. However, there is a bug in the layout label calculation that may be the source of a number of these inquiries. There is also a workaround until that bug is fixed. When the labels are composed, their location is determined by translating the label location of the object (usually the centroid) from geographic units into a location on the page. This location is then adjusted according to the nine label positioning and offset options and the text size which is determined by querying the operating system (Windows). Once these labels are located only changes in the label settings for that layer, the scale of the map or the size of the layout frame will cause the labels to be recomposed. A simple zoom change in the layout, will not cause this. It only changes the display size of all the labels. This is how it should be. However, when the screen display size of the labels is quite small, the conversions between geographic, screen and paper locations result in loss of precision resulting in the labels not being correctly located. Basically we are querying Windows with user point sizes (8, 10, 12 point) scaled down to 1 or 2 points. This commonly occurs with large size plots and/or small screen resolutions where a view which encompasses the entire layout results in very small on screen text sizes. The workaround is to force MapInfo Professional to recompose the labels when the screen size of the text is more reasonable. So, if you zoom in to the layout to where the text is readable and do any of the following the labels should recompose correctly: 1) Change any setting in the label settings dialog or the check box for dynamic label visibility at the first level of layer control. Obviously, if you choose to turn off visibility you will need to turn it back on again. 2) Run any of the MapBasic Set Map Layer Label commands from the MapBasic window. These are the same commands generated by the Layer control/Label settings dialogs. 3) Change any of the zoom/scale settings in the Change View dialog or the MapBasic commands that they generate. 4) Change the size of the Layout frame where the Map is contained via the Frame dialog or by dragging the frame corner or side. Also note that any workspaces that you save can automatically use this workaround by saving them at a Layout zoom where the text size is not too small! Opening the workspace causes the layout frames including the labels to be recomposed from scratch and if the viewed text size is reasonable, the correct calculations will occur. We are looking into a fix for this problem. Eric Blasenheim [EMAIL PROTECTED] [end of quote] -Original Message- From: Darrin Clement [mailto:darrin;maponics.com] Sent: Monday, October 21, 2002 4:14 PM To: Mapinfo-L Subject: MI-L point labels - losing alignment Hello everyone, We have been seeing a very perplexing anomaly for a long time and it is getting too hard to deal with. Here's a brief summary: We have a point layer (which we happen to style using symbols) which we also autolabel. For small layouts (~8.5x11 inches), the labels appear perfectly on the points as we set in the label options to be centered. However, when we get to larger layouts (~3'x4'), *sometimes* the labels get randomly off center. I say random because some are to the left, some under, some over, etc. I say sometimes because for the exact same data and workspaces, we can sometimes fix this by turning off other layers. However, we try the same fix on the next map, and it doesn't work. We can't figure out why the labels don't snap to the points they are supposed to be labeling. We've tried it using both custom symbols and standard symbols for the points, and we've tried different font sizes, etc. We have also made sure
MI-L SQL statement not saved in workspace
If I do these two selections in Mapinfo Pro: select * from States where stabbr = WY into WyomingState select * from Cities where obj within (select obj from WyomingState) into WyomingCities It works just fine. I end up with a table of WyomingCities I can map, browse, etc. When I save the workspace, however, only the first of the two select statements is saved. When I load the workspace, it comes up with no sign of the WyomingCities table. Is this normal, works-as-designed behavior? Can anyone explain this? I'm using Mapinfo Pro 6.5 Thanks- Tim Nuteson Target Corporation - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 4043
MI-L How does MI Pro create drop shadows?
If I create a drop shadow under a rectangle in a layout window, it gets placed directly underneath the object that was selected, but above other objects that are underneath the selected rectangle. I would like to do the same thing (insert an object between two other objects in the 'stack'), but the only ordering control I have in the layout is to either send something all the way to the back or bring something all the way to the front. How does MI pro do it? Is there a behind-the-scenes loop happening that creates a list of layout record IDs and jams the drop shadow in there somehow? Am I missing some logic here? Thanks- Tim Nuteson Target Corporation
MI-L Vertical Mapper Error 503
I am trying to use the modeling functions of VM and am constantly getting the error Error in Mapinfo File Access Library -- Extended Error Value 503. I have searched the MI-L archives; there is no help for me there, just a lot of questions and very few answers. I am using VM 2.0, but I see plenty of these MFAL errors in the archives from VM 3.0 users too. I will upgrade to 3.0, but will it help? Are there users out there who have had this problem fixed by upgrading VM? I am using VM 2.00 and MI 6.5 on NT 4.0 sp6. My point tables are in lat/lon NAD83, though changing them to UTM made no difference. Any help appreciated, will sum. Tim Nuteson Target Corporation [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
MI-L MB: Manipulating objects with MapBasic
I'm trying to write some MB code to take two overlapping objects (stored in MB object variables) and return an object representing their intersection. It seems that all the 'Create Object' and 'Objects ...' commands require me to have these objects stored in MI tables, or selected, or set to be the target or something. Though I could use tables, I don't really want to - I just want to do this in memory, with variables. Is it possible? Seems like it should be and I'm just overlooking the necessary command or function. Any help appreciated, will sum. Thanks Tim Nuteson Target - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11422
MI-L SUM: Manipulating objects with MapBasic
Thanks to Ian Erickson and Warren Vick: The MapBasic function Overlap(obj1, obj2) returns the intersection of two objects. Tim Nuteson Target - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11425
MI-L Testing to ensure a string is numeric
Listers, Does anyone have a method using MapBasic to test whether a string is numeric? I have a dialog with an edittext box that needs a numeric input. Even if the solution is just a big hack that would be OK, since I am going to make a logical MB function along the lines of IsNumeric(123) = TRUE or something. Thanks, will sum. Tim Nuteson Target - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11747
SUM: MI-L Testing to ensure a string is numeric
Thanks to all who responded to my question: How can I ensure that a value entered into an EditText control of a MB dialog is numeric? The simplest solution was offered by Michael Taylor, Martin Highham, and Robert Crossley: If str$(val(teststring)) = teststring then 'numeric Else 'not End If Thanks again, Tim Nuteson Target - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11784
RE: MI-L Testing to ensure a string is numeric: another approach
List, I just wanted to point out another solution from Bill Thoen that seems to be pretty bulletproof: function IsNumeric (byval sVal as string) as logical dim i as integer For i = 1 to Len(sVal) If NOT InStr (1, 0123456789.+-e, mid$(sVal,i,1)) Then 'String contains a non-numeric character! Exit Function End If Next IsNumeric = 1 end function It basically steps through the string that's being evaluated, testing each character against a list of 'legal' numeric characters, and if it finds one that's 'illegal', exits the function and returns FALSE. Intuitively you would expect that this approach would be much slower, but in practical usage it blazes along just as fast as the str$(val()) method. Tim Nuteson Target -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 9:43 AM To: Spencer Simpson Cc: [EMAIL PROTECTED] Subject: RE: MI-L Testing to ensure a string is numeric Spencer, In terms of speed, I would mostly stick with just the val function. Just the idea that converting a string to a number and back to a string and comparing them is fraught with danger, at least for floating point. Note that the val function returns a number. It returns 0 for things that don't parse and for real zeroes. So if you had code like: num = val(somestring) if num 0 then ' this is definitely a number ' return true else ' parse the string looking for spaces/tabs and then a 0 digit to determine a true 0 endif This code will be much faster if you think that you usually do have numbers. The val function will do all the work for you. Call it an optimistic implementation. You can even design the function so it returns the number on success so that you don't bother doing it again. Eric Blasenheim Software Architect MapInfo Corporation Mail List: [EMAIL PROTECTED] From: on 05/17/2004 11:54 AM AST To: [EMAIL PROTECTED] cc: Subject: RE: MI-L Testing to ensure a string is numeric No, it will notThere are a couple of ways to implement them, some of which are more efficient than others. The str$(val()) method is the fastest method, but it's not the most robust. For one thing, it works only for integers. However, it's great for quick applications that require only integers. For robust, idiot-proof applications, you need more sophisticated validation routines. It is possible, of course, to write a routine that scans the string for the correct format, but this can be very slow, given that you have to make calls to mid$() for every character in the string. If you've been programming for any length of time, you've probably written one that you can adapt to MapBasic. Or you can write one in a faster language, put it in a DLL, and link to it from MapBasic (scanf is NOT recommended). Another method is to try assigning the string to a MapBasic window variable, and catching any errors. This method is optimal for validating strings that can take non-integer values. run command Dim v_dbl as float ... function good_float (ByVal s as string, f as float) as logical On Error Goto notvalid run command v_dbl=+sval OnError goto 0 f=val(Sval) good_float = true exit function notvalid: resume failure failure: good_float = false end function Hope this helps Spencer -Original Message- From: B. Thoen [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 11:05 AM To: Tim.Nuteson Cc: [EMAIL PROTECTED] Subject: Re: SUM: MI-L Testing to ensure a string is numeric Would that algorithm return the correct result if you fed it a numeric string like '0023456', or are numbers with leading zeros not going to be encountered? On Mon, 17 May 2004, Tim.Nuteson wrote: Thanks to all who responded to my question: How can I ensure that a value entered into an EditText control of a MB dialog is numeric? The simplest solution was offered by Michael Taylor, Martin Highham, and Robert Crossley: If str$(val(teststring)) = teststring then 'numeric Else 'not End If Thanks again, Tim Nuteson Target - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11784 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11788 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 11789 - List hosting
MI-L MapWorld
Has anyone gone to any of the MapWorld road shows this year? Comments? Anyone going to Chicago next week? Tim Nuteson Target
MI-L MB: Geocoding in MapBasic
Hi list, Does anyone know how to emulate the Table-Geocode operation in MapBasic? If I have a list of say, 100 zip codes, and I also have a mapped table of all zip code centroids, I can choose Table-Geocode and have the zip code list inherit the objects from the centroid file, where the zip code matches. This works great through the interface, but how can this be done in MapBasic? Thanks Tim Nuteson Target
MI-L Assigning value to points from underlying DEM
List, I have some imported GTOPO30 DEMs in MI Pro, and a layer of point features. Does anyone know if it's possible to assign the elevation to each point from the DEM? Thanks Tim Nuteson Target
RE: MI-L Highlight of my week
Barbara, If you are using Google Earth Pro, you can purchase the optional GIS importing module ($200). It directly opens native TAB files, allowing you to overlay your data on the Google imagery. I bought this add-on and have found it to be an excellent investment. Tim Nuteson Target -Original Message- From: Barbara H. Carroll [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 9:59 AM To: Mapinfo-L@lists.directionsmag.com Subject: RE: MI-L Highlight of my week So just have to ask - how do we integrate this with MapInfo?? The images are AWESOME!!! Barbara -Original Message- From: Eric Gagnon [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 7:25 AM To: MapInfo List Subject: MI-L Highlight of my week Hi, Since it's friday I figured why not try something else So I downloaded the famous google earth tool.. That CNN constantly uses during the Katrina coverage. It's just GREAT.. For you outdoors enthusiast, if you go to nepal to see Mt. Everest and you zoom in closely to base camp. You see yellow and purple dots.. IT's the TENTS!! WOW Great product and it's frre!!! http://earth.google.com/ Have a nice one Eric Gagnon, B.Sc., GIS Specialist - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 17809 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 17812 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 17813
RE: MI-L Closing Query 'tables'
Hi John, This will close all query tables in the front mapper: Include mapbasic.def Declare Sub Main Sub Main Dim t as SmallInt For t = NumTables() to 1 Step -1 If TableInfo(t, TAB_INFO_NAME) like Query% Then Close Table TableInfo(t, TAB_INFO_NAME) End If Next End Sub -Original Message- From: John Polasky [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 19, 2005 4:15 PM To: mapinfo-l@lists.directionsmag.com Subject: MI-L Closing Query 'tables' Listers- Is there a 'One-Size-Fits-All' method for closing ALL query/temp tables in mapbasic, regardless of the query number? Thanks -John - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18399 - List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 18400
RE: [MI-L] Wandering Text Problem
In case anyone is interested in why, technically speaking, this 'wandering text' problem occurs, Eric Blasenheim explained it a few years ago. See below. Tim Nuteson Target [From Eric Blasenheim]: It is not entirely clear to me that all the recent questions on label plotting all relate to the same issue. Some may be a result of misunderstanding how dynamic labels are composed. In particular, many people still think that labels in the Layout are supposed to be the same as those in the Map window. This is not correct. The labels, which are always sized using paper (Points) units, fit differently in the Layout paper space than they do in the Map Window which has only the screen connection. However, there is a bug in the layout label calculation that may be the source of a number of these inquiries. There is also a workaround until that bug is fixed. When the labels are composed, their location is determined by translating the label location of the object (usually the centroid) from geographic units into a location on the page. This location is then adjusted according to the nine label positioning and offset options and the text size which is determined by querying the operating system (Windows). Once these labels are located only changes in the label settings for that layer, the scale of the map or the size of the layout frame will cause the labels to be recomposed. A simple zoom change in the layout, will not cause this. It only changes the display size of all the labels. This is how it should be. However, when the screen display size of the labels is quite small, the conversions between geographic, screen and paper locations result in loss of precision resulting in the labels not being correctly located. Basically we are querying Windows with user point sizes (8, 10, 12 point) scaled down to 1 or 2 points. This commonly occurs with large size plots and/or small screen resolutions where a view which encompasses the entire layout results in very small on screen text sizes. The workaround is to force MapInfo Professional to recompose the labels when the screen size of the text is more reasonable. So, if you zoom in to the layout to where the text is readable and do any of the following the labels should recompose correctly: 1) Change any setting in the label settings dialog or the check box for dynamic label visibility at the first level of layer control. Obviously, if you choose to turn off visibility you will need to turn it back on again. 2) Run any of the MapBasic Set Map Layer Label commands from the MapBasic window. These are the same commands generated by the Layer control/Label settings dialogs. 3) Change any of the zoom/scale settings in the Change View dialog or the MapBasic commands that they generate. 4) Change the size of the Layout frame where the Map is contained via the Frame dialog or by dragging the frame corner or side. Also note that any workspaces that you save can automatically use this workaround by saving them at a Layout zoom where the text size is not too small! Opening the workspace causes the layout frames including the labels to be recomposed from scratch and if the viewed text size is reasonable, the correct calculations will occur. We are looking into a fix for this problem. Eric Blasenheim [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Thoen Sent: Wednesday, December 21, 2005 6:26 PM To: MapInfo List Subject: SUM: [MI-L] Wandering Text Problem Carl Schaefer got it one. Thanks! Here's the solution for getting labels to stay put when creating a large-scale Layout window: The way I correct the labelling problem is to: 1) View Actual Size in the layout 2) double click on the map frame and change the scale ever so slightly (say 1cm = 500m to 1cm = 500.01m) - also make sure the resize frame toggle is checked. 3) double click again and change the scale back to your original All labels are happy now. And I agree with you all -- why HASN'T this bug been fixed yet? In fact, if MapInfo needs some featues to add for the next release that will actually excite people and motivate them to upgade, why not fix all the layout bugs and add some features that will allow us to put a finish on our maps that makes them look like cartographic art rather than 'toons? Why not add antialiasing like what's in SVG? Why not text on a curve, and some of the smart street labeling that's in MapText's Label-EZ? Why not provide line styles where you can change both the inside AND outside color? Why not color gradational fills? How about vector layer translucense? How about finishing the cartographic legend utility? Whew! (got a little wound up there...) ___ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l ___ MapInfo-L mailing list
RE: MI-L
Travis- Select * from TABLE Where COLUMN / 2 = Int(COLUMN / 2) 'evens Select * from TABLE Where COLUMN / 2 Int(COLUMN / 2) 'odds Tim Nuteson Target Corporation -Original Message- From: Lathrop, Travis [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 2:43 PM To: '[EMAIL PROTECTED]' Subject: MI-L How would I type a SQL if I am looking to find all the odd/even integers in a particular column? Travis Lathrop Intercarrier Service 913/762-4806 ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body. ___ List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MapInfo-L" in the message body.
