[mapguide-internals] Dynamic tile rendering proposal

Thu Jul 31 14:07:01 EDT 2008

Another important difference between tiled and non-tiled rendering requests is that features are not clipped in tiled requests.  This is in addition to having an "outer bounds" greater than the image bounds.  This will also affect performance.  Besides for proper labeling, the lack of clipping is needed so that line patterns / area hatches are continuous across tiles.

-----Original Message-----
From: Walt Welton-Lair
Sent: Thursday, July 31, 2008 12:17 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Dynamic tile rendering proposal

TileExtentOffset is currently only used for GETTILEIMAGE

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Thursday, July 31, 2008 12:12 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Dynamic tile rendering proposal

Does the serverconfig.ini  TileExtentOffset = 0.35 affect GETMAPIMAGE
or only for GETTILEIMAGE?

like GETTILEIMAGE with no base_layer group? to renders tiles of
everything in a dynamic map.
acting as RenderOnly=1 for such requests

Tho, as soon as you start to increase the tile count, the IO & CPU
required to make the maps goes up
and up. This will be compounded as the overlap extent is increased.

Assuming a 900pxx900px map with 300px tiles, that is now at least 9
requests and
9 times the IO as a single dynamic map image request, increasing the
buffer just means
your processing more and more data again and again.

That's where meta tiling comes to the rescue, those 9 tiles get
rendered once as
a 1500x1500 pixel tile and then cut up into the 9 tiles and served.

z

On Fri, Aug 1, 2008 at 1:27 AM, Paul Spencer <pspencer at dmsolutions.ca> wrote:
> I don't think that WMS will work for Kenneth's use case, specifically he
> wants to be able to request a tile as if it was being rendered and cached
> which implies a couple of changes in the rendering logic:
>
> * labels are positioned taking into account a large extent
> * polygons that intersect but are not contained within the extent are not
> automatically closed (I think that you get a neat line on the edge of a map
> draw right now).
>
> A problem I perceive with this is that labelling correctly for a larger
> extent may cause either visual or performance problems depending on how it
> is done - either you need more features to take into consideration label
> collisions or you run the risk of labels overlapping.
>
> Consider the case where you have two point features near adjacent edges of
> two different tiles - if you don't request the points from adjacent tiles
> but allow the label to go over the edge of the tile then you can have a
> problem of labels overlapping.  But if you request nearby points, you are
> going to have a potentially serious degradation in performance.
>
> One can imagine similar situations with lines, polygons etc where features
> that are not in the currently drawn extent can influence label positioning
> when rendering in the context of a larger map draw.  This can probably be
> mitigated by trying to find a sweet spot between requesting features that
> intersect a slightly larger extent and minimizing the number of features to
> be considered when rendering.
>
> I somehow doubt that you will be able to render tiles dynamically
> significantly faster than requesting a singleTile overlay, I suspect that
> enough overhead happens in setting up for a map draw that a dynamic tile of
> 256 x 256 would not be a lot faster.  But then again, I could be wrong :)
>
> Cheers
>
> Paul
>
> On 31-Jul-08, at 10:57 AM, Zac Spitzer wrote:
>
>> I think WMS would work fine for that, if it supported mapDefinitions.
>> You would call the session resource url
>>
>> z
>>
>> On Fri, Aug 1, 2008 at 12:53 AM, Kenneth Skovhede, GEOGRAF A/S
>> <ks at geograf.dk> wrote:
>>>
>>> Yes, but without storing the cache files, and run on the entire runtime
>>> map,
>>> not just the baselayers.
>>>
>>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>>
>>>
>>>
>>> Zac Spitzer skrev:
>>>>
>>>> So like the GETILEIMAGE result via the GETMAPIMAGE parameters?
>>>>
>>>> On Fri, Aug 1, 2008 at 12:12 AM, Kenneth Skovhede, GEOGRAF A/S
>>>> <ks at geograf.dk> wrote:
>>>>
>>>>>
>>>>> That might get what I want, assuming that WMS actually handles the
>>>>> splitting
>>>>> correctly.
>>>>> But that would also remove any possibility to work with the runtime
>>>>> map,
>>>>> which is required
>>>>> to handle selections, so unfortunately that does not work.
>>>>>
>>>>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>>>>
>>>>>
>>>>>
>>>>> Zac Spitzer skrev:
>>>>>
>>>>>>
>>>>>> How does exposing mapDefinition's as WMS sound as a solution?
>>>>>>
>>>>>> On Thu, Jul 31, 2008 at 11:02 PM, Kenneth Skovhede, GEOGRAF A/S
>>>>>> <ks at geograf.dk> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> As I understand meta tiling, it works by creating a larger image than
>>>>>>> the
>>>>>>> one requested (smaller),
>>>>>>> in anticipation of requests to similar/adjacent (smaller) images.
>>>>>>>
>>>>>>> In a sense, that is what I want, but I would request the larger
>>>>>>> image,
>>>>>>> and
>>>>>>> retrieve the sub-tiles.
>>>>>>> Unlike meta-tiling, the purpose of this feature is not to create
>>>>>>> extra
>>>>>>> data
>>>>>>> in advance,
>>>>>>> but rather serve a large image in smaller chunks.
>>>>>>>
>>>>>>> If the server renders the entire image and just hands out the smaller
>>>>>>> images, I would not
>>>>>>> expect the percieved transmission time to diminish, as the crucial
>>>>>>> part
>>>>>>> is
>>>>>>> the time that goes
>>>>>>> before the initial image is displayed.
>>>>>>>
>>>>>>> From a users perspective, a long but visible progress, is better than
>>>>>>> a
>>>>>>> shorter uncertain wait.
>>>>>>> (Within certain bounds of course)
>>>>>>>
>>>>>>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Zac Spitzer skrev:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Kenneth, do you think meta tiling could also solve this problem?
>>>>>>>>
>>>>>>>> On Thu, Jul 31, 2008 at 7:20 PM, Kenneth Skovhede, GEOGRAF A/S
>>>>>>>> <ks at geograf.dk> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The current tile mechanism is using static images to serve
>>>>>>>>> pre-built
>>>>>>>>> images
>>>>>>>>> as tiles.
>>>>>>>>> For this reason, the tiles are only usefull with "base layers".
>>>>>>>>>
>>>>>>>>> I have worked with OpenLayers, and it has a very nice tiling
>>>>>>>>> mechanism.
>>>>>>>>> DM Solutions have built some tiling support into the MapGuide
>>>>>>>>> provider
>>>>>>>>> for
>>>>>>>>> OpenLayers.
>>>>>>>>> This uses the static tiles, and the row/column index system in
>>>>>>>>> MapGuide.
>>>>>>>>>
>>>>>>>>> Using the "original" OpenLayers tiling mechanism one can get a
>>>>>>>>> dynamic
>>>>>>>>> MapGuide image
>>>>>>>>> to load as tiles, giving the illusion that the page loads faster
>>>>>>>>> (when
>>>>>>>>> it
>>>>>>>>> actually loads a bit slower).
>>>>>>>>>
>>>>>>>>> The problem with this method is that MapGuide optimizes the
>>>>>>>>> rendered
>>>>>>>>> image
>>>>>>>>> for the given bounds.
>>>>>>>>> This is especially true for calculating label positions and
>>>>>>>>> overlaps.
>>>>>>>>> I would like to add a parameter for the "GETMAPIMAGE" call that
>>>>>>>>> accepts
>>>>>>>>> an
>>>>>>>>> "outer bounds" parameter.
>>>>>>>>>
>>>>>>>>> With this parameter, MapGuide should render the extent given by the
>>>>>>>>> extent
>>>>>>>>> parameter, but use the outer
>>>>>>>>> bounds for determining label placements and any other details that
>>>>>>>>> may
>>>>>>>>> have
>>>>>>>>> the same problems.
>>>>>>>>>
>>>>>>>>> With this, it would be possible for MapGuide to serve tiles from
>>>>>>>>> MapGuide,
>>>>>>>>> without relying on a
>>>>>>>>> static tilcache.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would like to add this as an RFC, but would like feedback on the
>>>>>>>>> idea,
>>>>>>>>> as
>>>>>>>>> well as possible problems.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> mapguide-internals mailing list
>>>>>>>>> mapguide-internals at lists.osgeo.org
>>>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mapguide-internals mailing list
>>>>>>> mapguide-internals at lists.osgeo.org
>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mapguide-internals mailing list
>>>>> mapguide-internals at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>
>>
>>
>> --
>> Zac Spitzer -
>> http://zacster.blogspot.com (My Blog)
>> +61 405 847 168
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
> __________________________________________
>
>   Paul Spencer
>   Chief Technology Officer
>   DM Solutions Group Inc
>   http://www.dmsolutions.ca/
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals