[mapguide-internals] MapGuide Comments

Haris Kurtagic haris at sl-king.com
Wed Sep 19 03:35:48 EDT 2007 

Yes, server needs it and how is done now is that you need to do two
requests: one to send changes about extent, layers' etc and another one
to request for image.
I look now at scale, center, layers visibility etc as state of
application not as a state of data. So I think it doesn't belong on
server side. 
I see several advantages:
- one request ( I looked in OpenLayers sandbox and saw implementation
for MG layer, one synchronous request to set image and then image
itself, unpractical)
- one runtime map data can be used and shared by multiple clients
- and most important stateless request for image, with one url you get
same image every time ( regardless of previous requests)
There are couple of things I am not sure of like selection. Right now I
think either put selection ( not data but filter ) in every request or
separate selection image from base image.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
Birch
Sent: Wednesday, September 19, 2007 4:25 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide Comments

 
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