[mapguide-internals] Dynamic tile rendering proposal
Paul Spencer
pspencer at dmsolutions.ca
Thu Jul 31 11:27:31 EDT 2008
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/
More information about the mapguide-internals
mailing list