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 (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 > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From crschmidt at metacarta.com Thu Oct 18 14:31:04 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> Message-ID: <20071018183104.GB31939@metacarta.com> On Thu, Oct 18, 2007 at 12:23:27PM -0500, Erik Uzureau wrote: > or maybe to keep the namespaces straight and clean, more like this: > > OpenLayers.Strings.languages['english'] = { > 'foo': "Foo for president", > 'bar': "Bar for gardner" > }; This seems fine to me. > OpenLayers.String.setLanguage = function(lang) { > OpenLayers.Strings.language = lang; > } setLanguage, if we're going to provide a method for it, is going to need to be more complex than that. We'd have to loop through the controls, and call redraw() on them, to update their text, and I'm not sure that all controls would support a redraw correctly. > OpenLayers.String.get = function(strKey) { > return OpenLayers.Strings.languages[OpenLayers.String._language][strKey]; > } It needs to be more complex than this to support interpolation, and I think it will need to: as the RFC says: "The OpenLayers.String object will have an additional function, translate. Translate will accept a translation key -- a single string which can be used to look up the string -- and any number of additional arguments. If additional arguments are passed, they will be interpolated in the string in order." MapBuilder already has some code that does this, so we can work with them to integrate those bits of it into OpenLayers. It seems there is a general agreement that we need to do this. There are more technical details to work out: * What is the expectation we provide for updating existing langauge strings in the code? For example, controls will probably soon have the ability to display titles in a control.panel object. However, the title property is set on the div when it's created. Do we need to make a redraw() that works for all controls that would use text? Does this block integration of i18n support into core? (See also: CSS support for display, which we didn't block on.) * Do we block putting the library into core until we have all the strings pulled out? (I think that given how little text we have, I think this is 'yes'.) * Do we block all future commits that include text on getting it using the translation system? I think the answer to this is also yes. How far do we go before we put code in trunk? I think that some people who know more about i18n than me should start pondering all the things that an english speaker like me is going to screw up :) MapBuilder's experience here is, again, instructive. Regards, -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Thu Oct 18 15:08:25 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071018183104.GB31939@metacarta.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> Message-ID: <1192734505.8316.30.camel@mellon> Hi, Christopher Schmidt p??e v ?t 18. 10. 2007 v 14:31 -0400: > On Thu, Oct 18, 2007 at 12:23:27PM -0500, Erik Uzureau wrote: > > or maybe to keep the namespaces straight and clean, more like this: > > > > > > OpenLayers.Strings.languages['english'] = { > > 'foo': "Foo for president", > > 'bar': "Bar for gardner" > > }; This is IMHO bad, because it makes things untransparent. I would suggest using whole english strings as key: OpenLayers.Strings.languages['czech'] = { 'Foo for president': "Foo prezidentem!", 'Bar for gardner': "Bar zahradn?kem!" }; more comments below > This seems fine to me. > > > OpenLayers.String.setLanguage = function(lang) { > > OpenLayers.Strings.language = lang; > > } > > setLanguage, if we're going to provide a method for it, is going to need > to be more complex than that. We'd have to loop through the controls, > and call redraw() on them, to update their text, and I'm not sure that > all controls would support a redraw correctly. > > > OpenLayers.String.get = function(strKey) { > > return OpenLayers.Strings.languages[OpenLayers.String._language][strKey]; > > } > > It needs to be more complex than this to support interpolation, and I > think it will need to: as the RFC says: > > "The OpenLayers.String object will have an additional function, > translate. Translate will accept a translation key -- a single string > which can be used to look up the string -- and any number of additional > arguments. If additional arguments are passed, they will be interpolated > in the string in order." > > MapBuilder already has some code that does this, so we can work with > them to integrate those bits of it into OpenLayers. > > It seems there is a general agreement that we need to do this. There are > more technical details to work out: > > * What is the expectation we provide for updating existing langauge > strings in the code? For example, controls will probably soon have > the ability to display titles in a control.panel object. However, the > title property is set on the div when it's created. Do we need to > make a redraw() that works for all controls that would use text? Does > this block integration of i18n support into core? (See also: CSS > support for display, which we didn't block on.) +0 > * Do we block putting the library into core until we have all the > strings pulled out? (I think that given how little text we have, I > think this is 'yes'.) -1 > * Do we block all future commits that include text on getting it using > the translation system? I think the answer to this is also yes. +1 > > How far do we go before we put code in trunk? There should be just general support for this. Methods for setting the language of the map/OpenLayers (Something like ProxyHost) and support for translations files. Translation is a job, which will never be marked as "done". It will always change, the translators never translate everything, and so on. > > I think that some people who know more about i18n than me should start > pondering all the things that an english speaker like me is going to > screw up :) MapBuilder's experience here is, again, instructive. Few more comments: I agree, that there are only few strings in current version. However, this is a job, which will never be marked as done :) Also, one has to distinguish between debugging messages nad standard user messages/strings. Also translation will never be completed just my 2 cents 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/bc3ebe47/attachment.bin From pspencer at dmsolutions.ca Thu Oct 18 15:46:21 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071018183104.GB31939@metacarta.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> Message-ID: On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: > setLanguage, if we're going to provide a method for it, is going to > need > to be more complex than that. We'd have to loop through the controls, > and call redraw() on them, to update their text, and I'm not sure that > all controls would support a redraw correctly. > Could we use an event that is triggered and then controls that have strings can register (or be registered) for the language changing? OpenLayers.String.events.register('languagechange', OpenLayers.Function.bind(this, this.onLanguageChange)); Then it is a matter of implementing support in specific controls that need it or can use it. And if there are things other than controls that can use the current language, they can take advantage easily. For instance, some layer types might be able to use the current language for labeling. And applications (or application frameworks) around OpenLayers could also take advantage of it. We will probably want a LanguageSwitcher control that sets the language and tracks the current language too, mostly for testing and development. We need a way of indicating what languages to support in any given application, and of enumerating the supported languages through the OpenLayers API. We need a way to extend the base set of translations with other, application-specific translations. 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 16:01:13 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> Message-ID: <20071018200113.GA7249@metacarta.com> On Thu, Oct 18, 2007 at 03:46:21PM -0400, Paul Spencer wrote: > > On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: > > >setLanguage, if we're going to provide a method for it, is going to > >need > >to be more complex than that. We'd have to loop through the controls, > >and call redraw() on them, to update their text, and I'm not sure that > >all controls would support a redraw correctly. > > > > Could we use an event that is triggered and then controls that have > strings can register (or be registered) for the language changing? > > OpenLayers.String.events.register('languagechange', > OpenLayers.Function.bind(this, this.onLanguageChange)); I like this idea. I hadn't thought of it, and it makes sense. > We will probably want a LanguageSwitcher control that sets the > language and tracks the current language too, mostly for testing and > development. I'm not convinced that we need that, but if it gets built as part of development, it would probably be useful. > We need a way of indicating what languages to support in any given > application, and of enumerating the supported languages through the > OpenLayers API. for (var key in OpenLayers.Strings.languages) { alert(key); } > We need a way to extend the base set of translations with other, > application-specific translations. OpenLayers.Strings.languages['eng']['My Application String!'] = 'My application String!'; OpenLayers.Strings.languages['spa']['My Application String!'] = '¡String Applicacion de mio!'; Regards, -- Christopher Schmidt MetaCarta From arnd.wippermann at web.de Thu Oct 18 16:09:19 2007 From: arnd.wippermann at web.de (Arnd Wippermann) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] vector layer does not draw at lower resolutions. In-Reply-To: <13219517.post@talk.nabble.com> References: <13219517.post@talk.nabble.com> Message-ID: <13282676.post@talk.nabble.com> Use this map.addLayers([layer,vlayer]); instead of map.addLayer(layer,vlayer); with your code only one layer will added to the map. Arnd Wippermann http://gis.ibbeck.de/ginfo -- View this message in context: http://www.nabble.com/vector-layer-does-not-draw-at-lower-resolutions.-tf4629642.html#a13282676 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From erik.uzureau at metacarta.com Thu Oct 18 17:24:21 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: <20071018183104.GB31939@metacarta.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> Message-ID: <6ae3fb590710181424n51ff8a76y6b05248644cfbd6f@mail.gmail.com> On 10/18/07, Christopher Schmidt wrote: > On Thu, Oct 18, 2007 at 12:23:27PM -0500, Erik Uzureau wrote: > > or maybe to keep the namespaces straight and clean, more like this: > > > > > > OpenLayers.Strings.languages['english'] = { > > 'foo': "Foo for president", > > 'bar': "Bar for gardner" > > }; > > This seems fine to me. > > > OpenLayers.String.setLanguage = function(lang) { > > OpenLayers.Strings.language = lang; > > } > > setLanguage, if we're going to provide a method for it, is going to need > to be more complex than that. We'd have to loop through the controls, > and call redraw() on them, to update their text, and I'm not sure that > all controls would support a redraw correctly. > > > OpenLayers.String.get = function(strKey) { > > return OpenLayers.Strings.languages[OpenLayers.String._language][strKey]; > > } > > It needs to be more complex than this to support interpolation, and I > think it will need to: as the RFC says: > > "The OpenLayers.String object will have an additional function, > translate. Translate will accept a translation key -- a single string > which can be used to look up the string -- and any number of additional > arguments. If additional arguments are passed, they will be interpolated > in the string in order." > > MapBuilder already has some code that does this, so we can work with > them to integrate those bits of it into OpenLayers. ah... you mean, like printf stylie? > It seems there is a general agreement that we need to do this. There are > more technical details to work out: > > * What is the expectation we provide for updating existing langauge > strings in the code? For example, controls will probably soon have > the ability to display titles in a control.panel object. However, the > title property is set on the div when it's created. Do we need to > make a redraw() that works for all controls that would use text? Does > this block integration of i18n support into core? (See also: CSS > support for display, which we didn't block on.) > * Do we block putting the library into core until we have all the > strings pulled out? (I think that given how little text we have, I > think this is 'yes'.) > * Do we block all future commits that include text on getting it using > the translation system? I think the answer to this is also yes. > > How far do we go before we put code in trunk? > > I think that some people who know more about i18n than me should start > pondering all the things that an english speaker like me is going to > screw up :) MapBuilder's experience here is, again, instructive. > > Regards, > -- > Christopher Schmidt > MetaCarta > From erik.uzureau at metacarta.com Thu Oct 18 17:29:41 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: <20071018200113.GA7249@metacarta.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <20071018200113.GA7249@metacarta.com> Message-ID: <6ae3fb590710181429n182c547bld43f7be10bbcaedc@mail.gmail.com> On 10/18/07, Christopher Schmidt wrote: > On Thu, Oct 18, 2007 at 03:46:21PM -0400, Paul Spencer wrote: > > > > On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: > > > > >setLanguage, if we're going to provide a method for it, is going to > > >need > > >to be more complex than that. We'd have to loop through the controls, > > >and call redraw() on them, to update their text, and I'm not sure that > > >all controls would support a redraw correctly. > > > > > > > Could we use an event that is triggered and then controls that have > > strings can register (or be registered) for the language changing? > > > > OpenLayers.String.events.register('languagechange', > > OpenLayers.Function.bind(this, this.onLanguageChange)); > > I like this idea. I hadn't thought of it, and it makes sense. yes, i like it to. the only thing i dont like about it is that it seems like it might sort of be a burden to control developers to have to deal with registering events. to that end, we might consider such a thing as making the base OpenLayers.Control's constructor register the listener and call a stub function udpateLanguage() or something like that. In OpenLayers.Control, the stub function would do nothing. Then if controls _do_ wish to update on language changes, they need only implement the updateLanguage(). This might help in the case of a control that is subclassed from another control -- the updateLanguage() calls would be chained up, instead of having to register a separate listener for each class. I dunno. This is just the first thing that comes to mind... that as a control developer it seems like kind of a PITA and or unnecessary overhead to be registering more listeners. --E > > > We will probably want a LanguageSwitcher control that sets the > > language and tracks the current language too, mostly for testing and > > development. > > I'm not convinced that we need that, but if it gets built as part of > development, it would probably be useful. > > > We need a way of indicating what languages to support in any given > > application, and of enumerating the supported languages through the > > OpenLayers API. > > for (var key in OpenLayers.Strings.languages) { > alert(key); > } > > > We need a way to extend the base set of translations with other, > > application-specific translations. > > OpenLayers.Strings.languages['eng']['My Application String!'] = 'My > application String!'; > > OpenLayers.Strings.languages['spa']['My Application String!'] = > '?String Applicacion de mio!'; > > Regards, > -- > Christopher Schmidt > MetaCarta > From gertjan at West.NL Fri Oct 19 07:05:18 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <6ae3fb590710181424n51ff8a76y6b05248644cfbd6f@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <20071018133356.GA19498@metacarta.com> References: <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> Message-ID: <20071019110518.GA5597@West.NL> As quoted from Christopher Schmidt : > It needs to be more complex than this to support interpolation, and I > think it will need to: as the RFC says: [ http://trac.openlayers.org/wiki/RFC/Internationalization ] > "The OpenLayers.String object will have an additional function, > translate. Translate will accept a translation key -- a single string > which can be used to look up the string -- and any number of additional > arguments. If additional arguments are passed, they will be interpolated > in the string in order." > > MapBuilder already has some code that does this, so we can work with > them to integrate those bits of it into OpenLayers. As I wrote on the I18N thread mid-July (see below), OpenLayers can just copy the interpolation function I wrote for MapBuilder. So interpolation capabilities are more or less a given. The only question remaining is how to get the i18n'ed strings into (and out of) the Openlayers code. I have never come across a real-life use case where you would want i18n data to be displayed in mixed-language in one application, so a single, global language setting would suffice for the majority of cases. Note that even when you have i18n texts, you still need to take into account that the developer adding new strings to the code and the people doing the translation thereof into the other supported languages are generally not the same. Which means you need some sort of fall-back mechanism for message keys that remain as yet untranslated. In MapBuilder the fall back is on the default language "en". To start off, I guess simple language tags ("en", "nl", "fr", ...) will suffice. If and when people want to support language subtags ("en-GB", "en-US", "nl-NL", "nl-BE", "fr-FR", "fr-CA", ...) you should also incorporate a fall back from the subtagged language on the more general language tag. For MapBuilder this is still on my TODO list; there has been no demand for it yet. [See http://communitymapbuilder.org/display/MAP/Add+Translations for complete information on how MapBuilder does things.] Anyway, to quote myself on interpolation ;-) : [...] the function mbFormatMessage() I wrote, copied below from trunk/lib/util/Util.js for your convenience, can be used straight out-of-the-box to get simple interpolation. Since at the top of the file it clearly states that it is LGPL, nothing is stopping you. 8-) /** * Format a message with the extra arguments.
* E.g. if called as: mbFormatMessage("{1} is {0} {2}, {1}", "a good", "this", "test")
* the formatted message returned is: "this is a good test, this" * @param messageFormat the message format string * @param varArgs optional extra parameters for formatting the message * @return the formatted message */ function mbFormatMessage(messageFormat) { var message = messageFormat; var varArgs = [].slice.call(arguments, mbFormatMessage.length); for (var i in varArgs) { var parm = new RegExp("\\{" + i + "\\}", "g"); message = message.replace(parm, varArgs[i]); } return message; } Regards, -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From gertjan at West.NL Fri Oct 19 07:17:04 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:36 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: <20071019111704.GB5597@West.NL> As quoted from "Steven M. Ottens" : > 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. The grouping thing is only supported in the OWSContext spec I believe (not in the WMC). The future of the OWSContext spec is unclear to me, BTW. > 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. I don't think I did that, I seem to recall Olivier (Cc'ed) did that? Regards, -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From crschmidt at metacarta.com Fri Oct 19 07:47:21 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019110518.GA5597@West.NL> References: <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> Message-ID: <20071019114721.GE1322@metacarta.com> On Fri, Oct 19, 2007 at 01:05:18PM +0200, Gertjan van Oosten wrote: > Note that even when you have i18n texts, you still need to take into > account that the developer adding new strings to the code and the people > doing the translation thereof into the other supported languages are > generally not the same. Which means you need some sort of fall-back > mechanism for message keys that remain as yet untranslated. In > MapBuilder the fall back is on the default language "en". Good point. I had forgotten about that. We should update teh RFC to take that (and other things in this thread) into account. > Anyway, to quote myself on interpolation ;-) : Right, I remembered this message. Per the OpenLayers commit policy, we prefer (unless absolutely neccesary) to get a CLA for submissions from their author, so they can be released under ClearBSD. (Understaning the legal implications of LGPL is way more than I have the legal brain cells for.) I assume that's not really a problem, but I'm mentioniong it anyway :) I'll come back to it when we get that far in the code. Regards, -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Fri Oct 19 09:08:35 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019114721.GE1322@metacarta.com> References: <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> Message-ID: <1192799315.7995.19.camel@mellon> Hi Christopher Schmidt p??e v P? 19. 10. 2007 v 07:47 -0400: > On Fri, Oct 19, 2007 at 01:05:18PM +0200, Gertjan van Oosten wrote: > > Note that even when you have i18n texts, you still need to take into > > account that the developer adding new strings to the code and the people > > doing the translation thereof into the other supported languages are > > generally not the same. Which means you need some sort of fall-back > > mechanism for message keys that remain as yet untranslated. In > > MapBuilder the fall back is on the default language "en". > > Good point. I had forgotten about that. We should update teh RFC to take > that (and other things in this thread) into account. > I was thinking, that rather then return default "en" translation, it could return the untranslated message back. Since I still suppose, translation keys will be strings in english, result will be the same. Jachym > > Anyway, to quote myself on interpolation ;-) : > > Right, I remembered this message. Per the OpenLayers commit policy, we > prefer (unless absolutely neccesary) to get a CLA for submissions from > their author, so they can be released under ClearBSD. (Understaning the > legal implications of LGPL is way more than I have the legal brain cells > for.) I assume that's not really a problem, but I'm mentioniong it > anyway :) I'll come back to it when we get that far in the code. > > 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/20071019/dd423f2a/attachment.bin From rohith.kota at uai.com Fri Oct 19 09:56:04 2007 From: rohith.kota at uai.com (Rohith Kota) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] vector layer does not draw at lower resoluti ons. Message-ID: <76758090F8686C47A44B6FF52514A1D308681C7B@hermes.uai.int> I did try as you have suggested, but without any luck. If you move the zoom bar to the lowest level and try to draw vector it does not draw rather it would be on zoom level 2 bar higher. thanks rohith kota 327-3925 -----Original Message----- From: dev-bounces@openlayers.org [mailto:dev-bounces@openlayers.org]On Behalf Of Arnd Wippermann Sent: Thursday, October 18, 2007 3:09 PM To: dev@openlayers.org Subject: Re: [OpenLayers-Dev] vector layer does not draw at lower resolutions. Use this map.addLayers([layer,vlayer]); instead of map.addLayer(layer,vlayer); with your code only one layer will added to the map. Arnd Wippermann http://gis.ibbeck.de/ginfo -- View this message in context: http://www.nabble.com/vector-layer-does-not-draw-at-lower-resolutions.-tf462 9642.html#a13282676 Sent from the OpenLayers Dev mailing list archive at Nabble.com. _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev 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 19 10:18:27 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <1192799315.7995.19.camel@mellon> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> <1192799315.7995.19.camel@mellon> Message-ID: <20071019141827.GA11728@metacarta.com> On Fri, Oct 19, 2007 at 03:08:35PM +0200, Jachym Cepicky wrote: > Hi > Christopher Schmidt p????e v P?? 19. 10. 2007 v 07:47 -0400: > > On Fri, Oct 19, 2007 at 01:05:18PM +0200, Gertjan van Oosten wrote: > > > Note that even when you have i18n texts, you still need to take into > > > account that the developer adding new strings to the code and the people > > > doing the translation thereof into the other supported languages are > > > generally not the same. Which means you need some sort of fall-back > > > mechanism for message keys that remain as yet untranslated. In > > > MapBuilder the fall back is on the default language "en". > > > > Good point. I had forgotten about that. We should update teh RFC to take > > that (and other things in this thread) into account. > > > > I was thinking, that rather then return default "en" translation, it > could return the untranslated message back. Since I still suppose, > translation keys will be strings in english, result will be the same. Right. Though perhaps support for a 'fallback' language in addition to just returning the translation string makes sense? It wouldn't be that hard, in any case -- a couple extra lines of code in String.translate() Regards, -- Christopher Schmidt MetaCarta From jachym.cepicky at gmail.com Fri Oct 19 10:48:31 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019141827.GA11728@metacarta.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> <1192799315.7995.19.camel@mellon> <20071019141827.GA11728@metacarta.com> Message-ID: <1192805311.7995.23.camel@mellon> Christopher Schmidt p??e v P? 19. 10. 2007 v 10:18 -0400: > On Fri, Oct 19, 2007 at 03:08:35PM +0200, Jachym Cepicky wrote: > > > Good point. I had forgotten about that. We should update teh RFC to take > > > that (and other things in this thread) into account. > > > > > > > I was thinking, that rather then return default "en" translation, it > > could return the untranslated message back. Since I still suppose, > > translation keys will be strings in english, result will be the same. > > Right. Though perhaps support for a 'fallback' language in addition to > just returning the translation string makes sense? It wouldn't be that > hard, in any case -- a couple extra lines of code in String.translate() > > Regards, just to be sure: "support" yes, but not "assume", everything will always be translated even in "fallback" language 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/20071019/a696021f/attachment.bin From barbara.philippot at camptocamp.com Fri Oct 19 11:18:32 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 In-Reply-To: References: Message-ID: <4718CAC8.7020705@camptocamp.com> Ian Mayo a ?crit : > 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. > Yes, this is why we are trying to do. But people would have to specify two filenames (one in SVG, the other in VML) to replace the pre-existing symbol catalogue files and it's not still the ideal solution but perhaps it's the only one. > 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. > Well, I hadn't considered using symbols in a georss feed and I don't know well Georss format. For the moment, symbols are associated with points geometry with a style.use="symbol" in the same way as images were associated with style.externalGraphic. So, I haven't looked in detail to the way you attach icons to GeoRss nodes but it seems that you would be able to use SVG and VML symbols as well as images. I hope to make progress before your development pause ends :-) > Ian. > > 1. http://trac.openlayers.org/ticket/1073 > 2. http://dev.openlayers.org/sandbox/ianmayo/branches/rss/openlayers/examples/georss.html > > From gertjan at West.NL Fri Oct 19 11:37:46 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <1192805311.7995.23.camel@mellon> References: <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> <1192799315.7995.19.camel@mellon> <20071019141827.GA11728@metacarta.com> <1192805311.7995.23.camel@mellon> Message-ID: <20071019153746.GB6468@West.NL> As quoted from Jachym Cepicky : > Christopher Schmidt p???e v P? 19. 10. 2007 v 10:18 -0400: > > On Fri, Oct 19, 2007 at 03:08:35PM +0200, Jachym Cepicky wrote: > > > > Good point. I had forgotten about that. We should update teh RFC to take > > > > that (and other things in this thread) into account. > > > > > > I was thinking, that rather then return default "en" translation, it > > > could return the untranslated message back. Since I still suppose, > > > translation keys will be strings in english, result will be the same. > > > > Right. Though perhaps support for a 'fallback' language in addition to > > just returning the translation string makes sense? It wouldn't be that > > hard, in any case -- a couple extra lines of code in String.translate() > > just to be sure: "support" yes, but not "assume", everything will always > be translated even in "fallback" language In MapBuilder we use message keys to look up the message; think of mnemonical names like featureNotFound or pointProjectsToInfinity. If a messageKey is not found for the selected language, and the messageKey is not found for the default language, then the messageKey itself is returned as the message. That way you a. get at least some message for every key and b. can easily inspect visually that a messageKey has not yet been translated into even the default language. Regards, -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From gertjan at West.NL Fri Oct 19 11:41:17 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019153746.GB6468@West.NL> References: <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> <1192799315.7995.19.camel@mellon> <20071019141827.GA11728@metacarta.com> <1192805311.7995.23.camel@mellon> <20071019153746.GB6468@West.NL> Message-ID: <20071019154117.GA8385@West.NL> > If a messageKey is not found for the selected language, and the > messageKey is not found for the default language, then the messageKey > itself is returned as the message. To be complete: if no messages at all are found (yes, that can happen with MapBuilder if e.g. a wrong widgetText directory is specified in the config) it returns "NoMsgsFound". Not sure if that could happen with OpenLayers though. Regards, -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From jachym.cepicky at gmail.com Fri Oct 19 11:44:35 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019153746.GB6468@West.NL> References: <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> <20071019114721.GE1322@metacarta.com> <1192799315.7995.19.camel@mellon> <20071019141827.GA11728@metacarta.com> <1192805311.7995.23.camel@mellon> <20071019153746.GB6468@West.NL> Message-ID: <1192808675.7995.35.camel@mellon> Gertjan van Oosten p??e v P? 19. 10. 2007 v 17:37 +0200: > In MapBuilder we use message keys to look up the message; think of > mnemonical names like featureNotFound or pointProjectsToInfinity. > If a messageKey is not found for the selected language, and the > messageKey is not found for the default language, then the messageKey > itself is returned as the message. That way you a. get at least some > message for every key and b. can easily inspect visually that a > messageKey has not yet been translated into even the default language. > yes. only difference is, I'm suggesting not to use specified messageKeys, but strings itself, because it can be IMHO fast mess. Otherwise, the concept is exactly that, what I would expect. 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/20071019/f30d7bc2/attachment.bin From tschaub at openplans.org Fri Oct 19 12:38:46 2007 From: tschaub at openplans.org (Tim Schaub) 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: <4718DD96.8000102@openplans.org> Hey- 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. > We ship a patched version of firebug lite. See http://code.google.com/p/fbug/issues/detail?id=85 I'd rather not patch it any further, as it looks like even that patch might not get any attention. More importantly, we don't concatenate/compress firebug in the single file builds. If anybody does this, they should be scolded. So, no need to modify firebug (any more than I have) as far as I'm concerned. Thanks for fixing the other issues Paul. Tim > 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, From val.cartei at gmail.com Fri Oct 19 12:38:50 2007 From: val.cartei at gmail.com (Val Cartei) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] use openlayers for images Message-ID: Instead of using maps, I'd like to extend the OpenLayers functions to be able to manipulate other images too. This is what I have got so far: http://dev.getconveyor.org/panorama_experiments/15 The main issue I am having at the moment is that I can't make the library not to use resolution info. The image should be displayed to its original resolution (as if displayed in a browser) and the overviewmap built accordingly. Has anyone 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/20071019/ab56fc07/attachment.html From pspencer at dmsolutions.ca Fri Oct 19 12:42:38 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: <4718DD96.8000102@openplans.org> References: <20071018130448.GB14361@metacarta.com> <4718DD96.8000102@openplans.org> Message-ID: On 19-Oct-07, at 12:38 PM, Tim Schaub wrote: >>> /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. >> > > We ship a patched version of firebug lite. See > http://code.google.com/p/fbug/issues/detail?id=85 > > I'd rather not patch it any further, as it looks like even that patch > might not get any attention. > > More importantly, we don't concatenate/compress firebug in the single > file builds. If anybody does this, they should be scolded. > for the record, I did fix the above warnings in Rico/* and did NOT touch firebug. As Tim indicates, it doesn't affect the final build. As of now, the final full build is 'lint free' with my current settings, which makes me very happy :) I may look at some of the other settings to see if there is anything else we could potentially benefit from in the newer version of jslint which I discovered last night ... Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From pspencer at dmsolutions.ca Fri Oct 19 12:46:35 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] use openlayers for images In-Reply-To: References: Message-ID: <118744D3-6118-4539-8D67-2299EDEBC7A3@dmsolutions.ca> I did something similar to show pre-built tiles in pixel space, how about something like: olMap = new OpenLayers.Map( 'map', {maxExtent: new OpenLayers.Bounds(0, 0, 4000, 4000), minResolution: 1.0, maxResolution: 1.0, controls: []}); Paul On 19-Oct-07, at 12:38 PM, Val Cartei wrote: > Instead of using maps, I'd like to extend the OpenLayers functions > to be able to manipulate other images too. > This is what I have got so far: > http://dev.getconveyor.org/panorama_experiments/15 > The main issue I am having at the moment is that I can't make the > library not to use resolution info. The image should be displayed > to its original resolution (as if displayed in a browser) and the > overviewmap built accordingly. > Has anyone suggestions? > > -- > Best Regards, > > Valentina Cartei > UK Tel. +44 (0)796 6882820 > _______________________________________________ > 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 olivier.terral at geomatys.fr Fri Oct 19 12:47:27 2007 From: olivier.terral at geomatys.fr (olivier.terral) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <20071019111704.GB5597@West.NL> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> <4715D475.4080409@minst.net> <20071019111704.GB5597@West.NL> Message-ID: <4718DF9F.1090002@geomatys.fr> Ola, Sorry , I think it's Vincent Schut who did that but I 've often manipulated Group layers . I don't know what is it specified in OWS spec but I know what is done in Mapbuilder. We have choosen to add in an Extension tag because the spec was not clear with groups and the Extension tag permits to add everything we want (that's I've understood). All groups are specified inside the General/Extension tags : and if a Layer is a member of a Group, it's specified in its extension tag like said Steven But actually, this way of define groups is very limited because there is only one level possible. May be we should improve this solution to permit a tree view as I've seen in the demo of Arm?n http://rips-uis.lubw.baden-wuerttemberg.de/rips/wms_viewer/test/myOpenLayer.php Gertjan van Oosten a ?crit : > As quoted from "Steven M. Ottens" : > >> 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. >> > > The grouping thing is only supported in the OWSContext spec I believe > (not in the WMC). The future of the OWSContext spec is unclear to me, BTW. > > >> 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. >> > > I don't think I did that, I seem to recall Olivier (Cc'ed) did that? > > Regards, > From tschaub at openplans.org Fri Oct 19 12:53:52 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> Message-ID: <4718E120.6000401@openplans.org> Or we could do like others and give elements that contain strings that need translating a unique attribute. Simplified, this could look something like this: foo in my lang Then, switching languages would comb through all elements on the page, replacing the content of those with i18n attributes - determining the appropriate content based on the global lang setting and the value of the key in the appropriate dictionary. Not efficient, but simple. Tim PS - I don't think we should go too heavy here because I think OL as a mapping library should contain very few strings if any. How can we get strings out of the library you ask? Use templates to make things like the layer switcher - instead of cramming a bunch of text node creation code in the controls. Paul Spencer wrote: > On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: > >> setLanguage, if we're going to provide a method for it, is going to >> need >> to be more complex than that. We'd have to loop through the controls, >> and call redraw() on them, to update their text, and I'm not sure that >> all controls would support a redraw correctly. >> > > Could we use an event that is triggered and then controls that have > strings can register (or be registered) for the language changing? > > OpenLayers.String.events.register('languagechange', > OpenLayers.Function.bind(this, this.onLanguageChange)); > > Then it is a matter of implementing support in specific controls that > need it or can use it. And if there are things other than controls > that can use the current language, they can take advantage easily. > For instance, some layer types might be able to use the current > language for labeling. And applications (or application frameworks) > around OpenLayers could also take advantage of it. > > We will probably want a LanguageSwitcher control that sets the > language and tracks the current language too, mostly for testing and > development. > > We need a way of indicating what languages to support in any given > application, and of enumerating the supported languages through the > OpenLayers API. > > We need a way to extend the base set of translations with other, > application-specific translations. > > 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,4717b81f246325210051143! > From tschaub at openplans.org Fri Oct 19 13:18:44 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <6ae3fb590710181429n182c547bld43f7be10bbcaedc@mail.gmail.com> References: <926726.10161.qm@web51402.mail.re2.yahoo.com> <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <20071018200113.GA7249@metacarta.com> <6ae3fb590710181429n182c547bld43f7be10bbcaedc@mail.gmail.com> Message-ID: <4718E6F4.6010103@openplans.org> I think we should organize thoughts with these use cases in mind. Please correct me as you see fit - but this is how I see things breaking down (descending order based on number of people in each group). 1) people who want a single language (theirs) 2) people who want dynamic translation I almost put 0) people who don't know about language since that is the case that OpenLayers currently considers - but I didn't want to make anybody angry. Anyway, I'd like to see things done so we don't sacrifice efficiency for people who want a single file build that just includes their single language. Having every element that contains a string registered as an event listener starts sounding a bit heavy for this case. And, in terms of parsing strings for formatting, isn't it enough to break elements up based on the portions that can be translated:

OpenLayers rocks

? This doesn't work for alert(str), but I happen to think we should purge alerts from the library. Being contrary, Tim PS- Also, I know the i18n attribute is too simple to deal with element attribute values that need translating themselves (translate me). In that case, we need multiple attributes in the i18n namespace (something akin to http://wiki.zope.org/zope3/ZPTInternationalizationSupport). Erik Uzureau wrote: > On 10/18/07, Christopher Schmidt wrote: >> On Thu, Oct 18, 2007 at 03:46:21PM -0400, Paul Spencer wrote: >>> On 18-Oct-07, at 2:31 PM, Christopher Schmidt wrote: >>> >>>> setLanguage, if we're going to provide a method for it, is going to >>>> need >>>> to be more complex than that. We'd have to loop through the controls, >>>> and call redraw() on them, to update their text, and I'm not sure that >>>> all controls would support a redraw correctly. >>>> >>> Could we use an event that is triggered and then controls that have >>> strings can register (or be registered) for the language changing? >>> >>> OpenLayers.String.events.register('languagechange', >>> OpenLayers.Function.bind(this, this.onLanguageChange)); >> I like this idea. I hadn't thought of it, and it makes sense. > > yes, i like it to. the only thing i dont like about it is that it > seems like it might sort of be a burden to control developers to have > to deal with registering events. > > to that end, we might consider such a thing as making the base > OpenLayers.Control's constructor register the listener and call a stub > function udpateLanguage() or something like that. In > OpenLayers.Control, the stub function would do nothing. Then if > controls _do_ wish to update on language changes, they need only > implement the updateLanguage(). > > This might help in the case of a control that is subclassed from > another control -- the updateLanguage() calls would be chained up, > instead of having to register a separate listener for each class. > > I dunno. This is just the first thing that comes to mind... that as a > control developer it seems like kind of a PITA and or unnecessary > overhead to be registering more listeners. > > --E > > >>> We will probably want a LanguageSwitcher control that sets the >>> language and tracks the current language too, mostly for testing and >>> development. >> I'm not convinced that we need that, but if it gets built as part of >> development, it would probably be useful. >> >>> We need a way of indicating what languages to support in any given >>> application, and of enumerating the supported languages through the >>> OpenLayers API. >> for (var key in OpenLayers.Strings.languages) { >> alert(key); >> } >> >>> We need a way to extend the base set of translations with other, >>> application-specific translations. >> OpenLayers.Strings.languages['eng']['My Application String!'] = 'My >> application String!'; >> >> OpenLayers.Strings.languages['spa']['My Application String!'] = >> '?String Applicacion de mio!'; >> >> Regards, >> -- >> Christopher Schmidt >> MetaCarta >> > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,4717d058293873327367457! > From tschaub at openplans.org Fri Oct 19 13:30:26 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: References: <20071018130448.GB14361@metacarta.com> <4718DD96.8000102@openplans.org> Message-ID: <4718E9B2.9010308@openplans.org> Hey- Paul Spencer wrote: > > for the record, I did fix the above warnings in Rico/* and did NOT touch > firebug. As Tim indicates, it doesn't affect the final build. As of > now, the final full build is 'lint free' with my current settings, which > makes me very happy :) I may look at some of the other settings to see > if there is anything else we could potentially benefit from in the newer > version of jslint which I discovered last night ... > Paul, I'd also be interested in the result of disallowing use of undefined variables. Perhaps you already talked about this and I missed it. What would be really cool is if jslint could be tweaked to look for variable assignment outside of the OpenLayers namespace - something we occasionally stumble across and have no way of testing for. (I know a case where window.i == 2 and I cannot figure out why.) This might even be caught by the "no undefined variables" filter if it is initialized without the var keyword (which is likely). Tim > Cheers > > Paul > > +-----------------------------------------------------------------+ > |Paul Spencer pspencer@dmsolutions.ca | > +-----------------------------------------------------------------+ > |Chief Technology Officer | > |DM Solutions Group Inc http://www.dmsolutions.ca/ | > +-----------------------------------------------------------------+ > > > > > > > !DSPAM:4033,4718de8133771961014482! > From pspencer at dmsolutions.ca Fri Oct 19 15:33:40 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: <4718E9B2.9010308@openplans.org> References: <20071018130448.GB14361@metacarta.com> <4718DD96.8000102@openplans.org> <4718E9B2.9010308@openplans.org> Message-ID: <3F98421E-0C63-4763-B2C2-3F727AE79D11@dmsolutions.ca> For those of you that are not on IRC, Tim and I worked this out this afternoon and I committed: http://trac.openlayers.org/changeset/5028 which cleans up some 29 instances of local scope variables used without 'var', making them global in scope. This is now part of my regularly scheduled routine :) Cheers Paul On 19-Oct-07, at 1:30 PM, Tim Schaub wrote: > Hey- > > Paul Spencer wrote: >> >> for the record, I did fix the above warnings in Rico/* and did NOT >> touch >> firebug. As Tim indicates, it doesn't affect the final build. As of >> now, the final full build is 'lint free' with my current settings, >> which >> makes me very happy :) I may look at some of the other settings >> to see >> if there is anything else we could potentially benefit from in the >> newer >> version of jslint which I discovered last night ... >> > > Paul, I'd also be interested in the result of disallowing use of > undefined variables. Perhaps you already talked about this and I > missed it. > > What would be really cool is if jslint could be tweaked to look for > variable assignment outside of the OpenLayers namespace - something we > occasionally stumble across and have no way of testing for. (I know a > case where window.i == 2 and I cannot figure out why.) This might > even > be caught by the "no undefined variables" filter if it is initialized > without the var keyword (which is likely). > > Tim > >> Cheers >> >> Paul >> >> +-----------------------------------------------------------------+ >> |Paul Spencer pspencer@dmsolutions.ca | >> +-----------------------------------------------------------------+ >> |Chief Technology Officer | >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> >> >> !DSPAM:4033,4718de8133771961014482! >> > > _______________________________________________ > 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 pspencer at dmsolutions.ca Fri Oct 19 15:35:15 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jslint cleanup committed In-Reply-To: <3F98421E-0C63-4763-B2C2-3F727AE79D11@dmsolutions.ca> References: <20071018130448.GB14361@metacarta.com> <4718DD96.8000102@openplans.org> <4718E9B2.9010308@openplans.org> <3F98421E-0C63-4763-B2C2-3F727AE79D11@dmsolutions.ca> Message-ID: <62EC14F9-9730-4628-A62A-9AF684F8E6F7@dmsolutions.ca> 19 instances, not 29. Next, I will get a calculator and learn to add ... On 19-Oct-07, at 3:33 PM, Paul Spencer wrote: > For those of you that are not on IRC, Tim and I worked this out > this afternoon and I committed: > > http://trac.openlayers.org/changeset/5028 > > which cleans up some 29 instances of local scope variables used > without 'var', making them global in scope. This is now part of my > regularly scheduled routine :) > > Cheers > > Paul > > On 19-Oct-07, at 1:30 PM, Tim Schaub wrote: > >> Hey- >> >> Paul Spencer wrote: >>> >>> for the record, I did fix the above warnings in Rico/* and did >>> NOT touch >>> firebug. As Tim indicates, it doesn't affect the final build. >>> As of >>> now, the final full build is 'lint free' with my current >>> settings, which >>> makes me very happy :) I may look at some of the other settings >>> to see >>> if there is anything else we could potentially benefit from in >>> the newer >>> version of jslint which I discovered last night ... >>> >> >> Paul, I'd also be interested in the result of disallowing use of >> undefined variables. Perhaps you already talked about this and I >> missed it. >> >> What would be really cool is if jslint could be tweaked to look for >> variable assignment outside of the OpenLayers namespace - >> something we >> occasionally stumble across and have no way of testing for. (I >> know a >> case where window.i == 2 and I cannot figure out why.) This might >> even >> be caught by the "no undefined variables" filter if it is initialized >> without the var keyword (which is likely). >> >> Tim >> >>> Cheers >>> >>> Paul >>> >>> +-----------------------------------------------------------------+ >>> |Paul Spencer pspencer@dmsolutions.ca | >>> +-----------------------------------------------------------------+ >>> |Chief Technology Officer | >>> |DM Solutions Group Inc http://www.dmsolutions.ca/ | >>> +-----------------------------------------------------------------+ >>> >>> >>> >>> >>> >>> >>> !DSPAM:4033,4718de8133771961014482! >>> >> >> _______________________________________________ >> 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/ | > +-----------------------------------------------------------------+ > > > > > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From lorenzo at ominiverdi.com Fri Oct 19 16:09:05 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <4718DF9F.1090002@geomatys.fr> References: <1192447207.7829.52.camel@mellon> <471355A2.9040803@ominiverdi.com> <4713F885.9060004@gmail.com> <4715D475.4080409@minst.net> <20071019111704.GB5597@West.NL> <4718DF9F.1090002@geomatys.fr> Message-ID: <47190EE1.3030206@ominiverdi.com> Hi Olivier, > May be we should improve this solution to permit a tree view as I've > seen in the demo of Arm?n > I think too we shoud choose something all together and try to use osgeo-standards mailing list to make lobby and help OGC to go in a good direction. As we are dealing with OGC standards, why don't we use the solution already used by WMS? well, it's a bit I'm not revisioning the specs but should be something like this: my group of level 1 my group of layer 2 layer_1 .... layer_2 .... layer3 ciao Lorenzo olivier.terral wrote: > Ola, > > Sorry , I think it's Vincent Schut who did that but I 've often > manipulated Group layers . > > I don't know what is it specified in OWS spec but I know what is done > in Mapbuilder. > We have choosen to add in an Extension tag because the spec was > not clear with groups and the Extension tag permits to add everything we > want (that's I've understood). > > All groups are specified inside the General/Extension tags : > > > > > > > > > > > > and if a Layer is a member of a Group, it's specified in its extension > tag like said Steven > > > > > > But actually, this way of define groups is very limited because there is > only one level possible. > > May be we should improve this solution to permit a tree view as I've > seen in the demo of Arm?n > > http://rips-uis.lubw.baden-wuerttemberg.de/rips/wms_viewer/test/myOpenLayer.php > > > Gertjan van Oosten a ?crit : > >> As quoted from "Steven M. Ottens" : >> >> >>> 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. >>> >>> >> The grouping thing is only supported in the OWSContext spec I believe >> (not in the WMC). The future of the OWSContext spec is unclear to me, BTW. >> >> >> >>> 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. >>> >>> >> I don't think I did that, I seem to recall Olivier (Cc'ed) did that? >> >> Regards, >> >> > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From cameron.shorter at gmail.com Fri Oct 19 17:34:41 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <20071019110518.GA5597@West.NL> References: <6ae3fb590710181022n5151ef06wadc5d87b5f2b32d@mail.gmail.com> <6ae3fb590710181023j1bf6cb0cmcfe58b201207bdc2@mail.gmail.com> <20071018183104.GB31939@metacarta.com> <926726.10161.qm@web51402.mail.re2.yahoo.com> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <17AD4DD1-AF6F-44AE-9D72-3D6CFB1EB2F0@dmsolutions.ca> <1192713830.8316.9.camel@mellon> <20071018133356.GA19498@metacarta.com> <20071019110518.GA5597@West.NL> Message-ID: <471922F1.1050509@gmail.com> I think this is another candidate for functionality from Mapbuilder to be migrated to Openlayers or maybe the new Openlayers Addins directory. Mapbuilder can then access functionality by calling Openlayers. It would probably involve a little reformatting of code to fit the Openlayers style guide. Gertjan would be able to talk to this further. Gertjan van Oosten wrote: > As quoted from Christopher Schmidt : > >> It needs to be more complex than this to support interpolation, and I >> think it will need to: as the RFC says: >> > [ http://trac.openlayers.org/wiki/RFC/Internationalization ] > >> "The OpenLayers.String object will have an additional function, >> translate. Translate will accept a translation key -- a single string >> which can be used to look up the string -- and any number of additional >> arguments. If additional arguments are passed, they will be interpolated >> in the string in order." >> >> MapBuilder already has some code that does this, so we can work with >> them to integrate those bits of it into OpenLayers. >> > > As I wrote on the I18N thread mid-July (see below), OpenLayers can just > copy the interpolation function I wrote for MapBuilder. So > interpolation capabilities are more or less a given. The only question > remaining is how to get the i18n'ed strings into (and out of) the > Openlayers code. I have never come across a real-life use case where > you would want i18n data to be displayed in mixed-language in one > application, so a single, global language setting would suffice for the > majority of cases. > > Note that even when you have i18n texts, you still need to take into > account that the developer adding new strings to the code and the people > doing the translation thereof into the other supported languages are > generally not the same. Which means you need some sort of fall-back > mechanism for message keys that remain as yet untranslated. In > MapBuilder the fall back is on the default language "en". > > To start off, I guess simple language tags ("en", "nl", "fr", ...) will > suffice. If and when people want to support language subtags ("en-GB", > "en-US", "nl-NL", "nl-BE", "fr-FR", "fr-CA", ...) you should also > incorporate a fall back from the subtagged language on the more general > language tag. For MapBuilder this is still on my TODO list; there has > been no demand for it yet. > > [See http://communitymapbuilder.org/display/MAP/Add+Translations > for complete information on how MapBuilder does things.] > > Anyway, to quote myself on interpolation ;-) : > > > [...] the function mbFormatMessage() I wrote, copied below from > trunk/lib/util/Util.js for your convenience, can be used straight > out-of-the-box to get simple interpolation. Since at the top of the > file it clearly states that it is LGPL, nothing is stopping you. 8-) > > /** > * Format a message with the extra arguments.
> * E.g. if called as: mbFormatMessage("{1} is {0} {2}, {1}", "a good", "this", "test")
> * the formatted message returned is: "this is a good test, this" > * @param messageFormat the message format string > * @param varArgs optional extra parameters for formatting the message > * @return the formatted message > */ > function mbFormatMessage(messageFormat) > { > var message = messageFormat; > var varArgs = [].slice.call(arguments, mbFormatMessage.length); > for (var i in varArgs) { > var parm = new RegExp("\\{" + i + "\\}", "g"); > message = message.replace(parm, varArgs[i]); > } > return message; > } > > > Regards, > -- 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 Fri Oct 19 18:27:02 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: <3F98421E-0C63-4763-B2C2-3F727AE79D11@dmsolutions.ca> References: <20071018130448.GB14361@metacarta.com> <4718DD96.8000102@openplans.org> <4718E9B2.9010308@openplans.org> <3F98421E-0C63-4763-B2C2-3F727AE79D11@dmsolutions.ca> Message-ID: <6ae3fb590710191527h3acb8fdcn29493fdf1856418c@mail.gmail.com> Another wicked patch. Also tim's complementary patch http://trac.openlayers.org/changeset/5027 ...which clears the jslint complaints for the 'OpenLayers' variable. Great job with this. Let's hope we can keep the OL codebase free of these slips in the future. :-) E On 10/19/07, Paul Spencer wrote: > For those of you that are not on IRC, Tim and I worked this out this > afternoon and I committed: > > http://trac.openlayers.org/changeset/5028 > > which cleans up some 29 instances of local scope variables used > without 'var', making them global in scope. This is now part of my > regularly scheduled routine :) > > Cheers > > Paul > > On 19-Oct-07, at 1:30 PM, Tim Schaub wrote: > > > Hey- > > > > Paul Spencer wrote: > >> > >> for the record, I did fix the above warnings in Rico/* and did NOT > >> touch > >> firebug. As Tim indicates, it doesn't affect the final build. As of > >> now, the final full build is 'lint free' with my current settings, > >> which > >> makes me very happy :) I may look at some of the other settings > >> to see > >> if there is anything else we could potentially benefit from in the > >> newer > >> version of jslint which I discovered last night ... > >> > > > > Paul, I'd also be interested in the result of disallowing use of > > undefined variables. Perhaps you already talked about this and I > > missed it. > > > > What would be really cool is if jslint could be tweaked to look for > > variable assignment outside of the OpenLayers namespace - something we > > occasionally stumble across and have no way of testing for. (I know a > > case where window.i == 2 and I cannot figure out why.) This might > > even > > be caught by the "no undefined variables" filter if it is initialized > > without the var keyword (which is likely). > > > > Tim > > > >> Cheers > >> > >> Paul > >> > >> +-----------------------------------------------------------------+ > >> |Paul Spencer pspencer@dmsolutions.ca | > >> +-----------------------------------------------------------------+ > >> |Chief Technology Officer | > >> |DM Solutions Group Inc http://www.dmsolutions.ca/ | > >> +-----------------------------------------------------------------+ > >> > >> > >> > >> > >> > >> > >> !DSPAM:4033,4718de8133771961014482! > >> > > > > _______________________________________________ > > 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 veen at science.uva.nl Sat Oct 20 10:00:15 2007 From: veen at science.uva.nl (Lourens Veen) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <1192713830.8316.9.camel@mellon> References: <1192713830.8316.9.camel@mellon> Message-ID: <200710201600.15839.veen@science.uva.nl> On Thursday 18 October 2007 15:23:50 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? I haven't followed this thread that carefully so maybe it has come up already, but what about number formats? OL's current scale display uses K and M for thousands and millions, which is not how it's commonly done on paper maps. I'd really rather have it write out the full number, but of course it would then have to use a number format that is appropriate to the locale. In Dutch, I would like it to say 1:50.000, while in English that would be 1:50,000. If you're designing i18n anyway... Lourens -- ? ? ? ? ?ir. Lourens Veen ? ? ? ? University of Amsterdam - IBED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Nieuwe Achtergracht 166 ? ?Scientific Software Engineer ? 1018 WV Amsterdam, The Netherlands ? ? ?? ? ? ? EcoGRID-GAN ? ? ? ? ? t: +31 20-5257453 ?f: +31 20-5257431 From gertjan at West.NL Sat Oct 20 13:02:15 2007 From: gertjan at West.NL (Gertjan van Oosten) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <200710201600.15839.veen@science.uva.nl> References: <1192713830.8316.9.camel@mellon> <200710201600.15839.veen@science.uva.nl> Message-ID: <52090.82.93.165.204.1192899735.squirrel@www.west.nl> As quoted from Lourens Veen: > I haven't followed this thread that carefully so maybe it has come up > already, but what about number formats? OL's current scale display uses > K and M for thousands and millions, which is not how it's commonly done > on paper maps. I'd really rather have it write out the full number, but > of course it would then have to use a number format that is appropriate > to the locale. In Dutch, I would like it to say 1:50.000, while in > English that would be 1:50,000. > > If you're designing i18n anyway... Well, strictly speaking you're talking about L10n (Localisation). That's currently beyond MapBuilder's reach, as you would need locale-specific formatters for that (date, numbers, money). It is doable; some JavaScript classes to do this may be available out there. I haven't taken the effort to integrate them into MapBuilder though (not enough demand). Once you have these L10n classes, fitting them into the i18n framework is easy, as I will show below. Let's say we start out with: var msg = "Scale 1:" + map.scale; which (if map.scale==25000) would give us "Scale 1:25000", in any language. Say the message key "mapScale" maps to the message format string "Scale 1:{0}" in English or "Schaal 1:{0}" in Dutch. After the I18n step it would be: var msg = OpenLayers.String.format("mapScale", msp.scale); which would give "Scale 1:25000" in English and "Schaal 1:25000" in Dutch. If we then add L10n, e.g.: var formattedNumber = OpenLayers.Something.DecimalFormat(map.scale); would return the number formatted according to the proper decimal format for the current locale, e.g. #,### for UK or #.### for NL. Combining the two: var msg = OpenLayers.String.format("mapScale", formattedNumber); would return the I18n'ed message, and since the formattedNumber is L10n'ed, the resulting message would be say "Scale 1:25,000" in English and "Schaal 1:25.000" in Dutch. As you see, I18n and L10n are quite complementary. So the two could be implemented separately (and could even have separate RFC's, which has my preference). Regards, -- -- Gertjan van Oosten, gertjan@West.NL, West Consulting B.V., +31 15 2191 600 From veen at science.uva.nl Sat Oct 20 15:28:52 2007 From: veen at science.uva.nl (Lourens Veen) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <52090.82.93.165.204.1192899735.squirrel@www.west.nl> References: <1192713830.8316.9.camel@mellon> <200710201600.15839.veen@science.uva.nl> <52090.82.93.165.204.1192899735.squirrel@www.west.nl> Message-ID: <200710202128.52985.veen@science.uva.nl> On Saturday 20 October 2007 19:02:15 Gertjan van Oosten wrote: > As quoted from Lourens Veen: > > I haven't followed this thread that carefully so maybe it has come > > up already, but what about number formats? OL's current scale > > display uses K and M for thousands and millions, which is not how > > it's commonly done on paper maps. I'd really rather have it write > > out the full number, but of course it would then have to use a > > number format that is appropriate to the locale. In Dutch, I would > > like it to say 1:50.000, while in English that would be 1:50,000. > > > > If you're designing i18n anyway... > > Well, strictly speaking you're talking about L10n (Localisation). That's not quite how I thought the terms were used, and Wikipedia seems to agree with me. Adding the capability for numbers to be formatted in different ways is i18n, adding specific number formats for certain locales would be L10n. Not that it affects the technical argument :-). > That's currently beyond MapBuilder's reach, as you would need > locale-specific formatters for that (date, numbers, money). It is > doable; some JavaScript classes to do this may be available out > there. I haven't taken the effort to integrate them into MapBuilder > though (not enough demand). Once you have these L10n classes, fitting > them into the i18n framework is easy, as I will show below. > > Let's say we start out with: > var msg = "Scale 1:" + map.scale; > which (if map.scale==25000) would give us "Scale 1:25000", in any > language. > > Say the message key "mapScale" maps to the message format string > "Scale 1:{0}" in English or "Schaal 1:{0}" in Dutch. After the I18n > step it would be: var msg = OpenLayers.String.format("mapScale", > msp.scale); which would give "Scale 1:25000" in English and "Schaal > 1:25000" in Dutch. > > If we then add L10n, e.g.: > var formattedNumber = > OpenLayers.Something.DecimalFormat(map.scale); would return the > number formatted according to the proper decimal format for the > current locale, e.g. #,### for UK or #.### for NL. > > Combining the two: > var msg = OpenLayers.String.format("mapScale", formattedNumber); > would return the I18n'ed message, and since the formattedNumber is > L10n'ed, the resulting message would be say "Scale 1:25,000" in > English and "Schaal 1:25.000" in Dutch. > > As you see, I18n and L10n are quite complementary. So the two could > be implemented separately (and could even have separate RFC's, which > has my preference). Sounds good to me. Unfortunately I have no time to work on it myself at the moment, but I thought I'd mention it in case your tuits were round enough. Lourens -- ? ? ? ? ?ir. Lourens Veen ? ? ? ? University of Amsterdam - IBED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Nieuwe Achtergracht 166 ? ?Scientific Software Engineer ? 1018 WV Amsterdam, The Netherlands ? ? ?? ? ? ? EcoGRID-GAN ? ? ? ? ? t: +31 20-5257453 ?f: +31 20-5257431 From cameron.shorter at gmail.com Sat Oct 20 16:03:28 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] OSGeo access to OWS Context specs Message-ID: <471A5F10.60201@gmail.com> OSGeo Standards, Mapbuilder stores state information inside an OWS Context document, and consequently we may be the largests tester of OWS Context. Every few months we have debates over various parts of the OWS Context spec as developers implement new things. The latest is a discussion shared with Openlayers over how Layer groups should be handled. The current OWS Context spec/schema is globally available at: * http://www.ogcnetwork.net/schemas/owc/0.2.0/ A wiki list of identified issues is at: * https://portal.opengeospatial.org/wiki/twiki/bin/view/CGDIPilot/CgdiipOwsContext Unfortunately, this is only available to OGC members. My next email will be to lobby to make it visible. As part of OGC's mass market strategy, can we please open up access to the OWS Context issue list. This should ensure that specs would benefit from greater testing and increase adoption. An alternative I've considered is setting up an issue tracker as part of Mapbuilder to address OWS Context. (I'd prefer an issue tracker over a wiki as it is easier to manage issues through to completion). -- Cameron Shorter Systems Architect, http://lisasoft.com.au Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 From jachym.cepicky at gmail.com Sat Oct 20 16:54:09 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] status of translation possibilities In-Reply-To: <200710201600.15839.veen@science.uva.nl> References: <1192713830.8316.9.camel@mellon> <200710201600.15839.veen@science.uva.nl> Message-ID: <1192913649.6858.0.camel@kocour> hi Lourens Veen p??e v So 20. 10. 2007 v 16:00 +0200: > I haven't followed this thread that carefully so maybe it has come up > already, but what about number formats? OL's current scale display uses > K and M for thousands and millions, which is not how it's commonly done > on paper maps. I'd really rather have it write out the full number, but > of course it would then have to use a number format that is appropriate > to the locale. In Dutch, I would like it to say 1:50.000, while in > English that would be 1:50,000. good point j -- 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/20071020/1026dccc/attachment.bin From cameron.shorter at gmail.com Sun Oct 21 06:44:22 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol In-Reply-To: <4718CAC8.7020705@camptocamp.com> References: <4718CAC8.7020705@camptocamp.com> Message-ID: <471B2D86.3020705@gmail.com> Barbara, This sounds like a great initiative and I'd be surprised if there isn't already a number of projects which transform between SVG and VML. I know that there has been work converting GML to SVG, and hence there shouldn't be much work transforming GeoRSS to SVG. So I suggest: 1. Before you do any development, research available tools that you can use. 2. Create one vector library (either SVG or VML) and use a translation tool to automatically convert from one to the other. 3. Precompile the alternative library. Ie, don't convert SVG to VML on the fly in Javascript. It will slow the browser down. 3. I suspect that SVG would be a better format to support than VML. I believe SVG is used by a number of other projects, eg the Linux Icon libraries. 4. Search for existing icon libraries and consider extending the existing icon libraries rather than creating a new project. Maybe make a geographic version of the library. 5. Think bigger than just OpenLayers. You start the free icon library used by all Open Source GIS projects. It might be a candidate project for: http://wiki.osgeo.org/index.php/OSGeo_Labs (Although you may want to seed your project within Openlayers) Barbara Philippot wrote: > Ian Mayo a ?crit : > >> 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. >> >> > Yes, this is why we are trying to do. But people would have to specify > two filenames (one in SVG, the other in VML) to replace the pre-existing > symbol catalogue files and it's not still the ideal solution but perhaps > it's the only one. > >> 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. >> >> > Well, I hadn't considered using symbols in a georss feed and I don't > know well Georss format. For the moment, symbols are associated with > points geometry with a style.use="symbol" in the same way as images were > associated with style.externalGraphic. So, I haven't looked in detail to > the way you attach icons to GeoRss nodes but it seems that you would be > able to use SVG and VML symbols as well as images. > > I hope to make progress before your development pause ends :-) > >> Ian. >> >> 1. http://trac.openlayers.org/ticket/1073 >> 2. http://dev.openlayers.org/sandbox/ianmayo/branches/rss/openlayers/examples/georss.html >> >> >> > > _______________________________________________ > 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 Sun Oct 21 06:48:07 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] [OSGeo-Standards] OSGeo access to OWS Context specs In-Reply-To: <002701c8135e$76a75330$6401a8c0@SusieandCarl> References: <471A5F10.60201@gmail.com> <002701c8135e$76a75330$6401a8c0@SusieandCarl> Message-ID: <471B2E67.1090208@gmail.com> Forwarding Carl's email, as I'm aware he is not subscribed to all lists he replied to. Carl Reed OGC Account wrote: > I will be out of the office for two weeks. However, as the proposal is > a good one, I would suggest working with Raj, Greg, and Mark Reichardt > to make this happen. > > Also, FYI, as soon as we get out from under all the changes to > documents and the web site for the new OGC IPR policy, we will be > standing up a public OGC Change Request Proposal system whereby anyone > can submit change requests and track their progress. > > Regards > > Carl > > ----- Original Message ----- From: "Cameron Shorter" > > To: ; "Kralidis,Tom [Burlington]" > > Cc: ; "openlayers" > ; > Sent: Saturday, October 20, 2007 2:03 PM > Subject: [OSGeo-Standards] OSGeo access to OWS Context specs > > >> OSGeo Standards, >> >> Mapbuilder stores state information inside an OWS Context document, >> and consequently we may be the largests tester of OWS Context. >> >> Every few months we have debates over various parts of the OWS >> Context spec as developers implement new things. The latest is a >> discussion shared with Openlayers over how Layer groups should be >> handled. >> >> The current OWS Context spec/schema is globally available at: >> * http://www.ogcnetwork.net/schemas/owc/0.2.0/ >> >> A wiki list of identified issues is at: >> * >> https://portal.opengeospatial.org/wiki/twiki/bin/view/CGDIPilot/CgdiipOwsContext >> >> Unfortunately, this is only available to OGC members. My next email >> will be to lobby to make it visible. >> >> >> As part of OGC's mass market strategy, can we please open up access >> to the OWS Context issue list. This should ensure that specs would >> benefit from greater testing and increase adoption. >> >> An alternative I've considered is setting up an issue tracker as part >> of Mapbuilder to address OWS Context. (I'd prefer an issue tracker >> over a wiki as it is easier to manage issues through to completion). >> >> -- >> Cameron Shorter >> Systems Architect, http://lisasoft.com.au >> Tel: +61 (0)2 8570 5050 >> Mob: +61 (0)419 142 254 >> >> _______________________________________________ >> Standards mailing list >> Standards@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/standards > > -- 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 Sun Oct 21 12:12:15 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol In-Reply-To: <471B2D86.3020705@gmail.com> References: <4718CAC8.7020705@camptocamp.com> <471B2D86.3020705@gmail.com> Message-ID: <20071021161215.GA22608@metacarta.com> On Sun, Oct 21, 2007 at 08:44:22PM +1000, Cameron Shorter wrote: > 5. Think bigger than just OpenLayers. You start the free icon library > used by all Open Source GIS projects. Or you could use the existing project for all open clipart. http://openclipart.org/ Regards, -- Christopher Schmidt MetaCarta From bluecarto at gmail.com Sun Oct 21 15:18:00 2007 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Developement of an external vector symbol In-Reply-To: <20071021161215.GA22608@metacarta.com> References: <4718CAC8.7020705@camptocamp.com> <471B2D86.3020705@gmail.com> <20071021161215.GA22608@metacarta.com> Message-ID: Here is another interesting page with already existing svg symbols catalogue. http://wiki.openstreetmap.org/index.php/Osmarender/Symbols Regards, On 10/21/07, Christopher Schmidt wrote: > On Sun, Oct 21, 2007 at 08:44:22PM +1000, Cameron Shorter wrote: > > 5. Think bigger than just OpenLayers. You start the free icon library > > used by all Open Source GIS projects. > > Or you could use the existing project for all open clipart. > > http://openclipart.org/ > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > From domenico.febbo at gmail.com Tue Oct 23 04:28:29 2007 From: domenico.febbo at gmail.com (Domenico Febbo) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] proxyHost cgi issue Message-ID: <97236bbb0710230128y928bbe5r66f72cc4abef4e03@mail.gmail.com> I need to use proxy.cgi script to forward "get" request on XMLHttpRequest object to a external host, but I have same problem with the path to add at "url=" field. Moreover I've tried the online script http://dev.openlayers.org/sandbox/docs/examples/proxy.cgi but the http://openlayers.org redirect seems to have a issue because the OpenLayers object isn't found (try with Firebug enabled) and all the relative path are wrong. Somebody have other proxy script for Apache webserver? thanks, Domenico From ahhughes at gmail.com Tue Oct 23 07:19:58 2007 From: ahhughes at gmail.com (Andrew Hughes) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] proxyHost cgi issue In-Reply-To: <97236bbb0710230128y928bbe5r66f72cc4abef4e03@mail.gmail.com> References: <97236bbb0710230128y928bbe5r66f72cc4abef4e03@mail.gmail.com> Message-ID: <5f528cf40710230419h4da059aduaec8bc9465a303f9@mail.gmail.com> http://developer.yahoo.com/javascript/howto-proxy.html On 10/23/07, Domenico Febbo wrote: > > I need to use proxy.cgi script to forward "get" request on > XMLHttpRequest object to a external host, but I have same problem with > the path to add at "url=" field. > Moreover I've tried the online script > http://dev.openlayers.org/sandbox/docs/examples/proxy.cgi > but the http://openlayers.org redirect seems to have a issue because > the OpenLayers object isn't found (try with Firebug enabled) and all > the relative path are wrong. > Somebody have other proxy script for Apache webserver? > thanks, > Domenico > _______________________________________________ > 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/20071023/28fc6745/attachment.html From lynn.forrester at mottmac.com Tue Oct 23 09:41:04 2007 From: lynn.forrester at mottmac.com (LynnF) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Vector Layer and Popups Message-ID: <13364682.post@talk.nabble.com> Hi, I am currently working on trying to show a border around an area of interest on my map. The boundary is a list of points that I read and then load into a LinearRing and then load into a VectorFeature which is then finally placed onto a Vector Layer. The problem I am having is that if this boundary layer is on then the popups from other layers do not work (using the Text Layer). Can anyone suggest a solution to this problem? I have tried adding them in different orders but didn't solve anything. Thanks, Lynn. -- View this message in context: http://www.nabble.com/Vector-Layer-and-Popups-tf4677572.html#a13364682 Sent from the OpenLayers Dev mailing list archive at Nabble.com. From crschmidt at metacarta.com Tue Oct 23 09:51:40 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Vector Layer and Popups In-Reply-To: <13364682.post@talk.nabble.com> References: <13364682.post@talk.nabble.com> Message-ID: <20071023135140.GA11127@metacarta.com> On Tue, Oct 23, 2007 at 06:41:04AM -0700, LynnF wrote: > > Hi, > > I am currently working on trying to show a border around an area of interest > on my map. The boundary is a list of points that I read and then load into > a LinearRing and then load into a VectorFeature which is then finally placed > onto a Vector Layer. > The problem I am having is that if this boundary layer is on then the popups > from other layers do not work (using the Text Layer). I'm assuming you mean "The markers are not clickable." If you add the vector layer before your text layer, this hsould not be the case -- the markers should end up on top. Are you using a SelectFeature control? If so, that will present a problem, since it moves the selected vector layer up to the top of the map, above other elements, which would result in what you are describing. Regards, -- Christopher Schmidt MetaCarta From val.cartei at gmail.com Tue Oct 23 10:19:00 2007 From: val.cartei at gmail.com (Val Cartei) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] overviewMap viewport size to show entire overview map Message-ID: I am trying to modify the size of the overviewMap control from its original settings (180,90) to display the whole overview map. I seem to have achieved this, however when I drag the rectangle to browse the overview, its map scrolls, whereas it should stay fixed in the overview viewport. If I restrict the extents of the map to its size it doesn't work either. Any suggestions? Here's the code: //overviewMap object to resize to match the size of the overview map ovmap_size=new OpenLayers.Size ($("img#OpenLayersDiv43").width(),$("img#OpenLayersDiv43").height()); scroller.update(ovmap_size); //restrict the extent of the overview map scroller.ovmap.restrictedExtent=new OpenLayers.Bounds.fromSize(ovmap_size); -- 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/20071023/d742cbae/attachment.html From jing at pelmorex.com Tue Oct 23 13:28:53 2007 From: jing at pelmorex.com (Jim Ing) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] proxyHost cgi issue (Domenico Febbo) In-Reply-To: References: Message-ID: Domenico, Here's one that I'm using: http://www.jmarshall.com/tools/cgiproxy/ Just make sure your Apache httpd.conf has these settings: LoadModule cgi_module modules/mod_cgi.so "> Options Indexes FollowSymLinks ExecCGI AddHandler cgi-script .cgi Also, you might need to edit the first line of nph-proxy.cgi to point to your Perl #!/usr/bin/perl Jim -----Original Message----- Date: Tue, 23 Oct 2007 10:28:29 +0200 From: "Domenico Febbo" Subject: [OpenLayers-Dev] proxyHost cgi issue To: dev@openlayers.org I need to use proxy.cgi script to forward "get" request on XMLHttpRequest object to a external host, but I have same problem with the path to add at "url=" field. Moreover I've tried the online script http://dev.openlayers.org/sandbox/docs/examples/proxy.cgi but the http://openlayers.org redirect seems to have a issue because the OpenLayers object isn't found (try with Firebug enabled) and all the relative path are wrong. Somebody have other proxy script for Apache webserver? thanks, Domenico From jachym.cepicky at gmail.com Tue Oct 23 13:58:42 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups Message-ID: <1193162322.7428.12.camel@kocour> Hi, could anybody of you, guys, have a look at new "custom LayerSwitcher" example [1] ? I hope, it works on all platforms Comments are more then welcomed Jachym P.S. You will have to probably zoom to Canada, go get all layers work [1] http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layerswitcher.html Jachym Cepicky p??e v Po 15. 10. 2007 v 13:20 +0200: > 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/20071023/3d716e5d/attachment.bin From ludwigbrinckmann at gmail.com Tue Oct 23 16:06:38 2007 From: ludwigbrinckmann at gmail.com (Ludwig M Brinckmann) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <1193162322.7428.12.camel@kocour> References: <1193162322.7428.12.camel@kocour> Message-ID: <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> Hi Jachym, for me on XP and Firefox 2.0.0.8 this appears quite unresponsive, even though after a bit of clicking something eventually happens. I am not sure about the graphical solution as I do not really know when a layer is switched on or off. A while ago I experimented a bit with a custom layer switcher outside the map window, it still seems to be working at http://www.yunnanexplorer.com/mars.html There were several ideas in it: First of all ignore the tick-boxes -- they flicker a layer on and off. This is not very intuitive. I thought once having a special effects div hidden with every layer that could be turned on and off. Flickering a layer, moving a sliding window over a layer, inverting colours, image stretching could all go in there. Never followed through. The sliders allow to adjust transparency of a layer: red all the way to the left is off, green is 100% opaque. The rest somewhere in the middle: good way if you want to look at data in more than one map at a time. Furthermore it is possible to drag the layers up and down, changing the stacking/drawing order. I know that conflicts with the baselayer concept of OL. These effects were done with scriptaculous and do not really work that well under IE, but someone with more patience/time than me could probably make them work. It is now over a year old and I have not done any work on it, so some of the layers have ceased to function. I think building better/different layer switchers, particularly with grouping, is quite important... Ludwig On 23/10/2007, Jachym Cepicky wrote: > > Hi, > > could anybody of you, guys, have a look at new "custom LayerSwitcher" > example [1] ? > > I hope, it works on all platforms > > Comments are more then welcomed > > Jachym > > P.S. You will have to probably zoom to Canada, go get all layers work > > [1] > > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layerswitcher.html > > Jachym Cepicky p??e v Po 15. 10. 2007 v 13:20 +0200: > > 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 > > > _______________________________________________ > 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/20071023/da06f8ec/attachment.html From lorenzo at ominiverdi.com Tue Oct 23 18:21:10 2007 From: lorenzo at ominiverdi.com (Lorenzo Becchi) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> References: <1193162322.7428.12.camel@kocour> <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> Message-ID: <471E73D6.8020506@ominiverdi.com> Jachym, I see that all legend layouts can vary a lot. what about Tim's idea to use templates? I'm pretty scared about it but probably is a good solution. Tim, do you think templates could really apply to Layer switcher without getting mad? if yes can you "enlighten our way"? ciao lorenzo > > > A while ago I experimented a bit with a custom layer switcher outside > the map window, it still seems to be working at > > http://www.yunnanexplorer.com/mars.html > you've never tried it with Safari. Layers names disappears if you click on them. :-| > > There were several ideas in it: > First of all ignore the tick-boxes -- they flicker a layer on and off. > This is not very intuitive. I thought once having a special effects > div hidden with every layer that could be turned on and off. > Flickering a layer, moving a sliding window over a layer, inverting > colours, image stretching could all go in there. Never followed through. > > The sliders allow to adjust transparency of a layer: red all the way > to the left is off, green is 100% opaque. The rest somewhere in the > middle: good way if you want to look at data in more than one map at a > time. > > Furthermore it is possible to drag the layers up and down, changing > the stacking/drawing order. I know that conflicts with the baselayer > concept of OL. > > These effects were done with scriptaculous and do not really work that > well under IE, but someone with more patience/time than me could > probably make them work. It is now over a year old and I have not done > any work on it, so some of the layers have ceased to function. > > I think building better/different layer switchers, particularly with > grouping, is quite important... > > Ludwig > > > > > > > On 23/10/2007, * Jachym Cepicky* > wrote: > > Hi, > > could anybody of you, guys, have a look at new "custom LayerSwitcher" > example [1] ? > > I hope, it works on all platforms > > Comments are more then welcomed > > Jachym > > P.S. You will have to probably zoom to Canada, go get all layers work > > [1] > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layerswitcher.html > > Jachym Cepicky p??e v Po 15. 10. 2007 v 13:20 +0200: > > 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 > > > _______________________________________________ > 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 24 03:59:17 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> References: <1193162322.7428.12.camel@kocour> <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> Message-ID: <1193212758.6297.21.camel@kocour> Hi, Ludwig M Brinckmann p??e v ?t 23. 10. 2007 v 21:06 +0100: > Hi Jachym, > > for me on XP and Firefox 2.0.0.8 this appears quite unresponsive, even > though after a bit of clicking something eventually happens. I am not > sure about the graphical solution as I do not really know when a layer > is switched on or off. Some layers were active only, if you zoomed to region around Canada (fixed). I completely agree with you, that the "design" of the page "could" be more intuitive -- sorry, no graphical designer. > > A while ago I experimented a bit with a custom layer switcher outside > the map window, it still seems to be working at > > http://www.yunnanexplorer.com/mars.html > > There were several ideas in it: > First of all ignore the tick-boxes -- they flicker a layer on and off. > This is not very intuitive. I thought once having a special effects > div hidden with every layer that could be turned on and off. > Flickering a layer, moving a sliding window over a layer, inverting > colours, image stretching could all go in there. Never followed > through. nice demo > > The sliders allow to adjust transparency of a layer: red all the way > to the left is off, green is 100% opaque. The rest somewhere in the > middle: good way if you want to look at data in more than one map at a > time. this is somehow more intuitive, than my previous layer-buttons.html example. Sliders are better for opacity settings, but I did not know, how to get them in current LayerSwitcher dimensions. > > > Furthermore it is possible to drag the layers up and down, changing > the stacking/drawing order. I know that conflicts with the baselayer > concept of OL. Dragging is definitely more intuitive, than buttons (again layer-buttons.html in my sandbox), when it is working. Together with layer groups (layer-groups.html), the code would get pretty complicated.. > > These effects were done with scriptaculous and do not really work that > well under IE, but someone with more patience/time than me could > probably make them work. It is now over a year old and I have not done > any work on it, so some of the layers have ceased to function. > > I think building better/different layer switchers, particularly with > grouping, is quite important... I'm working on it. If others like it, I hope, it would appear in OpenLayers trunk - I'm not avare of any other impediment. Jachym > > Ludwig > > > > > > > On 23/10/2007, Jachym Cepicky wrote: > Hi, > > could anybody of you, guys, have a look at new "custom > LayerSwitcher" > example [1] ? > > I hope, it works on all platforms > > Comments are more then welcomed > > Jachym > > P.S. You will have to probably zoom to Canada, go get all > layers work > > [1] > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layerswitcher.html > > Jachym Cepicky p??e v Po 15. 10. 2007 v 13:20 +0200: > > 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 > > > _______________________________________________ > 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/20071024/c76f73ae/attachment.bin From jachym.cepicky at gmail.com Wed Oct 24 04:18:07 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Layers into Groups In-Reply-To: <471E73D6.8020506@ominiverdi.com> References: <1193162322.7428.12.camel@kocour> <3f7a6e1c0710231306q5821daeex21517c8d582cf2ee@mail.gmail.com> <471E73D6.8020506@ominiverdi.com> Message-ID: <1193213887.6297.27.camel@kocour> Hi, Lorenzo Becchi p??e v St 24. 10. 2007 v 00:21 +0200: > Jachym, I see that all legend layouts can vary a lot. > what about Tim's idea to use templates? > I'm pretty scared about it but probably is a good solution. > Tim, do you think templates could really apply to Layer switcher without > getting mad? if yes can you "enlighten our way"? > > ciao > lorenzo How should the templates look like? My approach is, have everything (layers, groups, etc.) in separate divs, so they are now customisable via CSS styles. The example should be fixed for IE as well now. Jachym > > > > > > > > A while ago I experimented a bit with a custom layer switcher outside > > the map window, it still seems to be working at > > > > http://www.yunnanexplorer.com/mars.html > > > you've never tried it with Safari. Layers names disappears if you click > on them. > :-| > > > > There were several ideas in it: > > First of all ignore the tick-boxes -- they flicker a layer on and off. > > This is not very intuitive. I thought once having a special effects > > div hidden with every layer that could be turned on and off. > > Flickering a layer, moving a sliding window over a layer, inverting > > colours, image stretching could all go in there. Never followed through. > > > > The sliders allow to adjust transparency of a layer: red all the way > > to the left is off, green is 100% opaque. The rest somewhere in the > > middle: good way if you want to look at data in more than one map at a > > time. > > > > Furthermore it is possible to drag the layers up and down, changing > > the stacking/drawing order. I know that conflicts with the baselayer > > concept of OL. > > > > These effects were done with scriptaculous and do not really work that > > well under IE, but someone with more patience/time than me could > > probably make them work. It is now over a year old and I have not done > > any work on it, so some of the layers have ceased to function. > > > > I think building better/different layer switchers, particularly with > > grouping, is quite important... > > > > Ludwig > > > > > > > > > > > > > > On 23/10/2007, * Jachym Cepicky* > > wrote: > > > > Hi, > > > > could anybody of you, guys, have a look at new "custom LayerSwitcher" > > example [1] ? > > > > I hope, it works on all platforms > > > > Comments are more then welcomed > > > > Jachym > > > > P.S. You will have to probably zoom to Canada, go get all layers work > > > > [1] > > http://dev.openlayers.org/sandbox/jachym/openlayers/examples/layerswitcher.html > > > > Jachym Cepicky p??e v Po 15. 10. 2007 v 13:20 +0200: > > > 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 > > > > > > _______________________________________________ > > 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/20071024/3c2f9534/attachment.bin From domenico.febbo at gmail.com Wed Oct 24 09:10:34 2007 From: domenico.febbo at gmail.com (Domenico Febbo) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] proxyHost cgi issue Message-ID: <97236bbb0710240610x194c352dlac9919436488150f@mail.gmail.com> Hi, with same modify I've configured the OpenLayers script "proxy.cgi" for my lan (adding http_proxy configuration). thanks, Jim for that url. I've this question: the same cgi is configurable for IIS web server or there is other script to workaround the "samePolicy" restriction? Domenico > Date: Tue, 23 Oct 2007 13:28:53 -0400 > From: "Jim Ing" > Subject: Re: [OpenLayers-Dev] proxyHost cgi issue (Domenico Febbo) > To: > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Domenico, > > Here's one that I'm using: > http://www.jmarshall.com/tools/cgiproxy/ > > Just make sure your Apache httpd.conf has these settings: > > LoadModule cgi_module modules/mod_cgi.so > > "> > Options Indexes FollowSymLinks ExecCGI > > > AddHandler cgi-script .cgi > > Also, you might need to edit the first line of nph-proxy.cgi to point to > your Perl > #!/usr/bin/perl > > > Jim > > > -----Original Message----- > Date: Tue, 23 Oct 2007 10:28:29 +0200 > From: "Domenico Febbo" > Subject: [OpenLayers-Dev] proxyHost cgi issue > To: dev@openlayers.org > > I need to use proxy.cgi script to forward "get" request on > XMLHttpRequest object to a external host, but I have same problem with > the path to add at "url=" field. > Moreover I've tried the online script > http://dev.openlayers.org/sandbox/docs/examples/proxy.cgi > but the http://openlayers.org redirect seems to have a issue because > the OpenLayers object isn't found (try with Firebug enabled) and all > the relative path are wrong. > Somebody have other proxy script for Apache webserver? > thanks, > Domenico > > > ------------------------------ From bartvde at osgis.nl Thu Oct 25 04:57:37 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] deactivating other handlers Message-ID: Hi devs, I've written a FeatureInfo Handler, which only uses click. However, the DragPan handler for instance is still active. What is the best way to deactivate these other handlers? Ofcourse I can also implement mousedown etc. and not let the event propagate, but that seems a bit cumbersome. Is there a way to make a Handler exclusive, or to remove all other handlers from the map? Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl From jachym.cepicky at gmail.com Thu Oct 25 07:57:45 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg Message-ID: <1193313465.6482.6.camel@kocour> Hi, in OpenLayers.Layer.Tilecache, around line 55, there is this.extension = (this.extension == 'jpeg') ? 'jpg' : this.extension; in tilecache/TileCache/Layer.py, around line 80, there is if extension.lower() == 'jpg': extension = 'jpeg' # MIME IMHO, it does not make sense, if I understand this well, you can never access JPEG TileCache from OpenLayers Do I understand it well? 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/20071025/93eb6131/attachment.bin From pspencer at dmsolutions.ca Thu Oct 25 08:49:06 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <1193313465.6482.6.camel@kocour> References: <1193313465.6482.6.camel@kocour> Message-ID: <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> Jachym, if I understand it correctly, the image saved on disk has an extension of .jpg while the mime type returned by the web server with a JPEG image is image/jpeg. So the code is fine and is doing the right thing. You just need to specify the correct extension in OpenLayers (either 'jpg' or 'jpeg' will do) and in TileCache config (again, probably either will do). Paul On 25-Oct-07, at 7:57 AM, Jachym Cepicky wrote: > Hi, > > in OpenLayers.Layer.Tilecache, around line 55, there is > > this.extension = (this.extension == 'jpeg') ? 'jpg' : this.extension; > > in tilecache/TileCache/Layer.py, around line 80, there is > > if extension.lower() == 'jpg': extension = 'jpeg' # MIME > > IMHO, it does not make sense, if I understand this well, you can never > access JPEG TileCache from OpenLayers > > Do I understand it well? > > 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 > > _______________________________________________ > 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 jachym.cepicky at gmail.com Thu Oct 25 08:51:17 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] alt or title text on Layer.Marker Message-ID: <1193316677.6482.12.camel@kocour> Hi, maybe, it would be good to have option for OpenLayers.Layer.Marker, which would enable displaying alt text of icons on mouse over. The alt attribute could be e.g. Title of OL.Layer.Text Is there such possibility, which would display alt or other attribute, while moving with mouse over icon? 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/20071025/3f8603cc/attachment.bin From jachym.cepicky at gmail.com Thu Oct 25 08:53:04 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> Message-ID: <1193316784.6482.15.camel@kocour> Hi, no, if I understand it right, TileCache will always save the files with extension "jpeg", while OpenLayers will always request "jpg" files. Jachym Paul Spencer p??e v ?t 25. 10. 2007 v 08:49 -0400: > Jachym, > > if I understand it correctly, the image saved on disk has an > extension of .jpg while the mime type returned by the web server with > a JPEG image is image/jpeg. So the code is fine and is doing the > right thing. You just need to specify the correct extension in > OpenLayers (either 'jpg' or 'jpeg' will do) and in TileCache config > (again, probably either will do). > > Paul > > On 25-Oct-07, at 7:57 AM, Jachym Cepicky wrote: > > > Hi, > > > > in OpenLayers.Layer.Tilecache, around line 55, there is > > > > this.extension = (this.extension == 'jpeg') ? 'jpg' : this.extension; > > > > in tilecache/TileCache/Layer.py, around line 80, there is > > > > if extension.lower() == 'jpg': extension = 'jpeg' # MIME > > > > IMHO, it does not make sense, if I understand this well, you can never > > access JPEG TileCache from OpenLayers > > > > Do I understand it well? > > > > 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 > > > > _______________________________________________ > > 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/ | > +-----------------------------------------------------------------+ > > > > > -- 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/20071025/d0ca51d4/attachment.bin From pspencer at dmsolutions.ca Thu Oct 25 08:57:02 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <1193316784.6482.15.camel@kocour> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> Message-ID: <720A0DE4-3A47-47F7-9908-0389C15CC16A@dmsolutions.ca> No. TileCache saves the image with a .jpg extension but uses 'jpeg' for the mime type of the returned content. The underlying library, PIL, will do that automagically for you. Cheers Paul On 25-Oct-07, at 8:53 AM, Jachym Cepicky wrote: > Hi, > > no, if I understand it right, TileCache will always save the files > with > extension "jpeg", while OpenLayers will always request "jpg" files. > > Jachym > > > Paul Spencer p??e v ?t 25. 10. 2007 v 08:49 -0400: >> Jachym, >> >> if I understand it correctly, the image saved on disk has an >> extension of .jpg while the mime type returned by the web server with >> a JPEG image is image/jpeg. So the code is fine and is doing the >> right thing. You just need to specify the correct extension in >> OpenLayers (either 'jpg' or 'jpeg' will do) and in TileCache config >> (again, probably either will do). >> >> Paul >> >> On 25-Oct-07, at 7:57 AM, Jachym Cepicky wrote: >> >>> Hi, >>> >>> in OpenLayers.Layer.Tilecache, around line 55, there is >>> >>> this.extension = (this.extension == 'jpeg') ? 'jpg' : >>> this.extension; >>> >>> in tilecache/TileCache/Layer.py, around line 80, there is >>> >>> if extension.lower() == 'jpg': extension = 'jpeg' # MIME >>> >>> IMHO, it does not make sense, if I understand this well, you can >>> never >>> access JPEG TileCache from OpenLayers >>> >>> Do I understand it well? >>> >>> 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 >>> >>> _______________________________________________ >>> 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/ | >> +-----------------------------------------------------------------+ >> >> >> >> >> > -- > Jachym Cepicky > e-mail: jachym.cepicky@gmail.com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Thu Oct 25 08:59:32 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] deactivating other handlers In-Reply-To: References: Message-ID: <20071025125932.GC3540@metacarta.com> On Thu, Oct 25, 2007 at 10:57:37AM +0200, Bart van den Eijnden (OSGIS) wrote: > Hi devs, > > I've written a FeatureInfo Handler, which only uses click. However, the > DragPan handler for instance is still active. > > What is the best way to deactivate these other handlers? > > Ofcourse I can also implement mousedown etc. and not let the event > propagate, but that seems a bit cumbersome. > > Is there a way to make a Handler exclusive, or to remove all other handlers > from the map? Controls should use registerPriority when registering events on activate -- registerPriority says 'me first!'. So, even though dragPan would get the event, if you registerPriority, you'll get it first, and then stop it so that dragPan doesn't get it. If that doesn't work somewhere, then it would be good to know, but I think it should. Regards, -- Christopher Schmidt MetaCarta From crschmidt at metacarta.com Thu Oct 25 09:02:48 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <1193316784.6482.15.camel@kocour> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> Message-ID: <20071025130248.GE3540@metacarta.com> On Thu, Oct 25, 2007 at 02:53:04PM +0200, Jachym Cepicky wrote: > Hi, > > no, if I understand it right, TileCache will always save the files with > extension "jpeg", while OpenLayers will always request "jpg" files. You're correct. It's a bug in the TileCache layer. I've bumped into a couple times, but haven't fixed it. Please feel free to file a ticket with a patch. Regards, -- Christopher Schmidt MetaCarta From gonrial at gmail.com Thu Oct 25 09:03:39 2007 From: gonrial at gmail.com (Ezequiel Gonzalez Rial) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] alt or title text on Layer.Marker In-Reply-To: <1193316677.6482.12.camel@kocour> References: <1193316677.6482.12.camel@kocour> Message-ID: Jachym, I've developed something arround that (Ticket #751) wich is not yet on the trunk, it's a label that apperars next to the marker (by css you can set it above, below or wherever you want), as it inheritance from marker you don't loose anything you have already coded. -- Best Regards, Ezequiel Gonzalez Rial (gonrial@gmail.com) 2007/10/25, Jachym Cepicky : > Hi, > > maybe, it would be good to have option for OpenLayers.Layer.Marker, > which would enable displaying alt text of icons on mouse over. The alt > attribute could be e.g. Title of OL.Layer.Text > > Is there such possibility, which would display alt or other attribute, > while moving with mouse over icon? > > 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 > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev From crschmidt at metacarta.com Thu Oct 25 09:08:21 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <720A0DE4-3A47-47F7-9908-0389C15CC16A@dmsolutions.ca> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <720A0DE4-3A47-47F7-9908-0389C15CC16A@dmsolutions.ca> Message-ID: <20071025130821.GF3540@metacarta.com> On Thu, Oct 25, 2007 at 08:57:02AM -0400, Paul Spencer wrote: > No. TileCache saves the image with a .jpg extension but uses 'jpeg' > for the mime type of the returned content. The underlying library, > PIL, will do that automagically for you. No. 1. PIL is not neccesarily involved in transactions. It is only used with meta-tiling, so invoking the name of PIL here is irrelevant. 2. The last parts of the diskcache key are: "%03d.%s" % (int(tile.y) % 1000, tile.layer.extension) 3. The Layer class converts the extension: if extension.lower() == 'jpg': extension = 'jpeg' # MIME self.extension = extension.lower() Jachym is right. The Layer.TileCache is wrong. Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Thu Oct 25 09:11:19 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <20071025130821.GF3540@metacarta.com> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <720A0DE4-3A47-47F7-9908-0389C15CC16A@dmsolutions.ca> <20071025130821.GF3540@metacarta.com> Message-ID: Ok, I take that back :) I was looking at the PIL code and it takes the extension (jpeg) as a format option but I hadn't considered the case where you were not using PIL. But in either case, I now realize the final image name is being created incorrectly regardless of whether PIL is used or not. Paul On 25-Oct-07, at 9:08 AM, Christopher Schmidt wrote: > On Thu, Oct 25, 2007 at 08:57:02AM -0400, Paul Spencer wrote: >> No. TileCache saves the image with a .jpg extension but uses 'jpeg' >> for the mime type of the returned content. The underlying library, >> PIL, will do that automagically for you. > > No. > > 1. PIL is not neccesarily involved in transactions. It is only used > with meta-tiling, so invoking the name of PIL here is irrelevant. > 2. The last parts of the diskcache key are: > "%03d.%s" % (int(tile.y) % 1000, tile.layer.extension) > 3. The Layer class converts the extension: > > if extension.lower() == 'jpg': extension = 'jpeg' # MIME > self.extension = extension.lower() > > Jachym is right. The Layer.TileCache is wrong. > > Regards, > -- > Christopher Schmidt > MetaCarta +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From jachym.cepicky at gmail.com Thu Oct 25 10:11:50 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <20071025130248.GE3540@metacarta.com> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <20071025130248.GE3540@metacarta.com> Message-ID: <1193321510.6482.20.camel@kocour> Hi, http://dev.tilecache.org/ticket/555 Cheers Jachym Christopher Schmidt p??e v ?t 25. 10. 2007 v 09:02 -0400: > On Thu, Oct 25, 2007 at 02:53:04PM +0200, Jachym Cepicky wrote: > > Hi, > > > > no, if I understand it right, TileCache will always save the files with > > extension "jpeg", while OpenLayers will always request "jpg" files. > > You're correct. It's a bug in the TileCache layer. I've bumped into a > couple times, but haven't fixed it. Please feel free to file a ticket > with a patch. > > 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/20071025/317ac2bc/attachment.bin From crschmidt at metacarta.com Thu Oct 25 11:17:47 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <1193321510.6482.20.camel@kocour> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <20071025130248.GE3540@metacarta.com> <1193321510.6482.20.camel@kocour> Message-ID: <20071025151747.GA12250@metacarta.com> On Thu, Oct 25, 2007 at 04:11:50PM +0200, Jachym Cepicky wrote: > Hi, > > http://dev.tilecache.org/ticket/555 Actually, it needs to be fixed on the client side, not the server side. The server side WMS uses the extension to request data from the WMS server as "image/"+layer.extension -- this clearly won't work with image/jpg for most WMS servers. Instead, the TileCache Layer in openlayers needs to be changed to reverse its current logic. Regards, -- Christopher Schmidt MetaCarta From bluecarto at gmail.com Thu Oct 25 11:26:35 2007 From: bluecarto at gmail.com (Pierre GIRAUD) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] patched ticket to review Message-ID: Hello all, As proposed by Chris on the IRC, here's a list of ticket I would like to see reviewed : #819 : Linestring draws filled in IE #965 : rendered geometries blink sometimes in the VML renderer #1042 : renderer flashes black #1107 : handlers have to check if layer exists before destroying it Regards Pierre From jachym.cepicky at gmail.com Thu Oct 25 11:38:58 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <20071025151747.GA12250@metacarta.com> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <20071025130248.GE3540@metacarta.com> <1193321510.6482.20.camel@kocour> <20071025151747.GA12250@metacarta.com> Message-ID: <1193326738.6482.22.camel@kocour> Hmm, this makes sense is http://trac.openlayers.org/ticket/1110 all right for you? Jachym Christopher Schmidt p??e v ?t 25. 10. 2007 v 11:17 -0400: > On Thu, Oct 25, 2007 at 04:11:50PM +0200, Jachym Cepicky wrote: > > Hi, > > > > http://dev.tilecache.org/ticket/555 > > Actually, it needs to be fixed on the client side, not the server side. > The server side WMS uses the extension to request data from the WMS > server as "image/"+layer.extension -- this clearly won't work with > image/jpg for most WMS servers. Instead, the TileCache Layer in > openlayers needs to be changed to reverse its current logic. > > 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/20071025/10027318/attachment.bin From crschmidt at metacarta.com Thu Oct 25 11:48:24 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] jpeg vs jpg In-Reply-To: <1193326738.6482.22.camel@kocour> References: <1193313465.6482.6.camel@kocour> <82C4DC2C-755D-4B0A-AD0E-4C942938EF14@dmsolutions.ca> <1193316784.6482.15.camel@kocour> <20071025130248.GE3540@metacarta.com> <1193321510.6482.20.camel@kocour> <20071025151747.GA12250@metacarta.com> <1193326738.6482.22.camel@kocour> Message-ID: <20071025154824.GA13839@metacarta.com> On Thu, Oct 25, 2007 at 05:38:58PM +0200, Jachym Cepicky wrote: > Hmm, this makes sense > > is http://trac.openlayers.org/ticket/1110 all right for you? Yep. Thanks. WIll take care of it sometime soon. Regards, -- Christopher Schmidt MetaCarta From erik.uzureau at metacarta.com Thu Oct 25 20:16:33 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] OL Vector Layer: What are the Limitations? Message-ID: <6ae3fb590710251716k559d42a1nb24993ec75bd7a28@mail.gmail.com> Dear users, dev, Someone asked me today what the max number of coordinates could be drawn for a geometry with the OL Vector Layer and I did not know how to really answer. I asked cr5 and he gave me some off the cuff estimates, which I have added to the FAQ here: http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#WhatisthemaximumnumberofCoordinatesFeaturesIcandrawwithaVectorlayer Basically, he has suggested the following as upper bounds of reasonable use: * ~2500 Coordinates * ~100-200 Features (Since each geometry is rendered as a separate DOM object, dragging and the like get seriously slowed down the more features you have on the map.) If you've been using the vector layers in different browsers or with different limits... please let us know by either replying to this email... or just going right in and directly ediitng the wiki itself. The more input we have the better we know our own limits. Thanks for anyone who can chime in --Erik From rdewit at users.sourceforge.net Fri Oct 26 00:13:21 2007 From: rdewit at users.sourceforge.net (Roald de Wit) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Empty geometries causing errors in IE Message-ID: <1193372001.25343.12.camel@bender> Hi list, Creating an empty geometry is fine in Firefox (SVG), but fails in IE (VML). It goes wrong in VML.js in setNodeDimension. This method tries to create a bbox, then tests for its existence, but not if there is something in there. I'd like to start a discussion on whether OL should allow for empty geometries or not. The least that should come out of the discussion is a solution where the user doesn't get a javascript error for trying. See ticket #1111 for a simple 'fix'. Chris, Tim, anyone else? -- Roald de Wit Software Engineer roald.dewit@lisasoft.com Commercial Support for Open Source GIS Software http://lisasoft.com/LISAsoft/SupportedProducts/ From eider at fh-bingen.de Fri Oct 26 01:54:12 2007 From: eider at fh-bingen.de (Dipl. Inf. Carsten Eider) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] [OpenLayers-Users] OL Vector Layer: What are the Limitations? In-Reply-To: <6ae3fb590710251716k559d42a1nb24993ec75bd7a28@mail.gmail.com> References: <6ae3fb590710251716k559d42a1nb24993ec75bd7a28@mail.gmail.com> Message-ID: <47218104.5080807@fh-bingen.de> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: eider.vcf Type: text/x-vcard Size: 330 bytes Desc: not available Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071026/045cd298/eider.vcf From jachym.cepicky at gmail.com Fri Oct 26 04:37:23 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] alt or title text on Layer.Marker In-Reply-To: References: <1193316677.6482.12.camel@kocour> Message-ID: <1193387843.7094.6.camel@kocour> Hi, not so bad, the labels are working for me (+1 for adding it to trunk), but I would need something, which would appear on mouse over I'll try to update your Labels.js, if you would not mind cheers Jachym Ezequiel Gonzalez Rial p??e v ?t 25. 10. 2007 v 10:03 -0300: > Jachym, > I've developed something arround that (Ticket #751) wich is not yet on > the trunk, it's a label that apperars next to the marker (by css you > can set it above, below or wherever you want), as it inheritance from > marker you don't loose anything you have already coded. > > -- > Best Regards, > Ezequiel Gonzalez Rial (gonrial@gmail.com) > > 2007/10/25, Jachym Cepicky : > > Hi, > > > > maybe, it would be good to have option for OpenLayers.Layer.Marker, > > which would enable displaying alt text of icons on mouse over. The alt > > attribute could be e.g. Title of OL.Layer.Text > > > > Is there such possibility, which would display alt or other attribute, > > while moving with mouse over icon? > > > > 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 > > > > > > _______________________________________________ > > 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/20071026/1f0296dd/attachment.bin From toncho11 at abv.bg Fri Oct 26 09:34:26 2007 From: toncho11 at abv.bg (__ __) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] colors a specific country Message-ID: <590357296.935721193405666921.JavaMail.nobody@mail51.abv.bg> Hi, I need a solution which colors a specific country with specific color. Any suggestion will be greatly appreciated!!! Cheers, Anton From val.cartei at gmail.com Fri Oct 26 10:26:54 2007 From: val.cartei at gmail.com (Val Cartei) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] How to make overview map resizable? Message-ID: Hi, I am trying to make the overview map resizable. I suppose this can be done by setting the scale of the overview map. Is there a method to update it dynamically? -- 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/20071026/67caf1ad/attachment.html From tschaub at openplans.org Fri Oct 26 11:28:11 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] deactivating other handlers In-Reply-To: References: Message-ID: <4722078B.4010207@openplans.org> Hey- Bart van den Eijnden (OSGIS) wrote: > Hi devs, > > I've written a FeatureInfo Handler, which only uses click. However, the > DragPan handler for instance is still active. > Not sure exactly what your FeatureInfo handler does, but it feels like it might be more of a control than a handler. Perhaps it could be a control that used the Feature handler (which can be configured to respond to a click)? Or maybe it does something like GetFeatureInfo (from WMS)? In this case, it should almost certainly be a control (because it doesn't represent a complex sequence of browser events). > What is the best way to deactivate these other handlers? Handlers are designed to abstract out sequences of browser events. They are typically sent to controls to modify the behavior of a control. When you activate a control, the appropriate handlers are activated. Deactivate, and the handlers are deactivated. We want there to be many controls in a given mapping app. Perhaps many will be active at one time. In this case, any handlers associated with these controls need to play well together. The order of activation is important. Controls (and their handlers) that are activated later get priority in event handling. > Is there a way to make a Handler exclusive, or to remove all other handlers > from the map? It wouldn't make sense necessarily to silence (or plug the ears of maybe) all handlers on the map. This would be akin to unregistering all event listeners just because you want to register a new one. You're better off having your application control the order of control (and hence handler) activation. This is a somewhat tedious task. Because of this, we have a control panel class. If you add a tool type control to a control panel, when it is activated (and it's handler is activated), it will deactivate all other tool type controls (and their handlers) on the same panel. I think this structure gives enough to work with in most situations. Perhaps I've totally missed what you're trying to do though. If you give more detail, I can try again. Tim > 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 > > !DSPAM:4033,47205aa1282033327367457! > From barbara.philippot at camptocamp.com Fri Oct 26 11:32:51 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 In-Reply-To: <471B2D86.3020705@gmail.com> References: <4718CAC8.7020705@camptocamp.com> <471B2D86.3020705@gmail.com> Message-ID: <472208A3.7050806@camptocamp.com> Thanks for your advice Cameron! I researched available tools to transform SVG into VML. I found that only one project was usable without too many modifications : Mark Finkle's opensource project : Implementation of simple static SVG rendering in Internet Explorer using VML, which is under the terms of MIT license. http://starkravingfinkle.org/blog/2006/03/svg-in-ie/ After a certain number of modifications (symbol and viewbox management, minor corrections), I was able to transform SVG symbols into VML groups. Some problems are still there but most of them are well transformed. So, I inserted the needed functions into Openlayers codebase. For the moment, they are independant functions put into VML.js (one main function and 4 linked functions). We need to put these functions elsewhere : methods still in VML.js, in Util.js?, or integrate them into a new class and a new file? Since VML shapetype elements can't be as complex as SVG symbol elements, I transformed SVG symbols into VML groups with a visibility put to hidden. The specified group matching the point to draw is then cloned, made visible and put at the right place. So when creating a new vector layer, we can now specify an option with the URL of a single SVG symbols library which will be loaded in the rendererRoot node. Symbols of this library can be used on Firefox (directly in SVG) or on IE (transformed on the fly in Javascript into VML). It slows a little the browser down but loading time is satisfactory. For the moment, we have used this catalogue : http://wiki.openstreetmap.org/index.php/Osmarender/Symbols but people can add their own symbols or symbols from the Open Clip Art library provided that SVG symbols are put inside a element with the correct viewBox attribute associated. See : http://dev.openlayers.org/sandbox/camptocamp/vectorSymbols/examples/vector-symbols.html Regards, Barbara Cameron Shorter a ?crit : > Barbara, > This sounds like a great initiative and I'd be surprised if there > isn't already a number of projects which transform between SVG and VML. > I know that there has been work converting GML to SVG, and hence there > shouldn't be much work transforming GeoRSS to SVG. > > So I suggest: > 1. Before you do any development, research available tools that you > can use. > 2. Create one vector library (either SVG or VML) and use a translation > tool to automatically convert from one to the other. > 3. Precompile the alternative library. Ie, don't convert SVG to VML on > the fly in Javascript. It will slow the browser down. > 3. I suspect that SVG would be a better format to support than VML. I > believe SVG is used by a number of other projects, eg the Linux Icon > libraries. > 4. Search for existing icon libraries and consider extending the > existing icon libraries rather than creating a new project. Maybe make > a geographic version of the library. > 5. Think bigger than just OpenLayers. You start the free icon library > used by all Open Source GIS projects. It might be a candidate project > for: http://wiki.osgeo.org/index.php/OSGeo_Labs > (Although you may want to seed your project within Openlayers) > > > Barbara Philippot wrote: >> Ian Mayo a ?crit : >> >>> 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. >>> >> Yes, this is why we are trying to do. But people would have to specify >> two filenames (one in SVG, the other in VML) to replace the pre-existing >> symbol catalogue files and it's not still the ideal solution but perhaps >> it's the only one. >> >>> 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. >>> >> Well, I hadn't considered using symbols in a georss feed and I don't >> know well Georss format. For the moment, symbols are associated with >> points geometry with a style.use="symbol" in the same way as images were >> associated with style.externalGraphic. So, I haven't looked in detail to >> the way you attach icons to GeoRss nodes but it seems that you would be >> able to use SVG and VML symbols as well as images. >> >> I hope to make progress before your development pause ends :-) >> >>> Ian. >>> >>> 1. http://trac.openlayers.org/ticket/1073 >>> 2. >>> http://dev.openlayers.org/sandbox/ianmayo/branches/rss/openlayers/examples/georss.html >>> >>> >>> >> >> _______________________________________________ >> Dev mailing list >> Dev@openlayers.org >> http://openlayers.org/mailman/listinfo/dev >> >> > > From tschaub at openplans.org Fri Oct 26 11:52:50 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] Empty geometries causing errors in IE In-Reply-To: <1193372001.25343.12.camel@bender> References: <1193372001.25343.12.camel@bender> Message-ID: <47220D52.6020904@openplans.org> Hey- Roald de Wit wrote: > Hi list, > > Creating an empty geometry is fine in Firefox (SVG), but fails in IE > (VML). > It goes wrong in VML.js in setNodeDimension. This method tries to create > a bbox, then tests for its existence, but not if there is something in > there. > > I'd like to start a discussion on whether OL should allow for empty > geometries or not. The least that should come out of the discussion is a > solution where the user doesn't get a javascript error for trying. > I'm entirely in favor of this. I don't think the renderer is the right place to bomb (or hey maybe even throw an exception!) on an empty geometry. I think it makes sense to have our format classes throw exceptions on empty geometries. They could even have an option to allow empty geometry. In any case, it should be up to the application designer to decide what to do with empty geometry. As library developers, I don't think we should impose our beliefs about empty geometries on all others. Breaking in only one browser, and only when rendering, is a bit late and a bit inconsistent. > See ticket #1111 for a simple 'fix'. See also http://trac.openlayers.org/ticket/968 I'd like to see some tests for the renderers really. I haven't looked closely at your patch, but it would be nice to make sure we don't slip once we decide to make a change (like make browser behavior consistent). Tim > > Chris, Tim, anyone else? > From tschaub at openplans.org Fri Oct 26 11:56:51 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] colors a specific country In-Reply-To: <590357296.935721193405666921.JavaMail.nobody@mail51.abv.bg> References: <590357296.935721193405666921.JavaMail.nobody@mail51.abv.bg> Message-ID: <47220E43.9070906@openplans.org> __ __ wrote: > Hi, > > I need a solution which colors a specific country with specific color. > Any suggestion will be greatly appreciated!!! Red. > > Cheers, > Anton > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,4721ecee301671628642973! > From tschaub at openplans.org Fri Oct 26 12:44:01 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] colors a specific country In-Reply-To: <47220E43.9070906@openplans.org> References: <590357296.935721193405666921.JavaMail.nobody@mail51.abv.bg> <47220E43.9070906@openplans.org> Message-ID: <47221951.1050905@openplans.org> Excuse me. I meant to ask for more detail. The correct solution depends on where your data resides and what renders it. Do you have the geometries representing countries client side (in the browser)? If you are using a WMS that you are in control of, the solution will be different than if you are requesting data from a server over which you have no control. Anyway, more detail would help. Tim Tim Schaub wrote: > __ __ wrote: >> Hi, >> >> I need a solution which colors a specific country with specific color. >> Any suggestion will be greatly appreciated!!! > > Red. > >> Cheers, >> Anton >> _______________________________________________ >> 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,47220e8b65681030819293! > From cameron.shorter at gmail.com Fri Oct 26 16:19:56 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] OL Vector Layer: What are the Limitations? In-Reply-To: <6ae3fb590710251716k559d42a1nb24993ec75bd7a28@mail.gmail.com> References: <6ae3fb590710251716k559d42a1nb24993ec75bd7a28@mail.gmail.com> Message-ID: <47224BEC.1020101@gmail.com> An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071027/74ac9d78/attachment.html From crschmidt at metacarta.com Sun Oct 28 15:09:31 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] [Incubator] OpenLayers graduation time In-Reply-To: <4724AA54.9020403@pobox.com> References: <1C0D69C7-2EFB-4516-AE9F-2134A2837A35@gmail.com> <4724AA54.9020403@pobox.com> Message-ID: <20071028190931.GA8355@metacarta.com> On Sun, Oct 28, 2007 at 11:27:16AM -0400, Frank Warmerdam wrote: > Howard Butler wrote: > >All, > > > >I would like to motion to graduate OpenLayers from incubation. > >OpenLayers has had the advantage of tailoring their governance, > >infrastructure, and licensing/provenance informed by the expectations of > >OSGeo incubation as the project has grown, and they have completed all > >required activities. > > Folks, > > I declare this motion passed with support from HowardB, DanielM, CameronS, > FrankW, PaulS, ArnulfC, and JodyG, and no dissent. > > The recommendation now goes to the board for final ratification this coming > Friday, but for our purposes I think we can consider it passed, and thus > consider a new incubation candidate for it's slot. But we will hold off on > formal news items and stuff till after Friday's final approval. > > Howard, thank you very much for your work as mentor for the OpenLayers > project, > and to the OpenLayers team - great work! You lapped several founding > projects > still in incubation. :-) Frank, Thank you for your, and OSGeo's support, and we look forward to our continued participation in the OSGeo community! Regards, -- Christopher Schmidt MetaCarta From bartvde at osgis.nl Mon Oct 29 08:10:39 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] defaultIcon: calculateOffset Message-ID: <8fd5abc07c19bbb884892310e4b18471@145.50.39.11> Hi list, can anybody explain why the calculateOffset from the defaultIcon places the icon on top of the point, and not in the center of the point? OpenLayers.Marker.defaultIcon = function() { var url = OpenLayers.Util.getImagesLocation() + "marker.png"; var size = new OpenLayers.Size(21, 25); var calculateOffset = function(size) { return new OpenLayers.Pixel(-(size.w/2), -size.h); }; return new OpenLayers.Icon(url, size, null, calculateOffset); Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl From ahhughes at gmail.com Mon Oct 29 09:35:53 2007 From: ahhughes at gmail.com (Andrew Hughes) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] defaultIcon: calculateOffset In-Reply-To: <8fd5abc07c19bbb884892310e4b18471@145.50.39.11> References: <8fd5abc07c19bbb884892310e4b18471@145.50.39.11> Message-ID: <5f528cf40710290635n7be8ad18q779332f5df35d1d6@mail.gmail.com> IMHO, the intersection point between the two longest of the 4-sides is clearly the focal point..this is the bottom point and... hence the intersection point bottom is aligned over the position. Perhaps what you are really raising is that the default icon does not clearly focus its attention on the bottom of the icon. An arrow / teardrop, flag or triangle may be a clearer option? I would agree the default is not as good as it could be. On 10/29/07, Bart van den Eijnden (OSGIS) wrote: > > Hi list, > > can anybody explain why the calculateOffset from the defaultIcon places > the > icon on top of the point, and not in the center of the point? > > OpenLayers.Marker.defaultIcon = function() { > var url = OpenLayers.Util.getImagesLocation() + "marker.png"; > var size = new OpenLayers.Size(21, 25); > var calculateOffset = function(size) { > return new OpenLayers.Pixel(-(size.w/2), -size.h); > }; > > return new OpenLayers.Icon(url, size, null, calculateOffset); > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20071030/2e9dad11/attachment.html From bartvde at osgis.nl Mon Oct 29 11:13:00 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:36 2010 Subject: [OpenLayers-Dev] prototype cleanWhitespace Message-ID: <29d2ec6b4c44c4234091c40607d410b3@145.50.39.11> Hi list, would it be an idea to include prototype's cleanWhitespace into OpenLayers Util? It's kind of handy when dealing with Mapserver's GML responses which have whitespace in there. Or do people use other techniques? Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl From erik.uzureau at metacarta.com Mon Oct 29 11:41:27 2007 From: erik.uzureau at metacarta.com (Erik Uzureau) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] defaultIcon: calculateOffset In-Reply-To: <8fd5abc07c19bbb884892310e4b18471@145.50.39.11> References: <8fd5abc07c19bbb884892310e4b18471@145.50.39.11> Message-ID: <6ae3fb590710290841h43b0f9f1id40ecc17a997104c@mail.gmail.com> Basically this is because the general markers (icons) that we've been working with are sort of like the gmaps one: the point of focus is on the bottom line center of the icon itself. e On 10/29/07, Bart van den Eijnden (OSGIS) wrote: > Hi list, > > can anybody explain why the calculateOffset from the defaultIcon places the > icon on top of the point, and not in the center of the point? > > OpenLayers.Marker.defaultIcon = function() { > var url = OpenLayers.Util.getImagesLocation() + "marker.png"; > var size = new OpenLayers.Size(21, 25); > var calculateOffset = function(size) { > return new OpenLayers.Pixel(-(size.w/2), -size.h); > }; > > return new OpenLayers.Icon(url, size, null, calculateOffset); > > 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 bartvde at osgis.nl Mon Oct 29 11:47:30 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] defaultIcon: calculateOffset Message-ID: <2be719a94da38b12d88ef5ac372832fb@145.50.39.11> But with this particular icon as a user I would expect the focal point to be in the dot which is approximately in the center of the icon. But I get the logic behind this now more clearly at least, thanks for the explanation (also Andrew ofcourse). Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl --------- Oorspronkelijk bericht -------- Van: Erik Uzureau Naar: Bart van den Eijnden OSGIS Cc: dev@openlayers.org Onderwerp: Re: [OpenLayers-Dev] defaultIcon: calculateOffset Datum: 29/10/07 13:42 > Basically this is because the general markers (icons) that we've been > working with are sort of like the gmaps one: the point of focus is on > the bottom line center of the icon itself. > > e > > On 10/29/07, Bart van den Eijnden (OSGIS) <bartvde@osgis.nl> wrote: > > Hi list, > > > > can anybody explain why the calculateOffset from the defaultIcon places the > > icon on top of the point, and not in the center of the point? > > > > OpenLayers.Marker.defaultIcon = function() { > > var url = OpenLayers.Util.getImagesLocation() + "marker.png"; > > var size = new OpenLayers.Size(21, 25); > > var calculateOffset = function(size) { > > return new OpenLayers.Pixel(-(size.w/2), -size.h); > > }; > > > > return new OpenLayers.Icon(url, size, null, calculateOffset); > > > > 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 eric.c2c at gmail.com Mon Oct 29 15:07:46 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish Message-ID: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> Hi OpenLayers dev! The Camptocamp team will soon be releasing the first version of MapFish (previously known as CartoWeb 4). Before the official (user) release, we want to make MapFish available to developers, and in particular to the OpenLayers dev community. Keep in mind that this isn't a release, there's still things to be done, including documentation and bug fixing. MapFish aims to be an easy-to-use and extensible web GIS application. MapFish is composed of two parts: MapFish Client and MapFish Server. MapFish Client is based on OpenLayers. For MapFish Client we've decided to move away from Dojo and use Ext [1] instead as the GUI framework. We're quite pleased with this change, Ext gives us satistaction in many respects: features, look and feel, documentation. Our move to Ext isn't complete yet. MapFish Server currently provides Python code based on gispython.org [2] Shapely and GeoJSON. The MapFishSample code base provides examples on how to use MapFish Server's Python code. MapFishSample uses the Pylons framework [3], with SQLAlchemy [4] as the ORM. With MapFish Server, we plan to build a a complete webmapping framework based on Pylons. Note also that MapFish Server aims to be RESTful and as compatible as possible with FeatureServer. You can visit to know more about MapFish, check out our demos, access the download page, register to the trac, register to the mailing lists, etc. We're looking forward to your feedback, [1] [2] [3] [4] -- The MapFish dev team From tschaub at openplans.org Mon Oct 29 17:30:44 2007 From: tschaub at openplans.org (Tim Schaub) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> Message-ID: <47265104.5080708@openplans.org> Hey- This looks great! My only other comment is that the "Why MapFish instead of OpenLayers?" question is a bit odd. Seems sort of like asking "Why sandwich instead of bread?" Tim Eric Lemoine wrote: > Hi OpenLayers dev! > > The Camptocamp team will soon be releasing the first version of MapFish > (previously known as CartoWeb 4). Before the official (user) release, we want > to make MapFish available to developers, and in particular to the OpenLayers > dev community. > > Keep in mind that this isn't a release, there's still things to be done, > including documentation and bug fixing. > > MapFish aims to be an easy-to-use and extensible web GIS application. MapFish > is composed of two parts: MapFish Client and MapFish Server. MapFish Client is > based on OpenLayers. > > For MapFish Client we've decided to move away from Dojo and use Ext [1] instead > as the GUI framework. We're quite pleased with this change, Ext gives us > satistaction in many respects: features, look and feel, documentation. > Our move to Ext isn't complete yet. > > MapFish Server currently provides Python code based on gispython.org [2] > Shapely and GeoJSON. The MapFishSample code base provides examples on > how to use MapFish Server's Python code. MapFishSample uses the Pylons > framework [3], with SQLAlchemy [4] as the ORM. With MapFish Server, we > plan to build a a complete webmapping framework based on Pylons. Note > also that MapFish Server aims to be RESTful and as compatible as > possible with FeatureServer. > > You can visit to know more about MapFish, check out > our demos, access the download page, register to the trac, register to the > mailing lists, etc. > > We're looking forward to your feedback, > > [1] > [2] > [3] > [4] > > -- > The MapFish dev team > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > !DSPAM:4033,47262f97161502092453641! > From rdewit at users.sourceforge.net Mon Oct 29 20:00:34 2007 From: rdewit at users.sourceforge.net (Roald de Wit) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] Empty geometries causing errors in IE In-Reply-To: <47220D52.6020904@openplans.org> References: <1193372001.25343.12.camel@bender> <47220D52.6020904@openplans.org> Message-ID: <1193702434.25343.81.camel@bender> On Fri, 2007-10-26 at 09:52 -0600, Tim Schaub wrote: > I'm entirely in favor of this. I don't think the renderer is the right > place to bomb (or hey maybe even throw an exception!) on an empty geometry. > > I think it makes sense to have our format classes throw exceptions on > empty geometries. They could even have an option to allow empty > geometry. In any case, it should be up to the application designer to > decide what to do with empty geometry. As library developers, I don't > think we should impose our beliefs about empty geometries on all others. > > Breaking in only one browser, and only when rendering, is a bit late and > a bit inconsistent. > > > > See ticket #1111 for a simple 'fix'. > > See also http://trac.openlayers.org/ticket/968 > > I'd like to see some tests for the renderers really. I haven't looked > closely at your patch, but it would be nice to make sure we don't slip > once we decide to make a change (like make browser behavior consistent). That fix in the patch I mentioned is probably not the best solution (although it worked for us). A few places where I can imagine we could prevent the renderer from trying to render the empty geometry is: - Renderer/Elements.js: drawGeometryNode() - Renderer.js: drawFeature() - Format/*.js: parseGeometry() It would be nice if we can come up with a clean solution for this. Roald -- Roald de Wit Software Engineer roald.dewit@lisasoft.com Commercial Support for Open Source GIS Software http://lisasoft.com/LISAsoft/SupportedProducts/ From lancelot at inetnebr.com Mon Oct 29 21:51:31 2007 From: lancelot at inetnebr.com (Lance Dyas) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> Message-ID: <47268E23.9020108@inetnebr.com> While it took a while to load I do love the ExtJS interface its down right hot.hmmm liked the old name better than MapFish... (more dignified, guess somebody is shooting for fun instead ;-)) From cameron.shorter at gmail.com Mon Oct 29 22:12:43 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> Message-ID: <4726931B.8040007@gmail.com> Eric, Looks very interesting. Quick questions. I couldn't find a reference to a license on the home page. What will you be using? My first thoughts when I look between server and client is "Should standard protocols be used". Do you see use of OGC Standards to be appropriate here? Or are some of your interfaces appropriate to put forward as a standard? Eric Lemoine wrote: > Hi OpenLayers dev! > > The Camptocamp team will soon be releasing the first version of MapFish > (previously known as CartoWeb 4). Before the official (user) release, we want > to make MapFish available to developers, and in particular to the OpenLayers > dev community. > > Keep in mind that this isn't a release, there's still things to be done, > including documentation and bug fixing. > > MapFish aims to be an easy-to-use and extensible web GIS application. MapFish > is composed of two parts: MapFish Client and MapFish Server. MapFish Client is > based on OpenLayers. > > For MapFish Client we've decided to move away from Dojo and use Ext [1] instead > as the GUI framework. We're quite pleased with this change, Ext gives us > satistaction in many respects: features, look and feel, documentation. > Our move to Ext isn't complete yet. > > MapFish Server currently provides Python code based on gispython.org [2] > Shapely and GeoJSON. The MapFishSample code base provides examples on > how to use MapFish Server's Python code. MapFishSample uses the Pylons > framework [3], with SQLAlchemy [4] as the ORM. With MapFish Server, we > plan to build a a complete webmapping framework based on Pylons. Note > also that MapFish Server aims to be RESTful and as compatible as > possible with FeatureServer. > > You can visit to know more about MapFish, check out > our demos, access the download page, register to the trac, register to the > mailing lists, etc. > > We're looking forward to your feedback, > > [1] > [2] > [3] > [4] > > -- > The MapFish dev team > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Software http://www.lisasoft.com/LISAsoft/SupportedProducts.html From cameron.shorter at gmail.com Tue Oct 30 01:34:35 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] Empty geometries causing errors in IE In-Reply-To: <1193702434.25343.81.camel@bender> References: <1193372001.25343.12.camel@bender> <47220D52.6020904@openplans.org> <1193702434.25343.81.camel@bender> Message-ID: <4726C26B.5040504@gmail.com> Roald de Wit wrote: > On Fri, 2007-10-26 at 09:52 -0600, Tim Schaub wrote: > >> I'm entirely in favor of this. I don't think the renderer is the right >> place to bomb (or hey maybe even throw an exception!) on an empty geometry. >> >> I think it makes sense to have our format classes throw exceptions on >> empty geometries. They could even have an option to allow empty >> geometry. In any case, it should be up to the application designer to >> decide what to do with empty geometry. As library developers, I don't >> think we should impose our beliefs about empty geometries on all others. >> >> Breaking in only one browser, and only when rendering, is a bit late and >> a bit inconsistent. >> >> >> >>> See ticket #1111 for a simple 'fix'. >>> >> See also http://trac.openlayers.org/ticket/968 >> >> I'd like to see some tests for the renderers really. I haven't looked >> closely at your patch, but it would be nice to make sure we don't slip >> once we decide to make a change (like make browser behavior consistent). >> > > That fix in the patch I mentioned is probably not the best solution > (although it worked for us). > > A few places where I can imagine we could prevent the renderer from > trying to render the empty geometry is: > > - Renderer/Elements.js: drawGeometryNode() > - Renderer.js: drawFeature() > - Format/*.js: parseGeometry() > > It would be nice if we can come up with a clean solution for this. > > Roald > > Chris has noted on IRC that he doesn't think VML.setNodeDimension() is the right place to catch this error and after digging around I agree. The problem is that a point geometry is created which has an x,y point of (null, null). This eventually causes an exception in the VML renderer. I propose we fix in Geometry/Point.initialize(x,y) where we should throw an exception if x or y is null. Reason: 1. Exceptions are already raised by Format/KML.js if it needs to create a (null,null) point, so I believe we have a precedence for handling errors by raising exceptions. 2. Our error was caused because Format/GML.js allows the creation of (null,null) points, probably from an empty tag. 3. I don't expect to break any legacy code by forcing Geometry to have valid values because old code would have caused exceptions in VML.js as we discovered. -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Software http://www.lisasoft.com/LISAsoft/SupportedProducts.html From bartvde at osgis.nl Tue Oct 30 03:37:55 2007 From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS)) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish Message-ID: <219375735ea16c3c7546e6a7ac989ad8@145.50.39.11> Wrt the license, the source code says GPL: /* * Copyright (C) 2007 Camptocamp * * This file is part of MapFish * * MapFish is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * MapFish is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with MapFish. If not, see . */ Best regards, Bart -- Bart van den Eijnden OSGIS, Open Source GIS http://www.osgis.nl --------- Oorspronkelijk bericht -------- Van: Cameron Shorter Naar: Eric Lemoine Cc: dev@openlayers ML Onderwerp: Re: [OpenLayers-Dev] MapFish Datum: 30/10/07 00:13 > Eric, > Looks very interesting. > > Quick questions. > I couldn't find a reference to a license on the home page. What will you > be using? > > My first thoughts when I look between server and client is "Should > standard protocols be used". Do you see use of OGC Standards to be > appropriate here? > Or are some of your interfaces appropriate to put forward as a standard? > > Eric Lemoine wrote: > > Hi OpenLayers dev! > > > > The Camptocamp team will soon be releasing the first version of MapFish > > (previously known as CartoWeb 4). Before the official (user) release, we want > > to make MapFish available to developers, and in particular to the OpenLayers > > dev community. > > > > Keep in mind that this isn't a release, there's still things to be done, > > including documentation and bug fixing. > > > > MapFish aims to be an easy-to-use and extensible web GIS application. MapFish > > is composed of two parts: MapFish Client and MapFish Server. MapFish Client is > > based on OpenLayers. > > > > For MapFish Client we've decided to move away from Dojo and use Ext [1] instead > > as the GUI framework. We're quite pleased with this change, Ext gives us > > satistaction in many respects: features, look and feel, documentation. > > Our move to Ext isn't complete yet. > > > > MapFish Server currently provides Python code based on gispython.org [2] > > Shapely and GeoJSON. The MapFishSample code base provides examples on > > how to use MapFish Server's Python code. MapFishSample uses the Pylons > > framework [3], with SQLAlchemy [4] as the ORM. With MapFish Server, we > > plan to build a a complete webmapping framework based on Pylons. Note > > also that MapFish Server aims to be RESTful and as compatible as > > possible with FeatureServer. > > > > You can visit <http://www.mapfish.org> to know more about MapFish, check out > > our demos, access the download page, register to the trac, register to the > > mailing lists, etc. > > > > We're looking forward to your feedback, > > > > [1] <http://extjs.com/> > > [2] <http://gispython.org/> > > [3] <http://pylonshq.com/> > > [4] <http://www.sqlalchemy.org/> > > > > -- > > The MapFish dev team > > _______________________________________________ > > Dev mailing list > > Dev@openlayers.org > > http://openlayers.org/mailman/listinfo/dev > > > > > > > -- > Cameron Shorter > Geospatial Systems Architect > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > Think Globally, Fix Locally > Commercial Support for Geospatial Open Source Software > http://www.lisasoft.com/LISAsoft/SupportedProducts.html > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev > > From eric.c2c at gmail.com Tue Oct 30 03:57:00 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <219375735ea16c3c7546e6a7ac989ad8@145.50.39.11> References: <219375735ea16c3c7546e6a7ac989ad8@145.50.39.11> Message-ID: <5ec103de0710300057o5270405ei3392d8e6ff034d90@mail.gmail.com> On 10/30/07, Bart van den Eijnden (OSGIS) wrote: > Wrt the license, the source code says GPL: It's actually LGPLv3. -- Eric From eric.c2c at gmail.com Tue Oct 30 05:22:32 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <47265104.5080708@openplans.org> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <47265104.5080708@openplans.org> Message-ID: <5ec103de0710300222j635c2d70o97c801ec1e43bfab@mail.gmail.com> On 10/29/07, Tim Schaub wrote: > Hey- > > This looks great! > > My only other comment is that the "Why MapFish instead of OpenLayers?" > question is a bit odd. Seems sort of like asking "Why sandwich instead > of bread?" Hi Tim Indeed, that question did not make any sense. I removed that question from the wiki (and changed things here and there in the project description). Thanks for your feedback, -- Eric From roch.sebastien at gmail.com Tue Oct 30 10:19:26 2007 From: roch.sebastien at gmail.com (=?ISO-8859-1?Q?S=E9bastien_Roch?=) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] FixedZoomLevels Message-ID: Hi Dev, I had a problem with some Google Layers in my map : I had some layers with min and maxScale above a google layer (the baselayer). At first it worked well, but after having zoomed 3 times, the layers don't appear anymore (the google one is ok) If at this moment I eval in the console "map.getScale()", it returns "NaN" I found that the resolutions array of the google layer was not properly set : this is done in FixedZoomLevels.js, in the "initResolutions" function : if (this.RESOLUTIONS != null) { var resolutionsIndex = 0; this.resolutions = []; for(var i= this.minZoomLevel; i < this.numZoomLevels; i++) { this.resolutions[resolutionsIndex++] = this.RESOLUTIONS[i]; } } I changed this part with : if (this.RESOLUTIONS != null) { var resolutionsIndex = 0; this.resolutions = []; for(var i= this.minZoomLevel; i <= this.maxZoomLevel; i++) { // HERE this.resolutions[resolutionsIndex++] = this.RESOLUTIONS[i]; } } And this works for me. Can anyone tell me if this is right ? if not, I'll post my code with my layers, maybe I'm wrong with something. Thanks Sebastien From eric.c2c at gmail.com Tue Oct 30 12:27:49 2007 From: eric.c2c at gmail.com (Eric Lemoine) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <4726931B.8040007@gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> Message-ID: <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> On 10/30/07, Cameron Shorter wrote: > Eric, > Looks very interesting. Hi Cameron > > Quick questions. > I couldn't find a reference to a license on the home page. What will you > be using? Already answered. > My first thoughts when I look between server and client is "Should > standard protocols be used". Do you see use of OGC Standards to be > appropriate here? On the client-side there are components, such as the layer widget, that don't rely on any service. Some others, such as geostat, do rely on services that serve features using GeoJSON. The services support filtering, and we're trying to conform to the parameters specified in OpenSearch Geo. The application developer can also add his own app-specific filter parameters, but the protocol becomes totally custom. As you've probably noted we could have used WFS and Filter Encoding for this. But our goal being to provide an extensible framework on the server side, where the application developer can provide his own code to respond to query of any complexity. I feel that achieving this same level of functionality with WFS and Filter Encoding would much more complex. I'm very interested to hear from you regarding all this. > Or are some of your interfaces appropriate to put forward as a standard? We'll be interested in pushing REST-based interfaces in the realm of feature services and filtering. I often read Sean Gillies' blog (CC:ed to this email) and he also seems to be interested in that area. Thanks, -- Eric From sgillies at frii.com Tue Oct 30 15:41:20 2007 From: sgillies at frii.com (Sean Gillies) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> Message-ID: <472788E0.3000002@frii.com> Eric Lemoine wrote: > On 10/30/07, Cameron Shorter wrote: >> Eric, >> Looks very interesting. > > Hi Cameron > >> Quick questions. >> I couldn't find a reference to a license on the home page. What will you >> be using? > > Already answered. > >> My first thoughts when I look between server and client is "Should >> standard protocols be used". Do you see use of OGC Standards to be >> appropriate here? > > On the client-side there are components, such as the layer widget, > that don't rely on any service. Some others, such as geostat, do rely > on services that serve features using GeoJSON. The services support > filtering, and we're trying to conform to the parameters specified in > OpenSearch Geo. The application developer can also add his own > app-specific filter parameters, but the protocol becomes totally > custom. > > As you've probably noted we could have used WFS and Filter Encoding > for this. But our goal being to provide an extensible framework on the > server side, where the application developer can provide his own code > to respond to query of any complexity. I feel that achieving this same > level of functionality with WFS and Filter Encoding would much more > complex. > > I'm very interested to hear from you regarding all this. > >> Or are some of your interfaces appropriate to put forward as a standard? > > We'll be interested in pushing REST-based interfaces in the realm of > feature services and filtering. I often read Sean Gillies' blog (CC:ed > to this email) and he also seems to be interested in that area. > > Thanks, > > -- > Eric > What could be more standard than REST and HTTP? Cheers, Sean From pspencer at dmsolutions.ca Tue Oct 30 16:45:56 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] safari bug on window resize Message-ID: <33FA5E70-3F68-4C7A-A187-E9E6F8C57F9E@dmsolutions.ca> Devs, there seems to be a bug in Safari 3 (not sure about 2) with trunk where a window resize causes the tiles to disappear. Zak and I tracked this down to the fact that Safari does not trigger an onload event on the image when you set the .src of the image and it is not different from the current src. Our fix was this patch: Index: /ms4w/apps/openlayers/trunk/openlayers/lib/OpenLayers/Tile/ Image.js =================================================================== --- /ms4w/apps/openlayers/trunk/openlayers/lib/OpenLayers/Tile/ Image.js (revision 5069) +++ /ms4w/apps/openlayers/trunk/openlayers/lib/OpenLayers/Tile/ Image.js (working copy) @@ -119,6 +119,7 @@ OpenLayers.Util.modifyAlphaImageDiv(this.imgDiv, null, null, imageSize, this.url); } else { + this.imgDiv.src = ''; this.imgDiv.src = this.url; OpenLayers.Util.modifyDOMElement(this.imgDiv, null, null, imageSize) ; By assigning an empty string, this causes Safari to behave properly when you assign the real source. An alternate patch would be to set the imgDiv.src = '' in the clear function. An alternate patch would be to check if the urls are identical (not sure if checking == is sufficient or if the isEquivalent function should be used) and just show the imgDiv if they are the same: But all this leads me to question what is happening if we are setting the source to the same image? It appears that a window resize is causing the map to redraw as if the zoom level has changed. This causes all the tiles to get cleared. I don't understand why this is necessary. There is code in setCenter to just move the layer container if the zoom hasn't changed and this seems like a reasonable thing, so why is updateSize forcing the zoom to change? I am willing to put together a patch if I can get some feedback on what the right solution would be: 1. clear src just before setting it 2. clear src in the clear function when we hide the imgDiv 3. only set the src if the new url is different from the old url, otherwise just show the imgDiv again 4. change updateSize in Map to not force a zoom level change Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From crschmidt at metacarta.com Tue Oct 30 17:19:32 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] safari bug on window resize In-Reply-To: <33FA5E70-3F68-4C7A-A187-E9E6F8C57F9E@dmsolutions.ca> References: <33FA5E70-3F68-4C7A-A187-E9E6F8C57F9E@dmsolutions.ca> Message-ID: <20071030211932.GA20272@metacarta.com> On Tue, Oct 30, 2007 at 04:45:56PM -0400, Paul Spencer wrote: > Devs, > > there seems to be a bug in Safari 3 (not sure about 2) with trunk > where a window resize causes the tiles to disappear. Zak and I > tracked this down to the fact that Safari does not trigger an onload > event on the image when you set the .src of the image and it is not > different from the current src. Yes, I've discussed this on the list before, a couple weeks ago: http://trac.openlayers.org/ticket/758 > But all this leads me to question what is happening if we are setting > the source to the same image? > > It appears that a window resize is causing the map to redraw as if > the zoom level has changed. This causes all the tiles to get > cleared. I don't understand why this is necessary. There is code in > setCenter to just move the layer container if the zoom hasn't changed > and this seems like a reasonable thing, so why is updateSize forcing > the zoom to change? > > I am willing to put together a patch if I can get some feedback on > what the right solution would be: > > 1. clear src just before setting it > > 2. clear src in the clear function when we hide the imgDiv > > 3. only set the src if the new url is different from the old url, > otherwise just show the imgDiv again > > 4. change updateSize in Map to not force a zoom level change This won't fix the problem in its entirity -- base layer switching will still cause the problem. Regards, -- Christopher Schmidt MetaCarta From cameron.shorter at gmail.com Tue Oct 30 18:20:27 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> Message-ID: <4727AE2B.2040506@gmail.com> Re Open Specs: Assuming specifications are of similar complexity to alternatives, a developer should pick specs as they offer an element of future proofing to an application. Unfortunately some of the OGC specs don't fall into the "similar complexity" category, as evidenced by the level of uptake things like the WFS spec. Encouragingly the OGC has shown signs of recognizing this with their recent "Mass Market" focus. So you are likely to find OGC receptive to suggestions to simple specs, as evidenced by OGC move toward Simple GML and GeoRSS. If you are looking into routing, I suggest you start by looking at the OGC's OpenLS spec. I am not familiar enough with it to make a call on whether a simpler protocol would be more appropriate. Eric Lemoine wrote: > On 10/30/07, Cameron Shorter wrote: > >> Eric, >> Looks very interesting. >> > > Hi Cameron > > >> Quick questions. >> I couldn't find a reference to a license on the home page. What will you >> be using? >> > > Already answered. > > >> My first thoughts when I look between server and client is "Should >> standard protocols be used". Do you see use of OGC Standards to be >> appropriate here? >> > > On the client-side there are components, such as the layer widget, > that don't rely on any service. Some others, such as geostat, do rely > on services that serve features using GeoJSON. The services support > filtering, and we're trying to conform to the parameters specified in > OpenSearch Geo. The application developer can also add his own > app-specific filter parameters, but the protocol becomes totally > custom. > > As you've probably noted we could have used WFS and Filter Encoding > for this. But our goal being to provide an extensible framework on the > server side, where the application developer can provide his own code > to respond to query of any complexity. I feel that achieving this same > level of functionality with WFS and Filter Encoding would much more > complex. > > I'm very interested to hear from you regarding all this. > > >> Or are some of your interfaces appropriate to put forward as a standard? >> > > We'll be interested in pushing REST-based interfaces in the realm of > feature services and filtering. I often read Sean Gillies' blog (CC:ed > to this email) and he also seems to be interested in that area. > > Thanks, > > -- > Eric > > -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Software http://www.lisasoft.com/LISAsoft/SupportedProducts.html From cameron.shorter at gmail.com Tue Oct 30 18:24:47 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <472788E0.3000002@frii.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> <472788E0.3000002@frii.com> Message-ID: <4727AF2F.3070002@gmail.com> Sean Gillies wrote: > > What could be more standard than REST and HTTP? > > Sean, nothing. I was referring to the OGC specs which sit on top of REST and HTTP. -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Software http://www.lisasoft.com/LISAsoft/SupportedProducts.html From crschmidt at metacarta.com Tue Oct 30 20:13:04 2007 From: crschmidt at metacarta.com (Christopher Schmidt) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <4727AF2F.3070002@gmail.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> <472788E0.3000002@frii.com> <4727AF2F.3070002@gmail.com> Message-ID: <20071031001304.GA15115@metacarta.com> On Wed, Oct 31, 2007 at 09:24:47AM +1100, Cameron Shorter wrote: > > Sean Gillies wrote: > > > > What could be more standard than REST and HTTP? > > > > > Sean, nothing. I was referring to the OGC specs which sit on top of REST > and HTTP. I haven't yet seen any OGC specs that 'sit on top of' REST or HTTP. OpenLS definitely doesn't apply, nor do WMS, WFS, or any of the other protocols that OpenLayers supports, as far as I'm aware. Which ones are you thinking about? Regards, -- Christopher Schmidt MetaCarta From pspencer at dmsolutions.ca Tue Oct 30 20:29:00 2007 From: pspencer at dmsolutions.ca (Paul Spencer) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] safari bug on window resize In-Reply-To: <20071030211932.GA20272@metacarta.com> References: <33FA5E70-3F68-4C7A-A187-E9E6F8C57F9E@dmsolutions.ca> <20071030211932.GA20272@metacarta.com> Message-ID: <9214765B-7959-4C92-B019-3541F4509F42@dmsolutions.ca> Chris, On 30-Oct-07, at 5:19 PM, Christopher Schmidt wrote: > On Tue, Oct 30, 2007 at 04:45:56PM -0400, Paul Spencer wrote: >> Devs, >> >> there seems to be a bug in Safari 3 (not sure about 2) with trunk >> where a window resize causes the tiles to disappear. Zak and I >> tracked this down to the fact that Safari does not trigger an onload >> event on the image when you set the .src of the image and it is not >> different from the current src. > > Yes, I've discussed this on the list before, a couple weeks ago: > > http://trac.openlayers.org/ticket/758 I've added a note to the ticket to the effect that the bug also occurs on resize since the ticket only talks about baseLayer switching > >> >> I am willing to put together a patch if I can get some feedback on >> what the right solution would be: >> >> 1. clear src just before setting it >> >> 2. clear src in the clear function when we hide the imgDiv >> >> 3. only set the src if the new url is different from the old url, >> otherwise just show the imgDiv again >> >> 4. change updateSize in Map to not force a zoom level change > > This won't fix the problem in its entirity -- base layer switching > will > still cause the problem. Right. The patch in the above ticket implements option 2 above. Assuming that the patch is eventually reviewed and committed to trunk, this will fix the problem that I am observing. However, it doesn't answer the broader question of why we force a redraw of the layers on a window resize. On Safari, the resize event is emitted continuously. The cost of a redraw is high enough that the window really chunks along during a resize (at least on my machine). If the reason for doing a redraw of the layers is to catch the case where the window grows and the grid has to expand, then I think there could be a lighter weight test that is done on resize before forcing a redraw. Is there another reason for the current behaviour? Cheers Paul +-----------------------------------------------------------------+ |Paul Spencer pspencer@dmsolutions.ca | +-----------------------------------------------------------------+ |Chief Technology Officer | |DM Solutions Group Inc http://www.dmsolutions.ca/ | +-----------------------------------------------------------------+ From cameron.shorter at gmail.com Tue Oct 30 21:45:12 2007 From: cameron.shorter at gmail.com (Cameron Shorter) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <20071031001304.GA15115@metacarta.com> References: <5ec103de0710291207k295f4fc1oe6efad3900d02f2f@mail.gmail.com> <4726931B.8040007@gmail.com> <5ec103de0710300927m44dddb30m93db64d1fecdf7d6@mail.gmail.com> <472788E0.3000002@frii.com> <4727AF2F.3070002@gmail.com> <20071031001304.GA15115@metacarta.com> Message-ID: <4727DE28.3020109@gmail.com> Christopher Schmidt wrote: > On Wed, Oct 31, 2007 at 09:24:47AM +1100, Cameron Shorter wrote: > >> Sean Gillies wrote: >> >>> >>> What could be more standard than REST and HTTP? >>> >>> >>> >> Sean, nothing. I was referring to the OGC specs which sit on top of REST >> and HTTP. >> > > I haven't yet seen any OGC specs that 'sit on top of' REST or HTTP. > OpenLS definitely doesn't apply, nor do WMS, WFS, or any of the other > protocols that OpenLayers supports, as far as I'm aware. > > Which ones are you thinking about? > > Regards, > I stand corrected. -- Cameron Shorter Geospatial Systems Architect Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Commercial Support for Geospatial Open Source Software http://www.lisasoft.com/LISAsoft/SupportedProducts.html From pat at cappelaere.com Wed Oct 31 08:18:56 2007 From: pat at cappelaere.com (Pat Cappelaere) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] MapFish In-Reply-To: <4727AF2F.3070002@gmail.com> Message-ID: I would really disagree with that statement. A REST-RPC style interface is not RESTful and appropriate for the Mass Market. So the current OGC specs are not quite there yet. But the OGC has recognized that and is working on this for OWS-5. There is still a challenge on the table for a RESTful WMS (which has been picked up by Arnulf) I am currently working hard at pushing those issues to the surface. We are having good success with the Workflow Chaining Service and Pubusb. I need to start the documentation process. Our version of the RESTful WFS is falling a little behind because of lack of funding... Hopefully, the SoCal fires are bringing some attention to the issues... http://blog.geobliki.com Pat. > From: Cameron Shorter > Organization: LISAsoft > Date: Wed, 31 Oct 2007 09:24:47 +1100 > To: Sean Gillies > Cc: "dev@openlayers ML" > Subject: Re: [OpenLayers-Dev] MapFish > > > Sean Gillies wrote: >> >> What could be more standard than REST and HTTP? >> >> > Sean, nothing. I was referring to the OGC specs which sit on top of REST > and HTTP. > > -- > Cameron Shorter > Geospatial Systems Architect > Tel: +61 (0)2 8570 5050 > Mob: +61 (0)419 142 254 > > Think Globally, Fix Locally > Commercial Support for Geospatial Open Source Software > http://www.lisasoft.com/LISAsoft/SupportedProducts.html > > > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev From richard.thurbin at cloudamber.com Wed Oct 31 20:51:34 2007 From: richard.thurbin at cloudamber.com (Richard Thurbin) Date: Wed Sep 1 17:23:37 2010 Subject: [OpenLayers-Dev] Sliverlight Message-ID: <47292316.3080808@cloudamber.com> Following on from the flash based mapping client posted a few days ago, I stumbled across this Microsoft Silverlight based version: http://silverlight.net/samples/1.1/virtualearthviewer/ I very much like the fade effects, smooth pan & zoom and speed wise it seems bang on. The only thing it needs navigation wise is a "window" tool to zoom in and out very quickly. Thoughts? -- Richard Thurbin www.cloudamber.com +44 7917 704 145