[mapguide-internals] MapGuide Comments
Kenneth, GEOGRAF A/S
ks at geograf.dk
Thu Sep 13 03:22:47 EDT 2007
I agree with your view that there should not be duplicates of data.
I also believe that the client should be stateless (oposite of you I
think?).
My reason for this is that all manipulation of the map is done on the
server.
If there is some state on the client (as there is now), it is sometimes
necessary to perform:
Client Event -> Server Action -> Client Feedback -> More server ->
Client feedback
If all states are on the server, this would never be needed.
Someone already pointed out that a server session is necessary for
keeping temporary markuplayers and the like.
The reason that the map state is also stored in the session is speed (in
my best guess).
It is not stored as an Xml, but a binary version of the MapDefinition,
with added info.
The map's layers gets info from the LayerDefinition (featuresource,
geometrycolumn, etc), so there is only one
repository access when manipulating the map.
I have mentioned before that this is a bad solution, as the format of
the binary Runtime Map, is heavily tied to
the internal structures and constants in the MapGuide server code. This
makes it very inacessible without using
the existing API wrappers. My RFC# 21, is an attempt to fix that
problem, but I have a feeling that your REST model will
perform this and more.
The method for storing the binary Runtime map, is creating an empty Map
resource (not MapDefinition).
The Map contains <Map />, but has attached a ResourceData file, that
contains this binary format.
I also feel that this is not a pretty way to implement it, but it works.
This approach means that it is possible to store multiple views on a
map, either by different dummy resources,
or by multiple resourcedata files. I am not aware of how well the client
is able to cope with this, but I know that the
server has the ResourceData filenames hardcoded.
I think that the client data is mainly thought of as a way of decreasing
server calls. It keeps a list of visible
layers, current zoom etc.
I hope that makes sense, and can help you decide what to do with the
sessions.
Regards, Kenneth, GEOGRAF A/S
Haris Kurtagic skrev:
> Keeping additional data in session sounds ok.
> Keeping Map state is something I am not sure off.
> To keep state in two places client and server doesn't sound right.
> Also, there could be use case where several different views (Map State)
> on same Map/Sesssion data would be implemented.
> I am trying to understand implication's of Map/Session design and thank
> you for your help.
>
> Haris
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Robert
> Bray
> Sent: Thursday, September 13, 2007 5:32 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide Comments
>
> Right and it is not just buffers. Any kind of spatial analysis typically
>
> leads to temporary data. Redline/markup and/or live data edit would also
>
> typically be kept in a session until the user was ready to save or
> commit their changes to a permanent data store.
>
> Also keeping map state in a session means smaller packets can be sent
> from client to server. E.g. the server only needs to know the delta in
> layer state, not the visibility of all layers in order to render a map.
> On the web today this is not all that important, but if we wanted to
> support wireless/mobile clients in the future then this is pretty
> attractive.
>
> Bob
>
> Haris Kurtagic wrote:
>
>> Yes, I was also thinking about returning all images at once, I read
>> about this Image strips (not familiar with those) but sounds like way
>>
> to
>
>> go.
>>
>> Buffers, I forgot about those.
>>
>> Thank you,
>> Haris
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
>>
> Robert
>
>> Bray
>> Sent: Wednesday, September 12, 2007 12:53 AM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] MapGuide Comments
>>
>> Harris,
>>
>> I could not agree more on your first point. In fact I would love to
>> optimize that to send some kind of legend image strip in one operation
>>
>
>
>> to avoid all the round-trips.
>>
>> As for this comment:
>>
>> >>I am setting Map view parameters and request for image in one
>> request,
>> >>good or bad ?
>>
>> I think your approach is good. In fact that is the way the DWF Viewer
>> works as a client.
>>
>> Sessions are necessary for other stuff, like temporary layers, data,
>> etc. A buffer for example creates a temporary SDF and layer. You can
>> then use that SDF for further geo-processing, etc.
>>
>> Thanks,
>> Bob
>>
>> Haris Kurtagic wrote:
>>
>>> I am working on MapGuide RESTful service and digging deep into
>>>
>> MapGuide.
>>
>>> I have a lot of good words on what Autodesk guys did, good job.
>>>
>>>
>>>
>>> I would like to comment on things that I don't like or understand and
>>> hopefully to hear other opinions.
>>>
>>>
>>>
>>> 1. Legend Image Icon creation is very paintfull and error
>>>
> prone.
>
>>> To request for Icon you need to send few parameters scale, theme rule
>>> index, geometry type,...
>>>
>>> What is happing is that viewer's are deciding on geometry type not on
>>> feature source geometry type but reading from XML ( PointStyle,
>>> LineStyle, Polygon, Combo ) by string tag.
>>>
>>> Then they will convert it into geometry type (and wrongly for
>>>
>> ComboStyle
>>
>>> - will go to Multi Point). Server rendering is expecting real
>>>
> geometry
>
>>> type to find appropriate feature style (getting feature source and
>>> correct geometry type would be even more overhead).
>>>
>>>
>>>
>>> I see several problems: here viewers have hard-coded schema elements,
>>> not correctly setting required geometry type, exception's on wrong
>>> scale, exception if data on server is changed.
>>>
>>> One of problems is if server can't figure out rule for example
>>>
> setting
>
>>> incorrect scale will crash web-tier badly ( null-pointer access).
>>>
>>> This can be repeated with Sheboygan example and if you send request
>>>
>> for
>>
>>> District legend icon with scale=0, it will not find it and will
>>>
> return
>
>>> null image and agent crashes ( HttpGetLegendImage needs if in 134
>>>
> line
>
>>> or throw exception in server).
>>>
>>>
>>>
>>> What I think would be right is to have Id for rule so you would
>>>
> simple
>
>>> request for image by id instead of ( scale, geometry type, rule index
>>>
>> ).
>>
>>> I wrote a lot about not so "important" thing but it took us a lot of
>>> time :)
>>>
>>>
>>>
>>> 2. Session - what are reasons for having session's ?
>>>
>>> To store Map runtime parameters ( center, scale layers show/hide,
>>> selection). Viewers are keeping this parameters of map and basically
>>> doing two requests one to set these properties to runtime map and
>>> another one to request image.
>>>
>>> To store user credentials - session as token, that I think is OK.
>>>
>>> I am setting Map view parameters and request for image in one
>>>
> request,
>
>>> good or bad ?
>>>
>>>
>>>
>>> Thanks ,
>>>
>>> Haris
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
More information about the mapguide-internals
mailing list