[mapguide-internals] MapGuide Comments
Paul Spencer
pspencer at dmsolutions.ca
Fri Sep 21 08:45:01 EDT 2007
My bad ... I am mis-using the API by always using
GETDYNAMICMAPOVERLAYIMAGE to draw the map, which required that I call
GETVISIBLEMAPEXTENT. By changing to GETMAPIMAGE for regular map
draws, we can avoid the double request as the same parameters can be
passed to GETMAPIMAGE as to GETVISIBLEMAPEXTENT.
Can we render just the selection using GETDYNAMICMAPOVERLAYIMAGE by
passing the selection XML? Or does GETDYNAMICMAPOVERLAYIMAGE also
draw the whole map?
This started from early misconception that has just lingered because
we never came back to look at it ... got it working and didn't think
about it any more. Now that the light bulb is ON ... ;)
Cheers
Paul
On 19-Sep-07, at 6:41 PM, Robert Bray wrote:
> 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
> _______________________________________________
> 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