Retina XYZ tile support

[jumpinjackie]

We have an implementation of XYZ tiles that works across many different versions of MapGuide (even versions before 3.0, where XYZ tile support was first introduced).

Extend this support to support "retina" XYZ tiles. Based on what I've read, "retina" XYZ tiles are basically tiles rendered in the same bounding box for a given XYZ tile coordinate, but the actual tile size is a multiple of the original tile size.

For example, a 2x retina tile will by 512x512 pixels. 4x would be 1024x1024 pixels.

Initial plan

Add a new route variation for retina xyz tiles:

/library/{resourcePath}.MapDefinition/xyz@{scale}/{groupName}/{z}/{x}/{y}/tile.{format}

This will render an XYZ tile, but it will be retina tile of the specified {scale}

For example, this will render a 512x512 (2x) retina tile

GET /library/Samples/Sheboygan/MapsTiled/Sheboygan.MapDefinition/xyz@2/Base Layer Group/13/2100/2985/tile.png

[begu24]

Great, works as expected. The only issue is the size of the styles (lines, lables, points). I guess that this is something that must be implemented in MG Server (via a dpi setting?) and cannot be accomplished via the rest webservice, since the RenderMap methode doesn't support such a setting. Is this correct?

[jumpinjackie]

We can mutate the DPI of the MgMap (SetDisplayDpi exists), so I've tried scaling the current map DPI with 400ffd5

Let me know how this goes.

[begu24]

Yes, looks much better now! Except the linestyles. You can see it when you compare your sampleapps. The one with double sized tiles had fainter lines (e.g. the border of the parcels). But I think that this behaviour was never implemented in MG since the beginning of MGOS. And I don't know how other map server (GeoServer, MapServer, etc.) behave on this issue.

[jumpinjackie]

I think this is expected is it not?

Say a layer definition specifies lines have a 3px thickness (constant value). 3px thick lines would definitely look fainter on a 512x512 tile than on a 256x256 one. They wouldn't automatically become thicker just because we're rendering a bigger tile.

Edit: I mean fainter when the 512x512 tile is "squished" down to 256x256 on a map viewer.

[flipper44]

I know I handled this in our viewer, I will check how a did it, I think I set each tile layer to device doing and had to do something special in mapguide openlayers layer

On Feb 9, 2018 7:00 AM, "Jackie Ng" notifications@github.com wrote:

We have an implementation of XYZ tiles that works across many different versions of MapGuide (even versions before 3.0, where XYZ tile support was first introduced).

Extend this support to support "retina" XYZ tiles. Based on what I've read, "retina" XYZ tiles are basically tiles rendered in the same bounding box for a given XYZ tile coordinate, but the actual tile size is a multiple of the original tile size.

For example, a 2x retina tile will by 512x512 pixels. 4x would be 1024x1024 pixels. Initial plan

Add a new route variation for retina xyz tiles:

/library/{resourcePath}.MapDefinition/xyz@{scale}/{ groupName}/{z}/{x}/{y}/tile.{format}

This will render an XYZ tile, but it will be retina tile of the specified {scale}

For example, this will render a 512x512 (2x) retina tile

GET /library/Samples/Sheboygan/MapsTiled/Sheboygan.MapDefinition/xyz@2/Base Layer Group/13/2100/2985/tile.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jumpinjackie/mapguide-rest/issues/181, or mute the thread https://github.com/notifications/unsubscribe-auth/APQv97k6pkWsdfOUcrorP3R5EBHFx4avks5tTEFUgaJpZM4R_40P .

[begu24]

From my understanding this is only expected when using the same dpi setting. But that's just my opinion.

I've found this hdpi map of osm data. When you compare one of these tiles with on from openstreetmap.org you can see that also the linestyles (ways, Buildings, etc.) were scaled: tile_256; tile_512

Of course, it could be that the creators of this hdpi tiles adjusted the styles before rendering them. So, there may be some other reasons that would explain why it is implemented in MG the way it is. And maybe it is the correct way of doing it.

[jumpinjackie]

Since size can be expressed in terms of an FDO expression for most style settings, you could take my hypothetical line layer and instead of having a constant size value of 3 pixels, it could be an FDO expression something like:

3 * (MAPDPI() / 96)

Then you would have a layer whose line thickness dynamically scales with the map dpi.

This assumes:

• DPI of retina tiles scales along with tile size (2x tile size -> 2x DPI). 400ffd5 makes this assumption.
• We actually have FDO expression stylization function MAPDPI that returns the DPI of the map currently being rendered. I don't know if this function exists. If it doesn't, we should get it implemented in MapGuide proper.

[begu24]

I must correct myself: Scaling of line styles for different dpi already works. I had set the "size context" of my style to map space instead of device space. After setting it to device space the width of my line was scaling with the factor of the retina tiles. So, correct behaviour here.

The reason why the Sheboygan map gets also fainter lines is that they were also misconfigured. The size context of the styles (e.g. parcels) was set correctly to "device space". Unfortunatly the line width was set to 0. So, that has to be fixed in the Sheboygan dataset.

Nevertheless, I think that your proposal for a new FDO expression function could be helpful. I guess that not every style is scaled correctly when applying a greater dpi value. Apparently line styles in symbols:

1. I found that the line width setting in the builtin symbols (circle, triangle, square, etc.) has no effect, no matter whether the symbols size context is set to map or device. I would assume that this setting, if it works, would scale in respect of the dpi setting and independent of the "size context".

2. Same for SimpleSymbolDefinitions/CompoundSymbolDefinitions. Resizing of lines works when the symbols "size context" is set to device but does not work for map space as I would assume (tested with map sized symbols)

[jumpinjackie]

Ok since the "problems" now appear to be mis-configuration in various layer definition settings, I'll consider this implementation complete.

@begu24 Also, if you could attach a "fixed" version of the Sheboygan Parcels layer here, I can look to incorporate it into the official dataset for the next MapGuide release.