[mapguide-internals] MapGuide Comments
Robert Bray
rbray at robertbray.net
Wed Sep 19 18:41:50 EDT 2007
I fail to comprehend why you need two round-trips. Maybe I am just dense
these days. Always passing layer visibility for each layer when the
number of layers in the map exceeds a certain boundary is not practical.
It is not uncommon to see MG maps with 500 or more layers (the record I
have seen in my 10 years on this project is around 1200).
I agree that two round trips is not desirable. However in one request
you should be able to pass a set of commands for altering the map state
with the expected result of a new image. Does that not satisfy the
requirement? What am I missing here?
Bob
Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
> _______________________________________________
> 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