Opened 17 years ago

Closed 17 years ago

#213 closed defect (fixed)

Bad labels

Reported by: jrizzo Owned by:
Priority: high Milestone: 2.0
Component: General Version: 1.2.0
Severity: critical Keywords:
Cc: External ID: 945351

Description

With the attached LayerDefinition, the labels look incorrect at certain scales. Zoomed all the way out or zoomed in really close, the labels look fine. Some scales (135 for example) show the labels as long numbers (pointer addresses, possibly?). An example of a bad label & a good label along with the sample data set will be attached. The feature source is an SDF feature source joined with an ODBC feature source (a SQL Server view). The ODBC feature source has been omited for security purposes. The labels contain values from the extended properties. This was working fine in 1.1.

Attachments (8)

bad.JPG (3.0 KB ) - added by jrizzo 17 years ago.
This is one of the "bad" labels
good.JPG (10.3 KB ) - added by jrizzo 17 years ago.
This is what the "bad" label is supposed to look like.
From_172-16-141-47_20070618_Defect.mgp (29.6 KB ) - added by jrizzo 17 years ago.
This package contains the layer definition & sdf feature source
FeatureSource.xml (581 bytes ) - added by jrizzo 17 years ago.
Here is the feature source definition with the username & password removed. You can modify the connection string as necessary for your testing
config.xml (49.5 KB ) - added by jrizzo 17 years ago.
Here is the config xml stream from the database feature source. This should contain enough information for you to reconstruct the view in your testing environment.
From_172-16-141-112_20070627_Defect.mgp (33.7 KB ) - added by jrizzo 17 years ago.
This package should demonstrate the problem at a display scale of 1:100
db.zip (245.3 KB ) - added by jrizzo 17 years ago.
The access database
From_172-16-141-112_20070629_Defect.mgp (33.6 KB ) - added by jrizzo 17 years ago.
Updated package

Download all attachments as: .zip

Change History (24)

by jrizzo, 17 years ago

Attachment: bad.JPG added

This is one of the "bad" labels

by jrizzo, 17 years ago

Attachment: good.JPG added

This is what the "bad" label is supposed to look like.

by jrizzo, 17 years ago

This package contains the layer definition & sdf feature source

comment:1 by rexszeto, 17 years ago

External ID: 945351

comment:2 by tomfukushima, 17 years ago

I cannot get the attached package to work because of the dependency on the joined data. Please attach a package that works and shows the problem. Thanks.

by jrizzo, 17 years ago

Attachment: FeatureSource.xml added

Here is the feature source definition with the username & password removed. You can modify the connection string as necessary for your testing

by jrizzo, 17 years ago

Attachment: config.xml added

Here is the config xml stream from the database feature source. This should contain enough information for you to reconstruct the view in your testing environment.

comment:3 by jrizzo, 17 years ago

I have updated two files that should help - the feature source definition and the corresponding config.xml. It may be quite a bit more difficult to post the actual database view that I am using...?

comment:4 by tomfukushima, 17 years ago

Hi,

What I am looking for is the ability to load a package and then see the problem. Unfortunately, I don't have the resources to try to recreate the problem. Trying to recreate the problem has the issue of: we won't know for sure when to stop if we cannot recreate the problem. With this in mind, please help us by creating a self-contained package that we can load and show the problem.

I know that this is not always easy, but your help is greatly appreciated.

Thanks Tom

comment:5 by tomfukushima, 17 years ago

Just as a further note, I'm not expecting the SQL Server to be attached, but perhaps it may be possible to take a sample out of the SQL Server and put it into an Access database, and recreate it that way.

by jrizzo, 17 years ago

This package should demonstrate the problem at a display scale of 1:100

comment:6 by jrizzo, 17 years ago

Severity: majorcritical

I have uploaded a package which should reproduce the defect using an Access database. Please let me know if I can provide additional information. Incidentally, the Access version of this layer is considerably faster than the SQL Server version that I am currently building. In Access, it is lightning fast, and in SQL Server it is almost unuseable. I think (hope) this performance difference is already logged as a defect but I am not sure.

comment:7 by chrisclaydon, 17 years ago

Would you be able to attach the Access database file you're using? If that poses a security problem, perhaps you could create a small mdb file with some fictitious data that can be used to reproduce the problem.

Thanks, Chris.

by jrizzo, 17 years ago

Attachment: db.zip added

The access database

comment:8 by jrizzo, 17 years ago

Sorry, I assumed that it would have been included in the package, but I guess I wasn't thinking. I just uploaded the file. Thanks.

comment:9 by rexszeto, 17 years ago

Hi, I've been trying to reproduce this, but have been unsuccessful so far. The SDF and Layerdef from the package came with some invalid data (mainly caused by the join fields). I've tried adjusting the values and the preview in layer def showed the labels are working fine.

Can you please make the correct changes to the package so we are able to load the package and see the problem?

Some problems I've come across:

  • The SDF feature source gives an error "Resource was not found: Library://Langan Floor Plans/Data/Database/Floor Plan Database.FeatureSource". I fixed this by changing the source field for the Room Join.
  • The secondary class for 'Room\' is not specified due to the incorrect source (from above). I re-directed it to the correct database (Library://Defect/Floor Plan Database.FeatureSource) and chose "Default:Floor" as the secondary class.
  • The columns to match the table + secondary class are missing from both Employee\ and Room\. For both joins, I matched up the FloorIds.
  • The layer definition was not able to find the feature source, (Due to point 1, see above). I correct it by directing it to a working feature source, but however, the feature class and labels were all set to default. This was where I tried defining the labels for the "Schema1:Office Data" class and they all show up fine.

If there's anything else missing, please include it in the new mgp.

Thanks, Rex.

by jrizzo, 17 years ago

Updated package

comment:10 by jrizzo, 17 years ago

apologies for the ties to my live data. I have uploaded an updated package with these dependencies removed - the only change that should be necessary on your end is to modify the database connection string with the correct path to the .mdb

With the latest version, I tried reproducing the issue by zooming to exactly 1:100 and the problem does not seem to happen at that scale. however, after panning and zooming in and out a little bit, the labels eventually go bad. I can't find an exact location or scale that causes it, but it usually only takes a few seconds of navigating around for the labels to go bad.

in reply to:  10 comment:11 by jrizzo, 17 years ago

Was this behavior ever reproduced, or do you need something more from me?

comment:12 by rexszeto, 17 years ago

This important issue have been reproduced and will be addressed. Apologies for the delay.

comment:13 by tomfukushima, 17 years ago

Milestone: 1.21.3

comment:14 by jbirch, 17 years ago

Priority: mediumhigh

comment:15 by jbirch, 17 years ago

Hey jrizzo, have you had a chance to test this with the 2.0 RC4 build yet? There have been many fixes to the join code that may have affected this.

comment:16 by jrizzo, 17 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.