[mapguide-internals] MapGuide Comments
Robert Bray
rbray at robertbray.net
Fri Sep 21 10:04:25 EDT 2007
It is not entirely your bad. I suspect the CGI API has some rather large
gapping holes that make it difficult to write a good AJAX client. For
one, GETDYNAMICOVERLAY cannot just render selection, but I agree it
should be able to. I bet there are other problems. What I'd like to do
is refocus this conversation on fixing the CGI API now that we are
hopefully done session bashing :).
Bob
Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
> _______________________________________________
> 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