[mapguide-internals] MapGuide Comments

Paul Spencer pspencer at dmsolutions.ca
Wed Sep 19 06:22:15 EDT 2007


Good point.  The client can pass layers to include in the selection  
process, if necessary, since it will be passing them to the render  
request.

Paul

On 18-Sep-07, at 10:24 PM, Jason Birch wrote:

>
> 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
>
> _______________________________________________
> 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/ |
+-----------------------------------------------------------------+







More information about the mapguide-internals mailing list