From bluecarto at gmail.com  Tue Apr  1 07:42:00 2008
From: bluecarto at gmail.com (Pierre GIRAUD)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] I Can Haz RC1?
In-Reply-To: <20080331055853.GA5857@metacarta.com>
References: <20080331055853.GA5857@metacarta.com>
Message-ID: <d50f50e60804010442t11a413e3i8d6aeb13d7c7e6c6@mail.gmail.com>

+1

On Mon, Mar 31, 2008 at 7:58 AM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> (Sorry for the lolspeak: it's that whole 2am thing.)
>
>  Erik and I have just done a 4 hour hack session and gotten the remaining
>  tickets in OpenLayers 2.6 resolved. At this point in time, there is no
>  outstanding issue recorded in trac as a regression against 2.5, nor are
>  there any issues which we have stated we would address in 2.6 left open.
>
>  Therefore, at this time, I am asking for a vote on a 2.6 RC1.
>
>  I am +1 on branching the current trunk to 2.6, and releasing that as an
>  RC1 as soon as possible, and then advertising far and wide for testing,
>  especially of popup-related usage.
>
>  If anyone has any major complaints, now is the time to bring them up.
>
>  I am +1 on branching trunk and releasing RC1.
>
>  Regards,
>  --
>  Christopher Schmidt
>  MetaCarta
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>

From crschmidt at metacarta.com  Tue Apr  1 08:23:49 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 RC1
Message-ID: <20080401122349.GE21204@metacarta.com>

The OpenLayers Development Team is proud to announce the first release
candidate of OpenLayers 2.6.  As of 2.6-RC1, the OpenLayers 2.6 release
closes 282 outstanding tickets, 75% more than any OpenLayers release to
date. 

For information on possible changes that will need to be made between
this version of OpenLayers and previous versions, please look at the
Release notes, available at the Release Notes information[1].

We invite you to help us test the 2.6 release candidate! To test 2.6 in
your applications, include the following tag in your OpenLayers-powered
page:

  <script src="http://openlayers.org/api/2.6-rc1/OpenLayers.js"></script>

As always, the source is available at http://openlayers.org/download/.
Bug reports can be filed in Trac, under the 2.6 version and milestone.

This is a large release: the largest of any OpenLayers release to date.
We encourage widescale testing in an effort to shake out any bugs in
upgrading existing applications to OpenLayers 2.6. This release features
a number of major developments, including:
  
  * Integration of the CloudAmber "Google Like" popups for advanced
    visual display of information in popups
    * Resulting improvements throughout all popup code, including
      autosizing popups to the content they contain.
  * Improved panning of commercial layers like Google Maps and Yahoo! Maps
  * Animated panning of the map, using OpenLayers.Tween support
  * Layer Image transitions, for keeping images visible when zooming
    to allow smoother transitions
  * Client side reprojection support using built in transformations for
    spherical mercator, or the proj4js library for other projections.
    * Support for reprojecting vector data layers
    * Support for reprojecting user-facing controls like mouseposition
    * Support for programatically reprojecting points and geometries 
  * Improved OpenLayers Styling, including:
    * OpenLayers.Style, OpenLayers.StyleMap, OpenLayers.Rule support
      for improved feature-attribute based styling
    * SLD read/write support 
  * Support for reading and writing multiple versions of WMC.
  * Improved KML support, including KML styling support.
  * Improved GeoRSS Format support, including GeoRSS GML read support.
  * New ScaleLine Control for displaying visual scale
  * New NavigationHistory control for map history navigation
  * Localization/Better Internationalization support
  * Layer support for MapGuide Open Source 
  * A number of new / improved handlers to make handling user
    interactions easier
     * Handler.Hover
     * Handler.Click
     
There are a number of people who have really made this release happen.

TOPP and MetaCarta worked together to arrange for several day long 'hack
session' in TOPP's office in New York City with myself, Erik, and Tim
Schaub: This session was extremely productive, and ended up producing a
huge amount of code for the relatively little amount of time we were all
able to get together. Without that several day long session, I think
we'd still be far from a release. Many thanks to Chris Holmes from TOPP 
and John Frank/Josiah Strandberg at MetaCarta for supporting that effort. 

A list of people who stic out to me as having helped especially to make
this release happen:
 * Andreas Hocevar (TOPP)
 * Tim Schaub (TOPP)
 * Roald DeWit (LISAsoft)
 * Bart van den Eijnden (OSGIS)
 * Erik Uzureau (MetaCarta)
 * Eric Lemoine (Camptocamp)
 * Pierre Giraud (Camptocamp)
 * Fred Junod (Camptocamp)
 * Paul Spencer (DM Solutions)
 * Mike Adair (DM Solutions)
 * All the other testers, commenters, etc.

This is by no means a complete list: There are dozens of people who I
have interacted with that deserve to be on this list, but these are the
ones who stick out in my mind as being a major boon to the current
release.

Additionally, I'd like to speak high praises about the users who helped
out during the hackathon during FOSS4G. Although it's hard to believe,
the FOSS4G hack session was during the current (2.6) release cycle, and
we picked up some really great additions to the library, like our new
Fancier examples list http://openlayers.org/dev/doc/examples.html  as a
result of the hard work put together in a single day by a bunch of
people who had never touched OpenLayers before. So thank you to those
people as well.

Further RC announcements will be sent only to the Developers list:
anyone interested in tracking the progress to a final release should
subscribe[2] to that list.

We look forward to your feedback on this release.

[1] http://trac.openlayers.org/wiki/Release/2.6/Notes#Changestoexistingapplicationsfrompreviousversions
[2] http://openlayers.org/mailman/listinfo/dev

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Wed Apr  2 10:20:51 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] When to do the next RC?
Message-ID: <20080402142051.GA3023@metacarta.com>

We have closed three bugs since our RC1 yesterday morning:

#1477
    VML renderer draws features in the upperleft corner of the map pane
    Fix: change VML namespace to 'olv' instead of 'v', which conflicts
      with existing applications.
#1479
    Popup.FramedCloud reports error in setContentHTML
    Fix: Don't run createBlocks or updateBlocks unless relativePosition
      is set. 
#1480
    Handler Hover causes exceptions on Firefox/Windows
    Fix: Don't call hasOwnProperty on window.Event.

It is my belief that none of these are likely to affect other
functionality. It is also my belief that a few more days of testing will
likely turn up more bugs.

At this time, I believe that we should hold off on another RC until
Friday, to allow more bug reports to come in. If we do not have any
additional bug reports at that time, we will do another RC with the
current fixes pulled into 2.6. (This saves the time/effort of kicking
out another RC, announcement email, etc. having people update their
applications and so on.)

Current plan of action: RC2 Friday morning assuming no further issues.

Regards,
-- 
Christopher Schmidt
MetaCarta

From euzuro at gmail.com  Wed Apr  2 11:34:30 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] When to do the next RC?
In-Reply-To: <20080402142051.GA3023@metacarta.com>
References: <20080402142051.GA3023@metacarta.com>
Message-ID: <6ae3fb590804020834n2d20693di2bbd6d1e730b8f97@mail.gmail.com>

Good plan, Chris. Friday sounds good... or even Monday, to give people
the weekend (for those of us who
work outside work hours)

e


On Wed, Apr 2, 2008 at 10:20 AM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> We have closed three bugs since our RC1 yesterday morning:
>
> #1477
>    VML renderer draws features in the upperleft corner of the map pane
>    Fix: change VML namespace to 'olv' instead of 'v', which conflicts
>      with existing applications.
> #1479
>    Popup.FramedCloud reports error in setContentHTML
>    Fix: Don't run createBlocks or updateBlocks unless relativePosition
>      is set.
> #1480
>    Handler Hover causes exceptions on Firefox/Windows
>    Fix: Don't call hasOwnProperty on window.Event.
>
> It is my belief that none of these are likely to affect other
> functionality. It is also my belief that a few more days of testing will
> likely turn up more bugs.
>
> At this time, I believe that we should hold off on another RC until
> Friday, to allow more bug reports to come in. If we do not have any
> additional bug reports at that time, we will do another RC with the
> current fixes pulled into 2.6. (This saves the time/effort of kicking
> out another RC, announcement email, etc. having people update their
> applications and so on.)
>
> Current plan of action: RC2 Friday morning assuming no further issues.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From eric.c2c at gmail.com  Wed Apr  2 11:39:09 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] When to do the next RC?
In-Reply-To: <20080402142051.GA3023@metacarta.com>
References: <20080402142051.GA3023@metacarta.com>
Message-ID: <5ec103de0804020839n4f438126wf55c96387853da6d@mail.gmail.com>

On Wed, Apr 2, 2008 at 4:20 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> We have closed three bugs since our RC1 yesterday morning:
>
>  #1477
>     VML renderer draws features in the upperleft corner of the map pane
>     Fix: change VML namespace to 'olv' instead of 'v', which conflicts
>       with existing applications.
>  #1479
>     Popup.FramedCloud reports error in setContentHTML
>     Fix: Don't run createBlocks or updateBlocks unless relativePosition
>       is set.
>  #1480
>     Handler Hover causes exceptions on Firefox/Windows
>     Fix: Don't call hasOwnProperty on window.Event.
>
>  It is my belief that none of these are likely to affect other
>  functionality. It is also my belief that a few more days of testing will
>  likely turn up more bugs.
>
>  At this time, I believe that we should hold off on another RC until
>  Friday, to allow more bug reports to come in. If we do not have any
>  additional bug reports at that time, we will do another RC with the
>  current fixes pulled into 2.6. (This saves the time/effort of kicking
>  out another RC, announcement email, etc. having people update their
>  applications and so on.)
>
>  Current plan of action: RC2 Friday morning assuming no further issues.

Yes, no need for an RC2 at this point I think.

And I'd agree with Erik, let's wait for Monday, we all know that
people leave things that really matter for weekends :-)

--
Eric

From crschmidt at metacarta.com  Wed Apr  2 13:53:45 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] When to do the next RC?
In-Reply-To: <5ec103de0804020839n4f438126wf55c96387853da6d@mail.gmail.com>
References: <20080402142051.GA3023@metacarta.com>
	<5ec103de0804020839n4f438126wf55c96387853da6d@mail.gmail.com>
Message-ID: <20080402175345.GB14640@metacarta.com>

On Wed, Apr 02, 2008 at 05:39:09PM +0200, Eric Lemoine wrote:
> And I'd agree with Erik, let's wait for Monday, we all know that
> people leave things that really matter for weekends :-)

That's actually part of my motivation: if we're likely to find bug with
this (small) set of changes, it's likely with people testing the RC over
the weekend. If our current changes broke *other* things, then having them
tested extensively over the weekend should find it.

Regards,
-- 
Christopher Schmidt
MetaCarta

From euzuro at gmail.com  Wed Apr  2 15:20:20 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] When to do the next RC?
In-Reply-To: <20080402175345.GB14640@metacarta.com>
References: <20080402142051.GA3023@metacarta.com>
	<5ec103de0804020839n4f438126wf55c96387853da6d@mail.gmail.com>
	<20080402175345.GB14640@metacarta.com>
Message-ID: <6ae3fb590804021220m7f103e56g36cd3ef7b357775c@mail.gmail.com>

Fair enough! :-)
friday it is

On Wed, Apr 2, 2008 at 1:53 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> On Wed, Apr 02, 2008 at 05:39:09PM +0200, Eric Lemoine wrote:
> > And I'd agree with Erik, let's wait for Monday, we all know that
> > people leave things that really matter for weekends :-)
>
> That's actually part of my motivation: if we're likely to find bug with
> this (small) set of changes, it's likely with people testing the RC over
> the weekend. If our current changes broke *other* things, then having them
> tested extensively over the weekend should find it.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From tschaub at openplans.org  Thu Apr  3 00:14:43 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
Message-ID: <47F459B3.4030508@openplans.org>

Hey-

I know this won't concern too many people, but I thought I'd ask for 
opinions anyway.

The new style work includes the addition of OpenLayers.Rule and 
subclasses.  The base Rule class corresponds well to the sld:Rule 
element in the SLD spec (min/max limits constraints, symbolizers, etc.).

The subclasses of Rule (Comparison, FeatureId, and Logical) correspond 
well to ogc:Filter elements in the Filter Encoding specification. 
Though our Rule subclasses can have a symbolizer, an ogc:Filter knows 
nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an 
sld:Rule that has a symbolizer.

Filters are useful for more than just SLD.  If we ever want to support 
filters in WFS, it would be useful to use the code currently in the Rule 
subclasses (minus the symbolizer and min/max scale limits).  There is 
code in the SLD format for reading and writing ogc:Filter elements that 
could be pulled out in to a Filter format class.

Since 2.6 is upon us, there are two scenarios that make sense to me:

1) Do no mark Rule subclasses as part of the API.  Later, change them so 
they are Filter subclasses and require that they be added to a Rule 
(with a symbolizer) for things like styling.  They could also be used 
alone (without rules) for things like WFS.  This would also require 
changing the georss-flickr.html example (that uses Rule.Comparison) and 
the wiki page on styling.

2) Add Filter classes later and keep (the redundant) Rule subclasses 
around until 3.0.


Any ideas?

Tim

From rdewit at users.sourceforge.net  Thu Apr  3 00:59:32 2008
From: rdewit at users.sourceforge.net (Roald de Wit)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47F459B3.4030508@openplans.org>
References: <47F459B3.4030508@openplans.org>
Message-ID: <1207198772.25691.65.camel@bender>

Hi Tim,

On Wed, 2008-04-02 at 22:14 -0600, Tim Schaub wrote:
> 1) Do no mark Rule subclasses as part of the API.  Later, change them so 
> they are Filter subclasses and require that they be added to a Rule 
> (with a symbolizer) for things like styling.  They could also be used 
> alone (without rules) for things like WFS.  This would also require 
> changing the georss-flickr.html example (that uses Rule.Comparison) and 
> the wiki page on styling.
> 
> 2) Add Filter classes later and keep (the redundant) Rule subclasses 
> around until 3.0.

I opt for scenario 1. At the moment we're working on improving WFS a bit
(removing the 'flashing' of features on reload of a tile) and we are
looking at using filters in WFS (and facing the mutually exclusive bbox
& filter parameters challenge).

Since 3.0 can be quite far away, SLD Rules have just been introduced in
2.6 and me believing that that less redundancy is better, I'd like the
Rule subclasses to be no API method in 2.6.

Regards,

Roald

-- 
Roald de Wit
Software Engineer
roald.dewit@lisasoft.com

Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/


From andreas.hocevar at gmail.com  Thu Apr  3 04:21:39 2008
From: andreas.hocevar at gmail.com (Andreas Hocevar)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47F459B3.4030508@openplans.org>
References: <47F459B3.4030508@openplans.org>
Message-ID: <5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>

Tim-

On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub@openplans.org> wrote:
>  The new style work includes the addition of OpenLayers.Rule and
>  subclasses.  The base Rule class corresponds well to the sld:Rule
>  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
>
>  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
>  well to ogc:Filter elements in the Filter Encoding specification.
>  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
>  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
>  sld:Rule that has a symbolizer.

To me, a logical step would be to have one Rule class, which has
minScale, maxScale, symbolizer, and a filter property. There would be
a new class OpenLayers.Filter with subclasses with the filter-related
code of the current Rule subclasses. I think that is in line with what
you think.

>  1) Do no mark Rule subclasses as part of the API.  Later, change them so
>  they are Filter subclasses and require that they be added to a Rule
>  (with a symbolizer) for things like styling.  They could also be used
>  alone (without rules) for things like WFS.  This would also require
>  changing the georss-flickr.html example (that uses Rule.Comparison) and
>  the wiki page on styling.

I am in favour of that option. We do not encourage people to touch
rules directly anyway (except for the georss-flickr example).

Also, the proposed change does not look like too much work to me.

>  2) Add Filter classes later and keep (the redundant) Rule subclasses
>  around until 3.0.

Nope.

Regards,
Andreas.

From crschmidt at metacarta.com  Sat Apr  5 06:49:42 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
Message-ID: <20080405104941.GA3372@metacarta.com>

On Thu, Apr 03, 2008 at 10:21:39AM +0200, Andreas Hocevar wrote:
> On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub@openplans.org> wrote:
> >  The new style work includes the addition of OpenLayers.Rule and
> >  subclasses.  The base Rule class corresponds well to the sld:Rule
> >  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
> >
> >  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
> >  well to ogc:Filter elements in the Filter Encoding specification.
> >  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
> >  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
> >  sld:Rule that has a symbolizer.
> 
> To me, a logical step would be to have one Rule class, which has
> minScale, maxScale, symbolizer, and a filter property. There would be
> a new class OpenLayers.Filter with subclasses with the filter-related
> code of the current Rule subclasses. I think that is in line with what
> you think.
> 
> >  1) Do no mark Rule subclasses as part of the API.  Later, change them so
> >  they are Filter subclasses and require that they be added to a Rule
> >  (with a symbolizer) for things like styling.  They could also be used
> >  alone (without rules) for things like WFS.  This would also require
> >  changing the georss-flickr.html example (that uses Rule.Comparison) and
> >  the wiki page on styling.
> 
> I am in favour of that option. We do not encourage people to touch
> rules directly anyway (except for the georss-flickr example).
> 
> Also, the proposed change does not look like too much work to me.

I must be missing something.

We've got significant new functionality that allows you to style
features based on their attributes via the Style/Rule system, a I
understand it.

This allows me to, for example, take a list of places named Cambridge,
around the world, with their population values, and give them different
sizes and colors according to population:

  http://crschmidt.net/mapping/cambridge-geojson.html

As much as I feel that the current system is somewhat complex, I do
think it's pretty cool. Not a lot of code, given how much has to be
done: it's not an easy problem to solve. This seems to me to have a
clear benefit for thematic mapping: it fits neatly into what used to be
forced into the application space, I think.

I can't figure out how to do this without using OpenLayers.Rule
subclasses.

Are we saying we're going to not make a committment to supporting
applications written against this system in 2.6 going forward? That my
cambridge-geojson example may break in the future?

I understand that perhaps we chose the wrong name. I'm cool with that;
we may want to change it in the future. But from what I understand,
Filters would replace Rule subclasses pretty directly: there wouldn't be
some *other* kind of Rule.Comparison that we would want that namespace
for, it would just be moving to Filter.Comparison instead. (If I'm wrong
on this, that would be good to know.)

Given that, I don't see how stating that we will maintain these classes
going forward hurts us. If users find that they transition their
applications, they can simply exclude the Rule subclasses from their
personal build profile, and they'll have the support they need. Heck, we
could even pull them out of the default build profile, with specific
instructions on how to keep them around, if file size is the concern.
I do believe that we should not require application authors who write
against this code in 2.6 to have to change their applications before
they can use 2.7. If we go that route, in my opinion, we're abondoning
the feature for this release... before it's even been used.

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Sat Apr  5 11:52:51 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
Message-ID: <5ec103de0804050852t34dad054k61376157ebf58a92@mail.gmail.com>

On Thu, Apr 3, 2008 at 10:21 AM, Andreas Hocevar
<andreas.hocevar@gmail.com> wrote:
> Tim-
>
>
>  On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub@openplans.org> wrote:
>  >  The new style work includes the addition of OpenLayers.Rule and
>  >  subclasses.  The base Rule class corresponds well to the sld:Rule
>  >  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
>  >
>  >  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
>  >  well to ogc:Filter elements in the Filter Encoding specification.
>  >  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
>  >  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
>  >  sld:Rule that has a symbolizer.
>
>  To me, a logical step would be to have one Rule class, which has
>  minScale, maxScale, symbolizer, and a filter property. There would be
>  a new class OpenLayers.Filter with subclasses with the filter-related
>  code of the current Rule subclasses. I think that is in line with what
>  you think.
>
>
>  >  1) Do no mark Rule subclasses as part of the API.  Later, change them so
>  >  they are Filter subclasses and require that they be added to a Rule
>  >  (with a symbolizer) for things like styling.  They could also be used
>  >  alone (without rules) for things like WFS.  This would also require
>  >  changing the georss-flickr.html example (that uses Rule.Comparison) and
>  >  the wiki page on styling.
>
>  I am in favour of that option. We do not encourage people to touch
>  rules directly anyway (except for the georss-flickr example).

I find it a bit weird to show people an example that uses Rule
subclasses and encourage those same people not to use these
subclasses.

--
Eric

From tschaub at openplans.org  Sat Apr  5 13:13:31 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080405104941.GA3372@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
Message-ID: <47F7B33B.4000802@openplans.org>

Christopher Schmidt wrote:
> On Thu, Apr 03, 2008 at 10:21:39AM +0200, Andreas Hocevar wrote:
>> On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub@openplans.org> wrote:
>>>  The new style work includes the addition of OpenLayers.Rule and
>>>  subclasses.  The base Rule class corresponds well to the sld:Rule
>>>  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
>>>
>>>  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
>>>  well to ogc:Filter elements in the Filter Encoding specification.
>>>  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
>>>  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
>>>  sld:Rule that has a symbolizer.
>> To me, a logical step would be to have one Rule class, which has
>> minScale, maxScale, symbolizer, and a filter property. There would be
>> a new class OpenLayers.Filter with subclasses with the filter-related
>> code of the current Rule subclasses. I think that is in line with what
>> you think.
>>
>>>  1) Do no mark Rule subclasses as part of the API.  Later, change them so
>>>  they are Filter subclasses and require that they be added to a Rule
>>>  (with a symbolizer) for things like styling.  They could also be used
>>>  alone (without rules) for things like WFS.  This would also require
>>>  changing the georss-flickr.html example (that uses Rule.Comparison) and
>>>  the wiki page on styling.
>> I am in favour of that option. We do not encourage people to touch
>> rules directly anyway (except for the georss-flickr example).
>>
>> Also, the proposed change does not look like too much work to me.
> 
> I must be missing something.
> 
> We've got significant new functionality that allows you to style
> features based on their attributes via the Style/Rule system, a I
> understand it.
> 
> This allows me to, for example, take a list of places named Cambridge,
> around the world, with their population values, and give them different
> sizes and colors according to population:
> 
>   http://crschmidt.net/mapping/cambridge-geojson.html
> 
> As much as I feel that the current system is somewhat complex, I do
> think it's pretty cool. Not a lot of code, given how much has to be
> done: it's not an easy problem to solve. This seems to me to have a
> clear benefit for thematic mapping: it fits neatly into what used to be
> forced into the application space, I think.
> 
> I can't figure out how to do this without using OpenLayers.Rule
> subclasses.
> 
> Are we saying we're going to not make a committment to supporting
> applications written against this system in 2.6 going forward? That my
> cambridge-geojson example may break in the future?
> 
> I understand that perhaps we chose the wrong name. I'm cool with that;
> we may want to change it in the future. But from what I understand,
> Filters would replace Rule subclasses pretty directly: there wouldn't be
> some *other* kind of Rule.Comparison that we would want that namespace
> for, it would just be moving to Filter.Comparison instead. (If I'm wrong
> on this, that would be good to know.)
> 

The OpenLayers.Rule class comes from the sld:Rule element.  A rule in 
SLD has optional constraints on scale (sld:MinScaleDenominator and 
sld:MaxScaleDenominator), typically has symbolizers (for Point, Line, 
Polygon, etc), and optionally has an ogc:Filter element.

In the Filter Encoding spec (where you find the description of 
ogc:Filter elements), there are a number of types of filters.  These 
include comparison filters, feature id filters, and logical filters.  In 
OpenLayers (currently) the subclasses of OpenLayers.Rule map directly to 
these types of ogc:Filter.

The problem is not only one of naming.  An sld:Rule *has* an ogc:Filter. 
   So a rule can have a feature id filter for example.  In OpenLayers, 
an OpenLayers.Rule.FeatureId *is* a rule.

The difference is that rules have things like scale constraints and 
symbolizers.  Filters do not have scale constraints and symbolizers.  A 
filter is the child of a rule.  A filter is not a rule.

So, OpenLayers.Rule.FeatureId would become OpenLayers.Filter.FeatureId. 
  This filter could be used for more than just styling - it could, for 
example, be serialized and used in a WFS query.  This has nothing to do 
with styling.

So yes, your cambridge example would break in the future.  Instead you 
would do something like:

var rule = new OpenLayers.Rule({
     symbolizer: {"Point": {"fillColor": "fuchsia"}},
     filter: new OpenLayers.Filter.Comparison({
         type: OpenLayers.Filter.Comparison.GREATER_THAN_OR_EQUAL_TO,
         property: "Population",
         value: 10000
     })
});

// or

var rule = new OpenLayers.Rule({
     symbolizer: {"Point": {"fillColor": "fuchsia"}},
     filter: new OpenLayers.Filter.Logical({
         type: OpenLayers.Filter.Logical.AND,
         filters: [
             new OpenLayers.Filter.Comparison({
                 type: OpenLayers.Filter.Comparison.LESS_THAN,
                 property: "Population",
                 value: 100000,
             }),
             new OpenLayers.Filter.Comparison({
                 type: OpenLayers.Filter.Comparison.GREATER_THAN,
                 property: "Population",
                 value: 0,
             })
         ]
     })
});

The difference is that rules have symbolizers and a filter (optionally). 
  Filters do not have symbolizers.  A logical filter has child filters.

My question was whether we wanted to
1) change this before 2.6, or
2) change this after 2.6.

If we change after 2.6, then we decide whether to wait for 3.0 or 
whether to release with the rule subclasses as not part of the API 
(subject to change).

I'm happy to write up a patch if we want to do this before 2.6 (which I 
do of course*).

Tim

* In the future, I'm also in favor of branching in advance of a release 
so we don't release brand spanking new features with unstable interfaces.

> Given that, I don't see how stating that we will maintain these classes
> going forward hurts us. If users find that they transition their
> applications, they can simply exclude the Rule subclasses from their
> personal build profile, and they'll have the support they need. Heck, we
> could even pull them out of the default build profile, with specific
> instructions on how to keep them around, if file size is the concern.
> I do believe that we should not require application authors who write
> against this code in 2.6 to have to change their applications before
> they can use 2.7. If we go that route, in my opinion, we're abondoning
> the feature for this release... before it's even been used.
> 
> Regards,


From crschmidt at metacarta.com  Sat Apr  5 14:25:29 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <5ec103de0804050852t34dad054k61376157ebf58a92@mail.gmail.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<5ec103de0804050852t34dad054k61376157ebf58a92@mail.gmail.com>
Message-ID: <20080405182529.GA10278@metacarta.com>

On Sat, Apr 05, 2008 at 05:52:51PM +0200, Eric Lemoine wrote:
> On Thu, Apr 3, 2008 at 10:21 AM, Andreas Hocevar
> <andreas.hocevar@gmail.com> wrote:
> > Tim-
> >
> >
> >  On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub@openplans.org> wrote:
> >  >  The new style work includes the addition of OpenLayers.Rule and
> >  >  subclasses.  The base Rule class corresponds well to the sld:Rule
> >  >  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
> >  >
> >  >  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
> >  >  well to ogc:Filter elements in the Filter Encoding specification.
> >  >  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
> >  >  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
> >  >  sld:Rule that has a symbolizer.
> >
> >  To me, a logical step would be to have one Rule class, which has
> >  minScale, maxScale, symbolizer, and a filter property. There would be
> >  a new class OpenLayers.Filter with subclasses with the filter-related
> >  code of the current Rule subclasses. I think that is in line with what
> >  you think.
> >
> >
> >  >  1) Do no mark Rule subclasses as part of the API.  Later, change them so
> >  >  they are Filter subclasses and require that they be added to a Rule
> >  >  (with a symbolizer) for things like styling.  They could also be used
> >  >  alone (without rules) for things like WFS.  This would also require
> >  >  changing the georss-flickr.html example (that uses Rule.Comparison) and
> >  >  the wiki page on styling.
> >
> >  I am in favour of that option. We do not encourage people to touch
> >  rules directly anyway (except for the georss-flickr example).
> 
> I find it a bit weird to show people an example that uses Rule
> subclasses and encourage those same people not to use these
> subclasses.

Yeah, I think that the idea is that we would remove that functionality
from the georss-flickr example, so far as I can tell...

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Sat Apr  5 14:57:31 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47F7B33B.4000802@openplans.org>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
Message-ID: <20080405185730.GB10278@metacarta.com>

On Sat, Apr 05, 2008 at 11:13:31AM -0600, Tim Schaub wrote:
> The OpenLayers.Rule class comes from the sld:Rule element.  A rule in 
> SLD has optional constraints on scale (sld:MinScaleDenominator and 
> sld:MaxScaleDenominator), typically has symbolizers (for Point, Line, 
> Polygon, etc), and optionally has an ogc:Filter element.

Right.

> In the Filter Encoding spec (where you find the description of 
> ogc:Filter elements), there are a number of types of filters.  These 
> include comparison filters, feature id filters, and logical filters.  In 
> OpenLayers (currently) the subclasses of OpenLayers.Rule map directly to 
> these types of ogc:Filter.

Right.  

> The problem is not only one of naming.  An sld:Rule *has* an ogc:Filter. 
>    So a rule can have a feature id filter for example.  In OpenLayers, 
> an OpenLayers.Rule.FeatureId *is* a rule.

Sure. It's a combination of the Filter and Rule into a single object for
convenience, right? There's no replacement for 
OpenLayers.Rule.FeatureID that wouldn't do the same thing the current
one does, is there?

> The difference is that rules have things like scale constraints and 
> symbolizers.  Filters do not have scale constraints and symbolizers.  A 
> filter is the child of a rule.  A filter is not a rule.

Understood. So currently (as far as I understand it), we have Rule,
which encompasses Rule + Filter, and in the future, we could make the
seperation into Rule and Filter explicit: So Rule.FeatureID would
(internally) create a Filter.FeatureID with the properties that are
specified in the filter.

> So, OpenLayers.Rule.FeatureId would become OpenLayers.Filter.FeatureId. 

Sort of, I think? OpenLayers.Rule.FeatureId would become OpenLayers.Rule
+ OpenLayers.Filter.FeatureId?

>   This filter could be used for more than just styling - it could, for 
> example, be serialized and used in a WFS query.  This has nothing to do 
> with styling.

Agreed. Filters are valuable.

> So yes, your cambridge example would break in the future.  Instead you 
> would do something like:
> 
> var rule = new OpenLayers.Rule({
>      symbolizer: {"Point": {"fillColor": "fuchsia"}},
>      filter: new OpenLayers.Filter.Comparison({
>          type: OpenLayers.Filter.Comparison.GREATER_THAN_OR_EQUAL_TO,
>          property: "Population",
>          value: 10000
>      })
> });

Alternatively, we add Filters, and make Rule subclasses a convenience
method that takes everything but the Rule-specific properties and passes
them onto the Filter? 

> var rule = new OpenLayers.Rule({
>      symbolizer: {"Point": {"fillColor": "fuchsia"}},
>      filter: new OpenLayers.Filter.Logical({
>          type: OpenLayers.Filter.Logical.AND,
>          filters: [
>              new OpenLayers.Filter.Comparison({
>                  type: OpenLayers.Filter.Comparison.LESS_THAN,
>                  property: "Population",
>                  value: 100000,
>              }),
>              new OpenLayers.Filter.Comparison({
>                  type: OpenLayers.Filter.Comparison.GREATER_THAN,
>                  property: "Population",
>                  value: 0,
>              })
>          ]
>      })
> });
> 
> The difference is that rules have symbolizers and a filter (optionally). 
>   Filters do not have symbolizers.  A logical filter has child filters.

Right. To me, this doesn't indicate that we should get rid of
Rule.FeatureID: instead, that we should make it a wrapper around
Rule+Filter. 

> My question was whether we wanted to
> 1) change this before 2.6, or
> 2) change this after 2.6.

Well, my position is "Neither": A rule is a combination of symbolizer +
Filters. The only thing is that right now, we define the filter
properties directly in the creation of the Rule, and we can instead use
those properties to create Filters in the future.

It seems like option 1) above sets us back another month in the process,
because we need to abandon the RC at that point, and move back to step 1
in the release process: The entire point of an RC is "We think that if
there are no bugs, we can ship this". Perhaps this concept hasn't been
made clear enough in our discussions in the past: I had assumed that "no
non-regression changes after we hit RC" was obvious, but it's possible
that meaning has not actually been stated.

So, I'm a big -1 on changing to Rules and Filters before 2.6.

> If we change after 2.6, then we decide whether to wait for 3.0 or 
> whether to release with the rule subclasses as not part of the API 
> (subject to change).

I'm -0 on removing them from the API, since we then move them out of our
documentation and examples, and they become for most intents and
purposes unusable until 2.7. (Not having them in the examples being the
biggest blocker to people actually using them, I think.) 

"Wait for 3.0" is a possibility, I guess, but I'd like to understand why
we can't provide Rule.FeatureId as a convenience method: is there
something that's likely to confuse users about it? I guess I'm -0 on
removing Rule subclasses even in 3.0, simply because doing so requires
an even deeper understanding of the underlying aspects of the building
blocks than I think we need to force users to have... 

> I'm happy to write up a patch if we want to do this before 2.6 (which I 
> do of course*).

If you had said all this 4 weeks ago, I would have said "write a patch
for 2.6, but I'd prefer to leave Rule subclasses as convenience
methods going forward." 

Today, I'll say "I prefer to leave the Rule subclasses as convenience
methods going forward; because of that, we can skip the patch."

If I'm lonely in my position, then I'm willing to accept that we
should pull Rules from the API for this release, grudgingly. 

> * In the future, I'm also in favor of branching in advance of a release 
> so we don't release brand spanking new features with unstable interfaces.

I understand that this is likely led in large part by the recent style
work that TOPP has put in, but prior to that, the last commit to rules
was in early February...  and prior to *that*, the last functional
change to rules was the initial commit in mid December. At what point
would branching early have helped? Was it known in December that someone
was going to be working seriously on SLD Styles/Rules/Filters in April?
If so, would that have changed our release plan for the features? 

Maintaining stable APIs hasn't actually been that painful, I don't
think. There's extra code, yes. But I don't see how that extra code
hurts the end product. We don't spend much of our time supporting
deprecated APIs: even ones that don't have direct replacements are
pretty much abandoned by most users. (How many users still use
MouseToolbar instead of NavToolbar, despite the fact that the former has
functionality that the latter doesn't?) Have we really avoided many
changes because backwards compatibility? Or just made our development
slightly more complex because of it?  

Regards,
-- 
Christopher Schmidt
MetaCarta

From tschaub at openplans.org  Sat Apr  5 17:30:16 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080405185730.GB10278@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
Message-ID: <47F7EF68.1060705@openplans.org>

Here's the problem.

Currently, you can do:

var popRule = new OpenLayers.Rule.Comparison({
     minScaleDenominator: 50000,
     symbolizer: {fillColor: "red"},
     type: OpenLayers.Rule.Comparison.GREATER_THAN_OR_EQUAL_TO,
     property: "Population",
     value: 10000
});

var catRule = new OpenLayers.Rule.Comparison({
     minScaleDenominator: 100000,
     symbolizer: {fillColor: "blue"},
     type: OpenLayers.Rule.Comparison.EQUAL_TO,
     property: "Category",
     value: "city"
});

var logRule = new OpenLayers.Rule.Logical({
     type: OpenLayers.Rule.Locical.AND,
     rules: [popRule, catRule]
});

Now, when you create a style using the logRule, your expectations are 
likely not to be met.

Logical filters have child filters.  Filters do not have scale 
constraints or symbolizers.

I know you could say that the OpenLayers.Rule.Logical wrapper strips the 
scale constraints and symbolizers from the child rules, but I think this 
defies logic.  I've already been asked if symbolizers from child rules 
extend symbolizers of the parent rule.  This is not convenient, this is 
confusing.

If we want convenience methods (shortcuts to the code I proposed below), 
I suggest we put them elsewhere (on OpenLayers.Rule, OpenLayers.Style, 
or OpenLayers.StyleMap).

Frankly, I'd rather wait until we identify common patterns before 
deciding on what is going to be the most convenient API.  I know that 
Andreas was trying to simplify the style stuff and felt that adding too 
many classes would make it harder to get the code in.  I think we'd all 
rather see it done right.  Convenience can come later*.


Tim

* The most useful shortcuts I see are for adding groups of rules to a 
style map.  The addUniqueValueRules mehtod is an example of this.  Other 
common rule groupings are class breaks, equal interval, proportional 
symbol, etc.  Having methods to quickly produce groups of rules for 
these would vastly improve style creation.  If you have to add one rule 
at a time, you're doing something wrong.

OpenLayers.StyleMap.addRuleGroup({
     intents: ["default"], // this would be the default
     type: OpenLayers.Rule.CLASS_BREAKS,
     property: "population",
     values: [0, 10000, 20000, 30000],
     symbolizers: array // length of values.length -1

});

etc.


Christopher Schmidt wrote:
> On Sat, Apr 05, 2008 at 11:13:31AM -0600, Tim Schaub wrote:
>> The OpenLayers.Rule class comes from the sld:Rule element.  A rule in 
>> SLD has optional constraints on scale (sld:MinScaleDenominator and 
>> sld:MaxScaleDenominator), typically has symbolizers (for Point, Line, 
>> Polygon, etc), and optionally has an ogc:Filter element.
> 
> Right.
> 
>> In the Filter Encoding spec (where you find the description of 
>> ogc:Filter elements), there are a number of types of filters.  These 
>> include comparison filters, feature id filters, and logical filters.  In 
>> OpenLayers (currently) the subclasses of OpenLayers.Rule map directly to 
>> these types of ogc:Filter.
> 
> Right.  
> 
>> The problem is not only one of naming.  An sld:Rule *has* an ogc:Filter. 
>>    So a rule can have a feature id filter for example.  In OpenLayers, 
>> an OpenLayers.Rule.FeatureId *is* a rule.
> 
> Sure. It's a combination of the Filter and Rule into a single object for
> convenience, right? There's no replacement for 
> OpenLayers.Rule.FeatureID that wouldn't do the same thing the current
> one does, is there?
> 
>> The difference is that rules have things like scale constraints and 
>> symbolizers.  Filters do not have scale constraints and symbolizers.  A 
>> filter is the child of a rule.  A filter is not a rule.
> 
> Understood. So currently (as far as I understand it), we have Rule,
> which encompasses Rule + Filter, and in the future, we could make the
> seperation into Rule and Filter explicit: So Rule.FeatureID would
> (internally) create a Filter.FeatureID with the properties that are
> specified in the filter.
> 
>> So, OpenLayers.Rule.FeatureId would become OpenLayers.Filter.FeatureId. 
> 
> Sort of, I think? OpenLayers.Rule.FeatureId would become OpenLayers.Rule
> + OpenLayers.Filter.FeatureId?
> 
>>   This filter could be used for more than just styling - it could, for 
>> example, be serialized and used in a WFS query.  This has nothing to do 
>> with styling.
> 
> Agreed. Filters are valuable.
> 
>> So yes, your cambridge example would break in the future.  Instead you 
>> would do something like:
>>
>> var rule = new OpenLayers.Rule({
>>      symbolizer: {"Point": {"fillColor": "fuchsia"}},
>>      filter: new OpenLayers.Filter.Comparison({
>>          type: OpenLayers.Filter.Comparison.GREATER_THAN_OR_EQUAL_TO,
>>          property: "Population",
>>          value: 10000
>>      })
>> });
> 
> Alternatively, we add Filters, and make Rule subclasses a convenience
> method that takes everything but the Rule-specific properties and passes
> them onto the Filter? 
> 
>> var rule = new OpenLayers.Rule({
>>      symbolizer: {"Point": {"fillColor": "fuchsia"}},
>>      filter: new OpenLayers.Filter.Logical({
>>          type: OpenLayers.Filter.Logical.AND,
>>          filters: [
>>              new OpenLayers.Filter.Comparison({
>>                  type: OpenLayers.Filter.Comparison.LESS_THAN,
>>                  property: "Population",
>>                  value: 100000,
>>              }),
>>              new OpenLayers.Filter.Comparison({
>>                  type: OpenLayers.Filter.Comparison.GREATER_THAN,
>>                  property: "Population",
>>                  value: 0,
>>              })
>>          ]
>>      })
>> });
>>
>> The difference is that rules have symbolizers and a filter (optionally). 
>>   Filters do not have symbolizers.  A logical filter has child filters.
> 
> Right. To me, this doesn't indicate that we should get rid of
> Rule.FeatureID: instead, that we should make it a wrapper around
> Rule+Filter. 
> 
>> My question was whether we wanted to
>> 1) change this before 2.6, or
>> 2) change this after 2.6.
> 
> Well, my position is "Neither": A rule is a combination of symbolizer +
> Filters. The only thing is that right now, we define the filter
> properties directly in the creation of the Rule, and we can instead use
> those properties to create Filters in the future.
> 
> It seems like option 1) above sets us back another month in the process,
> because we need to abandon the RC at that point, and move back to step 1
> in the release process: The entire point of an RC is "We think that if
> there are no bugs, we can ship this". Perhaps this concept hasn't been
> made clear enough in our discussions in the past: I had assumed that "no
> non-regression changes after we hit RC" was obvious, but it's possible
> that meaning has not actually been stated.
> 
> So, I'm a big -1 on changing to Rules and Filters before 2.6.
> 
>> If we change after 2.6, then we decide whether to wait for 3.0 or 
>> whether to release with the rule subclasses as not part of the API 
>> (subject to change).
> 
> I'm -0 on removing them from the API, since we then move them out of our
> documentation and examples, and they become for most intents and
> purposes unusable until 2.7. (Not having them in the examples being the
> biggest blocker to people actually using them, I think.) 
> 
> "Wait for 3.0" is a possibility, I guess, but I'd like to understand why
> we can't provide Rule.FeatureId as a convenience method: is there
> something that's likely to confuse users about it? I guess I'm -0 on
> removing Rule subclasses even in 3.0, simply because doing so requires
> an even deeper understanding of the underlying aspects of the building
> blocks than I think we need to force users to have... 
> 
>> I'm happy to write up a patch if we want to do this before 2.6 (which I 
>> do of course*).
> 
> If you had said all this 4 weeks ago, I would have said "write a patch
> for 2.6, but I'd prefer to leave Rule subclasses as convenience
> methods going forward." 
> 
> Today, I'll say "I prefer to leave the Rule subclasses as convenience
> methods going forward; because of that, we can skip the patch."
> 
> If I'm lonely in my position, then I'm willing to accept that we
> should pull Rules from the API for this release, grudgingly. 
> 
>> * In the future, I'm also in favor of branching in advance of a release 
>> so we don't release brand spanking new features with unstable interfaces.
> 
> I understand that this is likely led in large part by the recent style
> work that TOPP has put in, but prior to that, the last commit to rules
> was in early February...  and prior to *that*, the last functional
> change to rules was the initial commit in mid December. At what point
> would branching early have helped? Was it known in December that someone
> was going to be working seriously on SLD Styles/Rules/Filters in April?
> If so, would that have changed our release plan for the features? 
> 
> Maintaining stable APIs hasn't actually been that painful, I don't
> think. There's extra code, yes. But I don't see how that extra code
> hurts the end product. We don't spend much of our time supporting
> deprecated APIs: even ones that don't have direct replacements are
> pretty much abandoned by most users. (How many users still use
> MouseToolbar instead of NavToolbar, despite the fact that the former has
> functionality that the latter doesn't?) Have we really avoided many
> changes because backwards compatibility? Or just made our development
> slightly more complex because of it?  
> 
> Regards,


From crschmidt at metacarta.com  Sat Apr  5 19:20:34 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47F7EF68.1060705@openplans.org>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
Message-ID: <20080405232034.GA14330@metacarta.com>

On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
> Here's the problem.
> 
> Currently, you can do:
> 
> var popRule = new OpenLayers.Rule.Comparison({
>      minScaleDenominator: 50000,
>      symbolizer: {fillColor: "red"},
>      type: OpenLayers.Rule.Comparison.GREATER_THAN_OR_EQUAL_TO,
>      property: "Population",
>      value: 10000
> });
> 
> var catRule = new OpenLayers.Rule.Comparison({
>      minScaleDenominator: 100000,
>      symbolizer: {fillColor: "blue"},
>      type: OpenLayers.Rule.Comparison.EQUAL_TO,
>      property: "Category",
>      value: "city"
> });
> 
> var logRule = new OpenLayers.Rule.Logical({
>      type: OpenLayers.Rule.Locical.AND,
>      rules: [popRule, catRule]
> });
> 
> Now, when you create a style using the logRule, your expectations are 
> likely not to be met.
> 
> Logical filters have child filters.  Filters do not have scale 
> constraints or symbolizers.

Okay. That's fair.

> I know you could say that the OpenLayers.Rule.Logical wrapper strips the 
> scale constraints and symbolizers from the child rules, but I think this 
> defies logic.  I've already been asked if symbolizers from child rules 
> extend symbolizers of the parent rule.  This is not convenient, this is 
> confusing.

Agreed.

> If we want convenience methods (shortcuts to the code I proposed below), 
> I suggest we put them elsewhere (on OpenLayers.Rule, OpenLayers.Style, 
> or OpenLayers.StyleMap).

Yep.

> Frankly, I'd rather wait until we identify common patterns before 
> deciding on what is going to be the most convenient API.  I know that 
> Andreas was trying to simplify the style stuff and felt that adding too 
> many classes would make it harder to get the code in.  I think we'd all 
> rather see it done right.  Convenience can come later*.

Okay. What does this mean for a 2.6 that is released without Filters? A
2.6.1 which adds them, and moves Rules to API Properties? Do we leave
the example, and document in the example that anything using it will
need to change in the future?

I don't like encouraging users towards things that are going to change
in the next release, but I prefer it over not documenting what I
consider an incredibly useful new aspect of working with OpenLayers in
2.6.

> * The most useful shortcuts I see are for adding groups of rules to a 
> style map.  

Ignoring, for the moment, that I still don't comprehend when to use a
Style vs. a StyleMap, I agree so strongly with this that I've actually
already started pondering coding equal interval rule creation stuff. 

> The addUniqueValueRules mehtod is an example of this.  Other 
> common rule groupings are class breaks, equal interval, proportional 
> symbol, etc.  Having methods to quickly produce groups of rules for 
> these would vastly improve style creation.  If you have to add one rule 
> at a time, you're doing something wrong.

As is typically the case for me :)

> OpenLayers.StyleMap.addRuleGroup({
>      intents: ["default"], // this would be the default
>      type: OpenLayers.Rule.CLASS_BREAKS,
>      property: "population",
>      values: [0, 10000, 20000, 30000],
>      symbolizers: array // length of values.length -1

hm, -1, or plus one? Ah, I guess Infinity can be a number, so -1 is
good.

> });

So, with this, I'm convinced that:
 * In 2.7, Rule.Logical won't exist (or won't do what it does now).
 * In 2.6, We can drop API* from it 

Does that sufficiently solve the problem for 2.6 such that we can move
forward?

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Sun Apr  6 16:27:48 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080405232034.GA14330@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com> <47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
Message-ID: <5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>

On Sun, Apr 6, 2008 at 1:20 AM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
>  So, with this, I'm convinced that:
>   * In 2.7, Rule.Logical won't exist (or won't do what it does now).
>   * In 2.6, We can drop API* from it

Chris, if I understand you (and this whole discussion) correctly, you
would keep API* for the Rule subclasses except for Rule.Logical.
Rule.Logical must be treated differently because later - when we
introduce the Filter classes - we won't be able to make it a
convenience method. Does my understanding sound correct?

Now my position on this: if we're to drop API* from Rule.Logical, I
would drop it from all the Rule subclasses. Because I think it is hard
to guess upfront what will be good convenience methods.

Is it such a big deal to drop API* from Rule.*? People with sufficient
knowledge on the style/rule framework would be able to use the Rule
subclasses with 2.6 and modify their application code to make it work
with 2.7. The other people can still benefit from the style/rule
framework through SLD.

Cheers,
--
Eric

From euzuro at gmail.com  Sun Apr  6 16:36:14 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Fwd: [OSGeo-Announce] FOSS4G 2008 Registration and
	Calls for Papers and Workshops
In-Reply-To: <47F66CA6.6030409@pobox.com>
References: <47F66CA6.6030409@pobox.com>
Message-ID: <6ae3fb590804061336m19f333b3qc5a3d96155bdc1e4@mail.gmail.com>

---------- Forwarded message ----------
From: Frank Warmerdam <warmerdam@pobox.com>
Date: Fri, Apr 4, 2008 at 2:00 PM
Subject: [OSGeo-Announce] FOSS4G 2008 Registration and Calls for
Papers and Workshops
To: announce@lists.osgeo.org


If you attend just one GIS conference in 2008, make it FOSS4G 2008! It
promises to be the highlight of your year.

The 2008 Free and Open Source Software for Geospatial (FOSS4G)
conference, incorporating GISSA 2008, is on the horizon.

WHERE: Cape Town, South Africa, at the Cape Town International
Convention Centre. Cape Town is one of the Top 5 worldwide tourist and
conference destinations.

WHEN: Monday 29 September to Friday 3 October. Extend your stay with a
holiday in beautiful South Africa and make the trip even more
worthwhile.

Theme: "Open Source Geospatial: An Option for Developing Nations"

FOSS4G is presented annually by the Open Source Geospatial Foundation
(OSGeo) and in 2007 gathered 700 developers and users of open source
geospatial software as well as managers and decision makers from around
the world to discuss new directions, exciting implementations, and
growing business opportunities in the field of open source geospatial
software.

Incorporation of GISSA 2008 this year opens FOSS4G to a wider field of
GIS practitioners and decision makers. GISSA is the GeoInformation
Society of South Africa and we want all players from South Africa to
join their peers from around the world at this international event. Come
and present your work, learn about Open Source GIS and participate in
the FOSS-Proprietary debate.

South Africa's recent adoption of a National Open Source Policy in
Government and the introduction of GIS into our school syllabus this
year make FOSS4G an especially important conference for South Africa and
other countries in a similar position.

Major features include Hands-on Workshops and Labs, Presentations and
Academic Papers, a live Demo Theatre, large exhibition hall, Outreach
activities, Technical visits and a great social programme including a
gala dinner at Moyo in Stellenbosch.

Visit the website http://www.foss4g2008.org to find out more. Register
or submit an Abstract or Workshop Proposal. This year there will be an
Academic Track in addition to non-peer-reviewed presentations, catering
for a wide range of topics.

Autodesk and Google have already come on board as sponsors. If your
organisation is interested in supporting the conference or exhibiting,
please download the Prospectus from the website.

Please circulate this widely.

I'm looking forward to seeing you in Cape Town!

Gavin Fleming
FOSS4G 2008 Conference Chair
www.foss4g2008.org

_______________________________________________
Announce mailing list
Announce@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/announce

From crschmidt at metacarta.com  Sun Apr  6 16:44:06 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
Message-ID: <20080406204406.GB32489@metacarta.com>

On Sun, Apr 06, 2008 at 10:27:48PM +0200, Eric Lemoine wrote:
> On Sun, Apr 6, 2008 at 1:20 AM, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
> >  So, with this, I'm convinced that:
> >   * In 2.7, Rule.Logical won't exist (or won't do what it does now).
> >   * In 2.6, We can drop API* from it
> 
> Chris, if I understand you (and this whole discussion) correctly, you
> would keep API* for the Rule subclasses except for Rule.Logical.
> Rule.Logical must be treated differently because later - when we
> introduce the Filter classes - we won't be able to make it a
> convenience method. Does my understanding sound correct?

No, I think that I'm convinced that convenience of any Rule subclasses 
is likely overruled by the confusion they would cause: I'm not in favor
of keeping the Rule subclasses as API Classes at all, I just used
Rule.Logical as an example.

> Now my position on this: if we're to drop API* from Rule.Logical, I
> would drop it from all the Rule subclasses. Because I think it is hard
> to guess upfront what will be good convenience methods.

Agreed.

> Is it such a big deal to drop API* from Rule.*? People with sufficient
> knowledge on the style/rule framework would be able to use the Rule
> subclasses with 2.6 and modify their application code to make it work
> with 2.7. 

I don't like this, but I've grudgingly admitted that I am willing to
accept it, yes. I don't feel comfortable with it, though.  

> The other people can still benefit from the style/rule
> framework through SLD.

I'll take your word for it, since I don't know how to use SLD :) 

Regards,
-- 
Christopher Schmidt
MetaCarta

From guillaume.sueur at neogeo-online.net  Sun Apr  6 17:36:32 2008
From: guillaume.sueur at neogeo-online.net (Guillaume Sueur)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] getLayersByName bug ?
In-Reply-To: <20080406204406.GB32489@metacarta.com>
References: <47F459B3.4030508@openplans.org>	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>	<20080405104941.GA3372@metacarta.com>	<47F7B33B.4000802@openplans.org>	<20080405185730.GB10278@metacarta.com>	<47F7EF68.1060705@openplans.org>	<20080405232034.GA14330@metacarta.com>	<5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
	<20080406204406.GB32489@metacarta.com>
Message-ID: <47F94260.9040305@neogeo-online.net>

Hi devs,

I'm facing a strange behaviour on the map's getLayersByName method. 
Passing it "reseaunds' makes it returns an array with layers 'reseau' 
and 'reseaunds' in it. I could maybe understand that 
map.getLayersByName('reseau') returns 'reseau' AND 'reseaunds'; but 
"reseaunds" returning both "reseau" and "reseaunds" as well doesn't seem 
right to me.

Shall I open a ticket for it ?


-- 
Guillaume SUEUR



From crschmidt at metacarta.com  Sun Apr  6 20:13:20 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] getLayersByName bug ?
In-Reply-To: <47F94260.9040305@neogeo-online.net>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
	<20080406204406.GB32489@metacarta.com>
	<47F94260.9040305@neogeo-online.net>
Message-ID: <20080407001319.GA2587@metacarta.com>

On Sun, Apr 06, 2008 at 11:36:32PM +0200, Guillaume Sueur wrote:
> Hi devs,
> 
> I'm facing a strange behaviour on the map's getLayersByName method. 
> Passing it "reseaunds' makes it returns an array with layers 'reseau' 
> and 'reseaunds' in it. I could maybe understand that 
> map.getLayersByName('reseau') returns 'reseau' AND 'reseaunds'; but 
> "reseaunds" returning both "reseau" and "reseaunds" as well doesn't seem 
> right to me.
> 
> Shall I open a ticket for it ?

If you can provide a minimal test case that presents the issue, I think
yes: I just tried with a minimal example and couldn't reproduce.

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Mon Apr  7 00:44:20 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080406204406.GB32489@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com> <47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
	<20080406204406.GB32489@metacarta.com>
Message-ID: <5ec103de0804062144q7fc05eeekd4917e3e09d4260d@mail.gmail.com>

>  > The other people can still benefit from the style/rule
>  > framework through SLD.
>
>  I'll take your word for it, since I don't know how to use SLD :)

I have honestly never used it myself. So I'll let Andreas and Tim
correct me if what I'm saying is not correct.

Thanks,

--
Eric

From crschmidt at metacarta.com  Mon Apr  7 02:12:41 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] #1492: Move rule subclasses to filter subclasses
In-Reply-To: <050.a99b277f5b6d7bb985c82a2f2a89eb2e@openlayers.org>
References: <041.a2192cc8cf416db6367f5c09eb0c7c55@openlayers.org>
	<050.a99b277f5b6d7bb985c82a2f2a89eb2e@openlayers.org>
Message-ID: <20080407061241.GA7525@metacarta.com>

On Mon, Apr 07, 2008 at 05:47:54AM -0000, OpenLayers wrote:
> #1492: Move rule subclasses to filter subclasses
> Comment (by crschmidt):

>  Overall:
>  I have just spent three hours attempting to review this patch, so I'll
>  admit that I'm likely a little wired, but I don't see anything in this
>  patch that would cause me to reject it. Calling a Rule an elseFilter (and
>  having it be unrelated to filters) seems weird to me, but I'm willing to
>  accept that that is just the 'way things are'.
> 
>  The "FeatureId" change mentioned above for Format/SLD seems odd, but I
>  can't see a reason why it would need to be there.
> 
>  In an effort to get 2.6RC2 out, I'm willing to accept this into trunk if
>  Andreas also gives it a pass. Andreas, this is the only significant
>  blocker for 2.6: Please review as soon as you are able.
> 
>  I have confirmed that all tests continue to pass in FF3, Safari3, and I
>  see no code that indicates that there would be any change in testing
>  status for IE browsers.

Andreas, if you're not going to get a chance to review this tomorrow,
please let me know so that I can do what I can to see if I can get
another pair of eyes on it: I don't feel comfortable with just mine. I
have gone through all the examples, including rewriting my choropleth
maps using the new Filters instead, and had no problems that are worth
holding off committing.

(I did not expect my evening to include reading not only SLD XML but
also parts of the SLD spec, plus the entire SLD format, and all the rule
and filter classes...)

Regards,
-- 
Christopher Schmidt
MetaCarta

From bartvde at osgis.nl  Mon Apr  7 05:07:33 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] LoadingPanel addin
Message-ID: <e50632a53b71364d5edd184d3e64a830@145.50.39.11>

Hi list,

I want to revive the LoadingPanel as an addin, I've got the code ready
locally, and I've added a Wiki page here:

http://trac.openlayers.org/wiki/Addins/LoadingPanel

What is the best thing to do now:

-put an updated patch at ticket 102 in Trac?
-commit the code in a sandbox?

If a sandbox is the way to go, can someone please create a bartvde sandbox?
TIA.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl






From guillaume.sueur at neogeo-online.net  Mon Apr  7 05:29:13 2008
From: guillaume.sueur at neogeo-online.net (Guillaume Sueur)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] getLayersByName bug ?
In-Reply-To: <20080407001319.GA2587@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<5ec103de0804061327t34691b28p7b62b1d9fb6c8ba0@mail.gmail.com>
	<20080406204406.GB32489@metacarta.com>
	<47F94260.9040305@neogeo-online.net>
	<20080407001319.GA2587@metacarta.com>
Message-ID: <47F9E969.7090804@neogeo-online.net>

I couldn't reproduce it in a simple way. A minimal app is behaving correcly.
My app loads the layers from a JSON stream. I've checked that layers are 
not duplicated or so, they are not. But the 
map.getLayersByName(somename) returns more than one layer when the names 
are close. Still don't understand why. I'll do further checks and let 
you know.

Christopher Schmidt a ?crit :
> On Sun, Apr 06, 2008 at 11:36:32PM +0200, Guillaume Sueur wrote:
>> Hi devs,
>>
>> I'm facing a strange behaviour on the map's getLayersByName method. 
>> Passing it "reseaunds' makes it returns an array with layers 'reseau' 
>> and 'reseaunds' in it. I could maybe understand that 
>> map.getLayersByName('reseau') returns 'reseau' AND 'reseaunds'; but 
>> "reseaunds" returning both "reseau" and "reseaunds" as well doesn't seem 
>> right to me.
>>
>> Shall I open a ticket for it ?
> 
> If you can provide a minimal test case that presents the issue, I think
> yes: I just tried with a minimal example and couldn't reproduce.
> 
> Regards,

-- 



From crschmidt at metacarta.com  Mon Apr  7 07:32:19 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] LoadingPanel addin
In-Reply-To: <e50632a53b71364d5edd184d3e64a830@145.50.39.11>
References: <e50632a53b71364d5edd184d3e64a830@145.50.39.11>
Message-ID: <20080407113219.GB12341@metacarta.com>

On Mon, Apr 07, 2008 at 11:07:33AM +0200, Bart van den Eijnden (OSGIS) wrote:
> Hi list,
> 
> I want to revive the LoadingPanel as an addin, I've got the code ready
> locally, and I've added a Wiki page here:
> 
> http://trac.openlayers.org/wiki/Addins/LoadingPanel
> 
> What is the best thing to do now:
> 
> -put an updated patch at ticket 102 in Trac?
> -commit the code in a sandbox?
> 
> If a sandbox is the way to go, can someone please create a bartvde sandbox?
> TIA.

A sandbox is best. I've added your name to the list of sandbox
committers:
http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#HowdoIcreatemyownsandboxintheSVNrepository
has information on how to create a sandbox.

Regards,
-- 
Christopher Schmidt
MetaCarta

From bartvde at osgis.nl  Mon Apr  7 07:38:05 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] "design pattern" question
Message-ID: <d503d232ae94dac8eec218e01c9548e3@145.50.39.11>

Hi list,

I've been wresting with the following use case for quite some time now, so I
am seeking advice here.

My use case is the following:

1) I have a layer which is of type OpenLayers.Layer.WMS
2) to get the WFS associated with this layer, I perform an SLD WMS
DescribeLayer request, this gives me back the location of the WFS and the
name of the typename
3) using the info from step 2), I perform a WFS DescribeFeatureType request
and parse the result in order to get a list of attributes for this layer.

I've got this code working using a sequence of OpenLayers.LoadURL calls, but
now I want to create a utility function which wraps the above functionality
into 1 function. Can this be done without reverting to a synchronous call? I
need the response from 2) in order to do 3).

I.e. this is what I have now:

var url =  layer.getFullRequestString({REQUEST: "DescribeLayer"});
OpenLayers.loadURL(url, '', this, this.parseDescribeLayer);

..

parseDescribeLayer: function(response) {
  // parse the result and call a DescribeFeatureType on the WFS
  ..
  OpenLayers.loadURL(url, '', this, this.parseAttributes);
}

..

parseAttributes: function(response) {
  var descfeaturetype = new  OpenLayers.Format.WFSDescribeFeatureType();
  var attributes = descfeaturetype.read(response.responseText);
  this.layer.attributes = attributes;
}

What I would want to do is:

OpenLayers.Util.getAttributes(layer)

which performs all of the above and only returns when it has finished all
operations.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl






From bartvde at osgis.nl  Mon Apr  7 07:54:24 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] LoadingPanel addin
Message-ID: <2d1214088c0f91d5806a408f3941bcec@145.50.39.11>

Thanks Chris,

the code is now in my sandbox bartvde/loadingpanel:

http://trac.openlayers.org/changeset/6805

I would appreciate it if someone could have a look at it to see if it is
suitable as an addin.

The url of the example is:
http://dev.openlayers.org/sandbox/bartvde/loadingpanel/examples/loadingpanel.html

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl


--------- Oorspronkelijk bericht --------
Van: Christopher Schmidt <crschmidt@metacarta.com>
Naar: Bart van den Eijnden OSGIS <bartvde@osgis.nl>
Cc: dev@openlayers.org
Onderwerp: Re: [OpenLayers-Dev] LoadingPanel addin
Datum: 07/04/08 09:32

> On Mon, Apr 07, 2008 at 11:07:33AM +0200, Bart van den Eijnden (OSGIS)
wrote:
> &gt; Hi list,
> &gt; 
> &gt; I want to revive the LoadingPanel as an addin, I've got the code
ready
> &gt; locally, and I've added a Wiki page here:
> &gt; 
> &gt; http://trac.openlayers.org/wiki/Addins/LoadingPanel
> &gt; 
> &gt; What is the best thing to do now:
> &gt; 
> &gt; -put an updated patch at ticket 102 in Trac?
> &gt; -commit the code in a sandbox?
> &gt; 
> &gt; If a sandbox is the way to go, can someone please create a bartvde
sandbox?
> &gt; TIA.
> 
> A sandbox is best. I've added your name to the list of sandbox
> committers:
>
http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#HowdoIcreatemyownsandboxintheSVNrepository
> has information on how to create a sandbox.
> 
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> 
> 




From tschaub at openplans.org  Mon Apr  7 09:40:59 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080405232034.GA14330@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
Message-ID: <47FA246B.5000102@openplans.org>

Christopher Schmidt wrote:
> On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
> I don't like encouraging users towards things that are going to change
> in the next release, but I prefer it over not documenting what I
> consider an incredibly useful new aspect of working with OpenLayers in
> 2.6.
> 

Cool.  Glad we see things the same way.  I'd rather let out a limited 
set of functionality that we think is more solid.

>> * The most useful shortcuts I see are for adding groups of rules to a 
>> style map.  
> 
> Ignoring, for the moment, that I still don't comprehend when to use a
> Style vs. a StyleMap, I agree so strongly with this that I've actually
> already started pondering coding equal interval rule creation stuff. 

Re: StyleMap

You give a vector layer a style map.  This is functionally a dictionary 
of named styles.  You can specify a different style for different 
situations.  A common pattern is to specify a different style when the 
user selects a feature.  The key in the style map is referred to as the 
rendering intent.  A typical application might render with one style 
when sketching a temporary feature, with another style when a feature is 
persisted, and with another style when a feature is selected.

The Style class gives you a place to collect groups of rules (color 
populated cities this way, color ghost towns that way).

The StyleMap class gives you a way to organize multiple Style instances 
for use in different situations (switch to this style when user clicks 
on a feature).

Re: equal interval rule creation stuff

As usual, I'd like to have a big picture talk before adding convenience 
methods piecemeal.  I think we can create a single method that will be 
useful for adding a variety of rule groupings.

This is relevant to creating tools to edit styles visually.  A 
shortcoming of SLD is that rules aren't organized in any way that aligns 
with common sense.  I'd like OpenLayers to adopt conventions in how we 
persist styles (specifically groups of rules) so that they make for more 
intuitive editing.

When we have methods that allow convenient creation of rule groups 
(equal interval rules for example), it makes sense to store something on 
those rules that maintains that logical grouping.  More on this later.

> 
>> The addUniqueValueRules mehtod is an example of this.  Other 
>> common rule groupings are class breaks, equal interval, proportional 
>> symbol, etc.  Having methods to quickly produce groups of rules for 
>> these would vastly improve style creation.  If you have to add one rule 
>> at a time, you're doing something wrong.
> 
> As is typically the case for me :)
> 
>> OpenLayers.StyleMap.addRuleGroup({
>>      intents: ["default"], // this would be the default
>>      type: OpenLayers.Rule.CLASS_BREAKS,
>>      property: "population",
>>      values: [0, 10000, 20000, 30000],
>>      symbolizers: array // length of values.length -1
> 
> hm, -1, or plus one? Ah, I guess Infinity can be a number, so -1 is
> good.

Confused.  The idea above was that you create a rule for each interval 
between items in the values array.  That means the number of symbolizers 
is one less than the length of the values array (one symbolizer for 
0>=x>10000, one for 10000>=x>20000, and one for 20000>=x>30000). 
Anyway, also for later.

As suggested above, the real power of rule based styling will be 
realized when we have decent visual style (and rule) editors.  Ideally, 
people wouldn't have to understand how to hand roll their own rules. 
Also, in the future, hopefully you'll use SLD without knowing it (it's 
just a format for persistence).  If you want to persist OpenLayers 
styles with other application configuration (in JavaScript or JSON), 
that's where OLON comes in handy.  So, in the future, you shouldn't be 
hand writing OpenLayers rules - just like you shouldn't be hand writing SLD.

Tim

> 
>> });
> 
> So, with this, I'm convinced that:
>  * In 2.7, Rule.Logical won't exist (or won't do what it does now).
>  * In 2.6, We can drop API* from it 
> 
> Does that sufficiently solve the problem for 2.6 such that we can move
> forward?
> 
> Regards,


From crschmidt at metacarta.com  Mon Apr  7 10:16:13 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47FA246B.5000102@openplans.org>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<47FA246B.5000102@openplans.org>
Message-ID: <20080407141613.GA14602@metacarta.com>

On Mon, Apr 07, 2008 at 07:40:59AM -0600, Tim Schaub wrote:
> Christopher Schmidt wrote:
> > On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
> > I don't like encouraging users towards things that are going to change
> > in the next release, but I prefer it over not documenting what I
> > consider an incredibly useful new aspect of working with OpenLayers in
> > 2.6.
> 
> Cool.  Glad we see things the same way.  I'd rather let out a limited 
> set of functionality that we think is more solid.

It sounds to me like we don't see things the same way, in that case? If
so, we should remove Rule subclasses from the OpenLayers code, and not 
include filters, since they're not solid (being only 12 hours old)?

Perhaps you mean 'let out' in a different way than I do. 

> >> * The most useful shortcuts I see are for adding groups of rules to a 
> >> style map.  
> > 
> > Ignoring, for the moment, that I still don't comprehend when to use a
> > Style vs. a StyleMap, I agree so strongly with this that I've actually
> > already started pondering coding equal interval rule creation stuff. 
> 
> Re: StyleMap
> 
> You give a vector layer a style map.  This is functionally a dictionary 
> of named styles.  You can specify a different style for different 
> situations.  A common pattern is to specify a different style when the 
> user selects a feature.  The key in the style map is referred to as the 
> rendering intent.  A typical application might render with one style 
> when sketching a temporary feature, with another style when a feature is 
> persisted, and with another style when a feature is selected.
> 
> The Style class gives you a place to collect groups of rules (color 
> populated cities this way, color ghost towns that way).
> 
> The StyleMap class gives you a way to organize multiple Style instances 
> for use in different situations (switch to this style when user clicks 
> on a feature).

Yeah, I'd gotten that far, except I can't figure out how to make a
StyleMap *do* anything: I thought that the way to do it was something
like StyleMap({default: style, select: select_style}), but then adding
that, when I select a feature, it doesn't change, so I guess I'm just
doing it wrong. 

> Re: equal interval rule creation stuff
> 
> As usual, I'd like to have a big picture talk before adding convenience 
> methods piecemeal.  I think we can create a single method that will be 
> useful for adding a variety of rule groupings.

I've learned the lesson in this release that it's best if I stay out of
working on things that I'm only using for my personal use in OpenLayers.
Popups, Styles and Controls have only been hurt by my intervention in any
part of the process, so I don't intend to add any convenience methods:
I'm just working on writing code that makes it possible to do what I
want more easily. 

> >> OpenLayers.StyleMap.addRuleGroup({
> >>      intents: ["default"], // this would be the default
> >>      type: OpenLayers.Rule.CLASS_BREAKS,
> >>      property: "population",
> >>      values: [0, 10000, 20000, 30000],
> >>      symbolizers: array // length of values.length -1
> > 
> > hm, -1, or plus one? Ah, I guess Infinity can be a number, so -1 is
> > good.
> 
> Confused.  The idea above was that you create a rule for each interval 
> between items in the values array.  That means the number of symbolizers 
> is one less than the length of the values array (one symbolizer for 
> 0>=x>10000, one for 10000>=x>20000, and one for 20000>=x>30000). 
> Anyway, also for later.

Right, I was trying to figure out how this works when you want a rule
for "Anything above this point", which I had assumed was a default; once
I realized that could be explicitly stated, there was no longer a need
for it to be implicit, so my confusion went away. 

> So, in the future, you shouldn't be hand writing OpenLayers rules -
> just like you shouldn't be hand writing SLD.

To me, this statement reads the same as "you shouldn't be hand writing
OpenLayers Layer definitions -- just like you shouldn't be hand writing
WMC." I agree with the latter, but not with the former in all cases.
It seems that there are sets of common rules that are easily constructed
in code -- the example above seems simple enough to me. (Serializing out
to SLD from that is an obvious next step if you care about things other
than OpenLayers.) I don't think that it suffers anymore than doing web
site design without a WYSIWYG editor does: You can still pick out colors
using your color dropper and writing them into code (or in the HTML
case, CSS) without a graphical editor needing to be involved.

Regards,
-- 
Christopher Schmidt
MetaCarta

From tomas.novotny at tmapy.cz  Mon Apr  7 11:34:41 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] OpenLayers performance
Message-ID: <47FA3F11.1020107@tmapy.cz>

Hi,

I'm after few months of using OpenLayers (OL). I've built some 
application on OL and appreciated it's architecture for good extensibility.
But when things come to performance of such common task as panning 
(moving a map with mouse), I am really dissatisfied.
The way the panning is implemented is everything but not 
browser-friendly. There is coord2pixel and pixel2coord processing on 
several places in those moveTo() and setCenter() methods on every mouse 
move and it is only part of the problem. A tried to prune OL for tests 
to just moving map div with one empty layer and things were still the 
same. You can feel lags as you are moving map from side to side, up and 
down. When you try to compare it with ie. GoogleMaps you can really feel 
the difference.
I haven't seen any OL example with better feeling so I think it's a 
matter of source architecture, not bug.
What I'm trying to say? I found out that OL are good for building robust 
applications where wide functionality is the goal, not the performance. 
If I'm not right and making something wrong please tell me.


Regards,

Tomas Novotny

From tschaub at openplans.org  Mon Apr  7 11:34:34 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <20080407141613.GA14602@metacarta.com>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<47FA246B.5000102@openplans.org>
	<20080407141613.GA14602@metacarta.com>
Message-ID: <47FA3F0A.7020209@openplans.org>

Hey-

Christopher Schmidt wrote:
> On Mon, Apr 07, 2008 at 07:40:59AM -0600, Tim Schaub wrote:
>> Christopher Schmidt wrote:
>>> On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
>>> I don't like encouraging users towards things that are going to change
>>> in the next release, but I prefer it over not documenting what I
>>> consider an incredibly useful new aspect of working with OpenLayers in
>>> 2.6.
>> Cool.  Glad we see things the same way.  I'd rather let out a limited 
>> set of functionality that we think is more solid.
> 
> It sounds to me like we don't see things the same way, in that case? If
> so, we should remove Rule subclasses from the OpenLayers code, and not 
> include filters, since they're not solid (being only 12 hours old)?
> 
> Perhaps you mean 'let out' in a different way than I do. 

Well, I also said I thought it would make sense to branch prior to a 
release - so we could add new features to the trunk and let them settle 
(I still hold that sandboxes are good for development, but not for real 
user testing).

Anyway, I still think we agree.  Rule subclasses are getting new names. 
  Would be very nice if this wasn't being done this late in the process. 
  I apologize for not raising a fuss earlier and appreciate your help 
this late.

> 
>>>> * The most useful shortcuts I see are for adding groups of rules to a 
>>>> style map.  
>>> Ignoring, for the moment, that I still don't comprehend when to use a
>>> Style vs. a StyleMap, I agree so strongly with this that I've actually
>>> already started pondering coding equal interval rule creation stuff. 
>> Re: StyleMap
>>
>> You give a vector layer a style map.  This is functionally a dictionary 
>> of named styles.  You can specify a different style for different 
>> situations.  A common pattern is to specify a different style when the 
>> user selects a feature.  The key in the style map is referred to as the 
>> rendering intent.  A typical application might render with one style 
>> when sketching a temporary feature, with another style when a feature is 
>> persisted, and with another style when a feature is selected.
>>
>> The Style class gives you a place to collect groups of rules (color 
>> populated cities this way, color ghost towns that way).
>>
>> The StyleMap class gives you a way to organize multiple Style instances 
>> for use in different situations (switch to this style when user clicks 
>> on a feature).
> 
> Yeah, I'd gotten that far, except I can't figure out how to make a
> StyleMap *do* anything: I thought that the way to do it was something
> like StyleMap({default: style, select: select_style}), but then adding
> that, when I select a feature, it doesn't change, so I guess I'm just
> doing it wrong. 
> 

Hmm.  Could be a spelling error somewhere.  The georss-flickr.html 
example creates a StyleMap with a "select" rendering intent.

The default renderIntent for the SelectFeature control is "select" 
(http://trac.openlayers.org/browser/trunk/openlayers/lib/OpenLayers/Control/SelectFeature.js#L101). 
  This renderIntent is sent in the drawFeature call.

The drawFeature method now works with a renderIntent 
(http://trac.openlayers.org/browser/trunk/openlayers/lib/OpenLayers/Layer/Vector.js#L418).

All this is more complex and error prone than it needs to be - in the 
name of backwards compatibility.  If your feature has a style property, 
if your layer has a style property, or if your control has a selectStyle 
property the renderIntent will not be respected.

In the future (3.0), this can be simplified significantly.

If this is not working as expected, we should fix it prior to release.

>> Re: equal interval rule creation stuff
>>
>>>> OpenLayers.StyleMap.addRuleGroup({
>>>>      intents: ["default"], // this would be the default
>>>>      type: OpenLayers.Rule.CLASS_BREAKS,
>>>>      property: "population",
>>>>      values: [0, 10000, 20000, 30000],
>>>>      symbolizers: array // length of values.length -1
>>> hm, -1, or plus one? Ah, I guess Infinity can be a number, so -1 is
>>> good.
>> Confused.  The idea above was that you create a rule for each interval 
>> between items in the values array.  That means the number of symbolizers 
>> is one less than the length of the values array (one symbolizer for 
>> 0>=x>10000, one for 10000>=x>20000, and one for 20000>=x>30000). 
>> Anyway, also for later.
> 
> Right, I was trying to figure out how this works when you want a rule
> for "Anything above this point", which I had assumed was a default; once
> I realized that could be explicitly stated, there was no longer a need
> for it to be implicit, so my confusion went away. 
> 

Ah, got it.  Yeah, something like the following works:

     values: [Number.NEGATIVE_INFINITY, 0, Number.POSITIVE_INFINITY]


>> So, in the future, you shouldn't be hand writing OpenLayers rules -
>> just like you shouldn't be hand writing SLD.
> 
> To me, this statement reads the same as "you shouldn't be hand writing
> OpenLayers Layer definitions -- just like you shouldn't be hand writing
> WMC." I agree with the latter, but not with the former in all cases.
> It seems that there are sets of common rules that are easily constructed
> in code -- the example above seems simple enough to me. (Serializing out
> to SLD from that is an obvious next step if you care about things other
> than OpenLayers.) I don't think that it suffers anymore than doing web
> site design without a WYSIWYG editor does: You can still pick out colors
> using your color dropper and writing them into code (or in the HTML
> case, CSS) without a graphical editor needing to be involved.

Again, I think we agree.  No absolutes here.  We (you and I) will 
continue to code by hand.  I was using "you" more generally above.  I 
think tools for configuring a map w/o writing code would be of general use.

Tim

> 
> Regards,


From tschaub at openplans.org  Mon Apr  7 11:56:21 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] "design pattern" question
In-Reply-To: <d503d232ae94dac8eec218e01c9548e3@145.50.39.11>
References: <d503d232ae94dac8eec218e01c9548e3@145.50.39.11>
Message-ID: <47FA4425.9070306@openplans.org>

Hey-

Bart van den Eijnden (OSGIS) wrote:
> Hi list,
> 
> I've been wresting with the following use case for quite some time now, so I
> am seeking advice here.
> 
> My use case is the following:
> 
> 1) I have a layer which is of type OpenLayers.Layer.WMS
> 2) to get the WFS associated with this layer, I perform an SLD WMS
> DescribeLayer request, this gives me back the location of the WFS and the
> name of the typename
> 3) using the info from step 2), I perform a WFS DescribeFeatureType request
> and parse the result in order to get a list of attributes for this layer.
> 
> I've got this code working using a sequence of OpenLayers.LoadURL calls, but
> now I want to create a utility function which wraps the above functionality
> into 1 function. Can this be done without reverting to a synchronous call? I
> need the response from 2) in order to do 3).
> 
> I.e. this is what I have now:
> 
> var url =  layer.getFullRequestString({REQUEST: "DescribeLayer"});
> OpenLayers.loadURL(url, '', this, this.parseDescribeLayer);
> 
> ..
> 
> parseDescribeLayer: function(response) {
>   // parse the result and call a DescribeFeatureType on the WFS
>   ..
>   OpenLayers.loadURL(url, '', this, this.parseAttributes);
> }
> 
> ..
> 
> parseAttributes: function(response) {
>   var descfeaturetype = new  OpenLayers.Format.WFSDescribeFeatureType();
>   var attributes = descfeaturetype.read(response.responseText);
>   this.layer.attributes = attributes;
> }
> 
> What I would want to do is:
> 
> OpenLayers.Util.getAttributes(layer)
> 
> which performs all of the above and only returns when it has finished all
> operations.

Event driven design requires different thinking.  There are tricks that 
approximate what you want, but you're better off having your 
getAttributes function trigger a callback when the asynchronous sequence 
completes.

That said, there is nothing stopping you from defining 
parseDescribeLayer and parseAttributes within getAttributes.

function getAttributes(layer, callback) {
     function parseAttributes: function(response) {
         // parse response.responseText
         callback.call(attributes);
     }
     function parseDescribeLayer(response) {
         // parse
         OpenLayers.loadURL(url, null, null, parseAttributes);
     }
     OpenLayers.loadURL(url, null, null, parseDescribeLayer);
}

I suspect this is obvious, and you find it nicer to define those as 
public methods on some other object (more efficient that way).

Anyway, I'd say if your utility method involves asynchronous calls, it 
should take a callback as an argument.

The fact is, we've got a single thread.  If you just can't put up with 
this, you could consider writing in something like Narrative JavaScript 
[1] and compiling your code to JavaScript.

Tim

[1] http://neilmix.com/narrativejs/doc/index.html


> 
> 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,47fa07b7180331961014482!
> 


From crschmidt at metacarta.com  Mon Apr  7 13:11:26 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] Rule subclasses and 2.6
In-Reply-To: <47FA3F0A.7020209@openplans.org>
References: <47F459B3.4030508@openplans.org>
	<5b021dd0804030121i70364d20u45b9af76a296749a@mail.gmail.com>
	<20080405104941.GA3372@metacarta.com>
	<47F7B33B.4000802@openplans.org>
	<20080405185730.GB10278@metacarta.com>
	<47F7EF68.1060705@openplans.org>
	<20080405232034.GA14330@metacarta.com>
	<47FA246B.5000102@openplans.org>
	<20080407141613.GA14602@metacarta.com>
	<47FA3F0A.7020209@openplans.org>
Message-ID: <20080407171125.GA1474@metacarta.com>

On Mon, Apr 07, 2008 at 09:34:34AM -0600, Tim Schaub wrote:
> > Yeah, I'd gotten that far, except I can't figure out how to make a
> > StyleMap *do* anything: I thought that the way to do it was something
> > like StyleMap({default: style, select: select_style}), but then adding
> > that, when I select a feature, it doesn't change, so I guess I'm just
> > doing it wrong. 
> > 
> 
> Hmm.  Could be a spelling error somewhere.  The georss-flickr.html 
> example creates a StyleMap with a "select" rendering intent.

Okay. I'll assume for the time being that I screwed something up
and try to reproduce it. 


> Ah, got it.  Yeah, something like the following works:

Right. I forgot that Infinity is a number.

>      values: [Number.NEGATIVE_INFINITY, 0, Number.POSITIVE_INFINITY]

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Mon Apr  7 13:16:31 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FA3F11.1020107@tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz>
Message-ID: <20080407171630.GB1474@metacarta.com>

On Mon, Apr 07, 2008 at 05:34:41PM +0200, Tomas Novotny wrote:
> I'm after few months of using OpenLayers (OL). I've built some 
> application on OL and appreciated it's architecture for good extensibility.
> But when things come to performance of such common task as panning 
> (moving a map with mouse), I am really dissatisfied.

Patches welcome.

> The way the panning is implemented is everything but not 
> browser-friendly. There is coord2pixel and pixel2coord processing on 
> several places in those moveTo() and setCenter() methods on every mouse 
> move and it is only part of the problem. A tried to prune OL for tests 
> to just moving map div with one empty layer and things were still the 
> same. You can feel lags as you are moving map from side to side, up and 
> down. When you try to compare it with ie. GoogleMaps you can really feel 
> the difference.

I'll state for the record that I don't feel any difference -- if
anything, I typically feel like GMaps is slower than OpenLayers.
However, there are a number of patches in trac which have been stated by
their authors to be 'faster' or 'improve performance', which are
currently marked for further investigation in OpenLayers 2.7.

> I haven't seen any OL example with better feeling so I think it's a 
> matter of source architecture, not bug.

The architecture of OpenLayers is not designed to be slow. If you are
finding that it is slow, there is no reason that a refactoring of that
aspect of the code would not be appreciated so long as it did not
regress in behavior in some important way.

> What I'm trying to say? I found out that OL are good for building robust 
> applications where wide functionality is the goal, not the performance. 
> If I'm not right and making something wrong please tell me.

I don't think that OpenLayers tries to be slow in any way. If you feel
there are obvious deficiencies in the way that OpenLayers does things,
and see a better way, please feel free to offer them up as comments to
the community. 

Regards,
-- 
Christopher Schmidt
MetaCarta

From guillaume.sueur at neogeo-online.net  Mon Apr  7 14:40:11 2008
From: guillaume.sueur at neogeo-online.net (Guillaume Sueur)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <20080407171630.GB1474@metacarta.com>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
Message-ID: <47FA6A8B.1030502@neogeo-online.net>

I wouldn't say OpenLayers performances are slower than GM. You have to 
compare things the same way. If your OpenLayers app loads several layers 
(say 10), then yes, the pan is becoming slower, a bit like if you were 
carrying a heavy weight, which is indeed what you are doing, and what GM 
can't do. Furthermore, if your map is very large, say 1680 x 1050, yes 
it can be a bit slower too. But most of the time it can be considered at 
least as fast as GM (see 
http://www.openlayers.org/dev/examples/fullScreen.html for a good example)
But as OpenLayers can do much more than a GoogleMap app, there is 
another point to consider which is tuning. When you have many layers, 
you have to take care on how each of them is loaded and used in the app, 
and set meaningfully options such a SingleTile or the way you access the 
data (wms, wms + tilecache, wfs, geoJSON). each of these has its 
benefits and drawbacks. But it's not openlayers architecture anymore, 
it's your app architecture, your app tuning and settings, and finally, 
your job !
And it's an exciting part of it !

Guillaume

Christopher Schmidt a ?crit :
> On Mon, Apr 07, 2008 at 05:34:41PM +0200, Tomas Novotny wrote:
>> I'm after few months of using OpenLayers (OL). I've built some 
>> application on OL and appreciated it's architecture for good extensibility.
>> But when things come to performance of such common task as panning 
>> (moving a map with mouse), I am really dissatisfied.
> 
> Patches welcome.
> 
>> The way the panning is implemented is everything but not 
>> browser-friendly. There is coord2pixel and pixel2coord processing on 
>> several places in those moveTo() and setCenter() methods on every mouse 
>> move and it is only part of the problem. A tried to prune OL for tests 
>> to just moving map div with one empty layer and things were still the 
>> same. You can feel lags as you are moving map from side to side, up and 
>> down. When you try to compare it with ie. GoogleMaps you can really feel 
>> the difference.
> 
> I'll state for the record that I don't feel any difference -- if
> anything, I typically feel like GMaps is slower than OpenLayers.
> However, there are a number of patches in trac which have been stated by
> their authors to be 'faster' or 'improve performance', which are
> currently marked for further investigation in OpenLayers 2.7.
> 
>> I haven't seen any OL example with better feeling so I think it's a 
>> matter of source architecture, not bug.
> 
> The architecture of OpenLayers is not designed to be slow. If you are
> finding that it is slow, there is no reason that a refactoring of that
> aspect of the code would not be appreciated so long as it did not
> regress in behavior in some important way.
> 
>> What I'm trying to say? I found out that OL are good for building robust 
>> applications where wide functionality is the goal, not the performance. 
>> If I'm not right and making something wrong please tell me.
> 
> I don't think that OpenLayers tries to be slow in any way. If you feel
> there are obvious deficiencies in the way that OpenLayers does things,
> and see a better way, please feel free to offer them up as comments to
> the community. 
> 
> Regards,




From crschmidt at metacarta.com  Mon Apr  7 14:41:32 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
Message-ID: <20080407184131.GA18774@metacarta.com>

Our last RC2 blocker is (hopefully) going to be committed later today:
It's my plan to roll an RC2 out tonight, since we've received no other
reports of regressions that I feel we need to fix before RC2. (A couple
of things can get dropped into an RC3 if we do one, but I'm happy with
calling what we currently have final if we find no other regressions.)

If you have any reason to block an RC2, please bring it up before this
evening.

My plan is to pull up all changes to trunk into the branch in one big
commit, and roll that as an RC2. (This includes documentation/example 
changes which have no ticket.)

I'm +1 on an RC2.

Regards,
-- 
Christopher Schmidt
MetaCarta

From tomas.novotny at tmapy.cz  Mon Apr  7 15:35:50 2008
From: tomas.novotny at tmapy.cz (tomas.novotny@tmapy.cz)
Date: Wed Sep  1 17:23:46 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FA6A8B.1030502@neogeo-online.net>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
Message-ID: <1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>

Boys,

the problem I am talking about is not based on number of layers and map
size. I have no problem with loading time of map tiles as well. It's just
the way map dragging is implemented.
The link to OL example Guillaume posted is also the case I wrote about.
Let's try it (http://www.openlayers.org/dev/examples/fullScreen.html).
Please switch off overlay for fair-play and zoom in the map. Then make a
few large circles with map using mouse. Try the same with GM. And don't
try to tell me you have the same feeling (at least in FF 2 and IE7).
And I've made lot of such tests with same result.
I have absolutely nothing personal against OL, I really like them from
many points of view. I also understand and agree with Christopher when he
talks about freedom of influencing OL code. But if I try to solve that
panning problem I would do so significant change that I would be really
worried about the rest of the code. I'm open for discussion about such
possible change with OL core developers but I don't have capacity to do it
on my own.

Tomas Novotny

> I wouldn't say OpenLayers performances are slower than GM. You have to
> compare things the same way. If your OpenLayers app loads several layers
> (say 10), then yes, the pan is becoming slower, a bit like if you were
> carrying a heavy weight, which is indeed what you are doing, and what GM
> can't do. Furthermore, if your map is very large, say 1680 x 1050, yes
> it can be a bit slower too. But most of the time it can be considered at
> least as fast as GM (see
> http://www.openlayers.org/dev/examples/fullScreen.html for a good example)
> But as OpenLayers can do much more than a GoogleMap app, there is
> another point to consider which is tuning. When you have many layers,
> you have to take care on how each of them is loaded and used in the app,
> and set meaningfully options such a SingleTile or the way you access the
> data (wms, wms + tilecache, wfs, geoJSON). each of these has its
> benefits and drawbacks. But it's not openlayers architecture anymore,
> it's your app architecture, your app tuning and settings, and finally,
> your job !
> And it's an exciting part of it !
>
> Guillaume
>
> Christopher Schmidt a ?crit :
>> On Mon, Apr 07, 2008 at 05:34:41PM +0200, Tomas Novotny wrote:
>>> I'm after few months of using OpenLayers (OL). I've built some
>>> application on OL and appreciated it's architecture for good
>>> extensibility.
>>> But when things come to performance of such common task as panning
>>> (moving a map with mouse), I am really dissatisfied.
>>
>> Patches welcome.
>>
>>> The way the panning is implemented is everything but not
>>> browser-friendly. There is coord2pixel and pixel2coord processing on
>>> several places in those moveTo() and setCenter() methods on every mouse
>>> move and it is only part of the problem. A tried to prune OL for tests
>>> to just moving map div with one empty layer and things were still the
>>> same. You can feel lags as you are moving map from side to side, up and
>>> down. When you try to compare it with ie. GoogleMaps you can really
>>> feel
>>> the difference.
>>
>> I'll state for the record that I don't feel any difference -- if
>> anything, I typically feel like GMaps is slower than OpenLayers.
>> However, there are a number of patches in trac which have been stated by
>> their authors to be 'faster' or 'improve performance', which are
>> currently marked for further investigation in OpenLayers 2.7.
>>
>>> I haven't seen any OL example with better feeling so I think it's a
>>> matter of source architecture, not bug.
>>
>> The architecture of OpenLayers is not designed to be slow. If you are
>> finding that it is slow, there is no reason that a refactoring of that
>> aspect of the code would not be appreciated so long as it did not
>> regress in behavior in some important way.
>>
>>> What I'm trying to say? I found out that OL are good for building
>>> robust
>>> applications where wide functionality is the goal, not the performance.
>>> If I'm not right and making something wrong please tell me.
>>
>> I don't think that OpenLayers tries to be slow in any way. If you feel
>> there are obvious deficiencies in the way that OpenLayers does things,
>> and see a better way, please feel free to offer them up as comments to
>> the community.
>>
>> Regards,
>
>
>
>
>



From crschmidt at metacarta.com  Mon Apr  7 16:14:16 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
Message-ID: <20080407201416.GA19605@metacarta.com>

On Mon, Apr 07, 2008 at 09:35:50PM +0200, tomas.novotny@tmapy.cz wrote:
> The link to OL example Guillaume posted is also the case I wrote about.
> Let's try it (http://www.openlayers.org/dev/examples/fullScreen.html).
> Please switch off overlay for fair-play and zoom in the map. Then make a
> few large circles with map using mouse. Try the same with GM. And don't
> try to tell me you have the same feeling (at least in FF 2 and IE7).

Well, I hate to be the bearer of bad news, but on my browser on my
computer, they feel about the same. 

This is backed up, to some extent, by empirical evidence: using a
stopwatch, I dragged each map around in circles, clockwise, for 5
seconds, with the Firebug profiler turned on for each. 

OpenLayers: 944.26ms, 57342 calls
Google Maps: 820.147ms, 44818 calls

So, it appears that OpenLayers could be said, based on the empirical
evidence on my browser, to be about 15% slower than Google Maps: given
the limited scope of the specific test here, I would say that's not
really a big enough difference to complain about.

Interestingly enough, this is apparently a significant change from 2.5:

OpenLayers 2.5: 1469.714ms, 138497 calls

So, we've gained a 35% performance improvement without even trying. Not
bad.

> And I've made lot of such tests with same result.
> I have absolutely nothing personal against OL, I really like them from
> many points of view. I also understand and agree with Christopher when he
> talks about freedom of influencing OL code. But if I try to solve that
> panning problem I would do so significant change that I would be really
> worried about the rest of the code. 

Well, without understanding what is behaving slowly for you, it's hard
for anyone to fix it, but as I said, there is no intention to be slow,
and I don't see any serious evidence to indicate that OL is any worse in
this case than any other mapping API on my platform of choice.

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Mon Apr  7 16:50:42 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407184131.GA18774@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
Message-ID: <5ec103de0804071350j782c9fb3o9e303f0c7e48f1ee@mail.gmail.com>

On Mon, Apr 7, 2008 at 8:41 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> Our last RC2 blocker is (hopefully) going to be committed later today:
>  It's my plan to roll an RC2 out tonight, since we've received no other
>  reports of regressions that I feel we need to fix before RC2. (A couple
>  of things can get dropped into an RC3 if we do one, but I'm happy with
>  calling what we currently have final if we find no other regressions.)
>
>  If you have any reason to block an RC2, please bring it up before this
>  evening.
>
>  My plan is to pull up all changes to trunk into the branch in one big
>  commit, and roll that as an RC2. (This includes documentation/example
>  changes which have no ticket.)
>
>  I'm +1 on an RC2.

Am +1 too.

--
Eric

From andreas.hocevar at gmail.com  Mon Apr  7 16:54:51 2008
From: andreas.hocevar at gmail.com (Andreas Hocevar)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <5ec103de0804071350j782c9fb3o9e303f0c7e48f1ee@mail.gmail.com>
References: <20080407184131.GA18774@metacarta.com>
	<5ec103de0804071350j782c9fb3o9e303f0c7e48f1ee@mail.gmail.com>
Message-ID: <47FA8A1B.7060606@gmail.com>

-1. I would like to see the second patch for #1498 in the rc. But I'm 
open to reasons why that one should not go into rc2.

Regards,
Andreas.
Eric Lemoine wrote:
> On Mon, Apr 7, 2008 at 8:41 PM, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
>   
>> Our last RC2 blocker is (hopefully) going to be committed later today:
>>  It's my plan to roll an RC2 out tonight, since we've received no other
>>  reports of regressions that I feel we need to fix before RC2. (A couple
>>  of things can get dropped into an RC3 if we do one, but I'm happy with
>>  calling what we currently have final if we find no other regressions.)
>>
>>  If you have any reason to block an RC2, please bring it up before this
>>  evening.
>>
>>  My plan is to pull up all changes to trunk into the branch in one big
>>  commit, and roll that as an RC2. (This includes documentation/example
>>  changes which have no ticket.)
>>
>>  I'm +1 on an RC2.
>>     
>
> Am +1 too.
>
> --
> Eric
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>   


From andreas.hocevar at gmail.com  Mon Apr  7 17:11:51 2008
From: andreas.hocevar at gmail.com (Andreas Hocevar)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <5ec103de0804071350j782c9fb3o9e303f0c7e48f1ee@mail.gmail.com>
References: <20080407184131.GA18774@metacarta.com>
	<5ec103de0804071350j782c9fb3o9e303f0c7e48f1ee@mail.gmail.com>
Message-ID: <47FA8E17.4090804@gmail.com>

+1 if we can do #1498 later without anyone complaining about breaking 
the API.

Regards,
Andreas.

Eric Lemoine wrote:
> On Mon, Apr 7, 2008 at 8:41 PM, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
>   
>> Our last RC2 blocker is (hopefully) going to be committed later today:
>>  It's my plan to roll an RC2 out tonight, since we've received no other
>>  reports of regressions that I feel we need to fix before RC2. (A couple
>>  of things can get dropped into an RC3 if we do one, but I'm happy with
>>  calling what we currently have final if we find no other regressions.)
>>
>>  If you have any reason to block an RC2, please bring it up before this
>>  evening.
>>
>>  My plan is to pull up all changes to trunk into the branch in one big
>>  commit, and roll that as an RC2. (This includes documentation/example
>>  changes which have no ticket.)
>>
>>  I'm +1 on an RC2.
>>     
>
> Am +1 too.
>
> --
> Eric
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>   


From euzuro at gmail.com  Mon Apr  7 17:15:30 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407184131.GA18774@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
Message-ID: <6ae3fb590804071415h25fca9e8r9fb686e9bed1341e@mail.gmail.com>

+575

On Mon, Apr 7, 2008 at 2:41 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> Our last RC2 blocker is (hopefully) going to be committed later today:
> It's my plan to roll an RC2 out tonight, since we've received no other
> reports of regressions that I feel we need to fix before RC2. (A couple
> of things can get dropped into an RC3 if we do one, but I'm happy with
> calling what we currently have final if we find no other regressions.)
>
> If you have any reason to block an RC2, please bring it up before this
> evening.
>
> My plan is to pull up all changes to trunk into the branch in one big
> commit, and roll that as an RC2. (This includes documentation/example
> changes which have no ticket.)
>
> I'm +1 on an RC2.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From schuyler at nocat.net  Mon Apr  7 17:56:35 2008
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407184131.GA18774@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
Message-ID: <20080407215635.GU5298@vishnu.tridity.org>

* On  7-Apr-2008 at 11:41AM PDT, Christopher Schmidt said:
> I'm +1 on an RC2.

+1, of course. thanks. :)

SDE

From schuyler at nocat.net  Mon Apr  7 18:01:12 2008
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
Message-ID: <20080407220112.GV5298@vishnu.tridity.org>

* On  7-Apr-2008 at 12:35PM PDT, tomas.novotny@tmapy.cz said:
> But if I try to solve that panning problem I would do so significant
> change that I would be really worried about the rest of the code.
> I'm open for discussion about such possible change with OL core
> developers but I don't have capacity to do it on my own.

Tomas, we're open to considering any proposal that significantly improves the
usability or performance of OpenLayers. Of course, our main concerns
would be functional elegance, code readability, and the ability to
maintain backwards compatibility with the existing version 2 API.

I for one would welcome a specific proposal for review, if you feel
the issue is that pressing. Thanks for your interest, of course.

SDE

From john.frank at metacarta.com  Mon Apr  7 18:07:38 2008
From: john.frank at metacarta.com (John R. Frank)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407215635.GU5298@vishnu.tridity.org>
References: <20080407184131.GA18774@metacarta.com>
	<20080407215635.GU5298@vishnu.tridity.org>
Message-ID: <Pine.LNX.4.56.0804071806370.21951@jackson.metacarta.com>

> I'm +1 on an RC2.

+1 :-)  Thanks!


John

From crschmidt at metacarta.com  Mon Apr  7 18:59:50 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407184131.GA18774@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
Message-ID: <20080407225949.GA22246@metacarta.com>

On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
> If you have any reason to block an RC2, please bring it up before this
> evening.

At this point, it does not look like there will be an RC2 this evening.
I apparently underestimated the amount of effort remaining on #1492, and
now we have #1498 which apparently needs to be in 2.6. 

If both of these are resolved reasonably soon, I'll still roll the RC
tonight, but at this point, it seems unlikely, so we'll have to try
again tomorrow night.

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Mon Apr  7 22:15:02 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407225949.GA22246@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
	<20080407225949.GA22246@metacarta.com>
Message-ID: <20080408021501.GA24751@metacarta.com>

On Mon, Apr 07, 2008 at 06:59:50PM -0400, Christopher Schmidt wrote:
> On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
> > If you have any reason to block an RC2, please bring it up before this
> > evening.
> 
> At this point, it does not look like there will be an RC2 this evening.
> I apparently underestimated the amount of effort remaining on #1492, and
> now we have #1498 which apparently needs to be in 2.6. 
> 
> If both of these are resolved reasonably soon, I'll still roll the RC
> tonight, but at this point, it seems unlikely, so we'll have to try
> again tomorrow night.

1492 is taken care of. I've done all the pullups for tickets currently
marked 2.6, so the branch is in shape for a possible release.

However, Tim has added a comment to 1498 saying that he feels it should
be in 2.6, so I'm taking that as a blocker for the next RC, given his
lack of vote on the list.

/me curses plumbing incidents dragging him back out of bed just as he
falls asleep.

I've got other obligtations tomorrow night, so I might not be able to roll
the RC until Wednesday if we get the votes tomorrow. I'll try and sneak
some time in for it, just mentioning timeline. 

Regards,
-- 
Christopher Schmidt
MetaCarta

From cameron.shorter at gmail.com  Mon Apr  7 23:20:10 2008
From: cameron.shorter at gmail.com (Cameron Shorter)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080407225949.GA22246@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>
	<20080407225949.GA22246@metacarta.com>
Message-ID: <47FAE46A.80405@gmail.com>

+1, once the identified issues are addressed.

Christopher Schmidt wrote:
> On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
>   
>> If you have any reason to block an RC2, please bring it up before this
>> evening.
>>     
>
> At this point, it does not look like there will be an RC2 this evening.
> I apparently underestimated the amount of effort remaining on #1492, and
> now we have #1498 which apparently needs to be in 2.6. 
>
> If both of these are resolved reasonably soon, I'll still roll the RC
> tonight, but at this point, it seems unlikely, so we'll have to try
> again tomorrow night.
>
> Regards,
>   


-- 
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 Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html


From tschaub at openplans.org  Tue Apr  8 00:30:33 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <20080408021501.GA24751@metacarta.com>
References: <20080407184131.GA18774@metacarta.com>	<20080407225949.GA22246@metacarta.com>
	<20080408021501.GA24751@metacarta.com>
Message-ID: <47FAF4E9.60802@openplans.org>

Christopher Schmidt wrote:
> On Mon, Apr 07, 2008 at 06:59:50PM -0400, Christopher Schmidt wrote:
>> On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
>>> If you have any reason to block an RC2, please bring it up before this
>>> evening.
>> At this point, it does not look like there will be an RC2 this evening.
>> I apparently underestimated the amount of effort remaining on #1492, and
>> now we have #1498 which apparently needs to be in 2.6. 
>>
>> If both of these are resolved reasonably soon, I'll still roll the RC
>> tonight, but at this point, it seems unlikely, so we'll have to try
>> again tomorrow night.
> 
> 1492 is taken care of. I've done all the pullups for tickets currently
> marked 2.6, so the branch is in shape for a possible release.
> 
> However, Tim has added a comment to 1498 saying that he feels it should
> be in 2.6, so I'm taking that as a blocker for the next RC, given his
> lack of vote on the list.
> 
> /me curses plumbing incidents dragging him back out of bed just as he
> falls asleep.
> 
> I've got other obligtations tomorrow night, so I might not be able to roll
> the RC until Wednesday if we get the votes tomorrow. I'll try and sneak
> some time in for it, just mentioning timeline. 
> 
> Regards,

+0

Apologies for not getting in a vote until after hours.

I like the idea of the fix for 1498 getting in 2.6, but if it doesn't 
fit the schedule so be it.

In any case, Chris, I appreciate you picking up the job of release 
manager again.

Tim



From tschaub at openplans.org  Tue Apr  8 00:56:17 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <47FAF4E9.60802@openplans.org>
References: <20080407184131.GA18774@metacarta.com>	<20080407225949.GA22246@metacarta.com>	<20080408021501.GA24751@metacarta.com>
	<47FAF4E9.60802@openplans.org>
Message-ID: <47FAFAF1.8050209@openplans.org>

You'll notice two more commits related to #1492.

GeoRSS format tests fail in Safari (#1501).  As I mentioned in the 
ticket, it looks like a test problem instead of a lib problem, so I 
wouldn't call it a blocker.  But who wants to ship with failing tests?

Tim


Tim Schaub wrote:
> Christopher Schmidt wrote:
>> On Mon, Apr 07, 2008 at 06:59:50PM -0400, Christopher Schmidt wrote:
>>> On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
>>>> If you have any reason to block an RC2, please bring it up before this
>>>> evening.
>>> At this point, it does not look like there will be an RC2 this evening.
>>> I apparently underestimated the amount of effort remaining on #1492, and
>>> now we have #1498 which apparently needs to be in 2.6. 
>>>
>>> If both of these are resolved reasonably soon, I'll still roll the RC
>>> tonight, but at this point, it seems unlikely, so we'll have to try
>>> again tomorrow night.
>> 1492 is taken care of. I've done all the pullups for tickets currently
>> marked 2.6, so the branch is in shape for a possible release.
>>
>> However, Tim has added a comment to 1498 saying that he feels it should
>> be in 2.6, so I'm taking that as a blocker for the next RC, given his
>> lack of vote on the list.
>>
>> /me curses plumbing incidents dragging him back out of bed just as he
>> falls asleep.
>>
>> I've got other obligtations tomorrow night, so I might not be able to roll
>> the RC until Wednesday if we get the votes tomorrow. I'll try and sneak
>> some time in for it, just mentioning timeline. 
>>
>> Regards,
> 
> +0
> 
> Apologies for not getting in a vote until after hours.
> 
> I like the idea of the fix for 1498 getting in 2.6, but if it doesn't 
> fit the schedule so be it.
> 
> In any case, Chris, I appreciate you picking up the job of release 
> manager again.
> 
> Tim
> 
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47faf508305087082231907!
> 


From tschaub at openplans.org  Tue Apr  8 01:17:12 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <47FAFAF1.8050209@openplans.org>
References: <20080407184131.GA18774@metacarta.com>	<20080407225949.GA22246@metacarta.com>	<20080408021501.GA24751@metacarta.com>	<47FAF4E9.60802@openplans.org>
	<47FAFAF1.8050209@openplans.org>
Message-ID: <47FAFFD8.3060100@openplans.org>

Tim Schaub wrote:
> You'll notice two more commits related to #1492.
> 
> GeoRSS format tests fail in Safari (#1501).  As I mentioned in the 
> ticket, it looks like a test problem instead of a lib problem, so I 
> wouldn't call it a blocker.  But who wants to ship with failing tests?

Fixed now (#1501), and marked as pullup.

> 
> Tim
> 
> 
> Tim Schaub wrote:
>> Christopher Schmidt wrote:
>>> On Mon, Apr 07, 2008 at 06:59:50PM -0400, Christopher Schmidt wrote:
>>>> On Mon, Apr 07, 2008 at 02:41:32PM -0400, Christopher Schmidt wrote:
>>>>> If you have any reason to block an RC2, please bring it up before this
>>>>> evening.
>>>> At this point, it does not look like there will be an RC2 this evening.
>>>> I apparently underestimated the amount of effort remaining on #1492, and
>>>> now we have #1498 which apparently needs to be in 2.6. 
>>>>
>>>> If both of these are resolved reasonably soon, I'll still roll the RC
>>>> tonight, but at this point, it seems unlikely, so we'll have to try
>>>> again tomorrow night.
>>> 1492 is taken care of. I've done all the pullups for tickets currently
>>> marked 2.6, so the branch is in shape for a possible release.
>>>
>>> However, Tim has added a comment to 1498 saying that he feels it should
>>> be in 2.6, so I'm taking that as a blocker for the next RC, given his
>>> lack of vote on the list.
>>>
>>> /me curses plumbing incidents dragging him back out of bed just as he
>>> falls asleep.
>>>
>>> I've got other obligtations tomorrow night, so I might not be able to roll
>>> the RC until Wednesday if we get the votes tomorrow. I'll try and sneak
>>> some time in for it, just mentioning timeline. 
>>>
>>> Regards,
>> +0
>>
>> Apologies for not getting in a vote until after hours.
>>
>> I like the idea of the fix for 1498 getting in 2.6, but if it doesn't 
>> fit the schedule so be it.
>>
>> In any case, Chris, I appreciate you picking up the job of release 
>> manager again.
>>
>> Tim
>>
>>
>> _______________________________________________
>> 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,47fafb07312311804284693!
> 


From tomas.novotny at tmapy.cz  Tue Apr  8 03:17:26 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re:  OpenLayers performance
In-Reply-To: <20080407201416.GA19605@metacarta.com>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
	<20080407201416.GA19605@metacarta.com>
Message-ID: <47FB1C06.8020202@tmapy.cz>

An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080408/958628e9/attachment.html
From tomas.novotny at tmapy.cz  Tue Apr  8 03:52:05 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <20080407220112.GV5298@vishnu.tridity.org>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
	<20080407220112.GV5298@vishnu.tridity.org>
Message-ID: <47FB2425.4070507@tmapy.cz>

An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080408/c152b65c/attachment.html
From bartvde at osgis.nl  Tue Apr  8 03:59:36 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
Message-ID: <dad216966c001885c67120710d3ccfae@145.50.39.11>

Hi Tomas,

you can also have a look at:

http://trac.openlayers.org/ticket/1125

It's got a patch which you might want to try.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl


--------- Oorspronkelijk bericht --------
Van: Tomas Novotny <tomas.novotny@tmapy.cz>
Naar: Schuyler Erle <schuyler@nocat.net>
Cc: dev@openlayers.org
Onderwerp: Re: [OpenLayers-Dev] OpenLayers performance
Datum: 08/04/08 05:52

> 
> 
> 
>   
> 
> 
> Thank you for response. 
> It looks like "not-smooth" map moving is problem only for me. When we
> have same point of view we can try to do something with that.
> 
> Tomas
> 
> Schuyler Erle wrote:
> 
>   * On  7-Apr-2008 at 12:35PM PDT, tomas.novotny@tmapy.cz said:
>   
>   
>     But if I try to solve that panning problem I would do so significant
> change that I would be really worried about the rest of the code.
> I'm open for discussion about such possible change with OL core
> developers but I don't have capacity to do it on my own.
>     
>   
>   
> Tomas, we're open to considering any proposal that significantly improves
the
> usability or performance of OpenLayers. Of course, our main concerns
> would be functional elegance, code readability, and the ability to
> maintain backwards compatibility with the existing version 2 API.
> 
> I for one would welcome a specific proposal for review, if you feel
> the issue is that pressing. Thanks for your interest, of course.
> 
> SDE
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 




From kleptog at gmail.com  Tue Apr  8 04:09:11 2008
From: kleptog at gmail.com (Martijn van Oosterhout)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FB2425.4070507@tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>
	<47FA6A8B.1030502@neogeo-online.net>
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>
	<20080407220112.GV5298@vishnu.tridity.org> <47FB2425.4070507@tmapy.cz>
Message-ID: <2fc2c5f10804080109v636feda2scf27bf715362da37@mail.gmail.com>

2008/4/8 Tomas Novotny <tomas.novotny@tmapy.cz>:
>  Thank you for response.
>  It looks like "not-smooth" map moving is problem only for me. When we have
> same point of view we can try to do something with that.

For future reference: not all browsers were created equal. When
talking about performance it would be really helpful if you gave on
indication of the speed of the system you are referring to and the
browser you're testing on. Without this information it's very easy to
talk past eachother.

At some point you mentioned IE6 on a 5yo machine. If you had mentioned
that upfront it might have been helpful. I'm not sure how many
developers here have such a platform.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/

From tomas.novotny at tmapy.cz  Tue Apr  8 04:26:17 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <dad216966c001885c67120710d3ccfae@145.50.39.11>
References: <dad216966c001885c67120710d3ccfae@145.50.39.11>
Message-ID: <47FB2C29.5030309@tmapy.cz>

An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080408/86d64a09/attachment.html
From mail at kevinkempfer.de  Tue Apr  8 05:27:14 2008
From: mail at kevinkempfer.de (Kevin Kempfer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Deactivate Draw-Control after feature added
Message-ID: <47FB3A72.6000903@kevinkempfer.de>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3249 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080408/5dd7752a/smime.bin
From tomas.novotny at tmapy.cz  Tue Apr  8 05:42:19 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re:  OpenLayers performance
In-Reply-To: <2fc2c5f10804080109v636feda2scf27bf715362da37@mail.gmail.com>
References: <47FA3F11.1020107@tmapy.cz> <20080407171630.GB1474@metacarta.com>	
	<47FA6A8B.1030502@neogeo-online.net>	
	<1827.88.146.176.18.1207596950.squirrel@matous.tmapy.cz>	
	<20080407220112.GV5298@vishnu.tridity.org>
	<47FB2425.4070507@tmapy.cz>
	<2fc2c5f10804080109v636feda2scf27bf715362da37@mail.gmail.com>
Message-ID: <47FB3DFB.9050109@tmapy.cz>

An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080408/82e6092d/attachment.html
From pspencer at dmsolutions.ca  Tue Apr  8 06:33:20 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Deactivate Draw-Control after feature added
In-Reply-To: <47FB3A72.6000903@kevinkempfer.de>
References: <47FB3A72.6000903@kevinkempfer.de>
Message-ID: <497C9A57-126A-43E4-87F9-8DE965B5D6B8@dmsolutions.ca>

Kevin, I am using the same technique and it works just fine.

The featureAdded callback gets called during  
DrawFeature.drawFeature().  This function does not appear to be in  
your stack trace (nor is toggle()) so that isn't your problem at this  
point.

It looks like you have some other code hanging around that is causing  
you problems - something that is handling the dblclick it looks like.

Cheers

Paul

On 8-Apr-08, at 5:27 AM, Kevin Kempfer wrote:
> Crossposting this to the dev list, looks like nobody knows on the  
> user list.
>
> Kevin
>
> ----------------
> Hi,
>
> I'm trying to let the user draw a line feature and deactivate the draw
> feature after the feature was added to the map. Here's my code:
>
> var drawControls = {
>                 point: new OpenLayers.Control.DrawFeature(vectors,
>                             OpenLayers.Handler.Point),
>                 line: new OpenLayers.Control.DrawFeature(vectors,
> 		OpenLayers.Handler.Path,{featureAdded: toggle }
> 			),
>                 rectangle: new OpenLayers.Control.DrawFeature(vectors,
>                             OpenLayers.Handler.Box),
>                 select: new OpenLayers.Control.SelectFeature(vectors),
>             };
>
>             for(var key in drawControls) {
>                 map.addControl(drawControls[key]);
>             }
>
>
> function toggle(feature){
> 	var linecontrol = drawControls['line'];
> 	linecontrol.deactivate();
> }
>
> I get an error as soon as the control gets deactivated:
> this.point has no properties
> -> this.point.destroy();
>
> Here's the trace from FireBug:
> destroyFeature()Point.js (line 128)
> destroyFeature()Path.js (line 81)
> finalize()Point.js (line 139)
> dblclick(dblclick clientX=0, clientY=0)Path.js (line 240)
> triggerEvent("dblclick", dblclick clientX=0, clientY=0)Events.js  
> (line 612)
> handleBrowserEvent(dblclick clientX=0, clientY=0)Events.js (line 640)
> bindAsEventListener(dblclick clientX=0, clientY=0)
>
> Looks like the control gets deactivated too early in the feature- 
> adding
> process. Is there any advice on how to deactivate a draw control after
> drawing a feature?
>
> Thanks,
>
> Kevin
>
> -- 
> http://www.kevinkempfer.de
> Tel.: +49 7071 860303
> ICQ:  2186573
> Skype: kevin0815
> _______________________________________________
> Users mailing list
> Users@openlayers.org
> http://openlayers.org/mailman/listinfo/users
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From crschmidt at metacarta.com  Tue Apr  8 07:31:57 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] RC2 Later tonight?
In-Reply-To: <47FAFAF1.8050209@openplans.org>
References: <20080407184131.GA18774@metacarta.com>
	<20080407225949.GA22246@metacarta.com>
	<20080408021501.GA24751@metacarta.com>
	<47FAF4E9.60802@openplans.org> <47FAFAF1.8050209@openplans.org>
Message-ID: <20080408113156.GA307@metacarta.com>

On Mon, Apr 07, 2008 at 10:56:17PM -0600, Tim Schaub wrote:
> You'll notice two more commits related to #1492.
> 
> GeoRSS format tests fail in Safari (#1501).  As I mentioned in the 
> ticket, it looks like a test problem instead of a lib problem, so I 
> wouldn't call it a blocker.  But who wants to ship with failing tests?

Yeah, this is one of the tests we've been routinely failing since Safari
3.0.3 (I hate changes in code in browsers, makes my life more difficult)
and I hadn't gotten a chance to look at it. Thanks for that.

Note that we still fail one test in FF3b5: FF has fixed a broken
behavior to match every other browser, and we don't have an easy way to
check FF3 vs. FF2, but since that browser is still in beta, I'm leaving
it as is.

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Tue Apr  8 09:36:58 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Mapstraction vs OpenLayers?
In-Reply-To: <Pine.LNX.4.56.0804080852090.1845@jackson.metacarta.com>
References: <Pine.LNX.4.56.0804080852090.1845@jackson.metacarta.com>
Message-ID: <20080408133658.GB1475@metacarta.com>

On Tue, Apr 08, 2008 at 08:53:16AM -0400, John R. Frank wrote:
> If someone asked you "what's the difference between OpenLayers and
> Mapstraction?"  What would you say?

Mapstraction is a very thin wrapper on top of a variety of mapping APIs.
Essentially, it implements a 'lowest common denominator' API: allowing
you to use the common features between the APIs *within* those APIs.

So, for example, all mapping APIs have some kind of 'popup' class:
Mapstraction allows you to use Google Maps, or Yahoo Maps, or what have
you, and use *their* popup class for displaying the data. This has great
benefits in some cases: for example, it allows you to quickly say "I
want to see the difference between how this code looks against Google
Maps Popups, Yahoo Maps popups, and Virtual Earth popups." MetaCarta has
used Mapstraction in various projects for this reason: it allowed for
the disconnection between Javascript code and mapping API, but *not* the
disconnect between mapping API and the features of that mapping API.

OpenLayers, on the other hand, doesn't use the 'higher level'
functionality of any of the data sources: instead, it uses data sources
*only* as a source of data, and implements the entire API *above* the
lower level mapping API. So, with OpenLayers, you can't use Google Maps
popups: you use only OpenLayers popups.

This has a benefit in the other direction: if you want your application
to be distinctly 'you', you can customize OpenLayers popups to your
heart's content, and use them over *all* the APIs. However, this comes
at a cost: For example, the popups in OpenLayers before OpenLayers 2.6
are obviously not quite the same level of 'polish' as Google popups, and
you *can't* fall back to the underlying data source.

An additional restriction of using Mapstraction is you are essentially
tied to using one API at a time, and can only use the methods that exist 
within that API (as far as I'm aware). This means that, for example, you
can't have both Virtual Earth and Google Maps in the *same* map: you can
switch between them, but you can't switch the stuff out from under them.
(If you think about it, this makes some sense: you can't display Google
Maps popups on top of a Virtual Earth map, for example.)

This means that, if you're a county sheriff in Texas, where half your
county is covered by Virtual Earth data, and half your county is covered
by Google  Maps data, you can't quickly 'flip the switch' back and forth
as you cross the border, to see the two different data types. 

Another limitation is that it doesn't have the same 'layer' API that
OpenLayers does, because you're ependant on the underlying API: you
can't easily 'mix and match' datatypes, as far as I'm aware.

This means that there are use cases where using Mapstraction over
OpenLayers makes sense. If you just want 'markers on a map', and you're
planning to support switching between a few commercial APIs as a
preference, mapstraction works great. If you want something that's
simple to use and get started with, Mapstraction still has a leg up on
OpenLayers when using commercial data, because (similar to the
commercial data) it uses Lon/Lat to do its manipulation (whereas
OpenLayers prefers to work in sphericalMercator when working with
projected data). It's also mught lighter weight than even the lightest
OpenLayers build, which can be useful. 

However, when you've got a desire to switch between multiple commercial
basemaps while using an application, or you want to have a consistent
'look and feel' to your application regardless of what underlying
mapping API you're using, I think that OpenLayers is probably the way to
go. This increases if you plan to use custom data loading, or you want
to use some of the more advanced features of OpenLayers, like vector
editing, over any base map: Mapstraction does not, as far as I know,
have support for these types of usage.    

Hopefully this helps answer your question, 
-- 
Christopher Schmidt
MetaCarta

From jachym.cepicky at gmail.com  Tue Apr  8 11:18:13 2008
From: jachym.cepicky at gmail.com (Jachym Cepicky)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] possible bug in mousemove event handler
Message-ID: <1207667893.8643.41.camel@kocour>

Hi,
I have following problem: I try to implement moving markers with mouse
drag&drop. It is working well, but if the map is panned, then the
mousemove event contains wrong xy element OpenLayers.Pixel. The marker
is moved to other place, than the mousepointer is. Imho it is some kind
of bug.

Small example running at [1]

How to reproduce the bug:
1) drag & drop the marker - it should work
2) now pan with the mouse 
3) try to move the marker again - it will "jump" so site, with the
distance of previous map movement, mouseup is never caught and the
marker is never released.

Is there any other demo, which is working, demonstrating moving markers
with the mouse?

thanks

jachym

[1] http://www.bnhelp.cz/wwwlibs/openlayers/examples/move-marker.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/20080408/9dcc04d9/attachment.bin
From pspencer at dmsolutions.ca  Tue Apr  8 12:38:01 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] openlayers in the (rss) news
Message-ID: <FC1A525D-BE8C-4D73-B64B-844270E1BAC1@dmsolutions.ca>

http://www.alistapart.com/articles/takecontrolofyourmaps

A very extensive look at alternatives to Google for creating maps, in  
which OpenLayers figures prominently.

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From tschaub at openplans.org  Tue Apr  8 13:15:51 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FA3F11.1020107@tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz>
Message-ID: <47FBA847.1060108@openplans.org>

Hey-

I've got a half baked patch that gives the map a drag method.  This 
bypasses all center calculations until the drag ends (and only adjusts 
the position of the layer containers).  Works well except with 
commercial layers.  Given some more time, I'll fix it up.

Tim

Tomas Novotny wrote:
> Hi,
> 
> I'm after few months of using OpenLayers (OL). I've built some 
> application on OL and appreciated it's architecture for good extensibility.
> But when things come to performance of such common task as panning 
> (moving a map with mouse), I am really dissatisfied.
> The way the panning is implemented is everything but not 
> browser-friendly. There is coord2pixel and pixel2coord processing on 
> several places in those moveTo() and setCenter() methods on every mouse 
> move and it is only part of the problem. A tried to prune OL for tests 
> to just moving map div with one empty layer and things were still the 
> same. You can feel lags as you are moving map from side to side, up and 
> down. When you try to compare it with ie. GoogleMaps you can really feel 
> the difference.
> I haven't seen any OL example with better feeling so I think it's a 
> matter of source architecture, not bug.
> What I'm trying to say? I found out that OL are good for building robust 
> applications where wide functionality is the goal, not the performance. 
> If I'm not right and making something wrong please tell me.
> 
> 
> Regards,
> 
> Tomas Novotny
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47fa3f4c271318362916074!
> 


From Volker.Mische at lisasoft.com  Tue Apr  8 19:27:44 2008
From: Volker.Mische at lisasoft.com (Volker Mische)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FA3F11.1020107@tmapy.cz>
References: <47FA3F11.1020107@tmapy.cz>
Message-ID: <47FBFF70.8070001@lisasoft.com>

Hi,

I made a patch once that doesn't trigger on every mouse move but on 
every n-th move. You can find it there: 
http://openlayers.org/pipermail/dev/2007-July/001124.html

Cu,
   Volker

Tomas Novotny wrote:
> Hi,
> 
> I'm after few months of using OpenLayers (OL). I've built some 
> application on OL and appreciated it's architecture for good extensibility.
> But when things come to performance of such common task as panning 
> (moving a map with mouse), I am really dissatisfied.
> The way the panning is implemented is everything but not 
> browser-friendly. There is coord2pixel and pixel2coord processing on 
> several places in those moveTo() and setCenter() methods on every mouse 
> move and it is only part of the problem. A tried to prune OL for tests 
> to just moving map div with one empty layer and things were still the 
> same. You can feel lags as you are moving map from side to side, up and 
> down. When you try to compare it with ie. GoogleMaps you can really feel 
> the difference.
> I haven't seen any OL example with better feeling so I think it's a 
> matter of source architecture, not bug.
> What I'm trying to say? I found out that OL are good for building robust 
> applications where wide functionality is the goal, not the performance. 
> If I'm not right and making something wrong please tell me.
> 
> 
> Regards,
> 
> Tomas Novotny
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 


From thinesh.gen at gmail.com  Wed Apr  9 00:56:10 2008
From: thinesh.gen at gmail.com (Thinesh thusinthaka)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] dev@openlayers.org
Message-ID: <927196540804082156k15948b4br54caeeb8dcd16afe@mail.gmail.com>

I need to get subscribed to Openlayer today.
i have followed some project with its API.
Need some dev help..

thinesh

From crschmidt at metacarta.com  Wed Apr  9 07:08:34 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] dev@openlayers.org
In-Reply-To: <927196540804082156k15948b4br54caeeb8dcd16afe@mail.gmail.com>
References: <927196540804082156k15948b4br54caeeb8dcd16afe@mail.gmail.com>
Message-ID: <20080409110833.GD21948@metacarta.com>

On Wed, Apr 09, 2008 at 10:26:10AM +0530, Thinesh thusinthaka wrote:
> I need to get subscribed to Openlayer today.
> i have followed some project with its API.
> Need some dev help..

You *are* subscribed... that's why you got to post ;)

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Wed Apr  9 10:21:06 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Style question
Message-ID: <5ec103de0804090721n26eb1f80hdad81ad9d033037b@mail.gmail.com>

Hi. A style-related question: i've styled my vector layer using
StyleMap, Style and Rule. Now i'm in a featureselected event callback
and i'd like to get the current style (fillColor) of the selected
feature. I'm afraid i can't as the current feature style isn't stored
in the feature but only in the renderer deepness. Can someone confirm?
Thx.

Eric

From andreas.hocevar at gmail.com  Wed Apr  9 10:31:11 2008
From: andreas.hocevar at gmail.com (Andreas Hocevar)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Style question
In-Reply-To: <5ec103de0804090721n26eb1f80hdad81ad9d033037b@mail.gmail.com>
References: <5ec103de0804090721n26eb1f80hdad81ad9d033037b@mail.gmail.com>
Message-ID: <47FCD32F.2080805@gmail.com>

Eric,

Eric Lemoine wrote:
> Hi. A style-related question: i've styled my vector layer using
> StyleMap, Style and Rule. Now i'm in a featureselected event callback
> and i'd like to get the current style (fillColor) of the selected
> feature. I'm afraid i can't as the current feature style isn't stored
> in the feature but only in the renderer deepness. Can someone confirm?
>   

No problem to get the current symbolizer:

var symbolizer = feature.layer.styleMap.createSymbolizer(feature, 
feature.renderIntent);


Regards,
Andreas.

From piebe.de.vries at geodan.nl  Wed Apr  9 11:01:02 2008
From: piebe.de.vries at geodan.nl (Piebe de Vries)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector labels
Message-ID: <47FCDA2E.4090707@geodan.nl>

Hi,

I really need to display labels on a vector layer. I found 
http://dev.openlayers.org/sandbox/camptocamp/text/examples/vector-features-with-text.html 
which looks promising but it seems there has not been much activity 
since december.

Can somebody tell me the current status? Are there any plans to 
integrate this in trunk anywhere soon, and, if not, for what reason? How 
hard will it be to do it myself? etc....

cheers,
 Piebe




From bluecarto at gmail.com  Wed Apr  9 11:21:22 2008
From: bluecarto at gmail.com (Pierre GIRAUD)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector labels
In-Reply-To: <47FCDA2E.4090707@geodan.nl>
References: <47FCDA2E.4090707@geodan.nl>
Message-ID: <d50f50e60804090821p5bfc0861pf1aa89f9dc11d46c@mail.gmail.com>

Hi Piebe,

You're right, there was no activity on this feature since december.
In my opinion, there won't be any if there is no clear and loud demand
for that, or if there's no fund given.
Though, I think the code doesn't require much work to be ready to go into trunk.

It's currently available in a sandbox. Don't hesitate to try a merge
against current trunk version and to play with it !

Regards,
Pierre

On Wed, Apr 9, 2008 at 5:01 PM, Piebe de Vries <piebe.de.vries@geodan.nl> wrote:
> Hi,
>
>  I really need to display labels on a vector layer. I found
>  http://dev.openlayers.org/sandbox/camptocamp/text/examples/vector-features-with-text.html
>  which looks promising but it seems there has not been much activity
>  since december.
>
>  Can somebody tell me the current status? Are there any plans to
>  integrate this in trunk anywhere soon, and, if not, for what reason? How
>  hard will it be to do it myself? etc....
>
>  cheers,
>   Piebe
>
>
>
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>

From eric.c2c at gmail.com  Wed Apr  9 11:59:31 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Style question
In-Reply-To: <47FCD32F.2080805@gmail.com>
References: <5ec103de0804090721n26eb1f80hdad81ad9d033037b@mail.gmail.com>
	<47FCD32F.2080805@gmail.com>
Message-ID: <5ec103de0804090859q4c0a4b90l7913fccb51908bdc@mail.gmail.com>

On Wed, Apr 9, 2008 at 4:31 PM, Andreas Hocevar
<andreas.hocevar@gmail.com> wrote:
> Eric,
>
>
>
>  Eric Lemoine wrote:
>
> > Hi. A style-related question: i've styled my vector layer using
> > StyleMap, Style and Rule. Now i'm in a featureselected event callback
> > and i'd like to get the current style (fillColor) of the selected
> > feature. I'm afraid i can't as the current feature style isn't stored
> > in the feature but only in the renderer deepness. Can someone confirm?
> >
> >
>
>  No problem to get the current symbolizer:
>
>  var symbolizer = feature.layer.styleMap.createSymbolizer(feature,
> feature.renderIntent);

Obviously! Thanks Andreas,

--
Eric

From crschmidt at metacarta.com  Wed Apr  9 14:12:28 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Release Candidate 2
Message-ID: <20080409181228.GA28505@metacarta.com>

The OpenLayers Development Team is proud to announce the second release
candidate of OpenLayers 2.5. This change fixes a number of issues with
the RC1 release: a full list is available at
  
  http://trac.openlayers.org/query?status=closed&version=2.6%20RC1

We invite you to help us test the 2.6 release candidate! To test 2.6 in
your applications, include the following tag in your OpenLayers-powered
page:

{{{
  <script src="http://openlayers.org/api/2.6-rc2/OpenLayers.js"></script>
}}}

As always, the source is available at http://openlayers.org/download/.
Bug reports can be filed in Trac, under the 2.6 RC2 version. Any
regressions should be filed under the 2.6 milestone.

Additionally, if you are interested in confirming that this release
works well in your browser, especially if it is a less commonly used
browser, you can run the OpenLayers test suite, and automatically report
your results, by:
 
 * Closing and reopening your browser
 * Opening http://openlayers.org/dev/tests/auto-tests.html 
 * Clicking the 'run all' button at the bottom of the page. 

This will run tests, and deliver the results to our OpenLayers test
server for developers to review.

We look forward to your feedback!

Regards,

The OpenLayers Team 

From euzuro at gmail.com  Wed Apr  9 14:35:00 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Release Candidate 2
In-Reply-To: <20080409181228.GA28505@metacarta.com>
References: <20080409181228.GA28505@metacarta.com>
Message-ID: <6ae3fb590804091135j619d1504tf4ffb7b4d435424f@mail.gmail.com>

Big Big High fives to Chris for his continued hard work doing these
releases. Not only is he
the one going through the tedium of all the branching, packaging,
updating tickets, and
updating release notes, but he has also been burning the midnight oil
reviewing some
really complicated tickets and also cooking up patches so that this
RC2 could happen.

Without his patience, flexibility, and hard work, we wouldn't have
these releases.

Thanks, Chris.



On Wed, Apr 9, 2008 at 2:12 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> The OpenLayers Development Team is proud to announce the second release
> candidate of OpenLayers 2.5. This change fixes a number of issues with
> the RC1 release: a full list is available at
>
>  http://trac.openlayers.org/query?status=closed&version=2.6%20RC1
>
> We invite you to help us test the 2.6 release candidate! To test 2.6 in
> your applications, include the following tag in your OpenLayers-powered
> page:
>
> {{{
>  <script src="http://openlayers.org/api/2.6-rc2/OpenLayers.js"></script>
> }}}
>
> As always, the source is available at http://openlayers.org/download/.
> Bug reports can be filed in Trac, under the 2.6 RC2 version. Any
> regressions should be filed under the 2.6 milestone.
>
> Additionally, if you are interested in confirming that this release
> works well in your browser, especially if it is a less commonly used
> browser, you can run the OpenLayers test suite, and automatically report
> your results, by:
>
>  * Closing and reopening your browser
>  * Opening http://openlayers.org/dev/tests/auto-tests.html
>  * Clicking the 'run all' button at the bottom of the page.
>
> This will run tests, and deliver the results to our OpenLayers test
> server for developers to review.
>
> We look forward to your feedback!
>
> Regards,
>
> The OpenLayers Team
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From tomas.novotny at tmapy.cz  Wed Apr  9 15:30:37 2008
From: tomas.novotny at tmapy.cz (tomas.novotny@tmapy.cz)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
Message-ID: <1973.85.132.169.14.1207769437.squirrel@matous.tmapy.cz>

Hi Tim,

I've made something similar today. I've modified panMap() and panMapDone()
methods in Control/DragPan.js for only moving layerContainer by CSS until
the end of drag. Result is what I needed - smooth panning. I will look
further in the code tomorrow to see what it means for rest of OL and will
play with it more. (One of the problem is not-loading tiles of Grid layer
before drag end - but it can still be technically achieved without massive
center calculations on every move).
At the same time I'm curious about your solution Tim. Can you send me or
give me URL to your pieces of code? I can send you mine if you want, maybe
I will put it to some public web.

Tomas

> Hey-
>
> I've got a half baked patch that gives the map a drag method.  This
> bypasses all center calculations until the drag ends (and only adjusts
> the position of the layer containers).  Works well except with
> commercial layers.  Given some more time, I'll fix it up.
>
> Tim



From bluecarto at gmail.com  Wed Apr  9 15:47:01 2008
From: bluecarto at gmail.com (Pierre GIRAUD)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <1973.85.132.169.14.1207769437.squirrel@matous.tmapy.cz>
References: <1973.85.132.169.14.1207769437.squirrel@matous.tmapy.cz>
Message-ID: <d50f50e60804091247g2303653epc607de588abc6730@mail.gmail.com>

Don't hesitate to do this using the OpenLayers sandbox mecanism.

On Wed, Apr 9, 2008 at 9:30 PM,  <tomas.novotny@tmapy.cz> wrote:
> Hi Tim,
>
>  I've made something similar today. I've modified panMap() and panMapDone()
>  methods in Control/DragPan.js for only moving layerContainer by CSS until
>  the end of drag. Result is what I needed - smooth panning. I will look
>  further in the code tomorrow to see what it means for rest of OL and will
>  play with it more. (One of the problem is not-loading tiles of Grid layer
>  before drag end - but it can still be technically achieved without massive
>  center calculations on every move).
>  At the same time I'm curious about your solution Tim. Can you send me or
>  give me URL to your pieces of code? I can send you mine if you want, maybe
>  I will put it to some public web.
>
>  Tomas
>
>
>  > Hey-
>  >
>  > I've got a half baked patch that gives the map a drag method.  This
>  > bypasses all center calculations until the drag ends (and only adjusts
>  > the position of the layer containers).  Works well except with
>  > commercial layers.  Given some more time, I'll fix it up.
>  >
>  > Tim
>
>
>
>
> _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>

From crschmidt at metacarta.com  Wed Apr  9 18:00:30 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Summer of Code Proposals
Message-ID: <20080409220030.GB31999@metacarta.com>

http://trac.openlayers.org/wiki/SummerOfCode/Proposals

On Monday, OSGeo will be decideding how to rank their total of 54
applications to Summer of Code.

However, in the next 24 hours, our administrator wants a count of how
many projects we 'want'.
(http://lists.osgeo.org/pipermail/soc/2008-April/000257.html) 

Looking at the list, all other things being equal, I could see that we
could want 4-5 projects here: more than that, and we'd have too many for
mentors, I think, and fewer than that, and I think we could be missing
out on valuable development.

Does this match up to what others think?

Also, please check out the proposals and help score them.

Also, if you're on the list, please feel free to campaign for your
project! :)

Regards,
-- 
Christopher Schmidt
MetaCarta

From cameron.shorter at gmail.com  Wed Apr  9 19:07:24 2008
From: cameron.shorter at gmail.com (Cameron Shorter)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Release Candidate 2
In-Reply-To: <6ae3fb590804091135j619d1504tf4ffb7b4d435424f@mail.gmail.com>
References: <20080409181228.GA28505@metacarta.com>
	<6ae3fb590804091135j619d1504tf4ffb7b4d435424f@mail.gmail.com>
Message-ID: <47FD4C2C.7080004@gmail.com>

Erik Uzureau wrote:
> Big Big High fives to Chris for his continued hard work doing these
> releases.
+1 Chris's dedication to answering questions, and getting the dirty work done for Openlayers has got to be one of the major factors contributing to the Openlayers success story.

-- 
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 Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html



From thinesh.gen at gmail.com  Wed Apr  9 22:43:32 2008
From: thinesh.gen at gmail.com (Thinesh thusinthaka)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] New to Openlayers
Message-ID: <927196540804091943t5ccbe142mf5b3da025de4cc66@mail.gmail.com>

Hi,
Am new to OpenLayers and this is my first mail to the dev.

I have worked on GeoRss with SimplePie and on Google APIs.
Need to work more on Java script and OpenLayers and OSgeo..


reg,
Thinesh

From eric.c2c at gmail.com  Thu Apr 10 03:29:51 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Summer of Code Proposals
In-Reply-To: <20080409220030.GB31999@metacarta.com>
References: <20080409220030.GB31999@metacarta.com>
Message-ID: <5ec103de0804100029o9111fael97acf01562628794@mail.gmail.com>

On Thu, Apr 10, 2008 at 12:00 AM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> http://trac.openlayers.org/wiki/SummerOfCode/Proposals
>
>  On Monday, OSGeo will be decideding how to rank their total of 54
>  applications to Summer of Code.
>
>  However, in the next 24 hours, our administrator wants a count of how
>  many projects we 'want'.
>  (http://lists.osgeo.org/pipermail/soc/2008-April/000257.html)
>
>  Looking at the list, all other things being equal, I could see that we
>  could want 4-5 projects here: more than that, and we'd have too many for
>  mentors, I think, and fewer than that, and I think we could be missing
>  out on valuable development.
>
>  Does this match up to what others think?

I see 4 projects (the first four in the list).

--
Eric

From eric.c2c at gmail.com  Thu Apr 10 03:45:35 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Summer of Code Proposals
In-Reply-To: <5ec103de0804100029o9111fael97acf01562628794@mail.gmail.com>
References: <20080409220030.GB31999@metacarta.com>
	<5ec103de0804100029o9111fael97acf01562628794@mail.gmail.com>
Message-ID: <5ec103de0804100045r422d8a56wd65a6ad915a28748@mail.gmail.com>

On Thu, Apr 10, 2008 at 9:29 AM, Eric Lemoine <eric.c2c@gmail.com> wrote:
> On Thu, Apr 10, 2008 at 12:00 AM, Christopher Schmidt
>  <crschmidt@metacarta.com> wrote:
>  > http://trac.openlayers.org/wiki/SummerOfCode/Proposals
>  >
>  >  On Monday, OSGeo will be decideding how to rank their total of 54
>  >  applications to Summer of Code.
>  >
>  >  However, in the next 24 hours, our administrator wants a count of how
>  >  many projects we 'want'.
>  >  (http://lists.osgeo.org/pipermail/soc/2008-April/000257.html)
>  >
>  >  Looking at the list, all other things being equal, I could see that we
>  >  could want 4-5 projects here: more than that, and we'd have too many for
>  >  mentors, I think, and fewer than that, and I think we could be missing
>  >  out on valuable development.
>  >
>  >  Does this match up to what others think?
>
>  I see 4 projects (the first four in the list).

On an unrelated note: for those like me who did not automatically as
mentors get registered to the SoC mailing list, go to
<google-summer-of-code-mentors-list@googlegroups.com> and add yourself
in the google group.

--
Eric

From eric.c2c at gmail.com  Thu Apr 10 03:46:24 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Summer of Code Proposals
In-Reply-To: <5ec103de0804100045r422d8a56wd65a6ad915a28748@mail.gmail.com>
References: <20080409220030.GB31999@metacarta.com>
	<5ec103de0804100029o9111fael97acf01562628794@mail.gmail.com>
	<5ec103de0804100045r422d8a56wd65a6ad915a28748@mail.gmail.com>
Message-ID: <5ec103de0804100046w49ab9386l2e701a34e2622be6@mail.gmail.com>

>  On an unrelated note: for those like me who did not automatically as
>  mentors get registered to the SoC mailing list, go to
>  <google-summer-of-code-mentors-list@googlegroups.com> and add yourself
>  in the google group.

Sorry wrong URL. Here it is:

<http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en>

--
Eric

From euzuro at gmail.com  Thu Apr 10 03:40:55 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] New to Openlayers
In-Reply-To: <927196540804091943t5ccbe142mf5b3da025de4cc66@mail.gmail.com>
References: <927196540804091943t5ccbe142mf5b3da025de4cc66@mail.gmail.com>
Message-ID: <6ae3fb590804100040y6d73c28fg6369909df58d6bfb@mail.gmail.com>

Hello, Thinesh. Welcome to the OpenLayers community. This is the right list
on which to post questions or concerns. Look forward to hearing from you!


On Wed, Apr 9, 2008 at 10:43 PM, Thinesh thusinthaka
<thinesh.gen@gmail.com> wrote:
> Hi,
> Am new to OpenLayers and this is my first mail to the dev.
>
> I have worked on GeoRss with SimplePie and on Google APIs.
> Need to work more on Java script and OpenLayers and OSgeo..
>
>
> reg,
> Thinesh
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From bartvde at osgis.nl  Thu Apr 10 03:51:50 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
Message-ID: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>

Hi list,

is anyone going to FOSS4G2008 in Capetown?

Are there plans to do an OpenLayers workshop? I would be interested in
helping out.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl






From tomas.novotny at tmapy.cz  Thu Apr 10 05:59:53 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
Message-ID: <47FDE519.5080007@tmapy.cz>

Hi,

please try following examples and compare them:

First example shows current map dragging in OL 2.6:
http://www.utomase.cz/ol/currentDragging.html

Second example shows dragging after my little changes in DragPan.js:
http://www.utomase.cz/ol/newDragging.html

In second example only layers container is moving via CSS without any 
center calculations. Those calculations come to play either after 25ms 
of 'not-moving' or drag end (mouseup).


Tomas Novotny

From steven at minst.net  Thu Apr 10 06:18:20 2008
From: steven at minst.net (Steven M. Ottens)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Summer of Code Proposals
In-Reply-To: <20080409220030.GB31999@metacarta.com>
References: <20080409220030.GB31999@metacarta.com>
Message-ID: <9E3130F5-985C-40A7-83F8-9A98BFEFDFF6@minst.net>

I agree with 4-5

On Apr 10, 2008, at 12:00 AM, Christopher Schmidt wrote:

> http://trac.openlayers.org/wiki/SummerOfCode/Proposals
>
> On Monday, OSGeo will be decideding how to rank their total of 54
> applications to Summer of Code.
>
> However, in the next 24 hours, our administrator wants a count of how
> many projects we 'want'.
> (http://lists.osgeo.org/pipermail/soc/2008-April/000257.html)
>
> Looking at the list, all other things being equal, I could see that we
> could want 4-5 projects here: more than that, and we'd have too  
> many for
> mentors, I think, and fewer than that, and I think we could be missing
> out on valuable development.
>
> Does this match up to what others think?
>
> Also, please check out the proposals and help score them.
>
> Also, if you're on the list, please feel free to campaign for your
> project! :)
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


From crschmidt at metacarta.com  Thu Apr 10 06:44:27 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FDE519.5080007@tmapy.cz>
References: <47FDE519.5080007@tmapy.cz>
Message-ID: <20080410104427.GA10710@metacarta.com>

On Thu, Apr 10, 2008 at 11:59:53AM +0200, Tomas Novotny wrote:
> Hi,
> 
> please try following examples and compare them:
> 
> First example shows current map dragging in OL 2.6:
> http://www.utomase.cz/ol/currentDragging.html
> 
> Second example shows dragging after my little changes in DragPan.js:
> http://www.utomase.cz/ol/newDragging.html
> 
> In second example only layers container is moving via CSS without any 
> center calculations. Those calculations come to play either after 25ms 
> of 'not-moving' or drag end (mouseup).

Please contribute this in some way in the bug tracker: either with an
existing ticket, or by creating a new ticket. The bug tracker is our
long term knowledgebase: without a recording in it, we'll lose track of
it.

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Thu Apr 10 06:55:19 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
Message-ID: <20080410105518.GG10710@metacarta.com>

On Thu, Apr 10, 2008 at 09:51:50AM +0200, Bart van den Eijnden (OSGIS) wrote:
> Hi list,
> 
> is anyone going to FOSS4G2008 in Capetown?
> 
> Are there plans to do an OpenLayers workshop? I would be interested in
> helping out.

It's still not decided if I'm going to be able to go yet, but I'd love
to hear whether other people are going, and I'll gladly participate from
afar in any way I can.

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Thu Apr 10 08:19:08 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <20080410105518.GG10710@metacarta.com>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
	<20080410105518.GG10710@metacarta.com>
Message-ID: <5ec103de0804100519q10878b03w3296503111082b87@mail.gmail.com>

On Thu, Apr 10, 2008 at 12:55 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> On Thu, Apr 10, 2008 at 09:51:50AM +0200, Bart van den Eijnden (OSGIS) wrote:
>  > Hi list,
>  >
>  > is anyone going to FOSS4G2008 in Capetown?
>  >
>  > Are there plans to do an OpenLayers workshop? I would be interested in
>  > helping out.
>
>  It's still not decided if I'm going to be able to go yet, but I'd love
>  to hear whether other people are going, and I'll gladly participate from
>  afar in any way I can.

Camptocamp will be there. Now, we don't know who is going to go among
the OpenLayers/MapFish developpers.

--
Eric

From pspencer at dmsolutions.ca  Thu Apr 10 08:35:54 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
Message-ID: <2D181BF2-11CF-47E3-8E59-7A0AAC612F56@dmsolutions.ca>


On 10-Apr-08, at 3:51 AM, Bart van den Eijnden (OSGIS) wrote:
> Hi list,
>
> is anyone going to FOSS4G2008 in Capetown?
>
> Are there plans to do an OpenLayers workshop? I would be interested in
> helping out.
>

I am probably going with one other person from DM Solutions Group this  
year (to be determined), I am interested in doing some sort of  
OpenLayers workshop.

Cheers

Paul

From pspencer at dmsolutions.ca  Thu Apr 10 09:04:56 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FDE519.5080007@tmapy.cz>
References: <47FDE519.5080007@tmapy.cz>
Message-ID: <4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>

Sadly, no noticeable difference to me in Safari 3 or FF 2.

Paul

On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
> Hi,
>
> please try following examples and compare them:
>
> First example shows current map dragging in OL 2.6:
> http://www.utomase.cz/ol/currentDragging.html
>
> Second example shows dragging after my little changes in DragPan.js:
> http://www.utomase.cz/ol/newDragging.html
>
> In second example only layers container is moving via CSS without any
> center calculations. Those calculations come to play either after 25ms
> of 'not-moving' or drag end (mouseup).
>
>
> Tomas Novotny
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From woodbri at swoodbridge.com  Thu Apr 10 10:20:07 2008
From: woodbri at swoodbridge.com (Stephen Woodbridge)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
References: <47FDE519.5080007@tmapy.cz>
	<4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
Message-ID: <47FE2217.3060403@swoodbridge.com>

Sweet, this improves my experience. I have an older dual processor 
workstation running windows 2000 and 21 windows open. Running FF2. I 
think this patch has some merit. Keep going with it.

-Steve

Paul Spencer wrote:
> Sadly, no noticeable difference to me in Safari 3 or FF 2.
> 
> Paul
> 
> On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
>> Hi,
>>
>> please try following examples and compare them:
>>
>> First example shows current map dragging in OL 2.6:
>> http://www.utomase.cz/ol/currentDragging.html
>>
>> Second example shows dragging after my little changes in DragPan.js:
>> http://www.utomase.cz/ol/newDragging.html
>>
>> In second example only layers container is moving via CSS without any
>> center calculations. Those calculations come to play either after 25ms
>> of 'not-moving' or drag end (mouseup).
>>
>>
>> Tomas Novotny
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
> 
> 
> __________________________________________
> 
>     Paul Spencer
>     Chief Technology Officer
>     DM Solutions Group Inc
>     http://www.dmsolutions.ca/
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


From tschaub at openplans.org  Thu Apr 10 10:11:54 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Style question
In-Reply-To: <5ec103de0804090859q4c0a4b90l7913fccb51908bdc@mail.gmail.com>
References: <5ec103de0804090721n26eb1f80hdad81ad9d033037b@mail.gmail.com>	<47FCD32F.2080805@gmail.com>
	<5ec103de0804090859q4c0a4b90l7913fccb51908bdc@mail.gmail.com>
Message-ID: <47FE202A.2040300@openplans.org>

Functionality first, convenience second.  The feature.style property was 
convenient, but very limited in functionality.  The new stuff is getting 
very functional.  A feature.getSymbolizer method isn't that hard to 
imagine adding.

Tim

Eric Lemoine wrote:
> On Wed, Apr 9, 2008 at 4:31 PM, Andreas Hocevar
> <andreas.hocevar@gmail.com> wrote:
>> Eric,
>>
>>
>>
>>  Eric Lemoine wrote:
>>
>>> Hi. A style-related question: i've styled my vector layer using
>>> StyleMap, Style and Rule. Now i'm in a featureselected event callback
>>> and i'd like to get the current style (fillColor) of the selected
>>> feature. I'm afraid i can't as the current feature style isn't stored
>>> in the feature but only in the renderer deepness. Can someone confirm?
>>>
>>>
>>  No problem to get the current symbolizer:
>>
>>  var symbolizer = feature.layer.styleMap.createSymbolizer(feature,
>> feature.renderIntent);
> 
> Obviously! Thanks Andreas,
> 
> --
> Eric
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47fce970172191637810514!
> 


From tomas.novotny at tmapy.cz  Thu Apr 10 10:14:05 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re:  OpenLayers performance
In-Reply-To: <4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
References: <47FDE519.5080007@tmapy.cz>
	<4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
Message-ID: <47FE20AD.4050203@tmapy.cz>

My little summary:

Doing circles with map using mouse...

...on first PC (Intel Core 2 CPU 6400 @ 2.13GHz, 1GB RAM, Windows XP SP2):
- Safari 3: almost no difference
- FF2: noticeable difference (map makes little jumps now and then 
without patch)
- IE7: big difference (map jumps now and then without patch)
- IE6: huge difference (map only jumps without patch)
- Opera 9: clear difference (map makes jumps now and then without patch)

...on second PC (Intel Pentium M 1.73 GHz, 1GB RAM, Windows XP SP2):
- FF2: noticeable difference (map makes little jumps now and then 
without patch)
- IE7: big difference (map jumps now and then without patch)

My friends can feel the difference on their machines too. Believe me, 
this problem is significant not only for me. I need good-feeling 
solution on most of the platforms.

It is all based on: "It's just not as comfortable as GoogleMaps".

I will be glad to help with implementing such kind of patch - if there 
is will.


Tomas


Paul Spencer wrote:
> Sadly, no noticeable difference to me in Safari 3 or FF 2.
> 
> Paul
> 
> On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
>> Hi,
>>
>> please try following examples and compare them:
>>
>> First example shows current map dragging in OL 2.6:
>> http://www.utomase.cz/ol/currentDragging.html
>>
>> Second example shows dragging after my little changes in DragPan.js:
>> http://www.utomase.cz/ol/newDragging.html
>>
>> In second example only layers container is moving via CSS without any
>> center calculations. Those calculations come to play either after 25ms
>> of 'not-moving' or drag end (mouseup).
>>
>>
>> Tomas Novotny
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
> 
> 
> __________________________________________
> 
>    Paul Spencer
>    Chief Technology Officer
>    DM Solutions Group Inc
>    http://www.dmsolutions.ca/
> 
> 

From tschaub at openplans.org  Thu Apr 10 10:17:25 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <2D181BF2-11CF-47E3-8E59-7A0AAC612F56@dmsolutions.ca>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
	<2D181BF2-11CF-47E3-8E59-7A0AAC612F56@dmsolutions.ca>
Message-ID: <47FE2175.8050207@openplans.org>

I'll be campaigning to go as well.

Tim

Paul Spencer wrote:
> On 10-Apr-08, at 3:51 AM, Bart van den Eijnden (OSGIS) wrote:
>> Hi list,
>>
>> is anyone going to FOSS4G2008 in Capetown?
>>
>> Are there plans to do an OpenLayers workshop? I would be interested in
>> helping out.
>>
> 
> I am probably going with one other person from DM Solutions Group this  
> year (to be determined), I am interested in doing some sort of  
> OpenLayers workshop.
> 
> Cheers
> 
> Paul
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47fe09e97582092453641!
> 


From tschaub at openplans.org  Thu Apr 10 10:24:06 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re:  OpenLayers performance
In-Reply-To: <47FE20AD.4050203@tmapy.cz>
References: <47FDE519.5080007@tmapy.cz>
	<4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
	<47FE20AD.4050203@tmapy.cz>
Message-ID: <47FE2306.4050504@openplans.org>

Hey-

Thanks for the work.  As Chris suggested, a ticket is a good place to start:

http://trac.openlayers.org/wiki/FilingTickets

As Pierre suggested, a sandbox is a great place to work:

http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#HowdoIcreatemyownsandboxintheSVNrepository

Tim

Tomas Novotny wrote:
> My little summary:
> 
> Doing circles with map using mouse...
> 
> ...on first PC (Intel Core 2 CPU 6400 @ 2.13GHz, 1GB RAM, Windows XP SP2):
> - Safari 3: almost no difference
> - FF2: noticeable difference (map makes little jumps now and then 
> without patch)
> - IE7: big difference (map jumps now and then without patch)
> - IE6: huge difference (map only jumps without patch)
> - Opera 9: clear difference (map makes jumps now and then without patch)
> 
> ...on second PC (Intel Pentium M 1.73 GHz, 1GB RAM, Windows XP SP2):
> - FF2: noticeable difference (map makes little jumps now and then 
> without patch)
> - IE7: big difference (map jumps now and then without patch)
> 
> My friends can feel the difference on their machines too. Believe me, 
> this problem is significant not only for me. I need good-feeling 
> solution on most of the platforms.
> 
> It is all based on: "It's just not as comfortable as GoogleMaps".
> 
> I will be glad to help with implementing such kind of patch - if there 
> is will.
> 
> 
> Tomas
> 
> 
> Paul Spencer wrote:
>> Sadly, no noticeable difference to me in Safari 3 or FF 2.
>>
>> Paul
>>
>> On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
>>> Hi,
>>>
>>> please try following examples and compare them:
>>>
>>> First example shows current map dragging in OL 2.6:
>>> http://www.utomase.cz/ol/currentDragging.html
>>>
>>> Second example shows dragging after my little changes in DragPan.js:
>>> http://www.utomase.cz/ol/newDragging.html
>>>
>>> In second example only layers container is moving via CSS without any
>>> center calculations. Those calculations come to play either after 25ms
>>> of 'not-moving' or drag end (mouseup).
>>>
>>>
>>> Tomas Novotny
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>
>>
>> __________________________________________
>>
>>    Paul Spencer
>>    Chief Technology Officer
>>    DM Solutions Group Inc
>>    http://www.dmsolutions.ca/
>>
>>
> 
> !DSPAM:4033,47fe20e847326491211187!
> 


From bluecarto at gmail.com  Thu Apr 10 16:16:34 2008
From: bluecarto at gmail.com (Pierre GIRAUD)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re: OpenLayers performance
In-Reply-To: <47FE20AD.4050203@tmapy.cz>
References: <47FDE519.5080007@tmapy.cz>
	<4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
	<47FE20AD.4050203@tmapy.cz>
Message-ID: <d50f50e60804101316g2a852230t3d9a4c2b8e29247d@mail.gmail.com>

Please keep going with this work because to be honest, I'm one of the
guys who sinlently think "this is not as comfortable as GMaps".

Pierre

On Thu, Apr 10, 2008 at 4:14 PM, Tomas Novotny <tomas.novotny@tmapy.cz> wrote:
> My little summary:
>
>  Doing circles with map using mouse...
>
>  ...on first PC (Intel Core 2 CPU 6400 @ 2.13GHz, 1GB RAM, Windows XP SP2):
>  - Safari 3: almost no difference
>  - FF2: noticeable difference (map makes little jumps now and then
>  without patch)
>  - IE7: big difference (map jumps now and then without patch)
>  - IE6: huge difference (map only jumps without patch)
>  - Opera 9: clear difference (map makes jumps now and then without patch)
>
>  ...on second PC (Intel Pentium M 1.73 GHz, 1GB RAM, Windows XP SP2):
>  - FF2: noticeable difference (map makes little jumps now and then
>  without patch)
>  - IE7: big difference (map jumps now and then without patch)
>
>  My friends can feel the difference on their machines too. Believe me,
>  this problem is significant not only for me. I need good-feeling
>  solution on most of the platforms.
>
>  It is all based on: "It's just not as comfortable as GoogleMaps".
>
>  I will be glad to help with implementing such kind of patch - if there
>  is will.
>
>
>  Tomas
>
>
>
>
>  Paul Spencer wrote:
>  > Sadly, no noticeable difference to me in Safari 3 or FF 2.
>  >
>  > Paul
>  >
>  > On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
>  >> Hi,
>  >>
>  >> please try following examples and compare them:
>  >>
>  >> First example shows current map dragging in OL 2.6:
>  >> http://www.utomase.cz/ol/currentDragging.html
>  >>
>  >> Second example shows dragging after my little changes in DragPan.js:
>  >> http://www.utomase.cz/ol/newDragging.html
>  >>
>  >> In second example only layers container is moving via CSS without any
>  >> center calculations. Those calculations come to play either after 25ms
>  >> of 'not-moving' or drag end (mouseup).
>  >>
>  >>
>  >> Tomas Novotny
>  >> _______________________________________________
>  >> Dev mailing list
>  >> Dev@openlayers.org
>  >> http://openlayers.org/mailman/listinfo/dev
>  >
>  >
>  > __________________________________________
>  >
>  >    Paul Spencer
>  >    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  Thu Apr 10 17:17:03 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [SPAM] Re: OpenLayers performance
In-Reply-To: <d50f50e60804101316g2a852230t3d9a4c2b8e29247d@mail.gmail.com>
References: <47FDE519.5080007@tmapy.cz>
	<4A36DB8D-9EE4-4C51-A8CB-B2CECF7848EB@dmsolutions.ca>
	<47FE20AD.4050203@tmapy.cz>
	<d50f50e60804101316g2a852230t3d9a4c2b8e29247d@mail.gmail.com>
Message-ID: <253530F2-3F23-4F7B-92D1-EE0ED9017537@dmsolutions.ca>

Sorry, I should have added that I also see a difference between OL and  
GMap but the patch didn't seem to make things appreciably better for  
me ... but please keep working on it :)

Cheers

Paul

On 10-Apr-08, at 4:16 PM, Pierre GIRAUD wrote:
> Please keep going with this work because to be honest, I'm one of the
> guys who sinlently think "this is not as comfortable as GMaps".
>
> Pierre
>
> On Thu, Apr 10, 2008 at 4:14 PM, Tomas Novotny  
> <tomas.novotny@tmapy.cz> wrote:
>> My little summary:
>>
>> Doing circles with map using mouse...
>>
>> ...on first PC (Intel Core 2 CPU 6400 @ 2.13GHz, 1GB RAM, Windows  
>> XP SP2):
>> - Safari 3: almost no difference
>> - FF2: noticeable difference (map makes little jumps now and then
>> without patch)
>> - IE7: big difference (map jumps now and then without patch)
>> - IE6: huge difference (map only jumps without patch)
>> - Opera 9: clear difference (map makes jumps now and then without  
>> patch)
>>
>> ...on second PC (Intel Pentium M 1.73 GHz, 1GB RAM, Windows XP SP2):
>> - FF2: noticeable difference (map makes little jumps now and then
>> without patch)
>> - IE7: big difference (map jumps now and then without patch)
>>
>> My friends can feel the difference on their machines too. Believe me,
>> this problem is significant not only for me. I need good-feeling
>> solution on most of the platforms.
>>
>> It is all based on: "It's just not as comfortable as GoogleMaps".
>>
>> I will be glad to help with implementing such kind of patch - if  
>> there
>> is will.
>>
>>
>> Tomas
>>
>>
>>
>>
>> Paul Spencer wrote:
>>> Sadly, no noticeable difference to me in Safari 3 or FF 2.
>>>
>>> Paul
>>>
>>> On 10-Apr-08, at 5:59 AM, Tomas Novotny wrote:
>>>> Hi,
>>>>
>>>> please try following examples and compare them:
>>>>
>>>> First example shows current map dragging in OL 2.6:
>>>> http://www.utomase.cz/ol/currentDragging.html
>>>>
>>>> Second example shows dragging after my little changes in  
>>>> DragPan.js:
>>>> http://www.utomase.cz/ol/newDragging.html
>>>>
>>>> In second example only layers container is moving via CSS without  
>>>> any
>>>> center calculations. Those calculations come to play either after  
>>>> 25ms
>>>> of 'not-moving' or drag end (mouseup).
>>>>
>>>>
>>>> Tomas Novotny
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev@openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>>
>>> __________________________________________
>>>
>>>   Paul Spencer
>>>   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
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From pedrosimonetti at gmail.com  Thu Apr 10 18:23:37 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev]  Fix for issue #327: ka-Map overlays
Message-ID: <16620073.post@talk.nabble.com>


Hi all,

I'm doing an upgrade in the Veracidade project that was initially made over
ka-Map.
http://www.veracidade.com.br/

Were upgrading the whole project. We're upgrading our imagery database and
including new featues, so I felt a good step to migrate to OpenLayers,
giving the benefits OL offers to customization and user interaction.

As every project, we have a limited schedule, but I hope this jorney will
bring some goodies to the OL community, specially for those using OL+ka-Map.

I've made some changes in the OL's ka-Map interface, and I would like to
share this with you all. I'll break those changes in different threads to
make it easier to future research. 

So here we go. There is a problem in the "tile.php" file (named
"examples/kamap.txt") related to ka-Map overlays.
http://trac.openlayers.org/ticket/327

The solution is actually very simple. The code was missing to uppercase the
output format, so if you set your map in .js with "i" equals to "gif", the
code won't cacth this, and will use de default value from "tile.php"
configuration section.

I've break this file in two files "tile.php" and "config.php" to allow a
single configuration file be shared with both "tile.php" and "precache.php"
(I'll discuss prepache changes in another thread).

I'll posting a patch on the tracker for this issue.

Here goes a suggestion. Since there will be 3 different php files related to
ka-Map, I think will be good, to create another directory for those files,
maybe in "examples/kaMap", for example. I think also that is good to put
those files named "tile.php.txt", "config.php.txt", and "precache.php.txt",
to a better readibility.

This changes required a little change in KaMap.js, because the constant
"OpenLayers.Layer.KaMap.DEFAULT_PARAMS" souldn't be used, as the default
output format is taken from "config.php" file.

So, I'll post in the tracker a separated patch for this.

Here a simple example of creating two ka-Map layers:

  // The output format used will be that informed at "config.php", 
  // since the parameter "i" was not used.
  var kamap_base = new OpenLayers.Layer.KaMap(
      "Satellite",
      "http://www.openlayers.org/world/tile.php", 
      {g: "satellite", map: "world"}
    );

  // Create an ka-Map overlay layer (using "isBaseLayer: false"). Forces
  // the output to be a "gif", using the "i" parameter.
  var kamap_overlay = new OpenLayers.Layer.KaMap(
      "Streets",
      "http://www.openlayers.org/world/tile.php", 
      {g: "streets", map: "world", i: "gif"},
      {isBaseLayer: false}
    );

regards,

Pedro Simonetti.
-- 
View this message in context: http://www.nabble.com/Fix-for-issue--327%3A-ka-Map-overlays-tp16620073p16620073.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From pedrosimonetti at gmail.com  Thu Apr 10 21:24:28 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev]  Patch for a ka-Map cached layer
Message-ID: <16623387.post@talk.nabble.com>


Hi all,

As I stated in an earlier thread [1], I've changed some part of the OL's
code to 
handle ka-Map pre-cached layers, similar to the TileCache class. With a
cached 
layer, the ka-Map tiles will be loaded considerably faster.

[1]
http://www.nabble.com/Fix-for-issue--327%3A-ka-Map-overlays-tc16620073.html

A long time ago [2], Jochen Grefe has posted here about a similar aproach:

[2]
http://www.nabble.com/Using-kamaps-direct-cache-access-tc11581326.html#a11581326

The solution provided by him works, but it has some small problems I'll
decribe 
here. First, I thought it was more natural to make a separate KaMapCache
class, 
similar to TileCache class. One problem is that when the layer's group name
(the 
"g" parameter in KaMap class) has white spaces, it doesn't get the proper
url. 
Another problem is related to the directory structure described above. I've
also 
changed the string concatenation to the Array.splice method, as used in "
TileCache" class.

So, I wrote a new KaMapCache class, that overextends a KaMap class. This
class 
overrides the "getURL" to generate the full URL of each tile, without
calling 
the server.

To create a a new KaMapCache layer, you must indicate also the "i" parameter
(
that will be used to calculate the file extension), and another special 
parameter, object names "metaTileSize", with "h" (height) and "w"
properties, as 
suggested by Jochen.

Here's a simple example. Is the same example of my earlier thread [1], but
using
a KaMapCache layer. 

  // Create a new kaMapCache layer. You must allways inform the "i"
parameter
  // for a KaMapCache layer.
  var kamap_base = new OpenLayers.Layer.KaMapCache(
      "Satellite",
      "http://www.example.org/web/acessible/cache",
      {g: "satellite", map: "world", i: 'png24', metaTileSize: {w: 5, h: 5}
}
    );

  // Create an kaMapCache overlay layer (using "isBaseLayer: false"). Forces
  // the output to be a "gif", using the "i" parameter.
  var kamap_overlay = new OpenLayers.Layer.KaMapCache(
      "Streets",
      "http://www.example.org/web/acessible/cache",
      {g: "streets", map: "world", i: "gif", metaTileSize: {w: 5, h: 5} },
      {isBaseLayer: false}
    );

I don't have privileges to open a new ticket so I'll put the files as an 
atachment of this message. As it was stated in my earlier thread, I've
splitted
the "tile.php" in two files: "tile.php", and "config.php", so this
configuration 
file can be used also with a "precache.php" file.

Like the TileCache layers, you must pre-generate all tiles before using it.
This 
is done with the "precache.php" file. This file is basically the
"precache2.php" 
file that comes with ka-Map distribution, with almost none changes.

Was removed a piece of code that was trying to remotely create the cache 
directory. This was a useless step, once "precache.php" is a command line
tool 
that will generate that folder locally.

The other change was related to the directory structure of the cache. There
was 
a slighly difference between the directory generated by "precache2.php", and
the 
one generated by "tile.php", the code already in use at OL.

precache2.php:
var/cache/World/50000/Group_Name/def/t-440320/l20480

tile.php:
var/cache/World/50000/Group_Name/def/t-440320l20480

I don't know why this was changed, and I would like to hear some opinions. 
What's the best structure? Or both has the same performance? I mean, I
suppose 
the second one would generate more folders inside the "def" folder for
smaller 
scales like the street level scale. But since I'm not a hardware guru, I'm 
asking here in the list. This can somehow affect the hard disk performance
or 
something related?

The files used are:
  * "precache.php", renamed as "precache.php.txt"
  * "config.php", the same used in the my earlier's post. I'll not upload
this 
     again to avoid duplicities in the tracker.
  * "KaMapCache.js", the new class.   


I hope this patch helps.

my best regards,

Pedro Simonetti.
http://www.nabble.com/file/p16623387/KaMapCache.js KaMapCache.js 
http://www.nabble.com/file/p16623387/precache.php.txt precache.php.txt 
-- 
View this message in context: http://www.nabble.com/Patch-for-a-ka-Map-cached-layer-tp16623387p16623387.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From pspencer at dmsolutions.ca  Thu Apr 10 21:48:42 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Patch for a ka-Map cached layer
In-Reply-To: <16623387.post@talk.nabble.com>
References: <16623387.post@talk.nabble.com>
Message-ID: <20217482-4FA9-4F65-919B-E4D883B2DBCB@dmsolutions.ca>

Hi Pedro,

sounds like you are making good progress :)  You should be able to log  
in at http://trac.openlayers.org/ by following the instructions in the  
grey box at the top left of that page and then you can create tickets.


On 10-Apr-08, at 9:24 PM, Pedro Simonetti wrote:

<snip>

> The other change was related to the directory structure of the  
> cache. There
> was
> a slighly difference between the directory generated by  
> "precache2.php", and
> the
> one generated by "tile.php", the code already in use at OL.
>
> precache2.php:
> var/cache/World/50000/Group_Name/def/t-440320/l20480
>
> tile.php:
> var/cache/World/50000/Group_Name/def/t-440320l20480
>
> I don't know why this was changed, and I would like to hear some  
> opinions.
> What's the best structure? Or both has the same performance? I mean, I
> suppose
> the second one would generate more folders inside the "def" folder for
> smaller
> scales like the street level scale. But since I'm not a hardware  
> guru, I'm
> asking here in the list. This can somehow affect the hard disk  
> performance
> or
> something related?

You are exactly right, this was changed at one point to add an extra  
level of directory structure depth in an attempt to avoid file system  
limitations on the number of entries in a single directory.

Thank you for your hard work in figuring all this out.  I am sure that  
lots of people will finding both interesting and useful.

Cheers

Paul

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From pedrosimonetti at gmail.com  Thu Apr 10 22:05:09 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Patch for a ka-Map cached layer
In-Reply-To: <20217482-4FA9-4F65-919B-E4D883B2DBCB@dmsolutions.ca>
References: <16623387.post@talk.nabble.com>
	<20217482-4FA9-4F65-919B-E4D883B2DBCB@dmsolutions.ca>
Message-ID: <16623702.post@talk.nabble.com>




pagameba wrote:
> 
> Hi Pedro,
> 
> sounds like you are making good progress :)  You should be able to log  
> in at http://trac.openlayers.org/ by following the instructions in the  
> grey box at the top left of that page and then you can create tickets.
> 
> 
> On 10-Apr-08, at 9:24 PM, Pedro Simonetti wrote:
> 
> <snip>
> 
>> The other change was related to the directory structure of the  
>> cache. There
>> was
>> a slighly difference between the directory generated by  
>> "precache2.php", and
>> the
>> one generated by "tile.php", the code already in use at OL.
>>
>> precache2.php:
>> var/cache/World/50000/Group_Name/def/t-440320/l20480
>>
>> tile.php:
>> var/cache/World/50000/Group_Name/def/t-440320l20480
>>
>> I don't know why this was changed, and I would like to hear some  
>> opinions.
>> What's the best structure? Or both has the same performance? I mean, I
>> suppose
>> the second one would generate more folders inside the "def" folder for
>> smaller
>> scales like the street level scale. But since I'm not a hardware  
>> guru, I'm
>> asking here in the list. This can somehow affect the hard disk  
>> performance
>> or
>> something related?
> 
> You are exactly right, this was changed at one point to add an extra  
> level of directory structure depth in an attempt to avoid file system  
> limitations on the number of entries in a single directory.
> 

Hey Paul,

Thanks for your response.

Just to make it clear, so the structure [1] is the best one (one more
directory level)?

[1] var/cache/World/50000/Group_Name/def/t-440320/l20480
[2] var/cache/World/50000/Group_Name/def/t-440320l20480

If so, I'll have to make this little modifications in the patches/files I've
sended here, and in the earlier post. But this is easy, just confirm if the
first one is the best.

regards,

Pedro.
-- 
View this message in context: http://www.nabble.com/Patch-for-a-ka-Map-cached-layer-tp16623387p16623702.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From tchule at hotmail.com  Fri Apr 11 05:20:50 2008
From: tchule at hotmail.com (Benoit PESTY)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [OpenLayers-Users] Delete Feature
Message-ID: <BAY102-W2933EBF323399C532ABE6DCCEF0@phx.gbl>


Hello,

I've discovered that my problem is link with the presence of the "ModifyFeature" control that changes the behaviour of the Select control.

I'm a bit lost with these controls and the removeFeatures/ eraseFeatures / destroyFeatures methods of the Vector class.

Does someone have a clean example of how to create an Editing Toolbar with :
- The create point / line / polygone buttons
- A Delete Feature button
- A Modify Feature button

Thanks,

Tchule.

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080411/37ae92c3/attachment.html
From tomas.novotny at tmapy.cz  Fri Apr 11 07:45:14 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
Message-ID: <47FF4F4A.1060507@tmapy.cz>

After spending some time reading about sandboxes, tickets, patches and 
other OL-dev-kungfu I've tried to create a ticket for my problem:

http://trac.openlayers.org/ticket/1509

Thanks for help-links.


Tomas

From sylvain.beorchia at makina-corpus.com  Fri Apr 11 09:58:54 2008
From: sylvain.beorchia at makina-corpus.com (Sylvain Beorchia)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev]  Neutral theme for OL
In-Reply-To: <47FF4F4A.1060507@tmapy.cz>
References: <47FF4F4A.1060507@tmapy.cz>
Message-ID: <47FF6E9E.40800@makina-corpus.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


For those interested, i made a custom theme for OL, in white/grey
colors. Neutral theme.
You may see it on my sandbox :

http://dev.openlayers.org/sandbox/sbeorchia/openlayers/examples/controls.html




- --
Sylvain Beorchia, d?veloppeur SIG
MAKINA CORPUS - www.makina-corpus.com
T : +33 (0) 1 44 82 00 80 / F : +33 (0) 1 49 29 02 05
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/26eit+Ro3cR7XYRAiaNAJ4ghMc2rVhBwzkQkK+/oA1Gzo0uEQCeKHc8
PvAQ9laUwsgbjU73AoDyOQ8=
=Z2aZ
-----END PGP SIGNATURE-----

From woodbri at swoodbridge.com  Fri Apr 11 10:17:19 2008
From: woodbri at swoodbridge.com (Stephen Woodbridge)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Neutral theme for OL
In-Reply-To: <47FF6E9E.40800@makina-corpus.com>
References: <47FF4F4A.1060507@tmapy.cz> <47FF6E9E.40800@makina-corpus.com>
Message-ID: <47FF72EF.80502@swoodbridge.com>

Sylvain,

Very nice work! Thank you for sharing. I really like the look. I hope 
you and others will create other themes so that we have a small 
collection of them available.

Are you contributing this to OpenLayers for other to use?

You might want to change the blue field around the overview map to 
something more Neutral also.

Best regards,
   -Stephen Woodbridge

Sylvain Beorchia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> 
> For those interested, i made a custom theme for OL, in white/grey
> colors. Neutral theme.
> You may see it on my sandbox :
> 
> http://dev.openlayers.org/sandbox/sbeorchia/openlayers/examples/controls.html
> 
> 
> 
> 
> - --
> Sylvain Beorchia, d?veloppeur SIG
> MAKINA CORPUS - www.makina-corpus.com
> T : +33 (0) 1 44 82 00 80 / F : +33 (0) 1 49 29 02 05
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFH/26eit+Ro3cR7XYRAiaNAJ4ghMc2rVhBwzkQkK+/oA1Gzo0uEQCeKHc8
> PvAQ9laUwsgbjU73AoDyOQ8=
> =Z2aZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


From sylvain.beorchia at makina-corpus.com  Fri Apr 11 10:44:39 2008
From: sylvain.beorchia at makina-corpus.com (Sylvain Beorchia)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Neutral theme for OL
In-Reply-To: <47FF72EF.80502@swoodbridge.com>
References: <47FF4F4A.1060507@tmapy.cz> <47FF6E9E.40800@makina-corpus.com>
	<47FF72EF.80502@swoodbridge.com>
Message-ID: <47FF7957.1050904@makina-corpus.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen,

Thanks.
Yes i'm contributing this for other to use.
OverviewMap style is changed now.



Stephen Woodbridge a ?crit :
> Sylvain,
> 
> Very nice work! Thank you for sharing. I really like the look. I hope 
> you and others will create other themes so that we have a small 
> collection of them available.
> 
> Are you contributing this to OpenLayers for other to use?
> 
> You might want to change the blue field around the overview map to 
> something more Neutral also.
> 
> Best regards,
>    -Stephen Woodbridge
> 
> Sylvain Beorchia wrote:
> Hi,
> 
> 
> For those interested, i made a custom theme for OL, in white/grey
> colors. Neutral theme.
> You may see it on my sandbox :
> 
> http://dev.openlayers.org/sandbox/sbeorchia/openlayers/examples/controls.html
> 
> 
> 
> 
- --
Sylvain Beorchia, d?veloppeur SIG
MAKINA CORPUS - www.makina-corpus.com
T : +33 (0) 1 44 82 00 80 / F : +33 (0) 1 49 29 02 05
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/3lWit+Ro3cR7XYRApFFAKCRsUpvcIlJE76MkM7Xp9SRplfDMgCeKQ5g
d3aPteX8qlF42zbtNl6hoeI=
=Fl89
-----END PGP SIGNATURE-----

From schuyler at nocat.net  Fri Apr 11 09:50:01 2008
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <47FF4F4A.1060507@tmapy.cz>
References: <47FF4F4A.1060507@tmapy.cz>
Message-ID: <1207921801.21049.5.camel@vignesha>

On Fri, 2008-04-11 at 13:45 +0200, Tomas Novotny wrote:
> After spending some time reading about sandboxes, tickets, patches and 
> other OL-dev-kungfu I've tried to create a ticket for my problem:

Thanks for submitting this, Tomas.

We've tried to make the barrier to participation in OpenLayers as low as
possible. If you're finding it difficult to get involved in some way, we
welcome any concrete suggestions on how to streamline the process.

SDE


From schuyler at nocat.net  Fri Apr 11 09:56:18 2008
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
Message-ID: <20080411135618.GZ5298@vishnu.tridity.org>

* On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
> 
> is anyone going to FOSS4G2008 in Capetown?
> 
> Are there plans to do an OpenLayers workshop? I would be interested in
> helping out.

FWIW I plan to be there; would be willing to help organize an OL
workshop if needed.

SDE

From tomas.novotny at tmapy.cz  Fri Apr 11 09:58:27 2008
From: tomas.novotny at tmapy.cz (Tomas Novotny)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers performance
In-Reply-To: <1207921801.21049.5.camel@vignesha>
References: <47FF4F4A.1060507@tmapy.cz> <1207921801.21049.5.camel@vignesha>
Message-ID: <47FF6E83.804@tmapy.cz>

No! I only wanted substantiate that I hadn't posted ticket sooner. I 
have no problem with and quite like this mechanism. Words about kungfu 
were meant "bona fide" ;)

Tomas

Schuyler Erle wrote:
> On Fri, 2008-04-11 at 13:45 +0200, Tomas Novotny wrote:
>> After spending some time reading about sandboxes, tickets, patches and 
>> other OL-dev-kungfu I've tried to create a ticket for my problem:
> 
> Thanks for submitting this, Tomas.
> 
> We've tried to make the barrier to participation in OpenLayers as low as
> possible. If you're finding it difficult to get involved in some way, we
> welcome any concrete suggestions on how to streamline the process.
> 
> SDE
> 
> 

From tschaub at openplans.org  Fri Apr 11 10:25:05 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Neutral theme for OL
In-Reply-To: <47FF7957.1050904@makina-corpus.com>
References: <47FF4F4A.1060507@tmapy.cz>
	<47FF6E9E.40800@makina-corpus.com>	<47FF72EF.80502@swoodbridge.com>
	<47FF7957.1050904@makina-corpus.com>
Message-ID: <47FF74C1.1060905@openplans.org>

Hey-

Additional themes would make great addins.  As you create new themes, if 
you encounter anything that would be more easily styled in CSS, please 
create patches for the trunk.  If you can collect CSS and images 
together in a theme, please contribute it as an addin.

http://trac.openlayers.org/wiki/Addins

Tim

Sylvain Beorchia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen,
> 
> Thanks.
> Yes i'm contributing this for other to use.
> OverviewMap style is changed now.
> 
> 
> 
> Stephen Woodbridge a ?crit :
>> Sylvain,
>>
>> Very nice work! Thank you for sharing. I really like the look. I hope 
>> you and others will create other themes so that we have a small 
>> collection of them available.
>>
>> Are you contributing this to OpenLayers for other to use?
>>
>> You might want to change the blue field around the overview map to 
>> something more Neutral also.
>>
>> Best regards,
>>    -Stephen Woodbridge
>>
>> Sylvain Beorchia wrote:
>> Hi,
>>
>>
>> For those interested, i made a custom theme for OL, in white/grey
>> colors. Neutral theme.
>> You may see it on my sandbox :
>>
>> http://dev.openlayers.org/sandbox/sbeorchia/openlayers/examples/controls.html
>>
>>
>>
>>
> - --
> Sylvain Beorchia, d?veloppeur SIG
> MAKINA CORPUS - www.makina-corpus.com
> T : +33 (0) 1 44 82 00 80 / F : +33 (0) 1 49 29 02 05
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFH/3lWit+Ro3cR7XYRApFFAKCRsUpvcIlJE76MkM7Xp9SRplfDMgCeKQ5g
> d3aPteX8qlF42zbtNl6hoeI=
> =Fl89
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,47ff6b09304167180515871!
> 


From pspencer at dmsolutions.ca  Fri Apr 11 18:23:21 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Patch for a ka-Map cached layer
In-Reply-To: <16623702.post@talk.nabble.com>
References: <16623387.post@talk.nabble.com>
	<20217482-4FA9-4F65-919B-E4D883B2DBCB@dmsolutions.ca>
	<16623702.post@talk.nabble.com>
Message-ID: <53D0E841-B8A5-4869-860E-A2BA423F20E6@dmsolutions.ca>


On 10-Apr-08, at 10:05 PM, Pedro Simonetti wrote:
> Hey Paul,
>
> Thanks for your response.
>
> Just to make it clear, so the structure [1] is the best one (one more
> directory level)?
>
> [1] var/cache/World/50000/Group_Name/def/t-440320/l20480
> [2] var/cache/World/50000/Group_Name/def/t-440320l20480
>
> If so, I'll have to make this little modifications in the patches/ 
> files I've
> sended here, and in the earlier post. But this is easy, just confirm  
> if the
> first one is the best.


The first one is better than the second one for sure.  I wouldn't go  
so far as to say it is the best ;)

Cheers

Paul

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From crschmidt at metacarta.com  Sat Apr 12 11:54:53 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Project this morning: Canvas Renderer
Message-ID: <20080412155453.GA23823@metacarta.com>

http://trac.openlayers.org/ticket/1512 has this morning's project, a
canvas-based Renderer for OpenLayers vector layers. 

For comparison:
  * Canvas: http://crschmidt.net/mapping/choropleth-canvas.html
  * SVG: http://crschmidt.net/mapping/choropleth.html

(If this isn't available,
http://dev.openlayers.org/sandbox/crschmidt/canvas-renderer/examples/canvas-renderer.html
is/should be.)

In Firefox 2, there will probably be an obvious difference in rendering
speed. (there is also an obvious difference in functionality: the former
has no hover-select control, for performance reasons.)

>From the ticket: 

====

It implements feature selection by looping over its internal list of
features, and doing intersection queries. Depending on the browser, this
may or may not be reasonable. One thing that this behavior suggests is
that the standard Feature Handler should perhaps be informed whether it
is being used as a 'hover' handler: if it isn't, it shouldn't bother
doing the (now somewhat expensive) getFeatureIdFromEvent check on
mousemove as it currently does.

For browsing somewhat static vector data, this Renderer is quite
effective, especially for browsers where SVG support is less fast: FF2,
for example, gets to be much more usable on whole-world country borders
maps that are currently being tossed about.

Includes support for stroke/fill width/color/opacity, externalGraphic,
point/line/linearring/polygon and collections thereof. 

====

I've tested it in Safari 3.1, FF2, and Opera 9.5 on Mac. (IE still falls
back to the VML renderer in all situations so far as I'm aware.)

I find the most difference in Firefox 2, where the large DOM created by
the SVG document tends to make interacting with the map a painful
process. Of note, the entire canvas redraws on zoom/dragend/etc., so
there is a definite performance hit there, but even with 400 relatively 
complex features, it's only approximately a half second to redraw all of
the polygons, which is pretty impressive, in my opinion. 

The code is avaialble in #1512, or in the canvas-renderer sandbox, if
you're more comfortable with SVN than 'patch'.
http://svn.openlayers.org/sandbox/crschmidt/canvas-renderer/

Feedback gladly accepted.

Regards,
-- 
Christopher Schmidt
MetaCarta

From eric.c2c at gmail.com  Sun Apr 13 10:07:58 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] 0.2 doc
Message-ID: <5ec103de0804130707s7a79a74cw9a4734cdecbf7354@mail.gmail.com>

Hello all

In preparation for the 0.2 release, I worked on the wiki
documentation. Concretely, I rewrote the HowToInstall page.

See <http://trac.mapfish.org/trac/mapfish/wiki/HowToInstallNew>.

Once deemed ok, this page will be renamed HowToInstall. I will also
modify our main wiki page to make sure someone who wants to install
won't be confused and will directly go to the appropriate doc.

Comments welcome,

--
Eric

From eric.c2c at gmail.com  Sun Apr 13 10:09:16 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] 0.2 doc
In-Reply-To: <5ec103de0804130707s7a79a74cw9a4734cdecbf7354@mail.gmail.com>
References: <5ec103de0804130707s7a79a74cw9a4734cdecbf7354@mail.gmail.com>
Message-ID: <5ec103de0804130709p722b7ac4n7f21228fa83083bc@mail.gmail.com>

Argh, sorry. This email was meant to go dev@mapfish.org. It's the
second time I make this mistake. I'll try to be more careful in the
future.



On Sun, Apr 13, 2008 at 4:07 PM, Eric Lemoine <eric.c2c@gmail.com> wrote:
> Hello all
>
>  In preparation for the 0.2 release, I worked on the wiki
>  documentation. Concretely, I rewrote the HowToInstall page.
>
>  See <http://trac.mapfish.org/trac/mapfish/wiki/HowToInstallNew>.
>
>  Once deemed ok, this page will be renamed HowToInstall. I will also
>  modify our main wiki page to make sure someone who wants to install
>  won't be confused and will directly go to the appropriate doc.
>
>  Comments welcome,
>
>  --
>  Eric
>

From eric.c2c at gmail.com  Sun Apr 13 10:20:12 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Project this morning: Canvas Renderer
In-Reply-To: <20080412155453.GA23823@metacarta.com>
References: <20080412155453.GA23823@metacarta.com>
Message-ID: <5ec103de0804130720o12afede0u68d6f2c3a374ac0f@mail.gmail.com>

Hi Chris,

Thanks for this work and early release. One comment below.

On Sat, Apr 12, 2008 at 5:54 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
>  It implements feature selection by looping over its internal list of
>  features, and doing intersection queries.

Given the potential performance problem this method brings, do we
still plan to generalize its use to solve the "feature selection with
multiple vector layers" issue? Maybe the performance could be made
better using some geo index algorithm. Opinions on that?

Cheers,

--
Eric

From arnd.wippermann at web.de  Sun Apr 13 16:10:13 2008
From: arnd.wippermann at web.de (Arnd Wippermann)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [OpenLayers-Users] Delete Feature
In-Reply-To: <BAY102-W2933EBF323399C532ABE6DCCEF0@phx.gbl>
References: <BAY102-W2933EBF323399C532ABE6DCCEF0@phx.gbl>
Message-ID: <16667351.post@talk.nabble.com>


Hi,

i have enhanced the ModifyFeature Control, so that I can delete a feature
with the key 'k' like kill.

OpenLayers.Control.ModifyFeature.prototype.deleteCodes = [46, 100, 107]; 
//Backspace, d, k
OpenLayers.Control.ModifyFeature.prototype.handleKeypress = function(code) {

...
...
...

        else if(this.feature && OpenLayers.Util.indexOf(this.deleteCodes,
code) != -1 && code == 107)
        {
            var obj = this.feature;
            var lyr = obj.layer;
            this.unselectFeature(obj);
            lyr.removeFeatures(obj);
            msg ="201:" + code;
        }
        //alert(msg);
}

Arnd Wippermann
http://gis.ibbeck.de/ginfo/


Benoit PESTY wrote:
> 
> 
> Hello,
> 
> I've discovered that my problem is link with the presence of the
> "ModifyFeature" control that changes the behaviour of the Select control.
> 
> I'm a bit lost with these controls and the removeFeatures/ eraseFeatures /
> destroyFeatures methods of the Vector class.
> 
> Does someone have a clean example of how to create an Editing Toolbar with
> :
> - The create point / line / polygone buttons
> - A Delete Feature button
> - A Modify Feature button
> 
> Thanks,
> 
> Tchule.
> 
> _________________________________________________________________
> Use video conversation to talk face-to-face with Windows Live Messenger.
> http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> 

-- 
View this message in context: http://www.nabble.com/-OpenLayers-Users--Delete-Feature-tp16628555p16667351.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From crschmidt at metacarta.com  Sun Apr 13 22:15:16 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Project this morning: Canvas Renderer
In-Reply-To: <5ec103de0804130720o12afede0u68d6f2c3a374ac0f@mail.gmail.com>
References: <20080412155453.GA23823@metacarta.com>
	<5ec103de0804130720o12afede0u68d6f2c3a374ac0f@mail.gmail.com>
Message-ID: <20080414021516.GA20046@metacarta.com>

On Sun, Apr 13, 2008 at 04:20:12PM +0200, Eric Lemoine wrote:
> Hi Chris,
> 
> Thanks for this work and early release. One comment below.
> 
> On Sat, Apr 12, 2008 at 5:54 PM, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
> >  It implements feature selection by looping over its internal list of
> >  features, and doing intersection queries.
> 
> Given the potential performance problem this method brings, do we
> still plan to generalize its use to solve the "feature selection with
> multiple vector layers" issue? Maybe the performance could be made
> better using some geo index algorithm. Opinions on that?

My hope is that:
 * Our current SoC proposal for work in this area is accepted
 * Our SoC student finds a magical solution :)

More seriously, I think that the use case of "whole world in vectors"
and the use case of "I've got 3 point layers with 20 points each" are
radically different: the former is not just hundreds, but thousands, of
times more expensive.

A point-based intersection test with 150 features was able to execute
in only a handful of milliseconds, meaning that it could likely be a
realistic choice for people who need that kind of behavior. 

It was always my understanding that doing intersection-based selections
would be more expensive than determining the feature from the event
directly: the performance lost here didn't surprise me, but it is my
hope that there is some improvement that can be done to improve the
peformance, and that we can make use of SoC to do real investigation
into answering the questions related to it.

Regards,
-- 
Christopher Schmidt
MetaCarta

From tchule at hotmail.com  Mon Apr 14 08:15:52 2008
From: tchule at hotmail.com (Benoit PESTY)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] [OpenLayers-Users] Delete Feature
Message-ID: <BAY102-W1170CE396AC958511C792BCCE80@phx.gbl>


Hello,

I've mixed the mailing lists, I'm lost in my own mails, sorry for the disturbance.

Thanks to your example Arnd, I've come up with an ugly solution to my problem.

I've changed my delete method like this:
/**
 * Delete a feature
 */
function deleteFeature(feature) {
    modifyTool.unselectFeature(feature);   // modifyTool is my ModifyFeature Control 
    getEditableLayer().removeFeatures(feature);
}

But it's not very satisfying. It seems that the ModifyFeature control register the "featureselected" event on the layer and generate some temporary vertices event is the control should be disabled (in the toolbar it is toogled off). The cleaner solution would be to generate theses vertices only the the control is on.

Tchule.

--------------------------------------------------------------------------------------------------------------------------------------------
Hi,

i have enhanced the ModifyFeature Control, so that I can delete a feature
with the key 'k' like kill.

OpenLayers.Control.ModifyFeature.prototype.deleteCodes = [46, 100, 107]; 
//Backspace, d, k
OpenLayers.Control.ModifyFeature.prototype.handleKeypress = function(code) {

...
...
...

        else if(this.feature && OpenLayers.Util.indexOf(this.deleteCodes,
code) != -1 && code == 107)
        {
            var obj = this.feature;
            var lyr = obj.layer;
            this.unselectFeature(obj);
            lyr.removeFeatures(obj);
            msg ="201:" + code;
        }
        //alert(msg);
}

Arnd Wippermann
http://gis.ibbeck.de/ginfo/


> Hello,
> 
> I've discovered that my problem is link with the presence of the
> "ModifyFeature" control that changes the behaviour of the Select control.
> 
> I'm a bit lost with these controls and the removeFeatures/ eraseFeatures /
> destroyFeatures methods of the Vector class.
> 
> Does someone have a clean example of how to create an Editing Toolbar with
> :
> - The create point / line / polygone buttons
> - A Delete Feature button
> - A Modify Feature button
> 
> Thanks,



    From: tchule@hotmail.com
    To: users@openlayers.org
    Subject: Delete Feature
    Date: Mon, 7 Apr 2008 15:36:30 +0000

    Hello,

    I have a stupid error when trying to delete a vector feature. I've updated OpenLayers from 2.5 to 2.6 (latest from trunk) and when trying to delete a feature I have the corners of the polygon that stay on the map.

    I've added a control like this :

    // Delete feature
    var deleteTool = new OpenLayers.Control.SelectFeature(layer_vector,
    {
               onSelect:deleteFeature,
    });

    And the called method is like this :
    function deleteFeature(feature) {
        getEditableLayer().removeFeatures(feature);
    }


    The problem seems to be that when getting the vector layer (thru the getLayersByName() method) the feature is set to "modification mode".

    I've tried to look around for the "renderIntent" property of the selectfeature control but I don't know the clean way to use it.

    Thanks,

    Benoit Pesty




_________________________________________________________________
More immediate than e-mail? Get instant access with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080414/e5523df8/attachment.html
From euzuro at gmail.com  Mon Apr 14 14:05:59 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] reminder: vote on OL SoC proposals
Message-ID: <6ae3fb590804141105j58f0a049t9de49afe9c6f0cef@mail.gmail.com>

For those of you who are interested in the google summer of code
projects related to OpenLayers,
this is a reminder to vote for the applications that you like best.

Chris Schmidt has volunteered to be the OL representative to OSGEO,
who will be holding a
meeting tomorrow (tuesday) to vote on which projects to take on.

Erik

http://code.google.com/soc/2008/osgeo/open.html

From tschaub at openplans.org  Mon Apr 14 19:46:47 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
Message-ID: <4803ECE7.5000206@openplans.org>

Hey-

Some may have already seen the proposal for new vector layer behavior.
http://trac.openlayers.org/wiki/Proposal/VectorBehavior

This week, I'll be working on implementing a bit of this new design. 
I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
smartish BBOX strategy.

I've started putting stuff up in an "almanac" sandbox.  The one example 
that shows it wired together is not that impressive - but it represents 
a new design for giving vector layers behavior.

http://dev.openlayers.org/sandbox/topp/almanac/examples/vector2.html

I appreciate any ideas on the work.  I've got a deadline to get this 
working by next Monday - so it will be hasty work for a while.

http://trac.openlayers.org/log/sandbox/topp/almanac/

I've also refactored the WFS stuff into a WFS protocol.  This is 
completely untested and expected not to work currently.  If anybody is 
interested in picking that up, sbenthall will be working on it this week 
as well.

Tim

From crschmidt at metacarta.com  Mon Apr 14 22:02:13 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <4803ECE7.5000206@openplans.org>
References: <4803ECE7.5000206@openplans.org>
Message-ID: <20080415020213.GA9233@metacarta.com>

On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
> Hey-
> 
> Some may have already seen the proposal for new vector layer behavior.
> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
> 
> This week, I'll be working on implementing a bit of this new design. 
> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
> smartish BBOX strategy.

Thanks for the email letting us know what's up.

Out of curiosity: some Protocols seem likely to be 'trapped' within a
single Format. I'm assuming that you don't see any problem with that, so
long as it is sufficiently documented. I'm asking only because the
majority of protocols seem to clearly be in a position where they'll be 
able to cope with many formats -- WFS read support, AtomPub support,
etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
a specific Format. Does this make sense? Is a format-specific protocol
still a protocol? (I think yes.) 

> I've started putting stuff up in an "almanac" sandbox.  The one example 
> that shows it wired together is not that impressive - but it represents 
> a new design for giving vector layers behavior.
> 
> http://dev.openlayers.org/sandbox/topp/almanac/examples/vector2.html
> 
> I appreciate any ideas on the work.  I've got a deadline to get this 
> working by next Monday - so it will be hasty work for a while.
> 
> http://trac.openlayers.org/log/sandbox/topp/almanac/

I'm assuming that in the meantime you'd primarily like committing to be
held to topp people without prior discussion: I'm hacking a bit in SVK,
and when you guys pass your deadline, I hope to have some code
(unrelated to your current work) to toss back in the sandbox, so looking
forward to helping from afar in the meantime.

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Tue Apr 15 01:51:35 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <20080415020213.GA9233@metacarta.com>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
Message-ID: <20080415055135.GA12446@metacarta.com>

On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
> On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
> > Hey-
> > 
> > Some may have already seen the proposal for new vector layer behavior.
> > http://trac.openlayers.org/wiki/Proposal/VectorBehavior
> > 
> > This week, I'll be working on implementing a bit of this new design. 
> > I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
> > smartish BBOX strategy.
> 
> Thanks for the email letting us know what's up.
> 
> Out of curiosity: some Protocols seem likely to be 'trapped' within a
> single Format. I'm assuming that you don't see any problem with that, so
> long as it is sufficiently documented. I'm asking only because the
> majority of protocols seem to clearly be in a position where they'll be 
> able to cope with many formats -- WFS read support, AtomPub support,
> etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
> a specific Format. Does this make sense? Is a format-specific protocol
> still a protocol? (I think yes.) 

Alright, based on my assumption, I've gone ahead and implemented Google
Gears and HTML5 Local Storage support.
http://crschmidt.net/mapping/localdb/ . Patch is at
http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
guys are done on your push, let me know, and we can talk about the best
way to integrate.

This demo uses the local database in your browser to store features.
read(), create(), update(), delete() are committed: my assumption at
this point is that commit() will eventually be implemented on the base
Protocol() class, so I didn't bother to implement that method.  

I would not recommend anyone using this code for long term anything at
the moment, since at the very least there is an obvious use case for a
four-tuple based 'bbox' query, but it was a way to get a quick proof of
concept up in a night.

Regards,
-- 
Christopher Schmidt
MetaCarta

From zac.spitzer at gmail.com  Tue Apr 15 01:58:01 2008
From: zac.spitzer at gmail.com (Zac Spitzer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <20080415055135.GA12446@metacarta.com>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
	<20080415055135.GA12446@metacarta.com>
Message-ID: <7a85053e0804142258q4d95069dwf66ad17b10988f10@mail.gmail.com>

Really cool stuff :)

On Tue, Apr 15, 2008 at 3:51 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
>  > On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
>  > > Hey-
>  > >
>  > > Some may have already seen the proposal for new vector layer behavior.
>  > > http://trac.openlayers.org/wiki/Proposal/VectorBehavior
>  > >
>  > > This week, I'll be working on implementing a bit of this new design.
>  > > I'm focussed on an AtomPub protocol, an Atom format, and a somewhat
>  > > smartish BBOX strategy.
>  >
>  > Thanks for the email letting us know what's up.
>  >
>  > Out of curiosity: some Protocols seem likely to be 'trapped' within a
>  > single Format. I'm assuming that you don't see any problem with that, so
>  > long as it is sufficiently documented. I'm asking only because the
>  > majority of protocols seem to clearly be in a position where they'll be
>  > able to cope with many formats -- WFS read support, AtomPub support,
>  > etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
>  > a specific Format. Does this make sense? Is a format-specific protocol
>  > still a protocol? (I think yes.)
>
>  Alright, based on my assumption, I've gone ahead and implemented Google
>  Gears and HTML5 Local Storage support.
>  http://crschmidt.net/mapping/localdb/ . Patch is at
>  http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
>  guys are done on your push, let me know, and we can talk about the best
>  way to integrate.
>
>  This demo uses the local database in your browser to store features.
>  read(), create(), update(), delete() are committed: my assumption at
>  this point is that commit() will eventually be implemented on the base
>  Protocol() class, so I didn't bother to implement that method.
>
>  I would not recommend anyone using this code for long term anything at
>  the moment, since at the very least there is an obvious use case for a
>  four-tuple based 'bbox' query, but it was a way to get a quick proof of
>  concept up in a night.
>
>
>
>  Regards,
>  --
>  Christopher Schmidt
>  MetaCarta
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>



-- 
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168

From eric.c2c at gmail.com  Tue Apr 15 05:07:47 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <4803ECE7.5000206@openplans.org>
References: <4803ECE7.5000206@openplans.org>
Message-ID: <5ec103de0804150207m3687a30ane9441c9e7cd8c0e@mail.gmail.com>

On Tue, Apr 15, 2008 at 1:46 AM, Tim Schaub <tschaub@openplans.org> wrote:
> Hey-
>
>  Some may have already seen the proposal for new vector layer behavior.
>  http://trac.openlayers.org/wiki/Proposal/VectorBehavior
>
>  This week, I'll be working on implementing a bit of this new design.
>  I'm focussed on an AtomPub protocol, an Atom format, and a somewhat
>  smartish BBOX strategy.

Great! I've also started working on these Protocol ideas. I even
created a elemoine/protocol sandbox for that. So I'm definitely very
interested in collaborating on this.

I went over your code and here are preliminary comments:

The protocol subclasses have a layer property. Is this a temporary
thing or do you think of leaving this as is? In my opinion, a protocol
should be independent of the layer. For example you may want to use a
protocol just to read features and do things with these features that
aren't related to a layer (e.g. stash these features in a grid). As I
understand it, the layer is used as a common object for accessing the
strategy and the format. Don't you think we could make things more
separate?

--
Eric

From eric.c2c at gmail.com  Tue Apr 15 05:14:06 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <20080415055135.GA12446@metacarta.com>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
	<20080415055135.GA12446@metacarta.com>
Message-ID: <5ec103de0804150214t6bb502c7re3f0c36abb3bebbf@mail.gmail.com>

On Tue, Apr 15, 2008 at 7:51 AM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
> [...]
>  Alright, based on my assumption, I've gone ahead and implemented Google
>  Gears and HTML5 Local Storage support.

Really cool.

>  http://crschmidt.net/mapping/localdb/ . Patch is at
>  http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
>  guys are done on your push, let me know, and we can talk about the best
>  way to integrate.

I'd like that we start putting all these protocol-related bits in a
common sandbox. AFAIU the topp/almanac sandbox is kinda short-term. So
what about creating sandbox/protocol for gathering protocol-related
stuff: Tim's bits + Chris' + mine + others'.

--
Eric

From tschaub at openplans.org  Tue Apr 15 05:26:43 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <5ec103de0804150214t6bb502c7re3f0c36abb3bebbf@mail.gmail.com>
References: <4803ECE7.5000206@openplans.org>	
	<20080415020213.GA9233@metacarta.com>	
	<20080415055135.GA12446@metacarta.com>
	<5ec103de0804150214t6bb502c7re3f0c36abb3bebbf@mail.gmail.com>
Message-ID: <480474D3.2030205@openplans.org>

Hey-

Eric Lemoine wrote:
> On Tue, Apr 15, 2008 at 7:51 AM, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
>> On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
>> [...]
>>  Alright, based on my assumption, I've gone ahead and implemented Google
>>  Gears and HTML5 Local Storage support.
> 
> Really cool.
> 
>>  http://crschmidt.net/mapping/localdb/ . Patch is at
>>  http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
>>  guys are done on your push, let me know, and we can talk about the best
>>  way to integrate.
> 
> I'd like that we start putting all these protocol-related bits in a
> common sandbox. AFAIU the topp/almanac sandbox is kinda short-term. So
> what about creating sandbox/protocol for gathering protocol-related
> stuff: Tim's bits + Chris' + mine + others'.

Yeah, I agree.  A common dev spot will be good.  My work is currently 
driven by a near-term deadline.  I think it makes sense to throw 
together this implementation and then back up and talk about design.

Tim

> 
> --
> Eric
> 
> !DSPAM:4033,480471e4207207180515871!
> 


From tschaub at openplans.org  Tue Apr 15 06:21:06 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <20080415020213.GA9233@metacarta.com>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
Message-ID: <48048192.90005@openplans.org>

Christopher Schmidt wrote:
> On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
>> Hey-
>>
>> Some may have already seen the proposal for new vector layer behavior.
>> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
>>
>> This week, I'll be working on implementing a bit of this new design. 
>> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
>> smartish BBOX strategy.
> 
> Thanks for the email letting us know what's up.
> 
> Out of curiosity: some Protocols seem likely to be 'trapped' within a
> single Format. I'm assuming that you don't see any problem with that, so
> long as it is sufficiently documented. I'm asking only because the
> majority of protocols seem to clearly be in a position where they'll be 
> able to cope with many formats -- WFS read support, AtomPub support,
> etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
> a specific Format. Does this make sense? Is a format-specific protocol
> still a protocol? (I think yes.) 

Yeah, this seems unavoidable.

After a bit of discussion with Eric this morning, we came up with a 
cleaner design.  A protocol knows only about format (not layer).  A 
strategy knows about layer.  A strategy can be used to trigger requests 
with a format - and the strategy supplies callbacks.  In the case of 
read, the strategy callback expects to receive a list of features.

All a moving target at this point.  Good to have discussion on what 
things should look like.

Tim

> 
>> I've started putting stuff up in an "almanac" sandbox.  The one example 
>> that shows it wired together is not that impressive - but it represents 
>> a new design for giving vector layers behavior.
>>
>> http://dev.openlayers.org/sandbox/topp/almanac/examples/vector2.html
>>
>> I appreciate any ideas on the work.  I've got a deadline to get this 
>> working by next Monday - so it will be hasty work for a while.
>>
>> http://trac.openlayers.org/log/sandbox/topp/almanac/
> 
> I'm assuming that in the meantime you'd primarily like committing to be
> held to topp people without prior discussion: I'm hacking a bit in SVK,
> and when you guys pass your deadline, I hope to have some code
> (unrelated to your current work) to toss back in the sandbox, so looking
> forward to helping from afar in the meantime.
> 
> Regards,


From tschaub at openplans.org  Tue Apr 15 06:31:34 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <20080415055135.GA12446@metacarta.com>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
	<20080415055135.GA12446@metacarta.com>
Message-ID: <48048406.9020108@openplans.org>

Hey-

Christopher Schmidt wrote:
> On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
>> On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
>>> Hey-
>>>
>>> Some may have already seen the proposal for new vector layer behavior.
>>> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
>>>
>>> This week, I'll be working on implementing a bit of this new design. 
>>> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
>>> smartish BBOX strategy.
>> Thanks for the email letting us know what's up.
>>
>> Out of curiosity: some Protocols seem likely to be 'trapped' within a
>> single Format. I'm assuming that you don't see any problem with that, so
>> long as it is sufficiently documented. I'm asking only because the
>> majority of protocols seem to clearly be in a position where they'll be 
>> able to cope with many formats -- WFS read support, AtomPub support,
>> etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
>> a specific Format. Does this make sense? Is a format-specific protocol
>> still a protocol? (I think yes.) 
> 
> Alright, based on my assumption, I've gone ahead and implemented Google
> Gears and HTML5 Local Storage support.
> http://crschmidt.net/mapping/localdb/ . Patch is at
> http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
> guys are done on your push, let me know, and we can talk about the best
> way to integrate.
> 

Looks nice.  I really want to make sure we get this right before being 
stuck with any one design.  The more implementations the better - as 
long as nobody is promising *anybody* about things being set in stone.

Perhaps SQL is a better protocol name (just a bit closer to "protocol" 
than HTML5).

Tim

> This demo uses the local database in your browser to store features.
> read(), create(), update(), delete() are committed: my assumption at
> this point is that commit() will eventually be implemented on the base
> Protocol() class, so I didn't bother to implement that method.  
> 
> I would not recommend anyone using this code for long term anything at
> the moment, since at the very least there is an obvious use case for a
> four-tuple based 'bbox' query, but it was a way to get a quick proof of
> concept up in a night.
> 
> Regards,


From crschmidt at metacarta.com  Tue Apr 15 07:24:03 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <48048406.9020108@openplans.org>
References: <4803ECE7.5000206@openplans.org>
	<20080415020213.GA9233@metacarta.com>
	<20080415055135.GA12446@metacarta.com>
	<48048406.9020108@openplans.org>
Message-ID: <20080415112403.GA16557@metacarta.com>

On Tue, Apr 15, 2008 at 04:31:34AM -0600, Tim Schaub wrote:
> Hey-
> 
> Christopher Schmidt wrote:
> > On Mon, Apr 14, 2008 at 10:02:13PM -0400, Christopher Schmidt wrote:
> >> On Mon, Apr 14, 2008 at 05:46:47PM -0600, Tim Schaub wrote:
> >>> Hey-
> >>>
> >>> Some may have already seen the proposal for new vector layer behavior.
> >>> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
> >>>
> >>> This week, I'll be working on implementing a bit of this new design. 
> >>> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
> >>> smartish BBOX strategy.
> >> Thanks for the email letting us know what's up.
> >>
> >> Out of curiosity: some Protocols seem likely to be 'trapped' within a
> >> single Format. I'm assuming that you don't see any problem with that, so
> >> long as it is sufficiently documented. I'm asking only because the
> >> majority of protocols seem to clearly be in a position where they'll be 
> >> able to cope with many formats -- WFS read support, AtomPub support,
> >> etc. -- while a minority -- ESRI-REST, WFS-T/write, etc. -- are tied to
> >> a specific Format. Does this make sense? Is a format-specific protocol
> >> still a protocol? (I think yes.) 
> > 
> > Alright, based on my assumption, I've gone ahead and implemented Google
> > Gears and HTML5 Local Storage support.
> > http://crschmidt.net/mapping/localdb/ . Patch is at
> > http://crschmidt.net/~crschmidt/localdb.patch ; it's in SVK. When you
> > guys are done on your push, let me know, and we can talk about the best
> > way to integrate.
> > 
> 
> Looks nice.  I really want to make sure we get this right before being 
> stuck with any one design.  The more implementations the better - as 
> long as nobody is promising *anybody* about things being set in stone.
> 
> Perhaps SQL is a better protocol name (just a bit closer to "protocol" 
> than HTML5).

Yeah; I realized that after I wrote it :) Then we'd have various
implemenetations: SQL.HTML5/SQL.GoogleGears, maybe? I dunno. There's
definitely a lot of cleanup in this regard: I'm happy to continue
discussing it once you're past your near-term deadline :) 

For now, I think it makes a cool demo regardless.

Regards,
-- 
Christopher Schmidt
MetaCarta

From tschaub at openplans.org  Tue Apr 15 08:37:07 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <4803ECE7.5000206@openplans.org>
References: <4803ECE7.5000206@openplans.org>
Message-ID: <4804A173.3050405@openplans.org>

In case it helps in understanding the design, I'll include a little 
detail on a very simple example here.

http://dev.openlayers.org/sandbox/topp/almanac/examples/v2-fixed-http-gml.html

That example does about the same thing that the gml-layer.html example 
does.  Except it is more verbose.

Instead of creating a layer like:

var layer = new OpenLayers.Layer.GML("GML", "gml/polygon.xml");

The vector behavior example (v2-fixed-http-gml.html) does the following:

var layer = new OpenLayers.Layer.Vector2("GML", {
     strategy: new OpenLayers.Strategy.Fixed(),
     protocol: new OpenLayers.Protocol.HTTP({
         url: "gml/polygon.xml"
     }),
     format: new OpenLayers.Format.GML()
});

Looks horrible, right?  And the example name is so long and tedious as well.

The point is that the existing GML layer wraps up a bunch (well, a bit) 
of vector behavior into a single class.  The GML layer requests all data 
once (that's a strategy), it uses HTTP (that's a protocol), and it 
parses responses as GML (that's a format).

The new design separates strategy, protocol, and format.  A strategy is 
tied to a layer (it has a reference to a layer and can only be used with 
a layer).  A protocol is tied to a format (it has a reference to a 
format).  You can swap out the format for a protocol (in theory) and you 
can use a protocol in the absence of a layer.

The result is that we can use these parts elsewhere.  People can mix and 
match as they like.  We can develop new strategies, protocols, and 
formats independently - assumptions about how they are integrated 
doesn't need to be tied up in a layer.

Then, of course, we can make things convenient again.  The GML layer (if 
there is demand for one) can use a Fixed strategy, an HTTP protocol, and 
a GML format.  The WFS layer can use a BBOX strategy, a WFS protocol, 
and a GML format.  Etc.

Tim

Tim Schaub wrote:
> Hey-
> 
> Some may have already seen the proposal for new vector layer behavior.
> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
> 
> This week, I'll be working on implementing a bit of this new design. 
> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
> smartish BBOX strategy.
> 
> I've started putting stuff up in an "almanac" sandbox.  The one example 
> that shows it wired together is not that impressive - but it represents 
> a new design for giving vector layers behavior.
> 
> http://dev.openlayers.org/sandbox/topp/almanac/examples/vector2.html
> 
> I appreciate any ideas on the work.  I've got a deadline to get this 
> working by next Monday - so it will be hasty work for a while.
> 
> http://trac.openlayers.org/log/sandbox/topp/almanac/
> 
> I've also refactored the WFS stuff into a WFS protocol.  This is 
> completely untested and expected not to work currently.  If anybody is 
> interested in picking that up, sbenthall will be working on it this week 
> as well.
> 
> Tim
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,4803ed6625911804284693!
> 


From eric.c2c at gmail.com  Tue Apr 15 14:49:14 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <4804A173.3050405@openplans.org>
References: <4803ECE7.5000206@openplans.org> <4804A173.3050405@openplans.org>
Message-ID: <5ec103de0804151149u2b67907r3f85ec8bde1ef76b@mail.gmail.com>

Tim,

One comment below.

On Tue, Apr 15, 2008 at 2:37 PM, Tim Schaub <tschaub@openplans.org> wrote:
> [...]
>  The new design separates strategy, protocol, and format.  A strategy is
>  tied to a layer (it has a reference to a layer and can only be used with
>  a layer).

Are layers the only objects that can make use of strategies?

One thing that I don't quite understand is the Strategy API. The wiki
page says that the four methods update, remove, commit and merge are
all API methods. Will the four of them be actually called from outside
the strategy class? A more detailed description of what these methods
do, when they are called, what objects call them, etc. may be useful;
at least it'd be to me.

Thanks,
--
Eric

From eric.c2c at gmail.com  Tue Apr 15 15:00:48 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] LoadingPanel addin
In-Reply-To: <2d1214088c0f91d5806a408f3941bcec@145.50.39.11>
References: <2d1214088c0f91d5806a408f3941bcec@145.50.39.11>
Message-ID: <5ec103de0804151200v688a454ha6caf348172ed52f@mail.gmail.com>

On Mon, Apr 7, 2008 at 1:54 PM, Bart van den Eijnden (OSGIS)
<bartvde@osgis.nl> wrote:
> Thanks Chris,
>
>  the code is now in my sandbox bartvde/loadingpanel:
>
>  http://trac.openlayers.org/changeset/6805
>
>  I would appreciate it if someone could have a look at it to see if it is
>  suitable as an addin.
>
>  The url of the example is:
>  http://dev.openlayers.org/sandbox/bartvde/loadingpanel/examples/loadingpanel.html

Hi Bart,

I did a quick review of your code. This is looking code. So is looking
your example. The loading panel will make a great add'in.

Thanks,

--
Eric

From euzuro at gmail.com  Tue Apr 15 16:39:01 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
Message-ID: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>

Dear dev,

It has been nearly a full week now since we released 2.6 RC2, and
since then, we have gotten no showstopping bug or regression reports.

I hereby call for a vote to make the final release, OpenLayers 2.6

I *believe* that there are maybe a few changes to documentation that
we will want to bring up into the patch, though I may be incorrect
about that. Either way, let's get a show of hands...

cheers,
erik

From schuyler at nocat.net  Tue Apr 15 17:23:00 2008
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
Message-ID: <20080415212300.GD5298@vishnu.tridity.org>

* On 15-Apr-2008 at  1:39PM PDT, Erik Uzureau said:
> Dear dev,
> 
> It has been nearly a full week now since we released 2.6 RC2, and
> since then, we have gotten no showstopping bug or regression reports.
> 
> I hereby call for a vote to make the final release, OpenLayers 2.6

+1. Congrats, everyone.

SDE

From crschmidt at metacarta.com  Tue Apr 15 18:00:50 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
Message-ID: <20080415220050.GA26840@metacarta.com>

On Tue, Apr 15, 2008 at 03:39:01PM -0500, Erik Uzureau wrote:
> Dear dev,
> 
> It has been nearly a full week now since we released 2.6 RC2, and
> since then, we have gotten no showstopping bug or regression reports.
> 
> I hereby call for a vote to make the final release, OpenLayers 2.6
> 
> I *believe* that there are maybe a few changes to documentation that
> we will want to bring up into the patch, though I may be incorrect
> about that. Either way, let's get a show of hands...

I'm against pulling in the comments unless we find another reason to do
an RC3: Frankly (speaking as release manager) I feel unconvinced enough
in my own skill that I feel likely to screw it up if we did it. :)

I'm +1 on calling the current 2.6RC2 the 2.6 Final release. 

Regards,
-- 
Christopher Schmidt
MetaCarta

From sgillies at frii.com  Tue Apr 15 18:14:58 2008
From: sgillies at frii.com (Sean Gillies)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] vector behavior
In-Reply-To: <4803ECE7.5000206@openplans.org>
References: <4803ECE7.5000206@openplans.org>
Message-ID: <480528E2.4060708@frii.com>

Tim Schaub wrote:
> Hey-
> 
> Some may have already seen the proposal for new vector layer behavior.
> http://trac.openlayers.org/wiki/Proposal/VectorBehavior
> 
> This week, I'll be working on implementing a bit of this new design. 
> I'm focussed on an AtomPub protocol, an Atom format, and a somewhat 
> smartish BBOX strategy.
> 
> I've started putting stuff up in an "almanac" sandbox.  The one example 
> that shows it wired together is not that impressive - but it represents 
> a new design for giving vector layers behavior.
> 
> http://dev.openlayers.org/sandbox/topp/almanac/examples/vector2.html
> 
> I appreciate any ideas on the work.  I've got a deadline to get this 
> working by next Monday - so it will be hasty work for a while.
> 
> http://trac.openlayers.org/log/sandbox/topp/almanac/
> 
> I've also refactored the WFS stuff into a WFS protocol.  This is 
> completely untested and expected not to work currently.  If anybody is 
> interested in picking that up, sbenthall will be working on it this week 
> as well.
> 
> Tim

Hi Tim,

I've already submitted Atom and GMLSF formats to the tracker

http://trac.openlayers.org/ticket/1366

As Christopher wrote, they need to properly subclass other formats, but
otherwise I think they are the right way to do Atom + geo. Those formats
are currently employed at http://zcologia.com/kw/demo/map.

Count on me for help with AtomPub.

Sean


From tschaub at openplans.org  Tue Apr 15 18:34:50 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <20080415220050.GA26840@metacarta.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
	<20080415220050.GA26840@metacarta.com>
Message-ID: <48052D8A.3040105@openplans.org>

Christopher Schmidt wrote:
> On Tue, Apr 15, 2008 at 03:39:01PM -0500, Erik Uzureau wrote:
>> Dear dev,
>>
>> It has been nearly a full week now since we released 2.6 RC2, and
>> since then, we have gotten no showstopping bug or regression reports.
>>
>> I hereby call for a vote to make the final release, OpenLayers 2.6
>>
>> I *believe* that there are maybe a few changes to documentation that
>> we will want to bring up into the patch, though I may be incorrect
>> about that. Either way, let's get a show of hands...
> 
> I'm against pulling in the comments unless we find another reason to do
> an RC3: Frankly (speaking as release manager) I feel unconvinced enough
> in my own skill that I feel likely to screw it up if we did it. :)
> 
> I'm +1 on calling the current 2.6RC2 the 2.6 Final release. 

+1.  Bravo.

Tim

> 
> Regards,


From john.frank at metacarta.com  Tue Apr 15 18:36:54 2008
From: john.frank at metacarta.com (John R. Frank)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <20080415220050.GA26840@metacarta.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
	<20080415220050.GA26840@metacarta.com>
Message-ID: <Pine.LNX.4.56.0804151836130.10405@jackson.metacarta.com>

> I'm +1 on calling the current 2.6RC2 the 2.6 Final release.

+1

Thanks for all the great work in this major new release.



John

From pspencer at dmsolutions.ca  Tue Apr 15 19:38:09 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
Message-ID: <F6EF0709-526E-4B1D-AB95-E1828D7A7B2F@dmsolutions.ca>

+1, this is a great release with a ton of functionality!

Paul

On 15-Apr-08, at 4:39 PM, Erik Uzureau wrote:
> I hereby call for a vote to make the final release, OpenLayers 2.6


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From cameron.shorter at gmail.com  Tue Apr 15 19:44:58 2008
From: cameron.shorter at gmail.com (Cameron Shorter)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <Pine.LNX.4.56.0804151836130.10405@jackson.metacarta.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
	<20080415220050.GA26840@metacarta.com>
	<Pine.LNX.4.56.0804151836130.10405@jackson.metacarta.com>
Message-ID: <8fd6e5470804151644r5336bb61q9c1fbe292c40e6d4@mail.gmail.com>

+1 from me too.

On Wed, Apr 16, 2008 at 8:36 AM, John R. Frank <john.frank@metacarta.com> wrote:
> > I'm +1 on calling the current 2.6RC2 the 2.6 Final release.
>
>  +1
>
>  Thanks for all the great work in this major new release.
>
>
>
>  John
>
>
> _______________________________________________
>  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 Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html

From crschmidt at metacarta.com  Tue Apr 15 19:59:38 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
Message-ID: <20080415235938.GA28588@metacarta.com>

On Tue, Apr 15, 2008 at 03:39:01PM -0500, Erik Uzureau wrote:
> I hereby call for a vote to make the final release, OpenLayers 2.6

With unanimous support from John, Paul, Cameron, Myself, Tim, Schuyler,
and Erik, in no particular order, I declare the motion passed, and am
about to make 2.6 the new stable release.

Congrats to all!

Regards,
-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Tue Apr 15 20:41:43 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Final Release
Message-ID: <20080416004143.GA29395@metacarta.com>

The OpenLayers Development Team is proud to announce release of
OpenLayers 2.6.  As of this final release, the OpenLayers 2.6 release
closes 294 outstanding tickets, 75% more than any OpenLayers release to
date. 

The OpenLayers.js hosted at

  <script src="http://openlayers.org/api/OpenLayers.js"></script>

has now been changed to use the 2.6 API.

As always, the source is available at http://openlayers.org/download/.
  
  md5sums:
    ce957a47ad9bc8356d990417d61cc8a4  OpenLayers-2.6.tar.gz
    43c82d5a9ae9e0b18c1fa37a97065e02  OpenLayers-2.6.zip

This is a large release: the largest of any OpenLayers release to date.
This release features a number of major developments, including:
  
  * Integration of the CloudAmber "Google Like" popups for advanced
    visual display of information in popups
    * Resulting improvements throughout all popup code, including
      autosizing popups to the content they contain.
  * Improved panning of commercial layers like Google Maps and Yahoo!
    Maps
  * Animated panning of the map, using OpenLayers.Tween support
  * Layer Image transitions, for keeping images visible when zooming
    to allow smoother transitions
  * Client side reprojection support using built in transformations for
    spherical mercator, or the proj4js library for other projections.
    * Support for reprojecting vector data layers
    * Support for reprojecting user-facing controls like mouseposition
    * Support for programatically reprojecting points and geometries 
  * Improved OpenLayers Styling, including:
    * OpenLayers.Style, OpenLayers.StyleMap, OpenLayers.Rule,
      OpenLayers.Filter support for improved feature-attribute based
      styling
    * SLD read/write support 
  * Support for reading and writing multiple versions of WMC.
  * Improved KML support, including KML styling support.
  * Improved GeoRSS Format support, including GeoRSS GML read support.
  * New ScaleLine Control for displaying visual scale
  * New NavigationHistory control for map history navigation
  * Localization/Better Internationalization support
  * Layer support for MapGuide Open Source 
  * A number of new / improved handlers to make handling user
    interactions easier
     * Handler.Hover
     * Handler.Click
     
A thank you again to all the people who helped to make this release
happen. My earlier post[1] on the topic covers that as well as any
single email can hope to. 

We look forward to your feedback!

[1] http://openlayers.org/pipermail/users/2008-April/005329.html

Regards,

The OpenLayers Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080415/7ee736f2/attachment.bin
From woodbri at swoodbridge.com  Tue Apr 15 21:44:15 2008
From: woodbri at swoodbridge.com (Stephen Woodbridge)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Release 2.6?
In-Reply-To: <20080415235938.GA28588@metacarta.com>
References: <6ae3fb590804151339x22b0eebbx9de5f91736d455b0@mail.gmail.com>
	<20080415235938.GA28588@metacarta.com>
Message-ID: <480559EF.3020408@swoodbridge.com>

Christopher Schmidt wrote:
> On Tue, Apr 15, 2008 at 03:39:01PM -0500, Erik Uzureau wrote:
>> I hereby call for a vote to make the final release, OpenLayers 2.6
> 
> With unanimous support from John, Paul, Cameron, Myself, Tim, Schuyler,
> and Erik, in no particular order, I declare the motion passed, and am
> about to make 2.6 the new stable release.
> 
> Congrats to all!
> 
> Regards,

Yes indeed! Congrats to all on yet another AWESOME release!
I've been play with the various RC and it is very nice.

Many thanks!
   -Steve W

From lancelot at inetnebr.com  Wed Apr 16 01:04:03 2008
From: lancelot at inetnebr.com (Lance Dyas)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Permalink Broken in 2.6
Message-ID: <480588C3.2030100@inetnebr.com>

http://www.dyasdesigns.com/geoxml/navtoolbar.html?zoom=5&lat=45.625&lon=40.5957&layers=B



From kenneth.lind at logica.com  Wed Apr 16 04:34:43 2008
From: kenneth.lind at logica.com (Lind, Kenneth)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Regarding licensing
Message-ID: <C5E4853385FEA64198C3048F718D81171411BA9258@SE-EX007.groupinfra.com>

Hi all.

I am not sure this is the correct list to post this questions but here we go.

I wonder about the licensing of the openlayers for using as part in a commercial portfolio, is there any limits to what we can do with the product regarding using it in customer projects (just to clearify, we don?t intend to sell it as a product, just use it with customer developed solutions)? We will of course take responsibility towards the customer regarding bugs and support as well as giving code back to the project in any way we can. We will also not try to hide the fact that we use openlayers and give credit to the developers of this great solution. Is there anything else that we should be aware of regarding licensing?

We don?t have any problem with the bsd license that I am aware of. I am just curious if there is any additions to this base license.

And as a second question. What are the rules for giving code back to the project? Anything specific we should consider here, since we are a commercial company?

Best Regards
/Kenneth



Kenneth Lind
GIS/ITS Consultant
___________________________________

Logica - Releasing your potential

Box 1938
SE-791 19 Falun
Sweden

T:   +46(0) 243 93 670
M:   +46(0) 76 14 60 572
F:   +46(0) 23 54 850
E:   kenneth.lind@logica.com

www.logica.se
___________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e?mail and any attachment and all copies and inform the sender. Thank you.

From gis at vanbooth.com  Wed Apr 16 06:17:57 2008
From: gis at vanbooth.com (Rob)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Final Release
In-Reply-To: <20080416004143.GA29395@metacarta.com>
References: <20080416004143.GA29395@metacarta.com>
Message-ID: <2a955f950804160317v76a2709aqf3d18a40292e719e@mail.gmail.com>

Great work guys - looking forward to playing with the latest version!

I know its only 9 hours old, but the openlayers.org homepage still refers to
2.5, and I cant figure out a way to login and change it for you ( the
homepage doesnt seem to be part of the wiki?).

On 16/04/2008, Christopher Schmidt <crschmidt@metacarta.com> wrote:
>
> The OpenLayers Development Team is proud to announce release of
> OpenLayers 2.6.  As of this final release, the OpenLayers 2.6 release
> closes 294 outstanding tickets, 75% more than any OpenLayers release to
> date.
>
> The OpenLayers.js hosted at
>
>   <script src="http://openlayers.org/api/OpenLayers.js"></script>
>
> has now been changed to use the 2.6 API.
>
> As always, the source is available at http://openlayers.org/download/.
>
>   md5sums:
>     ce957a47ad9bc8356d990417d61cc8a4  OpenLayers-2.6.tar.gz
>     43c82d5a9ae9e0b18c1fa37a97065e02  OpenLayers-2.6.zip
>
> This is a large release: the largest of any OpenLayers release to date.
> This release features a number of major developments, including:
>
>   * Integration of the CloudAmber "Google Like" popups for advanced
>     visual display of information in popups
>     * Resulting improvements throughout all popup code, including
>       autosizing popups to the content they contain.
>   * Improved panning of commercial layers like Google Maps and Yahoo!
>     Maps
>   * Animated panning of the map, using OpenLayers.Tween support
>   * Layer Image transitions, for keeping images visible when zooming
>     to allow smoother transitions
>   * Client side reprojection support using built in transformations for
>     spherical mercator, or the proj4js library for other projections.
>     * Support for reprojecting vector data layers
>     * Support for reprojecting user-facing controls like mouseposition
>     * Support for programatically reprojecting points and geometries
>   * Improved OpenLayers Styling, including:
>     * OpenLayers.Style, OpenLayers.StyleMap, OpenLayers.Rule,
>       OpenLayers.Filter support for improved feature-attribute based
>       styling
>     * SLD read/write support
>   * Support for reading and writing multiple versions of WMC.
>   * Improved KML support, including KML styling support.
>   * Improved GeoRSS Format support, including GeoRSS GML read support.
>   * New ScaleLine Control for displaying visual scale
>   * New NavigationHistory control for map history navigation
>   * Localization/Better Internationalization support
>   * Layer support for MapGuide Open Source
>   * A number of new / improved handlers to make handling user
>     interactions easier
>      * Handler.Hover
>      * Handler.Click
>
> A thank you again to all the people who helped to make this release
> happen. My earlier post[1] on the topic covers that as well as any
> single email can hope to.
>
> We look forward to your feedback!
>
> [1] http://openlayers.org/pipermail/users/2008-April/005329.html
>
> Regards,
>
> The OpenLayers Team
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIBUtHqjCpmKHia1gRAtG2AJ0UDKNUAdn33oVEMO4GojpGZmEhpQCcCNOK
> MEj9vxhppTH5DlS0JCsBDIk=
> =7dqh
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20080416/30d12fda/attachment.html
From grand.edgemaster at gmail.com  Wed Apr 16 06:24:10 2008
From: grand.edgemaster at gmail.com (Thomas Wood)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Permalink Broken in 2.6
In-Reply-To: <480588C3.2030100@inetnebr.com>
References: <480588C3.2030100@inetnebr.com>
Message-ID: <1e14d5320804160324l58d5f5e2o113797bf51bba6a7@mail.gmail.com>

No, your setCenter call is overriding the permalink, the line should
check whether it is already set with something like
if(!map.getCenter()) map.setCenter(....

On Wed, Apr 16, 2008 at 6:04 AM, Lance Dyas <lancelot@inetnebr.com> wrote:
> http://www.dyasdesigns.com/geoxml/navtoolbar.html?zoom=5&lat=45.625&lon=40.5957&layers=B
>
>
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>



-- 
Regards,
Thomas Wood
(Edgemaster)

From pspencer at dmsolutions.ca  Wed Apr 16 06:37:02 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Regarding licensing
In-Reply-To: <C5E4853385FEA64198C3048F718D81171411BA9258@SE-EX007.groupinfra.com>
References: <C5E4853385FEA64198C3048F718D81171411BA9258@SE-EX007.groupinfra.com>
Message-ID: <65257724-425E-4B68-BB83-BC3C91D10B88@dmsolutions.ca>

Hi Kenneth,

the BSD license is liberal, allowing you to make use of OpenLayers in  
pretty much any way you want.  Giving visible credit to the developers  
is considered polite behaviour, but I think all you are required to do  
is maintain copyright notices for OpenLayers and the other libraries  
it builds on in your code or any portion thereof.

If you wish to contribute to the project, you may complete a  
contributors license agreement found at:

http://trac.openlayers.org/wiki/HowToContribute

Cheers

Paul

On 16-Apr-08, at 4:34 AM, Lind, Kenneth wrote:
> Hi all.
>
> I am not sure this is the correct list to post this questions but  
> here we go.
>
> I wonder about the licensing of the openlayers for using as part in  
> a commercial portfolio, is there any limits to what we can do with  
> the product regarding using it in customer projects (just to  
> clearify, we don?t intend to sell it as a product, just use it with  
> customer developed solutions)? We will of course take responsibility  
> towards the customer regarding bugs and support as well as giving  
> code back to the project in any way we can. We will also not try to  
> hide the fact that we use openlayers and give credit to the  
> developers of this great solution. Is there anything else that we  
> should be aware of regarding licensing?
>
> We don?t have any problem with the bsd license that I am aware of.  
> I am just curious if there is any additions to this base license.
>
> And as a second question. What are the rules for giving code back to  
> the project? Anything specific we should consider here, since we are  
> a commercial company?
>
> Best Regards
> /Kenneth
>
>
>
> Kenneth Lind
> GIS/ITS Consultant
> ___________________________________
>
> Logica - Releasing your potential
>
> Box 1938
> SE-791 19 Falun
> Sweden
>
> T:   +46(0) 243 93 670
> M:   +46(0) 76 14 60 572
> F:   +46(0) 23 54 850
> E:   kenneth.lind@logica.com
>
> www.logica.se
> ___________________________________
> This e-mail and any attachment is for authorised use by the intended  
> recipient(s) only. It may contain proprietary material, confidential  
> information and/or be subject to legal privilege. It should not be  
> copied, disclosed to, retained or used by, any other party. If you  
> are not an intended recipient then please promptly delete this  
> e?mail and any attachment and all copies and inform the sender.  
> Thank you.
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From crschmidt at metacarta.com  Wed Apr 16 06:56:23 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] OpenLayers 2.6 Final Release
In-Reply-To: <2a955f950804160317v76a2709aqf3d18a40292e719e@mail.gmail.com>
References: <20080416004143.GA29395@metacarta.com>
	<2a955f950804160317v76a2709aqf3d18a40292e719e@mail.gmail.com>
Message-ID: <20080416105623.GA5207@metacarta.com>

On Wed, Apr 16, 2008 at 11:17:57AM +0100, Rob wrote:
> Great work guys - looking forward to playing with the latest version!
> 
> I know its only 9 hours old, but the openlayers.org homepage still refers to
> 2.5, and I cant figure out a way to login and change it for you ( the
> homepage doesnt seem to be part of the wiki?).

Nope, it's in SVN. I passed out last night before I finished updating
everything; I've gone ahead and finished up now.

-- Chris

> On 16/04/2008, Christopher Schmidt <crschmidt@metacarta.com> wrote:
> >
> > The OpenLayers Development Team is proud to announce release of
> > OpenLayers 2.6.  As of this final release, the OpenLayers 2.6 release
> > closes 294 outstanding tickets, 75% more than any OpenLayers release to
> > date.
> >
> > The OpenLayers.js hosted at
> >
> >   <script src="http://openlayers.org/api/OpenLayers.js"></script>
> >
> > has now been changed to use the 2.6 API.
> >
> > As always, the source is available at http://openlayers.org/download/.
> >
> >   md5sums:
> >     ce957a47ad9bc8356d990417d61cc8a4  OpenLayers-2.6.tar.gz
> >     43c82d5a9ae9e0b18c1fa37a97065e02  OpenLayers-2.6.zip
> >
> > This is a large release: the largest of any OpenLayers release to date.
> > This release features a number of major developments, including:
> >
> >   * Integration of the CloudAmber "Google Like" popups for advanced
> >     visual display of information in popups
> >     * Resulting improvements throughout all popup code, including
> >       autosizing popups to the content they contain.
> >   * Improved panning of commercial layers like Google Maps and Yahoo!
> >     Maps
> >   * Animated panning of the map, using OpenLayers.Tween support
> >   * Layer Image transitions, for keeping images visible when zooming
> >     to allow smoother transitions
> >   * Client side reprojection support using built in transformations for
> >     spherical mercator, or the proj4js library for other projections.
> >     * Support for reprojecting vector data layers
> >     * Support for reprojecting user-facing controls like mouseposition
> >     * Support for programatically reprojecting points and geometries
> >   * Improved OpenLayers Styling, including:
> >     * OpenLayers.Style, OpenLayers.StyleMap, OpenLayers.Rule,
> >       OpenLayers.Filter support for improved feature-attribute based
> >       styling
> >     * SLD read/write support
> >   * Support for reading and writing multiple versions of WMC.
> >   * Improved KML support, including KML styling support.
> >   * Improved GeoRSS Format support, including GeoRSS GML read support.
> >   * New ScaleLine Control for displaying visual scale
> >   * New NavigationHistory control for map history navigation
> >   * Localization/Better Internationalization support
> >   * Layer support for MapGuide Open Source
> >   * A number of new / improved handlers to make handling user
> >     interactions easier
> >      * Handler.Hover
> >      * Handler.Click
> >
> > A thank you again to all the people who helped to make this release
> > happen. My earlier post[1] on the topic covers that as well as any
> > single email can hope to.
> >
> > We look forward to your feedback!
> >
> > [1] http://openlayers.org/pipermail/users/2008-April/005329.html
> >
> > Regards,
> >
> > The OpenLayers Team
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFIBUtHqjCpmKHia1gRAtG2AJ0UDKNUAdn33oVEMO4GojpGZmEhpQCcCNOK
> > MEj9vxhppTH5DlS0JCsBDIk=
> > =7dqh
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Dev mailing list
> > Dev@openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >
> >

-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Wed Apr 16 07:09:36 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Regarding licensing
In-Reply-To: <C5E4853385FEA64198C3048F718D81171411BA9258@SE-EX007.groupinfra.com>
References: <C5E4853385FEA64198C3048F718D81171411BA9258@SE-EX007.groupinfra.com>
Message-ID: <20080416110936.GC5207@metacarta.com>

On Wed, Apr 16, 2008 at 10:34:43AM +0200, Lind, Kenneth wrote:
> I am not sure this is the correct list to post this questions but here we go.

Close enough. :)

(Caveats: IANAL, but I am kinda the 'legal guy' on the mailing lists.)

> I wonder about the licensing of the openlayers for using as part in a
> commercial portfolio, is there any limits to what we can do with the
> product regarding using it in customer projects (just to clearify, we
> don???t intend to sell it as a product, just use it with customer
> developed solutions)? 

There are two real conditions to using OpenLayers, from the BSD license:
http://openlayers.org/dev/license.txt .

They boil down to: 
 * Include the OpenLayers copyright notice, in the source or in the docs.
   (This is taken care of for you by our build tools.)
 * Don't use MetaCarta's name as an endorsement.    

The rest of the license is just a legal wrapper around these conditions:
there are no limitations as to what you can do beyond that. (This
includes, for example, the outright selling of OpenLayers, rebranding of
OpenLayers, including OpenLayers in any product, etc.) The license is as
open as we can make it: there should be no legal reason why OpenLayers
can't be used in your project.

> We will of course take responsibility towards the customer regarding
> bugs and support as well as giving code back to the project in any way
> we can. We will also not try to hide the fact that we use openlayers
> and give credit to the developers of this great solution. Is there
> anything else that we should be aware of regarding licensing?

All of those are great *social* things to do, but none of it is legally
required by the license: we always appreciate the help, but we accept it
as much because it is offered freely as for any other reason :) 

I agree that all of these things are valuable, and great for the
community, and we very much appreciate them. I look forward to 

> We don???t have any problem with the bsd license that I am aware of. I
> am just curious if there is any additions to this base license.

There is technically speaking, one minor addition to the BSD license:
the bold on http://labs.metacarta.com/license-explanation.html#license
outlines what it is. However, most legal advice on the BSD license
appears to indicate that this technical change (adding these words)
actually doesn't change the meaning of the license in any way: it simply
means that the license explicitly states what is thought by at least
some lawyers to be implicit in the license.

This change should not affect your usage of the library in any way. If
you have concerns about it, I can explain further.

> And as a second question. What are the rules for giving code back to
> the project? Anything specific we should consider here, since we are a
> commercial company?

http://trac.openlayers.org/wiki/HowToContribute has complete
instructions, which apply to corporations as well as individuals.

We look forward to your continued participation in the community!

Regards,
-- 
Christopher Schmidt
MetaCarta

From pedrosimonetti at gmail.com  Wed Apr 16 09:54:13 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Fix for issue #327: ka-Map overlays
In-Reply-To: <16620073.post@talk.nabble.com>
References: <16620073.post@talk.nabble.com>
Message-ID: <5b629bbf0804160654x39326466j3f530e8f99564fed@mail.gmail.com>

Hi folks,

After some discussion with Paul [1]
<http://trac.openlayers.org/changeset/1>about the directory structure
isse, I've made some changes as he suggested.
So, the patch that sould be used is this second version I'm publishing in
the issue tracker [2].

[1] <http://trac.openlayers.org/changeset/1>
http://www.nabble.com/Patch-for-a-ka-Map-cached-layer-tp16623387p16623662.html

 [2] http://trac.openlayers.org/ticket/327

The patch for the KaMapCache layer with the proper modifications comes next.

My best regards,

Pedro Simonetti.

2008/4/10, Pedro Simonetti <pedrosimonetti@gmail.com>:
>
>
> Hi all,
>
> I'm doing an upgrade in the Veracidade project that was initially made
> over
> ka-Map.
> http://www.veracidade.com.br/
>
> Were upgrading the whole project. We're upgrading our imagery database and
> including new featues, so I felt a good step to migrate to OpenLayers,
> giving the benefits OL offers to customization and user interaction.
>
> As every project, we have a limited schedule, but I hope this jorney will
> bring some goodies to the OL community, specially for those using
> OL+ka-Map.
>
> I've made some changes in the OL's ka-Map interface, and I would like to
> share this with you all. I'll break those changes in different threads to
> make it easier to future research.
>
> So here we go. There is a problem in the "tile.php" file (named
> "examples/kamap.txt") related to ka-Map overlays.
> http://trac.openlayers.org/ticket/327
>
> The solution is actually very simple. The code was missing to uppercase
> the
> output format, so if you set your map in .js with "i" equals to "gif", the
> code won't cacth this, and will use de default value from "tile.php"
> configuration section.
>
> I've break this file in two files "tile.php" and "config.php" to allow a
> single configuration file be shared with both "tile.php" and
> "precache.php"
> (I'll discuss prepache changes in another thread).
>
> I'll posting a patch on the tracker for this issue.
>
> Here goes a suggestion. Since there will be 3 different php files related
> to
> ka-Map, I think will be good, to create another directory for those files,
> maybe in "examples/kaMap", for example. I think also that is good to put
> those files named "tile.php.txt", "config.php.txt", and
> "precache.php.txt",
> to a better readibility.
>
> This changes required a little change in KaMap.js, because the constant
> "OpenLayers.Layer.KaMap.DEFAULT_PARAMS" souldn't be used, as the default
> output format is taken from "config.php" file.
>
> So, I'll post in the tracker a separated patch for this.
>
> Here a simple example of creating two ka-Map layers:
>
>   // The output format used will be that informed at "config.php",
>   // since the parameter "i" was not used.
>   var kamap_base = new OpenLayers.Layer.KaMap(
>       "Satellite",
>       "http://www.openlayers.org/world/tile.php",
>       {g: "satellite", map: "world"}
>     );
>
>   // Create an ka-Map overlay layer (using "isBaseLayer: false"). Forces
>   // the output to be a "gif", using the "i" parameter.
>   var kamap_overlay = new OpenLayers.Layer.KaMap(
>       "Streets",
>       "http://www.openlayers.org/world/tile.php",
>       {g: "streets", map: "world", i: "gif"},
>       {isBaseLayer: false}
>     );
>
> regards,
>
> Pedro Simonetti.
>
> --
> View this message in context:
> http://www.nabble.com/Fix-for-issue--327%3A-ka-Map-overlays-tp16620073p16620073.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> 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/20080416/9e45e6a7/attachment.html
From lancelot at inetnebr.com  Wed Apr 16 09:57:49 2008
From: lancelot at inetnebr.com (Lance Dyas)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Permalink Broken in 2.6
In-Reply-To: <1e14d5320804160324l58d5f5e2o113797bf51bba6a7@mail.gmail.com>
References: <480588C3.2030100@inetnebr.com>
	<1e14d5320804160324l58d5f5e2o113797bf51bba6a7@mail.gmail.com>
Message-ID: <480605DD.8080904@inetnebr.com>

duh.... Smacks forehead (oops thanks)
converting pages from an earlier version
(I think a later 2.4) the issue didnt seem to occur..
 
Thomas Wood wrote:
> No, your setCenter call is overriding the permalink, the line should
> check whether it is already set with something like
> if(!map.getCenter()) map.setCenter(....
>
> On Wed, Apr 16, 2008 at 6:04 AM, Lance Dyas <lancelot@inetnebr.com> 
> wrote:
>  
>> http://www.dyasdesigns.com/geoxml/navtoolbar.html?zoom=5&lat=45.625&lon=40.5957&layers=B 
>>
>>
>>
>>  _______________________________________________
>>  Dev mailing list
>>  Dev@openlayers.org
>>  http://openlayers.org/mailman/listinfo/dev
>>
>>     
>
>
>
>   



From pedrosimonetti at gmail.com  Wed Apr 16 10:18:04 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Patch for a ka-Map cached layer
In-Reply-To: <53D0E841-B8A5-4869-860E-A2BA423F20E6@dmsolutions.ca>
References: <16623387.post@talk.nabble.com>
	<20217482-4FA9-4F65-919B-E4D883B2DBCB@dmsolutions.ca>
	<16623702.post@talk.nabble.com>
	<53D0E841-B8A5-4869-860E-A2BA423F20E6@dmsolutions.ca>
Message-ID: <5b629bbf0804160718j2575a07bve0f09ebd9677b512@mail.gmail.com>

Paul,

As you suggested, I've updated the file structure. Here comes the updated
patch. As I stated in the earlier post, I'm using the same configuration
file "config.php" for the "tile.php" and "precache.php". The "config.php"
file is in the tracker of the issue #327.

[1] http://trac.openlayers.org/ticket/327

Sould I add this file to the new ticket I'm opening? I'm not doing this to
avoid duplicities in the tracker.

The ticket for this patch is:

http://trac.openlayers.org/ticket/1518

My best regards,

Pedro Simonetti.

2008/4/11, Paul Spencer <pspencer@dmsolutions.ca>:
>
>
> On 10-Apr-08, at 10:05 PM, Pedro Simonetti wrote:
>
> > Hey Paul,
> >
> > Thanks for your response.
> >
> > Just to make it clear, so the structure [1] is the best one (one more
> > directory level)?
> >
> > [1] var/cache/World/50000/Group_Name/def/t-440320/l20480
> > [2] var/cache/World/50000/Group_Name/def/t-440320l20480
> >
> > If so, I'll have to make this little modifications in the patches/files
> > I've
> > sended here, and in the earlier post. But this is easy, just confirm if
> > the
> > first one is the best.
> >
>
>
> The first one is better than the second one for sure.  I wouldn't go so
> far as to say it is the best ;)
>
> Cheers
>
> Paul
>
> __________________________________________
>
>   Paul Spencer
>   Chief Technology Officer
>   DM Solutions Group Inc
>   http://www.dmsolutions.ca/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080416/a7fc43f3/attachment.html
From pedrosimonetti at gmail.com  Wed Apr 16 10:43:00 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:47 2010
Subject: [OpenLayers-Dev] Patch for the Brazilian Portuguese Dictonary
Message-ID: <5b629bbf0804160743r2e85ba34i7fa8d5fef494559d@mail.gmail.com>

Hi Devs,

Here's a simple one: the patch for the brazilian portuguese.

During the translation process I've noted some things I would
like to point out.

In 'minZoomLevelError' definition, the "That this" is wrong isn't?
It should be "this" or "that" only. Next in 'minZoomLevelError',
theres a mention on "min/max resolution setting". This shouldn't
be minScale/maxScale?

  'minZoomLevelError':
      ...
      "with the FixedZoomLevels-descendent layers. That this " +
      ...
      "use min/max resolution setting as described here: " +
      ...

Another small thing. On 'getLayerWarning' the "either" should
be removed.

  'getLayerWarning':

      "Most likely, this is because the ${layerLib} library " +
      "script was either not correctly included.<br><br>" +

One question. Is a desired feature to make a auto-detect
language on OL startup? I think this could be a good feature.

What's the best method to activate a different language
with the actual API?

I'm opening a new ticket to this patch:
http://trac.openlayers.org/ticket/1519

regards,

Pedro Simonetti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080416/8deecd49/attachment.html
From bartvde at osgis.nl  Fri Apr 18 15:13:37 2008
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <20080411135618.GZ5298@vishnu.tridity.org>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
	<20080411135618.GZ5298@vishnu.tridity.org>
Message-ID: <4808F2E1.8030004@osgis.nl>

Following up on this, since the deadline for workshop registration is 
coming close.

Who will take the lead in submitting a proposal to the conference 
website? I would be willing to do this, if the people attending for sure 
will write their affiliation and a short bio in an e-mail.

Also, what will be the focus of the workshop:
-the internals of OpenLayers (so a technical/developer perspective)
-the examples of OpenLayers useage (so a more practical, user-oriented 
perspective)
-or both?

Was there an OL workshop in 2006 or 2007 for which we can use the 
proposal details? Or do we have to start from scratch?

Best regards,
Bart

Schuyler Erle wrote:
> * On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
>   
>> is anyone going to FOSS4G2008 in Capetown?
>>
>> Are there plans to do an OpenLayers workshop? I would be interested in
>> helping out.
>>     
>
> FWIW I plan to be there; would be willing to help organize an OL
> workshop if needed.
>
> SDE
>
>
>   


-- 
Bart van den Eijnden
OSGIS, Open Source GIS
bartvde@osgis.nl
http://www.osgis.nl


From pedrosimonetti at gmail.com  Fri Apr 18 19:40:25 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] transition sandbox - request for comment
In-Reply-To: <55E7D265-EB58-4ADC-9B3E-072A57866758@dmsolutions.ca>
References: <8FD1CB6D-B941-49E1-BEBB-0D42CE253768@dmsolutions.ca>
	<5ec103de0801151200q41d6674bh98d882bb6b5e7852@mail.gmail.com>
	<55E7D265-EB58-4ADC-9B3E-072A57866758@dmsolutions.ca>
Message-ID: <16765822.post@talk.nabble.com>



pagameba wrote:
> 
> Eric,
> 
> the sandbox is unchanged, you should be able to try it out.
> 
> http://dev.openlayers.org/sandbox/pagameba/transition/examples/transition.html
> 
> Everything is pretty good except for the animated tiled layer, which  
> suffers from the problems indicated.
> 
> Cheers
> 
> Paul
> 

Hi all,

Sometime ago I was using a technique I'll describe here to resize multiple
HTML 
elements at the same time. This technique relies on relative sizing, so all 
elements that sould be resized must use "em" or "ex" units. The best results 
can be achieved with "em".

I thought that maybe this technique could be used to improve the performance
of 
the zoom animated transition effect, specially in the case when using tiles. 
The current implementation performs changes in "top", "left", "width" and 
"height" properties of each tile on the layer. With a small map viewport the 
performance isn't a problem at all, but with larger viewports, or with
multiple 
layers using this effect, you will clearly perceive the performance
problems.
MY PC is a little bit old, but it isn't slow. I'm using a AMD Semprom 2600+
1256 RAM, NVIDIA GeForce FX 5500, on a Windows XP SP2.  

Another problem of the current implementation, is that sometimes the tiles 
makes some strange resizing and shifting effects. I'm not sure how to
exaclty 
reproduce this, but I think is when you do a zoom in, and right after a zoom
out 
without waiting all tiles to be loaded.

As far as I can see, the "relative sizes technique" will vastly improve the 
performance, specially in tiled maps, or in multi-layered maps. The
performance 
gain occurs because you'll have to change only 3 css properties to resize
and 
reposition all tiles at once. I think that this technique will also fix the 
strange effects issue, because the individual tiles won't be changed.

This technique is a little bit tricky, and will require some modifications
in the style of the generated tiles, but I think the costs/benefits will be 
positive.

======================================
The Relative Sizes Technique Overview
======================================

The trick is use a 10px font-size in the map container. Then, all sizes and 
positions of the container, and the tiles inside of it, must use "em" units.
The 10px is the optimal value because it will easier the convertion to
relative
units. For example, to indicate that the "top" property of the container
will
have a value equivalent to 128px, you'll have to set the value as "12.8em" 
(12.8 * 10 = 128).  

In theory, all relative values of the container's children will be based on
the
container's font-size. But, it seems FF ignores the font-size inheritance
when
the element has a absolute position, and that's the case of the tiles. So'll 
have to explicit inform a "em" value in the tiles. 

Another problem is that Opera seems to have problems when using this
technique 
with "em" values smaller than 1, like 0.5. The workaround is to use a "10em" 
value on the tile's style rule.

So, to allow changing all values at once, you should use a css rule like
this: 

    .div_tile {
      font-size: 10em;
      position: absolute;
    }


Then each tile will be like:

    &lt;div class="div_tile" style="top:0; left:2.56em;"&gt;
      &lt;img src="..." class="img_tile" galleryimg="no"/&gt;&lt;/div&gt;


So, once 1em = 10px, 10em will be equivalent to 100px for the tile measures.
Then, to have a 256px wide tile, you'll have to use a "2.56em" value. To
apply
the same size to all tiles, I've used a css class in the tile images, but
you could use inline css values too.

    &lt;img src="..." class="img_tile" galleryimg="no"/&gt;

Here's the css rule of the tile images:

    /* 1em = 100px --&gt; 2.56em = 256px */
    .img_tile {
      width: 2.56em; 
      height: 2.56em; 
    }

By making this, if you change the "font-size" of the ".div_tile" css rule,
all 
tiles will be resized and repositioned proportionally. The "10em" value 
represents a 100% size, so changing the font-size to "20em" will make a 200% 
zoom, 5em = 50%, 2.5em = 25%, and so on.

After that, the position of the tiles will change, so you'll have to adjust
the
"top" and "left" properties of the container.

This aproach has some problems. First, it is semantically wrong using
font-size
to control elements measures and positions. Second, it will require 
modifications in some parts of OL code (I'm not sure exactly which parts).
Third, I'm not sure about the mathematical precision of this approach when
using cartographic calculations.

But, the improve in performance will be significantly high, allowing using
smooth animated zoom effect with full screen maps and/or with multiple
layers.

Considering that "a demo says more than a thousand line codes", I've made a 
simple example ilustrating this technique. I've declared the values of CSS
in 
the &lt;style&gt; tag, in a real application those values can be inline,
using 
style property inside html tags.

======================================
Example
======================================
Here's a prototype. I'm not using OpenLayers. It's just a test to check the
potential of this approach. This example is very simple but it uses a
timming
based animation technique that skips automatically the frames if the on
slow computers, or when the browser is processing heavy codes.

You can enable/disable an overlay to see how the performance is affected on
multiple layers. The impact in performance isn't big, so I'm estimating that
it will be possible to use this effect at fullscreen with 1 to 2 overlays,
even in older computers.

Of course, this performance will decrease when applied inside the OL 
application, but it worth take a look.  

http://jproton.com.br/sandbox/relative-sizes.html

Note: in the upper right corner there's a DIV that resizes the map when you
hover mouse in it. Again, this is just a test, and I think the performance
of 
this feature can be improved by skiping some frames.

Note2: I'm using document onload event to initialize the example. So,
because
of this, no effects will happens until all images are loaded. Though, this
approach should behave correctly even when the tiles are loading, if the 
images are generated by JavaScipt code. This is not implement in this
example
for simplicity reasons.

======================================
PROS
======================================
  - highly efficient
  - scalable
  - backwards compatibile
  - as far as I could test, it's consistent along different browsers (I've 
    tested with IE6, FF2, and Opera9)
  - will allow factional zooming when dragging the scale control, as the 
    earlier demo of Emanuel:
    http://dev.openlayers.org/sandbox/emanuel/animatedZooming/demo.html  

======================================
CONS
======================================
  - It is semantically wrong using font-size to control measures and
positions
  - Being semantically wrong, the code tends to be less readable, besides
    this can be minimized with comments along the code
  - By using relatives sizes, it means that if the user change the font-size 
    of document, or use a full-page zoom tool, it will resize the map too. 
    But in a near future this will be the normal behaviour of the browsers. 
    Opera 9 already resizes images when changing the page zoom. FF3 too. 
    And IE8 too. The nighly version of Webkit also supports this feature:
    http://www.mozilla.com/en-US/firefox/3.0b5/releasenotes/#whatsnew
   
http://blogs.msdn.com/ie/archive/2008/03/25/internet-explorer-8-and-adaptive-zoom.aspx
    http://webkit.org/blog/165/full-page-zoom/



If you feel insterested in more details about this technique, just ask for 
more info. I'm not describing all details here to not over extend this post.

I don't have much knowledge in cartographic math, so I'll let this part to 
you geo gurus. =)

I hope you find this crazy idea insteresting. =D

my best regards,

Pedro Simonetti.
-- 
View this message in context: http://www.nabble.com/transition-sandbox---request-for-comment-tp14823509p16765822.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From tschaub at openplans.org  Fri Apr 18 20:24:28 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <4808F2E1.8030004@osgis.nl>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>	<20080411135618.GZ5298@vishnu.tridity.org>
	<4808F2E1.8030004@osgis.nl>
Message-ID: <48093BBC.5040804@openplans.org>

Hey-

Bart van den Eijnden (OSGIS) wrote:
> Following up on this, since the deadline for workshop registration is 
> coming close.
> 
> Who will take the lead in submitting a proposal to the conference 
> website? I would be willing to do this, if the people attending for sure 
> will write their affiliation and a short bio in an e-mail.
> 
> Also, what will be the focus of the workshop:
> -the internals of OpenLayers (so a technical/developer perspective)
> -the examples of OpenLayers useage (so a more practical, user-oriented 
> perspective)
> -or both?
> 
> Was there an OL workshop in 2006 or 2007 for which we can use the 
> proposal details? Or do we have to start from scratch?

I gave an OpenLayers talk last year.
http://www.foss4g2007.org/presentations/view.php?abstract_id=228

I'd like to be involved in submitting another proposal.  Just need to 
confirm my attendance first.

Tim

> 
> Best regards,
> Bart
> 
> Schuyler Erle wrote:
>> * On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
>>   
>>> is anyone going to FOSS4G2008 in Capetown?
>>>
>>> Are there plans to do an OpenLayers workshop? I would be interested in
>>> helping out.
>>>     
>> FWIW I plan to be there; would be willing to help organize an OL
>> workshop if needed.
>>
>> SDE
>>
>>
>>   
> 
> 


From eric.c2c at gmail.com  Sun Apr 20 14:45:58 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Fwd: [OpenLayers-Commits] r6979 -
	sandbox/topp/almanac/lib/OpenLayers/Format
In-Reply-To: <20080420072940.B5D6D3FEBE@d3-3.metacarta.com>
References: <20080420072940.B5D6D3FEBE@d3-3.metacarta.com>
Message-ID: <5ec103de0804201145vd1c00a1s593003474fe26b8d@mail.gmail.com>

Tim,

Wouldn't it make sense to add a "link" or "url" property to the
Feature class (I like "link" better)? It would make sense to me in
regards to the code we have in the 'delete' and 'update' methods of
Protocol/HTTP.js (where we assume that feature.url exists).

Thoughts?
--
Eric

---------- Forwarded message ----------
From:  <commits@openlayers.org>
Date: Sun, Apr 20, 2008 at 9:29 AM
Subject: [OpenLayers-Commits] r6979 - sandbox/topp/almanac/lib/OpenLayers/Format
To: commits@openlayers.org


Author: tschaub
 Date: 2008-04-20 03:29:40 -0400 (Sun, 20 Apr 2008)
 New Revision: 6979

 Modified:
   sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js
 Log:
 atom requires href on link

 Modified: sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js
 ===================================================================
 --- sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js  2008-04-20
05:02:10 UTC (rev 6978)
 +++ sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js  2008-04-20
07:29:40 UTC (rev 6979)
 @@ -208,11 +208,7 @@
                 feature.attributes.content = this.getChildValue(node);
             },
             "link": function(node, feature) {
 -                var href = this.getChildValue(node);
 -                if(!href) {
 -                    href = node.getAttribute("href");
 -                }
 -                feature.attributes.link = href;
 +                feature.attributes.link = node.getAttribute("href");
             },
             "id": function(node, feature) {
                 feature.fid = this.getChildValue(node);

 _______________________________________________
 Commits mailing list
 Commits@openlayers.org
 http://openlayers.org/mailman/listinfo/commits

From m.manso at upm.es  Sun Apr 20 18:34:03 2008
From: m.manso at upm.es (m.manso@upm.es)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] WFS Layers,
	BBOX parameter OPTIONAL to enable FILTER or FEATUREID parameter
Message-ID: <480BE0FB.24642.12B2A633@m.manso.upm.es>

Hi to all,

I'm new to list.
I was looking for a integrated WFS and WFS client that enable me to define FILTER request 
GetFeature parameter.

When try to do this with OpenLayers and don't works, look on logs files of Geoserver and find 
that it's incompatible the use of BBOX and FEATUREID parameters.

By this reason i thing that other flag parameter of WFS layer can be include (useBBOX) that 
can be enable by default and when tru to define url check if this flag is enable to include 
BBOX parameter. 

I've proved with booth FILTER and FEATUREID optional parameter on WFS layer and works 
fine.

Send code for any.

Best regards,





-------------------------------------------------------------------------------------------------
Miguel ?ngel Manso Callejo.
Grupo Mercator: Tecnolog?as de la Geoinformaci?n.
Dpto. Ing. Topogr?fica y Cartograf?a (UPM)
ETSI en Topograf?a, Geodesia y Cartograf?a.
Autovia de Valencia Km 7.5 Madrid 28031
Tfno: 34 91 336 6487 - Fax:  34 91 336 7932
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  WFS_js.txt
     Date:  20 Apr 2008, 15:06
     Size:  18763 bytes.
     Type:  Text
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WFS_js.txt
Type: application/octet-stream
Size: 18763 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080421/be47ec6a/WFS_js.obj
From tschaub at openplans.org  Mon Apr 21 00:36:52 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Fwd: [OpenLayers-Commits] r6979 -
	sandbox/topp/almanac/lib/OpenLayers/Format
In-Reply-To: <5ec103de0804201145vd1c00a1s593003474fe26b8d@mail.gmail.com>
References: <20080420072940.B5D6D3FEBE@d3-3.metacarta.com>
	<5ec103de0804201145vd1c00a1s593003474fe26b8d@mail.gmail.com>
Message-ID: <480C19E4.6050408@openplans.org>


Eric Lemoine wrote:
> Tim,
> 
> Wouldn't it make sense to add a "link" or "url" property to the
> Feature class (I like "link" better)? It would make sense to me in
> regards to the code we have in the 'delete' and 'update' methods of
> Protocol/HTTP.js (where we assume that feature.url exists).
> 
> Thoughts?

Hey Eric-

Yeah, I just kept link as a feature.attributes property because that was 
where Sean had it.  In the application that I'm using this for, I extend 
the Atom readers & writers to do a good bit of custom parsing.  There, I 
create a link object on features - keyed by the "rel" attribute of the 
incoming atom:link.

In general, I think it makes good sense to put things in 
feature.attributes that users are responsible for editing.  Other 
properties are better on the feature directly.

I look forward to having a discussion about our feature model.  I also 
will pass on info on how I am extending formats to get custom 
application behavior.  This is easy enough to do that I don't think we 
have to have a single feature model that works for everyone.

But, yeah, I agree.  The protocol should be setting feature links.

Tim



> --
> Eric
> 
> ---------- Forwarded message ----------
> From:  <commits@openlayers.org>
> Date: Sun, Apr 20, 2008 at 9:29 AM
> Subject: [OpenLayers-Commits] r6979 - sandbox/topp/almanac/lib/OpenLayers/Format
> To: commits@openlayers.org
> 
> 
> Author: tschaub
>  Date: 2008-04-20 03:29:40 -0400 (Sun, 20 Apr 2008)
>  New Revision: 6979
> 
>  Modified:
>    sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js
>  Log:
>  atom requires href on link
> 
>  Modified: sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js
>  ===================================================================
>  --- sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js  2008-04-20
> 05:02:10 UTC (rev 6978)
>  +++ sandbox/topp/almanac/lib/OpenLayers/Format/Atom.js  2008-04-20
> 07:29:40 UTC (rev 6979)
>  @@ -208,11 +208,7 @@
>                  feature.attributes.content = this.getChildValue(node);
>              },
>              "link": function(node, feature) {
>  -                var href = this.getChildValue(node);
>  -                if(!href) {
>  -                    href = node.getAttribute("href");
>  -                }
>  -                feature.attributes.link = href;
>  +                feature.attributes.link = node.getAttribute("href");
>              },
>              "id": function(node, feature) {
>                  feature.fid = this.getChildValue(node);
> 
>  _______________________________________________
>  Commits mailing list
>  Commits@openlayers.org
>  http://openlayers.org/mailman/listinfo/commits
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,480b8f6d149261439371379!
> 


From eric.c2c at gmail.com  Mon Apr 21 02:20:29 2008
From: eric.c2c at gmail.com (Eric Lemoine)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <4808F2E1.8030004@osgis.nl>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
	<20080411135618.GZ5298@vishnu.tridity.org> <4808F2E1.8030004@osgis.nl>
Message-ID: <5ec103de0804202320t37b9bf8dt27c19ce27dbb8ff1@mail.gmail.com>

On Fri, Apr 18, 2008 at 9:13 PM, Bart van den Eijnden (OSGIS)
<bartvde@osgis.nl> wrote:
> Following up on this, since the deadline for workshop registration is
>  coming close.
>
>  Who will take the lead in submitting a proposal to the conference
>  website? I would be willing to do this, if the people attending for sure
>  will write their affiliation and a short bio in an e-mail.
>
>  Also, what will be the focus of the workshop:
>  -the internals of OpenLayers (so a technical/developer perspective)
>  -the examples of OpenLayers useage (so a more practical, user-oriented
>  perspective)
>  -or both?
>
>  Was there an OL workshop in 2006 or 2007 for which we can use the
>  proposal details? Or do we have to start from scratch?

Hi Bart,

It looks like I'll be at FOSS4G 2008. And I plan to submit a MapFish
workshop proposal. I haven't thought about that workshop yet but it
will most probably be an "how to use MapFish" workshop, so not much
about of MapFish internals. MapFish being based on and making use of
OpenLayers, I cannot avoid talking about usage of OpenLayers. With
that in mind, and considering that lots of people now know how to use
OpenLayers, wouldn't it be interesting and useful to have a OpenLayers
internals workshop?

Thanks,
--
Eric

From euzuro at gmail.com  Mon Apr 21 03:23:49 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <5ec103de0804202320t37b9bf8dt27c19ce27dbb8ff1@mail.gmail.com>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>
	<20080411135618.GZ5298@vishnu.tridity.org> <4808F2E1.8030004@osgis.nl>
	<5ec103de0804202320t37b9bf8dt27c19ce27dbb8ff1@mail.gmail.com>
Message-ID: <6ae3fb590804210023s2732ebddg58a80a86b81b58ac@mail.gmail.com>

I would be interested and willing to participate in a workshop like
that if people think people would be interested.

On 4/21/08, Eric Lemoine <eric.c2c@gmail.com> wrote:
> On Fri, Apr 18, 2008 at 9:13 PM, Bart van den Eijnden (OSGIS)
> <bartvde@osgis.nl> wrote:
> > Following up on this, since the deadline for workshop registration is
> >  coming close.
> >
> >  Who will take the lead in submitting a proposal to the conference
> >  website? I would be willing to do this, if the people attending for sure
> >  will write their affiliation and a short bio in an e-mail.
> >
> >  Also, what will be the focus of the workshop:
> >  -the internals of OpenLayers (so a technical/developer perspective)
> >  -the examples of OpenLayers useage (so a more practical, user-oriented
> >  perspective)
> >  -or both?
> >
> >  Was there an OL workshop in 2006 or 2007 for which we can use the
> >  proposal details? Or do we have to start from scratch?
>
> Hi Bart,
>
> It looks like I'll be at FOSS4G 2008. And I plan to submit a MapFish
> workshop proposal. I haven't thought about that workshop yet but it
> will most probably be an "how to use MapFish" workshop, so not much
> about of MapFish internals. MapFish being based on and making use of
> OpenLayers, I cannot avoid talking about usage of OpenLayers. With
> that in mind, and considering that lots of people now know how to use
> OpenLayers, wouldn't it be interesting and useful to have a OpenLayers
> internals workshop?
>
> Thanks,
> --
> Eric
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From jlacroix at mapgears.com  Mon Apr 21 10:42:16 2008
From: jlacroix at mapgears.com (Julien-Samuel Lacroix)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <4808F2E1.8030004@osgis.nl>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>	<20080411135618.GZ5298@vishnu.tridity.org>
	<4808F2E1.8030004@osgis.nl>
Message-ID: <480CA7C8.6050800@mapgears.com>

Hi,

I think it would be cool to have a presentation on the customisation of 
controls and other internal aspects like that. Functionalities like 
vector edition are really cool and well supported with functions like 
onModificationEnd. I think it would be really interesting for 
developpers to learn about those and for non-developpers to see the 
potential of them.

I can help you with the workshop if you want.

Julien

Bart van den Eijnden (OSGIS) wrote:
> Following up on this, since the deadline for workshop registration is 
> coming close.
> 
> Who will take the lead in submitting a proposal to the conference 
> website? I would be willing to do this, if the people attending for sure 
> will write their affiliation and a short bio in an e-mail.
> 
> Also, what will be the focus of the workshop:
> -the internals of OpenLayers (so a technical/developer perspective)
> -the examples of OpenLayers useage (so a more practical, user-oriented 
> perspective)
> -or both?
> 
> Was there an OL workshop in 2006 or 2007 for which we can use the 
> proposal details? Or do we have to start from scratch?
> 
> Best regards,
> Bart
> 
> Schuyler Erle wrote:
> 
>>* On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
>>  
>>
>>>is anyone going to FOSS4G2008 in Capetown?
>>>
>>>Are there plans to do an OpenLayers workshop? I would be interested in
>>>helping out.
>>>    
>>
>>FWIW I plan to be there; would be willing to help organize an OL
>>workshop if needed.
>>
>>SDE
>>
>>
>>  
> 
> 
> 

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/

From jlacroix at mapgears.com  Mon Apr 21 10:52:03 2008
From: jlacroix at mapgears.com (Julien-Samuel Lacroix)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Markers reprojection
Message-ID: <480CAA13.5030207@mapgears.com>

Hi,

I need to add Markers and Vectors on a SphericalMercator map. My 
coordinates are in degree instead of meters. The projection member is 
not supported in the Markers and Vector Layer class. Is there a reason 
for that?

I know I could reprojection all the LatLon object I create individually, 
but it would be more easier to have it directly in the Layer. I could 
open a ticket and submit a patch if you feel it worth going in the trunk.

Julien

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/

From tschaub at openplans.org  Mon Apr 21 12:41:57 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <480CA7C8.6050800@mapgears.com>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>	<20080411135618.GZ5298@vishnu.tridity.org>	<4808F2E1.8030004@osgis.nl>
	<480CA7C8.6050800@mapgears.com>
Message-ID: <480CC3D5.1060904@openplans.org>

Hey-

Julien-Samuel Lacroix wrote:
> Hi,
> 
> I think it would be cool to have a presentation on the customisation of 
> controls and other internal aspects like that. Functionalities like 
> vector edition are really cool and well supported with functions like 
> onModificationEnd. I think it would be really interesting for 
> developpers to learn about those and for non-developpers to see the 
> potential of them.

FWIW - I'd recommend using vector layer events rather than things like 
onModificationEnd :)

http://dev.openlayers.org/docs/files/OpenLayers/Layer/Vector-js.html#OpenLayers.Layer.Vector.EVENT_TYPES

Tim

> 
> I can help you with the workshop if you want.
> 
> Julien
> 
> Bart van den Eijnden (OSGIS) wrote:
>> Following up on this, since the deadline for workshop registration is 
>> coming close.
>>
>> Who will take the lead in submitting a proposal to the conference 
>> website? I would be willing to do this, if the people attending for sure 
>> will write their affiliation and a short bio in an e-mail.
>>
>> Also, what will be the focus of the workshop:
>> -the internals of OpenLayers (so a technical/developer perspective)
>> -the examples of OpenLayers useage (so a more practical, user-oriented 
>> perspective)
>> -or both?
>>
>> Was there an OL workshop in 2006 or 2007 for which we can use the 
>> proposal details? Or do we have to start from scratch?
>>
>> Best regards,
>> Bart
>>
>> Schuyler Erle wrote:
>>
>>> * On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
>>>  
>>>
>>>> is anyone going to FOSS4G2008 in Capetown?
>>>>
>>>> Are there plans to do an OpenLayers workshop? I would be interested in
>>>> helping out.
>>>>    
>>> FWIW I plan to be there; would be willing to help organize an OL
>>> workshop if needed.
>>>
>>> SDE
>>>
>>>
>>>  
>>
>>
> 


From grand.edgemaster at gmail.com  Mon Apr 21 13:17:55 2008
From: grand.edgemaster at gmail.com (Thomas Wood)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Markers reprojection
In-Reply-To: <480CAA13.5030207@mapgears.com>
References: <480CAA13.5030207@mapgears.com>
Message-ID: <1e14d5320804211017w17d4d0ael69bd3a8a9b9d3db1@mail.gmail.com>

I am doing work on transform methods for Vector and Marker layers in my sandbox:
http://dev.openlayers.org/sandbox/edgemaster/openlayers/

However, it should be fairly easy to transform all the points before
they're added to the marker layer depending on your datasource.
For example, the GML layer (badly named), can support input of many
data formats and automatically reproject before adding them onto the
map.

On Mon, Apr 21, 2008 at 3:52 PM, Julien-Samuel Lacroix
<jlacroix@mapgears.com> wrote:
> Hi,
>
>  I need to add Markers and Vectors on a SphericalMercator map. My
>  coordinates are in degree instead of meters. The projection member is
>  not supported in the Markers and Vector Layer class. Is there a reason
>  for that?
>
>  I know I could reprojection all the LatLon object I create individually,
>  but it would be more easier to have it directly in the Layer. I could
>  open a ticket and submit a patch if you feel it worth going in the trunk.
>
>  Julien
>
>  --
>  Julien-Samuel Lacroix
>  Mapgears
>  http://www.mapgears.com/
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>



-- 
Regards,
Thomas Wood
(Edgemaster)

From crschmidt at metacarta.com  Mon Apr 21 13:56:49 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Markers reprojection
In-Reply-To: <480CAA13.5030207@mapgears.com>
References: <480CAA13.5030207@mapgears.com>
Message-ID: <20080421175649.GC11748@metacarta.com>

On Mon, Apr 21, 2008 at 10:52:03AM -0400, Julien-Samuel Lacroix wrote:
> Hi,
> 
> I need to add Markers and Vectors on a SphericalMercator map. My 
> coordinates are in degree instead of meters. The projection member is 
> not supported in the Markers and Vector Layer class. Is there a reason 
> for that?

In general, there is no good place that we can know that we should be
reprojecting on these layers. 

> I know I could reprojection all the LatLon object I create individually, 
> but it would be more easier to have it directly in the Layer. I could 
> open a ticket and submit a patch if you feel it worth going in the trunk.

Where do you think the reprojection code would live in this case? I
don't like the idea of touching someone else's geometry. In the case of
a Layer.GML or some such, the format is creating the geometry, so it
never belonged to someone else to begin with, but with Layer.Vector and
Layer.Marker, that's less true.

Regards,
-- 
Christopher Schmidt
MetaCarta

From jlacroix at mapgears.com  Mon Apr 21 15:03:45 2008
From: jlacroix at mapgears.com (Julien-Samuel Lacroix)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Markers reprojection
In-Reply-To: <20080421175649.GC11748@metacarta.com>
References: <480CAA13.5030207@mapgears.com>
	<20080421175649.GC11748@metacarta.com>
Message-ID: <480CE511.3090903@mapgears.com>


Christopher Schmidt wrote:
> In general, there is no good place that we can know that we should be
> reprojecting on these layers. 
 >
> Where do you think the reprojection code would live in this case? I
> don't like the idea of touching someone else's geometry. In the case of
> a Layer.GML or some such, the format is creating the geometry, so it
> never belonged to someone else to begin with, but with Layer.Vector and
> Layer.Marker, that's less true.

I'm not sure about the vector layers, but the markers could be 
reprojected in the addMarker function:

addMarker: function(marker) {
         if(this.projection != this.map.projection)
         {
             marker.lonlat.transform(this.projection, this.map.projection);
         }
...


What do you think? Is there other uses of this class where this wouldn't 
work?

Julien

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/

From crschmidt at metacarta.com  Mon Apr 21 16:41:41 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Markers reprojection
In-Reply-To: <480CE511.3090903@mapgears.com>
References: <480CAA13.5030207@mapgears.com>
	<20080421175649.GC11748@metacarta.com>
	<480CE511.3090903@mapgears.com>
Message-ID: <20080421204141.GA14590@metacarta.com>

On Mon, Apr 21, 2008 at 03:03:45PM -0400, Julien-Samuel Lacroix wrote:
> 
> Christopher Schmidt wrote:
> > In general, there is no good place that we can know that we should be
> > reprojecting on these layers. 
>  >
> > Where do you think the reprojection code would live in this case? I
> > don't like the idea of touching someone else's geometry. In the case of
> > a Layer.GML or some such, the format is creating the geometry, so it
> > never belonged to someone else to begin with, but with Layer.Vector and
> > Layer.Marker, that's less true.
> 
> I'm not sure about the vector layers, but the markers could be 
> reprojected in the addMarker function:
> 
> addMarker: function(marker) {
>          if(this.projection != this.map.projection)
>          {
>              marker.lonlat.transform(this.projection, this.map.projection);
>          }
> ...
> 
> 
> What do you think? Is there other uses of this class where this wouldn't 
> work?

WFS, Text, and GeoRSS layers already reproject markers before they get
to the addMarker call.

Regards,
-- 
Christopher Schmidt
MetaCarta

From pspencer at dmsolutions.ca  Mon Apr 21 22:46:48 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] FOSS4G2008
In-Reply-To: <480CA7C8.6050800@mapgears.com>
References: <c3441c8b47c5d8be06c3999fe7251917@145.50.39.11>	<20080411135618.GZ5298@vishnu.tridity.org>
	<4808F2E1.8030004@osgis.nl> <480CA7C8.6050800@mapgears.com>
Message-ID: <F49A46DA-F3E7-4E6C-A1E8-933F5310C952@dmsolutions.ca>

I like the idea of more of an internals session but I wonder if the  
audience might be comprised of folks who haven't made it to the  
conference in the past in which case a user oriented session might be  
better?  I'll help on either if you want/need it.

Paul

On 21-Apr-08, at 10:42 AM, Julien-Samuel Lacroix wrote:
> Hi,
>
> I think it would be cool to have a presentation on the customisation  
> of
> controls and other internal aspects like that. Functionalities like
> vector edition are really cool and well supported with functions like
> onModificationEnd. I think it would be really interesting for
> developpers to learn about those and for non-developpers to see the
> potential of them.
>
> I can help you with the workshop if you want.
>
> Julien
>
> Bart van den Eijnden (OSGIS) wrote:
>> Following up on this, since the deadline for workshop registration is
>> coming close.
>>
>> Who will take the lead in submitting a proposal to the conference
>> website? I would be willing to do this, if the people attending for  
>> sure
>> will write their affiliation and a short bio in an e-mail.
>>
>> Also, what will be the focus of the workshop:
>> -the internals of OpenLayers (so a technical/developer perspective)
>> -the examples of OpenLayers useage (so a more practical, user- 
>> oriented
>> perspective)
>> -or both?
>>
>> Was there an OL workshop in 2006 or 2007 for which we can use the
>> proposal details? Or do we have to start from scratch?
>>
>> Best regards,
>> Bart
>>
>> Schuyler Erle wrote:
>>
>>> * On 10-Apr-2008 at 12:52AM PDT, Bart van den Eijnden (OSGIS) said:
>>>
>>>
>>>> is anyone going to FOSS4G2008 in Capetown?
>>>>
>>>> Are there plans to do an OpenLayers workshop? I would be  
>>>> interested in
>>>> helping out.
>>>>
>>>
>>> FWIW I plan to be there; would be willing to help organize an OL
>>> workshop if needed.
>>>
>>> SDE
>>>
>>>
>>>
>>
>>
>>
>
> -- 
> Julien-Samuel Lacroix
> Mapgears
> http://www.mapgears.com/
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From cameron.shorter at gmail.com  Tue Apr 22 23:07:01 2008
From: cameron.shorter at gmail.com (Cameron Shorter)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Openlayers GSOC project
In-Reply-To: <77f297290804221611m138cefb3rcf929d035f851116@mail.gmail.com>
References: <77f297290804221611m138cefb3rcf929d035f851116@mail.gmail.com>
Message-ID: <480EA7D5.9000808@gmail.com>

Erik Hazzard wrote:
<snip>

Hi Erik,
Where do you live? What timezone do you work to?

We have a mapbuilder team meeting today/tomorrow (depending where you 
live) and you would be welcome to join us. I'll forward an invitation in 
the next email.

It is worth noting that there are a few different ways to implement your 
GSoC project, and depending upon the technology you choose will 
influence which mentors join you on your journey.

There is a friendly rivalry over the best way forward, and you are the 
prize. :)
Having said that, I don't want to push you one way or the other, and I 
don't think any of the mentors will be offended by whatever path you choose.


-- 
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 Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html


From pedrosimonetti at gmail.com  Tue Apr 22 23:31:22 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Small Bug in Click Event Example
Message-ID: <5b629bbf0804222031j2ec9fa85qd784d46b5a023ae9@mail.gmail.com>

Hi Developers,

I found a little bug in the "Click Event Example" (1). There are two
commas (,)  misplaced at the end of some object declarations.
I guess someone forgot to remove those commas after some
refactoring in the code.

This is not a problem on good browsers, but unfurtunately, our best
friend ever IE simply returns an error on this case.

The 2 commas that should be removed are indicated in the following
code:

                initialize: function(options) {
                    this.handlerOptions = OpenLayers.Util.extend(
                        {}, this.defaultHandlerOptions
                    );
                    OpenLayers.Control.prototype.initialize.apply(
                        this, arguments
                    );
                    this.handler = new OpenLayers.Handler.Click(
                        this, {
                            'click': this.trigger, <==REMOVE-THIS
                        }, this.handlerOptions
                    );
                },

                trigger: function(e) {
                    var lonlat = map.getLonLatFromViewPortPx(e.xy);
                    alert("You clicked near " + lonlat.lat + " N, " +
                                              + lonlat.lon + " E");
                }, <==REMOVE-THIS


I've opened a new issue for this. The patch is in the tracker (2).

my best regards,

Pedro Simonetti.

(1) http://openlayers.org/dev/examples/click.html
(2) http://trac.openlayers.org/ticket/1525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080423/1fbd7fc0/attachment.html
From crschmidt at metacarta.com  Tue Apr 22 23:51:39 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Small Bug in Click Event Example
In-Reply-To: <5b629bbf0804222031j2ec9fa85qd784d46b5a023ae9@mail.gmail.com>
References: <5b629bbf0804222031j2ec9fa85qd784d46b5a023ae9@mail.gmail.com>
Message-ID: <20080423035138.GA20326@metacarta.com>

On Wed, Apr 23, 2008 at 12:31:22AM -0300, Pedro Simonetti Garcia wrote:
> Hi Developers,
> 
> I found a little bug in the "Click Event Example" (1). There are two
> commas (,)  misplaced at the end of some object declarations.
> I guess someone forgot to remove those commas after some
> refactoring in the code.

By the time you sent this email, I had committed your fix. :) Thanks!

Regards,
-- 
Christopher Schmidt
MetaCarta

From bartvde at osgis.nl  Wed Apr 23 07:18:32 2008
From: bartvde at osgis.nl (bartvde@osgis.nl)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] mouse cursors
Message-ID: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>

Hi list,

I've been working a bit on mouse cursors in OL, and would like to request
some feedback on the current approach.

I've got an example up in my sandbox:
http://dev.openlayers.org/sandbox/bartvde/cursor/examples/cursor.html

And I've added a very preliminary patch to ticket1484:
http://trac.openlayers.org/attachment/ticket/1484/ticket1484.patch

I'll try and outline my approach a bit. The most difficult decision I found
was whether or not to use css. I find it quite a bit of overhead to make
css classes for all possible cursor combinations. In my case I would need
the following classes (looks already quite cumbersome to me):

.olControlZoomBoxCursor
.olControlZoomBoxOutCursor
.olControlDragPanCursor
.olControlDragPanMouseupCursor
.olControlDragPanMousedownCursor

etc.? As you can see, even control properties (like the out property for
ZoomBox) come into play, so we would need something like a cursorClass
property for people to override the default class names. For the approach
to work, we would need them to start their names with the 'olControl'
prefix, otherwise we don't know which css classes are safe to remove from
the map div when e.g. a different control is activated (we cannot just
remove any css class from the map div, since people might have set stuff on
it, so we should remove all classes that start with 'olControl' or some
similar approach). This can be error-prone IMHO.

I did see there are some utility functions (like addClass, removeClass,
toggleClass) in topp's almanac sandbox which could be used.

Disadvantage ofcourse of my approach is that the mouse cursors cannot
easily be altered by non-programmers, but I wonder how often a chosen
cursor approach will change in a project.

If people feel strongly that css is the way to go though, I can change the
code to add and remove css classes on the map div.

What I've done is briefly:

* add a cursor property on the Control class, which is set on the map div
when the control is activated
* add a cursors property (array) on the Handler class, which makes it
possible to set cursors on the map div in different functions of a Handler
(like mousedown). For now I've only implemented mousedown and mouseup in
the Drag Handler as an example.

I think the example and the patch tells the rest of the story best.

Feedback very much welcome. TIA.

Best regards,
Bart


From zac.spitzer at gmail.com  Wed Apr 23 08:35:37 2008
From: zac.spitzer at gmail.com (Zac Spitzer)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] mouse cursors
In-Reply-To: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>
References: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>
Message-ID: <7a85053e0804230535h2c0080f6m63fa3740766250f3@mail.gmail.com>

looks great in firefox, ie7 seems to "flutter" between dragging between
the pointer cursor and the 'action' cursor

On Wed, Apr 23, 2008 at 9:18 PM,  <bartvde@osgis.nl> wrote:
> Hi list,
>
>  I've been working a bit on mouse cursors in OL, and would like to request
>  some feedback on the current approach.
>
>  I've got an example up in my sandbox:
>  http://dev.openlayers.org/sandbox/bartvde/cursor/examples/cursor.html
>
>  And I've added a very preliminary patch to ticket1484:
>  http://trac.openlayers.org/attachment/ticket/1484/ticket1484.patch
>
>  I'll try and outline my approach a bit. The most difficult decision I found
>  was whether or not to use css. I find it quite a bit of overhead to make
>  css classes for all possible cursor combinations. In my case I would need
>  the following classes (looks already quite cumbersome to me):
>
>  .olControlZoomBoxCursor
>  .olControlZoomBoxOutCursor
>  .olControlDragPanCursor
>  .olControlDragPanMouseupCursor
>  .olControlDragPanMousedownCursor
>
>  etc.? As you can see, even control properties (like the out property for
>  ZoomBox) come into play, so we would need something like a cursorClass
>  property for people to override the default class names. For the approach
>  to work, we would need them to start their names with the 'olControl'
>  prefix, otherwise we don't know which css classes are safe to remove from
>  the map div when e.g. a different control is activated (we cannot just
>  remove any css class from the map div, since people might have set stuff on
>  it, so we should remove all classes that start with 'olControl' or some
>  similar approach). This can be error-prone IMHO.
>
>  I did see there are some utility functions (like addClass, removeClass,
>  toggleClass) in topp's almanac sandbox which could be used.
>
>  Disadvantage ofcourse of my approach is that the mouse cursors cannot
>  easily be altered by non-programmers, but I wonder how often a chosen
>  cursor approach will change in a project.
>
>  If people feel strongly that css is the way to go though, I can change the
>  code to add and remove css classes on the map div.
>
>  What I've done is briefly:
>
>  * add a cursor property on the Control class, which is set on the map div
>  when the control is activated
>  * add a cursors property (array) on the Handler class, which makes it
>  possible to set cursors on the map div in different functions of a Handler
>  (like mousedown). For now I've only implemented mousedown and mouseup in
>  the Drag Handler as an example.
>
>  I think the example and the patch tells the rest of the story best.
>
>  Feedback very much welcome. TIA.
>
>  Best regards,
>  Bart
>
>  _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>



-- 
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168

From bartvde at osgis.nl  Wed Apr 23 08:38:53 2008
From: bartvde at osgis.nl (bartvde@osgis.nl)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] mouse cursors
In-Reply-To: <7a85053e0804230535h2c0080f6m63fa3740766250f3@mail.gmail.com>
References: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>
	<7a85053e0804230535h2c0080f6m63fa3740766250f3@mail.gmail.com>
Message-ID: <6120dd10045e920167356774ea171f44@pop02.backbone.tiscomhosting.nl>

Yeah, I've seen that as well (also in FF2 on Windows and IE6 btw, at least
on my computer).

I could not find a workaround however to prevent this behaviour, i.e. when
changing the cursor from a url cursor to another url cursor, the default
cursor appears for a while in between.

Best regards,
Bart

On Wed, 23 Apr 2008 22:35:37 +1000, "Zac Spitzer" <zac.spitzer@gmail.com>
wrote:
> looks great in firefox, ie7 seems to "flutter" between dragging between
> the pointer cursor and the 'action' cursor
> 
> On Wed, Apr 23, 2008 at 9:18 PM,  <bartvde@osgis.nl> wrote:
>> Hi list,
>>
>>  I've been working a bit on mouse cursors in OL, and would like to
> request
>>  some feedback on the current approach.
>>
>>  I've got an example up in my sandbox:
>>  http://dev.openlayers.org/sandbox/bartvde/cursor/examples/cursor.html
>>
>>  And I've added a very preliminary patch to ticket1484:
>>  http://trac.openlayers.org/attachment/ticket/1484/ticket1484.patch
>>
>>  I'll try and outline my approach a bit. The most difficult decision I
> found
>>  was whether or not to use css. I find it quite a bit of overhead to
> make
>>  css classes for all possible cursor combinations. In my case I would
> need
>>  the following classes (looks already quite cumbersome to me):
>>
>>  .olControlZoomBoxCursor
>>  .olControlZoomBoxOutCursor
>>  .olControlDragPanCursor
>>  .olControlDragPanMouseupCursor
>>  .olControlDragPanMousedownCursor
>>
>>  etc.? As you can see, even control properties (like the out property
> for
>>  ZoomBox) come into play, so we would need something like a cursorClass
>>  property for people to override the default class names. For the
> approach
>>  to work, we would need them to start their names with the 'olControl'
>>  prefix, otherwise we don't know which css classes are safe to remove
> from
>>  the map div when e.g. a different control is activated (we cannot just
>>  remove any css class from the map div, since people might have set
> stuff on
>>  it, so we should remove all classes that start with 'olControl' or some
>>  similar approach). This can be error-prone IMHO.
>>
>>  I did see there are some utility functions (like addClass, removeClass,
>>  toggleClass) in topp's almanac sandbox which could be used.
>>
>>  Disadvantage ofcourse of my approach is that the mouse cursors cannot
>>  easily be altered by non-programmers, but I wonder how often a chosen
>>  cursor approach will change in a project.
>>
>>  If people feel strongly that css is the way to go though, I can change
> the
>>  code to add and remove css classes on the map div.
>>
>>  What I've done is briefly:
>>
>>  * add a cursor property on the Control class, which is set on the map
> div
>>  when the control is activated
>>  * add a cursors property (array) on the Handler class, which makes it
>>  possible to set cursors on the map div in different functions of a
> Handler
>>  (like mousedown). For now I've only implemented mousedown and mouseup
> in
>>  the Drag Handler as an example.
>>
>>  I think the example and the patch tells the rest of the story best.
>>
>>  Feedback very much welcome. TIA.
>>
>>  Best regards,
>>  Bart
>>
>>  _______________________________________________
>>  Dev mailing list
>>  Dev@openlayers.org
>>  http://openlayers.org/mailman/listinfo/dev
>>
> 
> 
> 
> --
> Zac Spitzer -
> http://zacster.blogspot.com (My Blog)
> +61 405 847 168


From meat_catch at p0mi.com  Wed Apr 23 10:46:37 2008
From: meat_catch at p0mi.com (danguyf)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Know of any offline datasets compatible with
 OpenLayers?
In-Reply-To: <20071123134441.GA2090@metacarta.com>
References: <a0a470f10711221236x6f27edc4t1848d12afe7374c0@mail.gmail.com>
	<20071122213521.GB11457@metacarta.com>
	<a0a470f10711230107w6b355211ne92c5fd9fcef6a6f@mail.gmail.com>
	<20071123134441.GA2090@metacarta.com>
Message-ID: <16834640.post@talk.nabble.com>




Christopher Schmidt-4 wrote:
> 
> On Fri, Nov 23, 2007 at 09:07:47AM +0000, Ian Mayo wrote:
>> > Totally offline data can be easy... if it is small or your storage is
>> > big. Storing the top 7 levels of the vmap0 dataset as tiles
>> > is something like 200MB of data. Depending what you actually want to
>> do,
>> > this might be useful or not -- but I'm almost positive that it's going
>> > to be more useful than trying to actually draw the world as a vector.
>> 
>> I presume you're describing the use of a standalone mapping server to
>> support the OpenLayer instance. 
> 
> Nope. I've done it in the past (http://labs.metacarta.com/on-a-stick/)
> by pre-generating a cache using TileCache, then using the
> Layer.TileCache class to access it.  
> 

I tried out v1.0, but I don't see the cache and, when attempting to use it
offline, the tiles are all missing.  Please advise.  Thank you.


d.
-- 
View this message in context: http://www.nabble.com/Know-of-any-offline-datasets-compatible-with-OpenLayers--tp13903025p16834640.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From ks at geograf.dk  Thu Apr 24 08:06:44 2008
From: ks at geograf.dk (Kenneth, GEOGRAF A/S)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Registration
Message-ID: <481077D4.6030203@geograf.dk>

I have followed the instructions on:
http://trac.openlayers.org/wiki/FilingTickets
and emailed the request to the mentioned email address.

I have not yet recieved a reply.
The string I recieved for mkpasswd.cgi was:

ksgeograf:icHwy52vY3FgQ

-- 
Regards, Kenneth, GEOGRAF A/S



From thy at 42.dk  Thu Apr 24 08:23:41 2008
From: thy at 42.dk (Kristian Thy)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Registration
In-Reply-To: <481077D4.6030203@geograf.dk>
References: <481077D4.6030203@geograf.dk>
Message-ID: <20080424122341.GF28031@42.dk>

On Thu, Apr 24, Kenneth, GEOGRAF A/S wrote:
> The string I recieved for mkpasswd.cgi was:
> 
> ksgeograf:icHwy52vY3FgQ

That's the same code I have on my luggage!

\\kristian
-- 
... et nemo ex vobis interrogat me: ?Quo vadis??

From pedrosimonetti at gmail.com  Thu Apr 24 09:12:28 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Registration
In-Reply-To: <20080424122341.GF28031@42.dk>
References: <481077D4.6030203@geograf.dk> <20080424122341.GF28031@42.dk>
Message-ID: <5b629bbf0804240612n4db26cc6q6e4001e8ec744348@mail.gmail.com>

Hi,

I'm not sure if this solves your problem, but you can use the generic
user/pass:

In the meantime, you can also just login as username/pass: *openlayers* /*
> openlayers*
>

regards,

Pedro Simonetti.

2008/4/24 Kristian Thy <thy@42.dk>:

> On Thu, Apr 24, Kenneth, GEOGRAF A/S wrote:
> > The string I recieved for mkpasswd.cgi was:
> >
> > ksgeograf:icHwy52vY3FgQ
>
> That's the same code I have on my luggage!
>
> \\kristian
> --
> ... et nemo ex vobis interrogat me: ?Quo vadis??
> _______________________________________________
> 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/20080424/10dd72b7/attachment.html
From euzuro at gmail.com  Thu Apr 24 12:16:37 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Registration
In-Reply-To: <481077D4.6030203@geograf.dk>
References: <481077D4.6030203@geograf.dk>
Message-ID: <6ae3fb590804240916r7fd7124ar3b50f2df9880e805@mail.gmail.com>

Kenneth, I have just set up your account. Apologies for the delay --
these things have to be done by hand and sometimes they don't get top
priori

At any rate, you should be all set up now. Welcome to the community!
Erik

On 4/24/08, Kenneth, GEOGRAF A/S <ks@geograf.dk> wrote:
> I have followed the instructions on:
> http://trac.openlayers.org/wiki/FilingTickets
> and emailed the request to the mentioned email address.
>
> I have not yet recieved a reply.
> The string I recieved for mkpasswd.cgi was:
>
> ksgeograf:icHwy52vY3FgQ
>
> --
> Regards, Kenneth, GEOGRAF A/S
>
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From tschaub at openplans.org  Sat Apr 26 17:41:21 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] mouse cursors
In-Reply-To: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>
References: <dc1eee6aad50ccb7d716f816edf7df89@pop02.backbone.tiscomhosting.nl>
Message-ID: <4813A181.1050304@openplans.org>

Hey-

Disregard if this is not relevant here - only going a quick skim.

CSS class names that modify the cursor should be added and removed from 
existing element class names.

That is

class="olControlFoo someCursorClass"
class="olControlFoo someOtherCursorClass"

These class names can be managed (added, removed, existence tested) with 
simple utility methods.  I suggest the following

OpenLayers.Element.hasClassName
OpenLayers.Element.addClassName
OpenLayers.Element.removeClassName

I'll make a ticket and create a patch for these.  To see working code 
that does this, check out:

http://trac.openlayers.org/browser/sandbox/topp/almanac/lib/OpenLayers/BaseTypes/Element.js#L126

(and relevant tests in the tests dir)

All this assumes that you are reusing cursors for multiple controls.

Tim


bartvde@osgis.nl wrote:
> Hi list,
> 
> I've been working a bit on mouse cursors in OL, and would like to request
> some feedback on the current approach.
> 
> I've got an example up in my sandbox:
> http://dev.openlayers.org/sandbox/bartvde/cursor/examples/cursor.html
> 
> And I've added a very preliminary patch to ticket1484:
> http://trac.openlayers.org/attachment/ticket/1484/ticket1484.patch
> 
> I'll try and outline my approach a bit. The most difficult decision I found
> was whether or not to use css. I find it quite a bit of overhead to make
> css classes for all possible cursor combinations. In my case I would need
> the following classes (looks already quite cumbersome to me):
> 
> .olControlZoomBoxCursor
> .olControlZoomBoxOutCursor
> .olControlDragPanCursor
> .olControlDragPanMouseupCursor
> .olControlDragPanMousedownCursor
> 
> etc.? As you can see, even control properties (like the out property for
> ZoomBox) come into play, so we would need something like a cursorClass
> property for people to override the default class names. For the approach
> to work, we would need them to start their names with the 'olControl'
> prefix, otherwise we don't know which css classes are safe to remove from
> the map div when e.g. a different control is activated (we cannot just
> remove any css class from the map div, since people might have set stuff on
> it, so we should remove all classes that start with 'olControl' or some
> similar approach). This can be error-prone IMHO.
> 
> I did see there are some utility functions (like addClass, removeClass,
> toggleClass) in topp's almanac sandbox which could be used.
> 
> Disadvantage ofcourse of my approach is that the mouse cursors cannot
> easily be altered by non-programmers, but I wonder how often a chosen
> cursor approach will change in a project.
> 
> If people feel strongly that css is the way to go though, I can change the
> code to add and remove css classes on the map div.
> 
> What I've done is briefly:
> 
> * add a cursor property on the Control class, which is set on the map div
> when the control is activated
> * add a cursors property (array) on the Handler class, which makes it
> possible to set cursors on the map div in different functions of a Handler
> (like mousedown). For now I've only implemented mousedown and mouseup in
> the Drag Handler as an example.
> 
> I think the example and the patch tells the rest of the story best.
> 
> Feedback very much welcome. TIA.
> 
> Best regards,
> Bart
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> !DSPAM:4033,480f1b1977931961014482!
> 


From crschmidt at metacarta.com  Sun Apr 27 01:55:19 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
Message-ID: <20080427055519.GA15078@metacarta.com>

The 2.7 ticket list is a mess. I'd like to put some effort into cleaning
it up, but to be honest, it's a bit of a big job for me alone. 

http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release

We have 105 tickets in this release.

Although some metadata is wrong: 
 * 38 are bugs
 * 57 are features
 * 10 are tasks
 
Some of these have active work being done on them. Some of them just
need a thorough review. Some of them are probably not being actively
worked on, or are just an idea.

I think that if there is a ticket here that you consider yourself
'owner' of -- for example, if you reported it -- and you are no longer
actively working on this ticket, that you move it to a different
milestone than the 2.7 milestone. There is one for 2.8 -- if you're not
currently working on it, but you still intend to at some near-future
point, that might be a good place to put it. If you don't intend to get
back to it, but you're still interested in the functionality, please
feel free to toss it to the "Future" milestone. Note that this is all
just my opinion, since we don't have any strong rules on this... would
love to hear others opinions.

I don't think we have any specific plans for 2.7 at this point, but I'd
personally like to keep our releases a bit more release-early
release-often than 2.6 ended up being, and the current 100+ tickets that
are open is just a bit overwhelming for me...

Looking forward to hearing/seeing more discussion.

Regards,
-- 
Christopher Schmidt
MetaCarta

From radiceski at gmail.com  Sun Apr 27 08:04:28 2008
From: radiceski at gmail.com (Darko Radiceski)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Draw a polygon on the map
Message-ID: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>

Dear all,

I have been playing for the last few hours with no success to draw a polygon
through code.

What i would like to do is:

I have a button that when i press it returns me the bouds of a particular
aerial image. That is 4 pairs of Lat,Lon for the image polygon.

I would like to get those coordinates and from that generate a polygon that
i can show on the map to represent the extent of that image.

Is that possible?

Any help for doing that please?

I really apreciate your help.

Cheers
Dan

-- 
Radiceski Darko
University of Wollongong
Australia
SIFE - UOW Chapter - Alumni
CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
(School of Information Technology and Computer Science,University of
Wollongong)
Univeristy of Wollongong - Alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080427/609c40a5/attachment.html
From pedrosimonetti at gmail.com  Sun Apr 27 09:12:01 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Draw a polygon on the map
In-Reply-To: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>
References: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>
Message-ID: <5b629bbf0804270612g4e6fdde1i1aa4ee282f1857ca@mail.gmail.com>

Hi Darko,

Yes, it is possible. Take a look on this:

http://openlayers.org/dev/examples/setextent.html

You just need 2 pairs of lat/long, the (minx, miny) and (maxx, maxy).

regards,

Pedro Simonetti.

2008/4/27 Darko Radiceski <radiceski@gmail.com>:

> Dear all,
>
> I have been playing for the last few hours with no success to draw a
> polygon through code.
>
> What i would like to do is:
>
> I have a button that when i press it returns me the bouds of a particular
> aerial image. That is 4 pairs of Lat,Lon for the image polygon.
>
> I would like to get those coordinates and from that generate a polygon
> that i can show on the map to represent the extent of that image.
>
> Is that possible?
>
> Any help for doing that please?
>
> I really apreciate your help.
>
> Cheers
> Dan
>
> --
> Radiceski Darko
> University of Wollongong
> Australia
> SIFE - UOW Chapter - Alumni
> CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> (School of Information Technology and Computer Science,University of
> Wollongong)
> Univeristy of Wollongong - Alumni
>
> _______________________________________________
> 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/20080427/f831f8d5/attachment.html
From radiceski at gmail.com  Sun Apr 27 09:46:21 2008
From: radiceski at gmail.com (Darko Radiceski)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Draw a polygon on the map
In-Reply-To: <5b629bbf0804270612g4e6fdde1i1aa4ee282f1857ca@mail.gmail.com>
References: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>
	<5b629bbf0804270612g4e6fdde1i1aa4ee282f1857ca@mail.gmail.com>
Message-ID: <1bcf9b2c0804270646u5c075d09p678759a1f9f002b6@mail.gmail.com>

Hello all,

I had a look at the example but that doesnt help,

I have the 4 corners of the polygon. Its not a rectangle but irregular
polygon.

Any advice?



On Sun, Apr 27, 2008 at 11:12 PM, Pedro Simonetti Garcia <
pedrosimonetti@gmail.com> wrote:

> Hi Darko,
>
> Yes, it is possible. Take a look on this:
>
> http://openlayers.org/dev/examples/setextent.html
>
> You just need 2 pairs of lat/long, the (minx, miny) and (maxx, maxy).
>
> regards,
>
> Pedro Simonetti.
>
> 2008/4/27 Darko Radiceski <radiceski@gmail.com>:
>
> >   Dear all,
> >
> > I have been playing for the last few hours with no success to draw a
> > polygon through code.
> >
> > What i would like to do is:
> >
> > I have a button that when i press it returns me the bouds of a
> > particular aerial image. That is 4 pairs of Lat,Lon for the image polygon.
> >
> > I would like to get those coordinates and from that generate a polygon
> > that i can show on the map to represent the extent of that image.
> >
> > Is that possible?
> >
> > Any help for doing that please?
> >
> > I really apreciate your help.
> >
> > Cheers
> > Dan
> >
> > --
> > Radiceski Darko
> > University of Wollongong
> > Australia
> > SIFE - UOW Chapter - Alumni
> > CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> > (School of Information Technology and Computer Science,University of
> > Wollongong)
> > Univeristy of Wollongong - Alumni
> >
> > _______________________________________________
> > Dev mailing list
> > Dev@openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >
> >
>


-- 
Radiceski Darko
University of Wollongong
Australia
SIFE - UOW Chapter - Alumni
CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
(School of Information Technology and Computer Science,University of
Wollongong)
Univeristy of Wollongong - Alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080427/a3c9db74/attachment.html
From pedrosimonetti at gmail.com  Sun Apr 27 09:48:39 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <20080427055519.GA15078@metacarta.com>
References: <20080427055519.GA15078@metacarta.com>
Message-ID: <5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>

Hi Christopher,

I'm new to OL community, so I don't know all the internal
proceedings / rules to report bugs, write tickets, and so on.
So, forgive me if I skip some steps.

I wrote the tickets #327 e #1519 of this list.

http://trac.openlayers.org/ticket/327
http://trac.openlayers.org/ticket/1519

I also wrote a comment on issue #1108, which is related to
the #864 that is flagged to 2.7 milestone.

http://trac.openlayers.org/ticket/1108
http://trac.openlayers.org/ticket/864

I'm also the author of the #1518, which is related to the #1519:

http://trac.openlayers.org/ticket/1518

And I wish to help with this issues, but I'm not sure
exactly how to proceed. I reported those tickets using a
anonymous username/pass. Should I create a account
and post a comment in those tickets to make easier future
discussions about them?

If you are interested in my help, please let me know.

my best regards,

Pedro Simonetti.

2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:

> The 2.7 ticket list is a mess. I'd like to put some effort into cleaning
> it up, but to be honest, it's a bit of a big job for me alone.
>
>
> http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release
>
> We have 105 tickets in this release.
>
> Although some metadata is wrong:
>  * 38 are bugs
>  * 57 are features
>  * 10 are tasks
>
> Some of these have active work being done on them. Some of them just
> need a thorough review. Some of them are probably not being actively
> worked on, or are just an idea.
>
> I think that if there is a ticket here that you consider yourself
> 'owner' of -- for example, if you reported it -- and you are no longer
> actively working on this ticket, that you move it to a different
> milestone than the 2.7 milestone. There is one for 2.8 -- if you're not
> currently working on it, but you still intend to at some near-future
> point, that might be a good place to put it. If you don't intend to get
> back to it, but you're still interested in the functionality, please
> feel free to toss it to the "Future" milestone. Note that this is all
> just my opinion, since we don't have any strong rules on this... would
> love to hear others opinions.
>
> I don't think we have any specific plans for 2.7 at this point, but I'd
> personally like to keep our releases a bit more release-early
> release-often than 2.6 ended up being, and the current 100+ tickets that
> are open is just a bit overwhelming for me...
>
> Looking forward to hearing/seeing more discussion.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> 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/20080427/0849a20d/attachment.html
From pedrosimonetti at gmail.com  Sun Apr 27 10:04:00 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Draw a polygon on the map
In-Reply-To: <1bcf9b2c0804270646u5c075d09p678759a1f9f002b6@mail.gmail.com>
References: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>
	<5b629bbf0804270612g4e6fdde1i1aa4ee282f1857ca@mail.gmail.com>
	<1bcf9b2c0804270646u5c075d09p678759a1f9f002b6@mail.gmail.com>
Message-ID: <5b629bbf0804270704l557f9621wbb8a7d226041823f@mail.gmail.com>

Hi Darko,

Sorry, whe you said "bouds" I thought that you was talking about a
rectangle.

I don't know how to do it. I've looked at the documentation, but I didn't
find info on
that. But I suggest you take a look at the source code of the
OpenLayers.Control.DrawFeatute.

I hope this helps,

regards,

Pedro Simonetti.

2008/4/27 Darko Radiceski <radiceski@gmail.com>:

> Hello all,
>
> I had a look at the example but that doesnt help,
>
> I have the 4 corners of the polygon. Its not a rectangle but irregular
> polygon.
>
> Any advice?
>
>
>
> On Sun, Apr 27, 2008 at 11:12 PM, Pedro Simonetti Garcia <
> pedrosimonetti@gmail.com> wrote:
>
> > Hi Darko,
> >
> > Yes, it is possible. Take a look on this:
> >
> > http://openlayers.org/dev/examples/setextent.html
> >
> > You just need 2 pairs of lat/long, the (minx, miny) and (maxx, maxy).
> >
> > regards,
> >
> > Pedro Simonetti.
> >
> > 2008/4/27 Darko Radiceski <radiceski@gmail.com>:
> >
> > >   Dear all,
> > >
> > > I have been playing for the last few hours with no success to draw a
> > > polygon through code.
> > >
> > > What i would like to do is:
> > >
> > > I have a button that when i press it returns me the bouds of a
> > > particular aerial image. That is 4 pairs of Lat,Lon for the image polygon.
> > >
> > > I would like to get those coordinates and from that generate a polygon
> > > that i can show on the map to represent the extent of that image.
> > >
> > > Is that possible?
> > >
> > > Any help for doing that please?
> > >
> > > I really apreciate your help.
> > >
> > > Cheers
> > > Dan
> > >
> > > --
> > > Radiceski Darko
> > > University of Wollongong
> > > Australia
> > > SIFE - UOW Chapter - Alumni
> > > CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> > > (School of Information Technology and Computer Science,University of
> > > Wollongong)
> > > Univeristy of Wollongong - Alumni
> > >
> > > _______________________________________________
> > > Dev mailing list
> > > Dev@openlayers.org
> > > http://openlayers.org/mailman/listinfo/dev
> > >
> > >
> >
>
>
> --
> Radiceski Darko
> University of Wollongong
> Australia
> SIFE - UOW Chapter - Alumni
> CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> (School of Information Technology and Computer Science,University of
> Wollongong)
> Univeristy of Wollongong - Alumni
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080427/8eb592bc/attachment.html
From tschaub at openplans.org  Sun Apr 27 12:42:51 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] popups
Message-ID: <4814AD0B.5060809@openplans.org>

Hey-

Can someone describe the following to me:

1) OpenLayers.Popup
2) OpenLayers.Popup.Anchored
3) OpenLayers.Popup.AnchoredBubble
4) OpenLayers.Popup.Framed
5) OpenLayers.Popup.FramedCloud

Seems to me like all popups are "anchored" and I can't tell what is the 
implied distinction in the words "bubble" and "cloud".

Here are all the docs I've been able to find on popups:

http://trac.openlayers.org/wiki/FrequentlyAskedQuestions#Whydontbordersshowuponmypopups
http://dev.openlayers.org/docs/files/OpenLayers/Popup-js.html
http://dev.openlayers.org/docs/files/OpenLayers/Popup/Anchored-js.html
http://dev.openlayers.org/docs/files/OpenLayers/Popup/AnchoredBubble-js.html
http://dev.openlayers.org/docs/files/OpenLayers/Popup/Framed-js.html
http://dev.openlayers.org/docs/files/OpenLayers/Popup/FramedCloud-js.html

None of the above shed much light on the question "why so many, and 
which to use when?"  I also see the popupMatrix.html example but I think 
this is supposed to be a manual acceptance test instead of an 
educational example.

Thanks for any help (preferably in the form of natural docs and/or wiki 
pages).

Tim

From crschmidt at metacarta.com  Sun Apr 27 15:01:13 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] popups
In-Reply-To: <4814AD0B.5060809@openplans.org>
References: <4814AD0B.5060809@openplans.org>
Message-ID: <20080427190112.GA26846@metacarta.com>

On Sun, Apr 27, 2008 at 10:42:51AM -0600, Tim Schaub wrote:
> Hey-
> 
> Can someone describe the following to me:
> 
> 1) OpenLayers.Popup

Simple div. Tied to a lat/lon, not an object. Always opens in a single
direction. Generally not used: doesn't fit itself to the right area of
the map, and doesn't provide a 'pretty' UI.

> 2) OpenLayers.Popup.Anchored

Simple div, tied to an object (like a marker) which provides an
'offset'. The offset is used to place the popup based on the lonlat, and
the offset, based on the preferred relative position -- top left, bottom
right, etc. Thsi is automatically calculated based on where the lonlat
is in the map, designed to open the popup in the directin with the most
space.

> 3) OpenLayers.Popup.AnchoredBubble

Same as above, but with rounded corners using Rico.Corner.

> 4) OpenLayers.Popup.Framed

Base class for image-based popups, which can be fixedRelativePosition or
not. An image (defined in a property of the popup) is used to create the
"GUI" aspect of the popup. A base class, this is never meant to be used
excpet for extension.

> 5) OpenLayers.Popup.FramedCloud

A specific instance of the above: Provides image properties for a popup.


> Seems to me like all popups are "anchored" and I can't tell what is the 
> implied distinction in the words "bubble" and "cloud".

Anchored means 'has an offset, and can be offset relative to the
position of its 'anchor''

> None of the above shed much light on the question "why so many, and 
> which to use when?"  

I don't know if thsi helps at all, but, there it is.

Regards,
-- 
Christopher Schmidt
MetaCarta

From john.frank at metacarta.com  Sun Apr 27 15:46:13 2008
From: john.frank at metacarta.com (John R. Frank)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] broken VE layer in baseLayers.html
Message-ID: <Pine.LNX.4.56.0804271545321.29362@jackson.metacarta.com>

Is the VE layer in this example expected to work?

http://openlayers.org/dev/examples/baseLayers.html


From crschmidt at metacarta.com  Sun Apr 27 20:29:58 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
References: <20080427055519.GA15078@metacarta.com>
	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
Message-ID: <20080428002958.GA31086@metacarta.com>

On Sun, Apr 27, 2008 at 10:48:39AM -0300, Pedro Simonetti Garcia wrote:
> Hi Christopher,
> 
> I'm new to OL community, so I don't know all the internal
> proceedings / rules to report bugs, write tickets, and so on.
> So, forgive me if I skip some steps.
> 
> I wrote the tickets #327 e #1519 of this list.
> 
> http://trac.openlayers.org/ticket/327

Right, I need to respond to this one, as the de facto maintainer of the
ka-Map integration with OpenLayers. What it comes down to, breifly, is
that I believe the fixes you have described should be happening
upstream, with the ka-Map project, and that instead of having tile.php
in the OpenLayers examples, we should simply remove it totally.
Similarly, 1518 below: the precache.php.txt file does not belong in
OpenLayers, but I don't see anything particularly wrong with the
KaMapCache layer, if you're interested in it.

> http://trac.openlayers.org/ticket/1519

This is simple, and I just haven't learned enough about translations to
test them yet, so I haven't done anything with it. It looksfine in
general.

> I also wrote a comment on issue #1108, which is related to
> the #864 that is flagged to 2.7 milestone.
> 
> http://trac.openlayers.org/ticket/1108
> http://trac.openlayers.org/ticket/864
> 
> I'm also the author of the #1518, which is related to the #1519:
> 
> And I wish to help with this issues, but I'm not sure
> exactly how to proceed. I reported those tickets using a
> anonymous username/pass. Should I create a account
> and post a comment in those tickets to make easier future
> discussions about them?

That would be good, yeah.

Your patches, in general, look fine, and I'm glad to know you're still
aware of them and looking to push them forward. So long as that's the
case, there's no problem leaving them in the current milestone. I'm
mosty looking to push a lot of things that people have opened and
forgotten about forward, if there is no active work on them.

Any further comments on your tickets, I'll do through trac/seperate
maisl to the list: thanks for the summary, and the hard work!

> If you are interested in my help, please let me know.
> 
> my best regards,
> 
> Pedro Simonetti.
> 
> 2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:
> 
> > The 2.7 ticket list is a mess. I'd like to put some effort into cleaning
> > it up, but to be honest, it's a bit of a big job for me alone.
> >
> >
> > http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release
> >
> > We have 105 tickets in this release.
> >
> > Although some metadata is wrong:
> >  * 38 are bugs
> >  * 57 are features
> >  * 10 are tasks
> >
> > Some of these have active work being done on them. Some of them just
> > need a thorough review. Some of them are probably not being actively
> > worked on, or are just an idea.
> >
> > I think that if there is a ticket here that you consider yourself
> > 'owner' of -- for example, if you reported it -- and you are no longer
> > actively working on this ticket, that you move it to a different
> > milestone than the 2.7 milestone. There is one for 2.8 -- if you're not
> > currently working on it, but you still intend to at some near-future
> > point, that might be a good place to put it. If you don't intend to get
> > back to it, but you're still interested in the functionality, please
> > feel free to toss it to the "Future" milestone. Note that this is all
> > just my opinion, since we don't have any strong rules on this... would
> > love to hear others opinions.
> >
> > I don't think we have any specific plans for 2.7 at this point, but I'd
> > personally like to keep our releases a bit more release-early
> > release-often than 2.6 ended up being, and the current 100+ tickets that
> > are open is just a bit overwhelming for me...
> >
> > Looking forward to hearing/seeing more discussion.
> >
> > Regards,
> > --
> > Christopher Schmidt
> > MetaCarta
> > _______________________________________________
> > Dev mailing list
> > Dev@openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >

-- 
Christopher Schmidt
MetaCarta

From pedrosimonetti at gmail.com  Sun Apr 27 21:58:59 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <20080428002958.GA31086@metacarta.com>
References: <20080427055519.GA15078@metacarta.com>
	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
	<20080428002958.GA31086@metacarta.com>
Message-ID: <5b629bbf0804271858h1d8247b8lcbdb101ce7969a34@mail.gmail.com>

Christopher,

Thanks for the answers, and for the positive feedbacks!

I just have an opinion I would like to share.

...and that instead of having tile.php
> in the OpenLayers examples, we should simply remove it totally.
>

Really? One thing that I liked most in OL is that there are
a lot of examples all in one single place, with all you need
to start playing with OL. In this sense, I think it's  good to
maintaing the php code in there. But that's my humble
thought as a user. As a developer I must agree that it
makes sense putting them on ka-Map only, so future
changes won't require an update on OL example files.

Anyway, I'll follow your recommendation and post those
informations on ka-Map list.

I'll also create an account on OL's trac to easier our
communication about these issues

Any further comments on your tickets, I'll do through trac/seperate
> maisl to the list: thanks for the summary, and the hard work!
>

Sorry, I didn't get it right. Are you saying that future techical
comments should be posted on trac?

regards,

Pedro Simonetti.

2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:

> On Sun, Apr 27, 2008 at 10:48:39AM -0300, Pedro Simonetti Garcia wrote:
> > Hi Christopher,
> >
> > I'm new to OL community, so I don't know all the internal
> > proceedings / rules to report bugs, write tickets, and so on.
> > So, forgive me if I skip some steps.
> >
> > I wrote the tickets #327 e #1519 of this list.
> >
> > http://trac.openlayers.org/ticket/327
>
> Right, I need to respond to this one, as the de facto maintainer of the
> ka-Map integration with OpenLayers. What it comes down to, breifly, is
> that I believe the fixes you have described should be happening
> upstream, with the ka-Map project, and that instead of having tile.php
> in the OpenLayers examples, we should simply remove it totally.
> Similarly, 1518 below: the precache.php.txt file does not belong in
> OpenLayers, but I don't see anything particularly wrong with the
> KaMapCache layer, if you're interested in it.
>
> > http://trac.openlayers.org/ticket/1519
>
> This is simple, and I just haven't learned enough about translations to
> test them yet, so I haven't done anything with it. It looksfine in
> general.
>
> > I also wrote a comment on issue #1108, which is related to
> > the #864 that is flagged to 2.7 milestone.
> >
> > http://trac.openlayers.org/ticket/1108
> > http://trac.openlayers.org/ticket/864
> >
> > I'm also the author of the #1518, which is related to the #1519:
> >
> > And I wish to help with this issues, but I'm not sure
> > exactly how to proceed. I reported those tickets using a
> > anonymous username/pass. Should I create a account
> > and post a comment in those tickets to make easier future
> > discussions about them?
>
> That would be good, yeah.
>
> Your patches, in general, look fine, and I'm glad to know you're still
> aware of them and looking to push them forward. So long as that's the
> case, there's no problem leaving them in the current milestone. I'm
> mosty looking to push a lot of things that people have opened and
> forgotten about forward, if there is no active work on them.
>
> Any further comments on your tickets, I'll do through trac/seperate
> maisl to the list: thanks for the summary, and the hard work!
>
> > If you are interested in my help, please let me know.
> >
> > my best regards,
> >
> > Pedro Simonetti.
> >
> > 2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:
> >
> > > The 2.7 ticket list is a mess. I'd like to put some effort into
> cleaning
> > > it up, but to be honest, it's a bit of a big job for me alone.
> > >
> > >
> > >
> http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release
> > >
> > > We have 105 tickets in this release.
> > >
> > > Although some metadata is wrong:
> > >  * 38 are bugs
> > >  * 57 are features
> > >  * 10 are tasks
> > >
> > > Some of these have active work being done on them. Some of them just
> > > need a thorough review. Some of them are probably not being actively
> > > worked on, or are just an idea.
> > >
> > > I think that if there is a ticket here that you consider yourself
> > > 'owner' of -- for example, if you reported it -- and you are no longer
> > > actively working on this ticket, that you move it to a different
> > > milestone than the 2.7 milestone. There is one for 2.8 -- if you're
> not
> > > currently working on it, but you still intend to at some near-future
> > > point, that might be a good place to put it. If you don't intend to
> get
> > > back to it, but you're still interested in the functionality, please
> > > feel free to toss it to the "Future" milestone. Note that this is all
> > > just my opinion, since we don't have any strong rules on this... would
> > > love to hear others opinions.
> > >
> > > I don't think we have any specific plans for 2.7 at this point, but
> I'd
> > > personally like to keep our releases a bit more release-early
> > > release-often than 2.6 ended up being, and the current 100+ tickets
> that
> > > are open is just a bit overwhelming for me...
> > >
> > > Looking forward to hearing/seeing more discussion.
> > >
> > > Regards,
> > > --
> > > Christopher Schmidt
> > > MetaCarta
> > > _______________________________________________
> > > Dev mailing list
> > > Dev@openlayers.org
> > > http://openlayers.org/mailman/listinfo/dev
> > >
>
> --
> Christopher Schmidt
> MetaCarta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080427/2cfd81ed/attachment.html
From woodbri at swoodbridge.com  Sun Apr 27 23:42:16 2008
From: woodbri at swoodbridge.com (Stephen Woodbridge)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <20080428002958.GA31086@metacarta.com>
References: <20080427055519.GA15078@metacarta.com>	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
	<20080428002958.GA31086@metacarta.com>
Message-ID: <48154798.3060209@swoodbridge.com>

Chris,

I sympathize with your sentiment that tile.php and precache.php not 
being part of OpenLayers, but I think it is very useful to have them 
with the examples, for a couple of reasons.

1) it keeps a version that we know works because it has been tested, 
with the code
2) it makes it easy for people to find these as they may not have come 
from the ka-map project but might still want to use the,

May we should have a contrib directory that these could go into.

Just a thought, whatever you decide will work.

-Steve W

Christopher Schmidt wrote:
> On Sun, Apr 27, 2008 at 10:48:39AM -0300, Pedro Simonetti Garcia wrote:
>> Hi Christopher,
>>
>> I'm new to OL community, so I don't know all the internal
>> proceedings / rules to report bugs, write tickets, and so on.
>> So, forgive me if I skip some steps.
>>
>> I wrote the tickets #327 e #1519 of this list.
>>
>> http://trac.openlayers.org/ticket/327
> 
> Right, I need to respond to this one, as the de facto maintainer of the
> ka-Map integration with OpenLayers. What it comes down to, breifly, is
> that I believe the fixes you have described should be happening
> upstream, with the ka-Map project, and that instead of having tile.php
> in the OpenLayers examples, we should simply remove it totally.
> Similarly, 1518 below: the precache.php.txt file does not belong in
> OpenLayers, but I don't see anything particularly wrong with the
> KaMapCache layer, if you're interested in it.
> 
>> http://trac.openlayers.org/ticket/1519
> 
> This is simple, and I just haven't learned enough about translations to
> test them yet, so I haven't done anything with it. It looksfine in
> general.
> 
>> I also wrote a comment on issue #1108, which is related to
>> the #864 that is flagged to 2.7 milestone.
>>
>> http://trac.openlayers.org/ticket/1108
>> http://trac.openlayers.org/ticket/864
>>
>> I'm also the author of the #1518, which is related to the #1519:
>>
>> And I wish to help with this issues, but I'm not sure
>> exactly how to proceed. I reported those tickets using a
>> anonymous username/pass. Should I create a account
>> and post a comment in those tickets to make easier future
>> discussions about them?
> 
> That would be good, yeah.
> 
> Your patches, in general, look fine, and I'm glad to know you're still
> aware of them and looking to push them forward. So long as that's the
> case, there's no problem leaving them in the current milestone. I'm
> mosty looking to push a lot of things that people have opened and
> forgotten about forward, if there is no active work on them.
> 
> Any further comments on your tickets, I'll do through trac/seperate
> maisl to the list: thanks for the summary, and the hard work!
> 
>> If you are interested in my help, please let me know.
>>
>> my best regards,
>>
>> Pedro Simonetti.
>>
>> 2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:
>>
>>> The 2.7 ticket list is a mess. I'd like to put some effort into cleaning
>>> it up, but to be honest, it's a bit of a big job for me alone.
>>>
>>>
>>> http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release
>>>
>>> We have 105 tickets in this release.
>>>
>>> Although some metadata is wrong:
>>>  * 38 are bugs
>>>  * 57 are features
>>>  * 10 are tasks
>>>
>>> Some of these have active work being done on them. Some of them just
>>> need a thorough review. Some of them are probably not being actively
>>> worked on, or are just an idea.
>>>
>>> I think that if there is a ticket here that you consider yourself
>>> 'owner' of -- for example, if you reported it -- and you are no longer
>>> actively working on this ticket, that you move it to a different
>>> milestone than the 2.7 milestone. There is one for 2.8 -- if you're not
>>> currently working on it, but you still intend to at some near-future
>>> point, that might be a good place to put it. If you don't intend to get
>>> back to it, but you're still interested in the functionality, please
>>> feel free to toss it to the "Future" milestone. Note that this is all
>>> just my opinion, since we don't have any strong rules on this... would
>>> love to hear others opinions.
>>>
>>> I don't think we have any specific plans for 2.7 at this point, but I'd
>>> personally like to keep our releases a bit more release-early
>>> release-often than 2.6 ended up being, and the current 100+ tickets that
>>> are open is just a bit overwhelming for me...
>>>
>>> Looking forward to hearing/seeing more discussion.
>>>
>>> Regards,
>>> --
>>> Christopher Schmidt
>>> MetaCarta
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
> 


From pedrosimonetti at gmail.com  Sun Apr 27 23:28:07 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <48154798.3060209@swoodbridge.com>
References: <20080427055519.GA15078@metacarta.com>
	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
	<20080428002958.GA31086@metacarta.com>
	<48154798.3060209@swoodbridge.com>
Message-ID: <5b629bbf0804272028x16df1ef1ma4f4cc7063922688@mail.gmail.com>

Hi Stephen,

Good to see that I'm not alone with that!

Christopher & Stephen,

I would like to add one thing. I'm convinced that Python is the "server side
language of the future", but a lot of people still uses PHP, or feel more
confortable writing/reading PHP code. Of course, I've chosen using OL+ka-Map
because I was using ka-Map before, but I've decided that also because I'm
not familiar with Python code as with PHP code. So I think that keeping the
php code in examples would be good also to php-like developers.

But as Stephen stated, whatever you choose will work.

my best regards,

Pedro Simonetti.

2008/4/28 Stephen Woodbridge <woodbri@swoodbridge.com>:

> Chris,
>
> I sympathize with your sentiment that tile.php and precache.php not being
> part of OpenLayers, but I think it is very useful to have them with the
> examples, for a couple of reasons.
>
> 1) it keeps a version that we know works because it has been tested, with
> the code
> 2) it makes it easy for people to find these as they may not have come
> from the ka-map project but might still want to use the,
>
> May we should have a contrib directory that these could go into.
>
> Just a thought, whatever you decide will work.
>
> -Steve W
>
>
> Christopher Schmidt wrote:
>
> > On Sun, Apr 27, 2008 at 10:48:39AM -0300, Pedro Simonetti Garcia wrote:
> >
> > > Hi Christopher,
> > >
> > > I'm new to OL community, so I don't know all the internal
> > > proceedings / rules to report bugs, write tickets, and so on.
> > > So, forgive me if I skip some steps.
> > >
> > > I wrote the tickets #327 e #1519 of this list.
> > >
> > > http://trac.openlayers.org/ticket/327
> > >
> >
> > Right, I need to respond to this one, as the de facto maintainer of the
> > ka-Map integration with OpenLayers. What it comes down to, breifly, is
> > that I believe the fixes you have described should be happening
> > upstream, with the ka-Map project, and that instead of having tile.php
> > in the OpenLayers examples, we should simply remove it totally.
> > Similarly, 1518 below: the precache.php.txt file does not belong in
> > OpenLayers, but I don't see anything particularly wrong with the
> > KaMapCache layer, if you're interested in it.
> >
> >  http://trac.openlayers.org/ticket/1519
> > >
> >
> > This is simple, and I just haven't learned enough about translations to
> > test them yet, so I haven't done anything with it. It looksfine in
> > general.
> >
> >  I also wrote a comment on issue #1108, which is related to
> > > the #864 that is flagged to 2.7 milestone.
> > >
> > > http://trac.openlayers.org/ticket/1108
> > > http://trac.openlayers.org/ticket/864
> > >
> > > I'm also the author of the #1518, which is related to the #1519:
> > >
> > > And I wish to help with this issues, but I'm not sure
> > > exactly how to proceed. I reported those tickets using a
> > > anonymous username/pass. Should I create a account
> > > and post a comment in those tickets to make easier future
> > > discussions about them?
> > >
> >
> > That would be good, yeah.
> >
> > Your patches, in general, look fine, and I'm glad to know you're still
> > aware of them and looking to push them forward. So long as that's the
> > case, there's no problem leaving them in the current milestone. I'm
> > mosty looking to push a lot of things that people have opened and
> > forgotten about forward, if there is no active work on them.
> >
> > Any further comments on your tickets, I'll do through trac/seperate
> > maisl to the list: thanks for the summary, and the hard work!
> >
> >  If you are interested in my help, please let me know.
> > >
> > > my best regards,
> > >
> > > Pedro Simonetti.
> > >
> > > 2008/4/27 Christopher Schmidt <crschmidt@metacarta.com>:
> > >
> > >  The 2.7 ticket list is a mess. I'd like to put some effort into
> > > > cleaning
> > > > it up, but to be honest, it's a bit of a big job for me alone.
> > > >
> > > >
> > > >
> > > > http://trac.openlayers.org/query?status=new&status=assigned&status=reopened&group=type&milestone=2.7+Release
> > > >
> > > > We have 105 tickets in this release.
> > > >
> > > > Although some metadata is wrong:
> > > >  * 38 are bugs
> > > >  * 57 are features
> > > >  * 10 are tasks
> > > >
> > > > Some of these have active work being done on them. Some of them just
> > > > need a thorough review. Some of them are probably not being actively
> > > > worked on, or are just an idea.
> > > >
> > > > I think that if there is a ticket here that you consider yourself
> > > > 'owner' of -- for example, if you reported it -- and you are no
> > > > longer
> > > > actively working on this ticket, that you move it to a different
> > > > milestone than the 2.7 milestone. There is one for 2.8 -- if you're
> > > > not
> > > > currently working on it, but you still intend to at some near-future
> > > > point, that might be a good place to put it. If you don't intend to
> > > > get
> > > > back to it, but you're still interested in the functionality, please
> > > > feel free to toss it to the "Future" milestone. Note that this is
> > > > all
> > > > just my opinion, since we don't have any strong rules on this...
> > > > would
> > > > love to hear others opinions.
> > > >
> > > > I don't think we have any specific plans for 2.7 at this point, but
> > > > I'd
> > > > personally like to keep our releases a bit more release-early
> > > > release-often than 2.6 ended up being, and the current 100+ tickets
> > > > that
> > > > are open is just a bit overwhelming for me...
> > > >
> > > > Looking forward to hearing/seeing more discussion.
> > > >
> > > > Regards,
> > > > --
> > > > Christopher Schmidt
> > > > MetaCarta
> > > > _______________________________________________
> > > > 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/20080428/3b471fcd/attachment.html
From tschaub at openplans.org  Mon Apr 28 00:34:08 2008
From: tschaub at openplans.org (Tim Schaub)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] popups
In-Reply-To: <20080427190112.GA26846@metacarta.com>
References: <4814AD0B.5060809@openplans.org>
	<20080427190112.GA26846@metacarta.com>
Message-ID: <481553C0.7080803@openplans.org>

Thanks for the description.  New question.

How do folks like to manage popup destruction?

Seems to me like it would be pretty typical to set "exclusive" to true 
when calling map.addPopup (one popup open at a time).  This means in a 
typical application, a popup would be created by a user click.  The DOM 
elements associated with this popup are removed in another user click. 
This doesn't give much chance for the popup creator to call destroy.

IE6 (unpatched) is horrendous with memory leaks and element.removeChild 
when child elements are listening for events with functions that contain 
cyclic structures.  This seems a pretty obvious source of memory leaks.

IE6 aside, it seems like I must be missing something with regard to a 
simple way to destroy popups.  Is the solution to have the sixth arg to 
the popup constructor (closeBoxCallback) set to something that calls 
destroy?

Tim

Christopher Schmidt wrote:
> On Sun, Apr 27, 2008 at 10:42:51AM -0600, Tim Schaub wrote:
>> Hey-
>>
>> Can someone describe the following to me:
>>
>> 1) OpenLayers.Popup
> 
> Simple div. Tied to a lat/lon, not an object. Always opens in a single
> direction. Generally not used: doesn't fit itself to the right area of
> the map, and doesn't provide a 'pretty' UI.
> 
>> 2) OpenLayers.Popup.Anchored
> 
> Simple div, tied to an object (like a marker) which provides an
> 'offset'. The offset is used to place the popup based on the lonlat, and
> the offset, based on the preferred relative position -- top left, bottom
> right, etc. Thsi is automatically calculated based on where the lonlat
> is in the map, designed to open the popup in the directin with the most
> space.
> 
>> 3) OpenLayers.Popup.AnchoredBubble
> 
> Same as above, but with rounded corners using Rico.Corner.
> 
>> 4) OpenLayers.Popup.Framed
> 
> Base class for image-based popups, which can be fixedRelativePosition or
> not. An image (defined in a property of the popup) is used to create the
> "GUI" aspect of the popup. A base class, this is never meant to be used
> excpet for extension.
> 
>> 5) OpenLayers.Popup.FramedCloud
> 
> A specific instance of the above: Provides image properties for a popup.
> 
> 
>> Seems to me like all popups are "anchored" and I can't tell what is the 
>> implied distinction in the words "bubble" and "cloud".
> 
> Anchored means 'has an offset, and can be offset relative to the
> position of its 'anchor''
> 
>> None of the above shed much light on the question "why so many, and 
>> which to use when?"  
> 
> I don't know if thsi helps at all, but, there it is.
> 
> Regards,


From crschmidt at metacarta.com  Mon Apr 28 08:03:51 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <48154798.3060209@swoodbridge.com>
References: <20080427055519.GA15078@metacarta.com>
	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
	<20080428002958.GA31086@metacarta.com>
	<48154798.3060209@swoodbridge.com>
Message-ID: <20080428120351.GA8859@metacarta.com>

On Sun, Apr 27, 2008 at 10:42:16PM -0500, Stephen Woodbridge wrote:
> Chris,
> 
> I sympathize with your sentiment that tile.php and precache.php not 
> being part of OpenLayers, but I think it is very useful to have them 
> with the examples, for a couple of reasons.
> 
> 1) it keeps a version that we know works because it has been tested, 
> with the code
> 2) it makes it easy for people to find these as they may not have come 
> from the ka-map project but might still want to use the,

So, let's look at other code that this might apply to:

 * TileCache
 * MapServer
 * GeoServer
 * Worldwind tile server
 * GDAL2tiles

All of these have changing versions, some of which will work interact
differently with the outside world between different versions, all of
which might not be the first place that people will look. 

However, I don't think it's a sane expectation that OpenLayers is going
to host the code for any of these.

In fact, the primary reason, in my opinion, that this is special for
ka-Map is two-fold: 

 * The ka-Map project has experienced a long-term dearth of development,
   in part due to the success of OpenLayers as a web-mapping frontend.
   This means that for the past year or more, there has been limited
   support for ka-Map from the people who know it best, and that affects
   many things, like documentation, releases, etc. This happens in Open
   Source, and I'll admit that OpenLayers is at least partially
   responsible, as developer attention has been focused elsewhere.
 * ka-Map was never designed for external use as a separable client and
   server side components. As such, the documentation for the
   server-side components on their own was never particularly seperable,
   and the end result was that the server side was only described as
   part of the whole process.

These two things combine to make ka-Map a less than palatable solution
for users concentrating on OpenLayers, because the server-side
components of ka-Map are not easy to set up using the documentation
available from the ka-Map project at this time. However...

This is not a reason to fork a project!

Make no mistake: maintaining seperate copies of the ka-Map source code
in OpenLayers is a fork. We should not fork any project for convenience:
all the difficulties that exist in using ka-Map in OpenLayers are easily
solvable. Most are solvable without code: documentation is the only
thing that most of these problems need, and documentation can be easily
written in the OpenLayers wiki, the ka-Map wiki, etc. 

Helping the ka-Map project out by working to document a seperable
server-side component, one designed for use in other applications like
OpenLayers, would be useful to many people, and probably not just
OpenLayers. That's the appropriate place to solve the problem of ka-Map
source code not being effectively documented or clearly available:
forking the project is a mistake, and my first step towards doing so
with the tile.php in examples/ was a faux paus that I should have
corrected long ago. If there are people who are interested in solving
problems within the ka-Map code, we should not continue to solve them in
OpenLayers, where only OpenLayers users benefit.

Get involved. Help bring life to the ka-Map server side project, kick
out a release, get SVN access, and help out the people who spent so much
time writing the code in the first place.

Regards,
-- 
Christopher Schmidt
MetaCarta

From radiceski at gmail.com  Mon Apr 28 19:47:54 2008
From: radiceski at gmail.com (Darko Radiceski)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Draw a polygon on the map
In-Reply-To: <5b629bbf0804270704l557f9621wbb8a7d226041823f@mail.gmail.com>
References: <1bcf9b2c0804270504i6a4e1132x75b1264387f6b4bf@mail.gmail.com>
	<5b629bbf0804270612g4e6fdde1i1aa4ee282f1857ca@mail.gmail.com>
	<1bcf9b2c0804270646u5c075d09p678759a1f9f002b6@mail.gmail.com>
	<5b629bbf0804270704l557f9621wbb8a7d226041823f@mail.gmail.com>
Message-ID: <1bcf9b2c0804281647j2822c9aaua4cb4ec089f2435c@mail.gmail.com>

Hello all,

Just a note back in regards to what i was trying to do.

I managed to achieve the drawing of polygons and points using the WKT
aproach.

I know what feature i need to draw so i can create the WKT phrase, pass it
to the parser and then draw that.

Works like a charm:)

If anyone needs any help on it or would like to see the code just email us.

Sincerely
Darko



On Mon, Apr 28, 2008 at 12:04 AM, Pedro Simonetti Garcia <
pedrosimonetti@gmail.com> wrote:

> Hi Darko,
>
> Sorry, whe you said "bouds" I thought that you was talking about a
> rectangle.
>
> I don't know how to do it. I've looked at the documentation, but I didn't
> find info on
> that. But I suggest you take a look at the source code of the
> OpenLayers.Control.DrawFeatute.
>
> I hope this helps,
>
>
> regards,
>
> Pedro Simonetti.
>
> 2008/4/27 Darko Radiceski <radiceski@gmail.com>:
>
> > Hello all,
> >
> > I had a look at the example but that doesnt help,
> >
> > I have the 4 corners of the polygon. Its not a rectangle but irregular
> > polygon.
> >
> > Any advice?
> >
> >
> >
> > On Sun, Apr 27, 2008 at 11:12 PM, Pedro Simonetti Garcia <
> > pedrosimonetti@gmail.com> wrote:
> >
> > > Hi Darko,
> > >
> > > Yes, it is possible. Take a look on this:
> > >
> > > http://openlayers.org/dev/examples/setextent.html
> > >
> > > You just need 2 pairs of lat/long, the (minx, miny) and (maxx, maxy).
> > >
> > > regards,
> > >
> > > Pedro Simonetti.
> > >
> > > 2008/4/27 Darko Radiceski <radiceski@gmail.com>:
> > >
> > > >   Dear all,
> > > >
> > > > I have been playing for the last few hours with no success to draw a
> > > > polygon through code.
> > > >
> > > > What i would like to do is:
> > > >
> > > > I have a button that when i press it returns me the bouds of a
> > > > particular aerial image. That is 4 pairs of Lat,Lon for the image polygon.
> > > >
> > > > I would like to get those coordinates and from that generate a
> > > > polygon that i can show on the map to represent the extent of that image.
> > > >
> > > > Is that possible?
> > > >
> > > > Any help for doing that please?
> > > >
> > > > I really apreciate your help.
> > > >
> > > > Cheers
> > > > Dan
> > > >
> > > > --
> > > > Radiceski Darko
> > > > University of Wollongong
> > > > Australia
> > > > SIFE - UOW Chapter - Alumni
> > > > CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> > > > (School of Information Technology and Computer Science,University of
> > > > Wollongong)
> > > > Univeristy of Wollongong - Alumni
> > > >
> > > > _______________________________________________
> > > > Dev mailing list
> > > > Dev@openlayers.org
> > > > http://openlayers.org/mailman/listinfo/dev
> > > >
> > > >
> > >
> >
> >
> > --
> > Radiceski Darko
> > University of Wollongong
> > Australia
> > SIFE - UOW Chapter - Alumni
> > CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
> > (School of Information Technology and Computer Science,University of
> > Wollongong)
> > Univeristy of Wollongong - Alumni
> >
>
>


-- 
Radiceski Darko
University of Wollongong
Australia
SIFE - UOW Chapter - Alumni
CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
(School of Information Technology and Computer Science,University of
Wollongong)
Univeristy of Wollongong - Alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080429/9379b877/attachment.html
From euzuro at gmail.com  Mon Apr 28 20:02:33 2008
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] popups
In-Reply-To: <481553C0.7080803@openplans.org>
References: <4814AD0B.5060809@openplans.org>
	<20080427190112.GA26846@metacarta.com>
	<481553C0.7080803@openplans.org>
Message-ID: <6ae3fb590804281702x6dee8302g6eedb8b0d79dcd5f@mail.gmail.com>

On Sun, Apr 27, 2008 at 11:34 PM, Tim Schaub <tschaub@openplans.org> wrote:
> Thanks for the description.  New question.
>
> How do folks like to manage popup destruction?
>
> Seems to me like it would be pretty typical to set "exclusive" to true
> when calling map.addPopup (one popup open at a time).  This means in a
> typical application, a popup would be created by a user click.  The DOM
> elements associated with this popup are removed in another user click.
> This doesn't give much chance for the popup creator to call destroy.
>
> IE6 (unpatched) is horrendous with memory leaks and element.removeChild
> when child elements are listening for events with functions that contain
> cyclic structures.  This seems a pretty obvious source of memory leaks.
>
> IE6 aside, it seems like I must be missing something with regard to a
> simple way to destroy popups.  Is the solution to have the sixth arg to
> the popup constructor (closeBoxCallback) set to something that calls
> destroy?

yes, i think that is probably the best way to go about it nowadays. the
exclusive parameter was something i added many moons ago, when i was
just a young ajaxer and even younger ol-er. it and virtually everything else
about the popup API is to be firmly blamed on me.

these are among the many things that must be thoroughly re-thought-out
when we start the 3.0 discussions.

if you want to get into this further, find me on IM. i'm ready and willing.
erik





> Tim
>
>
> Christopher Schmidt wrote:
> > On Sun, Apr 27, 2008 at 10:42:51AM -0600, Tim Schaub wrote:
> >> Hey-
> >>
> >> Can someone describe the following to me:
> >>
> >> 1) OpenLayers.Popup
> >
> > Simple div. Tied to a lat/lon, not an object. Always opens in a single
> > direction. Generally not used: doesn't fit itself to the right area of
> > the map, and doesn't provide a 'pretty' UI.
> >
> >> 2) OpenLayers.Popup.Anchored
> >
> > Simple div, tied to an object (like a marker) which provides an
> > 'offset'. The offset is used to place the popup based on the lonlat, and
> > the offset, based on the preferred relative position -- top left, bottom
> > right, etc. Thsi is automatically calculated based on where the lonlat
> > is in the map, designed to open the popup in the directin with the most
> > space.
> >
> >> 3) OpenLayers.Popup.AnchoredBubble
> >
> > Same as above, but with rounded corners using Rico.Corner.
> >
> >> 4) OpenLayers.Popup.Framed
> >
> > Base class for image-based popups, which can be fixedRelativePosition or
> > not. An image (defined in a property of the popup) is used to create the
> > "GUI" aspect of the popup. A base class, this is never meant to be used
> > excpet for extension.
> >
> >> 5) OpenLayers.Popup.FramedCloud
> >
> > A specific instance of the above: Provides image properties for a popup.
> >
> >
> >> Seems to me like all popups are "anchored" and I can't tell what is the
> >> implied distinction in the words "bubble" and "cloud".
> >
> > Anchored means 'has an offset, and can be offset relative to the
> > position of its 'anchor''
> >
> >> None of the above shed much light on the question "why so many, and
> >> which to use when?"
> >
> > I don't know if thsi helps at all, but, there it is.
> >
> > Regards,
>
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

From pedrosimonetti at gmail.com  Mon Apr 28 21:10:14 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] 2.7 ticket list
In-Reply-To: <20080428120351.GA8859@metacarta.com>
References: <20080427055519.GA15078@metacarta.com>
	<5b629bbf0804270648v7ca2bd95k1b044d68efb7dc90@mail.gmail.com>
	<20080428002958.GA31086@metacarta.com>
	<48154798.3060209@swoodbridge.com>
	<20080428120351.GA8859@metacarta.com>
Message-ID: <5b629bbf0804281810t7a256de7l9688d2d34a325fd0@mail.gmail.com>

Christopher,

This is not a reason to fork a project!
>

Okay, you've convinced myself :)

Since OL is a front-end application, isn't appropriate to
maintaing server code in it.

I'll create an account in OL's track to get involved with the
KaMapCache layer.

Meanwhile, I'll communicate with the ka-Map list, and start
writing a basic how-to ka-Map+OL. If there's anyone else
interested in help, it will me much appreciated.

regards,

Pedro Simonetti.

2008/4/28 Christopher Schmidt <crschmidt@metacarta.com>:

> On Sun, Apr 27, 2008 at 10:42:16PM -0500, Stephen Woodbridge wrote:
> > Chris,
> >
> > I sympathize with your sentiment that tile.php and precache.php not
> > being part of OpenLayers, but I think it is very useful to have them
> > with the examples, for a couple of reasons.
> >
> > 1) it keeps a version that we know works because it has been tested,
> > with the code
> > 2) it makes it easy for people to find these as they may not have come
> > from the ka-map project but might still want to use the,
>
> So, let's look at other code that this might apply to:
>
>  * TileCache
>  * MapServer
>  * GeoServer
>  * Worldwind tile server
>  * GDAL2tiles
>
> All of these have changing versions, some of which will work interact
> differently with the outside world between different versions, all of
> which might not be the first place that people will look.
>
> However, I don't think it's a sane expectation that OpenLayers is going
> to host the code for any of these.
>
> In fact, the primary reason, in my opinion, that this is special for
> ka-Map is two-fold:
>
>  * The ka-Map project has experienced a long-term dearth of development,
>   in part due to the success of OpenLayers as a web-mapping frontend.
>   This means that for the past year or more, there has been limited
>   support for ka-Map from the people who know it best, and that affects
>   many things, like documentation, releases, etc. This happens in Open
>   Source, and I'll admit that OpenLayers is at least partially
>   responsible, as developer attention has been focused elsewhere.
>  * ka-Map was never designed for external use as a separable client and
>   server side components. As such, the documentation for the
>   server-side components on their own was never particularly seperable,
>   and the end result was that the server side was only described as
>   part of the whole process.
>
> These two things combine to make ka-Map a less than palatable solution
> for users concentrating on OpenLayers, because the server-side
> components of ka-Map are not easy to set up using the documentation
> available from the ka-Map project at this time. However...
>
> This is not a reason to fork a project!
>
> Make no mistake: maintaining seperate copies of the ka-Map source code
> in OpenLayers is a fork. We should not fork any project for convenience:
> all the difficulties that exist in using ka-Map in OpenLayers are easily
> solvable. Most are solvable without code: documentation is the only
> thing that most of these problems need, and documentation can be easily
> written in the OpenLayers wiki, the ka-Map wiki, etc.
>
> Helping the ka-Map project out by working to document a seperable
> server-side component, one designed for use in other applications like
> OpenLayers, would be useful to many people, and probably not just
> OpenLayers. That's the appropriate place to solve the problem of ka-Map
> source code not being effectively documented or clearly available:
> forking the project is a mistake, and my first step towards doing so
> with the tile.php in examples/ was a faux paus that I should have
> corrected long ago. If there are people who are interested in solving
> problems within the ka-Map code, we should not continue to solve them in
> OpenLayers, where only OpenLayers users benefit.
>
> Get involved. Help bring life to the ka-Map server side project, kick
> out a release, get SVN access, and help out the people who spent so much
> time writing the code in the first place.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080428/855fe2d7/attachment.html
From jcopes at harris.com  Tue Apr 29 13:31:25 2008
From: jcopes at harris.com (Copes, Jeff)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
Message-ID: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>

All,

I have not been able to connect MapServer to OpenLayers using TileIndex
directive in Mapserver. Has anyone been able to do this?

There are four geoTIFFs in the directory /ms4w/apps/ms_tiles/data/tiles.
gdaltindex made a tileindex shapfile G15Tiles.shp in the same directory
as the data. The output G15Tiles.shp has the correct entries for each of
the four images to be mosaicked and the correct overall bounding box for
the mosaic. The MapServer mapfile has the following entry:

LAYER
  NAME G15Tiles
  GROUP "Imagery"
  PROJECTION
   "init=epsg:4326"
  END
  TYPE RASTER
  DUMP TRUE
  STATUS DEFAULT
  # where the tiles are
  TILEINDEX "/ms4w/apps/ms_tiles/data/tiles/G15Tiles.shp"
  TILEITEM "../data/tiles/"
    
   more metadata items 
    
END

This is the layer creation code in OpenLayers:

        var map;
        window.onload = function(){
        map = new OpenLayers.Map('map',{ controls: [] }, {maxResolution:
'auto'} );
        var g15tiles = new OpenLayers.Layer.MapServer("G15Tiles",
	
"http://dnocc8036:8090/cgi-bin/ms_tiles",
	
{layers: 'G15Tiles'});
       map.addLayer(g15tiles);

The OpenLayers HTML page gives two pink boxes. Is there anyone who knows
about MapServer + Tile Mosaics + OpenLayers who can help? 

Thanks,

Jeff Copes
Harris Corporation
Enterprise Architecture COE - Geospatial Systems
(321) 984-6556

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080429/3edaef9b/attachment.html
From pedrosimonetti at gmail.com  Tue Apr 29 13:41:07 2008
From: pedrosimonetti at gmail.com (Pedro Simonetti Garcia)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
In-Reply-To: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
References: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
Message-ID: <5b629bbf0804291041n2b153d85xb05c03d3a720169a@mail.gmail.com>

Hi Jeff,

I never worked with MapServer + Tile Mosaics + OpenLayers, so I don't
have much to share with you.

But here goes a small suggestion. Have you ever tried to use the
"shp2img" command line tool to verify if MapServer is rendering
correctly the mapfile? If you can't generate a proper image with
shp2img it may indicate that you have a problem in your mapfile
configuration.

I hope this helps,

Pedro Simonetti.

2008/4/29 Copes, Jeff <jcopes@harris.com>:
>
>
>
> All,
>
> I have not been able to connect MapServer to OpenLayers using TileIndex
> directive in Mapserver. Has anyone been able to do this?
>
> There are four geoTIFFs in the directory /ms4w/apps/ms_tiles/data/tiles.
> gdaltindex made a tileindex shapfile G15Tiles.shp in the same directory as
> the data. The output G15Tiles.shp has the correct entries for each of the
> four images to be mosaicked and the correct overall bounding box for the
> mosaic. The MapServer mapfile has the following entry:
>
> LAYER
>   NAME G15Tiles
>   GROUP "Imagery"
>   PROJECTION
>    "init=epsg:4326"
>   END
>   TYPE RASTER
>   DUMP TRUE
>   STATUS DEFAULT
>   # where the tiles are
>   TILEINDEX "/ms4w/apps/ms_tiles/data/tiles/G15Tiles.shp"
>   TILEITEM "../data/tiles/"
>
>    more metadata items
>
> END
>
> This is the layer creation code in OpenLayers:
>
>         var map;
>         window.onload = function(){
>         map = new OpenLayers.Map('map',{ controls: [] }, {maxResolution:
> 'auto'} );
>         var g15tiles = new OpenLayers.Layer.MapServer("G15Tiles",
>
> "http://dnocc8036:8090/cgi-bin/ms_tiles",
>
> {layers: 'G15Tiles'});
>        map.addLayer(g15tiles);
>
> The OpenLayers HTML page gives two pink boxes. Is there anyone who knows
> about MapServer + Tile Mosaics + OpenLayers who can help?
>
> Thanks,
>
> Jeff Copes
> Harris Corporation
> Enterprise Architecture COE ? Geospatial Systems
> (321) 984-6556
>
>
>
>
> _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>
>

From jcopes at harris.com  Tue Apr 29 13:42:59 2008
From: jcopes at harris.com (Copes, Jeff)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
In-Reply-To: <5b629bbf0804291041n2b153d85xb05c03d3a720169a@mail.gmail.com>
References: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
	<5b629bbf0804291041n2b153d85xb05c03d3a720169a@mail.gmail.com>
Message-ID: <05A0487071106E4EA6F14A60A5381F16B8D6F1@mlbe2k5.cs.myharris.net>

Pedro,

Thank you for the suggestion. I am writing a map now to bypass
OpenLayers to isolate the issue. I think your suggestion is a more
appropriate first test step and will do that first.

Thanks,

Jeff 

-----Original Message-----
From: Pedro Simonetti Garcia [mailto:pedrosimonetti@gmail.com] 
Sent: Tuesday, April 29, 2008 1:41 PM
To: Copes, Jeff
Cc: dev@openlayers.org; Jordan, Thomas; Ingersoll, Mark
Subject: Re: [OpenLayers-Dev] Mapserver Mosaics with Tileindex


Hi Jeff,

I never worked with MapServer + Tile Mosaics + OpenLayers, so I don't
have much to share with you.

But here goes a small suggestion. Have you ever tried to use the
"shp2img" command line tool to verify if MapServer is rendering
correctly the mapfile? If you can't generate a proper image with
shp2img it may indicate that you have a problem in your mapfile
configuration.

I hope this helps,

Pedro Simonetti.

2008/4/29 Copes, Jeff <jcopes@harris.com>:
>
>
>
> All,
>
> I have not been able to connect MapServer to OpenLayers using
TileIndex
> directive in Mapserver. Has anyone been able to do this?
>
> There are four geoTIFFs in the directory
/ms4w/apps/ms_tiles/data/tiles.
> gdaltindex made a tileindex shapfile G15Tiles.shp in the same
directory as
> the data. The output G15Tiles.shp has the correct entries for each of
the
> four images to be mosaicked and the correct overall bounding box for
the
> mosaic. The MapServer mapfile has the following entry:
>
> LAYER
>   NAME G15Tiles
>   GROUP "Imagery"
>   PROJECTION
>    "init=epsg:4326"
>   END
>   TYPE RASTER
>   DUMP TRUE
>   STATUS DEFAULT
>   # where the tiles are
>   TILEINDEX "/ms4w/apps/ms_tiles/data/tiles/G15Tiles.shp"
>   TILEITEM "../data/tiles/"
>
>    more metadata items
>
> END
>
> This is the layer creation code in OpenLayers:
>
>         var map;
>         window.onload = function(){
>         map = new OpenLayers.Map('map',{ controls: [] },
{maxResolution:
> 'auto'} );
>         var g15tiles = new OpenLayers.Layer.MapServer("G15Tiles",
>
> "http://dnocc8036:8090/cgi-bin/ms_tiles",
>
> {layers: 'G15Tiles'});
>        map.addLayer(g15tiles);
>
> The OpenLayers HTML page gives two pink boxes. Is there anyone who
knows
> about MapServer + Tile Mosaics + OpenLayers who can help?
>
> Thanks,
>
> Jeff Copes
> Harris Corporation
> Enterprise Architecture COE - Geospatial Systems
> (321) 984-6556
>
>
>
>
> _______________________________________________
>  Dev mailing list
>  Dev@openlayers.org
>  http://openlayers.org/mailman/listinfo/dev
>
>

From crschmidt at metacarta.com  Tue Apr 29 14:14:19 2008
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
In-Reply-To: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
References: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
Message-ID: <20080429181418.GB2678@metacarta.com>

On Tue, Apr 29, 2008 at 01:31:25PM -0400, Copes, Jeff wrote:
> The OpenLayers HTML page gives two pink boxes. Is there anyone who knows
> about MapServer + Tile Mosaics + OpenLayers who can help? 

Sounds like you should look at this first:

http://trac.openlayers.org/wiki/TroubleshootingTips#Pinktiles
http://trac.openlayers.org/wiki/TroubleshootingTips#Problemswithimagesbeingincorrect

Regards,
-- 
Christopher Schmidt
MetaCarta

From pspencer at dmsolutions.ca  Tue Apr 29 15:38:31 2008
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
In-Reply-To: <05A0487071106E4EA6F14A60A5381F16B8D6F1@mlbe2k5.cs.myharris.net>
References: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
	<5b629bbf0804291041n2b153d85xb05c03d3a720169a@mail.gmail.com>
	<05A0487071106E4EA6F14A60A5381F16B8D6F1@mlbe2k5.cs.myharris.net>
Message-ID: <DC8808E2-A654-40D4-BA4D-8C6184EF1C3A@dmsolutions.ca>

Jeff,

I think the problem is with your TILEITEM member, that is supposed to  
point to an attribute of the shape file that contains the relative  
path to the raster files, the default is LOCATION and if you didn't  
change the options for gdaltindex then it will automatically use  
LOCATION as well.  This means you should drop TILEITEM from your map  
file.

Another small gotcha is that the value in the LOCATION field is  
relative to the SHAPEPATH defined for the map, not the location of the  
TILEINDEX.  The easiest way to make this work is to run gdaltindex in  
the directory that is your SHAPEPATH.  For instance, if you have  
SHAPEPATH ../data/tiles then you want to run gdaltindex from the ../ 
data/tiles.

Cheers

Paul

On 29-Apr-08, at 1:42 PM, Copes, Jeff wrote:
> Pedro,
>
> Thank you for the suggestion. I am writing a map now to bypass
> OpenLayers to isolate the issue. I think your suggestion is a more
> appropriate first test step and will do that first.
>
> Thanks,
>
> Jeff
>
> -----Original Message-----
> From: Pedro Simonetti Garcia [mailto:pedrosimonetti@gmail.com]
> Sent: Tuesday, April 29, 2008 1:41 PM
> To: Copes, Jeff
> Cc: dev@openlayers.org; Jordan, Thomas; Ingersoll, Mark
> Subject: Re: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
>
>
> Hi Jeff,
>
> I never worked with MapServer + Tile Mosaics + OpenLayers, so I don't
> have much to share with you.
>
> But here goes a small suggestion. Have you ever tried to use the
> "shp2img" command line tool to verify if MapServer is rendering
> correctly the mapfile? If you can't generate a proper image with
> shp2img it may indicate that you have a problem in your mapfile
> configuration.
>
> I hope this helps,
>
> Pedro Simonetti.
>
> 2008/4/29 Copes, Jeff <jcopes@harris.com>:
>>
>>
>>
>> All,
>>
>> I have not been able to connect MapServer to OpenLayers using
> TileIndex
>> directive in Mapserver. Has anyone been able to do this?
>>
>> There are four geoTIFFs in the directory
> /ms4w/apps/ms_tiles/data/tiles.
>> gdaltindex made a tileindex shapfile G15Tiles.shp in the same
> directory as
>> the data. The output G15Tiles.shp has the correct entries for each of
> the
>> four images to be mosaicked and the correct overall bounding box for
> the
>> mosaic. The MapServer mapfile has the following entry:
>>
>> LAYER
>>  NAME G15Tiles
>>  GROUP "Imagery"
>>  PROJECTION
>>   "init=epsg:4326"
>>  END
>>  TYPE RASTER
>>  DUMP TRUE
>>  STATUS DEFAULT
>>  # where the tiles are
>>  TILEINDEX "/ms4w/apps/ms_tiles/data/tiles/G15Tiles.shp"
>>  TILEITEM "../data/tiles/"
>>
>>   more metadata items
>>
>> END
>>
>> This is the layer creation code in OpenLayers:
>>
>>        var map;
>>        window.onload = function(){
>>        map = new OpenLayers.Map('map',{ controls: [] },
> {maxResolution:
>> 'auto'} );
>>        var g15tiles = new OpenLayers.Layer.MapServer("G15Tiles",
>>
>> "http://dnocc8036:8090/cgi-bin/ms_tiles",
>>
>> {layers: 'G15Tiles'});
>>       map.addLayer(g15tiles);
>>
>> The OpenLayers HTML page gives two pink boxes. Is there anyone who
> knows
>> about MapServer + Tile Mosaics + OpenLayers who can help?
>>
>> Thanks,
>>
>> Jeff Copes
>> Harris Corporation
>> Enterprise Architecture COE - Geospatial Systems
>> (321) 984-6556
>>
>>
>>
>>
>> _______________________________________________
>> 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
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From jcopes at harris.com  Tue Apr 29 19:56:27 2008
From: jcopes at harris.com (Copes, Jeff)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
In-Reply-To: <DC8808E2-A654-40D4-BA4D-8C6184EF1C3A@dmsolutions.ca>
References: <05A0487071106E4EA6F14A60A5381F16B8D6F0@mlbe2k5.cs.myharris.net>
	<5b629bbf0804291041n2b153d85xb05c03d3a720169a@mail.gmail.com>
	<05A0487071106E4EA6F14A60A5381F16B8D6F1@mlbe2k5.cs.myharris.net>
	<DC8808E2-A654-40D4-BA4D-8C6184EF1C3A@dmsolutions.ca>
Message-ID: <05A0487071106E4EA6F14A60A5381F16B8D6F6@mlbe2k5.cs.myharris.net>

Paul and Pedro,

Thanks for your replies. The SHAPEPATH member was the missing item. 

Jeff

-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca] 
Sent: Tuesday, April 29, 2008 3:39 PM
To: Copes, Jeff
Cc: Pedro Simonetti Garcia; dev@openlayers.org; Jordan, Thomas;
Ingersoll, Mark
Subject: Re: [OpenLayers-Dev] Mapserver Mosaics with Tileindex


Jeff,

I think the problem is with your TILEITEM member, that is supposed to  
point to an attribute of the shape file that contains the relative  
path to the raster files, the default is LOCATION and if you didn't  
change the options for gdaltindex then it will automatically use  
LOCATION as well.  This means you should drop TILEITEM from your map  
file.

Another small gotcha is that the value in the LOCATION field is  
relative to the SHAPEPATH defined for the map, not the location of the  
TILEINDEX.  The easiest way to make this work is to run gdaltindex in  
the directory that is your SHAPEPATH.  For instance, if you have  
SHAPEPATH ../data/tiles then you want to run gdaltindex from the ../ 
data/tiles.

Cheers

Paul

On 29-Apr-08, at 1:42 PM, Copes, Jeff wrote:
> Pedro,
>
> Thank you for the suggestion. I am writing a map now to bypass
> OpenLayers to isolate the issue. I think your suggestion is a more
> appropriate first test step and will do that first.
>
> Thanks,
>
> Jeff
>
> -----Original Message-----
> From: Pedro Simonetti Garcia [mailto:pedrosimonetti@gmail.com]
> Sent: Tuesday, April 29, 2008 1:41 PM
> To: Copes, Jeff
> Cc: dev@openlayers.org; Jordan, Thomas; Ingersoll, Mark
> Subject: Re: [OpenLayers-Dev] Mapserver Mosaics with Tileindex
>
>
> Hi Jeff,
>
> I never worked with MapServer + Tile Mosaics + OpenLayers, so I don't
> have much to share with you.
>
> But here goes a small suggestion. Have you ever tried to use the
> "shp2img" command line tool to verify if MapServer is rendering
> correctly the mapfile? If you can't generate a proper image with
> shp2img it may indicate that you have a problem in your mapfile
> configuration.
>
> I hope this helps,
>
> Pedro Simonetti.
>
> 2008/4/29 Copes, Jeff <jcopes@harris.com>:
>>
>>
>>
>> All,
>>
>> I have not been able to connect MapServer to OpenLayers using
> TileIndex
>> directive in Mapserver. Has anyone been able to do this?
>>
>> There are four geoTIFFs in the directory
> /ms4w/apps/ms_tiles/data/tiles.
>> gdaltindex made a tileindex shapfile G15Tiles.shp in the same
> directory as
>> the data. The output G15Tiles.shp has the correct entries for each of
> the
>> four images to be mosaicked and the correct overall bounding box for
> the
>> mosaic. The MapServer mapfile has the following entry:
>>
>> LAYER
>>  NAME G15Tiles
>>  GROUP "Imagery"
>>  PROJECTION
>>   "init=epsg:4326"
>>  END
>>  TYPE RASTER
>>  DUMP TRUE
>>  STATUS DEFAULT
>>  # where the tiles are
>>  TILEINDEX "/ms4w/apps/ms_tiles/data/tiles/G15Tiles.shp"
>>  TILEITEM "../data/tiles/"
>>
>>   more metadata items
>>
>> END
>>
>> This is the layer creation code in OpenLayers:
>>
>>        var map;
>>        window.onload = function(){
>>        map = new OpenLayers.Map('map',{ controls: [] },
> {maxResolution:
>> 'auto'} );
>>        var g15tiles = new OpenLayers.Layer.MapServer("G15Tiles",
>>
>> "http://dnocc8036:8090/cgi-bin/ms_tiles",
>>
>> {layers: 'G15Tiles'});
>>       map.addLayer(g15tiles);
>>
>> The OpenLayers HTML page gives two pink boxes. Is there anyone who
> knows
>> about MapServer + Tile Mosaics + OpenLayers who can help?
>>
>> Thanks,
>>
>> Jeff Copes
>> Harris Corporation
>> Enterprise Architecture COE - Geospatial Systems
>> (321) 984-6556
>>
>>
>>
>>
>> _______________________________________________
>> 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
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/


From radiceski at gmail.com  Tue Apr 29 22:35:46 2008
From: radiceski at gmail.com (Darko Radiceski)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Display mutiple instances of open layers on one
	screen
Message-ID: <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>

Grettings there,

I was working with open layers and had the following question:

I have 6 different sections (like different div sections or panes) on the
same page displaying data from 6 different WMS services.

What i would like to achieve is when i zoom in or pan on one of the displays
all of the other ones to zoom in or pan. They pretty much present the same
data but displayed differently.

Is that possible to do?

Any examples of that?

Cheers
Dan

-- 
Radiceski Darko
University of Wollongong
Australia
SIFE - UOW Chapter - Alumni
CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
(School of Information Technology and Computer Science,University of
Wollongong)
Univeristy of Wollongong - Alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080430/366dc15b/attachment.html
From tom at compton.nu  Wed Apr 30 03:31:08 2008
From: tom at compton.nu (Tom Hughes)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Display mutiple instances of open layers on
	one screen
In-Reply-To: <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
	(Darko Radiceski's message of "Wed\,
	30 Apr 2008 12\:35\:46 +1000")
References: <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
Message-ID: <yek1w4nvlxf.fsf@dellow.uk.cyberscience.com>

In message <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
        Darko Radiceski <radiceski@gmail.com> wrote:

> I have 6 different sections (like different div sections or panes) on the
> same page displaying data from 6 different WMS services.
>
> What i would like to achieve is when i zoom in or pan on one of the displays
> all of the other ones to zoom in or pan. They pretty much present the same
> data but displayed differently.
>
> Is that possible to do?

A bit like http://maps.compton.nu/compare.html you mean?

It's not trivial, and as you might notice there are still a few
glitches in my implementation... The code that does it is the
linkMaps() function in http://maps.compton.nu/map.js which is
called to link two OpenLayers.Map objects together.

Tom

-- 
Tom Hughes (tom@compton.nu)
http://www.compton.nu/

From radiceski at gmail.com  Wed Apr 30 03:39:56 2008
From: radiceski at gmail.com (Darko Radiceski)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Display mutiple instances of open layers on
	one screen
In-Reply-To: <yek1w4nvlxf.fsf@dellow.uk.cyberscience.com>
References: <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
	<yek1w4nvlxf.fsf@dellow.uk.cyberscience.com>
Message-ID: <1bcf9b2c0804300039r18554db6hf3fb9aec76e614f9@mail.gmail.com>

Exactly like that.

Only i would like to have 6 of those on the screen.

Is that code available for download?

Cheers
Dan

On Wed, Apr 30, 2008 at 5:31 PM, Tom Hughes <tom@compton.nu> wrote:

> In message <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
>        Darko Radiceski <radiceski@gmail.com> wrote:
>
> > I have 6 different sections (like different div sections or panes) on
> the
> > same page displaying data from 6 different WMS services.
> >
> > What i would like to achieve is when i zoom in or pan on one of the
> displays
> > all of the other ones to zoom in or pan. They pretty much present the
> same
> > data but displayed differently.
> >
> > Is that possible to do?
>
> A bit like http://maps.compton.nu/compare.html you mean?
>
> It's not trivial, and as you might notice there are still a few
> glitches in my implementation... The code that does it is the
> linkMaps() function in http://maps.compton.nu/map.js which is
> called to link two OpenLayers.Map objects together.
>
> Tom
>
> --
> Tom Hughes (tom@compton.nu)
> http://www.compton.nu/
>



-- 
Radiceski Darko
University of Wollongong
Australia
SIFE - UOW Chapter - Alumni
CASUAL ACADEMIC STAFF TEACHING - UOW SITACS
(School of Information Technology and Computer Science,University of
Wollongong)
Univeristy of Wollongong - Alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20080430/62b5e809/attachment.html
From tom at compton.nu  Wed Apr 30 03:43:54 2008
From: tom at compton.nu (Tom Hughes)
Date: Wed Sep  1 17:23:48 2010
Subject: [OpenLayers-Dev] Display mutiple instances of open layers on
	one screen
In-Reply-To: <1bcf9b2c0804300039r18554db6hf3fb9aec76e614f9@mail.gmail.com>
	(Darko Radiceski's message of "Wed\,
	30 Apr 2008 17\:39\:56 +1000")
References: <1bcf9b2c0804291935m7290d833u85e9c14cbe7f1f08@mail.gmail.com>
	<yek1w4nvlxf.fsf@dellow.uk.cyberscience.com>
	<1bcf9b2c0804300039r18554db6hf3fb9aec76e614f9@mail.gmail.com>
Message-ID: <yekod7ru6rp.fsf@dellow.uk.cyberscience.com>

In message <1bcf9b2c0804300039r18554db6hf3fb9aec76e614f9@mail.gmail.com>
        Darko Radiceski <radiceski@gmail.com> wrote:

> Exactly like that.
>
> Only i would like to have 6 of those on the screen.

That's a trivial matter of scaling up the solution ;-)

> Is that code available for download?

Sure, where I said it was, in map.js (and a small bit in compare.html
to set things up).

Tom

-- 
Tom Hughes (tom@compton.nu)
http://www.compton.nu/