From cameron.shorter at gmail.com Wed Nov 1 01:01:10 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] RE: [Context.RWG] Using OWS Context to describe GML/WFS layers whichdecimate In-Reply-To: <2576812186CDD411BF1500508B6DCE950D17F88E@ecnwri1.ontario.int.ec.gc.ca> References: <2576812186CDD411BF1500508B6DCE950D17F88E@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <45483826.9010401@gmail.com> Tom, Yes using groups would work. Do you expect to have a proposed schema with the group tag included in time for me to use it in the OWS4? Kralidis,Tom [Burlington] wrote: > > > >>-----Original Message----- >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>Sent: 31 October, 2006 7:17 PM >>To: Kralidis,Tom [Burlington] >>Cc: Martin Daly; context.rwg@opengeospatial.org; >>webmap-discuss@mail.osgeo.org; Raj Singh >>Subject: Re: [Context.RWG] Using OWS Context to describe >>GML/WFS layers whichdecimate >> >>Kralidis,Tom [Burlington] wrote: >> >>>Cameron, >>> >>>So you want one OWSContext FeatureType to hold many GML documents? >>> >>>If yes, can you not define each GML doc as an OWSContext >> >>FeatureType, >> >>>each with respective scale rules? >> >>Tom, >>Using Style scale rules to make a layer visible or not would >>be one solution - but with a number of limitations: >>1. If I were to build a LayerList (or Legend) from the >>Context, would I end up with a layer for each scale? >> > > > Yes, however you could build your client Legend handler to show layers > only if they're within the scale range of where the application scale is > at. > > >>2. If my legend was smart, and layers were only visible at >>certain resolutions, how do I associate a HighResolutionLayer >>with a LowResolutionLayer so that the Layer attributes (like >>visibility) can be associated between layers. >> > > > If OWSContext identified the notion of a @group attribute as part of the > AbstractResourceType, this might be an option. There has been some mild > discussion on this front. > > > >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>>Sent: 30 October, 2006 7:29 PM >>>>To: Martin Daly >>>>Cc: context.rwg@opengeospatial.org; Kralidis,Tom [Burlington]; >>>>webmap-discuss@mail.osgeo.org; Raj Singh >>>>Subject: Re: [Context.RWG] Using OWS Context to describe GML/WFS >>>>layers whichdecimate >>>> >>>>Martin, >>>>Point taken regarding G/Y/M maps. Replace zoomLevel with >>>>sld:Min/MaxScaleDenominator in my previous comment. >>>> >>>>I still need to reference different GML sources for each layer >>>>depending on scale, which doesn't seem to be covered by OWS Context >>>>yet. >>>> >>>> >>>>Martin Daly wrote: >>>> >>>> >>>>>>zoomLevel is a term used by Google/Yahoo/MSN Maps. >>>>>>It is a measure of resolution. As you zoom out, the zoomLevel >>>>>>increases. >>>>> >>>>> >>>>>That is not a definition that will wash in a standard that >> >>aims for >> >>>>>interoperability. >>>>> >>>>>In fact, OWS Context already uses >> >>sld:Min/MaxScaleDenominator in the >> >>>>>AbstractResourceType, so the capability already exists. >>>>> >>>>>As with the previous long e-mail trail re. GYM data, this >>>> >>>>spec. should >>>> >>>> >>>>>leverage de jure OGC standards, not de facto ones that >>>> >>>>large parts of >>>> >>>> >>>>>the target audience cannot use. >>>>> >>>>>M >>>>> >>>>> >>>> >>>> >>>>-- >>>>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 > > -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Wed Nov 1 01:21:25 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Vector rendering design updated Message-ID: <45483CE5.7060201@gmail.com> I've updated the Vector Rendering design at: http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design Key changes: * There is one graphics/Canvas class which creates all graphic objects (SVG/VML/etc). * This means that we don't need a Renderer for each target platform. The Renderer just calls the one Canvas class to create shapes. * I've created a StyledGeometry concept for storing features. * I've changed some of the names of files to align with the GO-1 naming convention. (as I understand it). There are still more details we can work out - but they would probably be best to work out during implementation. Comments welcome. Other news: =========== * Chris Thorne is interested to use implement X3D rendering. (3D rendering which can be installed into a browser as a pluggin). Some info at http://planet-earth.org/ -- Cameron Shorter http://cameron.shorter.net From Tom.Kralidis at ec.gc.ca Wed Nov 1 10:32:33 2006 From: Tom.Kralidis at ec.gc.ca (Kralidis,Tom [Burlington]) Date: Fri Dec 22 15:49:43 2006 Subject: [Context.RWG] [webmap-discuss] RE: Using OWS Context to describe GML/WFS layers whichdecimate Message-ID: <2576812186CDD411BF1500508B6DCE95103E2D36@ecnwri1.ontario.int.ec.gc.ca> Cameron, What are your timelines for OWS4? I'd like to get a 0.0.14 OWSContext up on the twiki before the San Diego TC meetings in December. > -----Original Message----- > From: > context.rwg-bounces+tom.kralidis=ec.gc.ca@opengeospatial.org > [mailto:context.rwg-bounces+tom.kralidis=ec.gc.ca@opengeospati > al.org] On Behalf Of Cameron Shorter > Sent: 01 November, 2006 1:01 AM > To: webmap-discuss@mail.osgeo.org > Cc: context.rwg@opengeospatial.org; Martin Daly; Raj Singh > Subject: Re: [Context.RWG] [webmap-discuss] RE: Using OWS > Context to describe GML/WFS layers whichdecimate > > Tom, > Yes using groups would work. > > Do you expect to have a proposed schema with the group tag > included in time for me to use it in the OWS4? > > Kralidis,Tom [Burlington] wrote: > > > > > > > >>-----Original Message----- > >>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > >>Sent: 31 October, 2006 7:17 PM > >>To: Kralidis,Tom [Burlington] > >>Cc: Martin Daly; context.rwg@opengeospatial.org; > >>webmap-discuss@mail.osgeo.org; Raj Singh > >>Subject: Re: [Context.RWG] Using OWS Context to describe GML/WFS > >>layers whichdecimate > >> > >>Kralidis,Tom [Burlington] wrote: > >> > >>>Cameron, > >>> > >>>So you want one OWSContext FeatureType to hold many GML documents? > >>> > >>>If yes, can you not define each GML doc as an OWSContext > >> > >>FeatureType, > >> > >>>each with respective scale rules? > >> > >>Tom, > >>Using Style scale rules to make a layer visible or not would be one > >>solution - but with a number of limitations: > >>1. If I were to build a LayerList (or Legend) from the > Context, would > >>I end up with a layer for each scale? > >> > > > > > > Yes, however you could build your client Legend handler to > show layers > > only if they're within the scale range of where the > application scale > > is at. > > > > > >>2. If my legend was smart, and layers were only visible at certain > >>resolutions, how do I associate a HighResolutionLayer with a > >>LowResolutionLayer so that the Layer attributes (like > >>visibility) can be associated between layers. > >> > > > > > > If OWSContext identified the notion of a @group attribute > as part of > > the AbstractResourceType, this might be an option. There has been > > some mild discussion on this front. > > > > > > > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] > >>>>Sent: 30 October, 2006 7:29 PM > >>>>To: Martin Daly > >>>>Cc: context.rwg@opengeospatial.org; Kralidis,Tom [Burlington]; > >>>>webmap-discuss@mail.osgeo.org; Raj Singh > >>>>Subject: Re: [Context.RWG] Using OWS Context to describe GML/WFS > >>>>layers whichdecimate > >>>> > >>>>Martin, > >>>>Point taken regarding G/Y/M maps. Replace zoomLevel with > >>>>sld:Min/MaxScaleDenominator in my previous comment. > >>>> > >>>>I still need to reference different GML sources for each layer > >>>>depending on scale, which doesn't seem to be covered by > OWS Context > >>>>yet. > >>>> > >>>> > >>>>Martin Daly wrote: > >>>> > >>>> > >>>>>>zoomLevel is a term used by Google/Yahoo/MSN Maps. > >>>>>>It is a measure of resolution. As you zoom out, the zoomLevel > >>>>>>increases. > >>>>> > >>>>> > >>>>>That is not a definition that will wash in a standard that > >> > >>aims for > >> > >>>>>interoperability. > >>>>> > >>>>>In fact, OWS Context already uses > >> > >>sld:Min/MaxScaleDenominator in the > >> > >>>>>AbstractResourceType, so the capability already exists. > >>>>> > >>>>>As with the previous long e-mail trail re. GYM data, this > >>>> > >>>>spec. should > >>>> > >>>> > >>>>>leverage de jure OGC standards, not de facto ones that > >>>> > >>>>large parts of > >>>> > >>>> > >>>>>the target audience cannot use. > >>>>> > >>>>>M > >>>>> > >>>>> > >>>> > >>>> > >>>>-- > >>>>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 > > > > > > > -- > Cameron Shorter > http://cameron.shorter.net > _______________________________________________ > Context.rwg mailing list > Context.rwg@opengeospatial.org > https://mail.opengeospatial.org/mailman/listinfo/context.rwg > > From cameron.shorter at gmail.com Wed Nov 1 14:39:31 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: vector editing summary In-Reply-To: <33B39F1E-BA81-4673-B6BA-2D9EB725687C@dmsolutions.ca> References: <0128DD30-46B4-4B6A-98A2-4545330D2722@dmsolutions.ca> <454737A8.8070307@gmail.com> <2686af10610311244q7057d47by792a8c05301c449c@mail.gmail.com> <4547CE29.8020904@gmail.com> <33B39F1E-BA81-4673-B6BA-2D9EB725687C@dmsolutions.ca> Message-ID: <4548F7F3.3080108@gmail.com> Pierre Giraud and Bertil Chapuis's vector rendering demo has moved to http://dev.camptocamp.com/openlayers They also have UML of their design there. Their design is very similar to ours at http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design At this early stage, it should be quite easy to merge the two code bases, then work on a common code base together. Could someone please forward this email to Bertil. I'm not sure what his contact details are. Pierre, Bertil, I'm very keen to get in touch with you when you are free. I've been hanging out at http://freenode.net#openlayers Or you can try one of the chat programs I use (listed at http://cameron.shorter.net ) Paul Spencer wrote: > http://svn.openlayers.org/sandbox/pagameba/vector is the current (not > working) version that I am using to move code around in. > > I created a copy of the more-or-less working version in http:// > svn.openlayers.org/sandbox/pagameba/vector-original > > The newer version is starting to look like the list below but a bunch > of stuff is still not moved around and its not in a runnable state > right now. > > Also, I did add the primative methods to the point and line segment > code for basic picking functions, which are the building blocks for > editing controls. Once the code is running again, I'll chat with Chris > Schmidt about creating controls for digitizing and editing. > > Anselm ... not sure where you want to dig in, perhaps just dig around > and look at the code ... I'll be working on it again tomorrow night for > an hour or two I think, perhaps we could discuss how to split up the > work if you see an area you want to work on. > > Cheers > > Paul > > > On 31-Oct-06, at 5:28 PM, Cameron Shorter wrote: > >> Yes Anselm, I suggest working in Paul's directory. (I assume that is >> OK with Paul?) >> >> And use the design from the UML diagrams as the master. >> At the moment, focus on the Graphics code. >> >> I'm struggling with how to handle Geometry at different scales. >> How do you describe a feature using a different FeatureCollection for >> each zoom level. >> >> I've raise the issue on the OWS Context email list and it seems that >> this problem has not been resolved properly in Context, WFS, and >> possibly even GML specs. >> >> Anselm Hook wrote: >> >>> I'd like to be able to play with some code a bit - should i use the >>> stuff here: >>> http://svn.openlayers.org/sandbox/pagameba/vector/lib/OpenLayers/ >>> Vector.js >>> Or should I use pauls stuff which may be elsewhere? >>> I wouldn't mind roughing out some of camerons framework and then >>> playing with some canvas based implementations of the abstractions for >>> fun... >>> - a >>> On 10/31/06, Cameron Shorter wrote: >>> >>>> Paul, Anselm, >>>> I haven't updated as much of the design as I hoped. Other >>>> priorities got >>>> in the way. >>>> >>>> I've primarilly only updated the Graphics code. >>>> I've changed the names slightly to align with GO-1 naming convensions. >>>> (A Java standard API) >>>> >>>> I've re-introduced a Factory. >>>> >>>> The key API will be the Canvas object. >>>> >>>> I'll be back onto this tomorrow. (your afternoon) >>>> >>>> Paul Spencer wrote: >>>> > Cameron, here is my non-uml version of where I think we could go >>>> with >>>> > the design/architecture. I think this allows for a lot of >>>> flexibility >>>> > but is reasonably easy to understand. >>>> > >>>> > Lemme know what you think ... >>>> > >>>> > Cheers >>>> > >>>> > Paul >>>> > >>>> > -- >>>> > >>>> > Graphics >>>> > Graphics.Point >>>> > Graphics.Line >>>> > Graphics.LineSegment >>>> > Graphics.Polygon >>>> > Graphics.Circle >>>> > >>>> > Graphics represents graphic primitives. Graphic primitives deal >>>> > directly in pixel coordinates and know nothing about the spatial >>>> > objects they represent. >>>> > >>>> > Vector >>>> > Vector.Point >>>> > Vector.Line >>>> > Vector.Polygon >>>> > >>>> > Vector encapsulates a geo-spatial feature. Vector objects can >>>> create >>>> > Graphics primitives to use for rendering. A Vector object can >>>> also be >>>> > initialized from a Graphics object to aid in digitizing new >>>> features >>>> > and editing existing features. >>>> > >>>> > Style >>>> > Style.PointSymbolizer >>>> > Style.LineSymbolizer >>>> > Style.AreaSymbolizer >>>> > >>>> > Style is a general description of how to render a specific type of >>>> > Vector feature. Styles can be associated with a Layer or with >>>> > individual Vector objects. Style is used by the Renderer to >>>> create a >>>> > visual representation of a Vector >>>> > >>>> > Renderer >>>> > Renderer.Graphic >>>> > Renderer.Graphic.Canvas >>>> > Renderer.Graphic.SVG >>>> > Renderer.Graphic.VML >>>> > Renderer.WKT >>>> > Renderer.GML >>>> > >>>> > Renderer is a generic virtual vector rendering interface. Only >>>> > specific subclasses of Renderer can be instantiated. A vector layer >>>> > uses the renderer to render its Vector objects into some output. >>>> The >>>> > main use is to render a graphic representation of a Vector feature. >>>> > However, Renderers can also produce string representations such >>>> as WKT >>>> > and GML. >>>> > >>>> > Layer >>>> > Layer.Vector >>>> > Layer.Vector.GeoRSS >>>> > Layer.Vector.WFS >>>> > >>>> > A Layer.Vector is a generic vector rendering layer. It manages an >>>> > array of Vector objects. Sub-classes of Layer.Vector provide direct >>>> > access to vector data via a specific protocol like GeoRSS or WFS. >>>> > >>>> > >>>> > +-----------------------------------------------------------------+ >>>> > |Paul Spencer pspencer@dmsolutions.ca | >>>> > +-----------------------------------------------------------------+ >>>> > |Chief Technology Officer | >>>> > |DM Solutions Group Inc http:// www.dmsolutions.ca/ | >>>> > +-----------------------------------------------------------------+ >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>>> -- >>>> 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 >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > --------------------------------------------------------------------- > 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 cameron.shorter at gmail.com Wed Nov 1 15:35:00 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [Context.RWG] [webmap-discuss] RE: Using OWS Context to describe GML/WFS layers whichdecimate In-Reply-To: <2576812186CDD411BF1500508B6DCE95103E2D36@ecnwri1.ontario.int.ec.gc.ca> References: <2576812186CDD411BF1500508B6DCE95103E2D36@ecnwri1.ontario.int.ec.gc.ca> Message-ID: <454904F4.8060205@gmail.com> I plan to deliver Mapbuilder with the majority of the functionality in mid Novemeber, however I have budget until early December which I can use to tweak the application. Ideally I'd like to have an idea of how the group functionality is structured by the end of next week. Kralidis,Tom [Burlington] wrote: > Cameron, > > What are your timelines for OWS4? I'd like to get a 0.0.14 OWSContext > up on the twiki before the San Diego TC meetings in December. > > >>-----Original Message----- >>From: >>context.rwg-bounces+tom.kralidis=ec.gc.ca@opengeospatial.org >>[mailto:context.rwg-bounces+tom.kralidis=ec.gc.ca@opengeospati >>al.org] On Behalf Of Cameron Shorter >>Sent: 01 November, 2006 1:01 AM >>To: webmap-discuss@mail.osgeo.org >>Cc: context.rwg@opengeospatial.org; Martin Daly; Raj Singh >>Subject: Re: [Context.RWG] [webmap-discuss] RE: Using OWS >>Context to describe GML/WFS layers whichdecimate >> >>Tom, >>Yes using groups would work. >> >>Do you expect to have a proposed schema with the group tag >>included in time for me to use it in the OWS4? >> >>Kralidis,Tom [Burlington] wrote: >> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>>Sent: 31 October, 2006 7:17 PM >>>>To: Kralidis,Tom [Burlington] >>>>Cc: Martin Daly; context.rwg@opengeospatial.org; >>>>webmap-discuss@mail.osgeo.org; Raj Singh >>>>Subject: Re: [Context.RWG] Using OWS Context to describe GML/WFS >>>>layers whichdecimate >>>> >>>>Kralidis,Tom [Burlington] wrote: >>>> >>>> >>>>>Cameron, >>>>> >>>>>So you want one OWSContext FeatureType to hold many GML documents? >>>>> >>>>>If yes, can you not define each GML doc as an OWSContext >>>> >>>>FeatureType, >>>> >>>> >>>>>each with respective scale rules? >>>> >>>>Tom, >>>>Using Style scale rules to make a layer visible or not would be one >>>>solution - but with a number of limitations: >>>>1. If I were to build a LayerList (or Legend) from the >> >>Context, would >> >>>>I end up with a layer for each scale? >>>> >>> >>> >>>Yes, however you could build your client Legend handler to >> >>show layers >> >>>only if they're within the scale range of where the >> >>application scale >> >>>is at. >>> >>> >>> >>>>2. If my legend was smart, and layers were only visible at certain >>>>resolutions, how do I associate a HighResolutionLayer with a >>>>LowResolutionLayer so that the Layer attributes (like >>>>visibility) can be associated between layers. >>>> >>> >>> >>>If OWSContext identified the notion of a @group attribute >> >>as part of >> >>>the AbstractResourceType, this might be an option. There has been >>>some mild discussion on this front. >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Cameron Shorter [mailto:cameron.shorter@gmail.com] >>>>>>Sent: 30 October, 2006 7:29 PM >>>>>>To: Martin Daly >>>>>>Cc: context.rwg@opengeospatial.org; Kralidis,Tom [Burlington]; >>>>>>webmap-discuss@mail.osgeo.org; Raj Singh >>>>>>Subject: Re: [Context.RWG] Using OWS Context to describe GML/WFS >>>>>>layers whichdecimate >>>>>> >>>>>>Martin, >>>>>>Point taken regarding G/Y/M maps. Replace zoomLevel with >>>>>>sld:Min/MaxScaleDenominator in my previous comment. >>>>>> >>>>>>I still need to reference different GML sources for each layer >>>>>>depending on scale, which doesn't seem to be covered by >> >>OWS Context >> >>>>>>yet. >>>>>> >>>>>> >>>>>>Martin Daly wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>zoomLevel is a term used by Google/Yahoo/MSN Maps. >>>>>>>>It is a measure of resolution. As you zoom out, the zoomLevel >>>>>>>>increases. >>>>>>> >>>>>>> >>>>>>>That is not a definition that will wash in a standard that >>>> >>>>aims for >>>> >>>> >>>>>>>interoperability. >>>>>>> >>>>>>>In fact, OWS Context already uses >>>> >>>>sld:Min/MaxScaleDenominator in the >>>> >>>> >>>>>>>AbstractResourceType, so the capability already exists. >>>>>>> >>>>>>>As with the previous long e-mail trail re. GYM data, this >>>>>> >>>>>>spec. should >>>>>> >>>>>> >>>>>> >>>>>>>leverage de jure OGC standards, not de facto ones that >>>>>> >>>>>>large parts of >>>>>> >>>>>> >>>>>> >>>>>>>the target audience cannot use. >>>>>>> >>>>>>>M >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>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 >>> >>> >> >> >>-- >>Cameron Shorter >>http://cameron.shorter.net >>_______________________________________________ >>Context.rwg mailing list >>Context.rwg@opengeospatial.org >>https://mail.opengeospatial.org/mailman/listinfo/context.rwg >> >> > > -- Cameron Shorter http://cameron.shorter.net From dragonmagi at gmail.com Wed Nov 1 16:21:00 2006 From: dragonmagi at gmail.com (chris) Date: Fri Dec 22 15:49:43 2006 Subject: my intro Message-ID: Hi, Cameron asked me to comment on the design so I thought I'd intro myself first. I live in 3D land so there is a big difference right there. However, I believe there is a lot of commonality between 2D and 3D graphcis plus I am doing geospatial, web bsed, open standards, open source - lots of common ground there. Normally, I network to the server directly from the 3D client via http, avoiding the portability issues that plague javascript solutions. However, it seems everyone else wants to use Ajax so I decided, after talking to Cameron, to start learning how to use it. There is also some web3D Ajax work in progress: Ajax3D - see http://ajax3d.org/content.html. I am completing a Phd on improving the fidelity and scalability of virtual environments and use a full scale geospatial world (planet-earth.org) as a test case. I have been working with the web 3D standards for years, starting with VRML and now with X3D (see http://www.web3d.org), which are both ISO standards for 3D on the Web. I've been writing open source for years too - java - for terrain modelling/translation (http://planet-earth.org/Rez/RezIndex.html). Anyway, what I envisage is a client that has a 2D geospatial window/frame and a 3D one as well, perhaps for local views. This clien would provide chat and other multiuser collaboration facilities. So, I'm going to follow up with my comments on the design Cameron has pointed me to and see if we can get to some common ground. cheers, chris From cameron.shorter at gmail.com Wed Nov 1 18:48:51 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [OpenLayers-Dev] vectors layer In-Reply-To: <6ae3fb590611011537g7badb047xd85607a019156050@mail.gmail.com> References: <6ae3fb590611011537g7badb047xd85607a019156050@mail.gmail.com> Message-ID: <45493263.3010805@gmail.com> Chris suggested 3d a few hours ago to the webmap-discuss list. I'll foward through. Erik Uzureau wrote: > should we maybe consider supporting 3d graphics? > > http://www.uselesspickles.com/triangles/demo.html > > ;-) > -erik > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > -- Cameron Shorter http://cameron.shorter.net From dragonmagi at gmail.com Wed Nov 1 20:38:20 2006 From: dragonmagi at gmail.com (chris) Date: Fri Dec 22 15:49:43 2006 Subject: comments on osgeo design in wiki Message-ID: Hi All, Cameron invited me to put comments intot he wiki but my comments are fairly general and long winded so I thought it would be more appropriate to put them here. keep in mind I know nothing of Javascript and I also tend to think of high level design in terms of building interface walls between the more changeable functionality and the more generic. Generally, it all looks good. My main feeling is that design seems to have begun too low level, I'd like to see the bigger architectural picture. Would help to define this as a geospatial pipeline architecture (e.g. like in attached image) and work from there. Including main pipeline stages: network, Object System (OS), User IO, graphic Display System (DS), server communication (full duplex handling of user requests, tracking, collaboration info (chat etc), data fetch and service requests). I don't see classes for the server side processing ? but that is potentially where a lot of the work will be done. I started to get a picture of how class hierarchies shown work together as a whole after seeing the parser diagram at the bottom. Is the parser the highest level class? I think it is very useful in the long term to have clear separation between object system and display system, think of the OS as the model and the DS as the View in a MVC design. A monolithic object/display class hierarchy gets too unweildy (I note the text on keeping the graphics library standalone: this is good but I am talking about a separation at a higher level still). In my Phd research and work on planet-earth.org and other geospatial stuff I find this separation essential to ensure high fidelity over large scale ? e.g. it helps with applying a floating origin (http://planet-earth.org/cw05/FloatingOrigin.pdf). Note: although I work from a 3D perspective :) these numerical matters also apply to 2D. Separation again: if u can define class or classes that isolate the code that is needed to make client cross browser/OS portable then that would go a long way to ensure its longevity. I think it will be perilous to ignore historical experience, despite the hype/excitement over Ajax: http://www.coachwei.com/blog/_archives/2006/9/27/2367882.html . On this subject, I see some DOM calls. From what I gather, some people believe that using DOM can alleviate many of the platform portability issues. I hope this is the case. I assume the raster layer class is to be the image data handler. I'm not sure there is enough here: what about interface class (or rather, abstract class) for layer::raster to use for multiple image format handling and also have a look at multirez image handling (tiling). This would provide layer with a consistent interface but handle the dynamic loading of whatever image reader was required. All then proly need to be extended to "tiled" versions. Use cases are v low level. Need to take a step back and look at the big picture. Perhaps look at use cases for w3d Geospatial Incubator Group: http://www.w3.org/2005/Incubator/geo/charter. Note the emphasis on handling semantic as well as spatial searches, and the inclusion of time. No interface classes are shown. A high level analysis of functionality that changes over a range of use cases versus functionality that is common would be useful. Interfaces can then be defined to separate the more dynamic from the more stable functionality that gets reused across use cases. E.g. the processing of geo data has a number of generic, stable operations (overlay, draw etc) that are always used no matter if the input is from GML, KML, a DEM format, image data etc. So, an interface class can be defined to provide a common interface for all these and it dynamically loads the GML reader if the user is just getting GML or some other reader as appropriate. Saves on client run time footprint and also breaks up the design nicely. All the data format readers form the dynamic part separated from the stable part by the interface. Note: I tend to use this sort of pattern in java and don't know if you can use such dynamic loading in javascript, but perhaps the same design principles should apply. Note I use the term interface loosely: in Java terms I often use an "abstract" class rather than an "interface" class because it usually has some method code in it. Need to have objects for spatial reference model: (http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_18026_Ed1.html). e.g. need objects for Ellipsoid, datum, SRS, projection, etc. this site: http://www.ai.sri.com/geovrml/1.1/doc/concepts.html has a nice subset that I think could be adopted. What about supporting 3D data? Consider: output can go to either 2D or 3D. Most geodata maps into a 3D position, in general so perhaps a layer can be defined that preserves the 3D. Time data is significant too. Consider how you are going to handle scaling from earth to human scale. Consider the handling of LOD. Multirrez tiling essential. Is "Line" a polyline? -- cheers, chris -------------- next part -------------- A non-text attachment was scrubbed... Name: GeoSimPipeline.png Type: image/png Size: 120904 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20061102/0150b889/GeoSimPipeline.png From dragonmagi at gmail.com Fri Nov 3 00:09:22 2006 From: dragonmagi at gmail.com (chris) Date: Fri Dec 22 15:49:43 2006 Subject: learning javascript guide Message-ID: Ok, after seeing the not so useless uselesspickles example, I'd like someone to point me at a good path to learn javascript, particularly the graphics part :), thanks, chris From bluecarto at gmail.com Fri Nov 3 06:32:23 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] AJAX vector rendering "gathering" In-Reply-To: <454714E3.2030708@gmail.com> References: <117e688acbe8839b27dd8c94f43a7125@145.50.39.8> <454714E3.2030708@gmail.com> Message-ID: Hi all, Sorry, I was gone for a long week-end taking advantage on a public holiday (date?) and I unfortunately missed the irc meeting. We (Bertil and I) will do our best to get more involved in the future discussions. Thanks Bart for the summary. Looks like it is difficult for all of us to go the same way but I hope we can. Regards Pierre On 10/31/06, Cameron Shorter wrote: > Thanks Bart: > > Logs at: > http://crschmidt.net/irc/openlayers/log.cgi/2006-10-30 > > Anselm Hook dropped in afterwards and plans to help out with the coding too. > > Bart van den Eijnden (OSGIS) wrote: > > Hi Steve, > > > > I can post a small summary. > > > > There was a discussion about using the DOJO Vector library, but generally > > OpenLayers is against introducing new dependencies (where they have just > > been removing others like Prototype). So it did not seem like the most > > appropriate option. > > > > Paul Spencer has been writing some code in OpenLayers for DMSG's MapGuide > > Fusion project, and this will be available roughly somewhere in the next > > month(s). It is based on Canvas and uses Google's IECanvas library. Paul and > > Christopher Schmidt claim this can do all they want to do for editing, even > > things like snapping should be possible. Cameron had some reservations when > > it comes to finding features on a map (performance e.g.), and attaching > > events to features. The server-side part of the Fusion project will likely > > not be open-sourced, but the vector part for OpenLayers will be. There will > > be a need for a redesign of the stuff after Cameron and Paul finish their > > general design. > > > > Cameron is working on SVG rendering in Mapbuilder for his OWS-4 project, and > > plans to integrate this into OpenLayers in the near future (maybe even next > > couple of weeks). The two options (Canvas and SVG) are probably > > complimentary. > > > > Please correct me if I noted something incorrectly :-) > > > > The IRC session was logged, but I don't have the URL unfortunately. > > > > Best regards, > > Bart > > > > -- > > Bart van den Eijnden > > OSGIS, Open Source GIS > > http://www.osgis.nl > > > > > > --------- Oorspronkelijk bericht -------- > > Van: webmap-discuss@mail.osgeo.org > > Naar: webmap-discuss@mail.osgeo.org > > Onderwerp: Re: [webmap-discuss] AJAX vector rendering "gathering" > > Datum: 31/10/06 00:27 > > > > > >>Cameron, > >> > >>I really wanted to attend, but had other commitments. Will someone post > >>a summary of the discussion and any decisions/outcomes/etc. > >> > >>Thanks, > >> -Steve > >> > >>Cameron Shorter wrote: > >>> There are a number of early implementations of AJAX GIS vector > > > > rendering > > > >>> that we are all involved in - and there seems to be a common desire > > > > to > > > >>> work together on this. > >>> > >>> I suggest we have an IRC meeting where we can agree on a common > > > > design > > > >>> (at a high level) then volunteer for components. > >>> > >>> that everyone who is interested join together in an IRC session in 12 > > > > > >>> hours at: > >>> > > > > http://timeanddate.com/worldclock/meetingdetails.html?year=2006&month=10&day=30&hour=19&min=0&sec=0&p1=240&p2=16&p3=179&p4=137 > > > > > >>> > >>> Sydney Tue 6:00:00 AM UTC+11 hours EST > >>> Amsterdam Mon 8:00:00 PM UTC+1 hour CET > >>> New York Mon 2:00:00 PM UTC-5 hours EST > >>> Los Angeles Mon 11:00:00 AM UTC-8 hours PST > >>> Corresponding UTC (GMT) Monday, 30 October 2006 at 19:00:00 > >>> > >>> Channel: > >>> irc://freenode.net#openlayers > >>> > >>> Agenda: > >>> 00 - 05: Roll Call. Confirm agenda. > >>> 05 - 10: Who is working on what, and what you plan to work on + > > > > questions. > > > >>> 10 - 50: Design discussion. > >>> 50 - 55: Coordinate efforts (who is working on what) > >>> 55 - 60: Arange next meeting. > >>> 60 --: Meeting close > >>> > >>> People who have shown an interest so far: > >>> ========================================= > >>> I'm writing vector rendering code for large GML datasets, currently > >>> using Mapbuilder but I'd like to move the logic into OpenLayers and > > > > use > > > >>> OpenLayers for the Mapbuilder rendering engine. > >>> With Paul Spencer, I've started putting together a design at: > >>> > > > > http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design#Graphics_Class_Diagram > > > > > >>> > >>> > >>> Paul Spencer has written vector rendering code for OpenLayers using > >>> IECanvas and has been discussing a new Vector rendering design with > > > > me. > > > >>> > >>> Pierre Giraud and Bertil Chapuis have implemented vector rendering in > > > > > >>> OpenLayers, including feature entry and editing at: > >>> http://dev.camptocamp.com/~bchapuis/openlayers/examples/vector.html > >>> > >>> Steven Ottens needs to edit features in a browser and I think he has > >>> plans for working on this soon. > >>> > >>> Ed Dowding has put together design ideas at: > >>> http://trac.openlayers.org/wiki/VectorDrawing > >>> > >>> Patrice Cappelaere has written SVG and VML support for GeoRSS and GML > > > > > >>> layers in Mapbuilder using elements of SLD for styling. > >>> > >>> Others on the CC list have contributed to discussions. Please add > > > > your > > > >>> name and come along if you are interested. > >>> > >> > >> > >>--------------------------------------------------------------------- > >>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 dragonmagi at gmail.com Fri Nov 3 07:17:17 2006 From: dragonmagi at gmail.com (chris) Date: Fri Dec 22 15:49:43 2006 Subject: [OpenLayers-Dev] learning javascript guide In-Reply-To: <6ae3fb590611030333x740f6ea9jfb0f701502cbd61@mail.gmail.com> References: <6ae3fb590611030333x740f6ea9jfb0f701502cbd61@mail.gmail.com> Message-ID: Thanks Erik, i'll have a look, chris On 11/3/06, Erik Uzureau wrote: > Chris- > > A good site with lots of JavaScript-related links: > http://www.crockford.com/javascript/ > > > > On 11/3/06, chris wrote: > > Ok, after seeing the not so useless uselesspickles example, I'd like > > someone to point me at a good path to learn javascript, particularly > > the graphics part :), > > > > thanks, > > > > chris > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > From steven.ottens at geodan.nl Fri Nov 3 08:22:08 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:43 2006 Subject: vector editing movie Message-ID: <454B4280.1030109@geodan.nl> Hi list, I'm a bit behind with the whole vector discussion, since I'm on a tight deadline to produce feature editing functionality. Building upon Patrice work in Mapbuilder I wrote functionality to display features in SVG/VML (Patrice work) and drag the vertices around and add/remove vertices. Currently the application is behind a firewall, so I can only give you all a screencast: http://jana.geodan.nl/steveno/Untitled.html and you've to take my word for it that it actually works both in FF and in IE. :) This is how I like to see feature editing in our uber-webmap-client ;) It works like this: The feature is requested from geoserver as a GML. The GML is double rendered: as a line and as a series of circles. On each circle there are eventhandlers on mouseover,-out,-down,-up Depending if the add/delete point function is enabled they behave differently (add a point, remove a point, move a point). On the mouseup event the GML is updated and the line is drawn again. My question is if this can be done with canvas as well, since putting eventhandlers on lines/points etc proves to be a very easy way to modify features. The essential (very hackish) code is in http://svn.codehaus.org/mapbuilder/sandbox/steven/FeatureEditing/ Steven -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From pat at cappelaere.com Fri Nov 3 08:36:03 2006 From: pat at cappelaere.com (Pat Cappelaere) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector editing movie In-Reply-To: <454B4280.1030109@geodan.nl> Message-ID: Very cool. Great job, brother! How did you make the movie? Pat. > From: "Steven M. Ottens" > Reply-To: > Date: Fri, 03 Nov 2006 14:22:08 +0100 > To: > Subject: [webmap-discuss] vector editing movie > > Hi list, > > I'm a bit behind with the whole vector discussion, since I'm on a tight > deadline to produce feature editing functionality. Building upon Patrice > work in Mapbuilder I wrote functionality to display features in SVG/VML > (Patrice work) and drag the vertices around and add/remove vertices. > Currently the application is behind a firewall, so I can only give you > all a screencast: > http://jana.geodan.nl/steveno/Untitled.html and you've to take my word > for it that it actually works both in FF and in IE. :) > This is how I like to see feature editing in our uber-webmap-client ;) > > It works like this: > The feature is requested from geoserver as a GML. The GML is double > rendered: as a line and as a series of circles. On each circle there are > eventhandlers on mouseover,-out,-down,-up Depending if the add/delete > point function is enabled they behave differently (add a point, remove a > point, move a point). On the mouseup event the GML is updated and the > line is drawn again. > > My question is if this can be done with canvas as well, since putting > eventhandlers on lines/points etc proves to be a very easy way to modify > features. > > The essential (very hackish) code is in > http://svn.codehaus.org/mapbuilder/sandbox/steven/FeatureEditing/ > > Steven > > -- > Geodan S&R Amsterdam > > ------------------------------------- > Geodan S&R > President Kennedylaan 1 > 1079 MB Amsterdam (NL) > ------------------------------------- > Tel: +31 (0)20 - 5711 311 > Fax: +31 (0)20 - 5711 333 > ------------------------------------- > E-mail: steven.ottens@geodan.nl > Website: www.geodan.nl > Disclaimer: www.geodan.nl/disclaimer > ------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > From steven.ottens at geodan.nl Fri Nov 3 08:44:13 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector editing movie In-Reply-To: References: Message-ID: <454B47AD.5070606@geodan.nl> I used camtasia, some screen recorder Steven Pat Cappelaere wrote: > Very cool. Great job, brother! > How did you make the movie? > Pat. > > >> From: "Steven M. Ottens" >> Reply-To: >> Date: Fri, 03 Nov 2006 14:22:08 +0100 >> To: >> Subject: [webmap-discuss] vector editing movie >> >> Hi list, >> >> I'm a bit behind with the whole vector discussion, since I'm on a tight >> deadline to produce feature editing functionality. Building upon Patrice >> work in Mapbuilder I wrote functionality to display features in SVG/VML >> (Patrice work) and drag the vertices around and add/remove vertices. >> Currently the application is behind a firewall, so I can only give you >> all a screencast: >> http://jana.geodan.nl/steveno/Untitled.html and you've to take my word >> for it that it actually works both in FF and in IE. :) >> This is how I like to see feature editing in our uber-webmap-client ;) >> >> It works like this: >> The feature is requested from geoserver as a GML. The GML is double >> rendered: as a line and as a series of circles. On each circle there are >> eventhandlers on mouseover,-out,-down,-up Depending if the add/delete >> point function is enabled they behave differently (add a point, remove a >> point, move a point). On the mouseup event the GML is updated and the >> line is drawn again. >> >> My question is if this can be done with canvas as well, since putting >> eventhandlers on lines/points etc proves to be a very easy way to modify >> features. >> >> The essential (very hackish) code is in >> http://svn.codehaus.org/mapbuilder/sandbox/steven/FeatureEditing/ >> >> Steven >> >> -- >> Geodan S&R Amsterdam >> >> ------------------------------------- >> Geodan S&R >> President Kennedylaan 1 >> 1079 MB Amsterdam (NL) >> ------------------------------------- >> Tel: +31 (0)20 - 5711 311 >> Fax: +31 (0)20 - 5711 333 >> ------------------------------------- >> E-mail: steven.ottens@geodan.nl >> Website: www.geodan.nl >> Disclaimer: www.geodan.nl/disclaimer >> ------------------------------------- >> >> >> >> --------------------------------------------------------------------- >> 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 > > -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From cameron.shorter at gmail.com Fri Nov 3 15:49:04 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] comments on osgeo design in wiki In-Reply-To: References: Message-ID: <454BAB40.8020606@gmail.com> chris wrote: > Hi All, > > Cameron invited me to put comments intot he wiki but my comments are > fairly general and long winded so I thought it would be more > appropriate to put them here. keep in mind I know nothing of > Javascript and I also tend to think of high level design in terms of > building interface walls between the more changeable functionality and > the more generic. > > Generally, it all looks good. My main feeling is that design seems to > have begun too low level, I'd like to see the bigger architectural > picture. Would help to define this as a geospatial pipeline > architecture (e.g. like in attached image) and work from there > Including main pipeline stages: network, Object System (OS), User IO, > graphic Display System (DS), server communication (full duplex > handling of user requests, tracking, collaboration info (chat etc), > data fetch and service requests). I don't see classes for the server > side processing ? but that is potentially where a lot of the work will > be done. Fair point about the design being too low level. The aim of the design is to explain to OpenLayers developers how we should extend OpenLayers. I'd like document the OpenLayers design but that is beyond scope. > > I started to get a picture of how class hierarchies shown work > together as a whole after seeing the parser diagram at the bottom. Is > the parser the highest level class? There are a number of other OpenLayers classes which are not included in my diagram. You can have a look at the class documentation at http://openlayers.org/ . > > I think it is very useful in the long term to have clear separation > between object system and display system, think of the OS as the model > and the DS as the View in a MVC design. A monolithic object/display > class hierarchy gets too unweildy (I note the text on keeping the > separation at a higher level still). In my Phd research and work on > planet-earth.org and other geospatial stuff I find this separation > essential to ensure high fidelity over large scale ? e.g. it helps > with applying a floating origin > (http://planet-earth.org/cw05/FloatingOrigin.pdf). Note: although I > work from a 3D perspective :) these numerical matters also apply to > 2D. I'm all for the Model/View/Controller design pattern. (That is how we coded Mapbuilder). OpenLayers goal is to provide a wrapper over Yahoo/Google/MSN maps and consequently have lined up with the Y/G/M maps design, which is not a strict MVC. The graphics code I'm proposing is aimed at fitting in the the existing OpenLayers code. > > Separation again: if u can define class or classes that isolate the > code that is needed to make client cross browser/OS portable then that > would go a long way to ensure its longevity. I think it will be > perilous to ignore historical experience, despite the hype/excitement > over Ajax: http://www.coachwei.com/blog/_archives/2006/9/27/2367882.html > . On this subject, I see some DOM calls. From what I gather, some > people believe that using DOM can alleviate many of the platform > portability issues. I hope this is the case. The platform incompatability issues will be in the Graphics packages which has a well defined generic interface - protected through a Abtract Factory, and in the Parser code which will need XML calls. Again, the Parser code will use a cross browser library. (I will be initially using Mapbuilder code for this which uses http://sarissa.sf.net ) > > I assume the raster layer class is to be the image data handler. I'm > not sure there is enough here: what about interface class (or rather, > abstract class) for layer::raster to use for multiple image format > handling and also have a look at multirez image handling (tiling). > This would provide layer with a consistent interface but handle the > dynamic loading of whatever image reader was required. All then proly > need to be extended to "tiled" versions. The OpenLayers guys have already written WMS and Titled WMS, Yahoo, MSN, Google layers (which are all raster based). I'm not sure whether the RasterLayer will actually become a class, it is just a suggestion which might or might not be acted upon. > > Use cases are v low level. Need to take a step back and look at the > big picture. Perhaps look at use cases for w3d Geospatial Incubator > Group: http://www.w3.org/2005/Incubator/geo/charter. Note the emphasis > on handling semantic as well as spatial searches, and the inclusion of > time. Point taken. There are quite a few other use cases which I haven't got round to adding yet. > > No interface classes are shown. > A high level analysis of functionality > that changes over a range of use cases versus functionality that is > common would be useful. Interfaces can then be defined to separate the > more dynamic from the more stable functionality that gets reused > across use cases. E.g. the processing of geo data has a number of > generic, stable operations (overlay, draw etc) that are always used no > matter if the input is from GML, KML, a DEM format, image data etc. > So, an interface class can be defined to provide a common interface > for all these and it dynamically loads the GML reader if the user is > just getting GML or some other reader as appropriate. Saves on client > run time footprint and also breaks up the design nicely. All the data > format readers form the dynamic part separated from the stable part by > the interface. Note: I tend to use this sort of pattern in java and > don't know if you can use such dynamic loading in javascript, but > perhaps the same design principles should apply. Note I use the term > interface loosely: in Java terms I often use an "abstract" class > rather than an "interface" class because it usually has some method > code in it. Javascript doesn't have a concept of an interface class like Java. You simulate an interface through inheritance. I think I have this concept built in to an extent. > > Need to have objects for spatial reference model: > (http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_18026_Ed1.html). Yes, I haven't addressed SRS in this design. I'm only focusing on the Vector Rendering part of the design. The Spacial Reference System (SRS) is part of the Geography classes (I just haven't included it in the attributes). > > e.g. need objects for Ellipsoid, datum, SRS, projection, etc. this > site: http://www.ai.sri.com/geovrml/1.1/doc/concepts.html has a nice > subset that I think could be adopted. Yes, I haven't included to keep the UML simple. These classes should follow the GML naming convensions. > > What about supporting 3D data? Consider: output can go to either 2D or > 3D. Most geodata maps into a 3D position, in general so perhaps a > layer can be defined that preserves the 3D. Time data is significant > too. Good point, you might be able to help in designing this. GML3 can store 2D or 3D Geometries. There will probably need to be a 3D Graphics class, and maybe a 3DRenderer too. > > Consider how you are going to handle scaling from earth to human scale. Yes this is a big problem to address and I have given a lot of thought to it, but I think there is a lot of room for optimisation. Initially, I think we will have a different layer for each zoom level. > > Consider the handling of LOD. Multirrez tiling essential. LOD? > > Is "Line" a polyline? Yes. > > > -- > > cheers, > > chris > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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 cameron.shorter at gmail.com Fri Nov 3 19:47:44 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector editing movie In-Reply-To: <454B4280.1030109@geodan.nl> References: <454B4280.1030109@geodan.nl> Message-ID: <454BE330.7080609@gmail.com> Steven, My understanding is that canvas is faster than SVG, but doesn't provide mouseEvents for each feature. Paul Spencer was considering writing a featureSearch algorithm to similar the featureEvents you get from SVG/VML. Steven M. Ottens wrote: > Hi list, > > I'm a bit behind with the whole vector discussion, since I'm on a tight > deadline to produce feature editing functionality. Building upon Patrice > work in Mapbuilder I wrote functionality to display features in SVG/VML > (Patrice work) and drag the vertices around and add/remove vertices. > Currently the application is behind a firewall, so I can only give you > all a screencast: > http://jana.geodan.nl/steveno/Untitled.html and you've to take my word > for it that it actually works both in FF and in IE. :) > This is how I like to see feature editing in our uber-webmap-client ;) > > It works like this: > The feature is requested from geoserver as a GML. The GML is double > rendered: as a line and as a series of circles. On each circle there are > eventhandlers on mouseover,-out,-down,-up Depending if the add/delete > point function is enabled they behave differently (add a point, remove a > point, move a point). On the mouseup event the GML is updated and the > line is drawn again. > > My question is if this can be done with canvas as well, since putting > eventhandlers on lines/points etc proves to be a very easy way to modify > features. > > The essential (very hackish) code is in > http://svn.codehaus.org/mapbuilder/sandbox/steven/FeatureEditing/ > > Steven > -- Cameron Shorter http://cameron.shorter.net From cameron.shorter at gmail.com Wed Nov 8 05:49:10 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Vector rendering status? Message-ID: <4551B626.3020502@gmail.com> Paul and Anselm, Where are you at with regards to vector rendering code? I'm planning to start coding in the next day or two and want to fit in with what has already been done. Bertil and Pierre plan to commit their code to SVN today. I'm hoping to review both code bases and make recommendations on how we can merge them into one. I'm assuming all the code is in the OpenLayers sandbox? -- Cameron Shorter http://cameron.shorter.net From pspencer at dmsolutions.ca Wed Nov 8 08:39:31 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:43 2006 Subject: Vector rendering status? In-Reply-To: <4551B626.3020502@gmail.com> References: <4551B626.3020502@gmail.com> Message-ID: <00AFF025-50A7-44D9-8B3F-15B8BE83720C@dmsolutions.ca> Cameron, I haven't had a chance to work on the code at all. I'm stuck on a tight deadline for this week. I will probably have a chance to work on this either Friday or perhaps the weekend though. Cheers Paul On 8-Nov-06, at 5:49 AM, Cameron Shorter wrote: > Paul and Anselm, > Where are you at with regards to vector rendering code? > > I'm planning to start coding in the next day or two and want to fit > in with what has already been done. > > Bertil and Pierre plan to commit their code to SVN today. > > I'm hoping to review both code bases and make recommendations on > how we can merge them into one. > > I'm assuming all the code is in the OpenLayers sandbox? > > -- > Cameron Shorter > http://cameron.shorter.net +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Wed Nov 8 23:38:56 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Code Review - proposal for vector code merger Message-ID: <4552B0E0.2050305@gmail.com> Paul, Anselm, Bertil, Pierre, I've reviewed both your code bases which I've written up at: http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design#Code_Review In essence, the designs are very similar, so I think a merger can be done without too much pain. In summary, I think we should start from the Camp2Camp (Bertil and Pierre) codebase, and apply functions, style and comments from Paul's codebase. There are a couple of potential points of contention: 1. Layer/Vector is similar but uses different functions. 2. The Rendering. I hope we can work though these issues as I'm exited by the chance to be working with you all on the same codebase. -- Cameron Shorter http://cameron.shorter.net From bluecarto at gmail.com Thu Nov 9 11:04:54 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:43 2006 Subject: vector layer - GML parsing and rendering - first test Message-ID: At the url below you will find a first quick and dirty test for a GML parser (WFS file). It loads a xml file (that simulates a WFS response) and renders the features geometries on the map. May only work on safari for the moment. Note that the datastore (us intersate) comprise 13379 vertices. http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html Regards Pierre From steven.ottens at geodan.nl Thu Nov 9 11:14:16 2006 From: steven.ottens at geodan.nl (Steven M. Ottens) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: References: Message-ID: <455353D8.4070903@geodan.nl> Looks good, it works in firefox as well, strangely not in flock a mozilla based browser which I use besides my heavily pimped firefox. It takes a few seconds to load/parse the gml (about 10 rough count) and after that it's fast Steven Pierre GIRAUD wrote: > At the url below you will find a first quick and dirty test for a GML > parser (WFS file). > It loads a xml file (that simulates a WFS response) and renders the > features geometries on the map. > May only work on safari for the moment. > > Note that the datastore (us intersate) comprise 13379 vertices. > > http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html > -- Geodan S&R Amsterdam ------------------------------------- Geodan S&R President Kennedylaan 1 1079 MB Amsterdam (NL) ------------------------------------- Tel: +31 (0)20 - 5711 311 Fax: +31 (0)20 - 5711 333 ------------------------------------- E-mail: steven.ottens@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer ------------------------------------- From bluecarto at gmail.com Thu Nov 9 11:18:30 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: <455353D8.4070903@geodan.nl> References: <455353D8.4070903@geodan.nl> Message-ID: Sorry, was thinking Firefox (not Safari) ! On 11/9/06, Steven M. Ottens wrote: > Looks good, it works in firefox as well, strangely not in flock a > mozilla based browser which I use besides my heavily pimped firefox. It > takes a few seconds to load/parse the gml (about 10 rough count) and > after that it's fast > > Steven > > Pierre GIRAUD wrote: > > At the url below you will find a first quick and dirty test for a GML > > parser (WFS file). > > It loads a xml file (that simulates a WFS response) and renders the > > features geometries on the map. > > May only work on safari for the moment. > > > > Note that the datastore (us intersate) comprise 13379 vertices. > > > > http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html > > > > > -- > Geodan S&R Amsterdam > > ------------------------------------- > Geodan S&R > President Kennedylaan 1 > 1079 MB Amsterdam (NL) > ------------------------------------- > Tel: +31 (0)20 - 5711 311 > Fax: +31 (0)20 - 5711 333 > ------------------------------------- > E-mail: steven.ottens@geodan.nl > Website: www.geodan.nl > Disclaimer: www.geodan.nl/disclaimer > ------------------------------------- > > > > --------------------------------------------------------------------- > 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 Thu Nov 9 22:39:36 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: References: <455353D8.4070903@geodan.nl> Message-ID: <4553F478.8030206@gmail.com> Looks good. We have a GML parser in Mapbuilder which you might want to refer to. It extracts coordinates out of GML2 and GML3. In Mapbuilder we rely quite heavilly on using XPATH for extracting nodes out of XML. For example, we use lines like: this.gmlType=featureNodes[0].selectSingleNode(".//gml:Point|.//gml:LineString|.//gml:Polygon|.//gml:LinearRing|.//gml:Box|.//gml:Envelope"); We use http://sarissa.sf.net to provide cross browser XPATH functionality. At the moment, OpenLayers doesn't provide XPATH support. I'll send an email to openlayers suggesting it. Pierre GIRAUD wrote: > Sorry, was thinking Firefox (not Safari) ! > > On 11/9/06, Steven M. Ottens wrote: > >> Looks good, it works in firefox as well, strangely not in flock a >> mozilla based browser which I use besides my heavily pimped firefox. It >> takes a few seconds to load/parse the gml (about 10 rough count) and >> after that it's fast >> >> Steven >> >> Pierre GIRAUD wrote: >> > At the url below you will find a first quick and dirty test for a GML >> > parser (WFS file). >> > It loads a xml file (that simulates a WFS response) and renders the >> > features geometries on the map. >> > May only work on safari for the moment. >> > >> > Note that the datastore (us intersate) comprise 13379 vertices. >> > >> > http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html >> > >> >> >> -- >> Geodan S&R Amsterdam >> >> ------------------------------------- >> Geodan S&R >> President Kennedylaan 1 >> 1079 MB Amsterdam (NL) >> ------------------------------------- >> Tel: +31 (0)20 - 5711 311 >> Fax: +31 (0)20 - 5711 333 >> ------------------------------------- >> E-mail: steven.ottens@geodan.nl >> Website: www.geodan.nl >> Disclaimer: www.geodan.nl/disclaimer >> ------------------------------------- >> >> >> >> --------------------------------------------------------------------- >> 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 cameron.shorter at gmail.com Thu Nov 9 23:52:59 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: References: <455353D8.4070903@geodan.nl> Message-ID: <455405AB.80401@gmail.com> Pierre, Bertil, I notice you have a dependancy upon prototype.js. As I understand it, Openlayers are trying to break this dependancy. Are you able to remove the requirement for prototype? Pierre GIRAUD wrote: > Sorry, was thinking Firefox (not Safari) ! > > On 11/9/06, Steven M. Ottens wrote: > >> Looks good, it works in firefox as well, strangely not in flock a >> mozilla based browser which I use besides my heavily pimped firefox. It >> takes a few seconds to load/parse the gml (about 10 rough count) and >> after that it's fast >> >> Steven >> >> Pierre GIRAUD wrote: >> > At the url below you will find a first quick and dirty test for a GML >> > parser (WFS file). >> > It loads a xml file (that simulates a WFS response) and renders the >> > features geometries on the map. >> > May only work on safari for the moment. >> > >> > Note that the datastore (us intersate) comprise 13379 vertices. >> > >> > http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html >> > >> >> >> -- >> Geodan S&R Amsterdam >> >> ------------------------------------- >> Geodan S&R >> President Kennedylaan 1 >> 1079 MB Amsterdam (NL) >> ------------------------------------- >> Tel: +31 (0)20 - 5711 311 >> Fax: +31 (0)20 - 5711 333 >> ------------------------------------- >> E-mail: steven.ottens@geodan.nl >> Website: www.geodan.nl >> Disclaimer: www.geodan.nl/disclaimer >> ------------------------------------- >> >> >> >> --------------------------------------------------------------------- >> 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 bluecarto at gmail.com Fri Nov 10 01:53:27 2006 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: <455405AB.80401@gmail.com> References: <455353D8.4070903@geodan.nl> <455405AB.80401@gmail.com> Message-ID: I do know that the OL team tries not to depend on prototype. It was debated at the FOSS4G meeting. I think that the only method I'm using is the each() iterator. It wouldn't be difficult to rewrite it and include it OL. I will try today. Or I would be pleased if someone helps. Regards On 11/10/06, Cameron Shorter wrote: > Pierre, Bertil, > I notice you have a dependancy upon prototype.js. > As I understand it, Openlayers are trying to break this dependancy. Are > you able to remove the requirement for prototype? > > Pierre GIRAUD wrote: > > Sorry, was thinking Firefox (not Safari) ! > > > > On 11/9/06, Steven M. Ottens wrote: > > > >> Looks good, it works in firefox as well, strangely not in flock a > >> mozilla based browser which I use besides my heavily pimped firefox. It > >> takes a few seconds to load/parse the gml (about 10 rough count) and > >> after that it's fast > >> > >> Steven > >> > >> Pierre GIRAUD wrote: > >> > At the url below you will find a first quick and dirty test for a GML > >> > parser (WFS file). > >> > It loads a xml file (that simulates a WFS response) and renders the > >> > features geometries on the map. > >> > May only work on safari for the moment. > >> > > >> > Note that the datastore (us intersate) comprise 13379 vertices. > >> > > >> > http://dev.openlayers.org/sandbox/bertil/examples/wfs_features.html > >> > > >> > >> > >> -- > >> Geodan S&R Amsterdam > >> > >> ------------------------------------- > >> Geodan S&R > >> President Kennedylaan 1 > >> 1079 MB Amsterdam (NL) > >> ------------------------------------- > >> Tel: +31 (0)20 - 5711 311 > >> Fax: +31 (0)20 - 5711 333 > >> ------------------------------------- > >> E-mail: steven.ottens@geodan.nl > >> Website: www.geodan.nl > >> Disclaimer: www.geodan.nl/disclaimer > >> ------------------------------------- > >> > >> > >> > >> --------------------------------------------------------------------- > >> 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 pspencer at dmsolutions.ca Sat Nov 11 14:58:38 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: References: <455353D8.4070903@geodan.nl> <455405AB.80401@gmail.com> Message-ID: <70B3E202-CEA4-4E24-9571-DDF408628181@dmsolutions.ca> I'm working on sandbox/vector, taking a look at the code and perhaps moving a canvas renderer in there. As a first step, I've removed all the each() calls and fixed something in vector.html that was preventing OpenLayers from starting in Safari. Cheers Paul On 10-Nov-06, at 1:53 AM, Pierre GIRAUD wrote: > I do know that the OL team tries not to depend on prototype. It was > debated at the FOSS4G meeting. > I think that the only method I'm using is the each() iterator. It > wouldn't be difficult to rewrite it and include it OL. > I will try today. Or I would be pleased if someone helps. > > Regards > > On 11/10/06, Cameron Shorter wrote: >> Pierre, Bertil, >> I notice you have a dependancy upon prototype.js. >> As I understand it, Openlayers are trying to break this >> dependancy. Are >> you able to remove the requirement for prototype? >> >> Pierre GIRAUD wrote: >> > Sorry, was thinking Firefox (not Safari) ! >> > >> > On 11/9/06, Steven M. Ottens wrote: >> > >> >> Looks good, it works in firefox as well, strangely not in flock a >> >> mozilla based browser which I use besides my heavily pimped >> firefox. It >> >> takes a few seconds to load/parse the gml (about 10 rough >> count) and >> >> after that it's fast >> >> >> >> Steven >> >> >> >> Pierre GIRAUD wrote: >> >> > At the url below you will find a first quick and dirty test >> for a GML >> >> > parser (WFS file). >> >> > It loads a xml file (that simulates a WFS response) and >> renders the >> >> > features geometries on the map. >> >> > May only work on safari for the moment. >> >> > >> >> > Note that the datastore (us intersate) comprise 13379 vertices. >> >> > >> >> > http://dev.openlayers.org/sandbox/bertil/examples/ >> wfs_features.html >> >> > >> >> >> >> >> >> -- >> >> Geodan S&R Amsterdam >> >> >> >> ------------------------------------- >> >> Geodan S&R >> >> President Kennedylaan 1 >> >> 1079 MB Amsterdam (NL) >> >> ------------------------------------- >> >> Tel: +31 (0)20 - 5711 311 >> >> Fax: +31 (0)20 - 5711 333 >> >> ------------------------------------- >> >> E-mail: steven.ottens@geodan.nl >> >> Website: www.geodan.nl >> >> Disclaimer: www.geodan.nl/disclaimer >> >> ------------------------------------- >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Sun Nov 12 08:29:52 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: References: <455353D8.4070903@geodan.nl> <455405AB.80401@gmail.com> Message-ID: <80EF2620-8AB2-493E-BF9B-1656807BA4AD@dmsolutions.ca> Some comments on the code: Layer.Vector * doesn't use Renderer.getBestRenderer (which seems like an oversight) * I think getBestRenderer needs to be moved into Layer.Vector and Renderer needs to be the base class for all renderers (see below) Renderer base class ... It seems to me that there are a lot of functions that are required of a renderer but these are not 'documented' in the base class. This makes it difficult to understand how to implement a new renderer (like Canvas). We need to create a base class Renderer that has all the public and private functions and attributes that external code relies on, and then subclass this for each of Vml, Svg, Canvas, and whatever else (wz for instance). Here is my quick summary of the Svg and Vml code as I see it in svn: (- means I think it is a private member, + means I think it is a public member) Attributes: + eventManager (accessed directly in Layer.Vector) - root - style (note initialized directly rather than using Style class) - svgns (in Svg only) - vmlns (in Vml only) - container (not declared) - vmlRoot (not declared, in Vml only) - svgRoot (not declared, in Svg only) - rootWidth (not declared, in Vml only) - rootHeight (not declared, in Vml only) - divWidth (not declared, in Vml only) - divHeight (not declared, in Vml only) Public Methods: + initialize (implicitly called by new operator) + setStyle + getStyle (in Svg only) + observe (called from generic code in vector.html) + dispose + setEventManager (called from Layer.Vector) + drawRoot (called from Layer.Vector) + clearRoot + setExtent (called from Layer.Vector) + setSize (called from Layer.Vector) + highlightGeometry (in Vml only) + drawGeometry (called from Layer.Vector, Control.Editing) + eraseElement (called from Layer.Vector, Control.Editing) Private Methods - triggEditingEvent - drawPoint - drawRectangle - drawCircle (in Svg only) - drawEllipse - drawLineString - drawLinearRing - drawPolygon - drawCurve - drawSurface - _setStyle (in Svg only) - _getFillElement (in Vml only) - _getStrokeElement (in Vml only) - _getVmlBoundingBox (in Vml only) - _nodeFactory - _vmlParseFloat (in Vml only) I am going to propose some changes based on the following comments and observations: * I don't like Style being a part of the renderer. I think the Style should be associated with the layer and geometry objects * I don't like using a new renderer instance for each layer, I think it would be better to use a single renderer for multiple layers * I don't like the way the eventManager and observe/dispose work. It seems difficult to follow how it works. It also won't work if the above change is made. I think this can be moved into Layer.Vector without too much difficulty by: - overloading setMap in Layer.Vector and registering for the events there - generic eventHandler function in Layer.Vector that calls this.renderer.GetGeometryFromEvent on renderer (for Vml/Svg, this would be the basic This seems a lot cleaner to me. * drawRoot/clearRoot renamed to attach/detach - attach a renderer to a layer. * I think setExtent and setSize should be merged and setExtent should take top, left, width, height in pixel positions (managed by the layer) * there are some implementation details and concepts in Vml and Svg rendering that have no meaning in Canvas and don't really seem to fit the model. The big one seems to be that in Vml and Svg, the rendered element is actually a dom element and needs to have an id and be attached in the dom somewhere. There is no parallel for this in Canvas. I am undecided as to whether this is a problem and how to deal with it. We can either go with the Vml/Svg model and just ignore stuff in Canvas, remove it in the general case and create a new sub-class for vector-based renders (yuck), or move the implementation details of Vml/Svg into the code rather than the public interface (my preference). I've committed a new version of Renderer.js to the vector sandbox (since I don't think it will break anything - it wasn't used anywhere AFAIK) that implements my proposed base class. There are some changes that I would like to make to the Svg and Vml renderers to implement the new architecture. I'm hoping to have a bit of time today to work on that plus the start of a Canvas renderer. Cheers Paul On 10-Nov-06, at 1:53 AM, Pierre GIRAUD wrote: > I do know that the OL team tries not to depend on prototype. It was > debated at the FOSS4G meeting. > I think that the only method I'm using is the each() iterator. It > wouldn't be difficult to rewrite it and include it OL. > I will try today. Or I would be pleased if someone helps. > > Regards > > On 11/10/06, Cameron Shorter wrote: >> Pierre, Bertil, >> I notice you have a dependancy upon prototype.js. >> As I understand it, Openlayers are trying to break this >> dependancy. Are >> you able to remove the requirement for prototype? >> >> Pierre GIRAUD wrote: >> > Sorry, was thinking Firefox (not Safari) ! >> > >> > On 11/9/06, Steven M. Ottens wrote: >> > >> >> Looks good, it works in firefox as well, strangely not in flock a >> >> mozilla based browser which I use besides my heavily pimped >> firefox. It >> >> takes a few seconds to load/parse the gml (about 10 rough >> count) and >> >> after that it's fast >> >> >> >> Steven >> >> >> >> Pierre GIRAUD wrote: >> >> > At the url below you will find a first quick and dirty test >> for a GML >> >> > parser (WFS file). >> >> > It loads a xml file (that simulates a WFS response) and >> renders the >> >> > features geometries on the map. >> >> > May only work on safari for the moment. >> >> > >> >> > Note that the datastore (us intersate) comprise 13379 vertices. >> >> > >> >> > http://dev.openlayers.org/sandbox/bertil/examples/ >> wfs_features.html >> >> > >> >> >> >> >> >> -- >> >> Geodan S&R Amsterdam >> >> >> >> ------------------------------------- >> >> Geodan S&R >> >> President Kennedylaan 1 >> >> 1079 MB Amsterdam (NL) >> >> ------------------------------------- >> >> Tel: +31 (0)20 - 5711 311 >> >> Fax: +31 (0)20 - 5711 333 >> >> ------------------------------------- >> >> E-mail: steven.ottens@geodan.nl >> >> Website: www.geodan.nl >> >> Disclaimer: www.geodan.nl/disclaimer >> >> ------------------------------------- >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org > For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Sun Nov 12 14:20:22 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] vector layer - GML parsing and rendering - first test In-Reply-To: <80EF2620-8AB2-493E-BF9B-1656807BA4AD@dmsolutions.ca> References: <455353D8.4070903@geodan.nl> <455405AB.80401@gmail.com> <80EF2620-8AB2-493E-BF9B-1656807BA4AD@dmsolutions.ca> Message-ID: <455773F6.1040406@gmail.com> Paul, a lot of good suggestions in here. My only addition to your suggestion which I've been pushing is that we split the current Renderer class into one Renderer class and a Sheet class. Renderer contains a paintGeometry function, and uses Geometry+Style to build drawing requests. Sheet contains the base vector rendering functions: drawLine(), drawCircle() ... We then create SvgSheet, VmlSheet, CanvasSheet etc. This keeps the Graphics code seperate from the GIS code. Paul Spencer wrote: > Some comments on the code: > > Layer.Vector > > * doesn't use Renderer.getBestRenderer (which seems like an oversight) > * I think getBestRenderer needs to be moved into Layer.Vector and > Renderer needs to be the base class for all renderers (see below) > > Renderer base class ... > > It seems to me that there are a lot of functions that are required of a > renderer but these are not 'documented' in the base class. This makes > it difficult to understand how to implement a new renderer (like > Canvas). We need to create a base class Renderer that has all the > public and private functions and attributes that external code relies > on, and then subclass this for each of Vml, Svg, Canvas, and whatever > else (wz for instance). > > Here is my quick summary of the Svg and Vml code as I see it in svn: > > (- means I think it is a private member, + means I think it is a public > member) > > Attributes: > > + eventManager (accessed directly in Layer.Vector) > - root > - style (note initialized directly rather than using Style class) > - svgns (in Svg only) > - vmlns (in Vml only) > - container (not declared) > - vmlRoot (not declared, in Vml only) > - svgRoot (not declared, in Svg only) > - rootWidth (not declared, in Vml only) > - rootHeight (not declared, in Vml only) > - divWidth (not declared, in Vml only) > - divHeight (not declared, in Vml only) > > Public Methods: > > + initialize (implicitly called by new operator) > + setStyle > + getStyle (in Svg only) > + observe (called from generic code in vector.html) > + dispose > + setEventManager (called from Layer.Vector) > + drawRoot (called from Layer.Vector) > + clearRoot > + setExtent (called from Layer.Vector) > + setSize (called from Layer.Vector) > + highlightGeometry (in Vml only) > + drawGeometry (called from Layer.Vector, Control.Editing) > + eraseElement (called from Layer.Vector, Control.Editing) > > Private Methods > - triggEditingEvent > - drawPoint > - drawRectangle > - drawCircle (in Svg only) > - drawEllipse > - drawLineString > - drawLinearRing > - drawPolygon > - drawCurve > - drawSurface > - _setStyle (in Svg only) > - _getFillElement (in Vml only) > - _getStrokeElement (in Vml only) > - _getVmlBoundingBox (in Vml only) > - _nodeFactory > - _vmlParseFloat (in Vml only) > > I am going to propose some changes based on the following comments and > observations: > > * I don't like Style being a part of the renderer. I think the Style > should be associated with the layer and geometry objects > > * I don't like using a new renderer instance for each layer, I think it > would be better to use a single renderer for multiple layers > > * I don't like the way the eventManager and observe/dispose work. It > seems difficult to follow how it works. It also won't work if the > above change is made. I think this can be moved into Layer.Vector > without too much difficulty by: > > - overloading setMap in Layer.Vector and registering for the events > there > - generic eventHandler function in Layer.Vector that calls > this.renderer.GetGeometryFromEvent on renderer (for Vml/Svg, this would > be the basic > > This seems a lot cleaner to me. > > * drawRoot/clearRoot renamed to attach/detach - attach a renderer to a > layer. > > * I think setExtent and setSize should be merged and setExtent should > take top, left, width, height in pixel positions (managed by the layer) > > * there are some implementation details and concepts in Vml and Svg > rendering that have no meaning in Canvas and don't really seem to fit > the model. The big one seems to be that in Vml and Svg, the rendered > element is actually a dom element and needs to have an id and be > attached in the dom somewhere. There is no parallel for this in > Canvas. I am undecided as to whether this is a problem and how to deal > with it. We can either go with the Vml/Svg model and just ignore stuff > in Canvas, remove it in the general case and create a new sub-class for > vector-based renders (yuck), or move the implementation details of > Vml/Svg into the code rather than the public interface (my preference). > > I've committed a new version of Renderer.js to the vector sandbox > (since I don't think it will break anything - it wasn't used anywhere > AFAIK) that implements my proposed base class. > > There are some changes that I would like to make to the Svg and Vml > renderers to implement the new architecture. I'm hoping to have a bit > of time today to work on that plus the start of a Canvas renderer. > > Cheers > > Paul > > On 10-Nov-06, at 1:53 AM, Pierre GIRAUD wrote: > >> I do know that the OL team tries not to depend on prototype. It was >> debated at the FOSS4G meeting. >> I think that the only method I'm using is the each() iterator. It >> wouldn't be difficult to rewrite it and include it OL. >> I will try today. Or I would be pleased if someone helps. >> >> Regards >> >> On 11/10/06, Cameron Shorter wrote: >> >>> Pierre, Bertil, >>> I notice you have a dependancy upon prototype.js. >>> As I understand it, Openlayers are trying to break this dependancy. Are >>> you able to remove the requirement for prototype? >>> >>> Pierre GIRAUD wrote: >>> > Sorry, was thinking Firefox (not Safari) ! >>> > >>> > On 11/9/06, Steven M. Ottens wrote: >>> > >>> >> Looks good, it works in firefox as well, strangely not in flock a >>> >> mozilla based browser which I use besides my heavily pimped >>> firefox. It >>> >> takes a few seconds to load/parse the gml (about 10 rough count) and >>> >> after that it's fast >>> >> >>> >> Steven >>> >> >>> >> Pierre GIRAUD wrote: >>> >> > At the url below you will find a first quick and dirty test for >>> a GML >>> >> > parser (WFS file). >>> >> > It loads a xml file (that simulates a WFS response) and renders >>> the >>> >> > features geometries on the map. >>> >> > May only work on safari for the moment. >>> >> > >>> >> > Note that the datastore (us intersate) comprise 13379 vertices. >>> >> > >>> >> > http://dev.openlayers.org/sandbox/bertil/examples/ >>> wfs_features.html >>> >> > >>> >> >>> >> >>> >> -- >>> >> Geodan S&R Amsterdam >>> >> >>> >> ------------------------------------- >>> >> Geodan S&R >>> >> President Kennedylaan 1 >>> >> 1079 MB Amsterdam (NL) >>> >> ------------------------------------- >>> >> Tel: +31 (0)20 - 5711 311 >>> >> Fax: +31 (0)20 - 5711 333 >>> >> ------------------------------------- >>> >> E-mail: steven.ottens@geodan.nl >>> >> Website: www.geodan.nl >>> >> Disclaimer: www.geodan.nl/disclaimer >>> >> ------------------------------------- >>> >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >>> >> 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 >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: webmap-discuss-unsubscribe@mail.osgeo.org >> For additional commands, e-mail: webmap-discuss-help@mail.osgeo.org >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > --------------------------------------------------------------------- > 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 cameron.shorter at gmail.com Thu Nov 16 17:34:31 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Using JSON instead of XML for OGC documents Message-ID: <455CE777.2050802@gmail.com> Context working group, Regarding: http://json.org There has been discussion amongst http://openlayers.org developers about using JSON instead of XML for storing OGC documents (like OGC Context, WMC, and probably a host of other documents too). The reason for considering JSON over XML are: * In Web Browsers, XML support is patchy. * Consequently extra code is required to be downloaded to cover all browsers. * In browser clients, code size is a major consideration as size=bandwidth=speed. * JSON is reportedly faster to process. JSON reportedly has all the other advantages of XML like being structured, easy to read, is supported by multiple languages etc. One thing discussed is standing up XML<->JSON services. I'd be interested to hear comments from OGC participants on these ideas. Feel free to foward onto others more appropriate. -- Cameron Shorter http://cameron.shorter.net From pspencer at dmsolutions.ca Thu Nov 16 22:45:19 2006 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Using JSON instead of XML for OGC documents In-Reply-To: <455CE777.2050802@gmail.com> References: <455CE777.2050802@gmail.com> Message-ID: Another factor is the inability of javascript-only clients (such as OpenLayers and MapBuilder) to directly request XML documents from remote servers due to security constraints, making it impossible to work with some of the more interesting OGC stuff without using some kind of workaround (such as proxy scripts etc). Paul On 16-Nov-06, at 5:34 PM, Cameron Shorter wrote: > Context working group, > > Regarding: http://json.org > > There has been discussion amongst http://openlayers.org developers > about using JSON instead of XML for storing OGC documents (like OGC > Context, WMC, and probably a host of other documents too). > > The reason for considering JSON over XML are: > * In Web Browsers, XML support is patchy. > * Consequently extra code is required to be downloaded to cover all > browsers. > * In browser clients, code size is a major consideration as > size=bandwidth=speed. > * JSON is reportedly faster to process. > > JSON reportedly has all the other advantages of XML like being > structured, easy to read, is supported by multiple languages etc. > > One thing discussed is standing up XML<->JSON services. > > I'd be interested to hear comments from OGC participants on these > ideas. > > Feel free to foward onto others more appropriate. > > -- > 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 > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Thu Nov 16 22:55:35 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [Context.RWG] Using JSON instead of XML for OGC documents In-Reply-To: References: <455CE777.2050802@gmail.com> Message-ID: <455D32B7.3000101@gmail.com> Without trying to claim to be a JSON expert, I found this link which suggests that JSON can be used to display nested structures. http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html XML: text text JSON: "e": { "a": "text", "b": { "c": "text" } } Joshua Lieberman wrote: > A quick look suggests that JSON is lightweight and easy because it's -- > KVP. It may be easy to pass and to process but there are reason's (total > obscuration of document structure, etc.) that XML has been preferred for > more complex messages. One can certainly deconvolve XML into an infoset > representation to serialize in KVP, but it can't be any easier to > process nested structures in this format and probably is harder. > > Now this can be taken the other way as a reason among others to maintain > and update KVP bindings for which JSON would be straightforward and > appropriate, and not be drawn into complex SOAP + XML for all > client-server interactions. > > As far as providing an alternate KVP serialization of such things as > context documents, I'm open to the possibility, but it does seem in > principle to be intended for richly hierarchical content, perhaps not > the best candidate for JSON. > > Josh > > Joshua Lieberman, Ph.D. > > Principal, Traverse Technologies Inc. > > mailto:jlieberman@traversetechnologies.com > > tel +1 (617) 395-7766 > > fax: +1 (815) 717-981 > > > > On Nov 16, 2006, at 5:34 PM, Cameron Shorter wrote: > >> Context working group, >> >> Regarding: http://json.org >> >> There has been discussion amongst http://openlayers.org developers about >> using JSON instead of XML for storing OGC documents (like OGC Context, >> WMC, and probably a host of other documents too). >> >> The reason for considering JSON over XML are: >> * In Web Browsers, XML support is patchy. >> * Consequently extra code is required to be downloaded to cover all >> browsers. >> * In browser clients, code size is a major consideration as >> size=bandwidth=speed. >> * JSON is reportedly faster to process. >> >> JSON reportedly has all the other advantages of XML like being >> structured, easy to read, is supported by multiple languages etc. >> >> One thing discussed is standing up XML<->JSON services. >> >> I'd be interested to hear comments from OGC participants on these ideas. >> >> Feel free to foward onto others more appropriate. >> >> -- >> Cameron Shorter >> http://cameron.shorter.net >> _______________________________________________ >> Context.rwg mailing list >> Context.rwg@opengeospatial.org >> https://mail.opengeospatial.org/mailman/listinfo/context.rwg > > -- Cameron Shorter http://cameron.shorter.net From crschmidt at metacarta.com Thu Nov 16 23:07:22 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: [Context.RWG] Using JSON instead of XML for OGC documents In-Reply-To: <455D32B7.3000101@gmail.com> References: <455CE777.2050802@gmail.com> <455D32B7.3000101@gmail.com> Message-ID: <20061117040722.GA730@metacarta.com> On Fri, Nov 17, 2006 at 02:55:35PM +1100, Cameron Shorter wrote: > Without trying to claim to be a JSON expert, I found this link which > suggests that JSON can be used to display nested structures. > http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html This is correct. > Joshua Lieberman wrote: > >A quick look suggests that JSON is lightweight and easy because it's -- > >KVP. A look which only brought this much information to light wasn't clear enough. That's half of it. The other half is what takes it beyond this. JSON.org says that JSON is: """ * A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array. * An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence. """ The rest of your (Josh's) reply was based around the idea that JSON is only KVP, so I will stop there, and if you still think JSON has failings in comparison to XML, I'd love to hear about them. -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Fri Nov 17 14:31:53 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [Fwd: Re: [Context.RWG] Using JSON instead of XML for OGC documents] Message-ID: <455E0E29.3070908@gmail.com> FYI -- Cameron Shorter http://cameron.shorter.net -------------- next part -------------- An embedded message was scrubbed... From: Jeff Yutzler Subject: Re: [Context.RWG] Using JSON instead of XML for OGC documents Date: Fri, 17 Nov 2006 13:06:39 -0500 Size: 4770 Url: http://lists.osgeo.org/pipermail/mail_webmap-discuss/attachments/20061118/cd0b1d0e/Context.mht From cameron.shorter at gmail.com Fri Nov 17 14:37:46 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: Using JSON instead of XML for OGC documents In-Reply-To: References: <455CE777.2050802@gmail.com> Message-ID: <455E0F8A.1040107@gmail.com> The biggest win for web browsers (performace wise) would be if Web Feature Services could return GML in JSON format. I'd imagine this would be relatively easy to incorporate into the WFS spec. Disclaimer: I still haven't done any performance tests with JSON. Raj Singh wrote: > Martin echoes my initial reaction. The bigger picture is the reliance > on XML data structures for information content. I don't think it's a > good idea to consider abandoning such a flexible, well-understood, > expressive format just because it's not ideal for one platform (Web > browsers), even if that platform is perhaps the primary parser of some > document types. > > Maybe a good long term strategy is to go with XML as the canonical > document format, but have some sort of "header" section that points to > other formats (or services that produce alternative formats). And make > that header easy enough to read that text parsers can easily pull out > enough information to avoid the rest and go get their preferred > document format. This strategy could apply not only to static document > formats like Context and SLD, but also to service responses like > GetCapabilities. > > --- > Raj > > On Nov 16, 2006, Martin Daly wrote: > >> We've also looked into JSON a bit, although not for Context documents. >> In this case not using XML for the first step seems to be just delaying >> the inevitable? That is, after you have the context data, the next step >> is always to get the capabilities of the server (see the recent e-mail >> trail about, for example, GetMap and GetCapabilities not sharing the >> same URL root). >> >> Unless all of the references services/data area also returned as JSON, >> then you will be parsing XML sooner rather than later. >> >> M > > > On Nov 16, 2006, at 5:34 PM, Cameron Shorter wrote: > >> Context working group, >> >> Regarding: http://json.org >> >> There has been discussion amongst http://openlayers.org developers >> about using JSON instead of XML for storing OGC documents (like OGC >> Context, WMC, and probably a host of other documents too). >> >> The reason for considering JSON over XML are: >> * In Web Browsers, XML support is patchy. >> * Consequently extra code is required to be downloaded to cover all >> browsers. >> * In browser clients, code size is a major consideration as >> size=bandwidth=speed. >> * JSON is reportedly faster to process. >> >> JSON reportedly has all the other advantages of XML like being >> structured, easy to read, is supported by multiple languages etc. >> >> One thing discussed is standing up XML<->JSON services. >> >> I'd be interested to hear comments from OGC participants on these ideas. >> >> Feel free to foward onto others more appropriate. >> >> -- >> Cameron Shorter >> http://cameron.shorter.net > > > -- Cameron Shorter http://cameron.shorter.net From schuyler at nocat.net Fri Nov 17 15:30:49 2006 From: schuyler at nocat.net (Schuyler Erle) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] [Fwd: Re: [Context.RWG] Using JSON instead of XML for OGC documents] In-Reply-To: <455E0E29.3070908@gmail.com> References: <455E0E29.3070908@gmail.com> Message-ID: <20061117203049.GY14127@vishnu.tridity.org> * On 17-Nov-2006 at 11:32AM PST, Cameron Shorter said: > > I believe the drawback to JSON compared to XML is that there is no > standard mechanism for validation. I don't see this as a problem. Most code can validate data structures just fine -- by throwing exceptions if the data struct doesn't have the members it expects. No sweat. SDE From adoyle at eogeo.org Fri Nov 17 16:32:56 2006 From: adoyle at eogeo.org (Allan Doyle) Date: Fri Dec 22 15:49:43 2006 Subject: [webmap-discuss] Re: Using JSON instead of XML for OGC documents In-Reply-To: <455E0F8A.1040107@gmail.com> References: <455CE777.2050802@gmail.com> <455E0F8A.1040107@gmail.com> Message-ID: <0F031A14-AB02-4AF0-9757-3601DCB8C4D1@eogeo.org> On Nov 17, 2006, at 14:37, Cameron Shorter wrote: > The biggest win for web browsers (performace wise) would be if Web > Feature Services could return GML in JSON format. I'd imagine this > would be relatively easy to incorporate into the WFS spec. AFAIK the WFS spec allows for alternate return formats. I know some people have used WFS's to return shapefiles. It should be a matter of declaring a MIME type in the capabilities or something. > > Disclaimer: I still haven't done any performance tests with JSON. > > Raj Singh wrote: >> Martin echoes my initial reaction. The bigger picture is the >> reliance on XML data structures for information content. I don't >> think it's a good idea to consider abandoning such a flexible, >> well-understood, expressive format just because it's not ideal >> for one platform (Web browsers), even if that platform is perhaps >> the primary parser of some document types. >> Maybe a good long term strategy is to go with XML as the >> canonical document format, but have some sort of "header" section >> that points to other formats (or services that produce >> alternative formats). And make that header easy enough to read >> that text parsers can easily pull out enough information to avoid >> the rest and go get their preferred document format. This >> strategy could apply not only to static document formats like >> Context and SLD, but also to service responses like GetCapabilities. >> --- >> Raj >> On Nov 16, 2006, Martin Daly wrote: >>> We've also looked into JSON a bit, although not for Context >>> documents. >>> In this case not using XML for the first step seems to be just >>> delaying >>> the inevitable? That is, after you have the context data, the >>> next step >>> is always to get the capabilities of the server (see the recent e- >>> mail >>> trail about, for example, GetMap and GetCapabilities not sharing the >>> same URL root). >>> >>> Unless all of the references services/data area also returned as >>> JSON, >>> then you will be parsing XML sooner rather than later. >>> >>> M >> On Nov 16, 2006, at 5:34 PM, Cameron Shorter wrote: >>> Context working group, >>> >>> Regarding: http://json.org >>> >>> There has been discussion amongst http://openlayers.org >>> developers about using JSON instead of XML for storing OGC >>> documents (like OGC Context, WMC, and probably a host of other >>> documents too). >>> >>> The reason for considering JSON over XML are: >>> * In Web Browsers, XML support is patchy. >>> * Consequently extra code is required to be downloaded to cover >>> all browsers. >>> * In browser clients, code size is a major consideration as >>> size=bandwidth=speed. >>> * JSON is reportedly faster to process. >>> >>> JSON reportedly has all the other advantages of XML like being >>> structured, easy to read, is supported by multiple languages etc. >>> >>> One thing discussed is standing up XML<->JSON services. >>> >>> I'd be interested to hear comments from OGC participants on >>> these ideas. >>> >>> Feel free to foward onto others more appropriate. >>> >>> -- >>> 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 > -- Allan Doyle +1.781.433.2695 adoyle@eogeo.org From cameron.shorter at gmail.com Sat Nov 18 03:54:15 2006 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Fri Dec 22 15:49:43 2006 Subject: [OpenLayers-Dev] Using JSON instead of XML for OGC documents In-Reply-To: References: <455CE777.2050802@gmail.com> <455E0F8A.1040107@gmail.com> Message-ID: <455ECA37.5010405@gmail.com> Browsers with XML APIs: Mozilla - Firefox and family, Internet Explorer with MSXML3.0 and up, Konqueror (KDE 3.3+ for sure), Safari and Opera. Konqueror, Safari and Opera offer no XSLT/XPath scripting support. Adam Hill wrote: > Cameron wrote: > >* In Web Browsers, XML support is patchy. > > I am curious. What browsers don't have basic read/write XML support? > Opera? Safari? > > Or is there some missing features that make it just a PITA? > > Adam Hill > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev -- Cameron Shorter http://cameron.shorter.net From crschmidt at metacarta.com Sat Nov 18 08:44:30 2006 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Fri Dec 22 15:49:43 2006 Subject: Using JSON instead of XML for OGC documents In-Reply-To: References: <455CE777.2050802@gmail.com> <455E0F8A.1040107@gmail.com> Message-ID: <20061118134430.GB5436@metacarta.com> This discussion is more appropriate to webmap-dev than anythign else: moving it to only be on that list. On Fri, Nov 17, 2006 at 02:03:46PM -0600, Adam Hill wrote: > Cameron wrote: > >* In Web Browsers, XML support is patchy. > > I am curious. What browsers don't have basic read/write XML support? Opera? > Safari? > > Or is there some missing features that make it just a PITA? I think one of the largest problems is that browsers all implement things just differently enough to cause them to not work the same cross-browserly. I do know that the lack of xpath support in Safari has been a PITA in the past, but I have a feeling that more recent Safari versions to include an XSLT library. I don't know what that means for xpath support. ("more recent" == Safari 2.0+, OS X Tiger.) I do know that in general, migrating from an XML-based transport to a JSON based transport (when working in Javascript) helped our performance tremendously in one application. I don't know much more about it. Essentially, when working in Javascript, JSON, especially loaded via a callback in a