From bluecarto at gmail.com Wed Dec 6 15:43:13 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:43 2006 Subject: Fwd: [OpenLayers-Dev] Advanced GIS functionnalities In-Reply-To: <3E2C795132D4BE4B96958332FB3325433AA53B@EINT11.einet.ad.eivd.ch> References: <3E2C795132D4BE4B96958332FB3325433AA53B@EINT11.einet.ad.eivd.ch> Message-ID: ---------- Forwarded message ---------- From: CHAPUIS Bertil Date: Dec 6, 2006 8:33 PM Subject: [OpenLayers-Dev] Advanced GIS functionnalities To: dev@openlayers.org Hello, We (at Camptocamp SA) are very impressed about the interactivity of OpenLayers. We are seriously thinking of using the OL API with advanced GIS server functionalities. Our experience with CartoWeb development could bring a lot to the OL community. Advanced GIS functionnalities may include: - Customizable layer (one image with several sub layers) - Advanced search queries with complex highlighting on the result images - Routing - And more... Are there already investigations to standardize the communication between the client and the server (XML, JSON, WFS, WPS, ...) ? Javascript often needs proxy severs to use Web services. So we think now would be a good time to discuss how to efficiently use the server. Regards, The Camptocamp team _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev From cameron.shorter at gmail.com Wed Dec 6 16:32:01 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Map Width/Height defined as a percentage in OWS Context Message-ID: <457736D1.9040401@gmail.com> Tom, Am I right in understanding that WMC and OWS Context always specify Map Size in fixed coordinates. Eg: With modern webmapping clients these days, maps are set to fit within the HTML
element that encloses them. So what would work better for the context is to set window size as: The Area of Interest would then need to be calculated to fit the specified BoundingBox. (We need to make the assumption that users don't want to stretch images). Could you please add this to your OWS Context issues to address/discuss. -- Cameron Shorter http://cameron.shorter.net From Tom.Kralidis at ec.gc.ca Wed Dec 6 16:49:14 2006 From: Tom.Kralidis at ec.gc.ca (Kralidis,Tom [Burlington]) Date: Fri Dec 22 15:49:43 2006 Subject: Map Width/Height defined as a percentage in OWS Context Message-ID: <2576812186CDD411BF1500508B6DCE950D17F9BA@ecnwri1.ontario.int.ec.gc.ca> > -----Original Message----- > From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > Sent: 06 December, 2006 4:32 PM > To: 'ows-4-geodss@opengeospatial.org'; > webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] > Subject: Map Width/Height defined as a percentage in OWS Context > > Tom, > Am I right in understanding that WMC and OWS Context always > specify Map Size in fixed coordinates. Eg: > > > Correct. This was originally from the WMC days. > With modern webmapping clients these days, maps are set to > fit within the HTML
element that encloses them. > So what would work better for the context is to set window size as: > > > > The Area of Interest would then need to be calculated to fit > the specified BoundingBox. (We need to make the assumption > that users don't want to stretch images). > 100% of what? This is assuming that a client has a width/height in place when loading a context. What if my client purely derived from what a WMC/OWSContext provided in Window/@width and Window/@height ? Similarly, we encountered this when working on WMC 1.0.0 (i.e. honouring bbox vs. window size). It was decided that it would be up to the client on whether to recalculate the bbox or adjust the window width/height (i.e. when aspect ratio is off). I would see this same behavious (i.e. letting the client decide) as can be applied to modern webmapping clients also. Does this make sense? > Could you please add this to your OWS Context issues to > address/discuss. > For sure. Thanks. > -- > Cameron Shorter > http://cameron.shorter.net > > From cameron.shorter at gmail.com Wed Dec 6 17:05:08 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Map Width/Height defined as a percentage in OWS Context In-Reply-To: <2576812186CDD411BF1500508B6DCE950D17F9BA@ecnwri1.ontario.int.ec.gc.ca> References: <2576812186CDD411BF1500508B6DCE950D17F9BA@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <45773E94.5020507@gmail.com> Width would be set to 100% of the size of the
(in line with HTML convensions). The will often be 100% of the browser window width. Kralidis,Tom [Burlington] wrote: > > > >>-----Original Message----- >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>Sent: 06 December, 2006 4:32 PM >>To: 'ows-4-geodss@opengeospatial.org'; >>webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] >>Subject: Map Width/Height defined as a percentage in OWS Context >> >>Tom, >>Am I right in understanding that WMC and OWS Context always >>specify Map Size in fixed coordinates. Eg: >> >> >> > > Correct. This was originally from the WMC days. > > >>With modern webmapping clients these days, maps are set to >>fit within the HTML
element that encloses them. >>So what would work better for the context is to set window size as: >> >> >> >>The Area of Interest would then need to be calculated to fit >>the specified BoundingBox. (We need to make the assumption >>that users don't want to stretch images). >> > > > 100% of what? This is assuming that a client has a width/height in > place when loading a context. What if my client purely derived from > what a WMC/OWSContext provided in Window/@width and Window/@height ? > > Similarly, we encountered this when working on WMC 1.0.0 (i.e. honouring > bbox vs. window size). It was decided that it would be up to the client > on whether to recalculate the bbox or adjust the window width/height > (i.e. when aspect ratio is off). > > I would see this same behavious (i.e. letting the client decide) as can > be applied to modern webmapping clients also. > > Does this make sense? > > >>Could you please add this to your OWS Context issues to >>address/discuss. >> > > > For sure. Thanks. > > >>-- >>Cameron Shorter >>http://cameron.shorter.net >> >> > > -- Cameron Shorter http://cameron.shorter.net From Tom.Kralidis at ec.gc.ca Wed Dec 6 17:06:36 2006 From: Tom.Kralidis at ec.gc.ca (Kralidis,Tom [Burlington]) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: Map Width/Height defined as a percentage in OWS Context Message-ID: <2576812186CDD411BF1500508B6DCE950D17F9BB@ecnwri1.ontario.int.ec.gc.ca> What if the context is not being used by an HTML client? > -----Original Message----- > From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > Sent: 06 December, 2006 5:05 PM > To: Kralidis,Tom [Burlington] > Cc: ows-4-geodss@opengeospatial.org; webmap-discuss@mail.osgeo.org > Subject: [webmap-discuss] Re: Map Width/Height defined as a > percentage in OWS Context > > Width would be set to 100% of the size of the
(in line > with HTML convensions). The will often be 100% of the browser > window width. > > Kralidis,Tom [Burlington] wrote: > > > > > > > >>-----Original Message----- > >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > >>Sent: 06 December, 2006 4:32 PM > >>To: 'ows-4-geodss@opengeospatial.org'; > >>webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] > >>Subject: Map Width/Height defined as a percentage in OWS Context > >> > >>Tom, > >>Am I right in understanding that WMC and OWS Context always specify > >>Map Size in fixed coordinates. Eg: > >> > >> > >> > > > > Correct. This was originally from the WMC days. > > > > > >>With modern webmapping clients these days, maps are set to > fit within > >>the HTML
element that encloses them. > >>So what would work better for the context is to set window size as: > >> > >> > >> > >>The Area of Interest would then need to be calculated to fit the > >>specified BoundingBox. (We need to make the assumption that users > >>don't want to stretch images). > >> > > > > > > 100% of what? This is assuming that a client has a width/height in > > place when loading a context. What if my client purely > derived from > > what a WMC/OWSContext provided in Window/@width and Window/@height ? > > > > Similarly, we encountered this when working on WMC 1.0.0 (i.e. > > honouring bbox vs. window size). It was decided that it > would be up > > to the client on whether to recalculate the bbox or adjust > the window > > width/height (i.e. when aspect ratio is off). > > > > I would see this same behavious (i.e. letting the client decide) as > > can be applied to modern webmapping clients also. > > > > Does this make sense? > > > > > >>Could you please add this to your OWS Context issues to > >>address/discuss. > >> > > > > > > For sure. Thanks. > > > > > >>-- > >>Cameron Shorter > >>http://cameron.shorter.net > >> > >> > > > > > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > From cameron.shorter at gmail.com Wed Dec 6 17:10:22 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: Map Width/Height defined as a percentage in OWS Context In-Reply-To: <2576812186CDD411BF1500508B6DCE950D17F9BB@ecnwri1.ontario.int.ec.gc.ca> References: <2576812186CDD411BF1500508B6DCE950D17F9BB@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <45773FCE.9050500@gmail.com> I assume that anything that is rendering a map has a window or a Pane concept which has width/height attributes. 100% = as big as you can make the map using your current display device. 50% = half of the Window width. etc. Kralidis,Tom [Burlington] wrote: > What if the context is not being used by an HTML client? > > >>-----Original Message----- >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>Sent: 06 December, 2006 5:05 PM >>To: Kralidis,Tom [Burlington] >>Cc: ows-4-geodss@opengeospatial.org; webmap-discuss@mail.osgeo.org >>Subject: [webmap-discuss] Re: Map Width/Height defined as a >>percentage in OWS Context >> >>Width would be set to 100% of the size of the
(in line >>with HTML convensions). The will often be 100% of the browser >>window width. >> >>Kralidis,Tom [Burlington] wrote: >> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>>Sent: 06 December, 2006 4:32 PM >>>>To: 'ows-4-geodss@opengeospatial.org'; >>>>webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] >>>>Subject: Map Width/Height defined as a percentage in OWS Context >>>> >>>>Tom, >>>>Am I right in understanding that WMC and OWS Context always specify >>>>Map Size in fixed coordinates. Eg: >>>> >>>> >>>> >>>Correct. This was originally from the WMC days. >>> >>> >>> >>>>With modern webmapping clients these days, maps are set to >> >>fit within >> >>>>the HTML
element that encloses them. >>>>So what would work better for the context is to set window size as: >>>> >>>> >>>> >>>>The Area of Interest would then need to be calculated to fit the >>>>specified BoundingBox. (We need to make the assumption that users >>>>don't want to stretch images). >>>> >>> >>> >>>100% of what? This is assuming that a client has a width/height in >>>place when loading a context. What if my client purely >> >>derived from >> >>>what a WMC/OWSContext provided in Window/@width and Window/@height ? >>> >>>Similarly, we encountered this when working on WMC 1.0.0 (i.e. >>>honouring bbox vs. window size). It was decided that it >> >>would be up >> >>>to the client on whether to recalculate the bbox or adjust >> >>the window >> >>>width/height (i.e. when aspect ratio is off). >>> >>>I would see this same behavious (i.e. letting the client decide) as >>>can be applied to modern webmapping clients also. >>> >>>Does this make sense? >>> >>> >>> >>>>Could you please add this to your OWS Context issues to >>>>address/discuss. >>>> >>> >>> >>>For sure. Thanks. >>> >>> >>> >>>>-- >>>>Cameron Shorter >>>>http://cameron.shorter.net >>>> >>>> >>> >>> >> >>-- >>Cameron Shorter >>http://cameron.shorter.net >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >>For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > -- Cameron Shorter http://cameron.shorter.net From Tom.Kralidis at ec.gc.ca Wed Dec 6 18:43:15 2006 From: Tom.Kralidis at ec.gc.ca (Kralidis,Tom [Burlington]) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: Map Width/Height defined as a percentage in OWS Context Message-ID: <2576812186CDD411BF1500508B6DCE950D17F9BC@ecnwri1.ontario.int.ec.gc.ca> What if the OWSContext doc is intended to be viewed given a target width/height? Having said this, maybe Window/@units (i.e. "pixels" or "percent") would be useful. I still think, as per our decisions in WMC 1.0.0, that a client can decipher what to do with BoundingBox and Window. Nevertheless, I'll tack this on as a discussion item for next week's ContextRWG. ..Tom > -----Original Message----- > From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > Sent: 06 December, 2006 5:10 PM > To: webmap-discuss@mail.osgeo.org > Cc: ows-4-geodss@opengeospatial.org > Subject: Re: [webmap-discuss] Re: Map Width/Height defined as > a percentage in OWS Context > > I assume that anything that is rendering a map has a window > or a Pane concept which has width/height attributes. > > 100% = as big as you can make the map using your current > display device. > 50% = half of the Window width. > etc. > > Kralidis,Tom [Burlington] wrote: > > What if the context is not being used by an HTML client? > > > > > >>-----Original Message----- > >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > >>Sent: 06 December, 2006 5:05 PM > >>To: Kralidis,Tom [Burlington] > >>Cc: ows-4-geodss@opengeospatial.org; webmap-discuss@mail.osgeo.org > >>Subject: [webmap-discuss] Re: Map Width/Height defined as a > percentage > >>in OWS Context > >> > >>Width would be set to 100% of the size of the
(in > line with HTML > >>convensions). The will often be 100% of the browser window width. > >> > >>Kralidis,Tom [Burlington] wrote: > >> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > >>>>Sent: 06 December, 2006 4:32 PM > >>>>To: 'ows-4-geodss@opengeospatial.org'; > >>>>webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] > >>>>Subject: Map Width/Height defined as a percentage in OWS Context > >>>> > >>>>Tom, > >>>>Am I right in understanding that WMC and OWS Context > always specify > >>>>Map Size in fixed coordinates. Eg: > >>>> > >>>> > >>>> > >>>Correct. This was originally from the WMC days. > >>> > >>> > >>> > >>>>With modern webmapping clients these days, maps are set to > >> > >>fit within > >> > >>>>the HTML
element that encloses them. > >>>>So what would work better for the context is to set > window size as: > >>>> > >>>> > >>>> > >>>>The Area of Interest would then need to be calculated to fit the > >>>>specified BoundingBox. (We need to make the assumption that users > >>>>don't want to stretch images). > >>>> > >>> > >>> > >>>100% of what? This is assuming that a client has a > width/height in > >>>place when loading a context. What if my client purely > >> > >>derived from > >> > >>>what a WMC/OWSContext provided in Window/@width and > Window/@height ? > >>> > >>>Similarly, we encountered this when working on WMC 1.0.0 (i.e. > >>>honouring bbox vs. window size). It was decided that it > >> > >>would be up > >> > >>>to the client on whether to recalculate the bbox or adjust > >> > >>the window > >> > >>>width/height (i.e. when aspect ratio is off). > >>> > >>>I would see this same behavious (i.e. letting the client > decide) as > >>>can be applied to modern webmapping clients also. > >>> > >>>Does this make sense? > >>> > >>> > >>> > >>>>Could you please add this to your OWS Context issues to > >>>>address/discuss. > >>>> > >>> > >>> > >>>For sure. Thanks. > >>> > >>> > >>> > >>>>-- > >>>>Cameron Shorter > >>>>http://cameron.shorter.net > >>>> > >>>> > >>> > >>> > >> > >>-- > >>Cameron Shorter > >>http://cameron.shorter.net > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > >>For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > >> > >> > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > > > > > -- > Cameron Shorter > http://cameron.shorter.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > > > From crschmidt at metacarta.com Wed Dec 6 20:08:09 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:43 2006 Subject: WebMap.js, aka OpenLayers Profiles Message-ID: <20061207010809.GA1816@metacarta.com> (I meant to send this more than a month ago -- sorry about that.) At the FOSS4G conference, members of the OSGeo web mapping development community met and agreed to begin developing towards a single basic client-side web map rendering library that can be used across the various projects in the community. The OpenLayers development team volunteered to work on the first cut of this library, using the !OpenLayers library as a base. To achieve this goal, we have formalized the notion of 'profiles' in the OpenLayers build process and created a 'lite' build profile. The desired characteristics were described as: * Containing a minimal framework for creating applications, with the ability to easily add additional components. * Free of Prototype.js constructs which break Javascript functionality, primarily the `Object.extend` method, which broke the ability to iterate over the properties of an object. As described during that meeting, these desires can be met using: * a 'Map class'' defining general properties of the map, such as projection, which are by default passed onto the layers in the map. * 'Event handling' functionality including the ability to register listeners to events which occur, and to control the map and cause those events to occur. * a 'Layer class', providing a framework for describing how content should be included in the Map. * Layer support for ''Gridded WMS requests'', providing the minimal amount of layer support to allow the lightweight version to display map imagery using WMS. The 'lite' build profile achieves these goals and is included in OpenLayers v2.2. It contains the ability to create a map, add a WMS layer, and control that map via JavaScript calls. Build profiles allow anyone to build a single-file JavaScript library containing whatever parts they desire, these and more. To build this light version of the library: * Download and extract OpenLayers 2.2 * `cd build` * `sh ./build.sh lite` When run with the 'lite' parameter, this script creates a single-file script that includes the following files: {{{ OpenLayers/SingleFile.js OpenLayers.js OpenLayers/BaseTypes.js OpenLayers/Util.js OpenLayers/Events.js OpenLayers/Map.js OpenLayers/Layer.js OpenLayers/Layer/Grid.js OpenLayers/Layer/HTTPRequest.js OpenLayers/Layer/WMS.js OpenLayers/Layer/WMS/Untiled.js OpenLayers/Tile.js OpenLayers/Tile/Image.js }}} The result of running the build.sh script is a new OpenLayers.js file that will include the functions of all files selected by the input profile name. The functions in files chosen by 'lite' are sufficient to create an OpenLayers map without any additional files. An example of using the 'lite' library is available in the "examples" directory, called `lite.html`. To add additional parts of OpenLayers to your single file, you can simply modify the `lite.cfg` file (or copy it to another name), and add the code that meets your needs. In this way, any user can create a minimal build which includes only the code needed by their project. We look forward to hearing your feedback as you look at the code available via OpenLayers. To avoid duplicating effort, we would like to integrate any code based on this framework into the OpenLayers project, so other projects can concentrate on application-specific interactions. As part of creating a project to which more people contribute, we have also expanded the committers list to the OpenLayers Subversion repository. For more information on becoming a committer, see "How to Contribute", on the OpenLayers wiki. http://trac.openlayers.org/wiki/HowToContribute http://trac.openlayers.org/wiki/Profiles Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Thu Dec 7 18:04:48 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [OWS-4-GeoDSS] [webmap-discuss] Re: Map Width/Height defined as a percentage in OWS Context In-Reply-To: <1EFDD798-94F7-4851-9FDB-203D67815706@traversetechnologies.com> References: <2576812186CDD411BF1500508B6DCE950D17F9BB@ecnwri1.ontario.int.ec.gc.ca> <1EFDD798-94F7-4851-9FDB-203D67815706@traversetechnologies.com> Message-ID: <45789E10.8010804@gmail.com> Interesting point. I guess this begs the question: "What is the use case driving the need for a Context document?" I think that the context is primarilly showing: layers and extent. "I'm looking in this area, using these layers". If we change the resolution of the screen used to display, then we should continue to show the same extent, but the layers would use a different SLD to cope with the resolution. (This would probably be handled at the server). As I think through this further, it seems that Width,Height is not as important as it used to be, and I suspect that in most clients it should be ignored during rendering, but prehaps should be manadory in the creation of a new Context. Joshua Lieberman wrote: > A problem with specifying a percentage is that the rendering of the > map is often scale-dependent, which means pixel scale. If the > original client (e.g. 20" monitor) is rendering a map window at a > different size than a client receiving the context document (e.g. > cellphone), the map details may be completely inapproriate for the > second client and it would be more appropriate to change the extent > in order to show the features in the context. Whether or not an > explicit pixel dimension of the image is given, the context document > should include some indication of the pixel scale for which it was > created. > > Josh > > On Dec 6, 2006, at 5:06 PM, Kralidis,Tom [Burlington] wrote: > > >>What if the context is not being used by an HTML client? >> >> >>>-----Original Message----- >>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>Sent: 06 December, 2006 5:05 PM >>>To: Kralidis,Tom [Burlington] >>>Cc: ows-4-geodss@opengeospatial.org; webmap-discuss@mail.osgeo.org >>>Subject: [webmap-discuss] Re: Map Width/Height defined as a >>>percentage in OWS Context >>> >>>Width would be set to 100% of the size of the
(in line >>>with HTML convensions). The will often be 100% of the browser >>>window width. >>> >>>Kralidis,Tom [Burlington] wrote: >>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>>>Sent: 06 December, 2006 4:32 PM >>>>>To: 'ows-4-geodss@opengeospatial.org'; >>>>>webmap-discuss@mail.osgeo.org; Kralidis,Tom [Burlington] >>>>>Subject: Map Width/Height defined as a percentage in OWS Context >>>>> >>>>>Tom, >>>>>Am I right in understanding that WMC and OWS Context always specify >>>>>Map Size in fixed coordinates. Eg: >>>>> >>>>> >>>>> >>>>Correct. This was originally from the WMC days. >>>> >>>> >>>> >>>>>With modern webmapping clients these days, maps are set to >>> >>>fit within >>> >>>>>the HTML
element that encloses them. >>>>>So what would work better for the context is to set window size as: >>>>> >>>>> >>>>> >>>>>The Area of Interest would then need to be calculated to fit the >>>>>specified BoundingBox. (We need to make the assumption that users >>>>>don't want to stretch images). >>>>> >>>> >>>> >>>>100% of what? This is assuming that a client has a width/height in >>>>place when loading a context. What if my client purely >>> >>>derived from >>> >>>>what a WMC/OWSContext provided in Window/@width and Window/@height ? >>>> >>>>Similarly, we encountered this when working on WMC 1.0.0 (i.e. >>>>honouring bbox vs. window size). It was decided that it >>> >>>would be up >>> >>>>to the client on whether to recalculate the bbox or adjust >>> >>>the window >>> >>>>width/height (i.e. when aspect ratio is off). >>>> >>>>I would see this same behavious (i.e. letting the client decide) as >>>>can be applied to modern webmapping clients also. >>>> >>>>Does this make sense? >>>> >>>> >>>> >>>>>Could you please add this to your OWS Context issues to >>>>>address/discuss. >>>>> >>>> >>>> >>>>For sure. Thanks. >>>> >>>> >>>> >>>>>-- >>>>>Cameron Shorter >>>>>http://cameron.shorter.net >>>>> >>>>> >>>> >>>> >>> >>>-- >>>Cameron Shorter >>>http://cameron.shorter.net >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >>>For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >>> >>> >>> >> >>_______________________________________________ >>OWS-4-GeoDSS mailing list >>OWS-4-GeoDSS@opengeospatial.org >>https://mail.opengeospatial.org/mailman/listinfo/ows-4-geodss > > > _______________________________________________ > OWS-4-GeoDSS mailing list > OWS-4-GeoDSS@opengeospatial.org > https://mail.opengeospatial.org/mailman/listinfo/ows-4-geodss > -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Mon Dec 11 20:04:16 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Further to context meeting - JSON Message-ID: <457E0010.7010401@gmail.com> I humbly appologise for missing the Context meeting. I had my head stuck in code and lost track of time. I suggest adding another issue to: https://portal.opengeospatial.org/wiki/twiki/bin/view/Contextrwg/DiscussionItems (What is the protocol here - should I just add comments to the page myself?) There has been discussion amongst web developers (in particular OpenLayers) about using JSON instead of XML for passing data between client/server. JSON is much easier to process that XML for web based clients, particularly for some of the fring browsers which have limited AJAX support. I'd like to see the OGC: 1. Recognise JSON as a legitimate alternative to XML that can be included in Capabilities documents. 2. Provide guidance on how to convert an XML based specification to JSON. 3. Sponsor a test bed with client/servers which both use JSON. -- Cameron Shorter http://cameron.shorter.net From steven.ottens at geodan.nl Thu Dec 14 06:32:37 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:43 2006 Subject: mapserver and xml respons Message-ID: <45813655.6010201@geodan.nl> Hi all, I'm wondering how to solve the following problem: I've got a mapbuilder/mapserver setup where mapserver is setup with relative paths, if I request a capabilities doc: