[mapguide-internals] MapGuide Comments

Jason Birch Jason.Birch at nanaimo.ca
Tue Sep 18 22:24:47 EDT 2007 

 
Mostly agree, but wouldn't the server need to have knowledge of layer visibility in order to respond to selection requests properly?
 
Jason

________________________________

From: mapguide-internals-bounces at lists.osgeo.org on behalf of Paul Spencer
Sent: Tue 2007-09-18 6:54 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide Comments

Sorry to come into this discussion so late, I think Harris and 
Kenneth have more-or-less expressed the opinions that I would have so 
I will just reiterate support for this.

It is critical for the client to maintain most of the state 
information about the map (extents, size, layer & group visibility, 
etc).  The necessity of calling the server to set this in the session 
is, frankly, a pain.  The client already has sufficient information 
to figure out the visible extents in the correct aspect ratio etc.

There is a necessity to be able to store a copy of the map in the 
session to be able to make structural changes to it, such as adding 
or removing layers, changing layer order etc.

I also prefer to have the selection maintained in the server rather 
than the client, but I am willing to change my mind on this.  For 
large selections, it seems like a lot of information to be moving 
back and forth if the details of the selection are not required on 
the client ...

Fusion would benefit greatly from a RESTful API such as Harris is 
working on, and I am excited to see how it evolves and how we can 
take advantage of it.

Cheers

Paul

On 15-Sep-07, at 1:22 PM, Kenneth, GEOGRAF A/S wrote:

> 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
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|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

More information about the mapguide-internals mailing list