From crschmidt at metacarta.com Mon Oct 1 00:54:46 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Hackfest: Docs Message-ID: <20071001045446.GA30079@metacarta.com> The output from the big chunk of people we had hacking at the FOSS4G code sprint is now up at: http://dev.openlayers.org/sandbox/docs/doc/examples.html special thanks to Josh Livni and David Bitner for getting the group organized, and to Josh for figuring out a way to make the output work. After 2.5 ships, we'll merge the updated examples back to trunk, and set up a live page generation to replace our existing directory listing with this type of listing instead. Many thanks to all the people who helped us get this far! Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Mon Oct 1 02:26:27 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Projection Support In-Reply-To: <20070930201929.GA821@metacarta.com> References: <20070930201929.GA821@metacarta.com> Message-ID: <47009313.4090602@gmail.com> Chris, The two key developers behind the proj4js code to date have been Richard Greenwood and Mike Adair - as you have noted and discussion has been on the mapbuilder-proj email list (copied). I suggest that we continue discussion on that list until such time as we as a group decide to move elsewhere. I'm excited to hear of your interest and feedback toward the project. It can only take us forward. Until the code sprint, the master repository has been in the mapbuilder repository. While I'm not fussed about where mapbuilder-proj ends up (Mike/Richard I think were considering OSGeo) I would like to ensure that we keep the svn history. Ie, can we please keep using the mapbuilder repository until such time as the whole subversion repository is moved. This provides an audit trail which we can use to credit developers and keep a copywrite ownership record. We can organise svn access to mapbuilder if that is required. Christopher Schmidt wrote: > Mike Adair worked on some great projection support stuff for OpenLayers > at the code sprint, and I've been working on making the underlying > infrastructure for his changes come together. > > The basic principle is that you should not need projection support for > anything, but if you want it, you can include the proj4js library, and > it will be there. > > To that end, there is: > > * OpenLayers.Projection class, a wrapper around proj4js projection, > and provider of transform function. (#1035) > * displayProjection support for controls, so that MousePosition, > Permalink, and ArgParser can display coordinates in a different > projection than the projection of the map. (#1036) > * geometry.transform function, which transforms a geometry from one > projection to another in place. (#1037) > * Format internalProjection and externalProjection support, so that > geometries are transformed in/out as requested. (#1039) > * Vector Layer support for reprojection using format classes (not yet > complete) > > There are still some API discussions happening here -- Tim had a > different vision in mind for transformation, and is going to comment at > some point. Other feedback would also be appreciated: I don't do much > with transformations, so I don't know what I'm missing here. > > To actually do any work, OpenLayers depends on proj4js, a library which > is, at the moment, in a state of flux. > > Thus far, in order to create code which doesn't need things like proxies > or remote access, I've been including .js files and projection > definitions manually. This seems to work relatively well. In order to > have projection support, you simply include proj4js.js in your page, > along with the projection: > > > > > It seems likely that we will want to assemble tools that let you build a > customized projection library with all the bits you need put together. > > Mike Adair has been working on proj4js, based on Richard Greenwood's > cscs code, as I understand it. I'm looking at it, and I have a couple > questions. > > * Where is the current canonical home for the code? There is definitely a > version of it in Mapbuilder's cscs/trunk, but the version in > http://svn.openlayers.org/sandbox/madair/lib/proj4js/ seems to have > most of the remote loading stuff added on to it, and so I think > that's the newer version of the code. > > * Where should the code live? I'm happy putting it anywhere, but right > now it feels scattered and I'm lost as to where improvements should > be done. I'd like to start hacking on the library, as well as > documenting it better. I think we need to be looking at making it a > full on library in and of itself, which (again) can live wherever. > > Eventually, I think it seems likely that we will want to move this > into an OSGeo code repository. In the short term, I think that > identifying a single SVN repository and keeping it there, and > documenting where 'there' is, is the first step forward. > > Mike, where would you like to keep this code? For the purposes of > provenance review and the like, I'd like to keep it out of OL SVN as > a primary home -- you have commit access to the Mapbuilder SVN, and > I'm happy to maintain it there while pursuing possible future > arrangements. > > * How is the code managed? I don't know much about the code, but I do > know that right now, there are things like API naming and the like > that bother me. Who do I take that to? > > Specifically, I don't like the '_reportError' style naming, and I'd > like to do a number of cleanups to make proj4js more > "OpenLayers-like" in style. (Dropping _, picking a standard for > whitespace, stuff like that.) I don't mind leaving things the way > they are if someone else is going to be maintaining the library, but > right now, it feels like it's not usable in OpenLayers, and I'd like > to change that. > > * Creating a service where you can build your own projection javascript > library based on the appropriate pieces from proj4js and the EPSG > data seems like a good thing that we should work on. I'm happy to > take the lead on that and building other similar tools for managing > the proj code based on the OpenLayers stuff. > > Mike, I think most of these are directed at you: can you offer feedback > when you get a chance? (And if you're the wrong person, direct me in the > right direction?) > > In the short term, I'm going to copy the proj4js code into a seperate > sandbox, which anyone can feel free to hack on, and attempt to build > what I think I would like to see and help maintain for OpenLayers users. > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From crschmidt at metacarta.com Mon Oct 1 08:39:04 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: Context Message-ID: <20071001123904.GA15010@metacarta.com> Tim Schaub and Lorenzo (of the little green men) sat down and started working on serializing and deserializing OpenLayers Map objects: you can see some results of that work in the context sandbox: http://dev.openlayers.org/sandbox/context/examples/context.html This is the first step to having a full history tool, which allows a user to do things like 'back button support' that have been worked on in the past. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Mon Oct 1 08:42:48 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD Message-ID: <20071001124248.GB15010@metacarta.com> Andreas Hocevar and Pierre Giraud sat down on Friday at the code sprint and got working on SLD rendering. The results of that are available at: http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/gml-layer-sld.html This small example demonstrates significant support for SLD parameters and filters, parsing (as I understand it) a lot of the contents of the file at: http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/xml/sld.xml Very cool work, and I'm looking forward to helping move the work back to trunk! Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Mon Oct 1 10:30:55 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <12933317.post@talk.nabble.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> Message-ID: <20071001143055.GA26441@metacarta.com> On Thu, Sep 27, 2007 at 06:38:23PM -0700, fporc7ji wrote: > > Hi Eric -- > > Here is what I am experiencing. > > When reading in a KML layer using the VML renderer, the first point displays > at the correct location. > If the layer has multiple points after the first point is added a child node > is added to the root as directed in elements.drawGeometry. As soon as a > child node is appended to the root, the first point shifts and is no longer > at the correct location. I am unable to replicate this behavior. The kml-layer example changed from using points to lines before 2.5, but I just tried it with a KML file with points, and everything looked the same (barring sub-pixel rendering differences) in IE6, IE7, and FF. > My attachment has a sample KML point layer included. Your attachment didn't make it through. Try again, perhaps? Regards, -- Christopher Schmidt MetaCarta From fporcelli at taic.net Mon Oct 1 13:10:02 2007 From: fporcelli at taic.net (fporc7ji) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <20071001143055.GA26441@metacarta.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> <20071001143055.GA26441@metacarta.com> Message-ID: <12983313.post@talk.nabble.com> Hi Chris -- I posted the files again, this time without the entire build. You should be able to paste into any OL2.5 build. Regards, Frank Christopher Schmidt-4 wrote: > > On Thu, Sep 27, 2007 at 06:38:23PM -0700, fporc7ji wrote: >> >> Hi Eric -- >> >> Here is what I am experiencing. >> >> When reading in a KML layer using the VML renderer, the first point >> displays >> at the correct location. >> If the layer has multiple points after the first point is added a child >> node >> is added to the root as directed in elements.drawGeometry. As soon as a >> child node is appended to the root, the first point shifts and is no >> longer >> at the correct location. > > I am unable to replicate this behavior. The kml-layer example changed > from using points to lines before 2.5, but I just tried it with a KML > file with points, and everything looked the same (barring sub-pixel > rendering differences) in IE6, IE7, and FF. > >> My attachment has a sample KML point layer included. > > Your attachment didn't make it through. Try again, perhaps? > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > http://www.nabble.com/file/p12983313/VMLIE6Issue.zip VMLIE6Issue.zip -- View this message in context: http://www.nabble.com/VML-Rendering-of-point-data-tf4516302.html#a12983313 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From crschmidt at metacarta.com Mon Oct 1 16:22:42 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <12983313.post@talk.nabble.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> <20071001143055.GA26441@metacarta.com> <12983313.post@talk.nabble.com> Message-ID: <20071001202242.GB2787@metacarta.com> On Mon, Oct 01, 2007 at 10:10:02AM -0700, fporc7ji wrote: > > Hi Chris -- > > I posted the files again, this time without the entire build. You should be > able to paste into any OL2.5 build. Frank -- I just grabbed the example KML file from this, and loaded it into the SVN build in the kml-layer. It looks exactly the same in IE6, IE7, and FF. You can see the output at: http://dev.openlayers.org/sandbox/crschmidt/kml/examples/kml-layer.html It is possible (though unlikely) that this is something we fixed in SVN, but is not fixed in 2.5RC3. (I don't have the resources to go back through the RCs testing at this time.) If it is, then that's fine, and we'll need to figureo ut what it was and get it pulled up. However, to the best of my knowledge, we have made no significant changes in rendering in the time since we released 2.5RC3, so I can't imagine this being the case. If you can view the URL above and let me know if it's causing you problems, that would be great. I've had another user with IE confirm that he is unable to reproduce any differences between IE and FF either. Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Mon Oct 1 16:28:15 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices Message-ID: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> I am not a particularly fastidious coder but I do strongly believe that folks should be making their code readable and, as much as possible, avoid common sources of bugs. Also, for those folks looking to make contributions, it is going to be much easier for the core maintainers to bring your code into trunk if it already fits the coding style of OpenLayers. I am sure Chris will have more to say on this, but my particular pet peeves are: 1. Not using { } around code associated with if statements. For instance, it is legal in javascript to write the following: if (foo) return true Lets say you need to do one more thing in this case, increment foo: if (foo) foo++ return true This will no longer work as expected (its not python!). I highly recommend using brace brackets around all conditionals. 2. Not using whitespace to make code readable: if(foo<2||foo>5)return foo+12 else if(foo>7)return foo-1 else return foo should be: if (foo < 2 || foo > 5) { return foo + 12; } else if (foo > 7) { return foo - 1; } else { return foo; } or some variant of this. The code compressor can make it unreadable later. Right now, I need to be able to understand the code when reviewing it! Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From fporcelli at taic.net Mon Oct 1 16:32:23 2007 From: fporcelli at taic.net (fporc7ji) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <20071001202242.GB2787@metacarta.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> <20071001143055.GA26441@metacarta.com> <12983313.post@talk.nabble.com> <20071001202242.GB2787@metacarta.com> Message-ID: <12987251.post@talk.nabble.com> Hi Chris -- I've attached a zip file containing screen shots of what my output looks like when viewing the example in both Firefox and IE6. Notice that the IE6 output shows the points skewed to the right (IE6 has FF points in Florida located in Cuba and Maryland's are in the Atlantic. The further east you go, the farther off the points are. Are you seeing the same result in your browser? Thanks, Frank Christopher Schmidt-4 wrote: > > On Mon, Oct 01, 2007 at 10:10:02AM -0700, fporc7ji wrote: >> >> Hi Chris -- >> >> I posted the files again, this time without the entire build. You should >> be >> able to paste into any OL2.5 build. > > Frank -- > > I just grabbed the example KML file from this, and loaded it into the > SVN build in the kml-layer. It looks exactly the same in IE6, IE7, and FF. > > You can see the output at: > > http://dev.openlayers.org/sandbox/crschmidt/kml/examples/kml-layer.html > > It is possible (though unlikely) that this is something we fixed in SVN, > but is not fixed in 2.5RC3. (I don't have the resources to go back > through the RCs testing at this time.) If it is, then that's fine, and > we'll need to figureo ut what it was and get it pulled up. However, to > the best of my knowledge, we have made no significant changes in > rendering in the time since we released 2.5RC3, so I can't imagine this > being the case. > > If you can view the URL above and let me know if it's causing you > problems, that would be great. I've had another user with IE confirm > that he is unable to reproduce any differences between IE and FF either. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > http://www.nabble.com/file/p12987251/KMLOutput.zip KMLOutput.zip -- View this message in context: http://www.nabble.com/VML-Rendering-of-point-data-tf4516302.html#a12987251 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From crschmidt at metacarta.com Mon Oct 1 16:43:46 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices In-Reply-To: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> References: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> Message-ID: <20071001204346.GC2787@metacarta.com> On Mon, Oct 01, 2007 at 04:28:15PM -0400, Paul Spencer wrote: > I am not a particularly fastidious coder but I do strongly believe > that folks should be making their code readable and, as much as > possible, avoid common sources of bugs. Also, for those folks > looking to make contributions, it is going to be much easier for the > core maintainers to bring your code into trunk if it already fits the > coding style of OpenLayers. > > I am sure Chris will have more to say on this, but my particular pet > peeves are: Erik will much more so than me :) Both of Paul's points are dead on, and some others: * Wrap lines at 80 characters. I'm less picky about this than Erik, but he'll go through and clean up the code later if you don't do it, and his commit statistics are inflated enough without giving him more material ;) * Comments when you're doing something confusing are helpful. Don't write a novel, but also don't leave the next guy wondering what was going on. (And as always, a key when commenting is "Not how, but *why*.") I screwed this up with one change I made around r1400, and we've been paying for it for 3000 commits. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Mon Oct 1 16:46:05 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <12987251.post@talk.nabble.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> <20071001143055.GA26441@metacarta.com> <12983313.post@talk.nabble.com> <20071001202242.GB2787@metacarta.com> <12987251.post@talk.nabble.com> Message-ID: <20071001204605.GE2787@metacarta.com> On Mon, Oct 01, 2007 at 01:32:23PM -0700, fporc7ji wrote: > > Hi Chris -- > > I've attached a zip file containing screen shots of what my output looks > like when viewing the example in both Firefox and IE6. Notice that the IE6 > output shows the points skewed to the right (IE6 has FF points in Florida > located in Cuba and Maryland's are in the Atlantic. The further east you go, > the farther off the points are. Your attachment didn't get through, but I'm definitely not seeing this. Can you try installing IE7 (or finding someone with it) and seeing if this changes things? Regards, -- Christopher Schmidt MetaCarta From fporcelli at taic.net Mon Oct 1 17:01:00 2007 From: fporcelli at taic.net (fporc7ji) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] VML Rendering of point data In-Reply-To: <20071001204605.GE2787@metacarta.com> References: <44045.192.168.1.70.1190733934.webmail@192.168.1.70> <5ec103de0709251138y48ca8d74s9fe7f8490445bb3e@mail.gmail.com> <12933317.post@talk.nabble.com> <20071001143055.GA26441@metacarta.com> <12983313.post@talk.nabble.com> <20071001202242.GB2787@metacarta.com> <12987251.post@talk.nabble.com> <20071001204605.GE2787@metacarta.com> Message-ID: <12987707.post@talk.nabble.com> It's very strange that this is only happening in my dev environment. I'll have to assume it's something on my end. Thanks for checking. Regards, Frank Christopher Schmidt-4 wrote: > > On Mon, Oct 01, 2007 at 01:32:23PM -0700, fporc7ji wrote: >> >> Hi Chris -- >> >> I've attached a zip file containing screen shots of what my output looks >> like when viewing the example in both Firefox and IE6. Notice that the >> IE6 >> output shows the points skewed to the right (IE6 has FF points in Florida >> located in Cuba and Maryland's are in the Atlantic. The further east you >> go, >> the farther off the points are. > > Your attachment didn't get through, but I'm definitely not seeing this. > Can you try installing IE7 (or finding someone with it) and seeing if > this changes things? > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > http://www.nabble.com/file/p12987707/KML-IE6.jpg -- View this message in context: http://www.nabble.com/VML-Rendering-of-point-data-tf4516302.html#a12987707 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From cameron.shorter at gmail.com Mon Oct 1 17:46:08 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: Context In-Reply-To: <20071001123904.GA15010@metacarta.com> References: <20071001123904.GA15010@metacarta.com> Message-ID: <47016AA0.3060307@gmail.com> Mapbuilder has history tools. When you get to implementing this, could you please touch base with the Mapbuilder developers and code. If done right it should make it easier for Mapbuilder to integrate with the Openlayers functionality. Christopher Schmidt wrote: > Tim Schaub and Lorenzo (of the little green men) sat down and started > working on serializing and deserializing OpenLayers Map objects: you can > see some results of that work in the context sandbox: > > http://dev.openlayers.org/sandbox/context/examples/context.html > > This is the first step to having a full history tool, which allows a > user to do things like 'back button support' that have been worked on in > the past. > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From crschmidt at metacarta.com Mon Oct 1 19:49:18 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: Context In-Reply-To: <47016AA0.3060307@gmail.com> References: <20071001123904.GA15010@metacarta.com> <47016AA0.3060307@gmail.com> Message-ID: <20071001234918.GA30903@alta.metacarta.com> On Tue, Oct 02, 2007 at 07:46:08AM +1000, Cameron Shorter wrote: > Mapbuilder has history tools. > When you get to implementing this, could you please touch base with the > Mapbuilder developers and code. If done right it should make it easier > for Mapbuilder to integrate with the Openlayers functionality. Cross-page load history tools? Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Mon Oct 1 20:31:19 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices In-Reply-To: <20071001204346.GC2787@metacarta.com> References: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> <20071001204346.GC2787@metacarta.com> Message-ID: <6ae3fb590710011731ydda3e7dvcd8d1557f8ca8742@mail.gmail.com> fyi: http://trac.openlayers.org/wiki/CodingStandards ;-) erik On 10/1/07, Christopher Schmidt wrote: > On Mon, Oct 01, 2007 at 04:28:15PM -0400, Paul Spencer wrote: > > I am not a particularly fastidious coder but I do strongly believe > > that folks should be making their code readable and, as much as > > possible, avoid common sources of bugs. Also, for those folks > > looking to make contributions, it is going to be much easier for the > > core maintainers to bring your code into trunk if it already fits the > > coding style of OpenLayers. > > > > I am sure Chris will have more to say on this, but my particular pet > > peeves are: > > Erik will much more so than me :) > > Both of Paul's points are dead on, and some others: > > * Wrap lines at 80 characters. I'm less picky about this than > Erik, but he'll go through and clean up the code later if you don't > do it, and his commit statistics are inflated enough without giving > him more material ;) > * Comments when you're doing something confusing are helpful. > Don't write a novel, but also don't leave the next guy wondering what > was going on. (And as always, a key when commenting is "Not how, but > *why*.") I screwed this up with one change I made around r1400, and > we've been paying for it for 3000 commits. > > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From pspencer at dmsolutions.ca Mon Oct 1 20:46:43 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices In-Reply-To: <6ae3fb590710011731ydda3e7dvcd8d1557f8ca8742@mail.gmail.com> References: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> <20071001204346.GC2787@metacarta.com> <6ae3fb590710011731ydda3e7dvcd8d1557f8ca8742@mail.gmail.com> Message-ID: <5697B79D-EE5B-4985-A47F-293A30904BAB@dmsolutions.ca> Somewhat unrelated to coding standards, what do you think about using jslint, perhaps as a pre-commit hook? There are a couple of places that jslint gives warnings about in OpenLayers that are probably not necessary to fix (regular expressions I think), but I did find a number of missing semi-colons just working on the transition stuff. I have jslint embedded in my text editor so it lint's every file I save. I find this very handy to avoid certain problems. Paul On 1-Oct-07, at 8:31 PM, Erik Uzureau wrote: > fyi: > > http://trac.openlayers.org/wiki/CodingStandards > > ;-) > > erik > > On 10/1/07, Christopher Schmidt wrote: >> On Mon, Oct 01, 2007 at 04:28:15PM -0400, Paul Spencer wrote: >>> I am not a particularly fastidious coder but I do strongly believe >>> that folks should be making their code readable and, as much as >>> possible, avoid common sources of bugs. Also, for those folks >>> looking to make contributions, it is going to be much easier for the >>> core maintainers to bring your code into trunk if it already fits >>> the >>> coding style of OpenLayers. >>> >>> I am sure Chris will have more to say on this, but my particular pet >>> peeves are: >> >> Erik will much more so than me :) >> >> Both of Paul's points are dead on, and some others: >> >> * Wrap lines at 80 characters. I'm less picky about this than >> Erik, but he'll go through and clean up the code later if you >> don't >> do it, and his commit statistics are inflated enough without >> giving >> him more material ;) >> * Comments when you're doing something confusing are helpful. >> Don't write a novel, but also don't leave the next guy >> wondering what >> was going on. (And as always, a key when commenting is "Not >> how, but >> *why*.") I screwed this up with one change I made around r1400, >> and >> we've been paying for it for 3000 commits. >> >> >> Regards, >> -- >> Christopher Schmidt >> MetaCarta >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From rdewit at users.sourceforge.net Mon Oct 1 20:51:15 2007 From: rdewit at users.sourceforge.net (Roald de Wit) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] WFS Layer loadstart/loadend events missing in moveTo() Message-ID: <1191286275.5891.18.camel@bender> Hi List, Maybe I'm overlooking something, but it seems that in the method moveTo() the following monotoring hook is missing after line 259 in Layer/WFS.js (SVN trunk: revision 4744) this.addTileMonitoringHooks(this.tile); A current tile is destroyed and a new tile is created, but not getting the monitoring hooks before being drawn. This results in the loadstart/loadend events not being triggered. It seems that the code there is a bit double anyway. Wouldn't something like this be a cleaner? // Destroy tile first if exists if (this.tile) { if (this.vectorMode) { this.destroyFeatures(); this.renderer.clear(); } else { this.clearMarkers(); } this.removeTileMonitoringHooks(this.tile); this.tile.destroy(); } //(re)create tile this.tile = null; // do we need to do this?? this.tile = new OpenLayers.Tile.WFS(this, pos, tileBounds, url, tileSize); this.addTileMonitoringHooks(this.tile); this.tile.draw(); Can this be fixed in the 2.5 release? Greetings, Roald From crschmidt at metacarta.com Mon Oct 1 20:57:03 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices In-Reply-To: <5697B79D-EE5B-4985-A47F-293A30904BAB@dmsolutions.ca> References: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> <20071001204346.GC2787@metacarta.com> <6ae3fb590710011731ydda3e7dvcd8d1557f8ca8742@mail.gmail.com> <5697B79D-EE5B-4985-A47F-293A30904BAB@dmsolutions.ca> Message-ID: <20071002005703.GA14305@metacarta.com> On Mon, Oct 01, 2007 at 08:46:43PM -0400, Paul Spencer wrote: > Somewhat unrelated to coding standards, what do you think about using > jslint, perhaps as a pre-commit hook? There are a couple of places > that jslint gives warnings about in OpenLayers that are probably not > necessary to fix (regular expressions I think), but I did find a > number of missing semi-colons just working on the transition stuff. Pre- or post-commit hooks I'm trying to limit -- too many ways to fail, too much chance of getting caught up on the server bombing out. Our commit process is rigorous enough that it typically catches any bugs that affect behavior -- running the tests in multiple browsers will do that. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Mon Oct 1 21:03:47 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] coding style best practices In-Reply-To: <20071002005703.GA14305@metacarta.com> References: <3F74B8C3-1A2E-46B1-ACBB-29EB49B67465@dmsolutions.ca> <20071001204346.GC2787@metacarta.com> <6ae3fb590710011731ydda3e7dvcd8d1557f8ca8742@mail.gmail.com> <5697B79D-EE5B-4985-A47F-293A30904BAB@dmsolutions.ca> <20071002005703.GA14305@metacarta.com> Message-ID: <6ae3fb590710011803r4d661b21s523c797f8eb5650f@mail.gmail.com> That said, I would be thrilled to get people running JSLint on the OL codebase regularly. It might be interesting to add it as a step in the RC process or something like that. At this point, however, OL is riding like an octopus on ridalin... so we better tend to essential matters first. Let it not be forgotten! On 10/1/07, Christopher Schmidt wrote: > On Mon, Oct 01, 2007 at 08:46:43PM -0400, Paul Spencer wrote: > > Somewhat unrelated to coding standards, what do you think about using > > jslint, perhaps as a pre-commit hook? There are a couple of places > > that jslint gives warnings about in OpenLayers that are probably not > > necessary to fix (regular expressions I think), but I did find a > > number of missing semi-colons just working on the transition stuff. > > Pre- or post-commit hooks I'm trying to limit -- too many ways to fail, > too much chance of getting caught up on the server bombing out. > > Our commit process is rigorous enough that it typically catches any bugs > that affect behavior -- running the tests in multiple browsers will do > that. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From cameron.shorter at gmail.com Mon Oct 1 21:29:14 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: Context In-Reply-To: <20071001234918.GA30903@alta.metacarta.com> References: <20071001123904.GA15010@metacarta.com> <47016AA0.3060307@gmail.com> <20071001234918.GA30903@alta.metacarta.com> Message-ID: <47019EEA.8060306@gmail.com> I think mapbuilder's history is limited to remembering previous AreaOfInterest. I don't think we have gone as far as remembering layers as well as would happen if you recorded the Context for each previous history revision. Here is an example: http://demo.communitymapbuilder.org/demo/mapbuilder/demo/Demis/index.html Christopher Schmidt wrote: > On Tue, Oct 02, 2007 at 07:46:08AM +1000, Cameron Shorter wrote: > >> Mapbuilder has history tools. >> When you get to implementing this, could you please touch base with the >> Mapbuilder developers and code. If done right it should make it easier >> for Mapbuilder to integrate with the Openlayers functionality. >> > > Cross-page load history tools? > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From madair at dmsolutions.ca Mon Oct 1 23:35:29 2007 From: madair at dmsolutions.ca (Mike Adair) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Projection Support In-Reply-To: <20070930201929.GA821@metacarta.com> References: <20070930201929.GA821@metacarta.com> Message-ID: <4701BC81.4080907@dmsolutions.ca> > To actually do any work, OpenLayers depends on proj4js, a library which > is, at the moment, in a state of flux. > The API as defined now should be pretty stable from now on. What's left to do is converting existing projection class code and port of new classes from Proj.4 to Proj4js (sounds like a good summer of code project). Also left for me is to check in the code I have to the cscs directory which has all the dynamic loading stuff that is in the OL demo. > * Where is the current canonical home for the code? There is definitely a > version of it in Mapbuilder's cscs/trunk, but the version in > http://svn.openlayers.org/sandbox/madair/lib/proj4js/ seems to have > most of the remote loading stuff added on to it, and so I think > that's the newer version of the code. > Definitive version should be in http://svn.codehaus.org/mapbuilder/cscs/trunk/cscs but as I said I have stuff to check in still. I'll do that ASAP. > * Where should the code live? I'm happy putting it anywhere, but right > now it feels scattered and I'm lost as to where improvements should > be done. I'd like to start hacking on the library, as well as > documenting it better. I think we need to be looking at making it a > full on library in and of itself, which (again) can live wherever. > > Eventually, I think it seems likely that we will want to move this > into an OSGeo code repository. In the short term, I think that > identifying a single SVN repository and keeping it there, and > documenting where 'there' is, is the first step forward. > > Mike, where would you like to keep this code? For the purposes of > provenance review and the like, I'd like to keep it out of OL SVN as > a primary home -- you have commit access to the Mapbuilder SVN, and > I'm happy to maintain it there while pursuing possible future > arrangements. > Frank W. has started a discussion on the OSGeo list to resolve this, and it is also related to the supporting new projects thread there. Personally I think it is a great idea to consolidate coordinate transformation stuff on OSGeo somewhere, both client side and server-side stuff. We should be able to gather enought of a community around that to make it viable in the long term. In the meantime, the mapbuilder/csc svn should be the definitive repository for this. > > * How is the code managed? I don't know much about the code, but I do > know that right now, there are things like API naming and the like > that bother me. Who do I take that to? > > Specifically, I don't like the '_reportError' style naming, and I'd > like to do a number of cleanups to make proj4js more > "OpenLayers-like" in style. (Dropping _, picking a standard for > whitespace, stuff like that.) I don't mind leaving things the way > they are if someone else is going to be maintaining the library, but > right now, it feels like it's not usable in OpenLayers, and I'd like > to change that. > Right now it seems to be Richard and myself. I was using the _ prepending to indicate private methods, but I'm open to other suggestions. The point is that any automatically generated documentation should just show the Proj constructor and the .transform() method. Users should never have to worry about any of the other methods in the library. > * Creating a service where you can build your own projection javascript > library based on the appropriate pieces from proj4js and the EPSG > data seems like a good thing that we should work on. I'm happy to > take the lead on that and building other similar tools for managing > the proj code based on the OpenLayers stuff. > Yes some experimentation on how best to load the required data and code is needed. I'm also interested in seeing some other metadata around projections be supported (e.g. bbox for applicability of a particular projection, a set of test points for each code, etc.) ie. some of the same metadata that is available to the spatialreference.org pages. Mike From andreas.hocevar at gmail.com Tue Oct 2 03:12:39 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <20071001124248.GB15010@metacarta.com> References: <20071001124248.GB15010@metacarta.com> Message-ID: <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> Hi, after discussing the pro and cons of evaluating rules by a pre-compiled string and eval() vs. an object-based representation of the ogc rules with Chris and Tim at the FOSS4G code sprint, I have to admit that avoiding eval() has several advantages: - rules can be easily created independently from the sld parser (eg through a sld editor), and written out with a write() method, like with other formats. - better security - (maybe also) better performance I finally figured out a way to build an object tree with rules, including all requirements like recursively stacking logical operators. For this, I had to create a new class OpenLayers.Rule, with subclasses for the main types of rules, similar to those in the OGC filter spec sld. This class replaces the OpenLayers.Style.Rule hash we had before, and instances of this class (or its subclasses) are held in the rules array of an OpenLayers.Style instance. This Rule class has a method evaluate(feature), which is different for all rule types and returns true or false. I also rewrote parts of the SLD parser itself (OpenLayers.Format.SLD) for better readability of the code, by adding convenience methods and taking care of the length of code lines. I hope the progress I made will make it easier for you to move this sld thing into trunk. Regards, Andreas. On 10/1/07, Christopher Schmidt wrote: > Andreas Hocevar and Pierre Giraud sat down on Friday at the code sprint > and got working on SLD rendering. > > The results of that are available at: > > http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/gml-layer-sld.html > > This small example demonstrates significant support for SLD parameters > and filters, parsing (as I understand it) a lot of the contents of the > file at: > > http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/xml/sld.xml > > Very cool work, and I'm looking forward to helping move the work back to > trunk! > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From crschmidt at metacarta.com Tue Oct 2 09:03:31 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> Message-ID: <20071002130331.GA18878@metacarta.com> On Tue, Oct 02, 2007 at 04:12:39PM +0900, Andreas Hocevar wrote: > I finally figured out a way to build an object tree with rules, > including all requirements like recursively stacking logical > operators. Andreas, I read through your code last night, and was quite pleased with the result you had come up with. I saw it go into trunk and immediately read through it -- quite happy with the result. Thanks for the hard work on this! > I hope the progress I made will make it easier for you to move this > sld thing into trunk. So, I would like to see at least a few tests before we bring it back into trunk: * Minimal constructor tests for any new classes * A test or two for each of the Rule.Foo subclasses, if possible * A minimal test for pulling in SLD. * Do we write out SLD from rules? if so, a round-trip test would be nice to have too -- read in, write out, compare to expected results. Nothing too complex -- just enough to build a framework so that future bugfixes can build on top of it. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Tue Oct 2 12:07:15 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Development toolset In-Reply-To: <190430c0709210036n514f33bdtbe622b216bfc2710@mail.gmail.com> References: <6ae3fb590709202314j7d8fdc95xcf33915aaa382c6e@mail.gmail.com> <190430c0709210036n514f33bdtbe622b216bfc2710@mail.gmail.com> Message-ID: <6ae3fb590710020907m3a704dacif74cf5280d185730@mail.gmail.com> Hi Gianni, I haven't been using the Outline view. In fact, I use the eclipse for nothing more than the simple gui folder/file hierarchy (Navigation Tab), for the syntax coloring and JS error detection that JSEclipse provides in the editor. That and the nice global search functions. Every once in a while I get some intelligent predictive text while writing code, but I haven't really paid much attention to when or how that happens, and I usually ignore it. (except when it helps me with "document.getElementById()" :-D) Last week in victoria, I saw Paul S using a program I think is called "TextMate" or something like that. I believe it's a mac thing. The cool thing with that is that it runs that JSLint program automatically, which my goodness I really want to get JSLint running over OL somehow... E On 9/21/07, Gianni Barrotta wrote: > What about the 'outline' view with JSEclipse? With some objects I can't she > this view and I can't check class methods... > Erik, do I miss something? > > > On 9/21/07, Erik Uzureau wrote: > > I use eclipse with JSEclipse plugin > > > http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/ > > > > Erik > > > > On 9/21/07, Ian Mayo < ian@planetmayo.com> wrote: > > > Hi, > > > I'm getting up & running with OpenLayers development - starting with > small > > > steps. > > > > > > To stop me reinventing the wheel, I'd appreciate anybody's tips on > > > their development environment. > > > > > > I've seen the "ATF" plugin for Eclipse that seems to offer code > > > completion & interactive debugging (two live-savers...). > > > > > > Mailing list entries show a lot of support for FireBug, but I haven't > > > seen any body mention their editors. > > > > > > thanks in advance for any advice, > > > Ian. > > > _______________________________________________ > > > Dev mailing list > > > Dev@openlayers.org > > > http://openlayers.org/mailman/listinfo/dev > > > > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > From andreas.hocevar at gmail.com Tue Oct 2 13:31:25 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <20071002130331.GA18878@metacarta.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> <20071002130331.GA18878@metacarta.com> Message-ID: <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> Chris, On 10/2/07, Christopher Schmidt wrote: > So, I would like to see at least a few tests before we bring it back > into trunk: > * Minimal constructor tests for any new classes > * A test or two for each of the Rule.Foo subclasses, if possible > * A minimal test for pulling in SLD. > * Do we write out SLD from rules? if so, a round-trip test would be > nice to have too -- read in, write out, compare to expected > results. > > Nothing too complex -- just enough to build a framework so that future > bugfixes can build on top of it. I will create these tests, hopefully today. Pierre already built the minimal test for pulling in SLD in the Format.SLD test. We do not yet write out SLD, so the round trip test will have to wait until someone implements the write method. But, with the new way of storing the rules, write() should be easier to do than with the eval stuff before. Regards, Andreas. From ian at planetmayo.com Tue Oct 2 15:52:23 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Design for scale-line Message-ID: Here's the design for my OpenLayers scale control, aimed to offer similar functionality to the scale offered in google maps. The new control is to be called "ScaleLine". Yes, there's lots of room for improvement there, suggestions welcome. Here are the steps I'll take: 1. Determine current scale 2. Determine width of view in metres 3. Determine how wide 10% of view is in metres 4. Round width up/down to nearest "round number" in increasing size of units: -- 1,2,5,10,20,50,100,200,500 (metres) -- 1,2,5,10,20,50,100,200,500,1000,2000 (km) 5. Calculate size of line of rounded length in screen units 6. Draw line of scaled length, with text-label on right-hand size into 'div' for this control 7. Repeat the above for imperial units The Div will have been located using the css-style called .olControlScaleLine Questions from me? Well, yes. I've seen from the other controls how to draw plain text onto the map. Drawing my graphic is a little more complex. Should the line and "tails" be an OpenLayer feature? Or is there another method for drawing line-based items. I suppose I could have a div with left, bottom, right borders - with the div-width set to the width in step 5 above. Any advice? thanks in advance for any support, Ian. p.s. Should I have written this content into a wiki page? Opinions welcome. From lorenzo at ominiverdi.com Tue Oct 2 18:15:18 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Design for scale-line In-Reply-To: References: Message-ID: <4702C2F6.7090403@ominiverdi.com> Ian, have you ever seen Tim Schaub's Scalebar for ka-Map? that's all JS and CSS: http://www.ominiverdi.org/ka-map/ka-map/htdocs/ ciao Lorenzo Ian Mayo wrote: > Here's the design for my OpenLayers scale control, aimed to offer > similar functionality to the scale offered in google maps. > > The new control is to be called "ScaleLine". Yes, there's lots of > room for improvement there, suggestions welcome. > > Here are the steps I'll take: > 1. Determine current scale > 2. Determine width of view in metres > 3. Determine how wide 10% of view is in metres > 4. Round width up/down to nearest "round number" in increasing size of units: > -- 1,2,5,10,20,50,100,200,500 (metres) > -- 1,2,5,10,20,50,100,200,500,1000,2000 (km) > 5. Calculate size of line of rounded length in screen units > 6. Draw line of scaled length, with text-label on right-hand size into > 'div' for this control > 7. Repeat the above for imperial units > > The Div will have been located using the css-style called .olControlScaleLine > > Questions from me? > > Well, yes. I've seen from the other controls how to draw plain text > onto the map. Drawing my graphic is a little more complex. Should > the line and "tails" be an OpenLayer feature? Or is there another > method for drawing line-based items. I suppose I could have a div > with left, bottom, right borders - with the div-width set to the width > in step 5 above. > > Any advice? > > thanks in advance for any support, > Ian. > > p.s. Should I have written this content into a wiki page? Opinions welcome. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From carlos.hernandez at encontrack.com Tue Oct 2 18:48:32 2007 From: carlos.hernandez at encontrack.com (=?iso-8859-1?Q?Carlos_Hern=E1ndez?=) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Help with tms display Message-ID: <001201c80546$5c199850$144cc8f0$@hernandez@encontrack.com> Hi, my name?s Carlos and I?m starting to use open layers ?cause I need to program a google maps kind of application. I?ve read many of the examples and manage to made one of them work with my tiles, but I still don?t get some things like how to handle bounds? and why do I have to override the getURL function?. Can anyone please tell me where can I find a full tutorial or an article regarding this issues because I?ve searched the mailing list and the site and can?t found any. Thanks in advance. Carlos A. Hern?ndez A. Ingenier?a Encontrack, S.A. de C.V. Tel: (+52)(442) 215-3166 ext. 108 Email: carlos.hernandez@encontrack.com Web: www.encontrack.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071002/888b6a5e/attachment.html From crschmidt at metacarta.com Tue Oct 2 20:28:35 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] 2.5 Tickets Message-ID: <20071003002835.GA29349@metacarta.com> Devs - 3 patches need review for 2.5: * Support W3C Geo in Format.GeoRSS. An oversight, but an important one to maintain backwards compatibility for people wanting to switch from Layer.GeoRSS to Format.GeoRSS * GeoJSON Draft4 Support. Updating GeoJSON draft to revision 4, based on talks at FOSS4G. * KML should automatically determine NS. This bug has caused several reports of misbehavior already, and so although it's not a 'bug' per se, I'd like to get it fixed in 2.5. 2 patches are awaiting pullups: #1023, add ServiceVersion option to TMS, is as close to 0 risk as you can get, and will better support gdal2tiles. #1040 fixes a mistake in the spherical-mercator example. 1 patch awaiting commit: #1013 , OpenLayers.Layer.WMS.Untiled doesn't clone correctly. (Regression) 2 patches needing work: #1034, OpenLayers.Util.pagePosition occasionally fails in IE. #1043, OpenLayers zooms in too far on an extent 1043 and 1034 are both blockers for the release, as they are regressions from previous behavior. The three currently awaiting review would be nice to have for 2.5, but I'm willing to let it go without it. I'm willing to do the legwork to pull those in, and I'm convinced they are low risk. all three have tests. If I could get a reviewer on those, it would be great. Bart, can you share the HTML which gave you the error for #1034? Tim, can you comment on what you think is the best path for #1043? I think that we need to go to a threshold-like setup, where we pull the closest resolution only if it's within 5% of the total resolution or something -- something which is 40% away should zoom out one more step, and we've broken that behavior. (For more detailed information, grab me on IRC or AIM, and I'll show you a test case or 4.) If we can get those resolved, I'll do my best to get another 2.5 RC out 24 hours after we get all the bugs fixed in trunk. If you have any negative feedback on the changes in #1024, #1028, and #1044, let me know. The former are clearly relatively harmless and likely helpful -- the last is a purely selfish move so that we don't constantly deal with problems with KML files from different Namespaces floating by. However, I'm willing to be convinced on any of them that an RC is not the right time. Best Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Tue Oct 2 20:36:01 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Testing: prefer t.eq to t.ok(foo == bar) Message-ID: <20071003003601.GA5969@metacarta.com> Andreas -- I just noticed this in your code, but it applies to many other developers as well, so I'm going to use you as an example: In http://trac.openlayers.org/browser/sandbox/ahocevar/sldRenderer/tests/Rule/test_Logical.html?rev=4759 , you use: t.ok(rule.evaluate(feature) == false, "text") While this is acceptable for when the test succeeds, it's difficult in the future when the test fails to track down exactly what is failing. t.eq(rule.evaluate(feature), false, "text") Is more informative, because in the case where it fails, it will say something like: "got null, expected false" which is useful for tracking down the why of the failure. If you could rewrite the tests to use this instead, that would be great. (I'm really excited about getting this into trunk, though it's probably not clear from my criticsms. :) Just want to make the integration process as easy as possible.) Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Tue Oct 2 22:18:13 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Development toolset In-Reply-To: <6ae3fb590710020907m3a704dacif74cf5280d185730@mail.gmail.com> References: <6ae3fb590709202314j7d8fdc95xcf33915aaa382c6e@mail.gmail.com> <190430c0709210036n514f33bdtbe622b216bfc2710@mail.gmail.com> <6ae3fb590710020907m3a704dacif74cf5280d185730@mail.gmail.com> Message-ID: <847B67B1-DB8F-4030-B8D6-1B38F9BF8CFB@dmsolutions.ca> Yes, it is TextMate which is unfortunately not free but also not very expensive, and is quite fantastic in many respects. Paul On 2-Oct-07, at 12:07 PM, Erik Uzureau wrote: > Hi Gianni, > > I haven't been using the Outline view. In fact, I use the eclipse for > nothing more than the simple gui folder/file hierarchy (Navigation > Tab), for the syntax coloring and JS error detection that JSEclipse > provides in the editor. That and the nice global search functions. > > Every once in a while I get some intelligent predictive text while > writing code, but I haven't really paid much attention to when or how > that happens, and I usually ignore it. (except when it helps me with > "document.getElementById()" :-D) > > Last week in victoria, I saw Paul S using a program I think is called > "TextMate" or something like that. I believe it's a mac thing. The > cool thing with that is that it runs that JSLint program > automatically, which my goodness I really want to get JSLint running > over OL somehow... > > E > > On 9/21/07, Gianni Barrotta wrote: >> What about the 'outline' view with JSEclipse? With some objects I >> can't she >> this view and I can't check class methods... >> Erik, do I miss something? >> >> >> On 9/21/07, Erik Uzureau wrote: >>> I use eclipse with JSEclipse plugin >>> >> http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/ >>> >>> Erik >>> >>> On 9/21/07, Ian Mayo < ian@planetmayo.com> wrote: >>>> Hi, >>>> I'm getting up & running with OpenLayers development - starting >>>> with >> small >>>> steps. >>>> >>>> To stop me reinventing the wheel, I'd appreciate anybody's tips on >>>> their development environment. >>>> >>>> I've seen the "ATF" plugin for Eclipse that seems to offer code >>>> completion & interactive debugging (two live-savers...). >>>> >>>> Mailing list entries show a lot of support for FireBug, but I >>>> haven't >>>> seen any body mention their editors. >>>> >>>> thanks in advance for any advice, >>>> Ian. >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@openlayers.org >>>> http://openlayers.org/mailman/listinfo/dev >>>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> >> >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From andreas.hocevar at gmail.com Tue Oct 2 23:25:20 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Testing: prefer t.eq to t.ok(foo == bar) In-Reply-To: <20071003003601.GA5969@metacarta.com> References: <20071003003601.GA5969@metacarta.com> Message-ID: <5b021dd0710022025q4a8baea0x6e0401eb792cfad6@mail.gmail.com> Chris, thank you for this important hint! I changed all my tests to comply with that. Also, I pulled the latest trunk version into the sldRenderer sandbox, built a singlefile version of OpenLayers.js to check for correct @requires statements and dependencies, and used this successfully with the gml-layer-sld.html example. Regards, Andreas. On 10/2/07, Christopher Schmidt wrote: > Andreas -- > > I just noticed this in your code, but it applies to many other > developers as well, so I'm going to use you as an example: > > In > http://trac.openlayers.org/browser/sandbox/ahocevar/sldRenderer/tests/Rule/test_Logical.html?rev=4759 > > , you use: t.ok(rule.evaluate(feature) == false, "text") > > While this is acceptable for when the test succeeds, it's difficult in > the future when the test fails to track down exactly what is failing. > > t.eq(rule.evaluate(feature), false, "text") > > Is more informative, because in the case where it fails, it will say > something like: > > "got null, expected false" > > which is useful for tracking down the why of the failure. > > If you could rewrite the tests to use this instead, that would be great. > > (I'm really excited about getting this into trunk, though it's probably > not clear from my criticsms. :) Just want to make the integration > process as easy as possible.) > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From lancelot at inetnebr.com Wed Oct 3 00:16:36 2007 From: lancelot at inetnebr.com (Lance Dyas) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] [OpenLayers-Users] spherical-mercator In-Reply-To: <20071002202834.GC4594@metacarta.com> References: <6e9b30fb0710021120u60c51cf6xc37031c59c1673b3@mail.gmail.com> <20071002182454.GA23560@metacarta.com> <6e9b30fb0710021133g53e24a07ya421d74cb73fc7c4@mail.gmail.com> <20071002194241.GD10168@alta.metacarta.com> <5ec103de0710021259h4545212dwc8f22b3f51346f0d@mail.gmail.com> <6e9b30fb0710021313l2b25c7e8l843ad4b383460e8@mail.gmail.com> <20071002202834.GC4594@metacarta.com> Message-ID: <470317A4.6000507@inetnebr.com> Christopher Schmidt wrote: > * Use a WMS Server which support EPSG:900913 and sphericalMercator > on the base layer. I keep meaning to ask this Why 900913 I had previously seen 54004 and 41001 According to this code used oftn in the Google Maps API camp it is using an Ellipse. http://chignik.berkeley.edu/google/wms236.js From crschmidt at metacarta.com Wed Oct 3 00:50:23 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] [OpenLayers-Users] spherical-mercator In-Reply-To: <470317A4.6000507@inetnebr.com> References: <6e9b30fb0710021120u60c51cf6xc37031c59c1673b3@mail.gmail.com> <20071002182454.GA23560@metacarta.com> <6e9b30fb0710021133g53e24a07ya421d74cb73fc7c4@mail.gmail.com> <20071002194241.GD10168@alta.metacarta.com> <5ec103de0710021259h4545212dwc8f22b3f51346f0d@mail.gmail.com> <6e9b30fb0710021313l2b25c7e8l843ad4b383460e8@mail.gmail.com> <20071002202834.GC4594@metacarta.com> <470317A4.6000507@inetnebr.com> Message-ID: <20071003045023.GA13474@metacarta.com> On Tue, Oct 02, 2007 at 11:16:36PM -0500, Lance Dyas wrote: > Christopher Schmidt wrote: > > * Use a WMS Server which support EPSG:900913 and sphericalMercator > > on the base layer. > > I keep meaning to ask this Why 900913 > I had previously seen 54004 and 41001 54004 and 41001 have both been used to describe the same thing -- that is, the proj4 projection +proj=merc. Although this works well to a point, it has issues in matching up exactly -- a more exact proj4 string was uncovered by FrankW, as documented in http://proj.maptools.org/faq.html#sphere_as_wgs84 . Since the two things which are commonly used were already taken -- and the former was really reserved for a different purpose anyway -- we went with Tim's cute play on 'g o o g l e' -- 9 0 0 9 1 3. Can't tell me you'll forget that now. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Wed Oct 3 01:50:56 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] Zoom Problems Switching Baselayers -- HELP! Message-ID: <6ae3fb590710022250q5e274512i3ffdd89330066f96@mail.gmail.com> Dear Dev, Have you experienced zoom problems when switching baselayers with OpenLayers? You switch baselayers and seemingly for no reason, the map zooms in or out? Please help us! Can you send us the HTML for the example in which this occurs? We've put a fix[1] for this bug[2] into trunk but then realized that it was breaking other things[3]. I've been doing a little experiment with reverting the change and re-adding it, but only conditionally[4]. Anyways, the only thing that we really need is the HTML of an OpenLayers map that exhibits this annoying zooming-on-baselayer-switch bug. It would help us a bunch in getting a final version of 2.5 released. Please let us know! Erik [1] http://trac.openlayers.org/changeset/4381 [2] http://trac.openlayers.org/ticket/990 [3] http://trac.openlayers.org/ticket/1043 [4] http://trac.openlayers.org/attachment/ticket/1043/zoomer.3.patch From erik.uzureau at metacarta.com Wed Oct 3 16:14:24 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] WFS Layer loadstart/loadend events missing in moveTo() In-Reply-To: <1191286275.5891.18.camel@bender> References: <1191286275.5891.18.camel@bender> Message-ID: <6ae3fb590710031314u2a40ca40tc7dc7297a39e995a@mail.gmail.com> This has been fixed and will be included in the release. Thanks Roald for the bug report! Erik On 10/1/07, Roald de Wit wrote: > Hi List, > > Maybe I'm overlooking something, but it seems that in the method > moveTo() the following monotoring hook is missing after line 259 in > Layer/WFS.js (SVN trunk: revision 4744) > > this.addTileMonitoringHooks(this.tile); > > A current tile is destroyed and a new tile is created, but not getting > the monitoring hooks before being drawn. This results in the > loadstart/loadend events not being triggered. > > It seems that the code there is a bit double anyway. Wouldn't something > like this be a cleaner? > > > // Destroy tile first if exists > if (this.tile) { > if (this.vectorMode) { > this.destroyFeatures(); > this.renderer.clear(); > } else { > this.clearMarkers(); > } > this.removeTileMonitoringHooks(this.tile); > this.tile.destroy(); > } > > //(re)create tile > this.tile = null; // do we need to do this?? > this.tile = new OpenLayers.Tile.WFS(this, pos, tileBounds, > url, tileSize); > this.addTileMonitoringHooks(this.tile); > this.tile.draw(); > > Can this be fixed in the 2.5 release? > > Greetings, Roald > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From crschmidt at metacarta.com Wed Oct 3 17:39:13 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:33 2010 Subject: [OpenLayers-Dev] 2.5 Tickets In-Reply-To: <20071003002835.GA29349@metacarta.com> References: <20071003002835.GA29349@metacarta.com> Message-ID: <20071003213913.GA2347@metacarta.com> On Tue, Oct 02, 2007 at 08:28:35PM -0400, Christopher Schmidt wrote: > Devs - > > 3 patches need review for 2.5: > * Support W3C Geo in Format.GeoRSS. An oversight, but an important one > to maintain backwards compatibility for people wanting to switch from > Layer.GeoRSS to Format.GeoRSS Reviewed by Schuyler, checked in, merged to branch. > * GeoJSON Draft4 Support. Updating GeoJSON draft to revision 4, based > on talks at FOSS4G. Reviewed by Schuyler, checked in, merged to branch. > * KML should automatically determine NS. This bug has caused several > reports of misbehavior already, and so although it's not a 'bug' per > se, I'd like to get it fixed in 2.5. Reviewed by Schuyler, checked in, merged to branch. > > 2 patches are awaiting pullups: > #1023, add ServiceVersion option to TMS, is as close to 0 risk as > you can get, and will better support gdal2tiles. Merged to branch. > #1040 fixes a mistake in the spherical-mercator example. Merged to branch. > 1 patch awaiting commit: > #1013 , OpenLayers.Layer.WMS.Untiled doesn't clone correctly. > (Regression) Committed, merged to branch. > 2 patches needing work: > #1034, OpenLayers.Util.pagePosition occasionally fails in IE. Fixed, Reviewed by Erik, committed, merged to branch. > #1043, OpenLayers zooms in too far on an extent Fixed, Reviewed by Me, committed, merged to branch. This means that we're ready to tag RC4. I'm going to write up release notes, etc. and go on to create the release. I'll send email to the list once it's out. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Wed Oct 3 17:48:14 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Presentation about OpenLayers In-Reply-To: <46F0ECD9.6010308@hft-stuttgart.de> References: <20070918145114.GT3930@vishnu.tridity.org> <46EFF4C0.7040206@dmsolutions.ca> <20070918204217.GA30700@metacarta.com> <46F0ECD9.6010308@hft-stuttgart.de> Message-ID: <6ae3fb590710031448r2d2129f3xf925b8be13ce6ead@mail.gmail.com> Thank you Dr. Behr for sending this to our lists. I have included a link to your presentation in our gallery under a new section "Academic References" http://trac.openlayers.org/wiki/Gallery Erik On 9/19/07, Dr. Franz-Josef Behr wrote: > Dear list, > > last week I had the opportunity to give a presentation at a meeting of a > "Automation in Cartography, Photogrammetry and GIS" > (http://www.ikg.uni-hannover.de/aga/) about Openlayers. > > If you are interested you download the updated PPT (English) from > http://www.gis-news.de/papers/fjb_openlayers_4e.ppt. > > A PDF version can be found at > http://www.ikg.uni-hannover.de/aga/pdf-files_aga2007/pdf_files_aga_vortraege_2007/aga2007_behr.pdf. > > Sorry for cross-posting! > > Mit freundlichen Gr??en / Regards / Cordialement > > Franz-Josef Behr > > > --------------------------------------------------------------- > What does education often do? > It makes a straight-cut ditch of a free, meandering brook. > H.D. THOREAU > --------------------------------------------------------------- > Prof. Dr. Franz-Josef Behr - Home Office > Author of: Strategisches GIS-Management - http://www.gis-management.de > eMail: franz-josef.behr@hft-stuttgart.de > http://www.gis-news.de > Tel: +49 (0)721 / 453980-1 sowie 45 33 35 > Fax: +49 (0)721 / 453980-7 sowie via web.de: +49 (0)1212-5-12048213 > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From pspencer at dmsolutions.ca Wed Oct 3 17:50:49 2007 From: pspencer at dmsolutions.ca (pspencer@dmsolutions.ca) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization Message-ID: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> What do you think about aligning singleTile bounds to the grid to promote cacheability in the client? Paul Sent from my BlackBerry device on the Rogers Wireless Network From crschmidt at metacarta.com Wed Oct 3 17:56:30 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> Message-ID: <20071003215630.GA19489@metacarta.com> On Wed, Oct 03, 2007 at 09:50:49PM +0000, pspencer@dmsolutions.ca wrote: > What do you think about aligning singleTile bounds to the grid to promote cacheability in the client? I think this has come up before, and I've been against it, but I don't use singleTile, so it's not really my call. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Wed Oct 3 17:58:15 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] OpenLayers 2.5 RC4 Announcement Message-ID: <20071003215815.GB19489@metacarta.com> The OpenLayers Development Team is proud to announce the fourth release candidate of OpenLayers 2.5. Fixes in this version include: * KML needs to automatically determine the namespace of the document it is handling. (#1044) * Fix for zoomToExtent + changebaselayer. (Closes #1043) * Clone on WMS/MS Untiled (Closes #1013) * serviceVersion on TMS (Closes #1023) * W3CGeo in Format.GeoRSS (Closes #1024) * GeoJSON Draft4 Update (Closes #1028) * pagePosition Regression (Closes #1034) * example changes (Closes #1040) * WFS missing registerTileListener (Closes #1045) * Tell Yahoo API to stop dragging (Closes #1052) We invite you to help us test the 2.5 release candidate! To test 2.5 in your applications, include the following tag in your OpenLayers-powered page: {{{ }}} As always, the source is available at http://openlayers.org/download/. Bug reports can be filed in Trac, under the 2.5 version and milestone. We look forward to your feedback! Regards, The OpenLayers Team From erik.uzureau at metacarta.com Wed Oct 3 18:00:32 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <20071003215630.GA19489@metacarta.com> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> <20071003215630.GA19489@metacarta.com> Message-ID: <6ae3fb590710031500o3f53cfbbiefcbae4125840d25@mail.gmail.com> Seems like a reasonable idea in theory, but you're going to have to have some big ratios.. no? On 10/3/07, Christopher Schmidt wrote: > On Wed, Oct 03, 2007 at 09:50:49PM +0000, pspencer@dmsolutions.ca wrote: > > What do you think about aligning singleTile bounds to the grid to promote cacheability in the client? > > I think this has come up before, and I've been against it, but I don't > use singleTile, so it's not really my call. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Wed Oct 3 18:04:54 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] OpenLayers 2.5 RC4 Announcement In-Reply-To: <20071003215815.GB19489@metacarta.com> References: <20071003215815.GB19489@metacarta.com> Message-ID: <6ae3fb590710031504l2e2803aweabe5ef5ec40a746@mail.gmail.com> Great work on getting this RC together, Chris. This has been a lot of work and let's all cross our fingers that this guy can survive till friday.... :-) Erik On 10/3/07, Christopher Schmidt wrote: > The OpenLayers Development Team is proud to announce the fourth release > candidate of OpenLayers 2.5. Fixes in this version include: > > * KML needs to automatically determine the namespace of the document it > is handling. (#1044) > * Fix for zoomToExtent + changebaselayer. (Closes #1043) > * Clone on WMS/MS Untiled (Closes #1013) > * serviceVersion on TMS (Closes #1023) > * W3CGeo in Format.GeoRSS (Closes #1024) > * GeoJSON Draft4 Update (Closes #1028) > * pagePosition Regression (Closes #1034) > * example changes (Closes #1040) > * WFS missing registerTileListener (Closes #1045) > * Tell Yahoo API to stop dragging (Closes #1052) > > > We invite you to help us test the 2.5 release candidate! To test 2.5 in > your applications, include the following tag in your OpenLayers-powered > page: > > {{{ > > }}} > > As always, the source is available at http://openlayers.org/download/. > Bug reports can be filed in Trac, under the 2.5 version and milestone. > > We look forward to your feedback! > > Regards, > > The OpenLayers Team > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Wed Oct 3 18:09:14 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] problem in OpenLayers.Util.pagePosition In-Reply-To: <80efecaf6bb882076151257f715325a1@145.50.39.11> References: <80efecaf6bb882076151257f715325a1@145.50.39.11> Message-ID: <6ae3fb590710031509u686c3796p6c963a97e338c52e@mail.gmail.com> Thanks Bart for this good bug find. We've found and fixed the problem and it's all bundled up in the new RC4 that cr5 just created. This sort of report is priceless for ensuring the quality of each release of OpenLayers. THANK YOU to everyone who gives our RC's a spin. We appreciate! E On 9/25/07, Bart van den Eijnden (OSGIS) wrote: > Hi list, > > using 2.5RC3 I have a problem in the above mentioned function, whereas this > works fine in version 2.4. The problem is only in IE. > > The error occurs in the following line of getStyle (style is null or not an > object): > > var value = element.style[OpenLayers.String.camelize(style)]; > > If I change the following line (back to its 2.4 equivalent): > > if(element == document.body) { > > to: > > if(element.offsetParent == document.body) { > > it works fine again. > > Best regards, > Bart > > -- > Bart van den Eijnden > OSGIS, Open Source GIS > http://www.osgis.nl > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From trondmm-openlayers at crusaders.no Wed Oct 3 18:03:53 2007 From: trondmm-openlayers at crusaders.no (Trond Michelsen) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <6ae3fb590710031500o3f53cfbbiefcbae4125840d25@mail.gmail.com> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> <20071003215630.GA19489@metacarta.com> <6ae3fb590710031500o3f53cfbbiefcbae4125840d25@mail.gmail.com> Message-ID: <20071003220353.GF3224@crusaders.no> On Wed, Oct 03, 2007 at 05:00:32PM -0500, Erik Uzureau wrote: > On 10/3/07, Christopher Schmidt wrote: >> On Wed, Oct 03, 2007 at 09:50:49PM +0000, pspencer@dmsolutions.ca wrote: >>> What do you think about aligning singleTile bounds to the grid to >>> promote cacheability in the client? >> I think this has come up before, and I've been against it, but I don't >> use singleTile, so it's not really my call. > Seems like a reasonable idea in theory, but you're going to have to > have some big ratios.. no? Sure, but I'm convinced it'll be a lot better than no caching whatsoever. Especially if there's no temporal data, and the maps can be cached indefinately. -- Trond Michelsen From erik.uzureau at metacarta.com Wed Oct 3 18:13:02 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <20071003220353.GF3224@crusaders.no> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> <20071003215630.GA19489@metacarta.com> <6ae3fb590710031500o3f53cfbbiefcbae4125840d25@mail.gmail.com> <20071003220353.GF3224@crusaders.no> Message-ID: <6ae3fb590710031513r3f62cfb8s46f6311a56131944@mail.gmail.com> Wait. didn't we have this discussion before? maybe i'm confused. I feel like we determined that this actually wouldn't work? someone better than me at logs.... E On 10/3/07, Trond Michelsen wrote: > On Wed, Oct 03, 2007 at 05:00:32PM -0500, Erik Uzureau wrote: > > On 10/3/07, Christopher Schmidt wrote: > >> On Wed, Oct 03, 2007 at 09:50:49PM +0000, pspencer@dmsolutions.ca wrote: > >>> What do you think about aligning singleTile bounds to the grid to > >>> promote cacheability in the client? > >> I think this has come up before, and I've been against it, but I don't > >> use singleTile, so it's not really my call. > > Seems like a reasonable idea in theory, but you're going to have to > > have some big ratios.. no? > > Sure, but I'm convinced it'll be a lot better than no caching > whatsoever. Especially if there's no temporal data, and the maps can > be cached indefinately. > > -- > Trond Michelsen > > From crschmidt at metacarta.com Wed Oct 3 18:55:08 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] OpenLayers 2.5 RC4 Announcement In-Reply-To: <6ae3fb590710031504l2e2803aweabe5ef5ec40a746@mail.gmail.com> References: <20071003215815.GB19489@metacarta.com> <6ae3fb590710031504l2e2803aweabe5ef5ec40a746@mail.gmail.com> Message-ID: <20071003225508.GA10742@metacarta.com> On Wed, Oct 03, 2007 at 05:04:54PM -0500, Erik Uzureau wrote: > Great work on getting this RC together, Chris. This has been a lot of work > and let's all cross our fingers that this guy can survive till friday.... :-) For the record (not sure if I've publicly voiced my relatively unwritten policy on this): this RC will exist for 3 days, at which point I will motion that the PSC accept it as the final release for 2.5, and then I'll put a fork in it and ship it. So, find bugs now! :) Regards, -- Christopher Schmidt MetaCarta From arnd.wippermann at web.de Wed Oct 3 19:13:11 2007 From: arnd.wippermann at web.de (Arnd Wippermann) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Zoom Problems Switching Baselayers -- HELP! In-Reply-To: <6ae3fb590710022250q5e274512i3ffdd89330066f96@mail.gmail.com> References: <6ae3fb590710022250q5e274512i3ffdd89330066f96@mail.gmail.com> Message-ID: <13029786.post@talk.nabble.com> the attached file shows this behavior. Arnd Wippermann http://gis.ibbeck.de/ginfo -- View this message in context: http://www.nabble.com/Zoom-Problems-Switching-Baselayers----HELP%21-tf4559972.html#a13029786 Sent from the OpenLayers Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071003/2ad3040e/attachment.html From arnd.wippermann at web.de Wed Oct 3 19:14:05 2007 From: arnd.wippermann at web.de (Arnd Wippermann) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Zoom Problems Switching Baselayers -- HELP! Message-ID: And the file Mit freundlichen Gr?ssen Arnd Wippermann http://gis.ibbeck.de/ginfo/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071004/4a46f676/zoomTest.html From cameron.shorter at gmail.com Wed Oct 3 19:11:20 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> <20071002130331.GA18878@metacarta.com> <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> Message-ID: <47042198.9040107@gmail.com> Of note: During the code sprint I helped to start building sample ogc:filters for the style. (Actually, I only built one) The next step I discussed with Andreas was to use a standard GML test set which I recommend should be the Tasmania GML used by Geoserver and Mapbuilder. Alex Djioev from Lisasoft did a little work on this yesterday and I expect he will be committing to Andreas's sandbox soon. Of interest and possible concern is that rendering seemed to be noticeably slower with the slightly larger Tasmania dataset. This dataset is still reasonably small by vector standards and we might need to consider ways to optimize. Andreas Hocevar wrote: > Chris, > > On 10/2/07, Christopher Schmidt wrote: > >> So, I would like to see at least a few tests before we bring it back >> into trunk: >> * Minimal constructor tests for any new classes >> * A test or two for each of the Rule.Foo subclasses, if possible >> * A minimal test for pulling in SLD. >> * Do we write out SLD from rules? if so, a round-trip test would be >> nice to have too -- read in, write out, compare to expected >> results. >> >> Nothing too complex -- just enough to build a framework so that future >> bugfixes can build on top of it. >> > > I will create these tests, hopefully today. Pierre already built the > minimal test for pulling in SLD in the Format.SLD test. We do not yet > write out SLD, so the round trip test will have to wait until someone > implements the write method. But, with the new way of storing the > rules, write() should be easier to do than with the eval stuff before. > > Regards, > Andreas. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From pspencer at dmsolutions.ca Wed Oct 3 22:04:34 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <6ae3fb590710031513r3f62cfb8s46f6311a56131944@mail.gmail.com> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> <20071003215630.GA19489@metacarta.com> <6ae3fb590710031500o3f53cfbbiefcbae4125840d25@mail.gmail.com> <20071003220353.GF3224@crusaders.no> <6ae3fb590710031513r3f62cfb8s46f6311a56131944@mail.gmail.com> Message-ID: <2C730A78-38EB-44A4-AA9B-306AA7C6CC35@dmsolutions.ca> I guess I missed the original discussion or don't remember it. I can see that there are some issues with how this might be implemented. For instance, it only makes sense to attempt this for singleTile layers that are not also a baseLayer AND if the baseLayer is not a singleTile layer. Otherwise there is no grid to synchronize the extents with. The reason I was asking is because we had implemented the singleTile concept in kaMap for a particular use case and it was aligned with the 'meta extent' of the currently loaded tiles. The meta extent are the extent of all loaded tiles in the base layer. The singleTile was redrawn when either a row or column of tiles was wrapped, rather than when an edge of the singleTile was inside the current viewport extent. The default in kaMap was to use a single tile buffer rather than a two tile buffer, so the singleTile render would be roughly the same size as the current OpenLayers singleTile ratio of 1.5 The potential performance gain is largely theoretical to me since I always run my browser with the cache turned off. However, as we are moving one particular client from kaMap to OpenLayers, they have noticed a difference. Chris, can you elaborate on why you are/were against this? Paul On 3-Oct-07, at 6:13 PM, Erik Uzureau wrote: > Wait. didn't we have this discussion before? maybe i'm confused. > I feel like we determined that this actually wouldn't work? > > someone better than me at logs.... > > E > > On 10/3/07, Trond Michelsen wrote: >> On Wed, Oct 03, 2007 at 05:00:32PM -0500, Erik Uzureau wrote: >>> On 10/3/07, Christopher Schmidt wrote: >>>> On Wed, Oct 03, 2007 at 09:50:49PM +0000, >>>> pspencer@dmsolutions.ca wrote: >>>>> What do you think about aligning singleTile bounds to the grid to >>>>> promote cacheability in the client? >>>> I think this has come up before, and I've been against it, but I >>>> don't >>>> use singleTile, so it's not really my call. >>> Seems like a reasonable idea in theory, but you're going to have to >>> have some big ratios.. no? >> >> Sure, but I'm convinced it'll be a lot better than no caching >> whatsoever. Especially if there's no temporal data, and the maps can >> be cached indefinately. >> >> -- >> Trond Michelsen >> >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From woodbri at swoodbridge.com Wed Oct 3 22:37:29 2007 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> References: <1230368016-1191448347-cardhu_decombobulator_blackberry.rim.net-1904841-@bxe010.bisx.prod.on.blackberry> Message-ID: <470451E9.7010204@swoodbridge.com> pspencer@dmsolutions.ca wrote: > What do you think about aligning singleTile bounds to the grid to > promote cacheability in the client? I think that this should be an option in the layer definition if it gets done. I can see some benefits to doing this, but the down side is that all images generated will be larger and slower to generate and the singleTile option needs to support more than one use case in my mind anyway. -Steve From andreas.hocevar at gmail.com Wed Oct 3 22:38:34 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <47042198.9040107@gmail.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> <20071002130331.GA18878@metacarta.com> <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> <47042198.9040107@gmail.com> Message-ID: <5b021dd0710031938s7cb45838g4654da838e2d9978@mail.gmail.com> Hi, I'm sorry Cameron, I totally forgot mentioning your help at the code sprint. Thank you! Alex, have you tried to get the latest version of the sandbox for the Tasmania test set? Because after the code sprint, calculating the correct style for a feature was done using eval(). Meanwhile, I changed this, and Firebug Profiler shows no significant delay in rendering features with the sld.xml test file from the sandbox. It would be interesting to get some profiling/performance report from you, with the latest version from the ahocevar/sldRenderer sandbox. Regards, Andreas. On 10/3/07, Cameron Shorter wrote: > Of note: > During the code sprint I helped to start building sample ogc:filters for > the style. (Actually, I only built one) > The next step I discussed with Andreas was to use a standard GML test > set which I recommend should be the Tasmania GML used by Geoserver and > Mapbuilder. > Alex Djioev from Lisasoft did a little work on this yesterday and I > expect he will be committing to Andreas's sandbox soon. > Of interest and possible concern is that rendering seemed to be > noticeably slower with the slightly larger Tasmania dataset. This > dataset is still reasonably small by vector standards and we might need > to consider ways to optimize. From andreas.hocevar at gmail.com Wed Oct 3 22:55:14 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <5b021dd0710031938s7cb45838g4654da838e2d9978@mail.gmail.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> <20071002130331.GA18878@metacarta.com> <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> <47042198.9040107@gmail.com> <5b021dd0710031938s7cb45838g4654da838e2d9978@mail.gmail.com> Message-ID: <5b021dd0710031955n2f820758l4a8de577ac1158b5@mail.gmail.com> Cameron, Alex, I think from my previous posting it might not be quite clear what this eval() thing was all about. On 10/3/07, Andreas Hocevar wrote: > Alex, have you tried to get the latest version of the sandbox for the > Tasmania test set? Because after the code sprint, calculating the > correct style for a feature was done using eval(). This is probably the reason why you are getting poor performance. And this is the reason why Tim and Chris urged me to get rid of it, which I did. So hopefully, things are a dramatically faster now than with the old eval() code. As I said, the Firebug profiler now shows no performance differences between the gml-renderer.html example and gml-layer-sld.html when zooming in once from the initial view. But of course, there are only three features to check. The first revision using the new rule evaluation code is r4746. Regards, Andreas. From bluecarto at gmail.com Thu Oct 4 06:03:54 2007 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] snapping patch In-Reply-To: <1188968273.7778.3.camel@mellon> References: <1188968273.7778.3.camel@mellon> Message-ID: Hi Jachym, I would like to know if there is a working demo of this functionnality somewhere on the web. I plan to look at your code in order to compare it to the code developed by Fredj also dealing with vector snapping (in sandbox/camptocamp/feature see modify-feature.html). We already manage to "edge" and "vertex" snapping. Though, we don't support custom snapping (for the moment). Thanks Pierre On 9/5/07, Jachym Cepicky wrote: > hallo, > > I added patch, which enables snapping function. The patch adds > this.snapDist to OL.Handler.Point(.js) and apart from intern snapping > functions, it also defines empty this.customSnap method, which can be > used by user to define her own (e.g. raster-based) snapping. > > http://trac.openlayers.org/ticket/954 > > hope, it works also for another devs... > jachym > > -- > Jachym Cepicky > e-mail: jachym.cepicky@gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > > From steven at minst.net Thu Oct 4 08:19:27 2007 From: steven at minst.net (Steven M. Ottens) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] overviewmap and non-WMS baselayers Message-ID: <4704DA4F.5040500@minst.net> Hi All, I'm struggling to get overviewmap working with google sperical mercator. The closest I've gotten is that you need to resize the window to get the extent correct. I've used the following html file: http://rafb.net/p/Zf97Cd94.html At last I decided to investigate if it works with normal/old fashioned google or any other non-WMS layer for that matter. So I tried to just add an overviewmap to the plain google.html example resulting in this code: http://rafb.net/p/wLXBX581.html But here I get the same error I initially got in google-sm: bounds has no properties var center = bounds.getCenterLonLat(); This is to trace back to a missing baseLayer in the overviewMap; Map.js calls this function: 1282 getMaxExtent: function () { 1283 var maxExtent = null; 1284 if (this.baseLayer != null) { 1285 maxExtent = this.baseLayer.maxExtent; 1286 } 1287 return maxExtent; 1288 }, and this.baseLayer = null in this case To investigate further I tried TMS this way: http://rafb.net/p/cEKu5z90.html And this time it gave me the wrong extent, just like google-sm in the first example. So now I am wondering if there's something in overviewmap wrong, or in the way I invoke overviewmap. If anyone with a better insight in OverviewMap.js can help me out, I'd really appreciate it. regards, Steven From danlittle at yahoo.com Thu Oct 4 08:28:11 2007 From: danlittle at yahoo.com (Dan Little) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization Message-ID: <904740.87644.qm@web51402.mail.re2.yahoo.com> Yikes, first time poster! I think the speed to generate a single tile is wholely dependent on the map-rendering engine and the dataset. For example, here at the City of Saint Paul, our streets layer is entirely vector. I can generate a very very large tile with highly detailed streets for the entire city using Mapserver in less than 1/3 of a second. Given the nature of MapServer, and the size of the shapefile which stores our streets layer, multiple tiles is much much slower (as the shapefile needs to be read from disk and loaded to memory for each rendered tile). It would be nice to have some of the effects of tiling without the high-cost it currently presents in rendering performance. Dan "Ducky" Little City of Saint Paul / Public Works / GIS ----- Original Message ---- From: Stephen Woodbridge To: pspencer@dmsolutions.ca Cc: dev@openlayers.org Sent: Wednesday, October 3, 2007 9:37:29 PM Subject: Re: [OpenLayers-Dev] singleTile optimization pspencer@dmsolutions.ca wrote: > What do you think about aligning singleTile bounds to the grid to > promote cacheability in the client? I think that this should be an option in the layer definition if it gets done. I can see some benefits to doing this, but the down side is that all images generated will be larger and slower to generate and the singleTile option needs to support more than one use case in my mind anyway. -Steve _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071004/9417fa1e/attachment.html From david.bitner at gmail.com Thu Oct 4 09:36:16 2007 From: david.bitner at gmail.com (David William Bitner) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <904740.87644.qm@web51402.mail.re2.yahoo.com> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> Message-ID: Ducky! Great to see you here -- don't be a stranger. The problem with aligning singleTile to a grid is that as soon as you have the corner of the grid on the screen, all the sudden you are in a tiled mode only with larger tiles. It strikes me that for any use case that would require any kind of grid alignment at all, really you should be using a tiled mode only with perhaps larger tiles and smaller buffers. The use case that I see for single tile is for dynamic data -- data that is dynamic enough that you wouldn't want it cached at all, ever. David On 10/4/07, Dan Little wrote: > > Yikes, first time poster! > > I think the speed to generate a single tile is wholely dependent on the > map-rendering engine and the dataset. > > For example, here at the City of Saint Paul, our streets layer is entirely > vector. I can generate a very very large tile with highly detailed streets > for the entire city using Mapserver in less than 1/3 of a second. Given the > nature of MapServer, and the size of the shapefile which stores our streets > layer, multiple tiles is much much slower (as the shapefile needs to be read > from disk and loaded to memory for each rendered tile). It would be nice to > have some of the effects of tiling without the high-cost it currently > presents in rendering performance. > > Dan "Ducky" Little > City of Saint Paul / Public Works / GIS > > > ----- Original Message ---- > From: Stephen Woodbridge > To: pspencer@dmsolutions.ca > Cc: dev@openlayers.org > Sent: Wednesday, October 3, 2007 9:37:29 PM > Subject: Re: [OpenLayers-Dev] singleTile optimization > > pspencer@dmsolutions.ca wrote: > > What do you think about aligning singleTile bounds to the grid to > > promote cacheability in the client? > > I think that this should be an option in the layer definition if it gets > done. I can see some benefits to doing this, but the down side is that > all images generated will be larger and slower to generate and the > singleTile option needs to support more than one use case in my mind > anyway. > > -Steve > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > > ------------------------------ > Luggage? GPS? Comic books? > Check out fitting gifts for gradsat Yahoo! Search. > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- ************************************ David William Bitner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071004/bf8bc7e3/attachment.html From erik.uzureau at metacarta.com Thu Oct 4 12:09:34 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: References: <904740.87644.qm@web51402.mail.re2.yahoo.com> Message-ID: <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> There we go. What David's said here is what I was grasping for earlier here. If you use a singleTile layer that is gridded, *eventully* the user is going to pan the map such that the corners of the grid are in the viewbox. At that point, the only option is to load 4 tiles, at which point, we're back to gridded, in which case you might as well just use a normal gridded layer with a very big tilesize and a buffer:0 Alternatively, One could imagine a tile layer which is double-tiled and that would avoid this problem, but seems like a horrible implementation nightmare. On 10/4/07, David William Bitner wrote: > Ducky! > > Great to see you here -- don't be a stranger. > > The problem with aligning singleTile to a grid is that as soon as you have > the corner of the grid on the screen, all the sudden you are in a tiled mode > only with larger tiles. It strikes me that for any use case that would > require any kind of grid alignment at all, really you should be using a > tiled mode only with perhaps larger tiles and smaller buffers. The use case > that I see for single tile is for dynamic data -- data that is dynamic > enough that you wouldn't want it cached at all, ever. > > David > > > On 10/4/07, Dan Little wrote: > > > > > > > > Yikes, first time poster! > > > > I think the speed to generate a single tile is wholely dependent on the > map-rendering engine and the dataset. > > > > For example, here at the City of Saint Paul, our streets layer is entirely > vector. I can generate a very very large tile with highly detailed streets > for the entire city using Mapserver in less than 1/3 of a second. Given the > nature of MapServer, and the size of the shapefile which stores our streets > layer, multiple tiles is much much slower (as the shapefile needs to be read > from disk and loaded to memory for each rendered tile). It would be nice to > have some of the effects of tiling without the high-cost it currently > presents in rendering performance. > > > > Dan "Ducky" Little > > City of Saint Paul / Public Works / GIS > > > > > > > > > > ----- Original Message ---- > > From: Stephen Woodbridge > > To: pspencer@dmsolutions.ca > > Cc: dev@openlayers.org > > Sent: Wednesday, October 3, 2007 9:37:29 PM > > Subject: Re: [OpenLayers-Dev] singleTile optimization > > > > > > pspencer@dmsolutions.ca wrote: > > > What do you think about aligning singleTile bounds to the grid to > > > promote cacheability in the client? > > > > I think that this should be an option in the layer definition if it gets > > done. I can see some benefits to doing this, but the down side is that > > all images generated will be larger and slower to generate and the > > singleTile option needs to support more than one use case in my mind > anyway. > > > > -Steve > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > > > ________________________________ > Luggage? GPS? Comic books? > > Check out fitting gifts for grads at Yahoo! Search. > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > > > > > -- > ************************************ > David William Bitner > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > From crschmidt at metacarta.com Thu Oct 4 12:16:26 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> Message-ID: <20071004161626.GG31692@metacarta.com> On Thu, Oct 04, 2007 at 11:09:34AM -0500, Erik Uzureau wrote: > There we go. What David's said here is what I was grasping for earlier here. > > If you use a singleTile layer that is gridded, *eventully* the user is > going to pan the map such that the corners of the grid are in the > viewbox. At that point, the only option is to load 4 tiles, at which > point, we're back to gridded, in which case you might as well just use > a normal gridded layer with a very big tilesize and a buffer:0 I think Paul is imagining a singleTile which matches the grid of a *smaller* set of tiles -- so the gridded tile is 'snapped' to a corner of a smaller grid. For example, you could imagine the grid existing at 0.5 degree increments all the way across the world, and the tile would snap to the closest one. The tile no longer has equal buffer space on all outside edges, but is more cachable. The size of a single grid square must be smaller than the smallest area that can outside the map at any given time, so when the new area is requested, the tile 'jumps' to fill it, but positions itself based on the grid instead of based on the map center. Regards, -- Christopher Schmidt MetaCarta From eric.c2c at gmail.com Thu Oct 4 12:22:27 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] [OpenLayers-Users] callback for close button on popup In-Reply-To: <6ae3fb590709120749y5052849bq41eee78e4bce5f2b@mail.gmail.com> References: <44b0bbf60709120747l28cb83c7y271f61843238352a@mail.gmail.com> <6ae3fb590709120749y5052849bq41eee78e4bce5f2b@mail.gmail.com> Message-ID: <5ec103de0710040922g476fa6sc12d0b6a1c4dd8bf@mail.gmail.com> On 9/12/07, Erik Uzureau wrote: > Currently there is no way to do that. > If that is something you would find useful, please open a ticket and we > can consider it for 2.6. :-) I opened a ticket and attached a patch. I still need to create tests for the patch to be marked as review. -- Eric From erik.uzureau at metacarta.com Thu Oct 4 12:22:51 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Zoom Problems Switching Baselayers -- HELP! In-Reply-To: References: Message-ID: <6ae3fb590710040922v448af56ck334bb47cc00a2b30@mail.gmail.com> Hi Arnd, Thanks for sending this test code... can you explain what we should test for, though? ie how do we know if our patch has fixed the problem for you? Erik On 10/3/07, Arnd Wippermann wrote: > And the file > > Mit freundlichen Gr?ssen > > Arnd Wippermann > http://gis.ibbeck.de/ginfo/ > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > > From eric.c2c at gmail.com Thu Oct 4 12:23:02 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] [OpenLayers-Users] callback for close button on popup In-Reply-To: <5ec103de0710040922g476fa6sc12d0b6a1c4dd8bf@mail.gmail.com> References: <44b0bbf60709120747l28cb83c7y271f61843238352a@mail.gmail.com> <6ae3fb590709120749y5052849bq41eee78e4bce5f2b@mail.gmail.com> <5ec103de0710040922g476fa6sc12d0b6a1c4dd8bf@mail.gmail.com> Message-ID: <5ec103de0710040923q9087151k58e407a3b0fb5331@mail.gmail.com> On 10/4/07, Eric Lemoine wrote: > On 9/12/07, Erik Uzureau wrote: > > Currently there is no way to do that. > > If that is something you would find useful, please open a ticket and we > > can consider it for 2.6. :-) > > I opened a ticket and attached a patch. I still need to create tests > for the patch to be marked as review. Forgot to provide the ticket URL: -- Eric From pspencer at dmsolutions.ca Thu Oct 4 13:05:27 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <20071004161626.GG31692@metacarta.com> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> <20071004161626.GG31692@metacarta.com> Message-ID: <72F2E3A5-9D8E-4F79-95B8-3DC8DD03E7B4@dmsolutions.ca> On 4-Oct-07, at 12:16 PM, Christopher Schmidt wrote: > On Thu, Oct 04, 2007 at 11:09:34AM -0500, Erik Uzureau wrote: >> There we go. What David's said here is what I was grasping for >> earlier here. >> >> If you use a singleTile layer that is gridded, *eventully* the >> user is >> going to pan the map such that the corners of the grid are in the >> viewbox. At that point, the only option is to load 4 tiles, at which >> point, we're back to gridded, in which case you might as well just >> use >> a normal gridded layer with a very big tilesize and a buffer:0 > > I think Paul is imagining a singleTile which matches the grid of a > *smaller* set of tiles -- so the gridded tile is 'snapped' to a corner > of a smaller grid. For example, you could imagine the grid existing at > 0.5 degree increments all the way across the world, and the tile would > snap to the closest one. The tile no longer has equal buffer space > on all > outside edges, but is more cachable. > > The size of a single grid square must be smaller than the smallest > area > that can outside the map at any given time, so when the new area is > requested, the tile 'jumps' to fill it, but positions itself based on > the grid instead of based on the map center. right, the positioning based on grid rather than map center is the critical part since the requests are then more likely to be retrieved from the browser cache when returning to the same area. But the argument about wanting singleTile to be very dynamic is still a valid concern, to which I would say that in the current approach, client side caching becomes essentially a random event in which someone may get an old image and would not understand why. With a deliberately cacheable approach like snapping to the tile grid, we then have to think deliberately about how to avoid caching them and then actually get predictable behaviour. Paul > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Thu Oct 4 14:42:39 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] OL2.5RC5 Upcoming Message-ID: <20071004184239.GA11485@metacarta.com> In testing today, I found out htat OL 2.5 RC4 has a showstopping bug for serializing vector features to GeoJSON. I've fixed it in trunk, and it will be going into what will becomne 2.5 RC5. Unless I hear otherwise, I plan to do the release at the end of my work day, which is in about 3.5 hours. Go hunt! :) Regards, -- Christopher Schmidt MetaCarta From andreas.hocevar at gmail.com Thu Oct 4 17:38:08 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Code Sprint: SLD In-Reply-To: <47049FFB.5070605@lisasoft.com> References: <20071001124248.GB15010@metacarta.com> <5b021dd0710020012j2a2c95d6s692e353e3b693a06@mail.gmail.com> <20071002130331.GA18878@metacarta.com> <5b021dd0710021031v7edc6116kbebd7c744279461b@mail.gmail.com> <47042198.9040107@gmail.com> <5b021dd0710031938s7cb45838g4654da838e2d9978@mail.gmail.com> <5b021dd0710031955n2f820758l4a8de577ac1158b5@mail.gmail.com> <47049FFB.5070605@lisasoft.com> Message-ID: <5b021dd0710041438y5d3bc88dwed5b7fe629858a62@mail.gmail.com> Hi Alex, On 10/4/07, Alexandre Djioev wrote: > I have committed the file gml-tasmania-layer-sld.html, at this moment > its got about 8 different property tests. I have problems with > PropertyIsLessThanOrEqualTo, PropertyIsGreaterThanOrEqualTo Fixed. > and > PropertyIsLike There was a problem in your syntax, AND it was unimplemented. Anyway, I implemented it now and fixed your sld. So here's the new status of ogc:Filter support: - all comparison filters supported - all logical filters supported - FeatureId filter supported Regards, Andreas. From crschmidt at metacarta.com Thu Oct 4 18:57:55 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] OpenLayers 2.5 RC5 Released Message-ID: <20071004225755.GA5976@metacarta.com> The OpenLayers Development Team is (somewhat sheepishly) proud to announce the fifth release candidate of OpenLayers 2.5. The only fix in this version is: * Correcting GeoJSON write support for features attached to a layer (Closes #1062) We invite you to help us test the 2.5 release candidate! To test 2.5 in your applications, include the following tag in your OpenLayers-powered page: {{{ }}} As always, the source is available at http://openlayers.org/download/. Bug reports can be filed in Trac, under the 2.5 version and milestone. We look forward to your feedback! Regards, The OpenLayers Team -- Christopher Schmidt MetaCarta From woodbri at swoodbridge.com Thu Oct 4 22:04:34 2007 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <20071004161626.GG31692@metacarta.com> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> <20071004161626.GG31692@metacarta.com> Message-ID: <47059BB2.3030402@swoodbridge.com> Christopher Schmidt wrote: > On Thu, Oct 04, 2007 at 11:09:34AM -0500, Erik Uzureau wrote: >> There we go. What David's said here is what I was grasping for earlier here. >> >> If you use a singleTile layer that is gridded, *eventully* the user is >> going to pan the map such that the corners of the grid are in the >> viewbox. At that point, the only option is to load 4 tiles, at which >> point, we're back to gridded, in which case you might as well just use >> a normal gridded layer with a very big tilesize and a buffer:0 > > I think Paul is imagining a singleTile which matches the grid of a > *smaller* set of tiles -- so the gridded tile is 'snapped' to a corner > of a smaller grid. For example, you could imagine the grid existing at > 0.5 degree increments all the way across the world, and the tile would > snap to the closest one. The tile no longer has equal buffer space on all > outside edges, but is more cachable. > > The size of a single grid square must be smaller than the smallest area > that can outside the map at any given time, so when the new area is > requested, the tile 'jumps' to fill it, but positions itself based on > the grid instead of based on the map center. > > Regards, OR that the single tile is always rounded up so that the off screen corners snap to a tile vertices, but it is centered on the appropriate point in the viewport. Think of it as a single tile with a buffer, but the buffer is always snapped to the nearest tile vertex that is off screen. This just makes the image somewhat more cache-able at the expense of larger images. and you could slide the image up to the buffer edge without requesting a new image. I am not suggesting that we do this, only that it is another interpretation of Pauls request. The other reason that people might want to run singleTile models is that they do not want the overhead of setting up a tilecache and managing it. For example, I do a lot of small low volume pages that do not need tiles, it would just needlessly complicate things. -Steve From ian at planetmayo.com Fri Oct 5 03:54:37 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] SVN newbie looking forward to updating his sandbox Message-ID: Hi all, 2.5 will be "hitting the streets quite soon", but I'm unsure how to update my sandbox to include the updates sources. I created my sandbox a few weeks ago, and have made some changes to existing code aswell as creating new files. Can any sandbox owners give me some advice on how to update the sandbox without losing modifications? I presume there's an automated step (where unmodified sandbox files get replaced by newer versions) and a handraulic step (where conflicts get resolved by eye). thanks in advance, Ian. From eric.c2c at gmail.com Fri Oct 5 05:41:39 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] SVN newbie looking forward to updating his sandbox In-Reply-To: References: Message-ID: <5ec103de0710050241v10d8aef4x8b88b139699be349@mail.gmail.com> On 10/5/07, Ian Mayo wrote: > Hi all, > 2.5 will be "hitting the streets quite soon", but I'm unsure how to > update my sandbox to include the updates sources. > > I created my sandbox a few weeks ago, and have made some changes to > existing code aswell as creating new files. Can any sandbox owners > give me some advice on how to update the sandbox without losing > modifications? > > I presume there's an automated step (where unmodified sandbox files > get replaced by newer versions) and a handraulic step (where conflicts > get resolved by eye). Christopher Schmidt explained this a while back. < http://www.nabble.com/sandbox-howto-tf4205048.html#a11963070> -- Eric From ian at planetmayo.com Fri Oct 5 08:33:56 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] SVN newbie looking forward to updating his sandbox In-Reply-To: <5ec103de0710050241v10d8aef4x8b88b139699be349@mail.gmail.com> References: <5ec103de0710050241v10d8aef4x8b88b139699be349@mail.gmail.com> Message-ID: Christopher's advice followed, steps inserted into FAQ of OpenLayers wiki. thanks team... Ian On 05/10/2007, Eric Lemoine wrote: > On 10/5/07, Ian Mayo wrote: > > Hi all, > > Christopher Schmidt explained this a while back. > < http://www.nabble.com/sandbox-howto-tf4205048.html#a11963070> > > -- > Eric > From pspencer at dmsolutions.ca Fri Oct 5 09:56:31 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <47059BB2.3030402@swoodbridge.com> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> <20071004161626.GG31692@metacarta.com> <47059BB2.3030402@swoodbridge.com> Message-ID: <3E44E549-5358-4D5E-AE3C-CB9CDC825DD8@dmsolutions.ca> On 4-Oct-07, at 10:04 PM, Stephen Woodbridge wrote: snip ... > OR that the single tile is always rounded up so that the off screen > corners snap to a tile vertices, but it is centered on the appropriate > point in the viewport. > > Think of it as a single tile with a buffer, but the buffer is always > snapped to the nearest tile vertex that is off screen. This just makes > the image somewhat more cache-able at the expense of larger images. > and > you could slide the image up to the buffer edge without requesting > a new > image. > > I am not suggesting that we do this, only that it is another > interpretation of Pauls request. > > The other reason that people might want to run singleTile models is > that > they do not want the overhead of setting up a tilecache and > managing it. > For example, I do a lot of small low volume pages that do not need > tiles, it would just needlessly complicate things. Stephen, right now, the singleTile implementation defaults to a ratio of 1.5, which means that a singleTile draw is 1.5 times larger than the viewport. In many cases, people use large viewports because it is cheap with tiles. The default singleTile will then draw a tile much larger than the loaded grid. I don't think that larger images is actually the issue here. Also note that if you use singleTile instead of tiles, you are using a singleTile as the baseLayer and then there is no convenient grid to snap to. My original contention was that this was only useful when singleTile is not a baseLayer AND the baseLayer is not singleTile. I suppose it would be possible to deterministically size/place the singleTile such that it behaved more like a tiled layer but that was not my use case. Just to elaborate a little more, here is my use case: 1) user is able to create a dynamic overlay by searching a database of points - could be anything but in my case it is real estate locations 2) user can specify a wide range of criteria to filter the locations 3) user can change the criteria at any time 4) user can view all available results at any available resolution 5) there can be upwards of 50,000 results to display at any one time 6) new locations are added dynamically in the back end at any time, but they do not need to be included in the 'current' query. 7) typical coverage for a user is an entire US state We can't conveniently tile every query, even dynamic tiling takes too long and would have too short a useful life span (i.e. the tiles may or may not get used again.) The number of options make it unlikely that we could share tiles between users at any given point in time. And dynamic tiling requires administrative stuff to clean up because disk space is not unlimited. Perhaps a somewhat esoteric use case ... anyways, not much of an issue. I only originally wanted to know if folks had thought of it, and if not, would it be a generally useful idea. I'm getting the sense that there is some differences of opinion in how useful it will be. Fortunately, Chris is so tied up in vector stuff that I can probably slip the change by him ;) Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From ian at planetmayo.com Fri Oct 5 10:22:50 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Design for scale-line In-Reply-To: References: Message-ID: Hi all, I have a working demonstrator at: http://dev.openlayers.org/sandbox/ianmayo/openlayers/examples/controls.html At the top-right of the plot you'll see the current scale represented as a bar. As far as I can see, the implementation seems sound - I just have to polish off the unit tests (the earlier tests were more associated with me learning how the scaling works). Aaah, and yes, please break it & report as appropriate. I'd also appreciate hearing what configurable options people may want. Currently we have m/km on the top and ft/mi on the bottom - switching between the correct set to use depending on how far we've zoomed in. Does anybody want to be able to configure to use other units? Ian. On 02/10/2007, Ian Mayo wrote: > Here's the design for my OpenLayers scale control, aimed to offer > similar functionality to the scale offered in google maps. > Any advice? > > thanks in advance for any support, > Ian. > > p.s. Should I have written this content into a wiki page? Opinions welcome. > From ian at planetmayo.com Fri Oct 5 10:32:06 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units Message-ID: Hi, the maritime GIS community work in yards and nautical miles, so the following lines could be added to util.js OpenLayers.INCHES_PER_UNIT["yd"]= 36; // a yard is 36 inches OpenLayers.INCHES_PER_UNIT["nmi"]= 1852 * OpenLayers.INCHES_PER_UNIT["m"]; // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) How do the community feel about adding maritime units to OpenLayers? I appreciate developers can insert the above lines directly into the custom applications, but suspect a better home is in the trunk. thanks, Ian. From crschmidt at metacarta.com Fri Oct 5 11:26:27 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: References: Message-ID: <20071005152627.GB19044@metacarta.com> On Fri, Oct 05, 2007 at 03:32:06PM +0100, Ian Mayo wrote: > Hi, > the maritime GIS community work in yards and nautical miles, so the > following lines could be added to util.js > > OpenLayers.INCHES_PER_UNIT["yd"]= 36; > // a yard is 36 inches > OpenLayers.INCHES_PER_UNIT["nmi"]= 1852 * OpenLayers.INCHES_PER_UNIT["m"]; > // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) here you use '1852 * m', but it seems like this should be 1852 * yd. Also, I think 'nm' is the better abbreviation. > How do the community feel about adding maritime units to OpenLayers? Indifferent, but it seems unlikely to hurt anything :) > I appreciate developers can insert the above lines directly into the > custom applications, but suspect a better home is in the trunk. I'm generally okay with this. Can you put together a patch and file a ticket? Regards, -- Christopher Schmidt MetaCarta From woodbri at swoodbridge.com Fri Oct 5 11:31:19 2007 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] singleTile optimization In-Reply-To: <3E44E549-5358-4D5E-AE3C-CB9CDC825DD8@dmsolutions.ca> References: <904740.87644.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710040909y160f111bm2aab8b5601fbeed7@mail.gmail.com> <20071004161626.GG31692@metacarta.com> <47059BB2.3030402@swoodbridge.com> <3E44E549-5358-4D5E-AE3C-CB9CDC825DD8@dmsolutions.ca> Message-ID: <470658C7.10603@swoodbridge.com> Paul, Thanks for the more detailed explanation of your use case. Paul Spencer wrote: > > On 4-Oct-07, at 10:04 PM, Stephen Woodbridge wrote: > > snip ... > >> OR that the single tile is always rounded up so that the off screen >> corners snap to a tile vertices, but it is centered on the appropriate >> point in the viewport. >> >> Think of it as a single tile with a buffer, but the buffer is always >> snapped to the nearest tile vertex that is off screen. This just makes >> the image somewhat more cache-able at the expense of larger images. and >> you could slide the image up to the buffer edge without requesting a new >> image. >> >> I am not suggesting that we do this, only that it is another >> interpretation of Pauls request. >> >> The other reason that people might want to run singleTile models is that >> they do not want the overhead of setting up a tilecache and managing it. >> For example, I do a lot of small low volume pages that do not need >> tiles, it would just needlessly complicate things. > > Stephen, > > right now, the singleTile implementation defaults to a ratio of 1.5, > which means that a singleTile draw is 1.5 times larger than the > viewport. In many cases, people use large viewports because it is cheap > with tiles. The default singleTile will then draw a tile much larger > than the loaded grid. I don't think that larger images is actually the > issue here. Right. I usually set ratio: 1 > Also note that if you use singleTile instead of tiles, you are using a > singleTile as the baseLayer and then there is no convenient grid to snap > to. My original contention was that this was only useful when > singleTile is not a baseLayer AND the baseLayer is not singleTile. I > suppose it would be possible to deterministically size/place the > singleTile such that it behaved more like a tiled layer but that was not > my use case. Ahh, gotcha. I had the random thought that if the grid was defined as say 256x256 pixel tiles the the "extended" singleTile would get rounded up to that grid intervals. Like if you needed 4 tiles to fill the viewport then the single tile would be the size of the 4 tiles glued into a single tile. This would make the single tiles some what more cache able because they would always get round to the 256 values. But like I said, I'm not advocating it, it was just a random thought triggered by the discussion. Best regards, -Steve > Just to elaborate a little more, here is my use case: > > 1) user is able to create a dynamic overlay by searching a database of > points - could be anything but in my case it is real estate locations > > 2) user can specify a wide range of criteria to filter the locations > > 3) user can change the criteria at any time > > 4) user can view all available results at any available resolution > > 5) there can be upwards of 50,000 results to display at any one time > > 6) new locations are added dynamically in the back end at any time, but > they do not need to be included in the 'current' query. > > 7) typical coverage for a user is an entire US state > > We can't conveniently tile every query, even dynamic tiling takes too > long and would have too short a useful life span (i.e. the tiles may or > may not get used again.) The number of options make it unlikely that we > could share tiles between users at any given point in time. And dynamic > tiling requires administrative stuff to clean up because disk space is > not unlimited. > > Perhaps a somewhat esoteric use case ... anyways, not much of an issue. > I only originally wanted to know if folks had thought of it, and if not, > would it be a generally useful idea. I'm getting the sense that there > is some differences of opinion in how useful it will be. Fortunately, > Chris is so tied up in vector stuff that I can probably slip the change > by him ;) > > Cheers > > Paul > > > > > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > From ian at planetmayo.com Fri Oct 5 12:00:51 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: <20071005152627.GB19044@metacarta.com> References: <20071005152627.GB19044@metacarta.com> Message-ID: On 05/10/2007, Christopher Schmidt wrote: > On Fri, Oct 05, 2007 at 03:32:06PM +0100, Ian Mayo wrote: > > // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) > > here you use '1852 * m', but it seems like this should be 1852 * yd. duh. > I'm generally okay with this. Can you put together a patch and file a > ticket? > Christopher Schmidt > MetaCarta Sure. Guess what svn procedure I'm going to be researching in the next few hours... thanks for your (measured) support, Ian. From crschmidt at metacarta.com Fri Oct 5 12:46:13 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: References: <20071005152627.GB19044@metacarta.com> Message-ID: <20071005164613.GA15899@metacarta.com> On Fri, Oct 05, 2007 at 05:00:51PM +0100, Ian Mayo wrote: > Sure. Guess what svn procedure I'm going to be researching in the > next few hours... This one should be easy: * svn co http://svn.openlayers.org/trunk/openlayers/ * cd openlayers * $EDITOR lib/OpenLayers/Util.js * svn diff > patchfile.patch Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Fri Oct 5 14:49:31 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] SVN newbie looking forward to updating his sandbox In-Reply-To: References: <5ec103de0710050241v10d8aef4x8b88b139699be349@mail.gmail.com> Message-ID: <6ae3fb590710051149t6e44e5d9of75b992fda4784d@mail.gmail.com> Hey Ian, Thanks for adding that to the FAQ! Everyone wins. Erik On 10/5/07, Ian Mayo wrote: > Christopher's advice followed, steps inserted into FAQ of OpenLayers wiki. > > thanks team... > > Ian > > On 05/10/2007, Eric Lemoine wrote: > > On 10/5/07, Ian Mayo wrote: > > > Hi all, > > > > Christopher Schmidt explained this a while back. > > < http://www.nabble.com/sandbox-howto-tf4205048.html#a11963070> > > > > -- > > Eric > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Fri Oct 5 14:51:06 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: <20071005164613.GA15899@metacarta.com> References: <20071005152627.GB19044@metacarta.com> <20071005164613.GA15899@metacarta.com> Message-ID: <6ae3fb590710051151i22b69bc2nd2903bed62d04c5c@mail.gmail.com> alternatively: http://trac.openlayers.org/wiki/FilingTickets On 10/5/07, Christopher Schmidt wrote: > On Fri, Oct 05, 2007 at 05:00:51PM +0100, Ian Mayo wrote: > > Sure. Guess what svn procedure I'm going to be researching in the > > next few hours... > > This one should be easy: > * svn co http://svn.openlayers.org/trunk/openlayers/ > * cd openlayers > * $EDITOR lib/OpenLayers/Util.js > * svn diff > patchfile.patch > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From vgvallee at hotmail.com Fri Oct 5 16:33:43 2007 From: vgvallee at hotmail.com (=?iso-8859-1?Q?Vincent-Gabriel_Vall=E9e?=) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Vincenty with 1 Point, Bearing and Distance Message-ID: Hi all, There is another formula from Vincenty that permits to use 1 point, a bearing and a distance to obtain the coordinates of the target there. You can find the original JavaScript here: http://www.movable-type.co.uk- /scripts- /latlong-vincenty-direct.html I think this function should also be part of OpenLayers.Util as the distVincenty is. However, what would be the best return value type? I thought that since a OpenLayers.LonLat is used as a parameter, maybe that should be the return type. On the other hand, I needed such a function to create a geometry, which takes in an OpenLayers.Geometry.Point as a parameter so that I need to convert all points (what's the best way to do that?). Vincent Here is the function from the link above dapted for OpenLayers: /** * Function: destVincenty * * Parameters: * p1 - {} * bearing - {Float} The bearing, with 0 degree being true north and clockwise positive. * dist - {Float} The distance, in kilometers. * * Returns: * {} * * Note: * Adapted from Vincenty 'Direct' formula: (). */ OpenLayers.Util.destVincenty=function(p1, bearing, dist) { var a = 6378137, b = 6356752.3142, f = 1/298.257223563; // WGS-84 ellipsiod var s = dist * 1000; var alpha1 = OpenLayers.Util.rad(bearing); var sinAlpha1 = Math.sin(alpha1), cosAlpha1 = Math.cos(alpha1); var tanU1 = (1-f) * Math.tan(OpenLayers.Util.rad(p1.lat)); var cosU1 = 1 / Math.sqrt((1 + tanU1*tanU1)), sinU1 = tanU1*cosU1; var sigma1 = Math.atan2(tanU1, cosAlpha1); var sinAlpha = cosU1 * sinAlpha1; var cosSqAlpha = 1 - sinAlpha*sinAlpha; var uSq = cosSqAlpha * (a*a - b*b) / (b*b); var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq))); var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq))); var sigma = s / (b*A), sigmaP = 2*Math.PI; while (Math.abs(sigma-sigmaP) > 1e-12) { var cos2SigmaM = Math.cos(2*sigma1 + sigma); var sinSigma = Math.sin(sigma), cosSigma = Math.cos(sigma); var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)- B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM))); sigmaP = sigma; sigma = s / (b*A) + deltaSigma; } var tmp = sinU1*sinSigma - cosU1*cosSigma*cosAlpha1; var lat2 = Math.atan2(sinU1*cosSigma + cosU1*sinSigma*cosAlpha1, (1-f)*Math.sqrt(sinAlpha*sinAlpha + tmp*tmp)); var lambda = Math.atan2(sinSigma*sinAlpha1, cosU1*cosSigma - sinU1*sinSigma*cosAlpha1); var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha)); var L = lambda - (1-C) * f * sinAlpha * (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM))); var revAz = Math.atan2(sinAlpha, -tmp); // final bearing return new OpenLayers.LonLat(p1.lon+OpenLayers.Util.deg(L),OpenLayers.Util.deg(lat2)); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071005/711ea90d/attachment.html From vgvallee at hotmail.com Fri Oct 5 16:46:24 2007 From: vgvallee at hotmail.com (vgvallee) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Vincenty with 1 Point, Bearing and Distance In-Reply-To: References: Message-ID: <13067072.post@talk.nabble.com> I forgot to mention that I also added a function OpenLayers.Util.deg similar to the rad function. /** * Function: deg * * Parameters: * x - {Float} * * Returns: * {Float} */ OpenLayers.Util.deg = function(x) {return x*180/Math.PI;}; -- View this message in context: http://www.nabble.com/Vincenty-with-1-Point%2C-Bearing-and-Distance-tf4577470.html#a13067072 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From pspencer at dmsolutions.ca Fri Oct 5 16:47:21 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Design for scale-line In-Reply-To: References: Message-ID: Hi Ian, looks like nicely written code :) I'm sure this will be very useful to have as a Control in OpenLayers. I have a few comments: 1) you have a problem with tabs vs spaces in code formatting that made my eyes wonky in a couple of places. 2) you do not seem to be accommodating the current units of the map - I use different projections, often in meters. From the docs: units {String} The map units. Defaults to ?degrees?. Possible values are ?degrees? (or ?dd?), ?m?, ?ft?, ?km?, ?mi?, ?inches?. So you need to check to see what map.units is before converting 3) If the units are decimal degrees, you should adjust the calculation based on the current latitude of the center using the cosine of the latitude. This was from a distance measuring tool I did a while back: d = d * Math.cos(2 * Math.PI * map.center.lat / 360); 4) you will need to accomodate the spherical mercator stuff too ... loads of people use that Cheers Paul On 5-Oct-07, at 10:22 AM, Ian Mayo wrote: > Hi all, I have a working demonstrator at: > http://dev.openlayers.org/sandbox/ianmayo/openlayers/examples/ > controls.html > > At the top-right of the plot you'll see the current scale represented > as a bar. As far as I can see, the implementation seems sound - I > just have to polish off the unit tests (the earlier tests were more > associated with me learning how the scaling works). > > Aaah, and yes, please break it & report as appropriate. I'd also > appreciate hearing what configurable options people may want. > Currently we have m/km on the top and ft/mi on the bottom - switching > between the correct set to use depending on how far we've zoomed in. > Does anybody want to be able to configure to use other units? > > Ian. > > On 02/10/2007, Ian Mayo wrote: >> Here's the design for my OpenLayers scale control, aimed to offer >> similar functionality to the scale offered in google maps. >> Any advice? >> >> thanks in advance for any support, >> Ian. >> >> p.s. Should I have written this content into a wiki page? >> Opinions welcome. >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From giannibarrotta at gmail.com Fri Oct 5 17:24:18 2007 From: giannibarrotta at gmail.com (Gianni Barrotta) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Zoom Problems Switching Baselayers -- HELP! In-Reply-To: <6ae3fb590710040922v448af56ck334bb47cc00a2b30@mail.gmail.com> References: <6ae3fb590710040922v448af56ck334bb47cc00a2b30@mail.gmail.com> Message-ID: <190430c0710051424n480457a2jaf1ab28ff5563c0d@mail.gmail.com> I had a similar problem and solved it by passing the maxExtent to options of my layers and setting the tileOrigin before switching the layer. It's quite weird, I suppose the problem is that you don't call this method: /** When the layer is added to a map, then we can fetch our origin * (if we don't have one.) * * @param {OpenLayers.Map} map */ setMap: function(map) { OpenLayers.Layer.Grid.prototype.setMap.apply(this, arguments); if (!this.tileOrigin) { this.tileOrigin = new OpenLayers.LonLat(this.map.maxExtent.left, this.map.maxExtent.bottom); } }, when you switch the layer, and so the tile origin is not updated...but I don't know if this could be the right fix. On 10/4/07, Erik Uzureau wrote: > > Hi Arnd, > > Thanks for sending this test code... can you explain what we should > test for, though? > > ie how do we know if our patch has fixed the problem for you? > > Erik > > On 10/3/07, Arnd Wippermann wrote: > > And the file > > > > Mit freundlichen Gr?ssen > > > > Arnd Wippermann > > http://gis.ibbeck.de/ginfo/ > > > > > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071005/bc402dbe/attachment.html From ian at planetmayo.com Fri Oct 5 17:44:10 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Design for scale-line In-Reply-To: References: Message-ID: thanks for the support Paul. and I thought I was sooo close. Yet more details of OpenLayers projections to learn.... Thanks for the pointers anyway, regards, Ian. On 05/10/2007, Paul Spencer wrote: > Hi Ian, > > looks like nicely written code :) I'm sure this will be very useful > to have as a Control in OpenLayers. I have a few comments: > > 1) you have a problem with tabs vs spaces in code formatting that > made my eyes wonky in a couple of places. > > 2) you do not seem to be accommodating the current units of the map - > I use different projections, often in meters. From the docs: > > units > > {String} The map units. Defaults to 'degrees'. Possible values are > 'degrees' (or 'dd'), 'm', 'ft', 'km', 'mi', 'inches'. > > So you need to check to see what map.units is before converting > > 3) If the units are decimal degrees, you should adjust the > calculation based on the current latitude of the center using the > cosine of the latitude. This was from a distance measuring tool I > did a while back: > > d = d * Math.cos(2 * Math.PI * map.center.lat / 360); > > 4) you will need to accomodate the spherical mercator stuff too ... > loads of people use that > > Cheers > > Paul > > On 5-Oct-07, at 10:22 AM, Ian Mayo wrote: > > > Hi all, I have a working demonstrator at: > > http://dev.openlayers.org/sandbox/ianmayo/openlayers/examples/ > > controls.html > > > > At the top-right of the plot you'll see the current scale represented > > as a bar. As far as I can see, the implementation seems sound - I > > just have to polish off the unit tests (the earlier tests were more > > associated with me learning how the scaling works). > > > > Aaah, and yes, please break it & report as appropriate. I'd also > > appreciate hearing what configurable options people may want. > > Currently we have m/km on the top and ft/mi on the bottom - switching > > between the correct set to use depending on how far we've zoomed in. > > Does anybody want to be able to configure to use other units? > > > > Ian. > > > > On 02/10/2007, Ian Mayo wrote: > >> Here's the design for my OpenLayers scale control, aimed to offer > >> similar functionality to the scale offered in google maps. > >> Any advice? > >> > >> thanks in advance for any support, > >> Ian. > >> > >> p.s. Should I have written this content into a wiki page? > >> Opinions welcome. > >> > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > From crschmidt at metacarta.com Sun Oct 7 22:24:36 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Motion: 2.5 Final Release Message-ID: <20071008022436.GA7297@metacarta.com> There have been no new regressions reported in the OpenLayers 2.5 release in the time since the release of RC5. There is currently one outstanding issue that Tim had marked for 2.5 -- an improvement to GeometryCollection handling in GeoJSON parsing -- but it isn't a regression, and the use case where it actually affects people is very small. I'm of the opinion that since the GeoJSON spec is not yet 'done' -- there still could be more changes to it -- we shouldn't hold the release for another edge case lack of support: instead, if we really do want this into something we call 2.5, I'd be in favor of pulling it back and doing a 2.5.1 when the spec is complete. (See http://trac.openlayers.org/ticket/1067 -- this lack of funtionality only affects the case where a feature is passed with a GeometryCollection as the geometry.) With that being the only outstanding issue, I'd like to motion that we release OpenLayers 2.5 on Tuesday afternoon eastern time -- in about 40 hours -- unless we hear anything new in terms of bug reports in the meantime. This release would not include the fix for #1067. (If the PSC hasn't voted by that time, I propose that the release be made as soon as the PSC has voted.) I'm +1 on doing this, and will do the release engineering work if there are votes against releasing. Additionally, I'd like to put #1067 in trunk, and after the GeoJSON specification has been finalized, we pull any changes to the GeoJSON format back into a 2.5.1 after sufficient testing. The change that we're looking at is, imho, too risky to put into a 2.5 release this late in the game -- I screwed that up once already ;) (Hence the RC5 instead of RC4.) I'm interested in what the developer community thinks about doing this specifically to support full GeoJSON. The biggest reason for supporting the GeoJSON spec so strongly is that it is a format that we can round trip effectively, unlike many other formats. The simple feature model and limited geometry model allow us to fully support GeoJSON input/output in OpenLayers, and that's important for people to be able to have/understand. Looking forward to feedback on either of these two items, and would like to get the PSC to vote on the 2.5 release when they get a chance. Regards, -- Christopher Schmidt MetaCarta From gertjan at West.NL Mon Oct 8 04:59:41 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: References: <20071005152627.GB19044@metacarta.com> Message-ID: <20071008085941.GA4970@West.NL> As quoted from Ian Mayo : > On 05/10/2007, Christopher Schmidt wrote: > > On Fri, Oct 05, 2007 at 03:32:06PM +0100, Ian Mayo wrote: > > > // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) > > > > here you use '1852 * m', but it seems like this should be 1852 * yd. > > duh. Ehrm, you should fix the comment, not the calculation: a nautical mile is 1852 *meters*, not yards... -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From ian at planetmayo.com Mon Oct 8 05:16:56 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: <20071008085941.GA4970@West.NL> References: <20071005152627.GB19044@metacarta.com> <20071008085941.GA4970@West.NL> Message-ID: thanks for the support Gertjan, the mistake just occurred in my email proposal, the code contained the correct implementation. The patch I submitted contained the correct units: http://trac.openlayers.org/attachment/ticket/1065/patchfile.patch thanks again, Ian Mayo On 08/10/2007, Gertjan van Oosten wrote: > As quoted from Ian Mayo : > > On 05/10/2007, Christopher Schmidt wrote: > > > On Fri, Oct 05, 2007 at 03:32:06PM +0100, Ian Mayo wrote: > > > > // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) > > > > > > here you use '1852 * m', but it seems like this should be 1852 * yd. > > > > duh. > > Ehrm, you should fix the comment, not the calculation: a nautical mile > is 1852 *meters*, not yards... > > -- > -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 > From john.cole at uai.com Mon Oct 8 10:34:12 2007 From: john.cole at uai.com (John Cole) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Motion: 2.5 Final Release Message-ID: <76758090F8686C47A44B6FF52514A1D307909EEF@hermes.uai.int> +1 All the stuff I want is in 2.6 :-) The sooner 2.5 is cooked, the sooner 2.6 gets going! John -----Original Message----- From: dev-bounces@openlayers.org [mailto:dev-bounces@openlayers.org] On Behalf Of Christopher Schmidt Sent: Sunday, October 07, 2007 9:25 PM To: dev@openlayers.org Subject: [OpenLayers-Dev] Motion: 2.5 Final Release There have been no new regressions reported in the OpenLayers 2.5 release in the time since the release of RC5. There is currently one outstanding issue that Tim had marked for 2.5 -- an improvement to GeometryCollection handling in GeoJSON parsing -- but it isn't a regression, and the use case where it actually affects people is very small. I'm of the opinion that since the GeoJSON spec is not yet 'done' -- there still could be more changes to it -- we shouldn't hold the release for another edge case lack of support: instead, if we really do want this into something we call 2.5, I'd be in favor of pulling it back and doing a 2.5.1 when the spec is complete. (See http://trac.openlayers.org/ticket/1067 -- this lack of funtionality only affects the case where a feature is passed with a GeometryCollection as the geometry.) With that being the only outstanding issue, I'd like to motion that we release OpenLayers 2.5 on Tuesday afternoon eastern time -- in about 40 hours -- unless we hear anything new in terms of bug reports in the meantime. This release would not include the fix for #1067. (If the PSC hasn't voted by that time, I propose that the release be made as soon as the PSC has voted.) I'm +1 on doing this, and will do the release engineering work if there are votes against releasing. Additionally, I'd like to put #1067 in trunk, and after the GeoJSON specification has been finalized, we pull any changes to the GeoJSON format back into a 2.5.1 after sufficient testing. The change that we're looking at is, imho, too risky to put into a 2.5 release this late in the game -- I screwed that up once already ;) (Hence the RC5 instead of RC4.) I'm interested in what the developer community thinks about doing this specifically to support full GeoJSON. The biggest reason for supporting the GeoJSON spec so strongly is that it is a format that we can round trip effectively, unlike many other formats. The simple feature model and limited geometry model allow us to fully support GeoJSON input/output in OpenLayers, and that's important for people to be able to have/understand. Looking forward to feedback on either of these two items, and would like to get the PSC to vote on the 2.5 release when they get a chance. Regards, -- Christopher Schmidt MetaCarta _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.4/1055 - Release Date: 10/7/2007 10:24 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.4/1057 - Release Date: 10/8/2007 9:04 AM This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From pspencer at dmsolutions.ca Mon Oct 8 12:21:38 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Motion: 2.5 Final Release In-Reply-To: <20071008022436.GA7297@metacarta.com> References: <20071008022436.GA7297@metacarta.com> Message-ID: <4BC893AA-DC9D-4455-8963-CBDC9D491BAD@dmsolutions.ca> +1 Paul On 7-Oct-07, at 10:24 PM, Christopher Schmidt wrote: > There have been no new regressions reported in the OpenLayers 2.5 > release in the time since the release of RC5. > > There is currently one outstanding issue that Tim had marked for > 2.5 -- > an improvement to GeometryCollection handling in GeoJSON parsing -- > but > it isn't a regression, and the use case where it actually affects > people > is very small. I'm of the opinion that since the GeoJSON spec is > not yet > 'done' -- there still could be more changes to it -- we shouldn't hold > the release for another edge case lack of support: instead, if we > really > do want this into something we call 2.5, I'd be in favor of pulling it > back and doing a 2.5.1 when the spec is complete. (See > http://trac.openlayers.org/ticket/1067 -- this lack of funtionality > only > affects the case where a feature is passed with a > GeometryCollection as > the geometry.) > > With that being the only outstanding issue, I'd like to motion that we > release OpenLayers 2.5 on Tuesday afternoon eastern time -- in > about 40 > hours -- unless we hear anything new in terms of bug reports in the > meantime. This release would not include the fix for #1067. (If the > PSC > hasn't voted by that time, I propose that the release be made as > soon as > the PSC has voted.) > > I'm +1 on doing this, and will do the release engineering work if > there > are votes against releasing. > > Additionally, I'd like to put #1067 in trunk, and after the GeoJSON > specification has been finalized, we pull any changes to the GeoJSON > format back into a 2.5.1 after sufficient testing. The change that > we're > looking at is, imho, too risky to put into a 2.5 release this late in > the game -- I screwed that up once already ;) (Hence the RC5 > instead of > RC4.) I'm interested in what the developer community thinks about > doing > this specifically to support full GeoJSON. > > The biggest reason for supporting the GeoJSON spec so strongly is that > it is a format that we can round trip effectively, unlike many other > formats. The simple feature model and limited geometry model allow > us to > fully support GeoJSON input/output in OpenLayers, and that's important > for people to be able to have/understand. > > Looking forward to feedback on either of these two items, and would > like > to get the PSC to vote on the 2.5 release when they get a chance. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From erik.uzureau at metacarta.com Mon Oct 8 12:28:51 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Motion: 2.5 Final Release In-Reply-To: <4BC893AA-DC9D-4455-8963-CBDC9D491BAD@dmsolutions.ca> References: <20071008022436.GA7297@metacarta.com> <4BC893AA-DC9D-4455-8963-CBDC9D491BAD@dmsolutions.ca> Message-ID: <6ae3fb590710080928n7def1e20kfecd0c05f75e061e@mail.gmail.com> +1 euzur? On 10/8/07, Paul Spencer wrote: > +1 Paul > > On 7-Oct-07, at 10:24 PM, Christopher Schmidt wrote: > > > There have been no new regressions reported in the OpenLayers 2.5 > > release in the time since the release of RC5. > > > > There is currently one outstanding issue that Tim had marked for > > 2.5 -- > > an improvement to GeometryCollection handling in GeoJSON parsing -- > > but > > it isn't a regression, and the use case where it actually affects > > people > > is very small. I'm of the opinion that since the GeoJSON spec is > > not yet > > 'done' -- there still could be more changes to it -- we shouldn't hold > > the release for another edge case lack of support: instead, if we > > really > > do want this into something we call 2.5, I'd be in favor of pulling it > > back and doing a 2.5.1 when the spec is complete. (See > > http://trac.openlayers.org/ticket/1067 -- this lack of funtionality > > only > > affects the case where a feature is passed with a > > GeometryCollection as > > the geometry.) > > > > With that being the only outstanding issue, I'd like to motion that we > > release OpenLayers 2.5 on Tuesday afternoon eastern time -- in > > about 40 > > hours -- unless we hear anything new in terms of bug reports in the > > meantime. This release would not include the fix for #1067. (If the > > PSC > > hasn't voted by that time, I propose that the release be made as > > soon as > > the PSC has voted.) > > > > I'm +1 on doing this, and will do the release engineering work if > > there > > are votes against releasing. > > > > Additionally, I'd like to put #1067 in trunk, and after the GeoJSON > > specification has been finalized, we pull any changes to the GeoJSON > > format back into a 2.5.1 after sufficient testing. The change that > > we're > > looking at is, imho, too risky to put into a 2.5 release this late in > > the game -- I screwed that up once already ;) (Hence the RC5 > > instead of > > RC4.) I'm interested in what the developer community thinks about > > doing > > this specifically to support full GeoJSON. > > > > The biggest reason for supporting the GeoJSON spec so strongly is that > > it is a format that we can round trip effectively, unlike many other > > formats. The simple feature model and limited geometry model allow > > us to > > fully support GeoJSON input/output in OpenLayers, and that's important > > for people to be able to have/understand. > > > > Looking forward to feedback on either of these two items, and would > > like > > to get the PSC to vote on the 2.5 release when they get a chance. > > > > Regards, > > -- > > Christopher Schmidt > > MetaCarta > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Mon Oct 8 13:48:52 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Look who's using OpenLayers.... Message-ID: <6ae3fb590710081048w2cb0b966h449bd2126f690d56@mail.gmail.com> http://creativecommons.org/ From crschmidt at metacarta.com Mon Oct 8 12:09:38 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Adding nautical miles and yards to units In-Reply-To: <20071008085941.GA4970@West.NL> References: <20071005152627.GB19044@metacarta.com> <20071008085941.GA4970@West.NL> Message-ID: <20071008160938.GA4895@metacarta.com> On Mon, Oct 08, 2007 at 10:59:41AM +0200, Gertjan van Oosten wrote: > As quoted from Ian Mayo : > > On 05/10/2007, Christopher Schmidt wrote: > > > On Fri, Oct 05, 2007 at 03:32:06PM +0100, Ian Mayo wrote: > > > > // a nautical mile is 1852 yards (http://en.wikipedia.org/wiki/Nautical_mile) > > > > > > here you use '1852 * m', but it seems like this should be 1852 * yd. > > > > duh. > > Ehrm, you should fix the comment, not the calculation: a nautical mile > is 1852 *meters*, not yards... Yeah, I think he did, in the patch. Regards, -- Christopher Schmidt MetaCarta From Eric.Peterson at motorola.com Mon Oct 8 15:19:55 2007 From: Eric.Peterson at motorola.com (Peterson Eric-EEP002) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Problem with Auto-Detection of Script Path (and not a 2.5 release-blocker!) Message-ID: I am building a J2EE application using OpenLayers, and I'm including the OL tree in the .WAR file I build for release. My app deploys just fine. When I get to the JSP that displays my map, I get weird errors - it seems like lib/OpenLayers.js is getting loaded correctly, but it doesn't load any of the other .js files. My app deploys to a URL that looks like this: http://www.myhost.com/myapp/ And in the map-display JPS, I include this file via has now been changed to use the 2.5 API. As always, the source is available at http://openlayers.org/download/. Bug reports can be filed in Trac, under the 2.5 version and milestone. We look forward to your feedback! [1] http://trac.openlayers.org/query?status=closed&resolution=fixed&group=component&milestone=2.5+Release&order=status Regards, The OpenLayers Team From john.frank at metacarta.com Tue Oct 9 15:50:53 2007 From: john.frank at metacarta.com (John R. Frank) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <20071009181024.GA19175@metacarta.com> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> Message-ID: > That said, I would consider a "+0" to be part of a 'unanimous vote' -- ... > However, now that I think about it, I think all PSC members really > should be voting "+1" to change a license. If you can't get that level > of approval, then you shouldn't be changing the license. For something as core as license changes, I think it is important to get 100% voter turn out. Regarding the secondary question of whether a +0 should block a license change, it's worth pointing out that in the couple license related votes that we have had on the PSC list most (maybe all) had an initial +0 from someone. And in each case, this prompted a discussion that allowed more questions to be answered and more confidence accrued such that everyone reached +1. I think that's a healthy process to instill in the formal PSC rules. John From tschaub at openplans.org Tue Oct 9 19:26:06 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <091C2C7D-AEF0-489A-92E9-21F778C94E6D@dmsolutions.ca> References: <20071009165303.GB32728@metacarta.com> <091C2C7D-AEF0-489A-92E9-21F778C94E6D@dmsolutions.ca> Message-ID: <470C0E0E.2010304@openplans.org> For the record: +1 Tim Paul Spencer wrote: > +1 Paul > > On 9-Oct-07, at 12:53 PM, Christopher Schmidt wrote: > >> During the FOSS4G conference, the available members of the PSC sat >> down >> with our incubation mentor (Howard Butler) and Frank Warmadam, >> president >> of OSGeo, to discuss completing OSGeo incubation of OpenLayers. >> >> It was decided that the easiest path forward for all involved would be >> to change the license on all OpenLayers materials -- including all >> future releases -- to be licensed under the license that MetaCarta has >> been calling the 'Clear BSD'. The Clear BSD is essentially the BSD >> license, with an extra clause that states that no patent rights are >> granted with the license. >> >> In the past, we had posted to the dev/users lists about changing the >> repository license from the MetaCarta-specific one to the Clear BSD. >> (This had been discussed internally on the PSC list, then made >> public.) >> Now, we are having the same discussion, but instead of changing >> just the >> repository license, we are proposing to change the release license as >> well. >> >> Changing this license will allow us to remove all MetaCarta-specific >> aspects of the release process. It has no (known) change in the actual >> licensing restrictions. Changing the release process allows us to >> proceed with OSGeo incubation. >> >> As a reminder, for those who haven't been paying attention, an >> explanation of MetaCarta's need for the "Clear BSD" license is >> available >> from http://labs.metacarta.com/license-explanation.html , and has (in >> bold) the changes in the license text. (They're pretty minor.) >> >> This RFC is a request for any comments on the intention to change, for >> all future releases of OpenLayers, the release license to be the Clear >> BSD license, and (since the repository license will then be the same) >> to thereafter refer to it only as the "Clear BSD" license in the code, >> docs, etc. >> >> I am in favor (+1) of making this change as soon as the 2.5 release is >> out, making 2.5 the last release shipped under the official BSD >> license, >> and at that time making the previously proposed changes to the SVN >> layout in order to take into account the licensing change. >> >> (PSC Members: I know we voted on this on the PSC list, but I'd like to >> have a public vote as part of our goal of moving PSC list >> discussions to >> the public view, so even if you feel like you voted, please vote again >> :)) >> >> Regards, >> -- >> Christopher Schmidt >> MetaCarta >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,470bb3b2159413668746562! > From tschaub at openplans.org Tue Oct 9 19:28:48 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <6ae3fb590710091041n3c1135bfj97ddcfd50d1d632@mail.gmail.com> References: <20071009170208.GC32728@metacarta.com> <20071009172112.GD2616@vishnu.tridity.org> <6ae3fb590710091041n3c1135bfj97ddcfd50d1d632@mail.gmail.com> Message-ID: <470C0EB0.2060204@openplans.org> +1 on the unanimous bit regarding licensing. Tim Erik Uzureau wrote: > +1 euzu > > On 10/9/07, John R. Frank wrote: >>>> I'm +1 on altering the wording of the Steering Committee voting rules >>>> to state that any licensing changes require a unanimous vote from >>>> Steering Committee members. >>> +1. Thanks for registering your concerns, Chris! >> +1 jrf >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,470bbd62177878362916074! > From pspencer at dmsolutions.ca Tue Oct 9 21:19:47 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <20071009181024.GA19175@metacarta.com> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> Message-ID: <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> On 9-Oct-07, at 2:10 PM, Christopher Schmidt wrote: > On Tue, Oct 09, 2007 at 01:50:56PM -0400, Paul Spencer wrote: >> I'm ambivalent on this. I am not convinced that we need unanimity >> (?) on any given issue, but I do think we need everyone to vote so >> that we are certain there are no dissenting votes. I also think >> there may be a certain amount of pressure felt by someone that they >> have to vote with the rest of the PSC even though they are not >> necessarily fully supportive (or even just ambivalent). >> >> Discuss ... :) > > I think that license changes are important enough that if you can't > get > unanimous approval of the PSC, then "You're doing it wrong"[1]. > > That said, I would consider a "+0" to be part of a 'unanimous vote' -- > indicating no veto -- and since a single -1 vetoes a vote nayway, the > practical change to this would only be that all members would have to > vote. However, now that I think about it, I think all PSC members > really > should be voting "+1" to change a license. If you can't get that > level of > approval, then you shouldn't be changing the license.c > > > [1] http://img.photobucket.com/albums/v476/macjinx/campingmacro.jpg nice :) I agree on anything with a + being part of a unanimous vote. I think we are (or at least just I am) abusing the current rules by voting +1 on everything even if we (I) don't intend to help out. The PSC needs to maintain a list of things that we have agreed (unanimously) require a unanimous vote. Also, I think we should maintain a record of the results of votes. The way MapGuide runs their PSC. An RFC is prepared in the wiki, a link is forwarded to dev for discussion, then after a suitable waiting period a motion to vote is presented by a PSC member. After the vote, the proponent of the RFC updates the list with the voting record. For issues like this one, this seems like a bit of overkill but at least the main text of the RFC and the voting history could be plunked into the wiki after a vote? And +1 on making unanimity (all + votes) for this particular issue. Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From jb-openlayers at jasonbirch.com Tue Oct 9 23:05:29 2007 From: jb-openlayers at jasonbirch.com (Jason Birch) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <20071009165303.GB32728@metacarta.com> References: <20071009165303.GB32728@metacarta.com> Message-ID: <470C4179.8030106@jasonbirch.com> Christopher Schmidt wrote: > The Clear BSD is essentially the BSD > license, with an extra clause that states that no patent rights are > granted with the license. [snip] > Changing the release process allows us to > proceed with OSGeo incubation. Is Clear BSD an OSI-approved license, or has it been submitted to the OSI for approval? I'm asking because I haven't found any information on this, and because there's a nasty clause in the OSGeo bylaws which affects this: ----------------- To further the goals of the corporation and to ensure that the assets of the corporation are utilized for public benefit, all software whose development is managed by the corporation shall be released under a software license that is designated by the Open Source Initiative (OSI) as one that satisfies the OSI?s requirements for Certified Open Source Software. ----------------- http://www.osgeo.org/content/foundation/incorporation/bylaws.html Jason From crschmidt at metacarta.com Tue Oct 9 23:15:50 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <470C4179.8030106@jasonbirch.com> References: <20071009165303.GB32728@metacarta.com> <470C4179.8030106@jasonbirch.com> Message-ID: <20071010031550.GA23705@metacarta.com> On Tue, Oct 09, 2007 at 08:05:29PM -0700, Jason Birch wrote: > Christopher Schmidt wrote: > >The Clear BSD is essentially the BSD > >license, with an extra clause that states that no patent rights are > >granted with the license. > [snip] > >Changing the release process allows us to > >proceed with OSGeo incubation. > > Is Clear BSD an OSI-approved license, or has it been submitted to the > OSI for approval? > > I'm asking because I haven't found any information on this, and because > there's a nasty clause in the OSGeo bylaws which affects this: Clear BSD has not yet been submitted to the OSI license-discuss list for approval. I'll let Howard comment more thoroughly on this if he wants, but the gist of the conversation at the code sprint was that the Clear BSD license is like most BSD licenses -- so close to the existing BSD license as to be essentially the same. BSD licensed software included with a BSD distribution itself reportedly has 33 different variations on the "BSD" license. Frank stated that this is true of the GDAL project as well -- there are a number of pieces of software released under similar but occasionally differently worded licenses, which he collectively refers to as the 'MIT/X' style licenses. In the end, it may come down to a vote among either incubation or the OSGeo board as to whether they consider the "Clear BSD" to be close enough to OSI approved or not. If not, the next step will be to pursue approval. (This is something MetaCarta plans to do regardless, but the resources to do this have not been allocated yet, and the hope was to move this forward without blocking on that. As a result, it's possible that by the time a vote of that type happens, the license will already be OSI approved.) If the license *fails* to be approved by OSI, then we'll have a different problem, but we can cross that bridge when we come to it. Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Wed Oct 10 01:34:09 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <470C0EB0.2060204@openplans.org> References: <20071009170208.GC32728@metacarta.com> <20071009172112.GD2616@vishnu.tridity.org> <6ae3fb590710091041n3c1135bfj97ddcfd50d1d632@mail.gmail.com> <470C0EB0.2060204@openplans.org> Message-ID: <470C6451.2000908@gmail.com> +1 Tim Schaub wrote: > +1 on the unanimous bit regarding licensing. > > Tim > > > Erik Uzureau wrote: > >> +1 euzu >> >> On 10/9/07, John R. Frank wrote: >> >>>>> I'm +1 on altering the wording of the Steering Committee voting rules >>>>> to state that any licensing changes require a unanimous vote from >>>>> Steering Committee members. >>>>> >>>> +1. Thanks for registering your concerns, Chris! >>>> >>> +1 jrf >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> >>> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> >> !DSPAM:4033,470bbd62177878362916074! >> >> > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From erik.uzureau at metacarta.com Wed Oct 10 01:46:55 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> Message-ID: <6ae3fb590710092246s2c244f5t916226c0838b703a@mail.gmail.com> On 10/9/07, Paul Spencer wrote: > > On 9-Oct-07, at 2:10 PM, Christopher Schmidt wrote: > > > On Tue, Oct 09, 2007 at 01:50:56PM -0400, Paul Spencer wrote: > >> I'm ambivalent on this. I am not convinced that we need unanimity > >> (?) on any given issue, but I do think we need everyone to vote so > >> that we are certain there are no dissenting votes. I also think > >> there may be a certain amount of pressure felt by someone that they > >> have to vote with the rest of the PSC even though they are not > >> necessarily fully supportive (or even just ambivalent). > >> > >> Discuss ... :) > > > > I think that license changes are important enough that if you can't > > get > > unanimous approval of the PSC, then "You're doing it wrong"[1]. > > > > That said, I would consider a "+0" to be part of a 'unanimous vote' -- > > indicating no veto -- and since a single -1 vetoes a vote nayway, the > > practical change to this would only be that all members would have to > > vote. However, now that I think about it, I think all PSC members > > really > > should be voting "+1" to change a license. If you can't get that > > level of > > approval, then you shouldn't be changing the license.c > > > > > > [1] http://img.photobucket.com/albums/v476/macjinx/campingmacro.jpg > > nice :) > > I agree on anything with a + being part of a unanimous vote. I think > we are (or at least just I am) abusing the current rules by voting +1 > on everything even if we (I) don't intend to help out. > > The PSC needs to maintain a list of things that we have agreed > (unanimously) require a unanimous vote. http://trac.openlayers.org/wiki/SteeringCommittee?action=diff&version=8 > Also, I think we should maintain a record of the results of votes. > The way MapGuide runs their PSC. An RFC is prepared in the wiki, a > link is forwarded to dev for discussion, then after a suitable > waiting period a motion to vote is presented by a PSC member. After > the vote, the proponent of the RFC updates the list with the voting > record. For issues like this one, this seems like a bit of overkill > but at least the main text of the RFC and the voting history could be > plunked into the wiki after a vote? How do people feel about this? In the past, there have been very few issues which have required a vote -- the majority of the voting has just been for releases so far. If others are interested in this public log of voting, though, I would be happy to set up some wikistructure to handle it. :-) Erik > > And +1 on making unanimity (all + votes) for this particular issue. > > Cheers > > Paul > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From cameron.shorter at gmail.com Wed Oct 10 01:53:15 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <20071010031550.GA23705@metacarta.com> References: <20071009165303.GB32728@metacarta.com> <470C4179.8030106@jasonbirch.com> <20071010031550.GA23705@metacarta.com> Message-ID: <470C68CB.9040609@gmail.com> +0 (changed to +1 if +0 is considered blocking) As noted on PSC email lists, I don't like the proliferation of Open Source licenses. I understand Metacarta's concerns regarding the ambiguity of the BSD license and think they are valid. I'm encouraged by Metacarta's intent to propose the "Clear BSD" be incorporated into the next version of the BSD. However I'm concerned by the delay engaging the BSD community, and it seems no resources are allocated to the task. Will Metacarta still resource license concerns after Openlayers has completed OSGeo graduation? That said, (this time on a public list) I'm in favor of migrating to the Open BSD as waiting for an updated BSD license is likely to take years. Christopher Schmidt wrote: > On Tue, Oct 09, 2007 at 08:05:29PM -0700, Jason Birch wrote: > >> Christopher Schmidt wrote: >> >>> The Clear BSD is essentially the BSD >>> license, with an extra clause that states that no patent rights are >>> granted with the license. >>> >> [snip] >> >>> Changing the release process allows us to >>> proceed with OSGeo incubation. >>> >> Is Clear BSD an OSI-approved license, or has it been submitted to the >> OSI for approval? >> >> I'm asking because I haven't found any information on this, and because >> there's a nasty clause in the OSGeo bylaws which affects this: >> > > Clear BSD has not yet been submitted to the OSI license-discuss list for > approval. I'll let Howard comment more thoroughly on this if he wants, > but the gist of the conversation at the code sprint was that the Clear > BSD license is like most BSD licenses -- so close to the existing BSD > license as to be essentially the same. > > BSD licensed software included with a BSD distribution itself reportedly > has 33 different variations on the "BSD" license. Frank stated that this > is true of the GDAL project as well -- there are a number of pieces of > software released under similar but occasionally differently worded > licenses, which he collectively refers to as the 'MIT/X' style licenses. > > In the end, it may come down to a vote among either incubation or the > OSGeo board as to whether they consider the "Clear BSD" to be close > enough to OSI approved or not. If not, the next step will be to pursue > approval. (This is something MetaCarta plans to do regardless, but the > resources to do this have not been allocated yet, and the hope was to > move this forward without blocking on that. As a result, it's possible > that by the time a vote of that type happens, the license will already > be OSI approved.) If the license *fails* to be approved by OSI, then > we'll have a different problem, but we can cross that bridge when we > come to it. > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From crschmidt at metacarta.com Wed Oct 10 02:11:47 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <6ae3fb590710092246s2c244f5t916226c0838b703a@mail.gmail.com> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> <6ae3fb590710092246s2c244f5t916226c0838b703a@mail.gmail.com> Message-ID: <20071010061147.GA2197@metacarta.com> On Wed, Oct 10, 2007 at 12:46:55AM -0500, Erik Uzureau wrote: > On 10/9/07, Paul Spencer wrote: > > Also, I think we should maintain a record of the results of votes. > > The way MapGuide runs their PSC. An RFC is prepared in the wiki, a > > link is forwarded to dev for discussion, then after a suitable > > waiting period a motion to vote is presented by a PSC member. After > > the vote, the proponent of the RFC updates the list with the voting > > record. For issues like this one, this seems like a bit of overkill > > but at least the main text of the RFC and the voting history could be > > plunked into the wiki after a vote? > > How do people feel about this? In the past, there have been very few > issues which have required a vote -- the majority of the voting has > just been for releases so far. I think it's important to have a public record of who voted what way on a particular question. I don't feel a strong need to have an RFC first -- the mailing lists are a fine publicly accessible historical resource -- but a short summary and a list of the vote results in the wiki seems a great idea. Our rules for 'no controversial changes without consulting the PSC' not requiring many votes simply means that we haven't had many controversial changes, as far as I'm concerned. It becomes more of a question for things like 'Translation' -- large, sweeping changes that you want everyone to agree with ahead of time. In general, I try to break these things up into seperate tasks -- so even though I wrote http://trac.openlayers.org/wiki/RFC/ParsingAndDisplayingRemoteData as an "RFC", I realized that there were parts of it that were simply obvious code-deduplication, and doing that is unlikely to make anyone upset (so long as the end result is the same on both ends), so I just went ahead and wrote the patches. So, not having lots of votes is cool, but having public records for the votes we do have is also cool. Regards, -- Christopher Schmidt MetaCarta From ethan919 at gmail.com Wed Oct 10 04:45:00 2007 From: ethan919 at gmail.com (li ethan) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] how to set up map datasource? Message-ID: <4b886b0c0710100145u77fc8baawde7f0b9cae5b1b7f@mail.gmail.com> Dear all listers:) I'm new to openlayers,the question may be naive,I want to know how to set up my own map datasource,like I got a batch of png images,how to set OpenLayers.Layer to display them? And I saw most examples use WMS to get map data,how to set that service based on my own png image data? Thanks:) From val.cartei at gmail.com Wed Oct 10 05:21:15 2007 From: val.cartei at gmail.com (Val Cartei) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] how is the overview map created? Message-ID: Hi all, I am trying to figure out how OpenLayers calculates the overview map. What I would like is that no matter what map I use, the overview map should always resize itself to display the whole map. Any suggestions? -- Best Regards, Valentina Cartei UK Tel. +44 (0)796 6882820 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071010/c64318d9/attachment.html From cameron.shorter at gmail.com Wed Oct 10 04:34:28 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <20071010061147.GA2197@metacarta.com> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> <6ae3fb590710092246s2c244f5t916226c0838b703a@mail.gmail.com> <20071010061147.GA2197@metacarta.com> Message-ID: <470C8E94.3050204@gmail.com> My initial reaction to a wiki record of all votes was "what a great idea", but upon thinking further, I've cooled to the idea. My experience is that most things that go to a vote are usually fairly obvious and get a unanimous show support. It gives the proposer an acknowledgment they are on the right track. If there is debate on the issue, the proposal usually modified 2 or 3 times and re-voted on. Should we record all the votes for the proposal? And cut and paste how someone initially said no, then said yes after certain conditions were met? So the cost of recording a vote is probably ~ 15 mins. Is it worth it? What do we gain? I'm yet to have a need to return to a historic decision with a desire to know who voted for what. Maybe it would be useful for someone studying the effectiveness of Open Source. I can't think of any legal value that we gain above recording votes in an email list. And for collecting reasons for people voting "-1", this information can be collected in the comments section of a wiki RFC already. Christopher Schmidt wrote: > On Wed, Oct 10, 2007 at 12:46:55AM -0500, Erik Uzureau wrote: > >> On 10/9/07, Paul Spencer wrote: >> >>> Also, I think we should maintain a record of the results of votes. >>> The way MapGuide runs their PSC. An RFC is prepared in the wiki, a >>> link is forwarded to dev for discussion, then after a suitable >>> waiting period a motion to vote is presented by a PSC member. After >>> the vote, the proponent of the RFC updates the list with the voting >>> record. For issues like this one, this seems like a bit of overkill >>> but at least the main text of the RFC and the voting history could be >>> plunked into the wiki after a vote? >>> >> How do people feel about this? In the past, there have been very few >> issues which have required a vote -- the majority of the voting has >> just been for releases so far. >> > > I think it's important to have a public record of who voted what way on > a particular question. I don't feel a strong need to have an RFC first > -- the mailing lists are a fine publicly accessible historical resource > -- but a short summary and a list of the vote results in the wiki seems > a great idea. > > Our rules for 'no controversial changes without consulting the PSC' not > requiring many votes simply means that we haven't had many controversial > changes, as far as I'm concerned. It becomes more of a question for > things like 'Translation' -- large, sweeping changes that you want > everyone to agree with ahead of time. In general, I try to break these > things up into seperate tasks -- so even though I wrote > http://trac.openlayers.org/wiki/RFC/ParsingAndDisplayingRemoteData as an > "RFC", I realized that there were parts of it that were simply obvious > code-deduplication, and doing that is unlikely to make anyone upset (so > long as the end result is the same on both ends), so I just went ahead > and wrote the patches. > > So, not having lots of votes is cool, but having public records for the > votes we do have is also cool. > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From john.frank at metacarta.com Wed Oct 10 08:09:25 2007 From: john.frank at metacarta.com (John R. Frank) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <470C68CB.9040609@gmail.com> References: <20071009165303.GB32728@metacarta.com> <470C4179.8030106@jasonbirch.com> <20071010031550.GA23705@metacarta.com> <470C68CB.9040609@gmail.com> Message-ID: On Wed, 10 Oct 2007, Cameron Shorter wrote: > > I'm encouraged by Metacarta's intent to propose the "Clear BSD" be > incorporated into the next version of the BSD. However I'm concerned by > the delay engaging the BSD community, and it seems no resources are > allocated to the task. Will Metacarta still resource license concerns > after Openlayers has completed OSGeo graduation? Yes, at this point, MetaCarta Labs plans to support it indefinitely. We all share your concern about license proliferation. That's why we took so long in creating the CBSD; we were surprised not to find an existing alternative, despite the existing legal analysis indicating its need [1]. As you know, there are several communities interested in open source licenses. The OSI discuss list is one part of it. The Regents of UC might be counted as another. On the urgency-versus-importance plane, seeking OSI approval for the CBSD has been high importance and low urgency compared with other things on our plate. That was amplified by turmoil on the OSI discuss list. It remains high importance; I hope to boost its urgency soon. Fortunately, OSGEO graduation need not block on this. > That said, (this time on a public list) I'm in favor of migrating to the > Open BSD as waiting for an updated BSD license is likely to take years. Did you mean to write Clear BSD? John [1] http://labs.metacarta.com/license-explanation.html From erik.uzureau at metacarta.com Wed Oct 10 11:12:02 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Archiving PSC Votes Message-ID: <6ae3fb590710100812m67580041gc4ecdb8cac1cb7f6@mail.gmail.com> In the thread "RFC: Resolution to only change License with Unanimous Vote" , Paul Spencer has brought up the idea of making a section on the WIKI to keep a public record of RFC's and also the Votes of the PSC on issues of importance. So far, we've seen people on both sides of the fence with this issue. Some people think it's important, whereas others think it is maybe a waste of time. Luckily, noone seems to be particularly opposed to the idea, the reservations expressed to this point seem to indicate only a wariness at the overhead. Instead of convoluting the other thread with that discussion, I'd like it to continue here in a new thread. I see this as a rather minor issue: as per hobu's suggestion at the pow-wow in Victoria, all PSC votes will now be held publicly on the dev list, so the idea of registering them does not imply a compromise on anyone's privacy. It seems to me to only be a question of who is really willing to do the work and whether we think that would be time well spent. Please, if you have opinions on this, voice them here, now. Erik From erik.uzureau at metacarta.com Wed Oct 10 11:16:37 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Resolution to only change License with Unanimous Vote In-Reply-To: <470C8E94.3050204@gmail.com> References: <20071009170208.GC32728@metacarta.com> <2A54AFF8-3AFB-4681-8277-692D22DC1936@dmsolutions.ca> <20071009181024.GA19175@metacarta.com> <72BFDFF3-75DB-4B9F-B023-45851C8E5975@dmsolutions.ca> <6ae3fb590710092246s2c244f5t916226c0838b703a@mail.gmail.com> <20071010061147.GA2197@metacarta.com> <470C8E94.3050204@gmail.com> Message-ID: <6ae3fb590710100816i6bf5e48fta8acf652e92e2ba8@mail.gmail.com> In the interest of keeping proper discussions in their proper threads, I have started a new thread for the discussion of the idea of making public records of PSC votes. Since we did receive unanimous support for requiring unanimous support for license changes, I have gone ahead and modified the wiki to reflect this change in policy: http://trac.openlayers.org/wiki/SteeringCommittee?action=diff&version=8 If there are any more thoughts on this issue, or on the way in which I changed that wiki, please voice them here. Otherwise, please let's discuss the idea of recording PSC Votes in that other thread, "RFC: Archiving PSC Votes". Hopefully this will clear things up for people. Saludos, Euz On 10/10/07, Cameron Shorter wrote: > My initial reaction to a wiki record of all votes was "what a great > idea", but upon thinking further, I've cooled to the idea. > > My experience is that most things that go to a vote are usually fairly > obvious and get a unanimous show support. It gives the proposer an > acknowledgment they are on the right track. > > If there is debate on the issue, the proposal usually modified 2 or 3 > times and re-voted on. Should we record all the votes for the proposal? > And cut and paste how someone initially said no, then said yes after > certain conditions were met? > > So the cost of recording a vote is probably ~ 15 mins. Is it worth it? > > What do we gain? I'm yet to have a need to return to a historic decision > with a desire to know who voted for what. Maybe it would be useful for > someone studying the effectiveness of Open Source. I can't think of any > legal value that we gain above recording votes in an email list. > And for collecting reasons for people voting "-1", this information can > be collected in the comments section of a wiki RFC already. > > Christopher Schmidt wrote: > > On Wed, Oct 10, 2007 at 12:46:55AM -0500, Erik Uzureau wrote: > > > >> On 10/9/07, Paul Spencer wrote: > >> > >>> Also, I think we should maintain a record of the results of votes. > >>> The way MapGuide runs their PSC. An RFC is prepared in the wiki, a > >>> link is forwarded to dev for discussion, then after a suitable > >>> waiting period a motion to vote is presented by a PSC member. After > >>> the vote, the proponent of the RFC updates the list with the voting > >>> record. For issues like this one, this seems like a bit of overkill > >>> but at least the main text of the RFC and the voting history could be > >>> plunked into the wiki after a vote? > >>> > >> How do people feel about this? In the past, there have been very few > >> issues which have required a vote -- the majority of the voting has > >> just been for releases so far. > >> > > > > I think it's important to have a public record of who voted what way on > > a particular question. I don't feel a strong need to have an RFC first > > -- the mailing lists are a fine publicly accessible historical resource > > -- but a short summary and a list of the vote results in the wiki seems > > a great idea. > > > > Our rules for 'no controversial changes without consulting the PSC' not > > requiring many votes simply means that we haven't had many controversial > > changes, as far as I'm concerned. It becomes more of a question for > > things like 'Translation' -- large, sweeping changes that you want > > everyone to agree with ahead of time. In general, I try to break these > > things up into seperate tasks -- so even though I wrote > > http://trac.openlayers.org/wiki/RFC/ParsingAndDisplayingRemoteData as an > > "RFC", I realized that there were parts of it that were simply obvious > > code-deduplication, and doing that is unlikely to make anyone upset (so > > long as the end result is the same on both ends), so I just went ahead > > and wrote the patches. > > > > So, not having lots of votes is cool, but having public records for the > > votes we do have is also cool. > > > > Regards, > > > > > -- > Cameron Shorter > Systems Architect, http://lisasoft.com.au > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > > From sderle at metacarta.com Wed Oct 10 12:17:09 2007 From: sderle at metacarta.com (Schuyler Erle) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Fwd: Re: RFC: Changing the License on OpenLayers Message-ID: <20071010161709.GW2616@vishnu.tridity.org> * On 9-Oct-2007 at 10:53PM PDT, Cameron Shorter said: > +0 > (changed to +1 if +0 is considered blocking) > > As noted on PSC email lists, I don't like the proliferation of Open > Source licenses. I understand Metacarta's concerns regarding the > ambiguity of the BSD license and think they are valid. > > I'm encouraged by Metacarta's intent to propose the "Clear BSD" be > incorporated into the next version of the BSD. However I'm concerned by > the delay engaging the BSD community, and it seems no resources are > allocated to the task. I think we agreed by consensus that a +0 would block a license change. Our informal understanding with Howard and Frank is that the Clear BSD, as Chris indicated, is sufficiently similar to existing BSD licenses that, given the existing precedent with GDAL, the OSGeo Incubation Committee and Board of Directors are likely to accept it as falling well within the spirit of other OSGeo-approved licenses. It's very important that we have a strong consensus within the PSC before moving forward. Cameron, can we get either a +1 from you, or a more detailed explanation of your concerns so that we can ensure that they get addressed? SDE ----- End forwarded message ----- From pspencer at dmsolutions.ca Wed Oct 10 12:59:06 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Fwd: Re: RFC: Changing the License on OpenLayers In-Reply-To: <20071010161709.GW2616@vishnu.tridity.org> References: <20071010161709.GW2616@vishnu.tridity.org> Message-ID: <6813AC83-9E66-47B2-B511-53FB9644D35F@dmsolutions.ca> On 10-Oct-07, at 12:17 PM, Schuyler Erle wrote: > * On 9-Oct-2007 at 10:53PM PDT, Cameron Shorter said: >> +0 >> (changed to +1 if +0 is considered blocking) >> >> As noted on PSC email lists, I don't like the proliferation of Open >> Source licenses. I understand Metacarta's concerns regarding the >> ambiguity of the BSD license and think they are valid. >> >> I'm encouraged by Metacarta's intent to propose the "Clear BSD" be >> incorporated into the next version of the BSD. However I'm >> concerned by >> the delay engaging the BSD community, and it seems no resources are >> allocated to the task. > > I think we agreed by consensus that a +0 would block a license change. > Our informal understanding with Howard and Frank is that the Clear > BSD, as Chris indicated, is sufficiently similar to existing BSD > licenses that, given the existing precedent with GDAL, the OSGeo > Incubation Committee and Board of Directors are likely to accept it as > falling well within the spirit of other OSGeo-approved licenses. > > It's very important that we have a strong consensus within the PSC > before moving forward. Cameron, can we get either a +1 from you, or a > more detailed explanation of your concerns so that we can ensure that > they get addressed? > > SDE On this ... without wanting to be pedantic about it, can we change the wording of the + and - voting system to something like: +1 strongly agree +0 agree 0 neither agree nor disagree -0 disagree -1 strongly disagree and remove the wording about being willing to be involved in implementation or changing in the +1/-1 case as they really don't apply to the things we actually vote about. Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From john.frank at metacarta.com Wed Oct 10 13:38:44 2007 From: john.frank at metacarta.com (John R. Frank) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Fwd: Re: RFC: Changing the License on OpenLayers In-Reply-To: <6813AC83-9E66-47B2-B511-53FB9644D35F@dmsolutions.ca> References: <20071010161709.GW2616@vishnu.tridity.org> <6813AC83-9E66-47B2-B511-53FB9644D35F@dmsolutions.ca> Message-ID: > On this ... without wanting to be pedantic about it, can we change the > wording of the + and - voting system to something like: > > +1 strongly agree > +0 agree > 0 neither agree nor disagree > -0 disagree > -1 strongly disagree For the purposes of decision making, +0, 0, and -0 have been treated as identical in the past. I don't think we should change that. Thus, how about this: +1 agree +0,0,-0 ambivalent -1 disagree John From pspencer at dmsolutions.ca Wed Oct 10 14:30:46 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Fwd: Re: RFC: Changing the License on OpenLayers In-Reply-To: References: <20071010161709.GW2616@vishnu.tridity.org> <6813AC83-9E66-47B2-B511-53FB9644D35F@dmsolutions.ca> Message-ID: <4B28BBC8-8D48-4CFE-8FCB-3506C349DFE7@dmsolutions.ca> On 10-Oct-07, at 1:38 PM, John R. Frank wrote: >> On this ... without wanting to be pedantic about it, can we >> change the >> wording of the + and - voting system to something like: >> >> +1 strongly agree >> +0 agree >> 0 neither agree nor disagree >> -0 disagree >> -1 strongly disagree > > For the purposes of decision making, +0, 0, and -0 have been > treated as > identical in the past. I don't think we should change that. Thus, > how > about this: > > +1 agree > +0,0,-0 ambivalent > -1 disagree > I like it. +1 :) Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Wed Oct 10 15:08:47 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <20071010161403.GU2616@vishnu.tridity.org> References: <20071009165303.GB32728@metacarta.com> <470C4179.8030106@jasonbirch.com> <20071010031550.GA23705@metacarta.com> <470C68CB.9040609@gmail.com> <20071010161403.GU2616@vishnu.tridity.org> Message-ID: <470D233F.1050205@gmail.com> +1 My concerns are already noted, but I don't want to see graduation blocked by the separate, long winded process you are likely to have on your hands getting acceptance of the Clear BSD license. Schuyler Erle wrote: > * On 9-Oct-2007 at 10:53PM PDT, Cameron Shorter said: > >> +0 >> (changed to +1 if +0 is considered blocking) >> >> As noted on PSC email lists, I don't like the proliferation of Open >> Source licenses. I understand Metacarta's concerns regarding the >> ambiguity of the BSD license and think they are valid. >> >> I'm encouraged by Metacarta's intent to propose the "Clear BSD" be >> incorporated into the next version of the BSD. However I'm concerned by >> the delay engaging the BSD community, and it seems no resources are >> allocated to the task. >> > > I think we agreed by consensus that a +0 would block a license change. > Our informal understanding with Howard and Frank is that the Clear > BSD, as Chris indicated, is sufficiently similar to existing BSD > licenses that, given the existing precedent with GDAL, the OSGeo > Incubation Committee and Board of Directors are likely to accept it as > falling well within the spirit of other OSGeo-approved licenses. > > It's very important that we have a strong consensus within the PSC > before moving forward. Cameron, can we get either a +1 from you, or a > more detailed explanation of your concerns so that we can ensure that > they get addressed? > > SDE > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From bbrehmer at refractions.net Wed Oct 10 14:55:09 2007 From: bbrehmer at refractions.net (Ben Brehmer) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Client side load balancing Message-ID: <470D200D.8090104@refractions.net> I am looking at adding some client side load balancing to my OpenLayers app and was wondering if anyone has done something similair. Since a browser only ever opens a maximum of 2 connections to the same domain I am hoping to decrease the time it takes to load tiles by getting my layer to pull tiles from 4 domains (which will intern open 8 connections instead of 2). I am planning on loading an array of available domains at load time. Then when OpenLayers requests a tile it will choose a domain from this array (either round robin or randomly). Has this already been done? Does anyone foresee any problems with this? Thanks for any info, Ben Brehmer From crschmidt at metacarta.com Wed Oct 10 15:36:40 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Client side load balancing In-Reply-To: <470D200D.8090104@refractions.net> References: <470D200D.8090104@refractions.net> Message-ID: <20071010193640.GA2313@metacarta.com> On Wed, Oct 10, 2007 at 11:55:09AM -0700, Ben Brehmer wrote: > Has this already been done? Yes. This is implemented for all subclasses of the HTTPRequest layer -- if the "URL" parameter is an Array (as described as a possibility on http://dev.openlayers.org/apidocs/files/OpenLayers/Layer/HTTPRequest-js.html#OpenLayers.Layer.HTTPRequest.OpenLayers.Layer.HTTPRequest), then a URL will be selected based on a hash of the tile parameters. The multiserver.html file demonstrates this. Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Wed Oct 10 15:43:01 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:34 2010 Subject: [OpenLayers-Dev] Fwd: Re: RFC: Changing the License on OpenLayers In-Reply-To: <4B28BBC8-8D48-4CFE-8FCB-3506C349DFE7@dmsolutions.ca> References: <20071010161709.GW2616@vishnu.tridity.org> <6813AC83-9E66-47B2-B511-53FB9644D35F@dmsolutions.ca> <4B28BBC8-8D48-4CFE-8FCB-3506C349DFE7@dmsolutions.ca> Message-ID: <470D2B45.8020803@gmail.com> Mmm, I'm noticing a nit picking theme to all my emails lately. I apologize. I think it is important to distinguish in our documentation the difference between -0,0,+0 (as we already do at http://trac.openlayers.org/wiki/SteeringCommittee ). The only addition I'll add is is someone votes -0, the voter should state why they disagree. Paul Spencer wrote: > On 10-Oct-07, at 1:38 PM, John R. Frank wrote: > > >>> On this ... without wanting to be pedantic about it, can we >>> change the >>> wording of the + and - voting system to something like: >>> >>> +1 strongly agree >>> +0 agree >>> 0 neither agree nor disagree >>> -0 disagree >>> -1 strongly disagree >>> >> For the purposes of decision making, +0, 0, and -0 have been >> treated as >> identical in the past. I don't think we should change that. Thus, >> how >> about this: >> >> +1 agree >> +0,0,-0 ambivalent >> -1 disagree >> >> > > I like it. +1 :) > > Paul > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From eric.c2c at gmail.com Wed Oct 10 15:43:10 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers In-Reply-To: <470D233F.1050205@gmail.com> References: <20071009165303.GB32728@metacarta.com> <470C4179.8030106@jasonbirch.com> <20071010031550.GA23705@metacarta.com> <470C68CB.9040609@gmail.com> <20071010161403.GU2616@vishnu.tridity.org> <470D233F.1050205@gmail.com> Message-ID: <5ec103de0710101243l1a250b15jf922288c1b13886b@mail.gmail.com> +1 As its name suggests Clear BSD just clarifies BSD. So let's move forward with the OSGeo incubation. -- Eric On 10/10/07, Cameron Shorter wrote: > +1 > My concerns are already noted, but I don't want to see graduation > blocked by the separate, long winded process you are likely to have on > your hands getting acceptance of the Clear BSD license. > > Schuyler Erle wrote: > > * On 9-Oct-2007 at 10:53PM PDT, Cameron Shorter said: > > > >> +0 > >> (changed to +1 if +0 is considered blocking) > >> > >> As noted on PSC email lists, I don't like the proliferation of Open > >> Source licenses. I understand Metacarta's concerns regarding the > >> ambiguity of the BSD license and think they are valid. > >> > >> I'm encouraged by Metacarta's intent to propose the "Clear BSD" be > >> incorporated into the next version of the BSD. However I'm concerned by > >> the delay engaging the BSD community, and it seems no resources are > >> allocated to the task. > >> > > > > I think we agreed by consensus that a +0 would block a license change. > > Our informal understanding with Howard and Frank is that the Clear > > BSD, as Chris indicated, is sufficiently similar to existing BSD > > licenses that, given the existing precedent with GDAL, the OSGeo > > Incubation Committee and Board of Directors are likely to accept it as > > falling well within the spirit of other OSGeo-approved licenses. > > > > It's very important that we have a strong consensus within the PSC > > before moving forward. Cameron, can we get either a +1 from you, or a > > more detailed explanation of your concerns so that we can ensure that > > they get addressed? > > > > SDE > > > > > > > -- > Cameron Shorter > Systems Architect, http://lisasoft.com.au > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From eric.c2c at gmail.com Wed Oct 10 16:07:45 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Look who's using OpenLayers.... In-Reply-To: <6ae3fb590710081048w2cb0b966h449bd2126f690d56@mail.gmail.com> References: <6ae3fb590710081048w2cb0b966h449bd2126f690d56@mail.gmail.com> Message-ID: <5ec103de0710101307u2f366d4btd6bae43e432ac0da@mail.gmail.com> Their pushpin icons are very cool! -- Eric From ian at planetmayo.com Thu Oct 11 15:06:37 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Constructor trouble when testing new control Message-ID: I'm afraid I can't get my head around an error that's being thrown by my test at: http://trac.openlayers.org/browser/sandbox/ianmayo/openlayers/tests/Control/test_ScaleLine.html when I execute the following line in test_01_Control_ScaleLine_constructor: control = new OpenLayers.Control.ScaleLine(); I get this error reported: test_01_Control_ScaleLine_constructor planned 2 assertions but got 0; fail 0 ok 0 exception: : object: [Exception... "Illegal operation on WrappedNative prototype object" nsresult: "0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)" location: "JS frame :: file:///home/ian/dev/openlayers/openlayers/lib/OpenLayers/Util.js :: anonymous :: line 60" data: no] The guilty line is calling my constructor in http://trac.openlayers.org/browser/sandbox/ianmayo/openlayers/lib/OpenLayers/Control/ScaleLine.js: initialize: function(element, options) { OpenLayers.Control.prototype.initialize.apply(this, arguments); this.element = OpenLayers.Util.getElement(element); }, I have to admit, I don't fully understand how the constructor/initialiser model is working. The other tests in the module all work - and demonstrate parameters being used in the constructor. I'd really appreciate a pointer in either the correct way to handle parameters in the constructor, or the correct way to use the parameters in the constructor. cheers, Ian. From crschmidt at metacarta.com Thu Oct 11 15:24:18 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Constructor trouble when testing new control In-Reply-To: References: Message-ID: <20071011192418.GC2738@metacarta.com> On Thu, Oct 11, 2007 at 08:06:37PM +0100, Ian Mayo wrote: > I'm afraid I can't get my head around an error that's being thrown by > my test at: > http://trac.openlayers.org/browser/sandbox/ianmayo/openlayers/tests/Control/test_ScaleLine.html > > when I execute the following line in test_01_Control_ScaleLine_constructor: > control = new OpenLayers.Control.ScaleLine(); > > I get this error reported: > test_01_Control_ScaleLine_constructor planned 2 assertions but got 0; > fail 0 ok 0 > exception: : object: [Exception... "Illegal operation on WrappedNative > prototype object" nsresult: "0x8057000c > (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)" location: "JS frame :: > file:///home/ian/dev/openlayers/openlayers/lib/OpenLayers/Util.js :: > anonymous :: line 60" data: no] > > The guilty line is calling my constructor in > http://trac.openlayers.org/browser/sandbox/ianmayo/openlayers/lib/OpenLayers/Control/ScaleLine.js: > initialize: function(element, options) { > OpenLayers.Control.prototype.initialize.apply(this, arguments); > this.element = OpenLayers.Util.getElement(element); > }, > > I have to admit, I don't fully understand how the > constructor/initialiser model is working. So, there are a couple things to be aware of. 1. The Control.initialize prototype expects one argument, an object with key/value pairs to set on the control. Currently, you pass an element as the first argument, which means you pass that to your control prototype. You should instead do: OpenLayers.Control.prototype.initialize.apply(this, [options]); The reason this is happening is that it's attempting to copy the 'hasOwnProperty' from an HTML DOM Element, which is not allowed on a "Wrapped XP Native" object (HTML DOM element). Annoying error message, huh? 2. In general, passing an element as part of the contorl init is not how we do things anymore. Instead, we use the 'this.div' property: this can be passed via the options as {div: HTMLDOMElement}, which means that we don't have to do anything special for control initializers (they can all have the same args) which would have saved you here. We haven't updated the old code, but control.panel demonstrates it -- but so long as you use this.div for your HTML element, you don't really need to do anything to take advantage of this. Hope this helps... Regards, -- Christopher Schmidt MetaCarta From volpicelli at oato.inaf.it Thu Oct 11 17:29:32 2007 From: volpicelli at oato.inaf.it (Antonio) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with Safari on Mac Message-ID: <470E95BC.6050101@oato.inaf.it> Hi guys, I was just trying the 2.5. There are a lot of work done and I want say Thanks. I am having some troubles with safari on Mac to run many examples. This is the first time I am using this browser on this platform (Safari on Windows works well) and I don't know if the 2.5 or all old releases had the same problem. If I remember well there was something as "Safari need to load a unique js file, it doesn't like much to load multiple js files". Could be this the problem? In the example.html when I try to uncheck the Overlay layer "DM Solution" it is hidden but when I check it again it is no more showed. Thanks again Antonio -- /-------------------------------------------------------\ PLEASE WARNING: E-mail is CHANGED volpicelli@oato.inaf.it /-------------------------------------------------------\ From crschmidt at metacarta.com Thu Oct 11 18:07:19 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with Safari on Mac In-Reply-To: <470E95BC.6050101@oato.inaf.it> References: <470E95BC.6050101@oato.inaf.it> Message-ID: <20071011220719.GA20421@metacarta.com> On Thu, Oct 11, 2007 at 11:29:32PM +0200, Antonio wrote: > Hi guys, > I was just trying the 2.5. There are a lot of work done and I want say > Thanks. > I am having some troubles with safari on Mac to run many examples. This > is the first time I am using this browser on this platform (Safari on > Windows works well) and I don't know if the 2.5 or all old releases had > the same problem. > If I remember well there was something as "Safari need to load a unique > js file, it doesn't like much to load multiple js files". > Could be this the problem? > In the example.html when I try to uncheck the Overlay layer "DM > Solution" it is hidden but when I check it again it is no more showed. Sounds like http://trac.openlayers.org/ticket/758 , with no known workaround. Regards, -- Christopher Schmidt MetaCarta From john.frank at metacarta.com Fri Oct 12 09:37:25 2007 From: john.frank at metacarta.com (John R. Frank) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Changing the License on OpenLayers Message-ID: +1 jrf (I thought I had already voted in favor of this. Sorry for the delay.) From jachym.cepicky at gmail.com Fri Oct 12 01:10:58 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] OpenLayers.Popup status Message-ID: <1192165858.8262.14.camel@mellon> hi, I wanted to ask about the status of "Google" popups in OpenLayers. I managed more or less to port example from Richard Thurbin [1] to current trunk version of OpenLayers. However, as far as I saw, the code uses different approach for Popup decorations (images vs. rico rounded corners) and other details. So, I would like to ask, if it makes sense to continue in the porting and clean the code little bit, so it could be merged to trunk or if completely different approach is to be used and there is already defined concept or living demo, which will go to trunk in the future. Thanks Jachym [1] http://dev.openlayers.org/sandbox/CloudAmber/Trunk/ -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071012/80dc8d01/attachment.bin From crschmidt at metacarta.com Fri Oct 12 09:53:36 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Changing the license: Implementation Message-ID: <20071012135336.GA6748@metacarta.com> >From http://trac.openlayers.org/wiki/RFC/LicenseChange : * SVN Repository rearrangement as discussed in [http://openlayers.org/pipermail/users/2007-September/002823.html users post from september] * Remove repository-license entirely, instead having only license.txt * Change all code comments to refer to http://svn.openlayers.org/license.txt only * Modify pre-amble text to license.txt to read: """ This license applies to all code and content in the 'branches', 'trunk', and 'project' directories of the Openlayers code repository at svn.openlayers.org, and applies to all releases of OpenLayers later than 2.5. Releases before OpenLayers 2.5 were released under the BSD license, included with the distribution. """ There is no plan to attempt to retroactively apply the new license to old releases. Does that sound right? Does anyone have a problem with me modifying SVN to reflect this? I'll probably do it later today/this weekend unless I hear otherwise, since I think we all agree on the general implementation. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Fri Oct 12 09:54:34 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Changing the license: Implementation In-Reply-To: <20071012135336.GA6748@metacarta.com> References: <20071012135336.GA6748@metacarta.com> Message-ID: <20071012135434.GB6748@metacarta.com> On Fri, Oct 12, 2007 at 09:53:36AM -0400, Christopher Schmidt wrote: > From http://trac.openlayers.org/wiki/RFC/LicenseChange : Oh, most important part, which I forgot: change Release/Procedure to remove anything MetaCarta specific. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Fri Oct 12 09:57:23 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] OpenLayers.Popup status In-Reply-To: <1192165858.8262.14.camel@mellon> References: <1192165858.8262.14.camel@mellon> Message-ID: <20071012135723.GC6748@metacarta.com> On Fri, Oct 12, 2007 at 07:10:58AM +0200, Jachym Cepicky wrote: > hi, > I wanted to ask about the status of "Google" popups in OpenLayers. I > managed more or less to port example from Richard Thurbin [1] to current > trunk version of OpenLayers. However, as far as I saw, the code uses > different approach for Popup decorations (images vs. rico rounded > corners) and other details. So, I would like to ask, if it makes sense > to continue in the porting and clean the code little bit, so it could be > merged to trunk > > or > > if completely different approach is to be used and there is already > defined concept or living demo, which will go to trunk in the future. It is expected that the work done on the CloudAmber popups will be moved into trunk directly -- the rico rounded corners style popups simply don't have the ability to do what people want as far as 'pretty' look and feel, so we're going to need the option that the CloudAmber popups provide. I do not think we've done neough investigation to figure out the exact method of plling them in, but writing tests, etc. for them at this point is likely to be extremely beneficial and accelerate acceptance into trunk, even if things change. Regards, -- Christopher Schmidt MetaCarta From ian at planetmayo.com Fri Oct 12 02:27:46 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Servers down Message-ID: Chaps, it appears that the OpenLayers web servers have been down for the last hour or so, though the SVN server appears to be working ok. regards, Ian From crschmidt at metacarta.com Fri Oct 12 10:11:59 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Servers down In-Reply-To: References: Message-ID: <20071012141159.GA9610@metacarta.com> On Fri, Oct 12, 2007 at 07:27:46AM +0100, Ian Mayo wrote: > Chaps, > it appears that the OpenLayers web servers have been down for the last > hour or so, though the SVN server appears to be working ok. For the record, mail is hosted at the same machine as the webserver, so mailing the list doesn't help :) There was a network issue here at MetaCarta that caused this bump, and (as you can see) everything should be up and running ag ain now. Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Fri Oct 12 08:15:54 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Archiving PSC Votes In-Reply-To: <6ae3fb590710100812m67580041gc4ecdb8cac1cb7f6@mail.gmail.com> References: <6ae3fb590710100812m67580041gc4ecdb8cac1cb7f6@mail.gmail.com> Message-ID: <6D21A480-3D48-47AF-BF43-D713A7E2610D@dmsolutions.ca> I agree that this is a minor issue, and I agree that the information is available by searching the archives. However, searching the archives to get a summary of what was voted on is neither trivial nor convenient for most people. For me, I would find it difficult to figure out what the PSC had voted on and what the result was. Should we care? I think we should because this promotes the openness of the PSC to the community and I will volunteer to do the grunt work if necessary, but I think the onus is on the PSC member who brings an issue to vote to record it somewhere. Paul On 10-Oct-07, at 11:12 AM, Erik Uzureau wrote: > In the thread "RFC: Resolution to only change License with Unanimous > Vote" , Paul Spencer has brought up the idea of making a section on > the WIKI to keep a public record of RFC's and also the Votes of the > PSC on issues of importance. > > So far, we've seen people on both sides of the fence with this issue. > Some people think it's important, whereas others think it is maybe a > waste of time. Luckily, noone seems to be particularly opposed to the > idea, the reservations expressed to this point seem to indicate only a > wariness at the overhead. > > Instead of convoluting the other thread with that discussion, I'd like > it to continue here in a new thread. > > I see this as a rather minor issue: as per hobu's suggestion at the > pow-wow in Victoria, all PSC votes will now be held publicly on the > dev list, so the idea of registering them does not imply a compromise > on anyone's privacy. It seems to me to only be a question of who is > really willing to do the work and whether we think that would be time > well spent. > > > Please, if you have opinions on this, voice them here, now. > Erik > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Fri Oct 12 10:16:39 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Recording RFC votes Message-ID: <20071012141639.GB9610@metacarta.com> So, after doing this a couple times, I've decided that I definitely think it is worth it to record votes. See: http://trac.openlayers.org/wiki/RFC/RequireUnanimousVoteForLicenseChange http://trac.openlayers.org/wiki/RFC/LicenseChange Both of these now have full links to the thread and votes from each member, which show some history and relevant context for someone asking why the heck we did something. I think that perhaps it will make more sense to have RFCs for more large code changes -- the projection code is one example, and other thing sthat might change behavior. If we do that, I think it's good to have a link to the discussions around an issue, as well as a 'current status' page for things -- is projection supprot fully in, partially in, who's working on it, etc. Up until this point, most of our changes are just minor features or bugfixes -- a new layer type isn't anything to write home about. However, as we approach a place where small features are relatively filled in, and the changes we make are either more sweeping (internationallization, projection support, etc.) or possibly changing backwards compatibility, we should have a more widespread discussion, and that results in a case where linking back to that discussion is a good thing. In the case of the license change page, keeping a tally actually resulted in me finding that John never voted :) so I think that all in all, that's a good thing to follow. Regards, -- Christopher Schmidt MetaCarta From ian at planetmayo.com Fri Oct 12 01:46:36 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Constructor trouble when testing new control In-Reply-To: References: <20071011192418.GC2738@metacarta.com> Message-ID: Sorted. Will collate patch at next opportunity. I suspect I still haven't got the hang of OpenLayer javascript constructors- but I know the correct model to plagiarize next time... thanks for your help Chris, Ian On 11/10/2007, Christopher Schmidt wrote: > On Thu, Oct 11, 2007 at 08:06:37PM +0100, Ian Mayo wrote: > > I'm afraid I can't get my head around an error that's being thrown by > > my test at: > > > > I have to admit, I don't fully understand how the > > constructor/initialiser model is working. > > ... > > So, there are a couple things to be aware of. > > 1. The Control.initialize prototype expects one argument, an object with > ... > > 2. In general, passing an element as part of the contorl init is not how > ... > > Hope this helps... > > Regards, > -- > Christopher Schmidt > MetaCarta > From ian at planetmayo.com Fri Oct 12 11:04:50 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Servers down In-Reply-To: <20071012141159.GA9610@metacarta.com> References: <20071012141159.GA9610@metacarta.com> Message-ID: duh. We'll know for next time, Ian On 12/10/2007, Christopher Schmidt wrote: > On Fri, Oct 12, 2007 at 07:27:46AM +0100, Ian Mayo wrote: > > Chaps, > > it appears that the OpenLayers web servers have been down for the last > > hour or so, though the SVN server appears to be working ok. > > For the record, mail is hosted at the same machine as the webserver, so > mailing the list doesn't help :) > > There was a network issue here at MetaCarta that caused this bump, and > (as you can see) everything should be up and running ag ain now. > > Regards, > -- > Christopher Schmidt > MetaCarta > -- Ian Mayo PlanetMayo Ltd From john.cole at uai.com Fri Oct 12 11:10:40 2007 From: john.cole at uai.com (John Cole) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] google/ve panning issue Message-ID: <76758090F8686C47A44B6FF52514A1D307909EFA@hermes.uai.int> Playing around with the 2.5 examples, I noticed that when panning on the google or ve examples, the base layer goes white if you pan more than aprox 30% of the image quickly. Loading the same 2.4 examples, this doesn't happen. I tried IE7, FF2 and SafariWin. Is this expected behavior? John No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.8/1066 - Release Date: 10/12/2007 11:10 AM This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From erik.uzureau at metacarta.com Fri Oct 12 11:38:10 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Changing the license: Implementation In-Reply-To: <20071012135434.GB6748@metacarta.com> References: <20071012135336.GA6748@metacarta.com> <20071012135434.GB6748@metacarta.com> Message-ID: <6ae3fb590710120838q79ca02a8v91cb336351211f83@mail.gmail.com> Sounds great, Chris. A huge step forward for the OL project. Thanks for being so proactive about this. :-) Erik On 10/12/07, Christopher Schmidt wrote: > On Fri, Oct 12, 2007 at 09:53:36AM -0400, Christopher Schmidt wrote: > > From http://trac.openlayers.org/wiki/RFC/LicenseChange : > > Oh, most important part, which I forgot: change Release/Procedure to > remove anything MetaCarta specific. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From crschmidt at metacarta.com Fri Oct 12 11:54:01 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Constructor trouble when testing new control In-Reply-To: References: <20071011192418.GC2738@metacarta.com> Message-ID: <20071012155401.GA20717@metacarta.com> On Fri, Oct 12, 2007 at 06:46:36AM +0100, Ian Mayo wrote: > Sorted. Will collate patch at next opportunity. > > I suspect I still haven't got the hang of OpenLayer javascript > constructors- but I know the correct model to plagiarize next time... When you subclass from something in Python, your class looks like this: class SomeOtherClass(object): def __init__(self, options): # Do Stuff with Options class MyClass(SomeOtherClass): def __init__(self, myclass_specific, options): SomeOtherClass.__init__(self, options) That is: SomeOtherClass initializer takes one argument (other than itself), but MyClass takes more arguments. When MyClass calls the SomeOtherClass init, it should only pass the arguments to SomeOtherClass that SomeOtherClass is expecting, but not the additional args that MyClass cares about. This is the same in OpenLayers Javascript subclassing: Control = OpenLayers.Class({ initialize: function(options) { } }); Control.Subclass = OpenLayers.Class({ initialize: function(additional_arg, options) { Control.prototype.initialize.apply(this, [options]); } }); The 'apply' is saying 'call this function on *this* object, passing *this* list of arguments'. 'arguments' itself is a special keyword in Javascript, meaning 'an array of all args passed to this function'. Since the "Control" initialize only takes the one arg, instead of passing all the args we were given, we pass only the one. Does that help it make more sense? Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Fri Oct 12 11:59:16 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] google/ve panning issue In-Reply-To: <76758090F8686C47A44B6FF52514A1D307909EFA@hermes.uai.int> References: <76758090F8686C47A44B6FF52514A1D307909EFA@hermes.uai.int> Message-ID: <20071012155916.GB20717@metacarta.com> On Fri, Oct 12, 2007 at 10:10:40AM -0500, John Cole wrote: > Playing around with the 2.5 examples, I noticed that when panning on the > google or ve examples, the base layer goes white if you pan more than aprox > 30% of the image quickly. > > Loading the same 2.4 examples, this doesn't happen. I tried IE7, FF2 and > SafariWin. You got this to *not* happen in 2.4? I'm amazed -- this has always been a problem as far as I'm aware. See: http://gmaps.eactive.org/testmove.html http://groups.google.co.in/group/Google-Maps-API/browse_thread/thread/3cab18706cb51efd which address this issue as far as Google Maps is concerned. VE suffers a number of different problems, that have a similar effect -- some of which are improved by the changes proposed in http://trac.openlayers.org/ticket/1053 but which have not yet been codified into a patch. Can you share exactly what you're doing to make it work in 2.4? Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Fri Oct 12 12:17:54 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] javascript keys vs counter In-Reply-To: <20071012120310.7bb9cab8.jake@jpw.biz> References: <20071011120901.GB10193@metacarta.com> <20071011133441.GA19618@metacarta.com> <20071011152448.GA26324@metacarta.com> <20071012120310.7bb9cab8.jake@jpw.biz> Message-ID: <20071012161754.GA24305@metacarta.com> On Fri, Oct 12, 2007 at 12:03:10PM -0400, Jacob Westfall wrote: > On Thu, 11 Oct 2007 11:24:48 -0400 > Christopher Schmidt wrote: > > for (item in feats) { } > > > > will return 0, 1, 2, etc. > > > > It's the keys, not the objects, which are returned. > > > > However, in general, you should just use the for (i = 0; i < > > feats.length; i++) types -- there are resources on the web that you can > > read about why and how, I'm sure, I'm just not up to researching them at > > the moment :) > > Hi, > I haven't been able to find the resources you mention about this issue. Should I be searching for keys versus counters? Thanks, I think that I was thinking along the lines of: http://ajaxian.com/archives/javascript-associative-arrays-considered-harmful "The other problem with using Arrays as associative arrays means you can no longer extend Array.prototype, which is what Prototype 1.5 does to great effect." "So use Object for associative arrays, and use Array for numeric arrays. Of course, there will always be exceptions, "no best practices", yadda yadda - but just be aware of the danger and possible confusion if you do violate this." Regards, -- Christopher Schmidt MetaCarta From andre at covaluate.com Fri Oct 12 13:41:46 2007 From: andre at covaluate.com (Andre Lockhart) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] SVG line rendering bug on pan Message-ID: <02c601c80cf7$296fd730$270110ac@LIFEBOOKS7110> I am working on an application where I am drawing lines over a map using the OL SVG graphics API. This is a problem with dragging the map after the line has already been drawn/rendered. After dragging the map and seeing the OpenLayers lines move with the drag event, I have noticed that when I lift my finger off the left mouse button the line re-renders at its former location for an instant then disappears. I was wondering if there was a trick to suppressing this. The goal would be to have a smooth movement of the map and drawing layer and not see flicker and skew of the drawn features. Where in the source code would we go to fix this bug? I didn't see an open bug on this, so how do I get it logged? Thanks! Andre -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071012/54dfda31/attachment.html From john.cole at uai.com Fri Oct 12 13:46:39 2007 From: john.cole at uai.com (John Cole) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] google/ve panning issue Message-ID: <76758090F8686C47A44B6FF52514A1D307909EFF@hermes.uai.int> Hmmmm... I'm afraid that I just ran the example. I did have an older 2.4 rc, and the release apparently throws a JS error. I was under the impression that this was a new issue, since I haven't seen it in 2.3 or the 2.4 rc we were using. John -----Original Message----- From: Christopher Schmidt [mailto:crschmidt@metacarta.com] Sent: Friday, October 12, 2007 10:59 AM To: John Cole Cc: dev@openlayers.org Subject: Re: [OpenLayers-Dev] google/ve panning issue On Fri, Oct 12, 2007 at 10:10:40AM -0500, John Cole wrote: > Playing around with the 2.5 examples, I noticed that when panning on the > google or ve examples, the base layer goes white if you pan more than aprox > 30% of the image quickly. > > Loading the same 2.4 examples, this doesn't happen. I tried IE7, FF2 and > SafariWin. You got this to *not* happen in 2.4? I'm amazed -- this has always been a problem as far as I'm aware. See: http://gmaps.eactive.org/testmove.html http://groups.google.co.in/group/Google-Maps-API/browse_thread/thread/3cab18 706cb51efd which address this issue as far as Google Maps is concerned. VE suffers a number of different problems, that have a similar effect -- some of which are improved by the changes proposed in http://trac.openlayers.org/ticket/1053 but which have not yet been codified into a patch. Can you share exactly what you're doing to make it work in 2.4? Regards, -- Christopher Schmidt MetaCarta No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.8/1066 - Release Date: 10/12/2007 11:10 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.8/1066 - Release Date: 10/12/2007 11:10 AM This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From crschmidt at metacarta.com Fri Oct 12 14:08:54 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] SVG line rendering bug on pan In-Reply-To: <02c601c80cf7$296fd730$270110ac@LIFEBOOKS7110> References: <02c601c80cf7$296fd730$270110ac@LIFEBOOKS7110> Message-ID: <20071012180854.GA5200@metacarta.com> On Fri, Oct 12, 2007 at 10:41:46AM -0700, Andre Lockhart wrote: > I am working on an application where I am drawing lines over a map using the > OL SVG graphics API. What browser are you in? IE? (In that case, it's actually VML, not SVG.) Can you reproduce it on the examples? I think this might be fixed by http://trac.openlayers.org/ticket/965 -- I think this is the same general problem, but possibly not exactly the same one. > Where in the source code would we go to fix this bug? Probably in the Renderer/* Classes. > I didn't see an open bug on this, so how do I get it logged? http://trac.openlayers.org/wiki/FilingTickets Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Fri Oct 12 15:44:06 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Archiving PSC Votes In-Reply-To: <6D21A480-3D48-47AF-BF43-D713A7E2610D@dmsolutions.ca> References: <6ae3fb590710100812m67580041gc4ecdb8cac1cb7f6@mail.gmail.com> <6D21A480-3D48-47AF-BF43-D713A7E2610D@dmsolutions.ca> Message-ID: <470FCE86.7080807@gmail.com> I guess there are different levels of importance for things that are voted on. For a major design change, or large functionality addition, where someone is prepared to write up a RFQ to describe it, the extra effort to record the decision at the bottom of the RFQ is relatively minor. Eg: "Passed by PSC vote" or "Blocked by Joe Blogs during PSC vote who said ...". I'm happy with this. It would be more effort to fill in a table ticking off the votes for the 15 or so PSC members. While I can see value in this, I don't think the value outweighs the annoyance factor this will introduce. In defining a process, each task should have a person responsible for the task. So we should define the person who is going to record the votes. Ideally it should be a role, not a person who might leave the project. Eg: The person raising the RFC should also record the vote. For minor PSC votes, like "should we release or not", I'm not sure that this warrants the effort of transcribing from email to wiki table. If we had a voting web tool, which collected PSC member votes via a one click process, then I'll be 100% behind the proposal. (And I'll copy the process over to Mapbuilder too). Paul Spencer wrote: > I agree that this is a minor issue, and I agree that the information > is available by searching the archives. However, searching the > archives to get a summary of what was voted on is neither trivial nor > convenient for most people. For me, I would find it difficult to > figure out what the PSC had voted on and what the result was. > > Should we care? I think we should because this promotes the openness > of the PSC to the community and I will volunteer to do the grunt work > if necessary, but I think the onus is on the PSC member who brings an > issue to vote to record it somewhere. > > Paul > > On 10-Oct-07, at 11:12 AM, Erik Uzureau wrote: > > >> In the thread "RFC: Resolution to only change License with Unanimous >> Vote" , Paul Spencer has brought up the idea of making a section on >> the WIKI to keep a public record of RFC's and also the Votes of the >> PSC on issues of importance. >> >> So far, we've seen people on both sides of the fence with this issue. >> Some people think it's important, whereas others think it is maybe a >> waste of time. Luckily, noone seems to be particularly opposed to the >> idea, the reservations expressed to this point seem to indicate only a >> wariness at the overhead. >> >> Instead of convoluting the other thread with that discussion, I'd like >> it to continue here in a new thread. >> >> I see this as a rather minor issue: as per hobu's suggestion at the >> pow-wow in Victoria, all PSC votes will now be held publicly on the >> dev list, so the idea of registering them does not imply a compromise >> on anyone's privacy. It seems to me to only be a question of who is >> really willing to do the work and whether we think that would be time >> well spent. >> >> >> Please, if you have opinions on this, voice them here, now. >> Erik >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From cameron.shorter at gmail.com Fri Oct 12 15:52:26 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Servers down In-Reply-To: <20071012141159.GA9610@metacarta.com> References: <20071012141159.GA9610@metacarta.com> Message-ID: <470FD07A.4030602@gmail.com> Chris, This brings up another point, reliability of OpenLayers servers. The OpenLayers tutorials encourage users to point to the Openlayers.js from Metacarta. This means that users are now dependent upon Metacarta's service reliability. I don't want to start an argument as to whether it is a good idea or not to depend upon an organisation you don't control for your service. However, I think it would be good for Metacarta to publish its service uptime policy. Maybe run this email past your lawyers and I bet they come back with a requirement for a disclaimer. Christopher Schmidt wrote: > On Fri, Oct 12, 2007 at 07:27:46AM +0100, Ian Mayo wrote: > >> Chaps, >> it appears that the OpenLayers web servers have been down for the last >> hour or so, though the SVN server appears to be working ok. >> > > For the record, mail is hosted at the same machine as the webserver, so > mailing the list doesn't help :) > > There was a network issue here at MetaCarta that caused this bump, and > (as you can see) everything should be up and running ag ain now. > > Regards, > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From crschmidt at metacarta.com Fri Oct 12 16:27:36 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Servers down In-Reply-To: <470FD07A.4030602@gmail.com> References: <20071012141159.GA9610@metacarta.com> <470FD07A.4030602@gmail.com> Message-ID: <20071012202736.GA10637@metacarta.com> On Sat, Oct 13, 2007 at 05:52:26AM +1000, Cameron Shorter wrote: > Chris, > This brings up another point, reliability of OpenLayers servers. > The OpenLayers tutorials encourage users to point to the Openlayers.js > from Metacarta. This is a problem. We should fix this. MetaCarta does not have the resources to devote to ensuring any server is up. Even once we migrate to OSGeo infrastructure, we don't have any guarentees of uptime: the servers are run by volunteers, provided free of charge on the goodwill of other organizations, etc. Additionally, any service that uses the OpenLayers API live is going to suffer excessive load times compared to rolling their own, because the OpenLayers.js uses the 'full' build profile -- over 300kb now. It's fine for demos, and quick examples, but we need to change the docs to state explicitly that users should not be depending on openlayers.org to host the /api/ JS long term, unless/until such time as alternative resources which provide some SLA are available. Regards, -- Christopher Schmidt MetaCarta From lancelot at inetnebr.com Fri Oct 12 20:35:22 2007 From: lancelot at inetnebr.com (Lance Dyas) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] OpenLayers.Popup status In-Reply-To: <20071012135723.GC6748@metacarta.com> References: <1192165858.8262.14.camel@mellon> <20071012135723.GC6748@metacarta.com> Message-ID: <471012CA.2010809@inetnebr.com> Christopher Schmidt wrote: > On Fri, Oct 12, 2007 at 07:10:58AM +0200, Jachym Cepicky wrote: > >> hi, >> I wanted to ask about the status of "Google" popups in OpenLayers. I >> managed more or less to port example from Richard Thurbin [1] to current >> trunk version of OpenLayers. However, as far as I saw, the code uses >> different approach for Popup decorations (images vs. rico rounded >> corners) and other details. So, I would like to ask, if it makes sense >> to continue in the porting and clean the code little bit, so it could be >> merged to trunk >> >> or >> >> if completely different approach is to be used and there is already >> defined concept or living demo, which will go to trunk in the future. >> > > It is expected that the work done on the CloudAmber popups will be moved > into trunk directly -- the rico rounded corners style popups simply > don't have the ability to do what people want as far as 'pretty' look > and feel, so we're going to need the option that the CloudAmber popups > provide. > > I do not think we've done neough investigation to figure out the exact > method of plling them in, but writing tests, etc. for them at this point > is likely to be extremely beneficial and accelerate acceptance into > trunk, even if things change. > > Regards, > how about SVG / VML popups for the progressive ;-) I dont have many maps this wouldnt work for... you could even fall back to rico cornered popups for those very very very few poor souls without SVG or VML.. From eric.c2c at gmail.com Sat Oct 13 17:35:10 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] removeLayer issue? Message-ID: <5ec103de0710131435u14e3e91cw2e2495629c0bf172@mail.gmail.com> Hi Map.removeLayer() moves layers in the Map.layers array, but do not change these layers' z-index values. Can't this cause problems, or at least unexpected behavior from the OpenLayers user standpoint? Example scenario: Initial state: the map has one baselayer. (1) add 3 overlays to the map. Overlay A gets z-index 330. Overlay B gets z-index 335. Overlay C gets z-index 340 (2) remove Overlay A and Overlay B from the map (3) add Overlay D. Overlay D's layer index is 2 so it gets z-index 335. Overlay D's z-index (335) is lower than Overlay C (340), even though Overlay D was added after Overlay C. Do you think this deserves a ticket and a fix? -- Eric From crschmidt at metacarta.com Sat Oct 13 18:26:03 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] removeLayer issue? In-Reply-To: <5ec103de0710131435u14e3e91cw2e2495629c0bf172@mail.gmail.com> References: <5ec103de0710131435u14e3e91cw2e2495629c0bf172@mail.gmail.com> Message-ID: <20071013222603.GA20206@metacarta.com> On Sat, Oct 13, 2007 at 11:35:10PM +0200, Eric Lemoine wrote: > Hi > > Map.removeLayer() moves layers in the Map.layers array, but do not > change these layers' z-index values. Can't this cause problems, or at > least unexpected behavior from the OpenLayers user standpoint? > Do you think this deserves a ticket and a fix? Yep. Though I don't know how I'd fix it off the top fo my head :) maybe z-index reordering when removeLayer is called... Regards, -- Christopher Schmidt MetaCarta From eric.c2c at gmail.com Sun Oct 14 09:03:02 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] removeLayer issue? In-Reply-To: <20071013222603.GA20206@metacarta.com> References: <5ec103de0710131435u14e3e91cw2e2495629c0bf172@mail.gmail.com> <20071013222603.GA20206@metacarta.com> Message-ID: <5ec103de0710140603u6f1d292cq43a05a7176b8dd68@mail.gmail.com> On 10/14/07, Christopher Schmidt wrote: > On Sat, Oct 13, 2007 at 11:35:10PM +0200, Eric Lemoine wrote: > > Hi > > > > Map.removeLayer() moves layers in the Map.layers array, but do not > > change these layers' z-index values. Can't this cause problems, or at > > least unexpected behavior from the OpenLayers user standpoint? > > > Do you think this deserves a ticket and a fix? > > Yep. Though I don't know how I'd fix it off the top fo my head :) maybe > z-index reordering when removeLayer is called... I was thinking of that as well. I'll open a ticket and hopefully post a patch. -- Eric From crschmidt at metacarta.com Sun Oct 14 11:02:39 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] [OpenLayers-Trac] [OpenLayers] #758: BaseLayer switching in Opera, Safari In-Reply-To: <062.599f486e94ff3f5bf5bd7f0a7f5eab2c@openlayers.org> References: <053.7e7e87fc8155a51f976356ce5c044e50@openlayers.org> <062.599f486e94ff3f5bf5bd7f0a7f5eab2c@openlayers.org> Message-ID: <20071014150239.GA28563@metacarta.com> On Sun, Oct 14, 2007 at 02:12:12PM -0000, OpenLayers wrote: > Ticket URL: > #758: BaseLayer switching in Opera, Safari > Comment: > > For Safari, this is: > > Bug 9582: img.onload event ONLY fires when .src changes > http://bugs.webkit.org/show_bug.cgi?id=9582 > > A workaround is to make layer.getUrl() return a URL with additional > parameters, so that the src is always changed, but that's kind of ugly. > > Attaching a patch with a second workaround, which sets the Tile URL to > blank.gif in clear() (which will then be reset shortly after in draw()). I'd love to have some feedback on this. It's just a workaround for Safari. An alternative, more invasive, workaround would be to check in moveTo if the URL has changed, and if it hasn't, not call display:none in the first place. That would require overriding moveTo to actually call getURL on the tile before setting display:none, but might end up being a better solution, since we don't have to 'flicker' the tiles in that case. I just tried to hack that together, and failed, but I spent from 1am -> 5am finding the bug and talking it over with webkit devs, so I'm probably not really well qualified. I would really like to get this fixed in 2.6, now that I know it's fixable, though. Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Mon Oct 15 02:41:03 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling Message-ID: <47130B7F.2040600@gmail.com> Tomorrow, I'd like to get Roald enhancing OpenLayers KML support and would like to make sure we are not covering old ground. Is the KML code in the trunk of Openlayers the most recent, or does someone have a sandbox with some more development. Am I right in understanding that KML styles are not passed by Openlayers yet? If not, I was thinking this is an issue we would like to look into. Otherwise, I'm open to suggested alternative KML related development. Feel free to ping me or Roald on IRC to discuss implementation details. -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From lancelot at inetnebr.com Mon Oct 15 03:02:18 2007 From: lancelot at inetnebr.com (Lance Dyas) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <47130B7F.2040600@gmail.com> References: <47130B7F.2040600@gmail.com> Message-ID: <4713107A.7020302@inetnebr.com> I too am interested in this development. I have done development using the Google Maps API they have an API provided KML parser which allowed inadequate user control and features.. And the available third party parser was also innadequate to any real kml. particularly style handling.(as well as other features) Here are some of the complexities I ran into involving KML Styles 1) Inline Styles (easiest part) 2) StyleMaps (may define hover events) 3) Cascading Styles 4) Referenced Styles (can even be in a different document - though that part might not be worth implementing) Cameron Shorter wrote: > Tomorrow, I'd like to get Roald enhancing OpenLayers KML support and > would like to make sure we are not covering old ground. > > Is the KML code in the trunk of Openlayers the most recent, or does > someone have a sandbox with some more development. > > Am I right in understanding that KML styles are not passed by Openlayers > yet? If not, I was thinking this is an issue we would like to look into. > Otherwise, I'm open to suggested alternative KML related development. > Feel free to ping me or Roald on IRC to discuss implementation details. > > From cameron.shorter at gmail.com Mon Oct 15 03:16:44 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <4713107A.7020302@inetnebr.com> References: <47130B7F.2040600@gmail.com> <4713107A.7020302@inetnebr.com> Message-ID: <471313DC.4030609@gmail.com> Lance, Is any of the code you have written worth rolling back into the Openlayers codebase? Alternatively, do you have suggestions regarding how we should handle KML style support in Openlayers. Lance Dyas wrote: > I too am interested in this development. > I have done development using the Google Maps API > they have an API provided KML parser which allowed > inadequate user control and features.. And the available > third party parser was also innadequate to any real kml. > particularly style handling.(as well as other features) > > Here are some of the complexities I ran into > involving KML Styles > > 1) Inline Styles (easiest part) > 2) StyleMaps (may define hover events) > 3) Cascading Styles > 4) Referenced Styles (can even be in a different document - though > that part might not be worth implementing) > > Cameron Shorter wrote: >> Tomorrow, I'd like to get Roald enhancing OpenLayers KML support and >> would like to make sure we are not covering old ground. >> >> Is the KML code in the trunk of Openlayers the most recent, or does >> someone have a sandbox with some more development. >> >> Am I right in understanding that KML styles are not passed by >> Openlayers yet? If not, I was thinking this is an issue we would like >> to look into. Otherwise, I'm open to suggested alternative KML >> related development. Feel free to ping me or Roald on IRC to discuss >> implementation details. >> >> > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From andreas.hocevar at gmail.com Mon Oct 15 04:42:23 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <47130B7F.2040600@gmail.com> References: <47130B7F.2040600@gmail.com> Message-ID: <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> Hi, for styling, you should probably take a look at the OpenLayers.Style class in the ahocevar sandbox. This is the one we use for SLD styling, but it can be used for handling styles from other sources as well without modification. AFAIK KML has no rule-based styling, but if I'm wrong the OpenLayers.Rule class and its subclasses may also be of interest. Regards, Andreas. On 10/15/07, Cameron Shorter wrote: > Tomorrow, I'd like to get Roald enhancing OpenLayers KML support and > would like to make sure we are not covering old ground. > > Is the KML code in the trunk of Openlayers the most recent, or does > someone have a sandbox with some more development. > > Am I right in understanding that KML styles are not passed by Openlayers > yet? If not, I was thinking this is an issue we would like to look into. > Otherwise, I'm open to suggested alternative KML related development. > Feel free to ping me or Roald on IRC to discuss implementation details. > > -- > Cameron Shorter > Systems Architect, http://lisasoft.com.au > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From andreas.hocevar at gmail.com Mon Oct 15 04:54:35 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Class hierarchy API question Message-ID: <5b021dd0710150154t2238ca4dp7d1a4660e98b47bb@mail.gmail.com> Hi, as you know, we have the OpenLayers.Style class in the ahocevar/sldRenderer sandbox. At the FOSS4G code sprint, we were also talking about some "magic" on how to detect the correct style for a layer automatically. The SLD spec uses "NamedLayer" and "IsDefault", and we could use this as follows: - If there is a layer named "NamedLayer", use the according style. - If there are more styles for "NamedLayer", use the one that is marked true. For this magic, we would probably need some wrapper around the styles hash that is now generated by OpenLayers.Format.SLD.read(). And my question is: where should we put this wrapper class in the API hierarchy? Or should we create no new class at all and do this magic in the OpenLayers.Layer.Vector class? In this case, either a single OpenLayers.Style could be passed to the style property of a vector layer, or a complete hash of OpenLayers.Style. In the latter case, the magic would apply. Please give me some opinion and/or advice on that, so I can start implementing it. Regards, Andreas. From bartvde at osgis.nl Mon Oct 15 05:21:52 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] vector layer and removeLayer Message-ID: <34fbaf0c3ce25bccf396835b74c613a5@145.50.39.11> Hi list, if I do a refresh of my application in Internet Explorer 6, I get a javascript error "invalid argument", which comes from removeLayer. This only happens after drawing a feature in a vector layer. It is also reproducable using the editingtoolbar.html example. Draw a polygon, and press CTRL+F5. I needed to add a null check in Map.js's removeLayer to make this go away: if (layer.div) { this.layerContainerDiv.removeChild(layer.div); } But after this I get length is empty or no object in Util.js's removeItem, so apparently a null array is passed in. I also added a null check there. Next one up, this.features.length is not an object in destroyFeatures of Vector.js, so I added another null check. This resolved it. But maybe as Tim said before on a similar issue, we should investigate the root cause instead of putting in sanity checks ... Using OL 2.5. Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl From jachym.cepicky at gmail.com Mon Oct 15 07:20:07 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups Message-ID: <1192447207.7829.52.camel@mellon> Hi developers, I have implemented ordering map layers into groups [1]. You have to specify new layer attribute group:"Group Name", e.g.: var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", {layers: "rail,road", transparent: "true", format: "image/png" }, { group:"Transit" }); You can define group hierarchy using "/" mark: .... group: "Transit/Roads" .... Only changed file is LayerSwitcher.js For example see [2] Hope, you'll like it Jachym [1] http://trac.openlayers.org/ticket/1086 [2] http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071015/ce4abe78/attachment.bin From lorenzo at ominiverdi.com Mon Oct 15 07:57:22 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <1192447207.7829.52.camel@mellon> References: <1192447207.7829.52.camel@mellon> Message-ID: <471355A2.9040803@ominiverdi.com> Cool Jachym. that's a good idea. It can even represent the complete structure of a WMS GetCapabilites (read: WMS Manager [1]). At the code sprint in Victoria, we where talking with Chris about the possibility to add few features to LayerSwticher. This could be one. other possible attribute wired features: - "buttonDropLayer" : true //activate a button to let the user drop the layer from map and layerSwitcher - "buttonZoom2Extent" : true //show a button to zoom to layer extent - "buttonOpacity" : true //show two buttons change layer opacity - "buttonMoveLayer" : true //show two buttons to move layers up or down in the overlay list (this could collide with your structure) this are the buttons that could apply to all type of layers. button could be just a div where all styles are defined inside the CSS. if you and others agree we can expand your Ticket or make another that can manage all points. Or make a lots of tickets... ciao Lorenzo ps: btw, your patch doesn't work on Safari 2. [1] *http://tinyurl.com/2fjbr7* Jachym Cepicky wrote: > Hi developers, > I have implemented ordering map layers into groups [1]. You have to > specify new layer attribute group:"Group Name", e.g.: > > var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", > "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", > {layers: "rail,road", > transparent: "true", format: "image/png" > }, > { > group:"Transit" > }); > > You can define group hierarchy using "/" mark: > > .... > group: "Transit/Roads" > .... > > Only changed file is LayerSwitcher.js > > For example see [2] > > Hope, you'll like it > > Jachym > > [1] http://trac.openlayers.org/ticket/1086 > [2] > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html > > ------------------------------------------------------------------------ > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From crschmidt at metacarta.com Mon Oct 15 08:49:13 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> Message-ID: <20071015124913.GB1451@metacarta.com> On Mon, Oct 15, 2007 at 10:42:23AM +0200, Andreas Hocevar wrote: > Hi, > > for styling, you should probably take a look at the OpenLayers.Style > class in the ahocevar sandbox. This is the one we use for SLD styling, > but it can be used for handling styles from other sources as well > without modification. AFAIK KML has no rule-based styling, but if I'm > wrong the OpenLayers.Rule class and its subclasses may also be of > interest. I think that it would be acceptable to not worry about OpenLayers.Style until it makes it into trunk: we're going to have to do a lot of churn/transition once it's in, and I don't mind having KML development go the existing path until it gets in, just so we don't have cross-sandbox development (which I hate merging). Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Mon Oct 15 08:53:07 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] vector layer and removeLayer In-Reply-To: <34fbaf0c3ce25bccf396835b74c613a5@145.50.39.11> References: <34fbaf0c3ce25bccf396835b74c613a5@145.50.39.11> Message-ID: <20071015125307.GD1451@metacarta.com> On Mon, Oct 15, 2007 at 11:21:52AM +0200, Bart van den Eijnden (OSGIS) wrote: > Hi list, > > if I do a refresh of my application in Internet Explorer 6, I get a > javascript error "invalid argument", which comes from removeLayer. This only > happens after drawing a feature in a vector layer. This is likely based on the specific HTML you are using. If you could create a reduced test case that demonstrates the problem -- as close to an OpenLayers example as possible -- then the best path forward would be to open a ticket. (Actually, open a ticket either way, but a reduced test case will make it likely to get fixed.) Regards, -- Christopher Schmidt MetaCarta From dmorissette at mapgears.com Mon Oct 15 09:00:52 2007 From: dmorissette at mapgears.com (Daniel Morissette) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Archiving PSC Votes In-Reply-To: <470FCE86.7080807@gmail.com> References: <6ae3fb590710100812m67580041gc4ecdb8cac1cb7f6@mail.gmail.com> <6D21A480-3D48-47AF-BF43-D713A7E2610D@dmsolutions.ca> <470FCE86.7080807@gmail.com> Message-ID: <47136484.7020107@mapgears.com> Cameron Shorter wrote: > I guess there are different levels of importance for things that are > voted on. > For a major design change, or large functionality addition, where > someone is prepared to write up a RFQ to describe it, the extra effort > to record the decision at the bottom of the RFQ is relatively minor. Eg: > "Passed by PSC vote" or "Blocked by Joe Blogs during PSC vote who said > ...". I'm happy with this. > It would be more effort to fill in a table ticking off the votes for the > 15 or so PSC members. While I can see value in this, I don't think the > value outweighs the annoyance factor this will introduce. > For what it's worth, for MapServer, we include a "Voting History" section at the end of each RFC and fill it as follows... takes only a few minutes and gives all the info that we need for the posterity: e.g. http://mapserver.gis.umn.edu/development/rfc/ms-rfc-31#voting-history Voting history +1 from SteveL, SteveW, TomK, FrankW, AssefaY, PericlesN +0 from JeffM > > For minor PSC votes, like "should we release or not", I'm not sure that > this warrants the effort of transcribing from email to wiki table. We do not do much to archive minor PSC votes either. Daniel -- Daniel Morissette http://www.mapgears.com/ From andreas.hocevar at gmail.com Mon Oct 15 09:16:43 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <20071015124913.GB1451@metacarta.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> <20071015124913.GB1451@metacarta.com> Message-ID: <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> Chris, On 10/15/07, Christopher Schmidt wrote: > I think that it would be acceptable to not worry about OpenLayers.Style > until it makes it into trunk: we're going to have to do a lot of > churn/transition once it's in >From my point of view, there is only one open question for the sldRenderer, which I posted to the list earlier today. Once the "apply-style magic" is implemented, I would consider the sldRenderer sandbox ready for review and putting it into trunk after that. Since there are only two places in existing code that are affected by the sldRenderer, I dont't think that there would be too much churn to do. >, and I don't mind having KML development > go the existing path until it gets in, just so we don't have > cross-sandbox development (which I hate merging). This is the one thing. But the other thing is that the OpenLayers.Style class is a good representation for any kind of style information retreived from xml or elsewhere. And IMO it would be a shame if such neat things would have to be developed twice. Regards, Andreas. From crschmidt at metacarta.com Mon Oct 15 09:26:42 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> <20071015124913.GB1451@metacarta.com> <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> Message-ID: <20071015132642.GF1451@metacarta.com> On Mon, Oct 15, 2007 at 03:16:43PM +0200, Andreas Hocevar wrote: > Chris, > > On 10/15/07, Christopher Schmidt wrote: > > I think that it would be acceptable to not worry about OpenLayers.Style > > until it makes it into trunk: we're going to have to do a lot of > > churn/transition once it's in > > From my point of view, there is only one open question for the > sldRenderer, which I posted to the list earlier today. Once the > "apply-style magic" is implemented, I would consider the sldRenderer > sandbox ready for review and putting it into trunk after that. Since > there are only two places in existing code that are affected by the > sldRenderer, I dont't think that there would be too much churn to do. Ah, that's good. I hadn't realized it was so close -- I saw your post, but hadn't responded yet. I'll get on that. The 'churn' I'm talking about is converting existing OpenLayers.Feature.Vector.style stuff to use OpenLayers.Style instead. I feel like there is some significant chunk of this in the code still. I could be wrong though, and this will all be a trivial replacement. > >, and I don't mind having KML development > > go the existing path until it gets in, just so we don't have > > cross-sandbox development (which I hate merging). > > This is the one thing. But the other thing is that the > OpenLayers.Style class is a good representation for any kind of style > information retreived from xml or elsewhere. And IMO it would be a > shame if such neat things would have to be developed twice. Good feedback. Some of this depends on time, I'm sure. My feeling was just that creating an OpenLayers.Style object should be relatively easy once the KML style *parsing* and so on is done -- converting a {'hash':'of styles'} to an OpenLayers.style object is not much more than a find/replace, I don't think, especially if it's done right in the KML code. Regards, -- Christopher Schmidt MetaCarta From andreas.hocevar at gmail.com Mon Oct 15 10:01:22 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <20071015132642.GF1451@metacarta.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> <20071015124913.GB1451@metacarta.com> <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> <20071015132642.GF1451@metacarta.com> Message-ID: <5b021dd0710150701r184b4909x90105c29668374c4@mail.gmail.com> Hi, On 10/15/07, Christopher Schmidt wrote: > On Mon, Oct 15, 2007 at 03:16:43PM +0200, Andreas Hocevar wrote: > > On 10/15/07, Christopher Schmidt wrote: > The 'churn' I'm talking about is converting existing > OpenLayers.Feature.Vector.style stuff to use OpenLayers.Style instead. > I feel like there is some significant chunk of this in the code still. I > could be wrong though, and this will all be a trivial replacement. This is definitely something to pay attention to. I tried to mess with existing OL code as little as possible, so I made the new OpenLayers.Style co-exist with the existing style hashes. In fact, the good old style hash is still the output of OpenLayers.Style.createStyle, which is the only APIMethod of OpenLayers.Style. And the two files ([1] - addFeatures, drawFeature, setStyle and [2] - select) where existing code is changed check for the CLASS_NAME of the style property. If it is "OpenLayers.Class", then the createStyle() method is used to calculate the style for the feature. > Good feedback. Some of this depends on time, I'm sure. My feeling was > just that creating an OpenLayers.Style object should be relatively easy > once the KML style *parsing* and so on is done -- converting a > {'hash':'of styles'} to an OpenLayers.style object is not much more than > a find/replace, I don't think, especially if it's done right in the KML > code. After thinking twice, I would finally say you're right on that. The OpenLayers.Style class in the ahocevar/sldRenderer sandbox is quite simple. The core of the work was indeed the parser and also the rules. For the parser, things probably are a lot different in KML. And for the rules, I think there are none in KML. Regards, Andreas. [1] http://trac.openlayers.org/browser/sandbox/ahocevar/sldRenderer/lib/OpenLayers/Layer/Vector.js [2] http://trac.openlayers.org/browser/sandbox/ahocevar/sldRenderer/lib/OpenLayers/Control/SelectFeature.js From crschmidt at metacarta.com Mon Oct 15 10:41:00 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <5b021dd0710150701r184b4909x90105c29668374c4@mail.gmail.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> <20071015124913.GB1451@metacarta.com> <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> <20071015132642.GF1451@metacarta.com> <5b021dd0710150701r184b4909x90105c29668374c4@mail.gmail.com> Message-ID: <20071015144100.GA15821@metacarta.com> On Mon, Oct 15, 2007 at 04:01:22PM +0200, Andreas Hocevar wrote: > Hi, > > On 10/15/07, Christopher Schmidt wrote: > > On Mon, Oct 15, 2007 at 03:16:43PM +0200, Andreas Hocevar wrote: > > > On 10/15/07, Christopher Schmidt wrote: > > The 'churn' I'm talking about is converting existing > > OpenLayers.Feature.Vector.style stuff to use OpenLayers.Style instead. > > I feel like there is some significant chunk of this in the code still. I > > could be wrong though, and this will all be a trivial replacement. > > This is definitely something to pay attention to. I tried to mess > with existing OL code as little as possible, so I made the new > OpenLayers.Style co-exist with the existing style hashes. In fact, > the good old style hash is still the output of > OpenLayers.Style.createStyle, which is the only APIMethod of > OpenLayers.Style. And the two files ([1] - addFeatures, drawFeature, > setStyle and [2] - select) where existing code is changed check for > the CLASS_NAME of the style property. If it is "OpenLayers.Class", > then the createStyle() method is used to calculate the style for the > feature. Ah, gotcha. Okay, that makes sense -- and also means that there shouldn't be that much churn, but also that if there are no rules involved, there's no reason to not have the KML parser return style objects directly, right? Creating an OpenLayers.Style object is only useful if you're using rules? > > Good feedback. Some of this depends on time, I'm sure. My feeling was > > just that creating an OpenLayers.Style object should be relatively easy > > once the KML style *parsing* and so on is done -- converting a > > {'hash':'of styles'} to an OpenLayers.style object is not much more than > > a find/replace, I don't think, especially if it's done right in the KML > > code. > > After thinking twice, I would finally say you're right on that. The > OpenLayers.Style class in the ahocevar/sldRenderer sandbox is quite > simple. The core of the work was indeed the parser and also the > rules. For the parser, things probably are a lot different in KML. Yep. > And for the rules, I think there are none in KML. Yep. Regards, -- Christopher Schmidt MetaCarta From andreas.hocevar at gmail.com Mon Oct 15 10:53:00 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] KML Styling In-Reply-To: <20071015144100.GA15821@metacarta.com> References: <47130B7F.2040600@gmail.com> <5b021dd0710150142q1a3690b3x93a582c319432484@mail.gmail.com> <20071015124913.GB1451@metacarta.com> <5b021dd0710150616t188f2979vcf47725c07b3a4f0@mail.gmail.com> <20071015132642.GF1451@metacarta.com> <5b021dd0710150701r184b4909x90105c29668374c4@mail.gmail.com> <20071015144100.GA15821@metacarta.com> Message-ID: <5b021dd0710150753y3168c633m164cd166507d5e74@mail.gmail.com> Hi, On 10/15/07, Christopher Schmidt wrote: > Ah, gotcha. Okay, that makes sense -- and also means that there > shouldn't be that much churn, but also that if there are no rules > involved, there's no reason to not have the KML parser return style > objects directly, right? Creating an OpenLayers.Style object is only > useful if you're using rules? Exactly. That's the one thing I did not have in mind when posting to this thread in the first place. My mistake, sorry. Regards, Andreas. From crschmidt at metacarta.com Mon Oct 15 13:12:22 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] javascript keys vs counter In-Reply-To: <20071012161754.GA24305@metacarta.com> References: <20071011120901.GB10193@metacarta.com> <20071011133441.GA19618@metacarta.com> <20071011152448.GA26324@metacarta.com> <20071012120310.7bb9cab8.jake@jpw.biz> <20071012161754.GA24305@metacarta.com> Message-ID: <20071015171222.GB21139@metacarta.com> On Fri, Oct 12, 2007 at 12:17:54PM -0400, Christopher Schmidt wrote: > On Fri, Oct 12, 2007 at 12:03:10PM -0400, Jacob Westfall wrote: > > On Thu, 11 Oct 2007 11:24:48 -0400 > > Christopher Schmidt wrote: > > > for (item in feats) { } > > > > > > will return 0, 1, 2, etc. > > > > > > It's the keys, not the objects, which are returned. > > > > > > However, in general, you should just use the for (i = 0; i < > > > feats.length; i++) types -- there are resources on the web that you can > > > read about why and how, I'm sure, I'm just not up to researching them at > > > the moment :) > > > > Hi, > > I haven't been able to find the resources you mention about this issue. Should I be searching for keys versus counters? Thanks, > Found http://yuiblog.com/blog/2006/09/26/for-in-intrigue/ , which was what I was thinking about. There are a ton of comments on it, which tell a little about what I was thinking about. However, I think in general "Not confusing arrays and objects" would be the right thing to think of this as, and the posts I was thinking about are about other issues. Regards, -- Christopher Schmidt MetaCarta From rohith.kota at uai.com Mon Oct 15 15:13:18 2007 From: rohith.kota at uai.com (rohith) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] vector layer does not draw at lower resolutions. Message-ID: <13219517.post@talk.nabble.com> Here is the code When you run this you will see that vector layer does not draw anything at lower 2 positions of zoom bar. However i have turned on some of the WMS/WFS layer at this resolution and i can see them on the map.What i have found that when u try draw them at lower resolutions u don't see any vector layer but when zoomed out by 2 positions,then you will see all the vector layer images.I'm not sure if it is problem with the vector layer or my resolutions or if any extra settings that is required to draw/display correctly. Any help is really appreciated. thanks rohith -- View this message in context: http://www.nabble.com/vector-layer-does-not-draw-at-lower-resolutions.-tf4629642.html#a13219517 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From cameron.shorter at gmail.com Mon Oct 15 19:32:21 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <471355A2.9040803@ominiverdi.com> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> Message-ID: <4713F885.9060004@gmail.com> Grouping layers has been discussed a few time on the Mapbuilder list, in particular including Grouping in the OWS Spec. It would be good to confirm that your grouping code is consistent with Mapbuilder and OWS Context to ease future integration issues. I think Steven is probably the expert in this area. Lorenzo Becchi wrote: > Cool Jachym. > > that's a good idea. > It can even represent the complete structure of a WMS GetCapabilites > (read: WMS Manager [1]). > > At the code sprint in Victoria, we where talking with Chris about the > possibility to add few features to LayerSwticher. This could be one. > other possible attribute wired features: > - "buttonDropLayer" : true //activate a button to let the user drop the > layer from map and layerSwitcher > - "buttonZoom2Extent" : true //show a button to zoom to layer extent > - "buttonOpacity" : true //show two buttons change layer opacity > - "buttonMoveLayer" : true //show two buttons to move layers up or down > in the overlay list (this could collide with your structure) > > this are the buttons that could apply to all type of layers. > button could be just a div where all styles are defined inside the CSS. > > if you and others agree we can expand your Ticket or make another that > can manage all points. Or make a lots of tickets... > ciao > Lorenzo > > ps: btw, your patch doesn't work on Safari 2. > > [1] *http://tinyurl.com/2fjbr7* > > > > Jachym Cepicky wrote: > >> Hi developers, >> I have implemented ordering map layers into groups [1]. You have to >> specify new layer attribute group:"Group Name", e.g.: >> >> var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", >> "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", >> {layers: "rail,road", >> transparent: "true", format: "image/png" >> }, >> { >> group:"Transit" >> }); >> >> You can define group hierarchy using "/" mark: >> >> .... >> group: "Transit/Roads" >> .... >> >> Only changed file is LayerSwitcher.js >> >> For example see [2] >> >> Hope, you'll like it >> >> Jachym >> >> [1] http://trac.openlayers.org/ticket/1086 >> [2] >> http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From pspencer at dmsolutions.ca Mon Oct 15 21:34:35 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results Message-ID: Hi devs, I finally got around to hacking my jslint support to run across all files in a directory structure rather than just a single file and got these results on trunk: Warnings about missing semi-colons: firebug.js: 3 warnings firebugx.js: 1 warning Ajax.js: 5 warnings Class.js: 5 warnings EditingToolbar.js: 1 warning LayerSwitcher.js: 1 warning MouseDefaults.js: 1 warning MouseToolbar.js: 1 warning PanZoomBar.js: 4 warnings Events.js: 1 warning Vector.js: 1 warning WFS.js: 1 warning GeoJSON.js: 4 warnings WKT.js: 1 warning Polygon.js: 1 warning Drag.js: 3 warnings EventPane.js: 2 warnings Google.js: 2 warnings MultiMap.js: 2 warnings VirtualEarth: 2 warnings Yahoo.js: 2 warnings Layer.js: 1 warning VML.js: 2 warnings Image.js: 1 warning Util.js: 6 warnings Rico/Color.js: 4 warnings Rico/Corner.js: 3 warnings tests/throws.js: 1 warning OpenLayers.js: 1 warning regular expressions should be preceded by a left parenthesis, assignment, colon, or comma if (/MSIE/.test(navigator.userAgent) || /Safari/.test (navigator.userAgent)) { The semi-colon warnings are all trivial and browsers work around them no problem. The only issue can be in compression and I think the compression engine used is smart enough to add a semi-colon where it needs one. However, it would probably be a good idea to fix these warnings anyway. My little tool contains hyperlinks back to the file/ line with the problem so it is trivial albeit time consuming for me to fix them if everyone agrees. The regular expression one I am not so sure about. Anyone know anything about javascript syntax in this particular case? Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From jachym.cepicky at gmail.com Mon Oct 15 13:33:11 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <471355A2.9040803@ominiverdi.com> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> Message-ID: <1192469591.7829.55.camel@mellon> Hi, Lorenzo Becchi p??e v Po 15. 10. 2007 v 13:57 +0200: > - "buttonDropLayer" : true //activate a button to let the user drop the > layer from map and layerSwitcher > - "buttonZoom2Extent" : true //show a button to zoom to layer extent > - "buttonOpacity" : true //show two buttons change layer opacity > - "buttonMoveLayer" : true //show two buttons to move layers up or down > in the overlay list (this could collide with your structure) > I'll try something - everything in patch. > > ps: btw, your patch doesn't work on Safari 2. I'll look at it thanks jachym > > [1] *http://tinyurl.com/2fjbr7* > > > > Jachym Cepicky wrote: > > Hi developers, > > I have implemented ordering map layers into groups [1]. You have to > > specify new layer attribute group:"Group Name", e.g.: > > > > var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", > > "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", > > {layers: "rail,road", > > transparent: "true", format: "image/png" > > }, > > { > > group:"Transit" > > }); > > > > You can define group hierarchy using "/" mark: > > > > .... > > group: "Transit/Roads" > > .... > > > > Only changed file is LayerSwitcher.js > > > > For example see [2] > > > > Hope, you'll like it > > > > Jachym > > > > [1] http://trac.openlayers.org/ticket/1086 > > [2] > > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071015/32b921c6/attachment.bin From laventa147 at yahoo.es Tue Oct 16 04:07:45 2007 From: laventa147 at yahoo.es (victor victor) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 Message-ID: <168094.34445.qm@web23109.mail.ird.yahoo.com> Hi everybody, I am testing OpenLayers 2.5 and I have a problem with events. Let me try to explain: I?ve created my own object that uses OpenLayers. Inside it, I create a new OpenLayers.Marker with its LonLat object and its Icon object (with a png image) then, I register the "mouseover" event as shown below marker.events.register("mouseover", this, this.mouseover); and marker.icon.imageDiv.style.border="1px solid"; in order to see the div bounds. Then I add the marker to the layer. So, when I load the html page in the browser: If IE 6.0 I can see the borders and the marker in the browser, but the this.mouseover function only fires if I do mouseover in the area situated between the borders and the image (not the image itself). If Firefox 2.0 I can see the borders and the marker in the browser, but the this.mouseover function is never fired. Any suggestions, please? Thanks. Javier. ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071016/e2c5ca96/attachment.html From marten.sward at smhi.se Tue Oct 16 05:32:25 2007 From: marten.sward at smhi.se (=?iso-8859-1?Q?Sw=E4rd_M=E5rten?=) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problems with vector in projection epsg:3021 Message-ID: <575A94F91D20704387D1C69A913E95EE010A5B61@CORRE.ad.smhi.se> Hello folks! I've tried to draw a polygon on a map with projection epsg:3021, I've managed to get the polygon to be drawn to the map but the problem is that the shape doesn't show util you relese the mouse button. I guess that the problem is that I have to set the projection (epsg:3021) on something more than just the map and the vector-layer, or..? With the options to DrawFeature you can change the color on the polygon, is it somewhere here to that I should change the projection? Best regards: M?rten -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071016/d987d771/attachment.html From crschmidt at metacarta.com Tue Oct 16 08:07:22 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 In-Reply-To: <168094.34445.qm@web23109.mail.ird.yahoo.com> References: <168094.34445.qm@web23109.mail.ird.yahoo.com> Message-ID: <20071016120722.GA696@metacarta.com> On Tue, Oct 16, 2007 at 08:07:45AM +0000, victor victor wrote: > Hi everybody, > > I am testing OpenLayers 2.5 and I have a problem with events. Let me try to explain: > > I?ve created my own object that uses OpenLayers. > Inside it, I create a new OpenLayers.Marker with its LonLat object and its Icon object (with a png image) > then, I register the "mouseover" event as shown below > > marker.events.register("mouseover", this, this.mouseover); > > and > > marker.icon.imageDiv.style.border="1px solid"; > > in order to see the div bounds. Then I add the marker to the layer. > > So, when I load the html page in the browser: > If IE 6.0 > I can see the borders and the marker in the browser, but the this.mouseover function only fires if I do mouseover in the area situated between the borders and the image (not the image itself). > If Firefox 2.0 > I can see the borders and the marker in the browser, but the this.mouseover function is never fired. What happens if you remove the border? Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Tue Oct 16 08:11:55 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problems with vector in projection epsg:3021 In-Reply-To: <575A94F91D20704387D1C69A913E95EE010A5B61@CORRE.ad.smhi.se> References: <575A94F91D20704387D1C69A913E95EE010A5B61@CORRE.ad.smhi.se> Message-ID: <20071016121155.GB696@metacarta.com> On Tue, Oct 16, 2007 at 11:32:25AM +0200, Sw?rd M?rten wrote: > Hello folks! > I've tried to draw a polygon on a map with projection epsg:3021, I've > managed to get the polygon to be drawn to the map but the problem is > that the shape doesn't show util you relese the mouse button. I guess > that the problem is that I have to set the projection (epsg:3021) on > something more than just the map and the vector-layer, or..? You should only need to set your projection parameters -- maxExtent, maxResolution, and projection -- on the map. (Not your base layer, note.) If this isn't working, sharing HTML may help. Regards, -- Christopher Schmidt MetaCarta From laventa147 at yahoo.es Tue Oct 16 09:38:35 2007 From: laventa147 at yahoo.es (victor victor) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 Message-ID: <222960.48527.qm@web23104.mail.ird.yahoo.com> The same behavior. I only draw the border to define the icon area. I don't know what is happening but the behavior is different with diferent target objects, this is: if I code something like this this.marker.events.register("mouseover", this, this.mouseover); it is different than this one this.marker.events.register("mouseover", this.marker, this.mouseover); In the second case it doesn't work in IE 6.0 neither in Firefox. Thanks. Regards. ----- Mensaje original ---- De: Christopher Schmidt Para: victor victor CC: dev@openlayers.org Enviado: martes, 16 de octubre, 2007 14:07:22 Asunto: Re: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 On Tue, Oct 16, 2007 at 08:07:45AM +0000, victor victor wrote: > Hi everybody, > > I am testing OpenLayers 2.5 and I have a problem with events. Let me try to explain: > > I?ve created my own object that uses OpenLayers. > Inside it, I create a new OpenLayers.Marker with its LonLat object and its Icon object (with a png image) > then, I register the "mouseover" event as shown below > > marker.events.register("mouseover", this, this.mouseover); > > and > > marker.icon.imageDiv.style.border="1px solid"; > > in order to see the div bounds. Then I add the marker to the layer. > > So, when I load the html page in the browser: > If IE 6.0 > I can see the borders and the marker in the browser, but the this.mouseover function only fires if I do mouseover in the area situated between the borders and the image (not the image itself). > If Firefox 2.0 > I can see the borders and the marker in the browser, but the this.mouseover function is never fired. What happens if you remove the border? Regards, -- Christopher Schmidt MetaCarta ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071016/826a1b17/attachment.html From crschmidt at metacarta.com Tue Oct 16 09:44:45 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 In-Reply-To: <222960.48527.qm@web23104.mail.ird.yahoo.com> References: <222960.48527.qm@web23104.mail.ird.yahoo.com> Message-ID: <20071016134445.GA13093@metacarta.com> On Tue, Oct 16, 2007 at 01:38:35PM +0000, victor victor wrote: > The same behavior. I only draw the border to define the icon area. I don't > know what is happening but the behavior is different with diferent target objects, this is: > > if I code something like this > this.marker.events.register("mouseover", this, > this.mouseover); > it is different than this one > > this.marker.events.register("mouseover", this.marker, > this.mouseover); > > In the second case it doesn't work in IE 6.0 neither in Firefox. Well, I don't know what 'doesn't work' means -- the difference between these is that in the latter case, the 'this' inside this.mouseover is different, so you might be getting an error thrown because some property used inside this.mouseover doesn't exist... Check your error console? Get Firebug, and put a console.log() inside this.mouseover to see if it's working? Regards, -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Tue Oct 16 11:11:56 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <471355A2.9040803@ominiverdi.com> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> Message-ID: <1192547516.7884.16.camel@mellon> Hi, implemented. Everything in one patch [1], for examples see [2] and [3], see ticket #1086 [4] for details Jachym [1] http://trac.openlayers.org/attachment/ticket/1086/LayerSwitcher.js.diff [2] http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-buttons.html [3] http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html [4] http://trac.openlayers.org/ticket/1086 Lorenzo Becchi p??e v Po 15. 10. 2007 v 13:57 +0200: > Cool Jachym. > > that's a good idea. > It can even represent the complete structure of a WMS GetCapabilites > (read: WMS Manager [1]). > > At the code sprint in Victoria, we where talking with Chris about the > possibility to add few features to LayerSwticher. This could be one. > other possible attribute wired features: > - "buttonDropLayer" : true //activate a button to let the user drop the > layer from map and layerSwitcher > - "buttonZoom2Extent" : true //show a button to zoom to layer extent > - "buttonOpacity" : true //show two buttons change layer opacity > - "buttonMoveLayer" : true //show two buttons to move layers up or down > in the overlay list (this could collide with your structure) > > this are the buttons that could apply to all type of layers. > button could be just a div where all styles are defined inside the CSS. > > if you and others agree we can expand your Ticket or make another that > can manage all points. Or make a lots of tickets... > ciao > Lorenzo > > ps: btw, your patch doesn't work on Safari 2. > > [1] *http://tinyurl.com/2fjbr7* > > > > Jachym Cepicky wrote: > > Hi developers, > > I have implemented ordering map layers into groups [1]. You have to > > specify new layer attribute group:"Group Name", e.g.: > > > > var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", > > "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", > > {layers: "rail,road", > > transparent: "true", format: "image/png" > > }, > > { > > group:"Transit" > > }); > > > > You can define group hierarchy using "/" mark: > > > > .... > > group: "Transit/Roads" > > .... > > > > Only changed file is LayerSwitcher.js > > > > For example see [2] > > > > Hope, you'll like it > > > > Jachym > > > > [1] http://trac.openlayers.org/ticket/1086 > > [2] > > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071016/26f27df2/attachment.bin From laventa147 at yahoo.es Tue Oct 16 12:19:41 2007 From: laventa147 at yahoo.es (victor victor) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 Message-ID: <681019.14675.qm@web23112.mail.ird.yahoo.com> I'm sorry, it wasn't a problem of OpenLayers, it was a problem of my code. I am going to keep testing OpenLayers and the next time I'll try to ensure that it is not my problem ;-) Best regads. ----- Mensaje original ---- De: Christopher Schmidt Para: victor victor CC: dev@openlayers.org Enviado: martes, 16 de octubre, 2007 15:44:45 Asunto: Re: [OpenLayers-Dev] Problem with events in OpenLayers 2.5 On Tue, Oct 16, 2007 at 01:38:35PM +0000, victor victor wrote: > The same behavior. I only draw the border to define the icon area. I don't > know what is happening but the behavior is different with diferent target objects, this is: > > if I code something like this > this.marker.events.register("mouseover", this, > this.mouseover); > it is different than this one > > this.marker.events.register("mouseover", this.marker, > this.mouseover); > > In the second case it doesn't work in IE 6.0 neither in Firefox. Well, I don't know what 'doesn't work' means -- the difference between these is that in the latter case, the 'this' inside this.mouseover is different, so you might be getting an error thrown because some property used inside this.mouseover doesn't exist... Check your error console? Get Firebug, and put a console.log() inside this.mouseover to see if it's working? Regards, -- Christopher Schmidt MetaCarta ____________________________________________________________________________________ S? un Mejor Amante del Cine ?Quieres saber c?mo? ?Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071016/c731e537/attachment.html From tschaub at openplans.org Tue Oct 16 13:17:41 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: References: Message-ID: <4714F235.4050700@openplans.org> Hey - Paul Spencer wrote: > > The semi-colon warnings are all trivial and browsers work around them > no problem. The only issue can be in compression and I think the > compression engine used is smart enough to add a semi-colon where it > needs one. However, it would probably be a good idea to fix these > warnings anyway. My little tool contains hyperlinks back to the file/ > line with the problem so it is trivial albeit time consuming for me > to fix them if everyone agrees. > Thanks for getting a start on this. Would be good to have this integrated into our tests in some manner. (Not integrated into test another way - just as part of the testing procedure.) > The regular expression one I am not so sure about. Anyone know > anything about javascript syntax in this particular case? > Regarding the regular expression in OpenLayers.js, that condition can just be wrapped in parentheses. More importantly, it should be rewritten entirely. No reason to do regex tests there (string match is sufficient), and certainly no reason to do the test in every iteration of the loop (yikes). See the patch for #1092 [1]. Tim [1] http://trac.openlayers.org/ticket/1092 > Cheers > > Paul > > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,4714153753634901796417! > From dc at openapp.ie Tue Oct 16 13:50:37 2007 From: dc at openapp.ie (david creane) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] text rendering in svg and vml Message-ID: <200710161850.37646.dc@openapp.ie> I was wondering is anyone working on gettting text rendering on the map working. I heard camptocamp were either working on it or looking at it. If someone is working on it i would be glad to help. From erik.uzureau at metacarta.com Tue Oct 16 13:57:32 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: References: Message-ID: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> On 10/15/07, Paul Spencer wrote: > Hi devs, > > I finally got around to hacking my jslint support to run across all > files in a directory structure rather than just a single file and got > these results on trunk: > > Warnings about missing semi-colons: > > firebug.js: 3 warnings > firebugx.js: 1 warning > Ajax.js: 5 warnings > Class.js: 5 warnings > EditingToolbar.js: 1 warning > LayerSwitcher.js: 1 warning > MouseDefaults.js: 1 warning > MouseToolbar.js: 1 warning > PanZoomBar.js: 4 warnings > Events.js: 1 warning > Vector.js: 1 warning > WFS.js: 1 warning > GeoJSON.js: 4 warnings > WKT.js: 1 warning > Polygon.js: 1 warning > Drag.js: 3 warnings > EventPane.js: 2 warnings > Google.js: 2 warnings > MultiMap.js: 2 warnings > VirtualEarth: 2 warnings > Yahoo.js: 2 warnings > Layer.js: 1 warning > VML.js: 2 warnings > Image.js: 1 warning > Util.js: 6 warnings > Rico/Color.js: 4 warnings > Rico/Corner.js: 3 warnings > tests/throws.js: 1 warning > > OpenLayers.js: 1 warning regular expressions should be preceded by a > left parenthesis, assignment, colon, or comma > if (/MSIE/.test(navigator.userAgent) || /Safari/.test > (navigator.userAgent)) { > > The semi-colon warnings are all trivial and browsers work around them > no problem. The only issue can be in compression and I think the > compression engine used is smart enough to add a semi-colon where it > needs one. However, it would probably be a good idea to fix these > warnings anyway. My little tool contains hyperlinks back to the file/ > line with the problem so it is trivial albeit time consuming for me > to fix them if everyone agrees. As a core committer, you should feel free to make these changes as you see fit. OpenLayers has a (somewhat unstated) policy that non-functional patches need not go through the standard ticket/approval system. ...which means that if you want to replace a missing semicolon or tab out a line or add a comment or something like that, you should just go ahead and do it. As long as it doesn't change the functioning of the code. Erik ps. thanks so much for taking the time to run this analysis. Looks like our code has not a few little oversights! > The regular expression one I am not so sure about. Anyone know > anything about javascript syntax in this particular case? > > Cheers > > Paul > > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From pspencer at dmsolutions.ca Tue Oct 16 14:31:01 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> References: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> Message-ID: <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> Thanks Erik. Before I go ahead and make a bunch of changes, though, I'd like some feedback on how pedantic we should be about certain coding practices. I'd like feedback from the core devs on the following things: 1) use of semi-colons Should we care about certain edge cases, such as: var f = function(){return true}; will say that you need a semi-colon after true (inside the block scope of the function) 2) use of curly braces around block scope Should we care about one line cases and implied scope, such as: if (this.singleLayer) return; for (var i=0; i > As a core committer, you should feel free to make these changes as you > see fit. OpenLayers has a (somewhat unstated) policy that > non-functional patches need not go through the standard > ticket/approval system. > > ...which means that if you want to replace a missing semicolon or tab > out a line or add a comment or something like that, you should just go > ahead and do it. As long as it doesn't change the functioning of the > code. > > Erik > > ps. thanks so much for taking the time to run this analysis. Looks > like our code has not a few little oversights! > > >> The regular expression one I am not so sure about. Anyone know >> anything about javascript syntax in this particular case? >> >> Cheers >> >> Paul >> >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From erik.uzureau at metacarta.com Tue Oct 16 14:51:42 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> References: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> Message-ID: <6ae3fb590710161151qf6d730ag4a7cb1071aa7e43e@mail.gmail.com> Dear Paul, I approve of each and every one of the numbered resolutions you suggest herebelow. They will all contribute to a more standardized, consistent, readable codebase. You have my +1 Erik On 10/16/07, Paul Spencer wrote: > Thanks Erik. Before I go ahead and make a bunch of changes, though, > I'd like some feedback on how pedantic we should be about certain > coding practices. I'd like feedback from the core devs on the > following things: > > 1) use of semi-colons > > Should we care about certain edge cases, such as: > > var f = function(){return true}; > > will say that you need a semi-colon after true (inside the block > scope of the function) > > 2) use of curly braces around block scope > > Should we care about one line cases and implied scope, such as: > > if (this.singleLayer) return; > > for (var i=0; i if (this.grid[i].length) { > } > > 3) unreachable code > > function foo() { > return true; > var test = 1; > } > > 4) missing break statements, missing break in last case of switch > > 5) leading or trailing decimal points > > .000 > > 000. > > 6) nested comments > > /**************** > /* comment > /****************/ > > There are quite a few more options that can be used too, but are > disabled by default because they have more of an impact on coding style. > > I personally like the ones above because they are situations that can > lead to erroneous code in a multi-developer environment. > > I am also not advocating that we fix every warning that comes out of > the tool, but rather that it can help us focus on specific potential > problem areas - i.e. not using break statements in a switch is a > reasonable technique in some instances. > > Please give me feedback on whether you want me to vet the code for > the above issues or not. I will make a single commit with all the > changes on the current trunk once it is decided what we should or > shouldn't include. Thereafter, I will check trunk occasionally, > especially before we cut a release, and do touch ups as required. > > Cheers > > Paul > > > > > As a core committer, you should feel free to make these changes as you > > see fit. OpenLayers has a (somewhat unstated) policy that > > non-functional patches need not go through the standard > > ticket/approval system. > > > > ...which means that if you want to replace a missing semicolon or tab > > out a line or add a comment or something like that, you should just go > > ahead and do it. As long as it doesn't change the functioning of the > > code. > > > > Erik > > > > ps. thanks so much for taking the time to run this analysis. Looks > > like our code has not a few little oversights! > > > > > >> The regular expression one I am not so sure about. Anyone know > >> anything about javascript syntax in this particular case? > >> > >> Cheers > >> > >> Paul > >> > >> > >> +-----------------------------------------------------------------+ > >> |Paul Spencer pspencer@dmsolutions.ca | > >> +-----------------------------------------------------------------+ > >> |Chief Technology Officer | > >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | > >> +-----------------------------------------------------------------+ > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Dev mailing list > >> Dev@openlayers.org > >> http://openlayers.org/mailman/listinfo/dev > >> > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > From erik.uzureau at metacarta.com Tue Oct 16 14:52:32 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: <6ae3fb590710161151qf6d730ag4a7cb1071aa7e43e@mail.gmail.com> References: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> <6ae3fb590710161151qf6d730ag4a7cb1071aa7e43e@mail.gmail.com> Message-ID: <6ae3fb590710161152l692f2f3cj622ae9f8a4306f2b@mail.gmail.com> Also, It would probably be good to somehow incorporate these into: http://trac.openlayers.org/wiki/CodingStandards e On 10/16/07, Erik Uzureau wrote: > Dear Paul, > > I approve of each and every one of the numbered resolutions you > suggest herebelow. They will all contribute to a more standardized, > consistent, readable codebase. > > You have my +1 > Erik > > On 10/16/07, Paul Spencer wrote: > > Thanks Erik. Before I go ahead and make a bunch of changes, though, > > I'd like some feedback on how pedantic we should be about certain > > coding practices. I'd like feedback from the core devs on the > > following things: > > > > 1) use of semi-colons > > > > Should we care about certain edge cases, such as: > > > > var f = function(){return true}; > > > > will say that you need a semi-colon after true (inside the block > > scope of the function) > > > > 2) use of curly braces around block scope > > > > Should we care about one line cases and implied scope, such as: > > > > if (this.singleLayer) return; > > > > for (var i=0; i > if (this.grid[i].length) { > > } > > > > 3) unreachable code > > > > function foo() { > > return true; > > var test = 1; > > } > > > > 4) missing break statements, missing break in last case of switch > > > > 5) leading or trailing decimal points > > > > .000 > > > > 000. > > > > 6) nested comments > > > > /**************** > > /* comment > > /****************/ > > > > There are quite a few more options that can be used too, but are > > disabled by default because they have more of an impact on coding style. > > > > I personally like the ones above because they are situations that can > > lead to erroneous code in a multi-developer environment. > > > > I am also not advocating that we fix every warning that comes out of > > the tool, but rather that it can help us focus on specific potential > > problem areas - i.e. not using break statements in a switch is a > > reasonable technique in some instances. > > > > Please give me feedback on whether you want me to vet the code for > > the above issues or not. I will make a single commit with all the > > changes on the current trunk once it is decided what we should or > > shouldn't include. Thereafter, I will check trunk occasionally, > > especially before we cut a release, and do touch ups as required. > > > > Cheers > > > > Paul > > > > > > > > As a core committer, you should feel free to make these changes as you > > > see fit. OpenLayers has a (somewhat unstated) policy that > > > non-functional patches need not go through the standard > > > ticket/approval system. > > > > > > ...which means that if you want to replace a missing semicolon or tab > > > out a line or add a comment or something like that, you should just go > > > ahead and do it. As long as it doesn't change the functioning of the > > > code. > > > > > > Erik > > > > > > ps. thanks so much for taking the time to run this analysis. Looks > > > like our code has not a few little oversights! > > > > > > > > >> The regular expression one I am not so sure about. Anyone know > > >> anything about javascript syntax in this particular case? > > >> > > >> Cheers > > >> > > >> Paul > > >> > > >> > > >> +-----------------------------------------------------------------+ > > >> |Paul Spencer pspencer@dmsolutions.ca | > > >> +-----------------------------------------------------------------+ > > >> |Chief Technology Officer | > > >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | > > >> +-----------------------------------------------------------------+ > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Dev mailing list > > >> Dev@openlayers.org > > >> http://openlayers.org/mailman/listinfo/dev > > >> > > > > +-----------------------------------------------------------------+ > > |Paul Spencer pspencer@dmsolutions.ca | > > +-----------------------------------------------------------------+ > > |Chief Technology Officer | > > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > > +-----------------------------------------------------------------+ > > > > > > > > > > > > > From tschaub at openplans.org Tue Oct 16 16:59:53 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: <6ae3fb590710161151qf6d730ag4a7cb1071aa7e43e@mail.gmail.com> References: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> <6ae3fb590710161151qf6d730ag4a7cb1071aa7e43e@mail.gmail.com> Message-ID: <47152649.7030004@openplans.org> Agreed. These are all good practices. I'd be glad to see them become part of our coding standards. Tim Erik Uzureau wrote: > Dear Paul, > > I approve of each and every one of the numbered resolutions you > suggest herebelow. They will all contribute to a more standardized, > consistent, readable codebase. > > You have my +1 > Erik > > On 10/16/07, Paul Spencer wrote: >> Thanks Erik. Before I go ahead and make a bunch of changes, though, >> I'd like some feedback on how pedantic we should be about certain >> coding practices. I'd like feedback from the core devs on the >> following things: >> >> 1) use of semi-colons >> >> Should we care about certain edge cases, such as: >> >> var f = function(){return true}; >> >> will say that you need a semi-colon after true (inside the block >> scope of the function) >> >> 2) use of curly braces around block scope >> >> Should we care about one line cases and implied scope, such as: >> >> if (this.singleLayer) return; >> >> for (var i=0; i> if (this.grid[i].length) { >> } >> >> 3) unreachable code >> >> function foo() { >> return true; >> var test = 1; >> } >> >> 4) missing break statements, missing break in last case of switch >> >> 5) leading or trailing decimal points >> >> .000 >> >> 000. >> >> 6) nested comments >> >> /**************** >> /* comment >> /****************/ >> >> There are quite a few more options that can be used too, but are >> disabled by default because they have more of an impact on coding style. >> >> I personally like the ones above because they are situations that can >> lead to erroneous code in a multi-developer environment. >> >> I am also not advocating that we fix every warning that comes out of >> the tool, but rather that it can help us focus on specific potential >> problem areas - i.e. not using break statements in a switch is a >> reasonable technique in some instances. >> >> Please give me feedback on whether you want me to vet the code for >> the above issues or not. I will make a single commit with all the >> changes on the current trunk once it is decided what we should or >> shouldn't include. Thereafter, I will check trunk occasionally, >> especially before we cut a release, and do touch ups as required. >> >> Cheers >> >> Paul >> >>> As a core committer, you should feel free to make these changes as you >>> see fit. OpenLayers has a (somewhat unstated) policy that >>> non-functional patches need not go through the standard >>> ticket/approval system. >>> >>> ...which means that if you want to replace a missing semicolon or tab >>> out a line or add a comment or something like that, you should just go >>> ahead and do it. As long as it doesn't change the functioning of the >>> code. >>> >>> Erik >>> >>> ps. thanks so much for taking the time to run this analysis. Looks >>> like our code has not a few little oversights! >>> >>> >>>> The regular expression one I am not so sure about. Anyone know >>>> anything about javascript syntax in this particular case? >>>> >>>> Cheers >>>> >>>> Paul >>>> >>>> >>>> +-----------------------------------------------------------------+ >>>> |Paul Spencer pspencer@dmsolutions.ca | >>>> +-----------------------------------------------------------------+ >>>> |Chief Technology Officer | >>>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>>> +-----------------------------------------------------------------+ >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@openlayers.org >>>> http://openlayers.org/mailman/listinfo/dev >>>> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,47150847104772085621377! > From rdewit at users.sourceforge.net Tue Oct 16 21:58:17 2007 From: rdewit at users.sourceforge.net (Roald de Wit) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. Message-ID: <1192586297.6651.17.camel@bender> Hi List, Before I create a patch, I'd like to discuss the following issue. We found out that it takes IE (6 & 7) a long time to draw a linestring consisting of many coordinates (3000+). A little investigation in Renderer/VML.js (drawLine) showed that the biggest slowdown was the concatenation of the 'path' string. I managed to reduce the time to create the path string dramatically from 40+ seconds to 1 second by mimicking a StringBuffer (put path string pieces in array and join them in the end). So, in short, this: path += " " + x.toFixed() + "," + y.toFixed() + " l "; is replaced with this: path.push( " " + x.toFixed() + "," + y.toFixed() + " l "); The same slowdown most probably applies to the other drawing methods in this class. My question is: what would be the best way to tackle this? Suggested option: - create a OpenLayers.Util.StringBuffer object (with append and toString methods) - create a 'path' object that extends StringBuffer that will be used by VML.js and possibly SVG.js I also added a few other optimisations (will put more of that in the ticket created for this: #1095). Any suggestions? Greetings, Roald From crschmidt at metacarta.com Tue Oct 16 22:09:33 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. In-Reply-To: <1192586297.6651.17.camel@bender> References: <1192586297.6651.17.camel@bender> Message-ID: <20071017020933.GA28476@metacarta.com> On Wed, Oct 17, 2007 at 11:58:17AM +1000, Roald de Wit wrote: > The same slowdown most probably applies to the other drawing methods in > this class. > > My question is: what would be the best way to tackle this? Interesting. I'd always followed the type of behavior you're suggsting in Python, but had never known it was needed in JS. (It's always bugged me that we just shoved strings together in Javascript, but it seemed like everyone did it, so I didn't question.) The typical way I do this in Python is to just do the equivilant of: var stringList = []; for (var i = 0; i < 10000; i++) { stringList.push('foo'); } var string = stringList.join(""); I think we can even skip the .join("") and use .toString() in JS, but I have no idea how portable that is, and it feels slightly hacky. So, I don't see any need for a stringBuffer object, since it would just be an array (with 'push' replaced with 'append'). With these performance numbers in hand, I think that migrating any significant use of string concatanation -- which I think only includes the renderers, and maybe things like getParameterString -- to be array based makes sense, and I'm in support of that path. It probably makes sense to write at least basic tests for the renderer functionality before proceeding with this, to ensure that it doesn't break with the new code in any way that we can be aware of ahead of time. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Tue Oct 16 23:57:15 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. In-Reply-To: <20071017020933.GA28476@metacarta.com> References: <1192586297.6651.17.camel@bender> <20071017020933.GA28476@metacarta.com> Message-ID: <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> On 10/16/07, Christopher Schmidt wrote: > On Wed, Oct 17, 2007 at 11:58:17AM +1000, Roald de Wit wrote: > > The same slowdown most probably applies to the other drawing methods in > > this class. > > > > My question is: what would be the best way to tackle this? > > Interesting. I'd always followed the type of behavior you're suggsting > in Python, but had never known it was needed in JS. (It's always bugged > me that we just shoved strings together in Javascript, but it seemed > like everyone did it, so I didn't question.) > > The typical way I do this in Python is to just do the equivilant of: > > var stringList = []; > for (var i = 0; i < 10000; i++) { stringList.push('foo'); } > var string = stringList.join(""); > > I think we can even skip the .join("") and use .toString() in JS, but I > have no idea how portable that is, and it feels slightly hacky. > > So, I don't see any need for a stringBuffer object, since it would just > be an array (with 'push' replaced with 'append'). > > With these performance numbers in hand, I think that migrating any > significant use of string concatanation -- which I think only includes > the renderers, and maybe things like getParameterString -- to be array > based makes sense, and I'm in support of that path. It probably makes > sense to write at least basic tests for the renderer functionality > before proceeding with this, to ensure that it doesn't break with the > new code in any way that we can be aware of ahead of time. Wow. Cool trick. Can't see where else in the OL code it would make much of a difference other than: -GeoRSS parseData() -- 197 - BaseTypes String camelize -- 87 how many times is getParameterString() called? e > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Tue Oct 16 23:57:56 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. In-Reply-To: <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> References: <1192586297.6651.17.camel@bender> <20071017020933.GA28476@metacarta.com> <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> Message-ID: <6ae3fb590710162057q5dcfaef8t67547343c9d29083@mail.gmail.com> ps. has someone made a patch for this? sounds like something we shouldn't let slip through the cracks. On 10/16/07, Erik Uzureau wrote: > On 10/16/07, Christopher Schmidt wrote: > > On Wed, Oct 17, 2007 at 11:58:17AM +1000, Roald de Wit wrote: > > > The same slowdown most probably applies to the other drawing methods in > > > this class. > > > > > > My question is: what would be the best way to tackle this? > > > > Interesting. I'd always followed the type of behavior you're suggsting > > in Python, but had never known it was needed in JS. (It's always bugged > > me that we just shoved strings together in Javascript, but it seemed > > like everyone did it, so I didn't question.) > > > > The typical way I do this in Python is to just do the equivilant of: > > > > var stringList = []; > > for (var i = 0; i < 10000; i++) { stringList.push('foo'); } > > var string = stringList.join(""); > > > > I think we can even skip the .join("") and use .toString() in JS, but I > > have no idea how portable that is, and it feels slightly hacky. > > > > So, I don't see any need for a stringBuffer object, since it would just > > be an array (with 'push' replaced with 'append'). > > > > With these performance numbers in hand, I think that migrating any > > significant use of string concatanation -- which I think only includes > > the renderers, and maybe things like getParameterString -- to be array > > based makes sense, and I'm in support of that path. It probably makes > > sense to write at least basic tests for the renderer functionality > > before proceeding with this, to ensure that it doesn't break with the > > new code in any way that we can be aware of ahead of time. > > Wow. Cool trick. Can't see where else in the OL code it would make > much of a difference other than: > > -GeoRSS parseData() -- 197 > - BaseTypes String camelize -- 87 > > how many times is getParameterString() called? > > e > > > > > > > Regards, > > -- > > Christopher Schmidt > > MetaCarta > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > From eric.c2c at gmail.com Wed Oct 17 00:16:09 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint results In-Reply-To: <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> References: <6ae3fb590710161057q5e641e5n7c45231d1ad9ee6d@mail.gmail.com> <1F1ACED1-A3B2-436B-925F-C56A2B675064@dmsolutions.ca> Message-ID: <5ec103de0710162116u6f345dbr2763363ec0e78f4d@mail.gmail.com> On 10/16/07, Paul Spencer wrote: > [...] > 1) use of semi-colons > > Should we care about certain edge cases, such as: > > var f = function(){return true}; > > will say that you need a semi-colon after true (inside the block > scope of the function) > > 2) use of curly braces around block scope > > Should we care about one line cases and implied scope, such as: > > if (this.singleLayer) return; > > for (var i=0; i if (this.grid[i].length) { > } > > 3) unreachable code > > function foo() { > return true; > var test = 1; > } > > 4) missing break statements, missing break in last case of switch > > 5) leading or trailing decimal points > > .000 > > 000. > > 6) nested comments > > /**************** > /* comment > /****************/ Hi Paul Except the trailing decimal points stuff which I think isn't a big deal at all, the mentioned checks make lots of sense to me. Thanks a lot for taking the time to get started with jslint. -- Eric From erik.uzureau at metacarta.com Wed Oct 17 04:00:31 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory Message-ID: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> Since Se?or Schmidt has been so good about carrying the new ClearBSD license forward[1], the time has come once again to talk about the idea of an Addins directory. The idea behind Addins is to create a space in the OpenLayers repository where we can put layers, controls, and other OpenLayers related projects that don't quite belong in the core distribution of the library, but that people might find useful. The hope with Addins is that it will be a fertile ground for people to show off tricks and gadgets they've built that do cool things with OpenLayers and that they're interested to give back to the community. Off the top of my head, a couple of specific projects seem like worthy candidates: * WMS Manager (getCapabilities-enhanced layerswitcher tool) * Generally Improved LayerSwitcher (grouping, dragging-to-reorder) * Driving Directions library (code that works with OLS or pgRouting to request and display routing information on an OpenLayers Map) I'm sure there are many other projects that could qualify. It is important to distinguish between the sandboxes and the Addins directory. The former is a playground for people to experiment. The code is not covered by any license and is indeed in a sort of "free-for-all" state. The latter, however, will be exclusively for established projects interested in a more formal release process. Code in the Addins directory will be covered under the ClearBSD license, and tags will be made for compatibility with different OL versions. A proposed directory structure might look something like this: /sandbox /branches /trunk /trunk/openlayers /trunk/addins /tags/openlayers /tags/addins Please let me know what you think of this proposal, and if you think you have a project that you would be interested in releasing in the Addins directory. Cheers, boa noite, Erik [1] http://trac.openlayers.org/changeset/4985 From steven at minst.net Wed Oct 17 05:23:01 2007 From: steven at minst.net (Steven M. Ottens) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <4713F885.9060004@gmail.com> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> Message-ID: <4715D475.4080409@minst.net> The mapbuilder code uses //wmc:ResourceList/wmc:Layer[wmc:Extension/wmc:Group/@name=$GroupName] So this means that it selects the layers which have a group-extension. I believe the structure is hierarchical, so using group/layer approach should be consistent with the OWS spec. But I'm not the real expert, I though gertjan did the grouping code, but could be wrong. Steven Cameron Shorter wrote: > Grouping layers has been discussed a few time on the Mapbuilder list, in > particular including Grouping in the OWS Spec. > It would be good to confirm that your grouping code is consistent with > Mapbuilder and OWS Context to ease future integration issues. > I think Steven is probably the expert in this area. > > Lorenzo Becchi wrote: > >> Cool Jachym. >> >> that's a good idea. >> It can even represent the complete structure of a WMS GetCapabilites >> (read: WMS Manager [1]). >> >> At the code sprint in Victoria, we where talking with Chris about the >> possibility to add few features to LayerSwticher. This could be one. >> other possible attribute wired features: >> - "buttonDropLayer" : true //activate a button to let the user drop the >> layer from map and layerSwitcher >> - "buttonZoom2Extent" : true //show a button to zoom to layer extent >> - "buttonOpacity" : true //show two buttons change layer opacity >> - "buttonMoveLayer" : true //show two buttons to move layers up or down >> in the overlay list (this could collide with your structure) >> >> this are the buttons that could apply to all type of layers. >> button could be just a div where all styles are defined inside the CSS. >> >> if you and others agree we can expand your Ticket or make another that >> can manage all points. Or make a lots of tickets... >> ciao >> Lorenzo >> >> ps: btw, your patch doesn't work on Safari 2. >> >> [1] *http://tinyurl.com/2fjbr7* >> >> >> >> Jachym Cepicky wrote: >> >> >>> Hi developers, >>> I have implemented ordering map layers into groups [1]. You have to >>> specify new layer attribute group:"Group Name", e.g.: >>> >>> var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", >>> "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", >>> {layers: "rail,road", >>> transparent: "true", format: "image/png" >>> }, >>> { >>> group:"Transit" >>> }); >>> >>> You can define group hierarchy using "/" mark: >>> >>> .... >>> group: "Transit/Roads" >>> .... >>> >>> Only changed file is LayerSwitcher.js >>> >>> For example see [2] >>> >>> Hope, you'll like it >>> >>> Jachym >>> >>> [1] http://trac.openlayers.org/ticket/1086 >>> [2] >>> http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@openlayers.org >>> http://openlayers.org/mailman/listinfo/dev >>> >>> >>> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> >> >> > > > From jachym.cepicky at gmail.com Wed Oct 17 05:54:25 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <4715D475.4080409@minst.net> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> <4715D475.4080409@minst.net> Message-ID: <1192614865.7994.10.camel@mellon> Hi, sorry, I do not see your point: I want the layers grouped in LayerSwitcher. The simplest way how to do it, is to specify the group name group: "Group" and using Group hierarchy group: "Parent/Child" everything happens while new OpenLayers.Layer.* is defined jachym Steven M. Ottens p??e v St 17. 10. 2007 v 11:23 +0200: > The mapbuilder code uses > //wmc:ResourceList/wmc:Layer[wmc:Extension/wmc:Group/@name=$GroupName] > So this means that it selects the layers which have a group-extension. I > believe the structure is hierarchical, so using group/layer approach > should be consistent with the OWS spec. > But I'm not the real expert, I though gertjan did the grouping code, but > could be wrong. > > Steven > > Cameron Shorter wrote: > > Grouping layers has been discussed a few time on the Mapbuilder list, in > > particular including Grouping in the OWS Spec. > > It would be good to confirm that your grouping code is consistent with > > Mapbuilder and OWS Context to ease future integration issues. > > I think Steven is probably the expert in this area. > > > > Lorenzo Becchi wrote: > > > >> Cool Jachym. > >> > >> that's a good idea. > >> It can even represent the complete structure of a WMS GetCapabilites > >> (read: WMS Manager [1]). > >> > >> At the code sprint in Victoria, we where talking with Chris about the > >> possibility to add few features to LayerSwticher. This could be one. > >> other possible attribute wired features: > >> - "buttonDropLayer" : true //activate a button to let the user drop the > >> layer from map and layerSwitcher > >> - "buttonZoom2Extent" : true //show a button to zoom to layer extent > >> - "buttonOpacity" : true //show two buttons change layer opacity > >> - "buttonMoveLayer" : true //show two buttons to move layers up or down > >> in the overlay list (this could collide with your structure) > >> > >> this are the buttons that could apply to all type of layers. > >> button could be just a div where all styles are defined inside the CSS. > >> > >> if you and others agree we can expand your Ticket or make another that > >> can manage all points. Or make a lots of tickets... > >> ciao > >> Lorenzo > >> > >> ps: btw, your patch doesn't work on Safari 2. > >> > >> [1] *http://tinyurl.com/2fjbr7* > >> > >> > >> > >> Jachym Cepicky wrote: > >> > >> > >>> Hi developers, > >>> I have implemented ordering map layers into groups [1]. You have to > >>> specify new layer attribute group:"Group Name", e.g.: > >>> > >>> var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", > >>> "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", > >>> {layers: "rail,road", > >>> transparent: "true", format: "image/png" > >>> }, > >>> { > >>> group:"Transit" > >>> }); > >>> > >>> You can define group hierarchy using "/" mark: > >>> > >>> .... > >>> group: "Transit/Roads" > >>> .... > >>> > >>> Only changed file is LayerSwitcher.js > >>> > >>> For example see [2] > >>> > >>> Hope, you'll like it > >>> > >>> Jachym > >>> > >>> [1] http://trac.openlayers.org/ticket/1086 > >>> [2] > >>> http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Dev mailing list > >>> Dev@openlayers.org > >>> http://openlayers.org/mailman/listinfo/dev > >>> > >>> > >>> > >> _______________________________________________ > >> Dev mailing list > >> Dev@openlayers.org > >> http://openlayers.org/mailman/listinfo/dev > >> > >> > >> > > > > > > > > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071017/e47c223c/attachment.bin From steven at minst.net Wed Oct 17 06:16:55 2007 From: steven at minst.net (Steven M. Ottens) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <1192614865.7994.10.camel@mellon> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> <4715D475.4080409@minst.net> <1192614865.7994.10.camel@mellon> Message-ID: <4715E117.4060506@minst.net> Hi, In mapbuilder we use (OWS)Context to store our layer information, there the group information is stored in a XML format like this So I believe that your approach of using group name group: "Group" and using Group hierarchy group: "Parent/Child" Should be compatible with the OWSContext approach. So it was a heads up from me :) Although I wonder now if Openlayers knows about the groups apart from the display in the LayerSwitcher. Because if it implements layer management (moving layers) you want to move the entire group upif the parent is moved; eg: if you move parent 2 up it should bring its children along before: parent 1 -child 1 -child 2 normal layer parent 2 -child 3 -child 4 after: parent 1 -child 1 -child 2 parent 2 -child 3 -child 4 normal layer And to make things more complicated what happens if you move any of the childs? (I don't know if the specs require children to stay in their groups or not, if not it should be possible to drag them out of a group) Steven Jachym Cepicky wrote: > Hi, > > sorry, I do not see your point: I want the layers grouped in > LayerSwitcher. The simplest way how to do it, is to specify the group > name > group: "Group" > and using Group hierarchy > group: "Parent/Child" > > everything happens while new OpenLayers.Layer.* is defined > > jachym > > Steven M. Ottens p??e v St 17. 10. 2007 v 11:23 +0200: > >> The mapbuilder code uses >> //wmc:ResourceList/wmc:Layer[wmc:Extension/wmc:Group/@name=$GroupName] >> So this means that it selects the layers which have a group-extension. I >> believe the structure is hierarchical, so using group/layer approach >> should be consistent with the OWS spec. >> But I'm not the real expert, I though gertjan did the grouping code, but >> could be wrong. >> >> Steven >> >> Cameron Shorter wrote: >> >>> Grouping layers has been discussed a few time on the Mapbuilder list, in >>> particular including Grouping in the OWS Spec. >>> It would be good to confirm that your grouping code is consistent with >>> Mapbuilder and OWS Context to ease future integration issues. >>> I think Steven is probably the expert in this area. >>> >>> Lorenzo Becchi wrote: >>> >>> >>>> Cool Jachym. >>>> >>>> that's a good idea. >>>> It can even represent the complete structure of a WMS GetCapabilites >>>> (read: WMS Manager [1]). >>>> >>>> At the code sprint in Victoria, we where talking with Chris about the >>>> possibility to add few features to LayerSwticher. This could be one. >>>> other possible attribute wired features: >>>> - "buttonDropLayer" : true //activate a button to let the user drop the >>>> layer from map and layerSwitcher >>>> - "buttonZoom2Extent" : true //show a button to zoom to layer extent >>>> - "buttonOpacity" : true //show two buttons change layer opacity >>>> - "buttonMoveLayer" : true //show two buttons to move layers up or down >>>> in the overlay list (this could collide with your structure) >>>> >>>> this are the buttons that could apply to all type of layers. >>>> button could be just a div where all styles are defined inside the CSS. >>>> >>>> if you and others agree we can expand your Ticket or make another that >>>> can manage all points. Or make a lots of tickets... >>>> ciao >>>> Lorenzo >>>> >>>> ps: btw, your patch doesn't work on Safari 2. >>>> >>>> [1] *http://tinyurl.com/2fjbr7* >>>> >>>> >>>> >>>> Jachym Cepicky wrote: >>>> >>>> >>>> >>>>> Hi developers, >>>>> I have implemented ordering map layers into groups [1]. You have to >>>>> specify new layer attribute group:"Group Name", e.g.: >>>>> >>>>> var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", >>>>> "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", >>>>> {layers: "rail,road", >>>>> transparent: "true", format: "image/png" >>>>> }, >>>>> { >>>>> group:"Transit" >>>>> }); >>>>> >>>>> You can define group hierarchy using "/" mark: >>>>> >>>>> .... >>>>> group: "Transit/Roads" >>>>> .... >>>>> >>>>> Only changed file is LayerSwitcher.js >>>>> >>>>> For example see [2] >>>>> >>>>> Hope, you'll like it >>>>> >>>>> Jachym >>>>> >>>>> [1] http://trac.openlayers.org/ticket/1086 >>>>> [2] >>>>> http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@openlayers.org >>>>> http://openlayers.org/mailman/listinfo/dev >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@openlayers.org >>>> http://openlayers.org/mailman/listinfo/dev >>>> >>>> >>>> >>>> >>> >>> >> >> From lorenzo at ominiverdi.com Wed Oct 17 08:57:01 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <4715E117.4060506@minst.net> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> <4715D475.4080409@minst.net> <1192614865.7994.10.camel@mellon> <4715E117.4060506@minst.net> Message-ID: <4716069D.3010909@ominiverdi.com> Hi Steven, Jachym, all OL probably will adopt OLON, Tim Schaub's creation, as internal object (Format->OLON) to store all informations regarding the map objects and its layers. Then there are many different format that can be associated to OLON in a import/export concept. I'm personally working on Context and Tim on KML. OLON, AFAIK, is not planned to manage GROUPS but I think that Jachym's notation can be used as parameter inside OLON and to create XML hierarchies in OWS Context or KML or whatever... Only Tim knows what's OLON development status ;-) ciao Lorenzo Steven M. Ottens wrote: > Hi, > > In mapbuilder we use (OWS)Context to store our layer information, > there the group information is stored in a XML format like this > > > > > > So I believe that your approach of using > group name > group: "Group" > and using Group hierarchy > group: "Parent/Child" > Should be compatible with the OWSContext approach. So it was a heads > up from me :) > > Although I wonder now if Openlayers knows about the groups apart from > the display in the LayerSwitcher. Because if it implements layer > management (moving layers) you want to move the entire group upif the > parent is moved; eg: > if you move parent 2 up it should bring its children along > > before: > parent 1 > -child 1 > -child 2 > normal layer > parent 2 > -child 3 > -child 4 > > after: > parent 1 > -child 1 > -child 2 > parent 2 > -child 3 > -child 4 > normal layer > > And to make things more complicated what happens if you move any of > the childs? (I don't know if the specs require children to stay in > their groups or not, if not it should be possible to drag them out of > a group) > > Steven > > Jachym Cepicky wrote: >> Hi, >> >> sorry, I do not see your point: I want the layers grouped in >> LayerSwitcher. The simplest way how to do it, is to specify the group >> name >> group: "Group" >> and using Group hierarchy >> group: "Parent/Child" >> >> everything happens while new OpenLayers.Layer.* is defined >> >> jachym >> >> Steven M. Ottens p??e v St 17. 10. 2007 v 11:23 +0200: >> >>> The mapbuilder code uses >>> //wmc:ResourceList/wmc:Layer[wmc:Extension/wmc:Group/@name=$GroupName] >>> So this means that it selects the layers which have a >>> group-extension. I believe the structure is hierarchical, so using >>> group/layer approach should be consistent with the OWS spec. >>> But I'm not the real expert, I though gertjan did the grouping code, >>> but could be wrong. >>> >>> Steven >>> >>> Cameron Shorter wrote: >>> >>>> Grouping layers has been discussed a few time on the Mapbuilder >>>> list, in particular including Grouping in the OWS Spec. >>>> It would be good to confirm that your grouping code is consistent >>>> with Mapbuilder and OWS Context to ease future integration issues. >>>> I think Steven is probably the expert in this area. >>>> >>>> Lorenzo Becchi wrote: >>>> >>>>> Cool Jachym. >>>>> >>>>> that's a good idea. >>>>> It can even represent the complete structure of a WMS >>>>> GetCapabilites (read: WMS Manager [1]). >>>>> >>>>> At the code sprint in Victoria, we where talking with Chris about >>>>> the possibility to add few features to LayerSwticher. This could >>>>> be one. >>>>> other possible attribute wired features: >>>>> - "buttonDropLayer" : true //activate a button to let the user >>>>> drop the layer from map and layerSwitcher >>>>> - "buttonZoom2Extent" : true //show a button to zoom to layer extent >>>>> - "buttonOpacity" : true //show two buttons change layer opacity >>>>> - "buttonMoveLayer" : true //show two buttons to move layers up or >>>>> down in the overlay list (this could collide with your structure) >>>>> >>>>> this are the buttons that could apply to all type of layers. >>>>> button could be just a div where all styles are defined inside the >>>>> CSS. >>>>> >>>>> if you and others agree we can expand your Ticket or make another >>>>> that can manage all points. Or make a lots of tickets... >>>>> ciao >>>>> Lorenzo >>>>> >>>>> ps: btw, your patch doesn't work on Safari 2. >>>>> >>>>> [1] *http://tinyurl.com/2fjbr7* >>>>> >>>>> >>>>> >>>>> Jachym Cepicky wrote: >>>>> >>>>>> Hi developers, >>>>>> I have implemented ordering map layers into groups [1]. You have to >>>>>> specify new layer attribute group:"Group Name", e.g.: >>>>>> >>>>>> var dm = new OpenLayers.Layer.WMS( "DM Solutions Transit", >>>>>> "http://www2.dmsolutions.ca/cgi-bin/mswms_gmap", >>>>>> {layers: "rail,road", >>>>>> transparent: "true", format: "image/png" >>>>>> }, >>>>>> { group:"Transit" >>>>>> }); >>>>>> >>>>>> You can define group hierarchy using "/" mark: >>>>>> >>>>>> .... >>>>>> group: "Transit/Roads" >>>>>> .... >>>>>> >>>>>> Only changed file is LayerSwitcher.js >>>>>> >>>>>> For example see [2] >>>>>> >>>>>> Hope, you'll like it >>>>>> >>>>>> Jachym >>>>>> >>>>>> [1] http://trac.openlayers.org/ticket/1086 >>>>>> [2] >>>>>> http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layer-groups.html >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@openlayers.org >>>>>> http://openlayers.org/mailman/listinfo/dev >>>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@openlayers.org >>>>> http://openlayers.org/mailman/listinfo/dev >>>>> >>>>> >>>> >>> >>> > > > From ian at planetmayo.com Wed Oct 17 14:54:36 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] RFC: Creating IconManager utility class Message-ID: Hi, all. I'm working away on #1073 [1], and making steady progress [2]. I'm finding myself bolting on quite a bit of code to support the specification of size & location of the icon images themselves. There's still more processing to be done to translate "Pizza Restaurants" to "pizza.png". Rather than pollute the georss.xml class with this functionality I intend creating an IconManager class that performs as follows: - it takes a size, offset, root and suffix parameters - it is able to provide an openlayers.icon when provided with a String (an rss category from my implementation of georss.xml) - or returns null if it can't provide an image. - it has over-rideable function to determine the image to produce, though the default functionality will be to convert the string to lower case and swap underscores for spaces - then prepend with the root and append with the suffix I'm got the following questions: - can anybody point me to a suitable folder to contain this functionality - should it be included in its own ticket? - any other thoughts? In the working branch at [2], you still load georss.xml, but observe that some of the rss entries have had arbitrary categories added - and see the unique markers shown [1] http://trac.openlayers.org/ticket/1073 [2] http://dev.openlayers.org/sandbox/ianmayo/branches/rss/openlayers/examples/georss.html -- Ian Mayo PlanetMayo Ltd From andreas.hocevar at gmail.com Wed Oct 17 16:35:20 2007 From: andreas.hocevar at gmail.com (Andreas Hocevar) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] SLD parsing and rendering Message-ID: <5b021dd0710171335q34e85e89p8e36b64f458099b4@mail.gmail.com> Hi, the SLD parsing and rendering component (#533, [1]) I was working on with Pierre Giraud of Camptocamp at the FOSS4G code sprint is now ready for review. Since the code sprint, there have been major improvements: * OGC filter rules are no longer translated to JavaScript eval snippets. There is a new object hierarchy under OpenLayers.Rule with classes to store and evaluate rules. The big advantage of that is not only performance, but also that it is much easier to use as a starting point for a SLD editor that has to store rules and write them back to a SLD file. * More of the OGC filter spec is supported, namely the PropertyIsLike filter. * Parsing of sld:NamedLayer/sld:Name and sld:UserStyle/sld:IsDefault. Based on that, vector layers can now take the whole result hash of OpenLayers.Format.SLD.read() as style property and automatically use the default style for the NamedLayer that has the same name as the vector layer and is marked as IsDefault. * Improved example with the Tasmania data set from Geoserver [2]. The first version of this was contributed by Alex of Lisasoft, along with thorough testing. * TestAnotherWay tests for basic functionality of all new classes. * Improved code readability and comments. * Changes on the OpenLayers trunk codebase are limited to a few lines in two files: Layer/Vector.js and Control/SelectFeature.js Please have a look at it, I hope you share my opinion that this thing is ready for moving it to trunk. If not, feel free to comment on it and tell me what to improve. Once this is finished, it will be used for styling vector layers in Mapbuilder based on the SLD properties in View/OWS Context documents. It should also be a solid ground to build a SLD editor upon. Regards, Andreas. [1] http://trac.openlayers.org/ticket/533 [2] http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/gml-tasmania-sld.html From tschaub at openplans.org Wed Oct 17 17:46:20 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. In-Reply-To: <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> References: <1192586297.6651.17.camel@bender> <20071017020933.GA28476@metacarta.com> <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> Message-ID: <471682AC.4090508@openplans.org> Yeah, this is a standard JS optimization technique. Note that it is strictly slower to concatenate a handful of strings with array.join, but it is good practice for largish numbers. And, no new methods needed in my mind. Another thing to keep in mind is that any time you know the number of elements in the array, it is better to initialize the array with a length (instead of using push). That is: // worst var str = ""; for(var i=0; i On 10/16/07, Christopher Schmidt wrote: >> On Wed, Oct 17, 2007 at 11:58:17AM +1000, Roald de Wit wrote: >>> The same slowdown most probably applies to the other drawing methods in >>> this class. >>> >>> My question is: what would be the best way to tackle this? >> Interesting. I'd always followed the type of behavior you're suggsting >> in Python, but had never known it was needed in JS. (It's always bugged >> me that we just shoved strings together in Javascript, but it seemed >> like everyone did it, so I didn't question.) >> >> The typical way I do this in Python is to just do the equivilant of: >> >> var stringList = []; >> for (var i = 0; i < 10000; i++) { stringList.push('foo'); } >> var string = stringList.join(""); >> >> I think we can even skip the .join("") and use .toString() in JS, but I >> have no idea how portable that is, and it feels slightly hacky. >> >> So, I don't see any need for a stringBuffer object, since it would just >> be an array (with 'push' replaced with 'append'). >> >> With these performance numbers in hand, I think that migrating any >> significant use of string concatanation -- which I think only includes >> the renderers, and maybe things like getParameterString -- to be array >> based makes sense, and I'm in support of that path. It probably makes >> sense to write at least basic tests for the renderer functionality >> before proceeding with this, to ensure that it doesn't break with the >> new code in any way that we can be aware of ahead of time. > > Wow. Cool trick. Can't see where else in the OL code it would make > much of a difference other than: > > -GeoRSS parseData() -- 197 > - BaseTypes String camelize -- 87 > > how many times is getParameterString() called? > > e > > > > > >> Regards, >> -- >> Christopher Schmidt >> MetaCarta >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,47158827285493668746562! > From tschaub at openplans.org Wed Oct 17 17:51:56 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] SLD parsing and rendering In-Reply-To: <5b021dd0710171335q34e85e89p8e36b64f458099b4@mail.gmail.com> References: <5b021dd0710171335q34e85e89p8e36b64f458099b4@mail.gmail.com> Message-ID: <471683FC.9080109@openplans.org> Hey- This is great work - and a huge contribution to OpenLayers! I look forward to taking some time with it. Just a quick thanks for putting it all together. Tim Andreas Hocevar wrote: > Hi, > > the SLD parsing and rendering component (#533, [1]) I was working on > with Pierre Giraud of Camptocamp at the FOSS4G code sprint is now > ready for review. Since the code sprint, there have been major > improvements: > > * OGC filter rules are no longer translated to JavaScript eval > snippets. There is a new object hierarchy under OpenLayers.Rule with > classes to store and evaluate rules. The big advantage of that is not > only performance, but also that it is much easier to use as a starting > point for a SLD editor that has to store rules and write them back to > a SLD file. > > * More of the OGC filter spec is supported, namely the PropertyIsLike filter. > > * Parsing of sld:NamedLayer/sld:Name and sld:UserStyle/sld:IsDefault. > Based on that, vector layers can now take the whole result hash of > OpenLayers.Format.SLD.read() as style property and automatically use > the default style for the NamedLayer that has the same name as the > vector layer and is marked as IsDefault. > > * Improved example with the Tasmania data set from Geoserver [2]. The > first version of this was contributed by Alex of Lisasoft, along with > thorough testing. > > * TestAnotherWay tests for basic functionality of all new classes. > > * Improved code readability and comments. > > * Changes on the OpenLayers trunk codebase are limited to a few lines > in two files: Layer/Vector.js and Control/SelectFeature.js > > Please have a look at it, I hope you share my opinion that this thing > is ready for moving it to trunk. If not, feel free to comment on it > and tell me what to improve. > > Once this is finished, it will be used for styling vector layers in > Mapbuilder based on the SLD properties in View/OWS Context documents. > It should also be a solid ground to build a SLD editor upon. > > Regards, > Andreas. > > [1] http://trac.openlayers.org/ticket/533 > [2] http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/gml-tasmania-sld.html > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,4716721d30071804284693! > From rdewit at users.sourceforge.net Wed Oct 17 19:24:22 2007 From: rdewit at users.sourceforge.net (Roald de Wit) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] VML rendering in IE is slow with big geometries. Proposed Fix. In-Reply-To: <471682AC.4090508@openplans.org> References: <1192586297.6651.17.camel@bender> <20071017020933.GA28476@metacarta.com> <6ae3fb590710162057h54651c44laaa09adabc9fd711@mail.gmail.com> <471682AC.4090508@openplans.org> Message-ID: <1192663462.6651.26.camel@bender> On Wed, 2007-10-17 at 15:46 -0600, Tim Schaub wrote: > Yeah, this is a standard JS optimization technique. > > Note that it is strictly slower to concatenate a handful of strings with > array.join, but it is good practice for largish numbers. > > And, no new methods needed in my mind. > > Another thing to keep in mind is that any time you know the number of > elements in the array, it is better to initialize the array with a > length (instead of using push). OK, I'll use all the info in this thread to create a patch for VMS.js. Hope I'll get to it today. Thanx for that last tip Tim! Roald -- Roald de Wit Software Engineer, http://lisasoft.com From cameron.shorter at gmail.com Thu Oct 18 04:36:41 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> Message-ID: <47171B19.3050600@gmail.com> +1 Erik Uzureau wrote: > Since Se?or Schmidt has been so good about carrying the new ClearBSD > license forward[1], the time has come once again to talk about the > idea of an Addins directory. > > The idea behind Addins is to create a space in the OpenLayers > repository where we can put layers, controls, and other OpenLayers > related projects that don't quite belong in the core distribution of > the library, but that people might find useful. > > The hope with Addins is that it will be a fertile ground for people to > show off tricks and gadgets they've built that do cool things with > OpenLayers and that they're interested to give back to the community. > Off the top of my head, a couple of specific projects seem like worthy > candidates: > * WMS Manager (getCapabilities-enhanced layerswitcher tool) > * Generally Improved LayerSwitcher (grouping, dragging-to-reorder) > * Driving Directions library (code that works with OLS or pgRouting > to request and display routing information on an OpenLayers Map) > > I'm sure there are many other projects that could qualify. > > It is important to distinguish between the sandboxes and the Addins > directory. The former is a playground for people to experiment. The > code is not covered by any license and is indeed in a sort of > "free-for-all" state. The latter, however, will be exclusively for > established projects interested in a more formal release process. Code > in the Addins directory will be covered under the ClearBSD license, > and tags will be made for compatibility with different OL versions. > > A proposed directory structure might look something like this: > > /sandbox > /branches > /trunk > /trunk/openlayers > /trunk/addins > /tags/openlayers > /tags/addins > > Please let me know what you think of this proposal, and if you think > you have a project that you would be interested in releasing in the > Addins directory. > > Cheers, boa noite, > Erik > > > [1] http://trac.openlayers.org/changeset/4985 > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From cameron.shorter at gmail.com Thu Oct 18 04:41:40 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] SLD parsing and rendering In-Reply-To: <471683FC.9080109@openplans.org> References: <5b021dd0710171335q34e85e89p8e36b64f458099b4@mail.gmail.com> <471683FC.9080109@openplans.org> Message-ID: <47171C44.4020403@gmail.com> Yes, thanks for all the hard work on this thread. Tim Schaub wrote: > Hey- > > This is great work - and a huge contribution to OpenLayers! I look > forward to taking some time with it. Just a quick thanks for putting it > all together. > > Tim > > Andreas Hocevar wrote: > >> Hi, >> >> the SLD parsing and rendering component (#533, [1]) I was working on >> with Pierre Giraud of Camptocamp at the FOSS4G code sprint is now >> ready for review. Since the code sprint, there have been major >> improvements: >> >> * OGC filter rules are no longer translated to JavaScript eval >> snippets. There is a new object hierarchy under OpenLayers.Rule with >> classes to store and evaluate rules. The big advantage of that is not >> only performance, but also that it is much easier to use as a starting >> point for a SLD editor that has to store rules and write them back to >> a SLD file. >> >> * More of the OGC filter spec is supported, namely the PropertyIsLike filter. >> >> * Parsing of sld:NamedLayer/sld:Name and sld:UserStyle/sld:IsDefault. >> Based on that, vector layers can now take the whole result hash of >> OpenLayers.Format.SLD.read() as style property and automatically use >> the default style for the NamedLayer that has the same name as the >> vector layer and is marked as IsDefault. >> >> * Improved example with the Tasmania data set from Geoserver [2]. The >> first version of this was contributed by Alex of Lisasoft, along with >> thorough testing. >> >> * TestAnotherWay tests for basic functionality of all new classes. >> >> * Improved code readability and comments. >> >> * Changes on the OpenLayers trunk codebase are limited to a few lines >> in two files: Layer/Vector.js and Control/SelectFeature.js >> >> Please have a look at it, I hope you share my opinion that this thing >> is ready for moving it to trunk. If not, feel free to comment on it >> and tell me what to improve. >> >> Once this is finished, it will be used for styling vector layers in >> Mapbuilder based on the SLD properties in View/OWS Context documents. >> It should also be a solid ground to build a SLD editor upon. >> >> Regards, >> Andreas. >> >> [1] http://trac.openlayers.org/ticket/533 >> [2] http://dev.openlayers.org/sandbox/ahocevar/sldRenderer/examples/gml-tasmania-sld.html >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> >> !DSPAM:4033,4716721d30071804284693! >> >> > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From pspencer at dmsolutions.ca Thu Oct 18 08:42:15 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> Message-ID: <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> Erik, are the Addins intended to be officially supported, but outside the core library? Or are they intended to be third party contributions that are 'use at your own risk'? If it is the second case, I would rather see the addins directory be at the root level like sandboxes rather than within trunk. Cheers Paul On 17-Oct-07, at 4:00 AM, Erik Uzureau wrote: > Since Se?or Schmidt has been so good about carrying the new ClearBSD > license forward[1], the time has come once again to talk about the > idea of an Addins directory. > > The idea behind Addins is to create a space in the OpenLayers > repository where we can put layers, controls, and other OpenLayers > related projects that don't quite belong in the core distribution of > the library, but that people might find useful. > > The hope with Addins is that it will be a fertile ground for people to > show off tricks and gadgets they've built that do cool things with > OpenLayers and that they're interested to give back to the community. > Off the top of my head, a couple of specific projects seem like worthy > candidates: > * WMS Manager (getCapabilities-enhanced layerswitcher tool) > * Generally Improved LayerSwitcher (grouping, dragging-to-reorder) > * Driving Directions library (code that works with OLS or pgRouting > to request and display routing information on an OpenLayers Map) > > I'm sure there are many other projects that could qualify. > > It is important to distinguish between the sandboxes and the Addins > directory. The former is a playground for people to experiment. The > code is not covered by any license and is indeed in a sort of > "free-for-all" state. The latter, however, will be exclusively for > established projects interested in a more formal release process. Code > in the Addins directory will be covered under the ClearBSD license, > and tags will be made for compatibility with different OL versions. > > A proposed directory structure might look something like this: > > /sandbox > /branches > /trunk > /trunk/openlayers > /trunk/addins > /tags/openlayers > /tags/addins > > Please let me know what you think of this proposal, and if you think > you have a project that you would be interested in releasing in the > Addins directory. > > Cheers, boa noite, > Erik > > > [1] http://trac.openlayers.org/changeset/4985 > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Thu Oct 18 08:58:51 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> Message-ID: <20071018125851.GA14361@metacarta.com> On Thu, Oct 18, 2007 at 08:42:15AM -0400, Paul Spencer wrote: > Erik, > > are the Addins intended to be officially supported, but outside the > core library? Or are they intended to be third party contributions > that are 'use at your own risk'? I think my personal intention is that they are 'officially supported by their developer', and that users can expect help from the mailing list, IRC, etc. If the WMS Manager goes into addins, I expect Lorenzo to support the users of it via the OpenLayers infrastructure. So, I wouldn't expect that I would be answering every questino related to every addin, but I would chip in, and I would expect other developers to take an active role in supporting their users. If the OpenLayers trunk breaks compatibility with an addin, I think that the OpenLayers project would have a responsibility to fix it. To me this is definitely not 'use at your own risk': these are things that are meant to work with OpenLayers. If they don't, that's a problem, and the project has a responsibility to make sure that doesn't happen. If we find that an addin is not 'up to snuff' -- that is, it's consistently broken, or it's not being maintained -- then in my mind, it doesn't go into addins -- and if it's already there, we consider taking it out. Make sense? Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Thu Oct 18 09:01:57 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint cleanup committed Message-ID: I have added missing semi-colons and curly braces around all block scopes in: http://trac.openlayers.org/changeset/5002/ jslint reports the remaining warnings: /lib/Firebug/firebug.js: 0 error(s), 45 warning(s) /lib/Firebug/firebugx.js: 0 error(s), 2 warning(s) /lib/Rico/Color.js: 0 error(s), 18 warning(s) /lib/Rico/Corner.js: 0 error(s), 36 warning(s) Do you want me to do anything about these? Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Thu Oct 18 09:04:48 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: References: Message-ID: <20071018130448.GB14361@metacarta.com> On Thu, Oct 18, 2007 at 09:01:57AM -0400, Paul Spencer wrote: > I have added missing semi-colons and curly braces around all block > scopes in: > > http://trac.openlayers.org/changeset/5002/ > > jslint reports the remaining warnings: > > /lib/Firebug/firebug.js: 0 error(s), 45 warning(s) > /lib/Firebug/firebugx.js: 0 error(s), 2 warning(s) > /lib/Rico/Color.js: 0 error(s), 18 warning(s) > /lib/Rico/Corner.js: 0 error(s), 36 warning(s) > > Do you want me to do anything about these? I would prefer we leave the firebug files alone -- I don't think we've touched those at all. I have no strong feelings on Rico: we've already changed those files to put them in the OpenLayers namespace, further changes don't bother me much, but I'm also happy to just leave them. Regards, -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Thu Oct 18 09:19:25 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: <20071018125851.GA14361@metacarta.com> References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> <20071018125851.GA14361@metacarta.com> Message-ID: <1192713565.8316.3.camel@mellon> hi, Christopher Schmidt p??e v ?t 18. 10. 2007 v 08:58 -0400: > On Thu, Oct 18, 2007 at 08:42:15AM -0400, Paul Spencer wrote: > > Erik, > > > > are the Addins intended to be officially supported, but outside the > > core library? Or are they intended to be third party contributions > > that are 'use at your own risk'? > > I think my personal intention is that they are 'officially supported by > their developer', and that users can expect help from the mailing list, > IRC, etc. If the WMS Manager goes into addins, I expect Lorenzo to > support the users of it via the OpenLayers infrastructure. > > So, I wouldn't expect that I would be answering every questino related > to every addin, but I would chip in, and I would expect other developers > to take an active role in supporting their users. > > If the OpenLayers trunk breaks compatibility with an addin, I think that > the OpenLayers project would have a responsibility to fix it. > > To me this is definitely not 'use at your own risk': these are things > that are meant to work with OpenLayers. If they don't, that's a problem, > and the project has a responsibility to make sure that doesn't happen. > If we find that an addin is not 'up to snuff' -- that is, it's > consistently broken, or it's not being maintained -- then in my mind, > it doesn't go into addins -- and if it's already there, we consider > taking it out. > > Make sense? further more, IMHO Addins should be better tested, because of more users will use it and so, they are natural candidates to appear in the Trunk, if they could be used by general user. jachym -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071018/576de389/attachment.bin From jachym.cepicky at gmail.com Thu Oct 18 09:23:50 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities Message-ID: <1192713830.8316.9.camel@mellon> Hi, I would like to ask about the status of OpenLayers language support. There are not many strings, which could be translated, however, some are there and IMHO we should (de)find a way, how to make this possible. Was there some discussion to this topic? IMHO, new map attribute "lang" should be defined, as well as new method OpenLayer.Util.getOLString("English text") (or similar). Any suggestions? Should I write something like this? Is there already some code out there? Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071018/87e0328a/attachment.bin From crschmidt at metacarta.com Thu Oct 18 09:33:56 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <1192713830.8316.9.camel@mellon> References: <1192713830.8316.9.camel@mellon> Message-ID: <20071018133356.GA19498@metacarta.com> On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > Hi, > > I would like to ask about the status of OpenLayers language support. > There are not many strings, which could be translated, however, some are > there and IMHO we should (de)find a way, how to make this possible. Was > there some discussion to this topic? > > IMHO, new map attribute "lang" should be defined, as well as new method > OpenLayer.Util.getOLString("English text") (or similar). > > Any suggestions? Should I write something like this? Is there already > some code out there? No code yet, but I agree that now is the time. http://trac.openlayers.org/wiki/RFC/Internationalization Is my start at an RFC, which never went far enough. My belief is that we should make this a global setting, rather than a per-map configuration. This would mean you could not have multiple languages on the same page at the same time, but would also mean you don't need a reference to the map object in order to get a correct translation string. I don't know if the trade off is worth it. What do other people think? Regards, -- Christopher Schmidt MetaCarta From bartvde at osgis.nl Thu Oct 18 09:44:00 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071018133356.GA19498@metacarta.com> References: <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> Message-ID: <47176320.2060204@osgis.nl> Hi Chris, I think it is acceptable to have a global setting. I can't imagine a common use case (for myself) where one map would be in English and another one in Dutch on the same page. It is important though that it is possible to switch languages. Best regards, Bart Christopher Schmidt schreef: > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > >> Hi, >> >> I would like to ask about the status of OpenLayers language support. >> There are not many strings, which could be translated, however, some are >> there and IMHO we should (de)find a way, how to make this possible. Was >> there some discussion to this topic? >> >> IMHO, new map attribute "lang" should be defined, as well as new method >> OpenLayer.Util.getOLString("English text") (or similar). >> >> Any suggestions? Should I write something like this? Is there already >> some code out there? >> > > No code yet, but I agree that now is the time. > > http://trac.openlayers.org/wiki/RFC/Internationalization > > Is my start at an RFC, which never went far enough. > > My belief is that we should make this a global setting, rather than a > per-map configuration. This would mean you could not have multiple > languages on the same page at the same time, but would also mean you > don't need a reference to the map object in order to get a correct > translation string. I don't know if the trade off is worth it. What do > other people think? > > Regards, > -- Bart van den Eijnden OSGIS, Open Source GIS bartvde@osgis.nl http://www.osgis.nl From crschmidt at metacarta.com Thu Oct 18 09:53:57 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] [OSM-dev] Basic GPX parser in OpenLayers Message-ID: <20071018135357.GA13666@metacarta.com> Wrote this for the OSM crowd, but might be of interest here too. (Only took me 14 minutes total! Not that much code though, so it's not that impressive ;)) ----- Forwarded message from Christopher Schmidt ----- From: Christopher Schmidt To: dev@openstreetmap.org Date: Thu, 18 Oct 2007 09:36:33 -0400 Subject: [OSM-dev] Basic GPX parser in OpenLayers I just put together a basic GPX Parser for OpenLayers: it does track segments only, and is very limited. You can try it at: http://dev.openlayers.org/sandbox/crschmidt/osm/examples/vector-formats.html Select GPX from the dropdown, paste in a GPX doc, and hit the submit button. I have tried and confirmed it works with the following traces (at least minimally): http://www.openstreetmap.org/user/crschmidt/traces/45460 http://www.openstreetmap.org/user/roses/traces/45478 I don't know if this will make it into OpenLayers 2.6 -- if you have an interest in seeing this in OpenLayers, expressing that interest now would be a good way to encourage me :) Regards, -- Christopher Schmidt MetaCarta _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ----- End forwarded message ----- -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Thu Oct 18 09:58:42 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <47176320.2060204@osgis.nl> References: <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <47176320.2060204@osgis.nl> Message-ID: <1192715922.8316.11.camel@mellon> Bart van den Eijnden (OSGIS) p??e v ?t 18. 10. 2007 v 15:44 +0200: > Hi Chris, > > I think it is acceptable to have a global setting. I can't imagine a > common use case (for myself) where one map would be in English and > another one in Dutch on the same page. It is important though that it is > possible to switch languages. > +1 jachym > Best regards, > Bart > > Christopher Schmidt schreef: > > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > > > >> Hi, > >> > >> I would like to ask about the status of OpenLayers language support. > >> There are not many strings, which could be translated, however, some are > >> there and IMHO we should (de)find a way, how to make this possible. Was > >> there some discussion to this topic? > >> > >> IMHO, new map attribute "lang" should be defined, as well as new method > >> OpenLayer.Util.getOLString("English text") (or similar). > >> > >> Any suggestions? Should I write something like this? Is there already > >> some code out there? > >> > > > > No code yet, but I agree that now is the time. > > > > http://trac.openlayers.org/wiki/RFC/Internationalization > > > > Is my start at an RFC, which never went far enough. > > > > My belief is that we should make this a global setting, rather than a > > per-map configuration. This would mean you could not have multiple > > languages on the same page at the same time, but would also mean you > > don't need a reference to the map object in order to get a correct > > translation string. I don't know if the trade off is worth it. What do > > other people think? > > > > Regards, > > > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071018/de094b6e/attachment.bin From danlittle at yahoo.com Thu Oct 18 10:10:10 2007 From: danlittle at yahoo.com (Dan Little) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities Message-ID: <926726.10161.qm@web51402.mail.re2.yahoo.com> I wouldn't think this to be too hard. In most internationalized applications I've seen, there is typically a "lang" or "strings" file that contains all of the strings for a given application. Then when the code needs a string it will call a global variable containing that error/warning/info message. This way all of the needed translation is isolated to a single file. Changing languages becomes a matter of loading an alternate language file. So there could be a collection of language files: strings.en.js strings.es.js strings.fr.js strnigs.de.js And then provide some basic facilities for switching between them. In fact, each of those files could be a JSON object that gets loaded to a global object/variable. I may be just spewing bad ideas... but so long as the creative juices were flowing I'd thought I'd share. -Duck ----- Original Message ---- From: Jachym Cepicky To: Bart van den Eijnden (OSGIS) Cc: "dev@openlayers" Sent: Thursday, October 18, 2007 8:58:42 AM Subject: Re: [OpenLayers-Dev] status of translation possibilities Bart van den Eijnden (OSGIS) p??e v ?t 18. 10. 2007 v 15:44 +0200: > Hi Chris, > > I think it is acceptable to have a global setting. I can't imagine a > common use case (for myself) where one map would be in English and > another one in Dutch on the same page. It is important though that it is > possible to switch languages. > +1 jachym > Best regards, > Bart > > Christopher Schmidt schreef: > > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > > > >> Hi, > >> > >> I would like to ask about the status of OpenLayers language support. > >> There are not many strings, which could be translated, however, some are > >> there and IMHO we should (de)find a way, how to make this possible. Was > >> there some discussion to this topic? > >> > >> IMHO, new map attribute "lang" should be defined, as well as new method > >> OpenLayer.Util.getOLString("English text") (or similar). > >> > >> Any suggestions? Should I write something like this? Is there already > >> some code out there? > >> > > > > No code yet, but I agree that now is the time. > > > > http://trac.openlayers.org/wiki/RFC/Internationalization > > > > Is my start at an RFC, which never went far enough. > > > > My belief is that we should make this a global setting, rather than a > > per-map configuration. This would mean you could not have multiple > > languages on the same page at the same time, but would also mean you > > don't need a reference to the map object in order to get a correct > > translation string. I don't know if the trade off is worth it. What do > > other people think? > > > > Regards, > > > > -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071018/6fcfefd7/attachment.html From penyaskito at gmail.com Thu Oct 18 10:40:18 2007 From: penyaskito at gmail.com (=?UTF-8?Q?Christian_L=C3=B3pez_Esp=C3=ADnola?=) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <926726.10161.qm@web51402.mail.re2.yahoo.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> Message-ID: Hi all, I personally prefer the style that Chris pointed in a previous discussion: http://openlayers.org/pipermail/dev/2007-July/001017.html About the way it should be used, an Openlayers.i18n.CURRENT_LANG global var and an OpenLayers.i18n.setLanguage() method would be simple and extensible. My 2 cents. On 10/18/07, Dan Little wrote: > > I wouldn't think this to be too hard. > > In most internationalized applications I've seen, there is typically a > "lang" or "strings" file that contains all of the strings for a given > application. Then when the code needs a string it will call a global > variable containing that error/warning/info message. This way all of the > needed translation is isolated to a single file. Changing languages becomes > a matter of loading an alternate language file. > > So there could be a collection of language files: > strings.en.js > strings.es.js > strings.fr.js > strnigs.de.js > > And then provide some basic facilities for switching between them. In fact, > each of those files could be a JSON object that gets loaded to a global > object/variable. > > I may be just spewing bad ideas... but so long as the creative juices were > flowing I'd thought I'd share. > > -Duck > > > ----- Original Message ---- > From: Jachym Cepicky > To: Bart van den Eijnden (OSGIS) > Cc: "dev@openlayers" > Sent: Thursday, October 18, 2007 8:58:42 AM > Subject: Re: [OpenLayers-Dev] status of translation possibilities > > Bart van den Eijnden (OSGIS) p??e v ?t 18. 10. 2007 v 15:44 +0200: > > Hi Chris, > > > > I think it is acceptable to have a global setting. I can't imagine a > > common use case (for myself) where one map would be in English and > > another one in Dutch on the same page. It is important though that it is > > possible to switch languages. > > > +1 > > jachym > > > Best regards, > > Bart > > > > Christopher Schmidt schreef: > > > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > > > > > >> Hi, > > >> > > >> I would like to ask about the status of OpenLayers language support. > > >> There are not many strings, which could be translated, however, some > are > > >> there and IMHO we should (de)find a way, how to make this possible. Was > > >> there some discussion to this topic? > > >> > > >> IMHO, new map attribute "lang" should be defined, as well as new method > > >> OpenLayer.Util.getOLString("English text") (or similar). > > >> > > >> Any suggestions? Should I write something like this? Is there already > > >> some code out there? > > >> > > > > > > No code yet, but I agree that now is the time. > > > > > > > http://trac.openlayers.org/wiki/RFC/Internationalization > > > > > > Is my start at an RFC, which never went far enough. > > > > > > My belief is that we should make this a global setting, rather than a > > > per-map configuration. This would mean you could not have multiple > > > languages on the same page at the same time, but would also mean you > > > don't need a reference to the map object in order to get a correct > > > translation string. I don't know if the trade off is worth it. What do > > > other people think? > > > > > > Regards, > > > > > > > > -- > Jachym Cepicky > e-mail: jachym.cepicky@gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Regards, Christian L?pez Esp?nola From pspencer at dmsolutions.ca Thu Oct 18 10:31:37 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: <1192713565.8316.3.camel@mellon> References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> <20071018125851.GA14361@metacarta.com> <1192713565.8316.3.camel@mellon> Message-ID: On 18-Oct-07, at 9:19 AM, Jachym Cepicky wrote: > hi, > Christopher Schmidt p??e v ?t 18. 10. 2007 v 08:58 -0400: >> On Thu, Oct 18, 2007 at 08:42:15AM -0400, Paul Spencer wrote: >>> Erik, >>> >>> are the Addins intended to be officially supported, but outside the >>> core library? Or are they intended to be third party contributions >>> that are 'use at your own risk'? >> >> I think my personal intention is that they are 'officially >> supported by >> their developer', and that users can expect help from the mailing >> list, >> IRC, etc. If the WMS Manager goes into addins, I expect Lorenzo to >> support the users of it via the OpenLayers infrastructure. >> >> So, I wouldn't expect that I would be answering every questino >> related >> to every addin, but I would chip in, and I would expect other >> developers >> to take an active role in supporting their users. >> >> If the OpenLayers trunk breaks compatibility with an addin, I >> think that >> the OpenLayers project would have a responsibility to fix it. >> >> To me this is definitely not 'use at your own risk': these are things >> that are meant to work with OpenLayers. If they don't, that's a >> problem, >> and the project has a responsibility to make sure that doesn't >> happen. >> If we find that an addin is not 'up to snuff' -- that is, it's >> consistently broken, or it's not being maintained -- then in my mind, >> it doesn't go into addins -- and if it's already there, we consider >> taking it out. >> >> Make sense? > > further more, IMHO Addins should be better tested, because of more > users > will use it and so, they are natural candidates to appear in the > Trunk, > if they could be used by general user. > I'm happy with this rationale. Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Thu Oct 18 10:34:56 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071018133356.GA19498@metacarta.com> References: <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> Message-ID: <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> On 18-Oct-07, at 9:33 AM, Christopher Schmidt wrote: > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: >> Hi, >> >> I would like to ask about the status of OpenLayers language support. >> There are not many strings, which could be translated, however, >> some are >> there and IMHO we should (de)find a way, how to make this >> possible. Was >> there some discussion to this topic? >> >> IMHO, new map attribute "lang" should be defined, as well as new >> method >> OpenLayer.Util.getOLString("English text") (or similar). >> >> Any suggestions? Should I write something like this? Is there already >> some code out there? > > No code yet, but I agree that now is the time. > > http://trac.openlayers.org/wiki/RFC/Internationalization > > Is my start at an RFC, which never went far enough. > > My belief is that we should make this a global setting, rather than a > per-map configuration. This would mean you could not have multiple > languages on the same page at the same time, but would also mean you > don't need a reference to the map object in order to get a correct > translation string. I don't know if the trade off is worth it. What do > other people think? > > I like this idea. I think it would be useful to look at what others have done, specifically MapBuilder. We have Cameron and Mike from MapBuilder actively participating in OL and there could be some good lessons learned from them. Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From lorenzo at ominiverdi.com Thu Oct 18 11:14:52 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:35 2010 Subject: [OpenLayers-Dev] Addins Directory In-Reply-To: References: <6ae3fb590710170100x3ca18541n1763efa9e407305b@mail.gmail.com> <06495C79-83BE-4990-B0F3-DFD1681987AE@dmsolutions.ca> <20071018125851.GA14361@metacarta.com> <1192713565.8316.3.camel@mellon> Message-ID: <4717786C.9050908@ominiverdi.com> > > To me this is definitely not 'use at your own risk': these are things > that are meant to work with OpenLayers. If they don't, that's a problem, > and the project has a responsibility to make sure that doesn't happen. > If we find that an addin is not 'up to snuff' -- that is, it's > consistently broken, or it's not being maintained -- then in my mind, > it doesn't go into addins -- and if it's already there, we consider > taking it out. > > Make sense? it make sense to me. I think this can be a first try. I know I'll have to clean up the WMS Manager stuff before applying as AddIn. actually I'll try to make it an OWS Manager. I have some code for [$%&]Context and for Catalogue that I've started joining. ciao Lorenzo From barbara.philippot at camptocamp.com Thu Oct 18 11:29:21 2007 From: barbara.philippot at camptocamp.com (Barbara Philippot) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol library Message-ID: <47177BD1.2010508@camptocamp.com> Hi, We are trying to improve vector rendering for points geometry, allowing users to display symbols such as a square, a triangle, a plane, a church and so on instead of just a circle. At present, we have a library in SVG (using the element) and a library in VML (using the element). Symbols are loaded when the root element (or in VML) is created, and when the drawPoint function is called with a specific style for the point, it references the specified symbol with in SVG and in VML. http://dev.openlayers.org/sandbox/camptocamp/vectorSymbols/examples/vector-symbols.html We are thinking about creating a single library, in order to be generic and so that people can add their own symbols in one file and not both SVG and VML. Problems we meet are : - We would need to draw complex symbols. SVG element allows it since several or predefined can be included inside but in VML, the element isn't so permissive since we can't include several shapes or groups of elements inside. So only simple symbols (one shape, color, stroke-width, etc) would be allowed... - which language is better to write the single library : SVG since SVG symbols are quite spread on the web (with problem above in mind) or javascript to have a generic way to encode symbols, or another language? - A single library involves to develop a way to transform SVG into VML or a certain language into SVG and VML, and there are significant differences between the two (shapetype vs symbol, path element accepting decimal numbers in SVG and not in VML, etc) Any ideas about these problems? So do you think it's worth it or offering predefined symbols and letting people adding their code into SVG library and VML library would be satisfactory? Regards, Barbara From ian at planetmayo.com Thu Oct 18 13:14:31 2007 From: ian at planetmayo.com (Ian Mayo) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol Message-ID: Barbara, I'm afraid I can't offer an opinion on your languages challenge. It would be great if there was a pre-existing file-format for vector symbols, then we just specify filenames rather than hard-code the vectored shapes. I'm currenlty working on provision of per-entry icons (images) for georss feeds. [1]. I've made good progress, but may have to pause my efforts for the next 7 days, see my demo at: [2]. Had you considered using the symbols on a per-entry fashion in a georss feed? I suspect it's fortunate I've got a self-induced development pause: it would seem to be worth offering per-entry symbols as well as icons. Appreciate your thoughts/opinions. Ian. 1. http://trac.openlayers.org/ticket/1073 2. http://dev.openlayers.org/sandbox/ianmayo/branches/rss/openlayers/examples/georss.html -- Ian Mayo PlanetMayo Ltd From erik.uzureau at metacarta.com Thu Oct 18 13:22:03 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <926726.10161.qm@web51402.mail.re2.yahoo.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> Message-ID: <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> I like this idea a lot. we make a /lang directory and a separate file for each language. also the use of JSON I think is crafty. the file could look something like: OpenLayers.Strings['english'] = { 'foo': "Foo for president", 'bar': "Bar for gardner" }; OpenLayers.String.setLanguage = function(lang) { OpenLayers.String._language = lang; } OpenLayers.String.get = function(strKey) { return OpenLayers.String[OpenLayers.String._language][strKey]; } and so: OpenLayers.getString('foo'); or OpenLayers.String.get('foo'); this is off the top of my head. On 10/18/07, Dan Little wrote: > > I wouldn't think this to be too hard. > > In most internationalized applications I've seen, there is typically a > "lang" or "strings" file that contains all of the strings for a given > application. Then when the code needs a string it will call a global > variable containing that error/warning/info message. This way all of the > needed translation is isolated to a single file. Changing languages becomes > a matter of loading an alternate language file. > > So there could be a collection of language files: > strings.en.js > strings.es.js > strings.fr.js > strnigs.de.js > > And then provide some basic facilities for switching between them. In fact, > each of those files could be a JSON object that gets loaded to a global > object/variable. > > I may be just spewing bad ideas... but so long as the creative juices were > flowing I'd thought I'd share. > > -Duck > > > ----- Original Message ---- > From: Jachym Cepicky > To: Bart van den Eijnden (OSGIS) > Cc: "dev@openlayers" > Sent: Thursday, October 18, 2007 8:58:42 AM > Subject: Re: [OpenLayers-Dev] status of translation possibilities > > Bart van den Eijnden (OSGIS) p??e v ?t 18. 10. 2007 v 15:44 +0200: > > Hi Chris, > > > > I think it is acceptable to have a global setting. I can't imagine a > > common use case (for myself) where one map would be in English and > > another one in Dutch on the same page. It is important though that it is > > possible to switch languages. > > > +1 > > jachym > > > Best regards, > > Bart > > > > Christopher Schmidt schreef: > > > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > > > > > >> Hi, > > >> > > >> I would like to ask about the status of OpenLayers language support. > > >> There are not many strings, which could be translated, however, some > are > > >> there and IMHO we should (de)find a way, how to make this possible. Was > > >> there some discussion to this topic? > > >> > > >> IMHO, new map attribute "lang" should be defined, as well as new method > > >> OpenLayer.Util.getOLString("English text") (or similar). > > >> > > >> Any suggestions? Should I write something like this? Is there already > > >> some code out there? > > >> > > > > > > No code yet, but I agree that now is the time. > > > > > > > http://trac.openlayers.org/wiki/RFC/Internationalization > > > > > > Is my start at an RFC, which never went far enough. > > > > > > My belief is that we should make this a global setting, rather than a > > > per-map configuration. This would mean you could not have multiple > > > languages on the same page at the same time, but would also mean you > > > don't need a reference to the map object in order to get a correct > > > translation string. I don't know if the trade off is worth it. What do > > > other people think? > > > > > > Regards, > > > > > > > > -- > Jachym Cepicky > e-mail: jachym.cepicky@gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > From erik.uzureau at metacarta.com Thu Oct 18 13:23:27 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> Message-ID: <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> or maybe to keep the namespaces straight and clean, more like this: OpenLayers.Strings.languages['english'] = { 'foo': "Foo for president", 'bar': "Bar for gardner" }; OpenLayers.String.setLanguage = function(lang) { OpenLayers.Strings.language = lang; } OpenLayers.String.get = function(strKey) { return OpenLayers.Strings.languages[OpenLayers.String._language][strKey]; } and so: OpenLayers.getString('foo'); or OpenLayers.String.get('foo'); On 10/18/07, Erik Uzureau wrote: > I like this idea a lot. we make a /lang directory and a separate file for > each language. also the use of JSON I think is crafty. > > the file could look something like: > > OpenLayers.Strings['english'] = { > 'foo': "Foo for president", > 'bar': "Bar for gardner" > }; > > OpenLayers.String.setLanguage = function(lang) { > OpenLayers.String._language = lang; > } > > > OpenLayers.String.get = function(strKey) { > return OpenLayers.String[OpenLayers.String._language][strKey]; > } > > > and so: > > > OpenLayers.getString('foo'); > > or > > OpenLayers.String.get('foo'); > > > > this is off the top of my head. > > > On 10/18/07, Dan Little wrote: > > > > I wouldn't think this to be too hard. > > > > In most internationalized applications I've seen, there is typically a > > "lang" or "strings" file that contains all of the strings for a given > > application. Then when the code needs a string it will call a global > > variable containing that error/warning/info message. This way all of the > > needed translation is isolated to a single file. Changing languages becomes > > a matter of loading an alternate language file. > > > > So there could be a collection of language files: > > strings.en.js > > strings.es.js > > strings.fr.js > > strnigs.de.js > > > > And then provide some basic facilities for switching between them. In fact, > > each of those files could be a JSON object that gets loaded to a global > > object/variable. > > > > I may be just spewing bad ideas... but so long as the creative juices were > > flowing I'd thought I'd share. > > > > -Duck > > > > > > ----- Original Message ---- > > From: Jachym Cepicky > > To: Bart van den Eijnden (OSGIS) > > Cc: "dev@openlayers" > > Sent: Thursday, October 18, 2007 8:58:42 AM > > Subject: Re: [OpenLayers-Dev] status of translation possibilities > > > > Bart van den Eijnden (OSGIS) p??e v ?t 18. 10. 2007 v 15:44 +0200: > > > Hi Chris, > > > > > > I think it is acceptable to have a global setting. I can't imagine a > > > common use case (for myself) where one map would be in English and > > > another one in Dutch on the same page. It is important though that it is > > > possible to switch languages. > > > > > +1 > > > > jachym > > > > > Best regards, > > > Bart > > > > > > Christopher Schmidt schreef: > > > > On Thu, Oct 18, 2007 at 03:23:50PM +0200, Jachym Cepicky wrote: > > > > > > > >> Hi, > > > >> > > > >> I would like to ask about the status of OpenLayers language support. > > > >> There are not many strings, which could be translated, however, some > > are > > > >> there and IMHO we should (de)find a way, how to make this possible. Was > > > >> there some discussion to this topic? > > > >> > > > >> IMHO, new map attribute "lang" should be defined, as well as new method > > > >> OpenLayer.Util.getOLString("English text") (or similar). > > > >> > > > >> Any suggestions? Should I write something like this? Is there already > > > >> some code out there? > > > >> > > > > > > > > No code yet, but I agree that now is the time. > > > > > > > > > > http://trac.openlayers.org/wiki/RFC/Internationalization > > > > > > > > Is my start at an RFC, which never went far enough. > > > > > > > > My belief is that we should make this a global setting, rather than a > > > > per-map configuration. This would mean you could not have multiple > > > > languages on the same page at the same time, but would also mean you > > > > don't need a reference to the map object in order to get a correct > > > > translation string. I don't know if the trade off is worth it. What do > > > > other people think? > > > > > > > > Regards, > > > > > > > > > > > > -- > > Jachym Cepicky > > e-mail: jachym.cepicky@gmail.com > > URL: http://les-ejk.cz > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > > From erik.uzureau at metacarta.com Thu Oct 18 13:28:54 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: <20071018130448.GB14361@metacarta.com> References: <20071018130448.GB14361@metacarta.com> Message-ID: <6ae3fb590710181028q6c4c1fc9g6b2f7a2d750c9761@mail.gmail.com> I agree that the firebug files we should leave as-is so we can make upgrading easier (though it would certainly be worth posting a cleanup patch to their project. do onto others...) regarding the rico bits, I say "yes". We've modified them pretty significantly anyways, and I think we're now using them for everything we'll ever need from them. Which is to say, the only reason they're in there is for rounded corners, and I don't anticipate great leaps of innovation in the world of corner rounding. So yeah, let's go ahead and clean that up. Thanks so much for your work on this, Paul. r5002 is a great patch, a non-functional but professionalizing step forward. Muito muito obrigado!!! Erik On 10/18/07, Christopher Schmidt wrote: > On Thu, Oct 18, 2007 at 09:01:57AM -0400, Paul Spencer wrote: > > I have added missing semi-colons and curly braces around all block > > scopes in: > > > > http://trac.openlayers.org/changeset/5002/ > > > > jslint reports the remaining warnings: > > > > /lib/Firebug/firebug.js: 0 error(s), 45 warning(s) > > /lib/Firebug/firebugx.js: 0 error(s), 2 warning(s) > > /lib/Rico/Color.js: 0 error(s), 18 warning(s) > > /lib/Rico/Corner.js: 0 error(s), 36 warning(s) > > > > Do you want me to do anything about these? > > I would prefer we leave the firebug files alone -- I don't think we've > touched those at all. > > I have no strong feelings on Rico: we've already changed those files to > put them in the OpenLayers namespace, further changes don't bother me > much, but I'm also happy to just leave them. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From erik.uzureau at metacarta.com Thu Oct 18 13:38:23 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol library In-Reply-To: <47177BD1.2010508@camptocamp.com> References: <47177BD1.2010508@camptocamp.com> Message-ID: <6ae3fb590710181038u1b66ca7eld29382125278e9d7@mail.gmail.com> Dear Barbara, This project sounds *excellent*. This is just the sort of thing that OpenLayers needs in order to step it up to the next level. In a previous thread, I have proposed the creation of an Addins directory, which all things going right, should probably be together within the next week or so. I think your proposal for an OpenLayers Icons Repository would be a *great* candidate for the Addins directory. I'm sure many people developing OL apps would love to have access to these symbols. Erik On 10/18/07, Barbara Philippot wrote: > Hi, > > > We are trying to improve vector rendering for points geometry, allowing > users to display symbols such as a square, a triangle, a plane, a church > and so on instead of just a circle. > > At present, we have a library in SVG (using the element) and a > library in VML (using the element). Symbols are loaded when > the root element