[mapguide-internals] Dynamic tile rendering proposal

Zac Spitzer zac.spitzer at gmail.com
Thu Jul 31 12:12:20 EDT 2008


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


More information about the mapguide-internals mailing list