Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#792 closed defect (wontfix)

Excessive labeling with tiled maps

Reported by: zspitzer Owned by:
Priority: medium Milestone:
Component: Rendering Service Version: 2.0.2
Severity: critical Keywords:
Cc: External ID:

Description

Tiled maps get excessive ugly labels generated, attached are two screen shots, both with a debug tile overlay showing the tile grid ( at 600px )

One map is dynamic GETMAPIMAGE and one is tiled GETTILEIMAGE

Attachments (2)

dynamic_map_labels.png (298.9 KB ) - added by zspitzer 15 years ago.
tiled_map_labels.png (289.9 KB ) - added by zspitzer 15 years ago.

Download all attachments as: .zip

Change History (6)

by zspitzer, 15 years ago

Attachment: dynamic_map_labels.png added

by zspitzer, 15 years ago

Attachment: tiled_map_labels.png added

comment:1 by zspitzer, 15 years ago

BTW I used a larger tile size to see if the tile size was playing an issue with the labelling, but as can be seen from the images this is not the case

comment:2 by waltweltonlair, 15 years ago

With GETMAPIMAGE we can stitch together features across the entire image that are connected end-to-end and want the same label, and generate a single label for the resulting stitched feature - Moray Street in your attached images is a good example. I can see from the stylization that each block of Moray Street is actually a separate feature. The stitching code merges the geometry for all the features and uses the merged geometry when computing the label. That results in the single label you see.

With GETTILEIMAGE, we can only consider features that intersect the tile. This is a requirement of the local labeling algorithm used to generate labels for tiles: since each tile is rendered independently it can only depend on data local to that tile (this is necessary to avoid the problem where you have discontinuous labels across tile boundaries). Therefore features that don't interest a tile are not accounted for when generating the labels. Stitching is still done for features local to that tile (and in fact it's done only on features fully contained within that tile), but it will not occur across tiles. The result is what you're seeing in your tiled image: a candidate label is generated for every block of Moray Street - no stitching of the road is occuring.

Changing the tile labeling algorithm to be non-local would allow stitching to occur the same as in GETMAPIMAGE. However, if we allow labels in tiles to depend on data outside their extent then the only way to guarantee no discontinous labels across tile boundaries is to ensure that every tile works with the same data set - it would have to be the entire data set for the map. Obviously that's going to kill performance.

A compromise is to use a much larger size when generating tiles - on the order of the screen size - and then cut up this large tile into the normal 300x300 size we use in the viewer. Because each generated tile is large the stitching can be more effective. There have been some past discussions around this on the newsgroups.

Another possibility is to precompute the labels once for the entire map: load in the entire data set for the map, generate all labels, and store this information somewhere. Then when we generate tiles we just look up the labels. The initial label generation will be time-consuming, however. There's also the problem of how and where to store the information. If you have multiple servers in your MapGuide site then each one needs access to the generated labels.

A final option is for you to clean up your data. For example with Moray street, if you combine all the individual features into one then you will get a single label in your tiled map.

comment:3 by jbirch, 14 years ago

Resolution: wontfix
Status: newclosed

That sounds like a "won't fix" to me...

in reply to:  3 comment:4 by gmele, 13 years ago

Replying to jbirch:

That sounds like a "won't fix" to me...

Have you found any solution to this problem? I tried to enlarge the size of the tile but does not change. Moreover, the repetition of labels is within a single tile for each segment. The other solution proposed by zac, "combine all the individual features Into one" do not understand. I've tried to feature a single source of streets and the result is the same.

My test results are more acceptable GETMAPIMAGE (not repeated so much) that GETTILEIMAGE, but I have to use tiles for obvious reasons of performance.

Thks!

Note: See TracTickets for help on using tickets.