Autodesk MapGuide Bugs

Bugs introduced with MapGuide 6.5 SP1

• Two MapGuide 6.5 SP1 version numbers were released with the same function. The .exe installation file is version 6.5.6.11. The .cab file is version 6.5.6.12. This is the result of an anomaly with Autodesk's build process.
• In some cases the MapGuide legend is refreshed more often than it does with older versions, resulting in considerable annoying legend "flashing" as it rebuilds. This legend refreshing may also make map updates take longer.
• Using the MapGuide Viewer version 6.5 SP1, some Zoom Goto's don't work and return "Unable to locate matching feature(s)" when the object exists and should have been found. (After these bugs were found, we learned there are two 6.5 SP1 versions released, 6.5.6.11 and 6.5.6.12. These bugs are reproducible on with the 6.5.6.11 version. As the two versions are supposed to be functionally identical, the bug should be in both versions.) Failing Zoom Goto categories appear to fail for all values except the IMS ID which incorrectly returns "The location does not fall within this map window." for some values. There may be two Zoom Goto bugs, but the workaround described here resolves both zoom goto problems. These problems occurred with the version 6.5SP1 Viewer in conjunction with the original version 6.5 Server (not SP1).

  Workaround

  The best workaround we've found is to append a non-breaking space character as the first character to be returned by the select statement, by appending a leading chr(160) as shown in this example:

  select chr(160) + parcel + ' ',lat,lon,lat,lon from landbase
    where parcel like trim(ucase('%s%%')) order by parcel

  chr(160) is appropriate for DBF queries. SQL Server queries should use char(160) as the SQL Server function name is different.

  Discussion

  Experimenting and testing shows that zoom gotos fail when the contents of the zoom goto's SELECT statement first returned field in any of the returned records begins with one or more numeric characters. The zoom goto works if the first SELECT fields begins with an alphabetic character (among many others) for all returned records. When more than one record matches the zoom goto request, the contents of this field are displayed for the user to choose the map object they want to zoom to.

  By "first returned field" we mean the string data returned by everything after "select" and before the first comma as indicated with bold in the following sample zoom goto SQL statements.

  select parcel + ' ',lat,lon,lat,lon from landbase
    where parcel like trim(ucase('%s%%')) order by parcel

  select street_all,lat,lon,lat,lon from stinters
    where street_all like ucase('%s%%') order by street_all

  select str(street_no) + ' ' + street_dir + ' ' + street_nam,lat,lon,lat,lon from adparcel
    where street_nam like trim(ucase('%s%')) order by street_nam,street_no

  If a non-breaking space character, literal alphabetic character, underscore, or any of many other characters (except blanks and nulls) is added ahead of the string, the zoom goto works but displays the unwanted character. HOWEVER, unlike other characters that make it work, the non-breaking space still appears as just a space (and a narrow one at that since it's a proportional font). For example, these SQL statements make the zoom gotos work when the string would otherwise start with a numeric character: (Of course we don't want to see leading X's or even underscores in the displayed result list.)

  select chr(160) + parcel + ' ',lat,lon,lat,lon from landbase
    where parcel like trim(ucase('%s%%')) order by parcel

  select 'X' + parcel + ' ',lat,lon,lat,lon from landbase
    where parcel like trim(ucase('%s%%')) order by parcel

  select '_'+street_all,lat,lon,lat,lon from stinters
    where street_all like ucase('%s%%') order by street_all

  select str(street_no) + ' ' + street_dir + ' ' + street_nam,lat,lon,lat,lon from adparcel
    where street_nam like trim(ucase('%s%')) order by street_nam,street_no

  This SP1ZoomGotoBug.mwf MWF file demonstrates the problems for these Zoom Goto categories below and possibly other Zoom Goto categories as well. Indicated values are just sample values to try. If you try the these MWF Zoom Goto's with the version 6.5SP1 Viewer they fail. If you try them with the version 6.5 Viewer, they work.

  This SP1ZoomGotoBugFIX.mwf MWF file demonstrates the workaround of appending a non-breaking space character, decimal 160 or hexadecimal A0 entered as chr(160), ahead of the these Zoom Goto categories. This sample MWF works with both base 6.5 Viewer and the version 6.5SP1 Viewer.

  • Owner Name -- "SMITH" fails. (The returned strings all start with numeric parcel code characters.)
  • IMS ID (Sanitary Sewer Manhole ID) -- "8419-01" and many others work. "50-17" incorrectly returns "The location does not fall within this map window." "1703-03" has failed the same way but sometimes works.
  • St. Intersection (Enter one name only) -- "STONE" fails. (The returned list of intersection streets includes some streets starting with numeric characters. I.E. "1ST ST / STONE AV")
  • Street Name (DSD Situs Address) -- "STONE" fails. (The returned string starts with the street number. I.E. 201 N STONE AV
  • Street Number (DSD Situs Address) -- "201" fails.
  
  

  Some of the Zoom Goto's work while others fail. Here are a few Zoom Gotos that work in either MWF map with both the version 6.5 and version 6.5 SP1 Viewer:

  • Parcel Code (9 or less char. No dashes.) -- "11720012A" works. (Not sure why this works since it begins with numeric characters.)
  • Libraries (Enter * for a complete listing) -- Entering "*" without quotes works. (All returned values start with alphabetic characters.)
  • School Name -- "Dietz" works.
  • Street Name (Street Network) -- "STONE" works.
  • Township Range Section - (TTRRSS) -- "131313" works. (The actual returned string begins with an alphabetic character, "E131313")

Bugs and problems that are good version 6.5 "service pack" candidates

• (High priority) Not all features of the MapGuide Viewer work with dual displays where the desktop is extended across both displays. This appears to be a problem only when the primary display is on the right. When the map is on the "extended" display, layers and groups cannot be clicked on or off in the legend, making MapGuide essentially unusable with the second display. Verified with MapGuide Viewer 6.5 ActiveX control and plug-in. Fails with both ATI and nVidia display cards and drivers, indicating the problem is likely in the MapGuide Viewer and not the display subsystem. (Added 1/3/2005 and submitted to Autodesk via the web on 1/3/2005. Added comment about primary display location 1/31/2005)
• (High priority) The Google Toolbar interferes with the MapGuide Viewer 6.5 ActiveX control, causing Internet Explorer to crash with an error when closing Internet Explorer (i.e. when Internet Explorer exits). The crash can be avoided by navigating away from the MapGuide map to another page (try the browser's Back button) and then closing Internet Explorer. While we don't know if the problem cause is Google's or Autodesk's, it is a frequent frustration for users and a common complaint.
• (Medium priority) Double-clicking for URL link also selects the feature. It shouldn't. Single-click and double-click should be entirely separate functions as we believe they were in earlier MapGuide releases. It just confuses users and misrepresents themed values when a color changes as the result of a double-click.
• (Medium priority) When one filled polygon layer with labels is covered (or "hidden") by another like layer over it, the labels from the layer underneath are still visible. (Added 10/29/1998. Graphic added 6/9/2003.)

  You can see this on our MapGuide map by clicking here and seeing the problem with the Multiple Listing Service Areas and Supervisor Districts layers. You may need to zoom to the same scale of 1:172,556 to see exactly the same thing. None of the Supervisor District labels (names) should be visible as the Supervisor Districts layer is under the Multiple Listing Service Areas layer.

  

  

• (Low priority) The Copy tool fails to copy all the screen data when the displayed map includes a large quantity of dense vector data. Fortunately, there are workarounds for this problem. Certainly screen capture programs such as Snag-It will do the job, as will simply using Alt and the Print Screen key to put the whole active window on the clipboard. With Alt/PrintScreen you can then use Microsoft Paint or other image software to clip off the portion of the captured window around the map image itself. (With Snag-It you can do this at the time of capture.) These results should be every bit as accurate and good as using the Copy->Copy Map function built in to the MapGuide Viewer. (Added 1/17/2007)
• (Low priority at this time) In rare and random cases, the MapGuide Viewer fails to display one or more layers in the legend. This is not simply an error or problem with visibility by scale as it occurs with a group or layers defined as visible at all scales. It's not known what the catalyst is for dropping a layer but it seems to be unique to certain computers. One user reported that the Unzoom tool will bring the missing layer back and even works when using Unzoom from the initial map view with no change in the scale or displayed map. As we've only seen this with layers or groups that are off by default, it's not known if the problem is only affecting the legend or also affecting the layer on the map if the layer would be set to be visible by default. We don't know how to consistently reproduce this problem for further analysis. (Added 1/17/2007)

Other bugs and problems not likely to be 6.5 "service pack" candidates

These bugs may deal with inherent architectural issues or are big changes. As such, they aren't likely candidates.

Note that some of these problems may also exist in MapGuide Enterprise, although we haven't tested against the latest version. They are probably not good version 6.5 "service pack" canditates because they may require major code re-write or design changes.

• Annotation position errors. Polygon annotation seems to be placed at the centroid which is often outside the polygon. This can result is the wrong label being used to identify an area. (Originally added about 1998. Graphics added 6/9/2003.)

  You can see this on our MapGuide map by clicking here and obseriving the Supervisor Districts layer. The only correct label displayed is that for SHARON BRONSON. You may need to zoom to the same scale of 1:7,741 and adjust your window to the size displayed here to see exactly the same thing. Rebuilding the Supervisor Districts layer may cause more labels to appear (which is another strange anomaly).

  

  

  The problem can be even more severe as shown in this next example. Since labels may sometimes block other labels, there are situations where the desired label is obscured and only the wrong label is displayed. In this example, note that the green area is actually supervisor ANN DAY, not SHARON BRONSON as labeled. You may be able to see this on our MapGuide map by clicking here and observing the Supervisor Districts layer. It may help to zoom to the same scale of 1:18,152. If you see two supervisor district labels, try panning carefully until one of the labels is under a major road label, while the other is still visible. Depending on how you pan, you can probably obliterate either the correct label or the incorrect label.

  

  

• Sometimes map tip text is cut off on the right. Sometimes you can see part of the last character, but the rightmost part of the last character is truncated or missing altoghether. For example, if the word "PROPERTY" is the longest map tip line, then most of the "Y" will be cut off. In the examples below, the first map tip shows "S RICHARD ASHLEY C" which should be "S RICHARD ASHLEY CI". The second map tip shows "E CAMINO DEL GARANO" which should be "E CAMINO DEL GARANON". In both cases the correct text can be seen on the street name labels on the map. In some cases we worked around this problem by adding blanks after the field text. This shouldn't be necessary. (Added 1/16/2002 and submitted to Autodesk via the web on 1/18/2002). Autodesk investigated the problem, was unable to reproduce it, and dropped the problem.
• The selobjs MWF URL parameter causes only one map feature to be selected when more than one displayed map feature has the same identifier. This may not be considered a MapGuide bug since the map identifiers should be unique. If the browser window is resized manually, then the redraw causes all map features with the passed identifier to be selected. For example, see http://gis.pima.gov/maps/mapguide/mainmgmap.cfm?lat=31.74997440342&lon=-110.518755467&width=2499.81606367&units=ft&selobjs=Landbase,306340690 where you can use the map tips to see that several other circular area have the same parcel code as the selected area. (Added 12/2/2002 and submitted to Autodesk via the web on 12/2/2002)
• The legend may show an incorrect "layer" when all group layers available at the current scale are not "visible" and have "Show label in Viewer Legend" turned off. It seems that when all of a group's layers available at a given scale are set to not show in the legend, the Viewer logic for displaying the group line doesn't get the message. It thinks it should still display the group line. But it doesn't have any layers that are visible, so it somehow finds the cartegraphic data (such as point or theme representation) for a layer that would have been available at the current scale and shows that under a "layer" with the group name. As long as a real layer is shown in the legend or are zoomed to a scale where one or more group layers could be shown (whether set to visible or not), then it's OK. But, when you are in the twilight zone between having layers shown and zoomed to where no layers should be shown, and you have layers set to not show in the legend that are defined for that scale, then we get the junk. The bogus "layer" displayed displays the name of the group with cartegaphic info for one of the group's layers. (Added 3/3/2008)
• Selecting point map features by area uses the displayed symbol size rather than a true point. If the user selects map features within an area (Select Radius, Select Polygon, or Select Map Objects Within Selected Map Objects, or Select Layer Within Buffer) point-type map features are selected based on the displayed point symbol area, rather than a true point. That is, if any part of the displayed point symbol touches or is within the selection area then the point is selected, even if the point X,Y (usually in the center of the symbol) is outside of the selection area. For points that are near enough to the edge of the selection area that the symbol touches or is intersected by the selection area, then those points are selected, whether or not the true point X,Y is within the area.

  This results in the selection of unintended points that are outside of the selection area. The same selection area results in different numbers of points selected at different map scales because the ground area covered by the points symbols varies with scale. Since selections within areas (such as within buffers) are usually used for reporting or analysis purposes, the additional extraneous point features selected can cause dramatic errors in the reported results. Different users who follow the same selection or buffer procedures may get different results because their maps are not displayed at the same, exact scales. An individual user who repeats the process will also get differing results due to a potentially different map scale. 

  Initial map view	Select parcel	Select Map Objects Within Selected Objects (Selected 5 point features)

  Zooming in closer shows that only one of the 5 selected map features is actually within the parcel and should have been the only point selected.

  
  

  (Added 4/22/2011)