[mapguide-internals] MapGuide Comments
Kenneth, GEOGRAF A/S
ks at geograf.dk
Sat Sep 15 13:22:23 EDT 2007
Yes, you are right. The client should have a copy of the current map view.
I still think that the current map view should be present on the server,
and then
reset on the client after retrival of a map. The same way the legend
currently works.
Regards, Kenneth, GEOGRAF A/S
Haris Kurtagic skrev:
> First of all, thank you for sharing your thoughts.
>
> I think client had to keep data about current Map view. For example if
> you would like to Zoom in, client would recalculate new scale and send
> it to server.
> There is no server command for change scale by 1.5 ( and also that type
> of "incremental" command would be inappropriate) and doing calls get
> scale - recalculate - send back doesn't sound right.
>
> I am now looking at Map as data, data with state ( existing data from
> features, new data ).
> View of Map (Image) I look as stateless.
>
> When I am thinking about this than I try to draw parallel between
> Map/Image and Table/Query in database. Map is a Table in database.
> Generating image is similar to generating view on your table data by
> sending parameters ( center ,scale ,layers on/off ,...).
>
> Haris
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of
> Kenneth, GEOGRAF A/S
> Sent: Thursday, September 13, 2007 9:23 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide Comments
>
> 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
>>
>>
> _______________________________________________
> 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