[mapguide-internals] Future Development Options for Web Server Extensions and new High Performance Viewer

Kenneth Skovhede, GEOGRAF A/S ks at geograf.dk
Tue Dec 29 02:38:21 EST 2009


If that was a response to my question/statement, it's a bit off.

I was not asking for the client to perform the rendering, the server can 
render maps (including labels).

My point was that there is absolutely no reason that there has to be a 
.Net/PHP/Java server page that basically does:
MgMap map = new MgMap(...);
map.Layers[layername].Visible = !map.Layers[layername].Visible;
map.Save();

So to re-phrase my question/statement:
Why is there no AJAX method to just do this?

You can append requests for legendlabels, legendvisibility etc.
Basically everything that the Web API can do.

Regards, Kenneth Skovhede, GEOGRAF A/S

On 28-12-2009 19:41, Walt Welton-Lair wrote:
>> Why is it that there has to be server side code just to toggle layer visibility?
>>      
> If I have two layers with labels, when I toggle off one of the layers it can affect the placement of labels for the other layer.  So does the label placement logic get moved out of the server?
>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [ks at geograf.dk]
> Sent: Monday, December 28, 2009 3:37 AM
> To: mapguide-internals at lists.osgeo.org
> Subject: Re: [mapguide-internals] Future Development Options for Web Server     Extensions and new High Performance Viewer
>
> I agree with Zac (and Traian): just fix the HTTP API for AJAX!
> Why is it that there has to be server side code just to toggle layer
> visibility?
>
> If the HTTP API supports all the options that the Web API has, there is no
> need for the Web API, and no need to keep it in 3 or more versions.
>
> Should a Web API be desired, it can use the same API as the HTTP clients
> use, but just skip the HTTP part, and communicate directly with the
> MapGuide service.
>
> I also agree that OL is the thing to use. If there is a need for a
> client side render,
> just add it as a layer type to OL, that way there is also the
> possibility for a fallback/upgrade
> solution for browsers with certain plugins/capabilities.
> (That is also how OL handles the SVG/VML problem).
>
> If you want offline data, you just need MapGuide to convert the
> LayerDefinition to SLD.
> Once that is ready, OL can render your vector data, no coding needed.
> If you use something like google gears, you can store the GML responses
> from MapGuide
> for offline use.
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
> On 27-12-2009 11:50, Haris Kurtagic wrote:
>    
>> I  would like to add few of my thoughts.
>> I have tested few web client platforms, Flash/Flex, Silverlight, HTML5
>> Canvas for something like heavy client work with lot of vectors. There is
>> growing number of OS libraries for drawing stuff in canvas or VML/SVG and I
>> tried few of them. I wasn't pleased with any result I was able to get, it
>> was either performance or memory (or stylization). But, certainly things are
>> going to improve.
>>
>> In our project we then used combination of MG2.1 + GeoREST + OpenLayers, so
>> data is rendered as image and then on smaller zoom's we request vector
>> layers and render as such and allow interaction with the vectors. This is
>> combination of MG server rendering and vector rendering on client side.
>>
>> Recently OS svgweb project came out and it seems to me that SVG could be
>> something to look more into. SVG and HTML5 promising to be good combo.
>>
>> Also,  AutoCAD/MAP is in our projects very important MapGuide client. Not to
>> connect to data directly but trough web/http services and wms/wfs is not
>> enough. We are using FDO provider for GeoREST/MapGuide but much more is
>> needed there and I believe lot of our attention will go in that direction.
>>
>> In the end I don't have answer to myself what would be the right
>> technology/platform for client to focus on. I do know that MG needs to
>> support browsers, mobile solutions but also desktop apps like AutoCAD.
>>
>> I believe there is lot of work on server side which needs to be done to get
>> open/fast/scalable platform which could effectively support such clients.
>> Right now my focus is on the server side of story.
>>
>> Haris
>>
>>
>>
>> On Sun, Dec 27, 2009 at 7:35 AM, Jackie Ng<jumpinjackie at gmail.com>   wrote:
>>
>>
>>      
>>> Just another guy with no oar in the water :-)
>>>
>>> I am in favour of whichever solution/technologies that allows the viewer to
>>> operate in a *disconnected/offline* scenario. I believe that this will open
>>> up a whole bunch of scenarios that were previously not possible with
>>> MapGuide in its current form.
>>>
>>> Also I think that we shouldn't stress too much about IE6 support. If they
>>> want to still live in 2001 and not move with the times, they can always
>>> stick with the basic AJAX viewer :-P
>>>
>>> - Jackie
>>>
>>>
>>> Carsten Hess wrote:
>>>
>>>        
>>>> Jason,
>>>>
>>>> I like that you go back to the use cases. Personally I agree that the
>>>> server load is only a partial problem as hardware is cheap compared to
>>>> software. Don't get me wrong, I think there is plenty that we as an
>>>> overall community could do to make MapGuide more thread-able (have better
>>>> multi-processor and multi-server support). I also believe that some
>>>> rendering on the client is very intriguing as the clients have a lot of
>>>> computing power to share that often lays dormant.
>>>>
>>>> I think the second one use-case you talk (thick client for performance)
>>>>
>>>>          
>>> is
>>>
>>>        
>>>> significantly more work compared to editing which I am happy to elaborate
>>>> on.
>>>>
>>>> If you just do editing and assume a 100ms turnaround time for
>>>>
>>>>          
>>> web-requests
>>>
>>>        
>>>> you can let the server do tons of simple operations (i.e. compute line
>>>> patterns, compute snapping points, etc) for the client without recoding
>>>> and loading all this data to the client. This comes to another
>>>>
>>>>          
>>> interesting
>>>
>>>        
>>>> observation: In a web-environment we have to weigh network load against
>>>> server-load for real benefit.
>>>>
>>>> I think it would be very interesting to compare the data and packaging
>>>> cost of vectors vs. rendered images. I bet we would find that feature
>>>>
>>>>          
>>> wise
>>>
>>>        
>>>> dense maps, maps with lots of pattern / line styles, or raster layer and
>>>> operations are more expensive to do on the server compared to do it on
>>>> clients. At the same time they would be a lot cheaper on the network load
>>>> if done on the server. I bet you would find the other extremes also to be
>>>> true and find cases where sending the feature data over the wire would be
>>>> more expensive on network and server compared to the rendering. Just
>>>>
>>>>          
>>> think
>>>
>>>        
>>>> of a complex theming - the data would have to travel much further from
>>>>
>>>>          
>>> the
>>>
>>>        
>>>> data-tier if you do client side rendering.
>>>>
>>>> So in my opinion a mixed environment holds nirvana - and a lot of work -
>>>> for both use cases! And then there is the stuff Traian hacks together
>>>>
>>>>          
>>> that
>>>
>>>        
>>>> shows that simple solutions are not only fast but possible now compared
>>>>
>>>>          
>>> to
>>>
>>>        
>>>> next year - nice work on that canvas based rendering Traian!
>>>>
>>>> I also want to double your last comment. I don't have an oar in that
>>>>
>>>>          
>>> water
>>>
>>>        
>>>> either. It is just something I have thought about a bit and want to share
>>>> my thoughts on. Feel free to disregard :)
>>>>
>>>> Cheers,
>>>>     Carsten
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
>>>> Birch
>>>> Sent: Saturday, December 26, 2009 3:14 PM
>>>> To: MapGuide Internals Mail List
>>>> Subject: Re: [mapguide-internals] Future Development Options for Web
>>>> Server Extensions and new High Performance Viewer
>>>>
>>>> Carsten,
>>>>
>>>> I see two different use cases. One, for a disconnected editor, where a
>>>> very thick client would be of great use. Two, for a slightly thicker
>>>> client for higher performance. Server load is, I suppose, somewhat of
>>>> a concern, but from my perspective isn't really critical... You can
>>>> always throw more hardware at a task :)
>>>>
>>>> The first of these would require substantial re-implementation of the
>>>> mapguide interfaces ( or a non-direct port where mapguide is combines
>>>> with a bunch of other modules ) and has its own value proposition.
>>>>
>>>> The second of these may be able to provide benefits from some changes
>>>> to the mapagent to output an optimized format for the client. Have a
>>>> look at the GeoREST sample that haris built using KML output to render
>>>> in openlayers. Its not perfect, but its a step in the right direction
>>>> I think. Basically GeoREST is rendering a vector format for
>>>> consumption by the client.
>>>>
>>>> Finding the right balance of what to keep server side and what to
>>>> re-implement on the client may be difficult, but I think we could see
>>>> considerable benefit from looking at each layer.
>>>>
>>>> Note, I like talking about this stuff, but don't have an oar in the
>>>> water on this particular item yet, so take what I say for what its
>>>> worth :)
>>>>
>>>> Jason
>>>>
>>>> Jason
>>>>
>>>> On 2009-12-26, Carsten Hess<carsten.hess at autodesk.com>   wrote:
>>>>
>>>>          
>>>>> Ok, I tend to stay quite on this list but this is something of interest
>>>>> to
>>>>> me. I agree that client side rendering could help one aspect of the
>>>>> "scalability" of the server.
>>>>>
>>>>> So far the discussion has been all platform related but not talked about
>>>>> what the capabilities of such a client would be. Porting some of the
>>>>>
>>>>>            
>>> code
>>>
>>>        
>>>>> and API's would not be trivial to say the least. So I have my doubts
>>>>>
>>>>>            
>>> that
>>>
>>>        
>>>>> a
>>>>> heavy client would have the same "features" as MapGuide does today
>>>>>
>>>>>            
>>> unless
>>>
>>>        
>>>>> you can reuse code.
>>>>>
>>>>> As for platform, Traian quoted I think Stroustroup to me about a week
>>>>> having
>>>>> said "Java is not platform independent - Java is a platform". I totally
>>>>> agree with that whoever said it and I think flash is even more so a
>>>>> platform. Many small devices do support open web technologies like
>>>>>
>>>>>            
>>> canvas
>>>
>>>        
>>>>> and HTML5 but won't support Java or Flash. The most extreme example is
>>>>> the
>>>>> IPhone / Pod platform. Looking forward I believe that these devices will
>>>>> be
>>>>> more important than the intranet /internet / web-browser.
>>>>>
>>>>> Anyways, I think the real influence I would like to have on this
>>>>> discussion
>>>>> is to point out how much functionality there is on the server that would
>>>>> need to move or be given up / replaced.
>>>>>
>>>>> Cheers,
>>>>>     Carsten
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: mapguide-internals-bounces at lists.osgeo.org
>>>>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac
>>>>> Spitzer
>>>>> Sent: Thursday, December 24, 2009 7:56 PM
>>>>> To: MapGuide Internals Mail List
>>>>> Subject: Re: [mapguide-internals] Future Development Options for Web
>>>>> Server
>>>>> Extensions and new High Performance Viewer
>>>>>
>>>>> but openlayers is the defacto js api for geo spatial,
>>>>> and there are a lot more javascript developers than flash,
>>>>> plus it would 'just work' with our existing fusion client
>>>>> and also cool things like GeoExt
>>>>>
>>>>>
>>>>>
>>>>> 2009/12/25 Jason Birch<jason at jasonbirch.com>:
>>>>>
>>>>>            
>>>>>> It may be more productive to contribute to OpenScales; it's based on
>>>>>> the OL idea, but in flash. It's not especially fast (I think its still
>>>>>> thinking mostly about rasters) but I think with the right contributors
>>>>>> it could be and duplication of effort / NiH sucks :)
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> On 2009-12-24, Zac Spitzer<zac.spitzer at gmail.com>   wrote:
>>>>>>
>>>>>>              
>>>>>>> I'd propose that what ever gets done, should be based on Openlayers
>>>>>>> as a dynamic layer. That way we can leverage everything else already
>>>>>>> done
>>>>>>> in OL. It also reduces the amount of work required by a factor of like
>>>>>>> 100,
>>>>>>> plus there's a lot more dev's around in OL land
>>>>>>>
>>>>>>> Plugins are rather 1990's, I agree with Jason that flash is a good
>>>>>>> option,
>>>>>>> but it i reckon it should just be a layer renderer which fits into the
>>>>>>> OL framework
>>>>>>> if at all possible....
>>>>>>>
>>>>>>> The possibilities with HTML5 Canvas are pretty cool...
>>>>>>>
>>>>>>> As for browser support, I would suggest, shock horror, we only target
>>>>>>> modern
>>>>>>> browsers, forget IE6 completely, and given the rumours about IE9
>>>>>>> supporting
>>>>>>> real world javascript peformance, perhaps ignore IE7 and even IE8, as
>>>>>>> neither
>>>>>>> supports Canvas
>>>>>>>
>>>>>>> that said, a flash layer for OL would avoid that problem :)
>>>>>>>
>>>>>>> 2009/12/25 Jason Birch<jason at jasonbirch.com>:
>>>>>>>
>>>>>>>                
>>>>>>>> Oh, and I'm running on about 3 hours sleep in last 48, so sorry if
>>>>>>>> that
>>>>>>>> was
>>>>>>>> overly cranky :)
>>>>>>>>
>>>>>>>> 2009/12/24 Jason Birch
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> I can't believe that custom ActiveX or Java are seriously being
>>>>>>>>> considered.
>>>>>>>>>    Is there no organisational memory of how much of a pain in the ass
>>>>>>>>> it
>>>>>>>>> was
>>>>>>>>> for customers to maintain multiple implementations of MapGuide just
>>>>>>>>> to
>>>>>>>>> make
>>>>>>>>> sure that everyone could use it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>> _______________________________________________
>>>>>>>> mapguide-internals mailing list
>>>>>>>> mapguide-internals at lists.osgeo.org
>>>>>>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>>
>>>>>>> --
>>>>>>> Zac Spitzer
>>>>>>> Solution Architect / Director
>>>>>>> Ennoble Consultancy Australia
>>>>>>> http://www.ennoble.com.au
>>>>>>> http://zacster.blogspot.com
>>>>>>> +61 405 847 168
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>              
>>>>>
>>>>> --
>>>>> Zac Spitzer
>>>>> Solution Architect / Director
>>>>> Ennoble Consultancy Australia
>>>>> http://www.ennoble.com.au
>>>>> http://zacster.blogspot.com
>>>>> +61 405 847 168
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>>          
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-tp4208470p4219854.html
>>> Sent from the MapGuide Internals mailing list archive at Nabble.com.
>>> _______________________________________________
>>> 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
>    


More information about the mapguide-internals mailing list