From ahocevar at opengeo.org  Mon Jun  1 06:56:36 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] RC5 prop
In-Reply-To: <20090530205427.GB17782@metacarta.com>
References: <20090529105634.GI9092@metacarta.com>
	<ca7da9120905301328y4264ed60n66df20d4044dce43@mail.gmail.com>
	<20090530205427.GB17782@metacarta.com>
Message-ID: <5b021dd0906010356l549692dx5bc1e30b92ac2714@mail.gmail.com>

Now that another regression was found
(http://trac.openlayers.org/ticket/2115, currently set to Review),
there is at least one more reason :-).

Thanks,
Andreas.

On Sat, May 30, 2009 at 10:54 PM, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> On Sat, May 30, 2009 at 10:28:50PM +0200, Eric Lemoine wrote:
>> On Friday, May 29, 2009, Christopher Schmidt <crschmidt@metacarta.com> wrote:
>> > So, Pierre and Andreas worked out:
>> >
>> > ??http://trac.openlayers.org/ticket/1797#comment:22
>> >
>> > To likely be a Google API change. ?As I understand it, this:
>> >
>> > ?? ?* CHanged something that worked when we fixed it, to something that
>> > ?? ? ?didn't
>> > ?? ?* Was a change due to a GMaps API change
>> > ?? ?* Was something that we put a lot of effort into fixing
>> > ?? ?* Affects MapFish/GeoExt (and probably other JS Frameworks with
>> > ?? ?* flexible map sizes)
>> >
>> > As a result, I think it's worth including in 2.8: It was worth it the
>> > first time, it's still worth it this time (even though we aren't
>> > responsible for the regression, we've still got to deal with it.)
>> >
>> > IF this ticket doesn't affect people (I think it does -- i just emailed
>> > the geoext list about it, and pierre bumped into it, after all) then we
>> > can bump it, but otherwise, it's worth another RC.
>> >
>> > So, if anyone else agrees with me -- and I'd especially like to hear
>> > from GeoExt or MapFish people who can confirm that this is actually an
>> > issue, and is now fixed -- then I say I roll an RC5 this afternoon.
>>
>>
>> It indeed affects GeoExt - Google layers within a map panel do not
>> display. I'll test Andreas' latest patch on Tuesday (said Monday in
>> the ticket but realized Monday is off for me) and will report back in
>> the ticket.
>
> Well, a GeoExt user was able to confirm that 2.8-rc4 did not work, and
> using Google.js from trunk did, so I'm happy enough saying that this has
> been tested with GeoExt for the problem reported.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From crschmidt at metacarta.com  Tue Jun  2 12:12:49 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] OpenLayers 2.8 RC5
Message-ID: <20090602161249.GP17782@metacarta.com>

The OpenLayers Development Team is proud to announce the fifth release
candidate of OpenLayers 2.8!

RC5 closes an additional small number of bugs in the 2.8 Release,
including a bug with Google-based layers not resizing correctly when not
visible.

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

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

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

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 look forward to your feedback on this release.

Regards,
-- 
Christopher Schmidt
MetaCarta

From roald.dewit at lisasoft.com  Tue Jun  2 18:21:58 2009
From: roald.dewit at lisasoft.com (Roald de Wit)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
Message-ID: <4A25A606.1070702@lisasoft.com>

Hi Bj?rn,

Great initiative! Topology preserving editing functionality would be a 
very valuably contribution to OL (IMHO).
I did notice that when you edit one feature, then uncheck 'enforce 
topology', edit a bit more (by moving vertices) and then check 'enforce 
topology' again, the enforcing does not work anymore when you move more 
than the snapping threshold. I know this is work in progress, so you 
might be aware of it already.

I'm sure that more than 1 person (2 now, including me) will be 
interested in your work!

Regards, Roald


Bj?rn Harrtell wrote:
> Since I got at least one (and hopefully more :) interested person(s)
> in the details I'm posting this information about my initial
> implementation of the below proposal using using events in this
> sandbox:
>
> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>
> Check out the example at
> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
> to see the implementation in effect.
>
> The only change from the initial proposal is that
> OpenLayers.Control.ModifyFeature essentially does not have to be
> modified, which is made possible by basing the implementation on the
> vertexmodified event - though I do have added and are using
> delta-movement information to the vertexmodified event-message, which
> required small changes in DragFeature and ModifyFeature controls to
> fill in this information.
>
> New classes are:
> OpenLayers.Topology
> OpenLayers.Topology.Rule
> OpenLayers.Topology.Rule.VerticesMustIntersect
>
> The implementation is dynamic which means that the topology rule is
> evaluated at each change of the geometry which I think should be
> optional since this can be costly with more complex geometry and can
> cause wierd side-effects when using snapping for instance. I'd like to
> add some kind of caching in the future that would require manual or
> semi-manual update of the topology state.
>
> The render intent stuff is not done yet.
>
> Forgive me if I've forgot some detail in the above description :)
>
> /Bj?rn
>
> 2009/4/22 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>   
>> Hi devs,
>>
>> I want to make an effort to implement a topology restriction in
>> OpenLayers (specifically that polygons must share vertices). The ideal
>> would be something that is reusable for other topology rules than the
>> one I want to implement at first and my intent is to build it so that
>> it can be contributed as a patch. I've discussed the matter with Tim
>> briefly and here is my rough initial design proposal. Any feedback
>> will of course be appreciated.
>>
>> I wanted to add this to the wiki at Proposal/Topology but seems I
>> can't create new wikipages even when I'm logged in, or I'm missing
>> something. So here is it:
>>
>> * Represent topology rules as classes in namespace
>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I
>> don't really like using the same identifier as a namespace and class,
>> but I think this is the convention in OpenLayers?). The base class
>> should provide an interface for checking feature(s) for topology
>> errors and optionally set the render intent and return the violating
>> features.
>>
>> * Add a render intent for indicating topology violation
>>
>> * Add topologyRules property to OpenLayers.Layer.Vector as an optional
>> array of topology classes to associate with the layer
>>
>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to
>> indicate if a vector layer automatically should update the topology
>> render intent on feature changes (default false)
>>
>> * Add enforceTopology boolean property to
>> OpenLayers.Control.ModifyFeature to restrict edits to follow the
>> topology rule by either automatically snapping stuff (if possible) or
>> disallowing the interaction.
>>
>> * The first rule to be implemented is that polygons must share
>> vertices, suggested name is
>> OpenLayers.Topology.Rules.PolygonsMustShareVertices
>>
>> Motivations:
>>
>> * Topology rules could be constant enums instead of classes, the
>> reasons for suggesting classes are to make it more clear that the rule
>> should contain as much of the implementation as possible and that one
>> might want to make OL-builds containing only the rules that are
>> relevant for the use case.
>>
>> Uncertainties:
>>
>> * Where to put the logic that restricts editing - I'm not sure if it's
>> possible to separate it without creating a dependency mess between
>> ModifyControl and the topology rule.
>>
>> With regards,
>>
>> Bj?rn Harrtell
>>
>>     
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>   


From bruno.binet at camptocamp.com  Wed Jun  3 03:55:14 2009
From: bruno.binet at camptocamp.com (Bruno Binet)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
Message-ID: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com>

Hi list,

I am currently working on a new format to write CSW GetRecords
requests and read CSW GetRecordsResponse responses.
Do you think this format could have its place among other OL Formats ?

For information, CSW is an ogc specification which describes
interfaces to query a catalog.

Cheers.

-- 
Bruno Binet

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Mail : bruno.binet@camptocamp.com
http://www.camptocamp.com

From tschaub at opengeo.org  Wed Jun  3 19:01:51 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
In-Reply-To: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com>
References: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com>
Message-ID: <4A2700DF.2040907@opengeo.org>

Hey-

Bruno Binet wrote:
> Hi list,
> 
> I am currently working on a new format to write CSW GetRecords
> requests and read CSW GetRecordsResponse responses.
> Do you think this format could have its place among other OL Formats ?
> 

I think this sounds good.

There is a bit of awkwardness coding around services that require 
complex formatting of request data (in terms of the OL Protocol/Format 
split), but I think additional formats (and protocols) make sense.

At some point, it seems like we should discuss hosting a lite (but 
fairly functional build) so people wouldn't complain about OL continuing 
to get bigger with every release.

Tim

> For information, CSW is an ogc specification which describes
> interfaces to query a catalog.
> 
> Cheers.
> 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From bruno.binet at camptocamp.com  Thu Jun  4 03:37:03 2009
From: bruno.binet at camptocamp.com (Bruno Binet)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
In-Reply-To: <4A2700DF.2040907@opengeo.org>
References: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com> 
	<4A2700DF.2040907@opengeo.org>
Message-ID: <4b5079220906040037u68bef877vcc130988913e97fe@mail.gmail.com>

Hi,

>> I am currently working on a new format to write CSW GetRecords
>> requests and read CSW GetRecordsResponse responses.
>> Do you think this format could have its place among other OL Formats ?
>>
>
> I think this sounds good.
>
> There is a bit of awkwardness coding around services that require
> complex formatting of request data (in terms of the OL Protocol/Format
> split), but I think additional formats (and protocols) make sense.

Great. I'll let you know when I'll get something functional.

> At some point, it seems like we should discuss hosting a lite (but
> fairly functional build) so people wouldn't complain about OL continuing
> to get bigger with every release.

We may build a minimal version of OL for beginners, but most of the
time I think we use specific build for each project.

Bruno

> Tim
>
>> For information, CSW is an ogc specification which describes
>> interfaces to query a catalog.
>>
>> Cheers.
>>
>
>
> --
> Tim Schaub
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Bruno Binet

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Mail : bruno.binet@camptocamp.com
http://www.camptocamp.com

From bjorn.harrtell at gmail.com  Thu Jun  4 06:12:38 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <4A25A606.1070702@lisasoft.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
Message-ID: <ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>

The issue you describe is probably caused by conflicts between
snapping and topology enforcement, more specifically both snapping and
topology enforcement listen on vertexmodified-events and the order of
this combined logic is significant. I haven't investigated if I can
control priority of my event listener, but if that's possible I think
it would solve the problems.

On another note, the sandbox and example is now updated with an
initial implementation of the renderIntent-idea which means that at
each completed feature modification the state of topology will be
calculated and polygon that does not satisfy the rule will be set into
the renderIntent state "error" and will be colored in red.

/Bj?rn

On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com> wrote:
> Hi Bj?rn,
>
> Great initiative! Topology preserving editing functionality would be a very
> valuably contribution to OL (IMHO).
> I did notice that when you edit one feature, then uncheck 'enforce
> topology', edit a bit more (by moving vertices) and then check 'enforce
> topology' again, the enforcing does not work anymore when you move more than
> the snapping threshold. I know this is work in progress, so you might be
> aware of it already.
>
> I'm sure that more than 1 person (2 now, including me) will be interested in
> your work!
>
> Regards, Roald
>
>
> Bj?rn Harrtell wrote:
>>
>> Since I got at least one (and hopefully more :) interested person(s)
>> in the details I'm posting this information about my initial
>> implementation of the below proposal using using events in this
>> sandbox:
>>
>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>>
>> Check out the example at
>>
>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
>> to see the implementation in effect.
>>
>> The only change from the initial proposal is that
>> OpenLayers.Control.ModifyFeature essentially does not have to be
>> modified, which is made possible by basing the implementation on the
>> vertexmodified event - though I do have added and are using
>> delta-movement information to the vertexmodified event-message, which
>> required small changes in DragFeature and ModifyFeature controls to
>> fill in this information.
>>
>> New classes are:
>> OpenLayers.Topology
>> OpenLayers.Topology.Rule
>> OpenLayers.Topology.Rule.VerticesMustIntersect
>>
>> The implementation is dynamic which means that the topology rule is
>> evaluated at each change of the geometry which I think should be
>> optional since this can be costly with more complex geometry and can
>> cause wierd side-effects when using snapping for instance. I'd like to
>> add some kind of caching in the future that would require manual or
>> semi-manual update of the topology state.
>>
>> The render intent stuff is not done yet.
>>
>> Forgive me if I've forgot some detail in the above description :)
>>
>> /Bj?rn
>>
>> 2009/4/22 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>
>>>
>>> Hi devs,
>>>
>>> I want to make an effort to implement a topology restriction in
>>> OpenLayers (specifically that polygons must share vertices). The ideal
>>> would be something that is reusable for other topology rules than the
>>> one I want to implement at first and my intent is to build it so that
>>> it can be contributed as a patch. I've discussed the matter with Tim
>>> briefly and here is my rough initial design proposal. Any feedback
>>> will of course be appreciated.
>>>
>>> I wanted to add this to the wiki at Proposal/Topology but seems I
>>> can't create new wikipages even when I'm logged in, or I'm missing
>>> something. So here is it:
>>>
>>> * Represent topology rules as classes in namespace
>>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I
>>> don't really like using the same identifier as a namespace and class,
>>> but I think this is the convention in OpenLayers?). The base class
>>> should provide an interface for checking feature(s) for topology
>>> errors and optionally set the render intent and return the violating
>>> features.
>>>
>>> * Add a render intent for indicating topology violation
>>>
>>> * Add topologyRules property to OpenLayers.Layer.Vector as an optional
>>> array of topology classes to associate with the layer
>>>
>>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to
>>> indicate if a vector layer automatically should update the topology
>>> render intent on feature changes (default false)
>>>
>>> * Add enforceTopology boolean property to
>>> OpenLayers.Control.ModifyFeature to restrict edits to follow the
>>> topology rule by either automatically snapping stuff (if possible) or
>>> disallowing the interaction.
>>>
>>> * The first rule to be implemented is that polygons must share
>>> vertices, suggested name is
>>> OpenLayers.Topology.Rules.PolygonsMustShareVertices
>>>
>>> Motivations:
>>>
>>> * Topology rules could be constant enums instead of classes, the
>>> reasons for suggesting classes are to make it more clear that the rule
>>> should contain as much of the implementation as possible and that one
>>> might want to make OL-builds containing only the rules that are
>>> relevant for the use case.
>>>
>>> Uncertainties:
>>>
>>> * Where to put the logic that restricts editing - I'm not sure if it's
>>> possible to separate it without creating a dependency mess between
>>> ModifyControl and the topology rule.
>>>
>>> With regards,
>>>
>>> Bj?rn Harrtell
>>>
>>>
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>
>

From crschmidt at metacarta.com  Thu Jun  4 07:55:18 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
In-Reply-To: <4A2700DF.2040907@opengeo.org>
References: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com>
	<4A2700DF.2040907@opengeo.org>
Message-ID: <20090604115518.GZ17782@metacarta.com>

On Wed, Jun 03, 2009 at 05:01:51PM -0600, Tim Schaub wrote:
> At some point, it seems like we should discuss hosting a lite (but 
> fairly functional build) so people wouldn't complain about OL continuing 
> to get bigger with every release.

I think the real answer is we shouldn't make using a full build of
OpenLayers the recommended path, and instead encourage everyone to build
a custom build profile.

Regards,
-- 
Christopher Schmidt
MetaCarta

From mpriour at kestrelcomputer.com  Thu Jun  4 13:14:58 2009
From: mpriour at kestrelcomputer.com (Matt Priour)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
In-Reply-To: <mailman.1.1244131201.22609.dev@openlayers.org>
References: <mailman.1.1244131201.22609.dev@openlayers.org>
Message-ID: <057579033D3C452B9AF479C6262FA394@MattPC>


> Message: 4
> Date: Thu, 4 Jun 2009 07:55:18 -0400
> From: Christopher Schmidt <crschmidt@metacarta.com>
> Subject: Re: [OpenLayers-Dev] csw format
> To: Tim Schaub <tschaub@opengeo.org>
> Cc: dev@openlayers.org
> Message-ID: <20090604115518.GZ17782@metacarta.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Jun 03, 2009 at 05:01:51PM -0600, Tim Schaub wrote:
>> At some point, it seems like we should discuss hosting a lite (but
>> fairly functional build) so people wouldn't complain about OL continuing
>> to get bigger with every release.
>
> I think the real answer is we shouldn't make using a full build of
> OpenLayers the recommended path, and instead encourage everyone to build
> a custom build profile.
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
>
>
> ------------------------------

I think one path that OpenLayers could take in 3.0 is to implement lazy, 
on-demand loading of the library components like YUI. Also like YUI, it 
could be hosted on Google's CDN and have several "pre-built" modules so that 
neither the entire library is downloaded nor each specific file unless need 
be.
Just a possible idea for the future.

Matt Priour 



From sgillies at frii.com  Thu Jun  4 14:04:16 2009
From: sgillies at frii.com (Sean Gillies)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Builds (Re:  csw format)
In-Reply-To: <20090604115518.GZ17782@metacarta.com>
References: <4b5079220906030055s449a4ab9v87edb124afa2b510@mail.gmail.com>
	<4A2700DF.2040907@opengeo.org>
	<20090604115518.GZ17782@metacarta.com>
Message-ID: <8E45A41A-2C16-439C-A62F-F932E7A63593@frii.com>

On Jun 4, 2009, at 5:55 AM, Christopher Schmidt wrote:

> On Wed, Jun 03, 2009 at 05:01:51PM -0600, Tim Schaub wrote:
>> At some point, it seems like we should discuss hosting a lite (but
>> fairly functional build) so people wouldn't complain about OL  
>> continuing
>> to get bigger with every release.
>
> I think the real answer is we shouldn't make using a full build of
> OpenLayers the recommended path, and instead encourage everyone to  
> build
> a custom build profile.
>

FWIW, I just released a zc.buildout recipe that makes it easy to do  
such builds (any number of them) in a replicable way.

http://pypi.python.org/pypi/zgeo.recipe.openlayers/0.1

Cheers,
Sean

--
Sean Gillies
sean.gillies@gmail.com
http://sgillies.net


From crschmidt at metacarta.com  Thu Jun  4 14:19:54 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] csw format
In-Reply-To: <057579033D3C452B9AF479C6262FA394@MattPC>
References: <mailman.1.1244131201.22609.dev@openlayers.org>
	<057579033D3C452B9AF479C6262FA394@MattPC>
Message-ID: <20090604181953.GC17782@metacarta.com>

On Thu, Jun 04, 2009 at 12:14:58PM -0500, Matt Priour wrote:
> > On Wed, Jun 03, 2009 at 05:01:51PM -0600, Tim Schaub wrote:
> >> At some point, it seems like we should discuss hosting a lite (but
> >> fairly functional build) so people wouldn't complain about OL continuing
> >> to get bigger with every release.
> >
> > I think the real answer is we shouldn't make using a full build of
> > OpenLayers the recommended path, and instead encourage everyone to build
> > a custom build profile.
> 
> I think one path that OpenLayers could take in 3.0 is to implement lazy, 
> on-demand loading of the library components like YUI. Also like YUI, it 
> could be hosted on Google's CDN and have several "pre-built" modules so that 
> neither the entire library is downloaded nor each specific file unless need 
> be.
> Just a possible idea for the future.

We've discussed this i the past, but this is something that requies a
lot of effort to get right; in the past we've gone against this kind of
thing due to the difficulty.

Regards,
-- 
Christopher Schmidt
MetaCarta

From bjorn.harrtell at gmail.com  Thu Jun  4 17:51:16 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
Message-ID: <ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>

I've rewritten the implementation so that topology isn't calculated on
the fly, which I think might solve the problem discussed below and
also improves performance.

In doing this I got to think about the initial proposal. A redesign
that popped up in my head is to remove the idea that rules are applied
to a Vector layer and instead add a new Control called Topology that
controls the enforcement and renderIntent-stuff for the supplied layer
(or layer)

The basic idea with the above is to be able to leave the Vector Layer
completely unmodified (it's large as it is :) and also put all user
configurable interaction with the functionality in the control instead
of manipulating the rule. Any opinions?

/Bj?rn

2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
> The issue you describe is probably caused by conflicts between
> snapping and topology enforcement, more specifically both snapping and
> topology enforcement listen on vertexmodified-events and the order of
> this combined logic is significant. I haven't investigated if I can
> control priority of my event listener, but if that's possible I think
> it would solve the problems.
>
> On another note, the sandbox and example is now updated with an
> initial implementation of the renderIntent-idea which means that at
> each completed feature modification the state of topology will be
> calculated and polygon that does not satisfy the rule will be set into
> the renderIntent state "error" and will be colored in red.
>
> /Bj?rn
>
> On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com> wrote:
>> Hi Bj?rn,
>>
>> Great initiative! Topology preserving editing functionality would be a very
>> valuably contribution to OL (IMHO).
>> I did notice that when you edit one feature, then uncheck 'enforce
>> topology', edit a bit more (by moving vertices) and then check 'enforce
>> topology' again, the enforcing does not work anymore when you move more than
>> the snapping threshold. I know this is work in progress, so you might be
>> aware of it already.
>>
>> I'm sure that more than 1 person (2 now, including me) will be interested in
>> your work!
>>
>> Regards, Roald
>>
>>
>> Bj?rn Harrtell wrote:
>>>
>>> Since I got at least one (and hopefully more :) interested person(s)
>>> in the details I'm posting this information about my initial
>>> implementation of the below proposal using using events in this
>>> sandbox:
>>>
>>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>>>
>>> Check out the example at
>>>
>>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
>>> to see the implementation in effect.
>>>
>>> The only change from the initial proposal is that
>>> OpenLayers.Control.ModifyFeature essentially does not have to be
>>> modified, which is made possible by basing the implementation on the
>>> vertexmodified event - though I do have added and are using
>>> delta-movement information to the vertexmodified event-message, which
>>> required small changes in DragFeature and ModifyFeature controls to
>>> fill in this information.
>>>
>>> New classes are:
>>> OpenLayers.Topology
>>> OpenLayers.Topology.Rule
>>> OpenLayers.Topology.Rule.VerticesMustIntersect
>>>
>>> The implementation is dynamic which means that the topology rule is
>>> evaluated at each change of the geometry which I think should be
>>> optional since this can be costly with more complex geometry and can
>>> cause wierd side-effects when using snapping for instance. I'd like to
>>> add some kind of caching in the future that would require manual or
>>> semi-manual update of the topology state.
>>>
>>> The render intent stuff is not done yet.
>>>
>>> Forgive me if I've forgot some detail in the above description :)
>>>
>>> /Bj?rn
>>>
>>> 2009/4/22 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>>
>>>>
>>>> Hi devs,
>>>>
>>>> I want to make an effort to implement a topology restriction in
>>>> OpenLayers (specifically that polygons must share vertices). The ideal
>>>> would be something that is reusable for other topology rules than the
>>>> one I want to implement at first and my intent is to build it so that
>>>> it can be contributed as a patch. I've discussed the matter with Tim
>>>> briefly and here is my rough initial design proposal. Any feedback
>>>> will of course be appreciated.
>>>>
>>>> I wanted to add this to the wiki at Proposal/Topology but seems I
>>>> can't create new wikipages even when I'm logged in, or I'm missing
>>>> something. So here is it:
>>>>
>>>> * Represent topology rules as classes in namespace
>>>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I
>>>> don't really like using the same identifier as a namespace and class,
>>>> but I think this is the convention in OpenLayers?). The base class
>>>> should provide an interface for checking feature(s) for topology
>>>> errors and optionally set the render intent and return the violating
>>>> features.
>>>>
>>>> * Add a render intent for indicating topology violation
>>>>
>>>> * Add topologyRules property to OpenLayers.Layer.Vector as an optional
>>>> array of topology classes to associate with the layer
>>>>
>>>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to
>>>> indicate if a vector layer automatically should update the topology
>>>> render intent on feature changes (default false)
>>>>
>>>> * Add enforceTopology boolean property to
>>>> OpenLayers.Control.ModifyFeature to restrict edits to follow the
>>>> topology rule by either automatically snapping stuff (if possible) or
>>>> disallowing the interaction.
>>>>
>>>> * The first rule to be implemented is that polygons must share
>>>> vertices, suggested name is
>>>> OpenLayers.Topology.Rules.PolygonsMustShareVertices
>>>>
>>>> Motivations:
>>>>
>>>> * Topology rules could be constant enums instead of classes, the
>>>> reasons for suggesting classes are to make it more clear that the rule
>>>> should contain as much of the implementation as possible and that one
>>>> might want to make OL-builds containing only the rules that are
>>>> relevant for the use case.
>>>>
>>>> Uncertainties:
>>>>
>>>> * Where to put the logic that restricts editing - I'm not sure if it's
>>>> possible to separate it without creating a dependency mess between
>>>> ModifyControl and the topology rule.
>>>>
>>>> With regards,
>>>>
>>>> Bj?rn Harrtell
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>
>>
>

From blaise.picinbono at alyotech.fr  Fri Jun  5 08:54:27 2009
From: blaise.picinbono at alyotech.fr (PICINBONO Blaise)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] date of 2.8 final release ?
Message-ID: <06A7AD4E92172446ADDEB44F8A5D5C1009E0DD1568@ARE01.alyotech.fr>

Dear devs,

I've been watching the roadmap of 2.8 oscillating between 99% and 100% for the past weeks.
I know this question can't be answered no more than "when everything will have been tested and debugged", but do you have a more or less precise idea about when 2.8 final release will break out ? Is it a matter of days, weeks, months ?

I am dealing with a soon coming deadline and would like to include 2.8 final release for its snapping capabilities. It's working allright with rc3, but I would prefer a final release for my project.
Thanks for your great work.
Blaise



Blaise PICINBONO
Ing?nieur SIG
------------------------------------------------------------------------------


ALYOTECH TECHNOLOGIES
2, rue Antoine Becquerel
35700? RENNES

T?l. 02 23 21 11 11
Fax. 02.23.21.11.00 
www.alyotech.fr

?? N'imprimez ce mail que si c'est vraiment n?cessaire.


From evan.bowling at gmail.com  Fri Jun  5 11:20:51 2009
From: evan.bowling at gmail.com (Evan James Bowling)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
Message-ID: <d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>

I think it makes perfect sense to separate the Topology component into its
own Control. Were you able to alter the priority of the Snapping vs.
Topology controls?

-Evan

2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>

> I've rewritten the implementation so that topology isn't calculated on
> the fly, which I think might solve the problem discussed below and
> also improves performance.
>
> In doing this I got to think about the initial proposal. A redesign
> that popped up in my head is to remove the idea that rules are applied
> to a Vector layer and instead add a new Control called Topology that
> controls the enforcement and renderIntent-stuff for the supplied layer
> (or layer)
>
> The basic idea with the above is to be able to leave the Vector Layer
> completely unmodified (it's large as it is :) and also put all user
> configurable interaction with the functionality in the control instead
> of manipulating the rule. Any opinions?
>
> /Bj?rn
>
> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
> > The issue you describe is probably caused by conflicts between
> > snapping and topology enforcement, more specifically both snapping and
> > topology enforcement listen on vertexmodified-events and the order of
> > this combined logic is significant. I haven't investigated if I can
> > control priority of my event listener, but if that's possible I think
> > it would solve the problems.
> >
> > On another note, the sandbox and example is now updated with an
> > initial implementation of the renderIntent-idea which means that at
> > each completed feature modification the state of topology will be
> > calculated and polygon that does not satisfy the rule will be set into
> > the renderIntent state "error" and will be colored in red.
> >
> > /Bj?rn
> >
> > On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com>
> wrote:
> >> Hi Bj?rn,
> >>
> >> Great initiative! Topology preserving editing functionality would be a
> very
> >> valuably contribution to OL (IMHO).
> >> I did notice that when you edit one feature, then uncheck 'enforce
> >> topology', edit a bit more (by moving vertices) and then check 'enforce
> >> topology' again, the enforcing does not work anymore when you move more
> than
> >> the snapping threshold. I know this is work in progress, so you might be
> >> aware of it already.
> >>
> >> I'm sure that more than 1 person (2 now, including me) will be
> interested in
> >> your work!
> >>
> >> Regards, Roald
> >>
> >>
> >> Bj?rn Harrtell wrote:
> >>>
> >>> Since I got at least one (and hopefully more :) interested person(s)
> >>> in the details I'm posting this information about my initial
> >>> implementation of the below proposal using using events in this
> >>> sandbox:
> >>>
> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
> >>>
> >>> Check out the example at
> >>>
> >>>
> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
> >>> to see the implementation in effect.
> >>>
> >>> The only change from the initial proposal is that
> >>> OpenLayers.Control.ModifyFeature essentially does not have to be
> >>> modified, which is made possible by basing the implementation on the
> >>> vertexmodified event - though I do have added and are using
> >>> delta-movement information to the vertexmodified event-message, which
> >>> required small changes in DragFeature and ModifyFeature controls to
> >>> fill in this information.
> >>>
> >>> New classes are:
> >>> OpenLayers.Topology
> >>> OpenLayers.Topology.Rule
> >>> OpenLayers.Topology.Rule.VerticesMustIntersect
> >>>
> >>> The implementation is dynamic which means that the topology rule is
> >>> evaluated at each change of the geometry which I think should be
> >>> optional since this can be costly with more complex geometry and can
> >>> cause wierd side-effects when using snapping for instance. I'd like to
> >>> add some kind of caching in the future that would require manual or
> >>> semi-manual update of the topology state.
> >>>
> >>> The render intent stuff is not done yet.
> >>>
> >>> Forgive me if I've forgot some detail in the above description :)
> >>>
> >>> /Bj?rn
> >>>
> >>> 2009/4/22 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
> >>>
> >>>>
> >>>> Hi devs,
> >>>>
> >>>> I want to make an effort to implement a topology restriction in
> >>>> OpenLayers (specifically that polygons must share vertices). The ideal
> >>>> would be something that is reusable for other topology rules than the
> >>>> one I want to implement at first and my intent is to build it so that
> >>>> it can be contributed as a patch. I've discussed the matter with Tim
> >>>> briefly and here is my rough initial design proposal. Any feedback
> >>>> will of course be appreciated.
> >>>>
> >>>> I wanted to add this to the wiki at Proposal/Topology but seems I
> >>>> can't create new wikipages even when I'm logged in, or I'm missing
> >>>> something. So here is it:
> >>>>
> >>>> * Represent topology rules as classes in namespace
> >>>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule (I
> >>>> don't really like using the same identifier as a namespace and class,
> >>>> but I think this is the convention in OpenLayers?). The base class
> >>>> should provide an interface for checking feature(s) for topology
> >>>> errors and optionally set the render intent and return the violating
> >>>> features.
> >>>>
> >>>> * Add a render intent for indicating topology violation
> >>>>
> >>>> * Add topologyRules property to OpenLayers.Layer.Vector as an optional
> >>>> array of topology classes to associate with the layer
> >>>>
> >>>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector to
> >>>> indicate if a vector layer automatically should update the topology
> >>>> render intent on feature changes (default false)
> >>>>
> >>>> * Add enforceTopology boolean property to
> >>>> OpenLayers.Control.ModifyFeature to restrict edits to follow the
> >>>> topology rule by either automatically snapping stuff (if possible) or
> >>>> disallowing the interaction.
> >>>>
> >>>> * The first rule to be implemented is that polygons must share
> >>>> vertices, suggested name is
> >>>> OpenLayers.Topology.Rules.PolygonsMustShareVertices
> >>>>
> >>>> Motivations:
> >>>>
> >>>> * Topology rules could be constant enums instead of classes, the
> >>>> reasons for suggesting classes are to make it more clear that the rule
> >>>> should contain as much of the implementation as possible and that one
> >>>> might want to make OL-builds containing only the rules that are
> >>>> relevant for the use case.
> >>>>
> >>>> Uncertainties:
> >>>>
> >>>> * Where to put the logic that restricts editing - I'm not sure if it's
> >>>> possible to separate it without creating a dependency mess between
> >>>> ModifyControl and the topology rule.
> >>>>
> >>>> With regards,
> >>>>
> >>>> Bj?rn Harrtell
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Dev mailing list
> >>> Dev@openlayers.org
> >>> http://openlayers.org/mailman/listinfo/dev
> >>>
> >>
> >>
> >
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090605/a8e44930/attachment.html
From crschmidt at metacarta.com  Fri Jun  5 11:59:16 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
Message-ID: <20090605155916.GG17782@metacarta.com>

I think we're all done with bugs in OL 2.8. So, I'd like to motion that
RC5 be declared a final release, with myself doing the release work.

+1 from me.

Best Regards,
-- 
Christopher Schmidt
MetaCarta

From pspencer at dmsolutions.ca  Fri Jun  5 11:58:10 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <20090605155916.GG17782@metacarta.com>
References: <20090605155916.GG17782@metacarta.com>
Message-ID: <005D7E3E-E120-4D38-9126-E845053043B7@dmsolutions.ca>

+1 Paul --- Excellent work all, this is an awesome release

On 5-Jun-09, at 11:59 AM, Christopher Schmidt wrote:

> I think we're all done with bugs in OL 2.8. So, I'd like to motion  
> that
> RC5 be declared a final release, with myself doing the release work.
>
> +1 from me.
>
> Best Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

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


From euzuro at gmail.com  Fri Jun  5 11:59:53 2009
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <20090605155916.GG17782@metacarta.com>
References: <20090605155916.GG17782@metacarta.com>
Message-ID: <6ae3fb590906050859p4bf5181dha011f96a2cf7e658@mail.gmail.com>

Must admit I haven't really been paying too close attention to this release
cycle... so
just as a vote of confidence, I'll

+0

On Fri, Jun 5, 2009 at 10:59, Christopher Schmidt
<crschmidt@metacarta.com>wrote:

> I think we're all done with bugs in OL 2.8. So, I'd like to motion that
> RC5 be declared a final release, with myself doing the release work.
>
> +1 from me.
>
> Best 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/20090605/0b63e3cc/attachment.html
From eric.lemoine at camptocamp.com  Fri Jun  5 12:16:24 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <20090605155916.GG17782@metacarta.com>
References: <20090605155916.GG17782@metacarta.com>
Message-ID: <ca7da9120906050916y5f82855cr491bce012b49a42f@mail.gmail.com>

On Friday, June 5, 2009, Christopher Schmidt <crschmidt@metacarta.com> wrote:
> I think we're all done with bugs in OL 2.8. So, I'd like to motion that
> RC5 be declared a final release, with myself doing the release work.
>
> +1 from me.

+1 from me too.

>
> Best Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From bartvde at osgis.nl  Fri Jun  5 12:26:35 2009
From: bartvde at osgis.nl (Bart van den Eijnden (OSGIS))
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <20090605155916.GG17782@metacarta.com>
References: <20090605155916.GG17782@metacarta.com>
Message-ID: <4A29473B.7070302@osgis.nl>

Although I can't officially vote, +1 from me as well.

Perseverance is paying off, this was a long haul. Great work Chris and 
the others devs!

Best regards,
Bart

Christopher Schmidt wrote:
> I think we're all done with bugs in OL 2.8. So, I'd like to motion that
> RC5 be declared a final release, with myself doing the release work.
>
> +1 from me.
>
> Best Regards,
>   


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


From schuyler at nocat.net  Fri Jun  5 13:01:24 2009
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <6ae3fb590906050859p4bf5181dha011f96a2cf7e658@mail.gmail.com>
References: <20090605155916.GG17782@metacarta.com>
	<6ae3fb590906050859p4bf5181dha011f96a2cf7e658@mail.gmail.com>
Message-ID: <1244221284.24008.5.camel@goldman>

I'll echo this, +0, and I want to thank everyone involved for their
continued hard work on OpenLayers. Your efforts continue to demonstrate
the amazing efficacy of Open Source Done Right.

SDE

On Fri, 2009-06-05 at 10:59 -0500, Erik Uzureau wrote:
> Must admit I haven't really been paying too close attention to this
> release cycle... so 
> just as a vote of confidence, I'll 
> 
> +0
> 
> On Fri, Jun 5, 2009 at 10:59, Christopher Schmidt
> <crschmidt@metacarta.com> wrote:
>         I think we're all done with bugs in OL 2.8. So, I'd like to
>         motion that
>         RC5 be declared a final release, with myself doing the release
>         work.
>         
>         +1 from me.
>         
>         Best Regards,
>         --
>         Christopher Schmidt
>         MetaCarta
>         _______________________________________________
>         Dev mailing list
>         Dev@openlayers.org
>         http://openlayers.org/mailman/listinfo/dev
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


From tschaub at opengeo.org  Fri Jun  5 13:43:27 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Make RC5 final?
In-Reply-To: <20090605155916.GG17782@metacarta.com>
References: <20090605155916.GG17782@metacarta.com>
Message-ID: <4A29593F.5040609@opengeo.org>

Hey-

Christopher Schmidt wrote:
> I think we're all done with bugs in OL 2.8. So, I'd like to motion that
> RC5 be declared a final release, with myself doing the release work.
> 
> +1 from me.
> 

+1 from me too.

Go 2.8!

Tim

> Best Regards,


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From bjorn.harrtell at gmail.com  Fri Jun  5 20:21:29 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
Message-ID: <ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>

Not yet, but I was informed by Tim Schaub about the registerPriority
method on the Event class. I suspect that snapping needs the priority
though, but that's a bit of a guess right now.

I made an effort towards the Control-implementation in sandbox which
I'm reasonably happy with and the code now tries to follow the coding
standards of OL, so I guess the only thing missing now from the
implementation is testcases. That might take a while for me so I'll
probably create an initial patch for review and discussion against
post 2.8 trunk when 2.8 is released.

/Bj?rn

On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowling@gmail.com> wrote:
> I think it makes perfect sense to separate the Topology component into its
> own Control. Were you able to alter the priority of the Snapping vs.
> Topology controls?
>
> -Evan
>
> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>
>>
>> I've rewritten the implementation so that topology isn't calculated on
>> the fly, which I think might solve the problem discussed below and
>> also improves performance.
>>
>> In doing this I got to think about the initial proposal. A redesign
>> that popped up in my head is to remove the idea that rules are applied
>> to a Vector layer and instead add a new Control called Topology that
>> controls the enforcement and renderIntent-stuff for the supplied layer
>> (or layer)
>>
>> The basic idea with the above is to be able to leave the Vector Layer
>> completely unmodified (it's large as it is :) and also put all user
>> configurable interaction with the functionality in the control instead
>> of manipulating the rule. Any opinions?
>>
>> /Bj?rn
>>
>> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>> > The issue you describe is probably caused by conflicts between
>> > snapping and topology enforcement, more specifically both snapping and
>> > topology enforcement listen on vertexmodified-events and the order of
>> > this combined logic is significant. I haven't investigated if I can
>> > control priority of my event listener, but if that's possible I think
>> > it would solve the problems.
>> >
>> > On another note, the sandbox and example is now updated with an
>> > initial implementation of the renderIntent-idea which means that at
>> > each completed feature modification the state of topology will be
>> > calculated and polygon that does not satisfy the rule will be set into
>> > the renderIntent state "error" and will be colored in red.
>> >
>> > /Bj?rn
>> >
>> > On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com>
>> > wrote:
>> >> Hi Bj?rn,
>> >>
>> >> Great initiative! Topology preserving editing functionality would be a
>> >> very
>> >> valuably contribution to OL (IMHO).
>> >> I did notice that when you edit one feature, then uncheck 'enforce
>> >> topology', edit a bit more (by moving vertices) and then check 'enforce
>> >> topology' again, the enforcing does not work anymore when you move more
>> >> than
>> >> the snapping threshold. I know this is work in progress, so you might
>> >> be
>> >> aware of it already.
>> >>
>> >> I'm sure that more than 1 person (2 now, including me) will be
>> >> interested in
>> >> your work!
>> >>
>> >> Regards, Roald
>> >>
>> >>
>> >> Bj?rn Harrtell wrote:
>> >>>
>> >>> Since I got at least one (and hopefully more :) interested person(s)
>> >>> in the details I'm posting this information about my initial
>> >>> implementation of the below proposal using using events in this
>> >>> sandbox:
>> >>>
>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>> >>>
>> >>> Check out the example at
>> >>>
>> >>>
>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
>> >>> to see the implementation in effect.
>> >>>
>> >>> The only change from the initial proposal is that
>> >>> OpenLayers.Control.ModifyFeature essentially does not have to be
>> >>> modified, which is made possible by basing the implementation on the
>> >>> vertexmodified event - though I do have added and are using
>> >>> delta-movement information to the vertexmodified event-message, which
>> >>> required small changes in DragFeature and ModifyFeature controls to
>> >>> fill in this information.
>> >>>
>> >>> New classes are:
>> >>> OpenLayers.Topology
>> >>> OpenLayers.Topology.Rule
>> >>> OpenLayers.Topology.Rule.VerticesMustIntersect
>> >>>
>> >>> The implementation is dynamic which means that the topology rule is
>> >>> evaluated at each change of the geometry which I think should be
>> >>> optional since this can be costly with more complex geometry and can
>> >>> cause wierd side-effects when using snapping for instance. I'd like to
>> >>> add some kind of caching in the future that would require manual or
>> >>> semi-manual update of the topology state.
>> >>>
>> >>> The render intent stuff is not done yet.
>> >>>
>> >>> Forgive me if I've forgot some detail in the above description :)
>> >>>
>> >>> /Bj?rn
>> >>>
>> >>> 2009/4/22 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>> >>>
>> >>>>
>> >>>> Hi devs,
>> >>>>
>> >>>> I want to make an effort to implement a topology restriction in
>> >>>> OpenLayers (specifically that polygons must share vertices). The
>> >>>> ideal
>> >>>> would be something that is reusable for other topology rules than the
>> >>>> one I want to implement at first and my intent is to build it so that
>> >>>> it can be contributed as a patch. I've discussed the matter with Tim
>> >>>> briefly and here is my rough initial design proposal. Any feedback
>> >>>> will of course be appreciated.
>> >>>>
>> >>>> I wanted to add this to the wiki at Proposal/Topology but seems I
>> >>>> can't create new wikipages even when I'm logged in, or I'm missing
>> >>>> something. So here is it:
>> >>>>
>> >>>> * Represent topology rules as classes in namespace
>> >>>> OpenLayers.Topology.Rule with a base class OpenLayers.Topology.Rule
>> >>>> (I
>> >>>> don't really like using the same identifier as a namespace and class,
>> >>>> but I think this is the convention in OpenLayers?). The base class
>> >>>> should provide an interface for checking feature(s) for topology
>> >>>> errors and optionally set the render intent and return the violating
>> >>>> features.
>> >>>>
>> >>>> * Add a render intent for indicating topology violation
>> >>>>
>> >>>> * Add topologyRules property to OpenLayers.Layer.Vector as an
>> >>>> optional
>> >>>> array of topology classes to associate with the layer
>> >>>>
>> >>>> * Add topologyAutoCheck boolean property to OpenLayers.Layer.Vector
>> >>>> to
>> >>>> indicate if a vector layer automatically should update the topology
>> >>>> render intent on feature changes (default false)
>> >>>>
>> >>>> * Add enforceTopology boolean property to
>> >>>> OpenLayers.Control.ModifyFeature to restrict edits to follow the
>> >>>> topology rule by either automatically snapping stuff (if possible) or
>> >>>> disallowing the interaction.
>> >>>>
>> >>>> * The first rule to be implemented is that polygons must share
>> >>>> vertices, suggested name is
>> >>>> OpenLayers.Topology.Rules.PolygonsMustShareVertices
>> >>>>
>> >>>> Motivations:
>> >>>>
>> >>>> * Topology rules could be constant enums instead of classes, the
>> >>>> reasons for suggesting classes are to make it more clear that the
>> >>>> rule
>> >>>> should contain as much of the implementation as possible and that one
>> >>>> might want to make OL-builds containing only the rules that are
>> >>>> relevant for the use case.
>> >>>>
>> >>>> Uncertainties:
>> >>>>
>> >>>> * Where to put the logic that restricts editing - I'm not sure if
>> >>>> it's
>> >>>> possible to separate it without creating a dependency mess between
>> >>>> ModifyControl and the topology rule.
>> >>>>
>> >>>> With regards,
>> >>>>
>> >>>> Bj?rn Harrtell
>> >>>>
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> Dev mailing list
>> >>> Dev@openlayers.org
>> >>> http://openlayers.org/mailman/listinfo/dev
>> >>>
>> >>
>> >>
>> >
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>
>

From bartvde at osgis.nl  Mon Jun  8 04:41:25 2009
From: bartvde at osgis.nl (bartvde@osgis.nl)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] prevent layers from getting added
Message-ID: <55663.145.50.39.11.1244450485.squirrel@webmail.hostingdiscounter.nl>

Hi list,

currently there seems no option to prevent layers from getting added to
the map object. I thought I could use the preaddlayer event for this, but
that does not seem possible currently.

Is there interest in creating a patch for such a feature? Do people think
this would be useful general functionality?

Best regards,
Bart


From jdg at geosphere.fr  Mon Jun  8 08:07:38 2009
From: jdg at geosphere.fr (Jean-Daniel JDG. GONON)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Error with style.addRule in OL2.7 and IE8 and IE7
	mode compatibility
Message-ID: <E2ADD67225897645BB9082D293842F2380005A@mercure.MESSAGERIE.local>

Hi all

 

With OpenLayers 2.7, I have an error in
/OpenLayers2.7/lib/OpenLayers/Renderer/VML.js using IE8 and IE7
compatibility mode.

 

I tested the 3 patchs on this ticket
http://trac.openlayers.org/ticket/1910 :

 

With IE8_Generic_CSSPrefix_Selectors.patch and vml.patch
<http://trac.openlayers.org/attachment/ticket/1910/vml.patch>  , the
page of the map isn't loaded with errors.

 

With vml2.patch and IE8 (in IE7, the page of the map isn't loaded with
errors), the map is loaded and all functionalities are OK. 

But when I want to select features, the form of the polygon/point select
is drawn with a lag of extents.

 

And if I want to draw a point or polygon, the form of the polygon/point
isn't drawn.

 

Is there a solution that is not on internet http://trac.openlayers.org/
?

 

Tkanks

JD

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090608/38bd5c47/attachment.html
From m.r.deogade at gmail.com  Mon Jun  8 08:58:39 2009
From: m.r.deogade at gmail.com (Mohanish Deogade)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Mohanish's Birthday Calendar
Message-ID: <E067.2009-06-08.125839439@BirthdayAlarm.com>

Hi

I am creating a birthday calendar of all my friends and family.  Can you please click on the link below to enter your birthday for me?

http://www.birthdayalarm.com/bd2/84012023a677260570b1470325907c794671434d1386

Thanks,
Mohanish


From jlacroix at mapgears.com  Mon Jun  8 10:13:59 2009
From: jlacroix at mapgears.com (Julien-Samuel Lacroix)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] prevent layers from getting added
In-Reply-To: <55663.145.50.39.11.1244450485.squirrel@webmail.hostingdiscounter.nl>
References: <55663.145.50.39.11.1244450485.squirrel@webmail.hostingdiscounter.nl>
Message-ID: <4A2D1CA7.6070704@mapgears.com>

Hi,

Can you explain the use case of this? Why are you creating the layers 
object to prevent them to be added to the map object?

Thanks
Julien

bartvde@osgis.nl wrote:
> Hi list,
> 
> currently there seems no option to prevent layers from getting added to
> the map object. I thought I could use the preaddlayer event for this, but
> that does not seem possible currently.
> 
> Is there interest in creating a patch for such a feature? Do people think
> this would be useful general functionality?
> 
> Best regards,
> Bart
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 

-- 
Julien-Samuel Lacroix
Mapgears
http://www.mapgears.com/

From tschaub at opengeo.org  Mon Jun  8 11:03:12 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] prevent layers from getting added
In-Reply-To: <55663.145.50.39.11.1244450485.squirrel@webmail.hostingdiscounter.nl>
References: <55663.145.50.39.11.1244450485.squirrel@webmail.hostingdiscounter.nl>
Message-ID: <4A2D2830.50106@opengeo.org>

Hey-

bartvde@osgis.nl wrote:
> Hi list,
> 
> currently there seems no option to prevent layers from getting added to
> the map object. I thought I could use the preaddlayer event for this, but
> that does not seem possible currently.
> 

I think any "before{subject}{predicate}" listener should be able to 
return false to stop the pertinent action.  I'd consider any patch 
adding this behavior a step in the right direction (even if the event 
name doesn't conform with that template).

Tim

> Is there interest in creating a patch for such a feature? Do people think
> this would be useful general functionality?
> 
> Best regards,
> Bart
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From eric.lemoine at camptocamp.com  Tue Jun  9 02:01:48 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
Message-ID: <ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>

On Saturday, June 6, 2009, Bj?rn Harrtell <bjorn.harrtell@gmail.com> wrote:
> Not yet, but I was informed by Tim Schaub about the registerPriority
> method on the Event class

for some reason I dont know this method is marked "3.0 remove" IIRC.

>  I suspect that snapping needs the priority
> though, but that's a bit of a guess right now.
>
> I made an effort towards the Control-implementation in sandbox which
> I'm reasonably happy with and the code now tries to follow the coding
> standards of OL, so I guess the only thing missing now from the
> implementation is testcases. That might take a while for me so I'll
> probably create an initial patch for review and discussion against
> post 2.8 trunk when 2.8 is released.

This is great work Bj?rn!

I haven't looked at your code, so I'd just have one unimportant
comment: do you envision other stuff than Rule under the
OpenLayers.Topology namespace? If not I'd rather go with
OpenLayers.TopologyRule to keep namespace depth minimal. What do you
think?



>
> /Bj?rn
>
> On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowling@gmail.com> wrote:
>> I think it makes perfect sense to separate the Topology component into its
>> own Control. Were you able to alter the priority of the Snapping vs.
>> Topology controls?
>>
>> -Evan
>>
>> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>
>>>
>>> I've rewritten the implementation so that topology isn't calculated on
>>> the fly, which I think might solve the problem discussed below and
>>> also improves performance.
>>>
>>> In doing this I got to think about the initial proposal. A redesign
>>> that popped up in my head is to remove the idea that rules are applied
>>> to a Vector layer and instead add a new Control called Topology that
>>> controls the enforcement and renderIntent-stuff for the supplied layer
>>> (or layer)
>>>
>>> The basic idea with the above is to be able to leave the Vector Layer
>>> completely unmodified (it's large as it is :) and also put all user
>>> configurable interaction with the functionality in the control instead
>>> of manipulating the rule. Any opinions?
>>>
>>> /Bj?rn
>>>
>>> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>> > The issue you describe is probably caused by conflicts between
>>> > snapping and topology enforcement, more specifically both snapping and
>>> > topology enforcement listen on vertexmodified-events and the order of
>>> > this combined logic is significant. I haven't investigated if I can
>>> > control priority of my event listener, but if that's possible I think
>>> > it would solve the problems.
>>> >
>>> > On another note, the sandbox and example is now updated with an
>>> > initial implementation of the renderIntent-idea which means that at
>>> > each completed feature modification the state of topology will be
>>> > calculated and polygon that does not satisfy the rule will be set into
>>> > the renderIntent state "error" and will be colored in red.
>>> >
>>> > /Bj?rn
>>> >
>>> > On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com>
>>> > wrote:
>>> >> Hi Bj?rn,
>>> >>
>>> >> Great initiative! Topology preserving editing functionality would be a
>>> >> very
>>> >> valuably contribution to OL (IMHO).
>>> >> I did notice that when you edit one feature, then uncheck 'enforce
>>> >> topology', edit a bit more (by moving vertices) and then check 'enforce
>>> >> topology' again, the enforcing does not work anymore when you move more
>>> >> than
>>> >> the snapping threshold. I know this is work in progress, so you might
>>> >> be
>>> >> aware of it already.
>>> >>
>>> >> I'm sure that more than 1 person (2 now, including me) will be
>>> >> interested in
>>> >> your work!
>>> >>
>>> >> Regards, Roald
>>> >>
>>> >>
>>> >> Bj?rn Harrtell wrote:
>>> >>>
>>> >>> Since I got at least one (and hopefully more :) interested person(s)
>>> >>> in the details I'm posting this information about my initial
>>> >>> implementation of the below proposal using using events in this
>>> >>> sandbox:
>>> >>>
>>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>>> >>>
>>> >>> Check out the example at
>>> >>>
>>> >>>
>>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
>>> >>> to see the implementation in effect.
>>> >>>
>>> >>> The only change from the initial proposal is t

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From falcacibar at gmail.com  Tue Jun  9 06:06:29 2009
From: falcacibar at gmail.com (Felipe Alcacibar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Google Base Layer and WMS Cover
Message-ID: <72e3fc8f0906090306t3f32c819u5e8034ef4a33765a@mail.gmail.com>

Hi, i have a Google Base Layer and a WMS cover, y convert my
cartography (WMS cover) to epsg:4326 WCS WGS84 the problem come when i
panTo or zoom, when openlayers draw the map the WMS layer its above
that the place that must be shown, when i deactivate and activate the
layer using the layer switcher, redrawi in the correct place i have
something wrong or it is a bug?

I'm using openlayers 2.7

cheers, take care.

Felipe


/// the JavaScript Source


extent					= "-74.65234 -51.01375  -70.45508 -30.37288".split(/[,
]+/);
			for (i=0;i<extent.length;i++) extent[i] = parseFloat(extent[i]);
			
			var mapdim				= getElementDimensions($('map'));
			myBounds				= new OpenLayers.Bounds(
																extent[0], extent[1],
																extent[2], extent[3]
									  );
			var zoomAttributes = {						
										numZoomLevels		: 19,
										minZoomLevel		: 5,
										transitionEffect	: 'resize'
			}

			
			
            map = new OpenLayers.Map( 'map', {
				numZoomLevels		: 19,
				minZoomLevel		: 5,            	            	
				maxExtent			: myBounds,				
				restrictedExtent	: myBounds,				
				projection			: new OpenLayers.Projection('epsg:4326'),								
				tileSize			: new OpenLayers.Size(600, 600),													
				buffer				: 3,				
				controls			: [
										new OpenLayers.Control.Navigation(),
										new OpenLayers.Control.PanZoomBar(),
										new OpenLayers.Control.MousePosition({div : $('map-coords'),
title : 'Coordenadas de la posicion del puntero.'}),
										new OpenLayers.Control.NavToolbar(),
										new OpenLayers.Control.ZoomBox(),
										new OpenLayers.Control.Scale($('map-scale')),
										new OpenLayers.Control.ScaleLine()
										
				]													
            });

	    	map.addControl(new OpenLayers.Control.LayerSwitcher());
			
            var ghyb = new OpenLayers.Layer.Google(
                "Google Hybrid",
                OpenLayers.Util.extend(zoomAttributes, {type: G_HYBRID_MAP})
            );			
            var gphy = new OpenLayers.Layer.Google(
                "Google Physical",
                OpenLayers.Util.extend(zoomAttributes, {type: G_PHYSICAL_MAP})
            );
            var gmap = new OpenLayers.Layer.Google(
                "Google Streets", // the default
                OpenLayers.Util.extend(zoomAttributes, {type : null})
            );
            var gsat = new OpenLayers.Layer.Google(
                "Google Satellite",
                OpenLayers.Util.extend(zoomAttributes, {type: G_SATELLITE_MAP})
            );

		    wmsl = new OpenLayers.Layer.WMS( 'Mapa WMS',
					httpBase + "/wms/", {
							layers 				: 'rodales',
							format 				: "image/png; mode=24bit",	
							alpha				: true,
							projection			: new OpenLayers.Projection('epsg:4326')
							
					},{	
							isBaseLayer : false,
					}
		    );
			
            map.addLayers([ghyb, gphy, gmap, gsat]);
	   	 	map.addLayer(wmsl);
			
            map.setCenter(myBounds.getCenterLonLat(), 0);

From bjorn.harrtell at gmail.com  Tue Jun  9 08:08:06 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
Message-ID: <ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>

Thanks Eric :)

Details are important, though I would argue that
OpenLayers.TopologyRule is only one char shorter than
OpenLayers.Topology.Rule ;)

I've improved the current sandbox code (optimizations and bugfixes)
and I'm using registerPriority which does seem to fix the problems
when using the splitting control at the same time.

Two random thoughts:

1. Does the topology stuff really fit into OpenLayers or should be
done as an add-in? Might become alot of code if many rules are done...

2. The current implementation calculates topology state as a cache
separate from the basic geometry types. The dynamic nature of
javascript might allow "real" topology.. by this I mean that for
example a Point-instance could be shared between two different
LineString-instances. but I haven't tested this at all and would
complicate feature manipulation and communication with a backend via
WFS.

/Bj?rn

On Tue, Jun 9, 2009 at 08:01, Eric Lemoine<eric.lemoine@camptocamp.com> wrote:
> On Saturday, June 6, 2009, Bj?rn Harrtell <bjorn.harrtell@gmail.com> wrote:
>> Not yet, but I was informed by Tim Schaub about the registerPriority
>> method on the Event class
>
> for some reason I dont know this method is marked "3.0 remove" IIRC.
>
>> ?I suspect that snapping needs the priority
>> though, but that's a bit of a guess right now.
>>
>> I made an effort towards the Control-implementation in sandbox which
>> I'm reasonably happy with and the code now tries to follow the coding
>> standards of OL, so I guess the only thing missing now from the
>> implementation is testcases. That might take a while for me so I'll
>> probably create an initial patch for review and discussion against
>> post 2.8 trunk when 2.8 is released.
>
> This is great work Bj?rn!
>
> I haven't looked at your code, so I'd just have one unimportant
> comment: do you envision other stuff than Rule under the
> OpenLayers.Topology namespace? If not I'd rather go with
> OpenLayers.TopologyRule to keep namespace depth minimal. What do you
> think?
>
>
>
>>
>> /Bj?rn
>>
>> On Fri, Jun 5, 2009 at 17:20, Evan James Bowling<evan.bowling@gmail.com> wrote:
>>> I think it makes perfect sense to separate the Topology component into its
>>> own Control. Were you able to alter the priority of the Snapping vs.
>>> Topology controls?
>>>
>>> -Evan
>>>
>>> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>
>>>>
>>>> I've rewritten the implementation so that topology isn't calculated on
>>>> the fly, which I think might solve the problem discussed below and
>>>> also improves performance.
>>>>
>>>> In doing this I got to think about the initial proposal. A redesign
>>>> that popped up in my head is to remove the idea that rules are applied
>>>> to a Vector layer and instead add a new Control called Topology that
>>>> controls the enforcement and renderIntent-stuff for the supplied layer
>>>> (or layer)
>>>>
>>>> The basic idea with the above is to be able to leave the Vector Layer
>>>> completely unmodified (it's large as it is :) and also put all user
>>>> configurable interaction with the functionality in the control instead
>>>> of manipulating the rule. Any opinions?
>>>>
>>>> /Bj?rn
>>>>
>>>> 2009/6/4 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>>> > The issue you describe is probably caused by conflicts between
>>>> > snapping and topology enforcement, more specifically both snapping and
>>>> > topology enforcement listen on vertexmodified-events and the order of
>>>> > this combined logic is significant. I haven't investigated if I can
>>>> > control priority of my event listener, but if that's possible I think
>>>> > it would solve the problems.
>>>> >
>>>> > On another note, the sandbox and example is now updated with an
>>>> > initial implementation of the renderIntent-idea which means that at
>>>> > each completed feature modification the state of topology will be
>>>> > calculated and polygon that does not satisfy the rule will be set into
>>>> > the renderIntent state "error" and will be colored in red.
>>>> >
>>>> > /Bj?rn
>>>> >
>>>> > On Wed, Jun 3, 2009 at 00:21, Roald de Wit <roald.dewit@lisasoft.com>
>>>> > wrote:
>>>> >> Hi Bj?rn,
>>>> >>
>>>> >> Great initiative! Topology preserving editing functionality would be a
>>>> >> very
>>>> >> valuably contribution to OL (IMHO).
>>>> >> I did notice that when you edit one feature, then uncheck 'enforce
>>>> >> topology', edit a bit more (by moving vertices) and then check 'enforce
>>>> >> topology' again, the enforcing does not work anymore when you move more
>>>> >> than
>>>> >> the snapping threshold. I know this is work in progress, so you might
>>>> >> be
>>>> >> aware of it already.
>>>> >>
>>>> >> I'm sure that more than 1 person (2 now, including me) will be
>>>> >> interested in
>>>> >> your work!
>>>> >>
>>>> >> Regards, Roald
>>>> >>
>>>> >>
>>>> >> Bj?rn Harrtell wrote:
>>>> >>>
>>>> >>> Since I got at least one (and hopefully more :) interested person(s)
>>>> >>> in the details I'm posting this information about my initial
>>>> >>> implementation of the below proposal using using events in this
>>>> >>> sandbox:
>>>> >>>
>>>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology
>>>> >>>
>>>> >>> Check out the example at
>>>> >>>
>>>> >>>
>>>> >>> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology/examples/topology.html
>>>> >>> to see the implementation in effect.
>>>> >>>
>>>> >>> The only change from the initial proposal is t
>
> --
> Eric Lemoine
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac, Cedex
>
> Tel : 00 33 4 79 44 44 96
> Mail : eric.lemoine@camptocamp.com
> http://www.camptocamp.com
>

From crschmidt at metacarta.com  Tue Jun  9 08:24:24 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Google Base Layer and WMS Cover
In-Reply-To: <72e3fc8f0906090306t3f32c819u5e8034ef4a33765a@mail.gmail.com>
References: <72e3fc8f0906090306t3f32c819u5e8034ef4a33765a@mail.gmail.com>
Message-ID: <20090609122421.GG15594@metacarta.com>

On Tue, Jun 09, 2009 at 06:06:29AM -0400, Felipe Alcacibar wrote:
> Hi, i have a Google Base Layer and a WMS cover, y convert my
> cartography (WMS cover) to epsg:4326 WCS WGS84 the problem come when i
> panTo or zoom, when openlayers draw the map the WMS layer its above
> that the place that must be shown, when i deactivate and activate the
> layer using the layer switcher, redrawi in the correct place i have
> something wrong or it is a bug?

"In order to properly overlay data on top of the maps provided by the
commerical API providers, it is neccesary to use this projection. This
applies primarily to displaying raster tiles over the commercial API
layers ??? such as TMS, WMS, or other similar tiles." --
http://docs.openlayers.org/library/spherical_mercator.html

> I'm using openlayers 2.7
> 
> cheers, take care.
> 
> Felipe
> 
> 
> /// the JavaScript Source
> 
> 
> extent					= "-74.65234 -51.01375  -70.45508 -30.37288".split(/[,
> ]+/);
> 			for (i=0;i<extent.length;i++) extent[i] = parseFloat(extent[i]);
> 			
> 			var mapdim				= getElementDimensions($('map'));
> 			myBounds				= new OpenLayers.Bounds(
> 																extent[0], extent[1],
> 																extent[2], extent[3]
> 									  );
> 			var zoomAttributes = {						
> 										numZoomLevels		: 19,
> 										minZoomLevel		: 5,
> 										transitionEffect	: 'resize'
> 			}
> 
> 			
> 			
>             map = new OpenLayers.Map( 'map', {
> 				numZoomLevels		: 19,
> 				minZoomLevel		: 5,            	            	
> 				maxExtent			: myBounds,				
> 				restrictedExtent	: myBounds,				
> 				projection			: new OpenLayers.Projection('epsg:4326'),								
> 				tileSize			: new OpenLayers.Size(600, 600),													
> 				buffer				: 3,				
> 				controls			: [
> 										new OpenLayers.Control.Navigation(),
> 										new OpenLayers.Control.PanZoomBar(),
> 										new OpenLayers.Control.MousePosition({div : $('map-coords'),
> title : 'Coordenadas de la posicion del puntero.'}),
> 										new OpenLayers.Control.NavToolbar(),
> 										new OpenLayers.Control.ZoomBox(),
> 										new OpenLayers.Control.Scale($('map-scale')),
> 										new OpenLayers.Control.ScaleLine()
> 										
> 				]													
>             });
> 
> 	    	map.addControl(new OpenLayers.Control.LayerSwitcher());
> 			
>             var ghyb = new OpenLayers.Layer.Google(
>                 "Google Hybrid",
>                 OpenLayers.Util.extend(zoomAttributes, {type: G_HYBRID_MAP})
>             );			
>             var gphy = new OpenLayers.Layer.Google(
>                 "Google Physical",
>                 OpenLayers.Util.extend(zoomAttributes, {type: G_PHYSICAL_MAP})
>             );
>             var gmap = new OpenLayers.Layer.Google(
>                 "Google Streets", // the default
>                 OpenLayers.Util.extend(zoomAttributes, {type : null})
>             );
>             var gsat = new OpenLayers.Layer.Google(
>                 "Google Satellite",
>                 OpenLayers.Util.extend(zoomAttributes, {type: G_SATELLITE_MAP})
>             );
> 
> 		    wmsl = new OpenLayers.Layer.WMS( 'Mapa WMS',
> 					httpBase + "/wms/", {
> 							layers 				: 'rodales',
> 							format 				: "image/png; mode=24bit",	
> 							alpha				: true,
> 							projection			: new OpenLayers.Projection('epsg:4326')
> 							
> 					},{	
> 							isBaseLayer : false,
> 					}
> 		    );
> 			
>             map.addLayers([ghyb, gphy, gmap, gsat]);
> 	   	 	map.addLayer(wmsl);
> 			
>             map.setCenter(myBounds.getCenterLonLat(), 0);
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Tue Jun  9 08:26:30 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
Message-ID: <20090609122630.GH15594@metacarta.com>

On Tue, Jun 09, 2009 at 08:01:48AM +0200, Eric Lemoine wrote:
> On Saturday, June 6, 2009, Bj?rn Harrtell <bjorn.harrtell@gmail.com> wrote:
> > Not yet, but I was informed by Tim Schaub about the registerPriority
> > method on the Event class
> 
> for some reason I dont know this method is marked "3.0 remove" IIRC.

Because registerPriority should likely be the default; 'register' should
probably go to the beginning of the list, not the end, or at least have
an option, rather than two different methods.

-- Chris

Regards,
-- 
Christopher Schmidt
MetaCarta

From Niklas.Ringdahl at sweco.se  Tue Jun  9 10:29:21 2009
From: Niklas.Ringdahl at sweco.se (Ringdahl Niklas)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Alternating base layers
In-Reply-To: <20090609122630.GH15594@metacarta.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com><ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com><4A25A606.1070702@lisasoft.com><ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com><ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com><d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com><ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com><ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
	<20090609122630.GH15594@metacarta.com>
Message-ID: <0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>

Hello list.

I have two different raster layers with different coordinate systems;
one is a Google Satellite layer and the other is a tiled layer in
epsg:2400. Depending on scale, I would like to select either as the base
layer and keep the WMS and WFS overlays independent of which base layer
is used. 

The way I envision this is to add them both to the map and use the
map.setBaseLayer method to alternate. Is this approach complete, or are
there other considerations to make, keeping the different reference
systems in mind? What kind of trouble will I get myself into with this?

I would be happy for any pointer in the right direction on this. Thanks!

- Niklas Ringdahl



From crschmidt at metacarta.com  Tue Jun  9 10:37:56 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Alternating base layers
In-Reply-To: <0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>
References: <20090609122630.GH15594@metacarta.com>
	<0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>
Message-ID: <20090609143755.GJ15594@metacarta.com>

On Tue, Jun 09, 2009 at 04:29:21PM +0200, Ringdahl Niklas wrote:
> Hello list.
> 
> I have two different raster layers with different coordinate systems;
> one is a Google Satellite layer and the other is a tiled layer in
> epsg:2400. Depending on scale, I would like to select either as the base
> layer and keep the WMS and WFS overlays independent of which base layer
> is used. 

This is not particularly easy with the current version of OpeNLayers.
#1249 is tracking possible additions which would make this easier, but
is not planned for any particular release. In particular, the overlays
-- particularly vector overlays -- would likely need to be refreshed,
which might not happen.

If all of your data is based on BBOX-style requests -- that is, the data
changes when the extents change -- this might 'just work', though when
you change layers, i expect that the center will likely go to the wrong
place, so you'll need to do some work to set/restore that.

-- Chris

> The way I envision this is to add them both to the map and use the
> map.setBaseLayer method to alternate. Is this approach complete, or are
> there other considerations to make, keeping the different reference
> systems in mind? What kind of trouble will I get myself into with this?
> 
> I would be happy for any pointer in the right direction on this. Thanks!
> 
> - Niklas Ringdahl
> 
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta

From trondmm-openlayers at crusaders.no  Tue Jun  9 10:50:55 2009
From: trondmm-openlayers at crusaders.no (Trond Michelsen)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Alternating base layers
In-Reply-To: <0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>
References: <20090609122630.GH15594@metacarta.com>
	<0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>
Message-ID: <20090609145055.GF17360@crusaders.no>

On Tue, Jun 09, 2009 at 04:29:21PM +0200, Ringdahl Niklas wrote:
> I have two different raster layers with different coordinate systems;
> one is a Google Satellite layer and the other is a tiled layer in
> epsg:2400. Depending on scale, I would like to select either as the base
> layer and keep the WMS and WFS overlays independent of which base layer
> is used. 
> 
> The way I envision this is to add them both to the map and use the
> map.setBaseLayer method to alternate. Is this approach complete, or are
> there other considerations to make, keeping the different reference
> systems in mind? What kind of trouble will I get myself into with this?
> 
> I would be happy for any pointer in the right direction on this. Thanks!

I've done something similar to what you want. I've just implemented it
as three buttons you can click to switch projection, but I don't think
it should be too hard to trigger it by a layer change. 

As Christopher said, vector layers also needs to be reprojected, and
I've made no effort to do this in my solution. Adding a
setProjection() function to the Vector Layer class, that does The
Right Thing (tm), should do the trick, though.

Here is all the relevant code (I think...) needed:

OpenLayers.Map.prototype.setCenterProj = function (center, zoom, projection, params) {
    this.setProjection(projection, params);
    this.setCenter(center, zoom, true, true);
}

OpenLayers.Map.prototype.setProjection = function (projection, params) {
    this.projection = projection;

    for (var key in params) {
        this[key] = params[key];
    }
    for (var i=0; i< this.layers.length; i++) {
        this.layers[i].setProjection(projection, params);
    }
};

OpenLayers.Layer.WMS.prototype.setProjection = function (projection, params) {
    this.projection = projection;
    for (var key in params) {
        this[key] = params[key];
    }
    this.initResolutions();
};

OpenLayers.Layer.WMS.Untiled.prototype.setProjection = OpenLayers.Layer.WMS.prototype.setProjection;

GLOBAL.projections = {
  mercator: {projparams: {maxExtent: new OpenLayers.Bounds(-20014.0868, -20014.0868, 20016.0868, 20016.0868),
                          maxResolution: 50.037717,
                          units: "km"},
             projcode: "EPSG:41000",
             center: new OpenLayers.LonLat(0,0),
             zoom: 0},

  npole:  {projparams: {maxExtent: new OpenLayers.Bounds(-11888450, -11888450, 11888450, 11888450),
                        maxResolution: 29721.125/2,
                        units: "m"},
           projcode: "EPSG:42000",
           center: new OpenLayers.LonLat(0,0),
           zoom: 1},

  spole:  {projparams: {maxExtent: new OpenLayers.Bounds(-11888450, -11888450, 11888450, 11888450),
                        maxResolution: 29721.125/2,
                        units: "m"},
           projcode: "EPSG:43000",
           center: new OpenLayers.LonLat(0,0),
           zoom: 1}
};

function reproject (projname) {
    var map    = GLOBAL.map;
    var params = GLOBAL.projections[ projname ];
    var proj   = new OpenLayers.Projection(params.projcode);
    map.setCenterProj(params.center, params.zoom, proj, params.projparams);
}

and then in the webpage, there are three buttons like this:

<button id="bt_npol"  name="npole"    value="npole"    onClick="reproject(&quot;npole&quot;)">North Pole</button>
<button id="bt_merc"  name="mercator" value="Mercator" onClick="reproject(&quot;mercator&quot;)">Global</button>
<button id="bt_spol"  name="spole"    value="spole"    onClick="reproject(&quot;spole&quot;)">South Pole</button>

-- 
Trond Michelsen

From Niklas.Ringdahl at sweco.se  Tue Jun  9 11:15:06 2009
From: Niklas.Ringdahl at sweco.se (Ringdahl Niklas)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Alternating base layers
In-Reply-To: <20090609145055.GF17360@crusaders.no>
References: <20090609122630.GH15594@metacarta.com>
	<0A5D74014A47C44291FBA6BD64630D675B9C99@essth023.sweco.se>
	<20090609145055.GF17360@crusaders.no>
Message-ID: <0A5D74014A47C44291FBA6BD64630D675B9CF7@essth023.sweco.se>

Christopher and Trond, thanks for quick responses.

Trond: your code looks very promising, I will try it out ASAP! 

- Niklas




-----Ursprungligt meddelande-----
Fr?n: Trond Michelsen [mailto:trondmm-openlayers@crusaders.no] 
Skickat: den 9 juni 2009 16:51
Till: Ringdahl Niklas; OpenLayers developers list
?mne: Re: [OpenLayers-Dev] Alternating base layers

On Tue, Jun 09, 2009 at 04:29:21PM +0200, Ringdahl Niklas wrote:
> I have two different raster layers with different coordinate systems; 
> one is a Google Satellite layer and the other is a tiled layer in 
> epsg:2400. Depending on scale, I would like to select either as the 
> base layer and keep the WMS and WFS overlays independent of which base 
> layer is used.
> 
> The way I envision this is to add them both to the map and use the 
> map.setBaseLayer method to alternate. Is this approach complete, or 
> are there other considerations to make, keeping the different 
> reference systems in mind? What kind of trouble will I get myself into with this?
> 
> I would be happy for any pointer in the right direction on this. Thanks!

I've done something similar to what you want. I've just implemented it as three buttons you can click to switch projection, but I don't think it should be too hard to trigger it by a layer change. 

As Christopher said, vector layers also needs to be reprojected, and I've made no effort to do this in my solution. Adding a
setProjection() function to the Vector Layer class, that does The Right Thing (tm), should do the trick, though.

Here is all the relevant code (I think...) needed:

OpenLayers.Map.prototype.setCenterProj = function (center, zoom, projection, params) {
    this.setProjection(projection, params);
    this.setCenter(center, zoom, true, true); }

OpenLayers.Map.prototype.setProjection = function (projection, params) {
    this.projection = projection;

    for (var key in params) {
        this[key] = params[key];
    }
    for (var i=0; i< this.layers.length; i++) {
        this.layers[i].setProjection(projection, params);
    }
};

OpenLayers.Layer.WMS.prototype.setProjection = function (projection, params) {
    this.projection = projection;
    for (var key in params) {
        this[key] = params[key];
    }
    this.initResolutions();
};

OpenLayers.Layer.WMS.Untiled.prototype.setProjection = OpenLayers.Layer.WMS.prototype.setProjection;

GLOBAL.projections = {
  mercator: {projparams: {maxExtent: new OpenLayers.Bounds(-20014.0868, -20014.0868, 20016.0868, 20016.0868),
                          maxResolution: 50.037717,
                          units: "km"},
             projcode: "EPSG:41000",
             center: new OpenLayers.LonLat(0,0),
             zoom: 0},

  npole:  {projparams: {maxExtent: new OpenLayers.Bounds(-11888450, -11888450, 11888450, 11888450),
                        maxResolution: 29721.125/2,
                        units: "m"},
           projcode: "EPSG:42000",
           center: new OpenLayers.LonLat(0,0),
           zoom: 1},

  spole:  {projparams: {maxExtent: new OpenLayers.Bounds(-11888450, -11888450, 11888450, 11888450),
                        maxResolution: 29721.125/2,
                        units: "m"},
           projcode: "EPSG:43000",
           center: new OpenLayers.LonLat(0,0),
           zoom: 1}
};

function reproject (projname) {
    var map    = GLOBAL.map;
    var params = GLOBAL.projections[ projname ];
    var proj   = new OpenLayers.Projection(params.projcode);
    map.setCenterProj(params.center, params.zoom, proj, params.projparams); }

and then in the webpage, there are three buttons like this:

<button id="bt_npol"  name="npole"    value="npole"    onClick="reproject(&quot;npole&quot;)">North Pole</button>
<button id="bt_merc"  name="mercator" value="Mercator" onClick="reproject(&quot;mercator&quot;)">Global</button>
<button id="bt_spol"  name="spole"    value="spole"    onClick="reproject(&quot;spole&quot;)">South Pole</button>

--
Trond Michelsen

From tschaub at opengeo.org  Tue Jun  9 14:41:23 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
Message-ID: <4A2EACD3.70509@opengeo.org>

Can anyone with a copy of Opera ~9.27 take a look at 
http://trac.openlayers.org/ticket/2103 please?

I'd like to confirm a few things:

* OpenLayers 2.7 single file build works
* OpenLayers 2.8rc5 single file build does not work
* With the patch for 2103 applied, Opera doesn't complain (again, with 
the single file build)

This is not a problem in the version of Opera I've got (9.64).

Tim

-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From roald.dewit at lisasoft.com  Tue Jun  9 18:35:20 2009
From: roald.dewit at lisasoft.com (Roald de Wit)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A2EACD3.70509@opengeo.org>
References: <4A2EACD3.70509@opengeo.org>
Message-ID: <4A2EE3A8.9030501@lisasoft.com>

Hi Tim and list,

Why do we put so much effort into supporting an 'old' version of Opera? 
This problem does not exist in the latest stable version (9.64) any more 
as you say. So, this seems to be a bug in Opera that has been fixed.
I'm sure that Opera users will upgrade (pretty much) immediately when a 
new version gets released.

Regards, Roald

Tim Schaub wrote:
> Can anyone with a copy of Opera ~9.27 take a look at 
> http://trac.openlayers.org/ticket/2103 please?
>
> I'd like to confirm a few things:
>
> * OpenLayers 2.7 single file build works
> * OpenLayers 2.8rc5 single file build does not work
> * With the patch for 2103 applied, Opera doesn't complain (again, with 
> the single file build)
>
> This is not a problem in the version of Opera I've got (9.64).
>
> Tim
>
>   


From crschmidt at metacarta.com  Tue Jun  9 22:06:05 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A2EE3A8.9030501@lisasoft.com>
References: <4A2EACD3.70509@opengeo.org> <4A2EE3A8.9030501@lisasoft.com>
Message-ID: <20090610020605.GA12357@metacarta.com>

On Wed, Jun 10, 2009 at 08:35:20AM +1000, Roald de Wit wrote:
> Hi Tim and list,
> 
> Why do we put so much effort into supporting an 'old' version of Opera? 
> This problem does not exist in the latest stable version (9.64) any more 
> as you say. So, this seems to be a bug in Opera that has been fixed.
> I'm sure that Opera users will upgrade (pretty much) immediately when a 
> new version gets released.

Tim's probably not the person to talk to here, since I'm the one who
kept it in 2.8, as release manager. What follows is my opinion, and a
strongly held one that I have done my best to maintain throught the
history of OpenLayers. 

Any functionality that is in a released version of OpenLayers should
continue to work the same in all future versions of OpenLayers of the
same major revision. That is, there should never be any reason that
upgrading from 2.7 to 2.8 should cause anything to break.

The report from the user is not clear. If -- as I am assuming -- 
"This worked in 2.7,  and 2.8 breaks it" -- that is, simply switching to
2.8 causes a regression in behavior -- then this is a bug.

I am currently using OpenLayers for a project which uses Firefox 1.0.6
as the primary browsing platform. Users do not have the option to
upgrade their browsers. (The other option is IE6. I prefer working in
FF1, for obvious reasons.) I would be frustrated if OpenLayers took the
position that something that formerly worked -- specifically, Firefox
1.0.6 for a subset of OpenLayers features -- was removed simply because
"FF 1.0.6 is old."

Not supporting new features in older browsers is perfectly reasonable.
But we should do our best to limit the number of reasons for users to
*not* upgrade OpenLayers. Doing so hurts the project, because we have to
continue to support older versions to a greater extent, and hurts our
users, since they can't take advantage of bugfixes. 

If this worked in 2.7, we should fix it for 2.8. Since I don't have the
Opera version in question handy, I can't tell if it did. I'm hoping the
user can follow up with more information so we can confirm the problem,
and the fix.

Best Regards,
-- 
Christopher Schmidt
MetaCarta

From roald.dewit at lisasoft.com  Wed Jun 10 00:34:53 2009
From: roald.dewit at lisasoft.com (Roald de Wit)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <20090610020605.GA12357@metacarta.com>
References: <4A2EACD3.70509@opengeo.org> <4A2EE3A8.9030501@lisasoft.com>
	<20090610020605.GA12357@metacarta.com>
Message-ID: <4A2F37ED.7090901@lisasoft.com>

Hi Chris,

Thank you for your reply.

Christopher Schmidt wrote:
> Any functionality that is in a released version of OpenLayers should
> continue to work the same in all future versions of OpenLayers of the
> same major revision. That is, there should never be any reason that
> upgrading from 2.7 to 2.8 should cause anything to break.
>
I agree in general but not when somebody (1 person) uses an old version
of Opera that should have been
upgraded anyway (security).
> The report from the user is not clear. If -- as I am assuming --
> "This worked in 2.7,  and 2.8 breaks it" -- that is, simply switching to
> 2.8 causes a regression in behavior -- then this is a bug.
>
Unless we introduce new functionality that hits a bug in Opera that they
fixed in a later stable version.
It is a fact that the 2.8 branch does not work with this particular
version of this browser (I verified that today).

Plus, the 'new RegExp('...')' notation makes regular expressions harder
to read with the extra backslashes.

Anyway, the patch in #2103 does not solve the issue yet. It looks like
another regular expression needs to be converted.

Regards,

Roald

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

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



The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

From crschmidt at metacarta.com  Wed Jun 10 00:47:38 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A2F37ED.7090901@lisasoft.com>
References: <4A2EACD3.70509@opengeo.org> <4A2EE3A8.9030501@lisasoft.com>
	<20090610020605.GA12357@metacarta.com>
	<4A2F37ED.7090901@lisasoft.com>
Message-ID: <20090610044738.GB12357@metacarta.com>

On Wed, Jun 10, 2009 at 02:34:53PM +1000, Roald de Wit wrote:
> Hi Chris,
> 
> Thank you for your reply.
> 
> Christopher Schmidt wrote:
> >Any functionality that is in a released version of OpenLayers should
> >continue to work the same in all future versions of OpenLayers of the
> >same major revision. That is, there should never be any reason that
> >upgrading from 2.7 to 2.8 should cause anything to break.
> >
> I agree in general but not when somebody (1 person) uses an old
> version of Opera that should have been upgraded anyway (security).

IE6 stopped receiving security updates 6 months ago. If something breaks
in IE6, do we say "Sorry, we don't support that browser -- upgrade."? 

> >The report from the user is not clear. If -- as I am assuming --
> >"This worked in 2.7,  and 2.8 breaks it" -- that is, simply switching to
> >2.8 causes a regression in behavior -- then this is a bug.
> >
> Unless we introduce new functionality that hits a bug in Opera that they
> fixed in a later stable version.

This is fine if the issue is 'new functionality'. "The build doesn't
work at all" is not new functionality. (If this was something that could
be fixed in a build profile, I'd say remove it from the full build, and
call everything good, but that's simply not going to cut it here, since
it's in BaseTypes.js.)

> It is a fact that the 2.8 branch does not work with this particular
> version of this browser (I verified that today).
> 
> Plus, the 'new RegExp('...')' notation makes regular expressions harder
> to read with the extra backslashes.
> 
> Anyway, the patch in #2103 does not solve the issue yet. It looks like
> another regular expression needs to be converted.

Thanks for looking into it. I'll try to make time to do some digging
myself tomorrorw.

Regards,
-- 
Christopher Schmidt
MetaCarta

From arnaud.sig at gmail.com  Wed Jun 10 08:04:54 2009
From: arnaud.sig at gmail.com (geotribu)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Radius circle doesn't change for Canvas Vector
 Layer [Canvas.js Class]
Message-ID: <1244635494671-3055183.post@n2.nabble.com>


Hi,

I've noticed that if I use a style with a pointRadius for a vector layer
(with renderers canvas) the size of the circle doesn't change.
Indeed the method drawPoint of the Canvas class use the radius properties
only if the properties drawExternalGraphic is defined.

So I made some little change to the core class Canvas.js and now the radius
propertie works fine.

line 256 Actual code :
this.canvas.arc(pt[0], pt[1], 6, 0, Math.PI*2, true);

New code :
var radius = style.pointRadius?style.pointRadius:6;
this.canvas.arc(pt[0], pt[1], radius, 0, Math.PI*2, true);

Same things for the condition : style.stroke !== false.

And for example (user script) :

var style = new OpenLayers.Style(
	{
		fillColor: "#ffff00",
        fillOpacity: 0.5,
        pointRadius: "${radius}",
	    strokeColor: "#ff0000",
        strokeWidth: 2,
        strokeOpacity: 0.3
	},{		
		context: {			
		    radius: function(feature) {   
      		    return (feature.attributes.Population/2000);	
		    }
	    }
   }	
); 

var styleMap = new OpenLayers.StyleMap({'default':style, 'select':
{fillOpacity: 0.7, fillColor: "#ff0000"}});

vectors = new OpenLayers.Layer.GML( "Reunion city", "./city974.gml",
	{
			styleMap: styleMap,
			renderers: ['Canvas']
	}
); 

-----
http://geotribu.net Geotribu 
-- 
View this message in context: http://n2.nabble.com/Radius-circle-doesn%27t-change-for-Canvas-Vector-Layer--Canvas.js-Class--tp3055183p3055183.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From arnaud.sig at gmail.com  Wed Jun 10 08:06:26 2009
From: arnaud.sig at gmail.com (geotribu)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Radius circle doesn't change for Canvas Vector
 Layer [Canvas.js Class]
Message-ID: <1244635586435-3055191.post@n2.nabble.com>


Hi,

I've noticed that if I use a style with a pointRadius for a vector layer
(with renderers canvas) the size of the circle doesn't change.
Indeed the method drawPoint of the Canvas class use the radius properties
only if the properties drawExternalGraphic is defined.

So I made some little change to the core class Canvas.js and now the radius
propertie works fine.

line 256 Actual code :
this.canvas.arc(pt[0], pt[1], 6, 0, Math.PI*2, true);

New code :
var radius = style.pointRadius?style.pointRadius:6;
this.canvas.arc(pt[0], pt[1], radius, 0, Math.PI*2, true);

Same things for the condition : style.stroke !== false.

And for example (user script) :

var style = new OpenLayers.Style(
	{
		fillColor: "#ffff00",
        fillOpacity: 0.5,
        pointRadius: "${radius}",
	    strokeColor: "#ff0000",
        strokeWidth: 2,
        strokeOpacity: 0.3
	},{		
		context: {			
		    radius: function(feature) {   
      		    return (feature.attributes.Population/2000);	
		    }
	    }
   }	
); 

var styleMap = new OpenLayers.StyleMap({'default':style, 'select':
{fillOpacity: 0.7, fillColor: "#ff0000"}});

vectors = new OpenLayers.Layer.GML( "Reunion city", "./city974.gml",
	{
			styleMap: styleMap,
			renderers: ['Canvas']
	}
); 


Best regards

Arnaud

-----
http://geotribu.net Geotribu 
-- 
View this message in context: http://n2.nabble.com/Radius-circle-doesn%27t-change-for-Canvas-Vector-Layer--Canvas.js-Class--tp3055191p3055191.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From gregersrygg at gmail.com  Wed Jun 10 08:31:17 2009
From: gregersrygg at gmail.com (Gregers Gram Rygg)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Keyboard navigation and form elements
Message-ID: <2076e6510906100531l2da60e91y5b0f9fdd32780011@mail.gmail.com>

Hello all,

As previously discussed, the keyboard-handler is global for the
document, so it captures key events from form elements:
http://trac.openlayers.org/ticket/42
http://trac.openlayers.org/ticket/1027

This is particularly nasty when a user is typing text in an input
field, and use arrows to choose from a auto-suggestion.

I looked into the problem yesterday, and it turns out that Safari, as
the last major browser, added support to document.activeElement in
Safari 4.0 released two days ago. This was a proprietary property in
IE6, but has become the defacto standard in other browsers. I've
successfully tested this in IE6-8, FF3, Opera 9.6, Chrome 2.0.172 and
Safari 4.0. Luckily IE6 already has support, and users of other
browsers update on a more regular basis. So this should be available
on a large majority of users very soon. The best backwards
compatibility option I've found is to add focus and blur events on all
form elements (naaaasty!), and set document.activeElement in the
handler. This should of course only be done if
(!document.activeElement). But I suggest we ignore these users, as
this will not be released before OpenLayers 2.9 in a few months, and
hopefully most Safari users have upgraded by that time.

I have a working prototype, but I want some feedback before I submit
the patch. From my testing of document.activeElement, I've found that
some browsers use whatever node you clicked, and others use the body
object. As far as I know, form elements are the only DOM elements that
can have focus other than the body.

So far I've only added this to KeyboardDefaults.defaultKeyPress :
    if(document.activeElement) {
        var formElements = ["input", "select", "button", "textarea"];
        var tagName = document.activeElement.tagName.toLowerCase();
        for(var i=0,len=formElements.length; i<len; i++) {
            if(tagName == formElements[i]) return; // active element
is a form element
        }
    }

This should probably be extracted to a Util method (Util.isFormElementActive).

Does this seem like the Correct[TM]  solution?
Should this be done in KeybardDefaults or at a higher level?

More details about getting element in focus:
http://stackoverflow.com/questions/497094/how-do-i-find-out-which-javascript-element-has-focus


-Gregers

From crschmidt at metacarta.com  Wed Jun 10 08:44:38 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Radius circle doesn't change for Canvas Vector
	Layer [Canvas.js Class]
In-Reply-To: <1244635586435-3055191.post@n2.nabble.com>
References: <1244635586435-3055191.post@n2.nabble.com>
Message-ID: <20090610124437.GF12357@metacarta.com>

On Wed, Jun 10, 2009 at 05:06:26AM -0700, geotribu wrote:
> 
> Hi,
> 
> I've noticed that if I use a style with a pointRadius for a vector layer
> (with renderers canvas) the size of the circle doesn't change.
> Indeed the method drawPoint of the Canvas class use the radius properties
> only if the properties drawExternalGraphic is defined.

Please file a ticket with a patch for this issue:

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

> So I made some little change to the core class Canvas.js and now the radius
> propertie works fine.
> 
> line 256 Actual code :
> this.canvas.arc(pt[0], pt[1], 6, 0, Math.PI*2, true);
> 
> New code :
> var radius = style.pointRadius?style.pointRadius:6;
> this.canvas.arc(pt[0], pt[1], radius, 0, Math.PI*2, true);
> 
> Same things for the condition : style.stroke !== false.
> 
> And for example (user script) :
> 
> var style = new OpenLayers.Style(
> 	{
> 		fillColor: "#ffff00",
>         fillOpacity: 0.5,
>         pointRadius: "${radius}",
> 	    strokeColor: "#ff0000",
>         strokeWidth: 2,
>         strokeOpacity: 0.3
> 	},{		
> 		context: {			
> 		    radius: function(feature) {   
>       		    return (feature.attributes.Population/2000);	
> 		    }
> 	    }
>    }	
> ); 
> 
> var styleMap = new OpenLayers.StyleMap({'default':style, 'select':
> {fillOpacity: 0.7, fillColor: "#ff0000"}});
> 
> vectors = new OpenLayers.Layer.GML( "Reunion city", "./city974.gml",
> 	{
> 			styleMap: styleMap,
> 			renderers: ['Canvas']
> 	}
> ); 
> 
> 
> Best regards
> 
> Arnaud
> 
> -----
> http://geotribu.net Geotribu 
> -- 
> View this message in context: http://n2.nabble.com/Radius-circle-doesn%27t-change-for-Canvas-Vector-Layer--Canvas.js-Class--tp3055191p3055191.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta

From tschaub at opengeo.org  Wed Jun 10 12:08:25 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A2F37ED.7090901@lisasoft.com>
References: <4A2EACD3.70509@opengeo.org>
	<4A2EE3A8.9030501@lisasoft.com>	<20090610020605.GA12357@metacarta.com>
	<4A2F37ED.7090901@lisasoft.com>
Message-ID: <4A2FDA79.7080002@opengeo.org>

Hey-

Roald de Wit wrote:
> Hi Chris,
> 
> Thank you for your reply.
> 
> Christopher Schmidt wrote:
>> Any functionality that is in a released version of OpenLayers should
>> continue to work the same in all future versions of OpenLayers of the
>> same major revision. That is, there should never be any reason that
>> upgrading from 2.7 to 2.8 should cause anything to break.
>>
> I agree in general but not when somebody (1 person) uses an old version
> of Opera that should have been
> upgraded anyway (security).
>> The report from the user is not clear. If -- as I am assuming --
>> "This worked in 2.7,  and 2.8 breaks it" -- that is, simply switching to
>> 2.8 causes a regression in behavior -- then this is a bug.
>>
> Unless we introduce new functionality that hits a bug in Opera that they
> fixed in a later stable version.
> It is a fact that the 2.8 branch does not work with this particular
> version of this browser (I verified that today).
> 
> Plus, the 'new RegExp('...')' notation makes regular expressions harder
> to read with the extra backslashes.
> 
> Anyway, the patch in #2103 does not solve the issue yet. It looks like
> another regular expression needs to be converted.
> 

I'd like to get confirmation from someone with an older version of Opera 
about what works and what doesn't.  My recollection is that the patch 
made Opera 9.27 happy - even though it didn't remove all literal regular 
expressions.  You'll note that we had literal regexes in literal objects 
in 2.7 as well.  Hence my request for someone to check 2.7 in the same 
version of Opera.

If nobody has Opera 9.27, I'll look at reverting mine.  Though this does 
add weight to the opinion that the effort is a bit quixotic.

Tim

> Regards,
> 
> Roald
> 
> --
> Roald de Wit
> Software Engineer
> roald.dewit@lisasoft.com
> 
> Commercial Support for Open Source GIS Software
> http://lisasoft.com/LISAsoft/SupportedProducts/
> 
> 
> 
> The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From tschaub at opengeo.org  Wed Jun 10 12:15:59 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <20090610044738.GB12357@metacarta.com>
References: <4A2EACD3.70509@opengeo.org>
	<4A2EE3A8.9030501@lisasoft.com>	<20090610020605.GA12357@metacarta.com>	<4A2F37ED.7090901@lisasoft.com>
	<20090610044738.GB12357@metacarta.com>
Message-ID: <4A2FDC3F.1060701@opengeo.org>

Hey-

Christopher Schmidt wrote:
> On Wed, Jun 10, 2009 at 02:34:53PM +1000, Roald de Wit wrote:
>> Hi Chris,
>>
>> Thank you for your reply.
>>
>> Christopher Schmidt wrote:
>>> Any functionality that is in a released version of OpenLayers should
>>> continue to work the same in all future versions of OpenLayers of the
>>> same major revision. That is, there should never be any reason that
>>> upgrading from 2.7 to 2.8 should cause anything to break.
>>>
>> I agree in general but not when somebody (1 person) uses an old
>> version of Opera that should have been upgraded anyway (security).
> 
> IE6 stopped receiving security updates 6 months ago. If something breaks
> in IE6, do we say "Sorry, we don't support that browser -- upgrade."? 
> 

I understand and respect your decision to not release with something 
that breaks what worked previously.

However, I'd say a closer parallel would be if we introduced something 
that broke apps in Firefox 3.0.3 but not in 3.0.10.  Or if we introduced 
something that caused exceptions in Yahoo Maps v3.6 but not in v3.8.

I wouldn't be surprised if we have created issues like those above. 
However, if nobody complains, we can release with a clear conscience. 
When someone does point out a regression, we work to fix it.  I also 
think it makes sense to get an idea of the impact of the regression.

Tim

>>> The report from the user is not clear. If -- as I am assuming --
>>> "This worked in 2.7,  and 2.8 breaks it" -- that is, simply switching to
>>> 2.8 causes a regression in behavior -- then this is a bug.
>>>
>> Unless we introduce new functionality that hits a bug in Opera that they
>> fixed in a later stable version.
> 
> This is fine if the issue is 'new functionality'. "The build doesn't
> work at all" is not new functionality. (If this was something that could
> be fixed in a build profile, I'd say remove it from the full build, and
> call everything good, but that's simply not going to cut it here, since
> it's in BaseTypes.js.)
> 
>> It is a fact that the 2.8 branch does not work with this particular
>> version of this browser (I verified that today).
>>
>> Plus, the 'new RegExp('...')' notation makes regular expressions harder
>> to read with the extra backslashes.
>>
>> Anyway, the patch in #2103 does not solve the issue yet. It looks like
>> another regular expression needs to be converted.
> 
> Thanks for looking into it. I'll try to make time to do some digging
> myself tomorrorw.
> 
> Regards,


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From roald.dewit at lisasoft.com  Wed Jun 10 17:40:16 2009
From: roald.dewit at lisasoft.com (Roald de Wit)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A2FDA79.7080002@opengeo.org>
References: <4A2EACD3.70509@opengeo.org>	<4A2EE3A8.9030501@lisasoft.com>	<20090610020605.GA12357@metacarta.com>	<4A2F37ED.7090901@lisasoft.com>
	<4A2FDA79.7080002@opengeo.org>
Message-ID: <4A302840.4060707@lisasoft.com>

Hi Tim,

Tim Schaub wrote:
> I'd like to get confirmation from someone with an older version of Opera 
> about what works and what doesn't.  My recollection is that the patch 
> made Opera 9.27 happy - even though it didn't remove all literal regular 
> expressions.  You'll note that we had literal regexes in literal objects 
> in 2.7 as well.  Hence my request for someone to check 2.7 in the same 
> version of Opera.
>
> If nobody has Opera 9.27, I'll look at reverting mine.  Though this does 
> add weight to the opinion that the effort is a bit quixotic.
>   

Andreas pointed out that the problem with this Opera lies in the greedy 
parameter that's used in tokenRegEx ('g'). A quick search pointed me to 
over 40 cases in the OL library where we use the greedy parameter in 
regular expressions.

When I played with Opera 9.27 yesterday, I could make the JS errors go 
away (in the sundials example) with changing the 'trim' function to use 
'new RegExp' too.
So, we *can* make some functionality work for this version of Opera if 
we put the effort in.

The main question is: do we want to put all this effort in to support 
this version? I just asked the reporter of #2120 if he would consider 
upgrading to the latest Opera version [2], which might be the easiest 
way out.

Older versions of Opera can be found here: [1] for anyone to try out.

[1] http://www.filehippo.com/download_opera/3976/
[2] http://trac.openlayers.org/ticket/2120#comment:7

Regards, Roald

From tschaub at opengeo.org  Wed Jun 10 18:19:37 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A302840.4060707@lisasoft.com>
References: <4A2EACD3.70509@opengeo.org>	<4A2EE3A8.9030501@lisasoft.com>	<20090610020605.GA12357@metacarta.com>	<4A2F37ED.7090901@lisasoft.com>
	<4A2FDA79.7080002@opengeo.org> <4A302840.4060707@lisasoft.com>
Message-ID: <4A303179.8080307@opengeo.org>

Hey-

Roald de Wit wrote:
> Hi Tim,
> 
> Tim Schaub wrote:
>> I'd like to get confirmation from someone with an older version of 
>> Opera about what works and what doesn't.  My recollection is that the 
>> patch made Opera 9.27 happy - even though it didn't remove all literal 
>> regular expressions.  You'll note that we had literal regexes in 
>> literal objects in 2.7 as well.  Hence my request for someone to check 
>> 2.7 in the same version of Opera.
>>
>> If nobody has Opera 9.27, I'll look at reverting mine.  Though this 
>> does add weight to the opinion that the effort is a bit quixotic.
>>   
> 
> Andreas pointed out that the problem with this Opera lies in the greedy 
> parameter that's used in tokenRegEx ('g'). A quick search pointed me to 
> over 40 cases in the OL library where we use the greedy parameter in 
> regular expressions.
> 
> When I played with Opera 9.27 yesterday, I could make the JS errors go 
> away (in the sundials example) with changing the 'trim' function to use 
> 'new RegExp' too.
> So, we *can* make some functionality work for this version of Opera if 
> we put the effort in.
> 
> The main question is: do we want to put all this effort in to support 
> this version? I just asked the reporter of #2120 if he would consider 
> upgrading to the latest Opera version [2], which might be the easiest 
> way out.
> 

The first question is: did these issues exist in 2.7?  If OpenLayers 2.7 
did not work in Opera 9.27, then we are not talking about a regression.

Tim

> Older versions of Opera can be found here: [1] for anyone to try out.
> 
> [1] http://www.filehippo.com/download_opera/3976/
> [2] http://trac.openlayers.org/ticket/2120#comment:7
> 
> Regards, Roald


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From roald.dewit at lisasoft.com  Wed Jun 10 18:22:42 2009
From: roald.dewit at lisasoft.com (Roald de Wit)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Request for help from Opera users
In-Reply-To: <4A303179.8080307@opengeo.org>
References: <4A2EACD3.70509@opengeo.org>	<4A2EE3A8.9030501@lisasoft.com>	<20090610020605.GA12357@metacarta.com>	<4A2F37ED.7090901@lisasoft.com>	<4A2FDA79.7080002@opengeo.org>
	<4A302840.4060707@lisasoft.com> <4A303179.8080307@opengeo.org>
Message-ID: <4A303232.7070303@lisasoft.com>

Tim Schaub wrote:
>
> The first question is: did these issues exist in 2.7?  If OpenLayers 2.7 
> did not work in Opera 9.27, then we are not talking about a regression.
>   
They did not exist in 2.7. It is a regression.

Roald

From andy.deakin at pcmend.net  Wed Jun 10 18:38:52 2009
From: andy.deakin at pcmend.net (Andy Deakin)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Start drawing polygon on map with single click,
	ignore drag & dblclick
Message-ID: <4A3035FC.5050808@pcmend.net>

Hi list

I'm drawing a polygon on a map, but want drag events to move the map, 
double click to zoom in, and a single click to start drawing the polygon.

I have tried a number of methods, but the click propagation and 
single/double click events make it difficult.

Is there a handler that does anything like this, or are there any 
suggestions on how it can be done?

Cheers, Andy

From eric.lemoine at camptocamp.com  Thu Jun 11 03:08:28 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
	<ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>
Message-ID: <ca7da9120906110008j290a6297q7fa6269145724f94@mail.gmail.com>

2009/6/9 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
> Thanks Eric :)
>
> Details are important, though I would argue that
> OpenLayers.TopologyRule is only one char shorter than
> OpenLayers.Topology.Rule ;)

I'm not trying to save chars here, but to avoid unnecessary deep
namespaces. Just a matter of elegance... I'll try to go deeper in your
code and come up with more constructive comments ;)



-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From bjorn.harrtell at gmail.com  Thu Jun 11 03:19:21 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ca7da9120906110008j290a6297q7fa6269145724f94@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<ba82f3c60905300648p74d0e832j24ee07c4de7b0a2f@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
	<ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>
	<ca7da9120906110008j290a6297q7fa6269145724f94@mail.gmail.com>
Message-ID: <ba82f3c60906110019l77cac97fna0fcaa39ddfeb99d@mail.gmail.com>

I won't argue for the current name, and can see your point so.. we'll
see what happens :)

Anyway, I put togheter the current code into a patch against current
trunk for further discussion which might help you review the source
(which would be highly appriciated):

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

/Bj?rn

On Thu, Jun 11, 2009 at 09:08, Eric Lemoine<eric.lemoine@camptocamp.com> wrote:
> 2009/6/9 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>> Thanks Eric :)
>>
>> Details are important, though I would argue that
>> OpenLayers.TopologyRule is only one char shorter than
>> OpenLayers.Topology.Rule ;)
>
> I'm not trying to save chars here, but to avoid unnecessary deep
> namespaces. Just a matter of elegance... I'll try to go deeper in your
> code and come up with more constructive comments ;)
>
>
>
> --
> Eric Lemoine
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac, Cedex
>
> Tel : 00 33 4 79 44 44 96
> Mail : eric.lemoine@camptocamp.com
> http://www.camptocamp.com
>

From Matthew.Diez at iem.com  Thu Jun 11 09:09:27 2009
From: Matthew.Diez at iem.com (Diez, Matthew)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] minZoomLevel and WFS
Message-ID: <217B5942A5026F4780967A6E752C89AB0805F3D4@brmail1.ieminc.com>

Looking through the Layer.WFS source, i saw:

 //DEPRECATED - REMOVE IN 3.0
         // don't load data if current zoom level doesn't match
-        if (this.options.minZoomLevel && 
-            (this.map.getZoom() < this.options.minZoomLevel) ) {
-            return null;
-        };

So, if minZoomLevel is going away, why? And what is the preferred strategy for dealing with not loading WFS layers at certain zoomLevels/scaleDenominators?

-Matthew D. Diez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090611/0edf01e4/attachment.html
From evan.bowling at gmail.com  Thu Jun 11 12:59:25 2009
From: evan.bowling at gmail.com (Evan James Bowling)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Start drawing polygon on map with single click,
	ignore drag & dblclick
In-Reply-To: <4A3035FC.5050808@pcmend.net>
References: <4A3035FC.5050808@pcmend.net>
Message-ID: <d8259d610906110959s4e119cffk52b390a58581d110@mail.gmail.com>

Andy,

  The controls do exist, but they have to be activated separately right
now.Here
is a link that shows off the features you're looking for:

      http://openlayers.org/dev/examples/drag-feature.html

  Are you trying to make it so that a single click would either start
drawing a polygon or
move the map depending on whether or not the cursor moved before release?

-Evan


On Wed, Jun 10, 2009 at 6:38 PM, Andy Deakin <andy.deakin@pcmend.net> wrote:

> Hi list
>
> I'm drawing a polygon on a map, but want drag events to move the map,
> double click to zoom in, and a single click to start drawing the polygon.
>
> I have tried a number of methods, but the click propagation and
> single/double click events make it difficult.
>
> Is there a handler that does anything like this, or are there any
> suggestions on how it can be done?
>
> Cheers, Andy
> _______________________________________________
> 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/20090611/938f6ba1/attachment.html
From andy.deakin at pcmend.net  Thu Jun 11 13:34:23 2009
From: andy.deakin at pcmend.net (Andy Deakin)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Start drawing polygon on map with single click,
 ignore drag & dblclick
In-Reply-To: <d8259d610906110959s4e119cffk52b390a58581d110@mail.gmail.com>
References: <4A3035FC.5050808@pcmend.net>
	<d8259d610906110959s4e119cffk52b390a58581d110@mail.gmail.com>
Message-ID: <4A31401F.7080303@pcmend.net>

Hi,

I would like a click to start drawing a polygon if it is not a drag and 
not a double click.

At the moment I am doing similar to the link that you provided, and the 
user has to click on 'Start Drawing' once they have navigated to where 
they want to start drawing. However, a single click (on its own) does 
not mean anything in navigate mode, so I think that it makes sense to 
use this single click to start drawing.

I have added a 'click' to the map with e.g.
map.events.register( 'click', this, startDraw );
but this is causing strange behavior.

Andy

Evan James Bowling wrote:
> Andy,
>
>   The controls do exist, but they have to be activated separately 
> right now.Here
> is a link that shows off the features you're looking for:
>
>       http://openlayers.org/dev/examples/drag-feature.html
>
>   Are you trying to make it so that a single click would either start 
> drawing a polygon or
> move the map depending on whether or not the cursor moved before release?
>
> -Evan
>
>
> On Wed, Jun 10, 2009 at 6:38 PM, Andy Deakin <andy.deakin@pcmend.net 
> <mailto:andy.deakin@pcmend.net>> wrote:
>
>     Hi list
>
>     I'm drawing a polygon on a map, but want drag events to move the map,
>     double click to zoom in, and a single click to start drawing the
>     polygon.
>
>     I have tried a number of methods, but the click propagation and
>     single/double click events make it difficult.
>
>     Is there a handler that does anything like this, or are there any
>     suggestions on how it can be done?
>
>     Cheers, Andy
>     _______________________________________________
>     Dev mailing list
>     Dev@openlayers.org <mailto:Dev@openlayers.org>
>     http://openlayers.org/mailman/listinfo/dev
>
>


From ahocevar at opengeo.org  Fri Jun 12 05:03:11 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] minZoomLevel and WFS
In-Reply-To: <217B5942A5026F4780967A6E752C89AB0805F3D4@brmail1.ieminc.com>
References: <217B5942A5026F4780967A6E752C89AB0805F3D4@brmail1.ieminc.com>
Message-ID: <5b021dd0906120203m228f9590g2d1d1fff36162565@mail.gmail.com>

Hi Matt,

you do not need minZoomLevel, because you can control if layers should
be displayed using layer.minResolution and layer.maxResolution -- for
all layer types:

        "The minZoomLevel property is only intended for use " +
        "with the FixedZoomLevels-descendent layers. That this " +
        "wfs layer checks for minZoomLevel is a relic of the" +
        "past. We cannot, however, remove it without possibly " +
        "breaking OL based applications that may depend on it." +
        " Therefore we are deprecating it -- the minZoomLevel " +
        "check below will be removed at 3.0. Please instead " +
        "use min/max resolution setting as described here: " +
        "http://trac.openlayers.org/wiki/SettingZoomLevels",

The WFS layer will not load data if not in the min/maxResolution
range. Apart from that, in the future you will probably want to use
Layer.Vector with Protocol.WFS and Strategy.BBOX instead of Layer.WFS.
See http://localhost/openlayers/examples/wfs-protocol.html for an
example.

Regards,
Andreas.

On Thu, Jun 11, 2009 at 3:09 PM, Diez, Matthew<Matthew.Diez@iem.com> wrote:
> Looking through the Layer.WFS source, i saw:
>
> ?//DEPRECATED - REMOVE IN 3.0
> ???????? // don't load data if current zoom level doesn't match
> -??????? if (this.options.minZoomLevel &&
> -??????????? (this.map.getZoom() < this.options.minZoomLevel) ) {
> -??????????? return null;
> -??????? };
>
> So, if minZoomLevel is going away, why? And what is the preferred strategy
> for dealing with not loading WFS layers at certain
> zoomLevels/scaleDenominators?
>
> -Matthew D. Diez
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
>

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From crschmidt at metacarta.com  Fri Jun 12 16:07:46 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
Message-ID: <20090612200746.GZ12357@metacarta.com>

Hi,

For 2.8 RC6, we have a copule fixes for important issues affecting the
community. In general, I'd have avoided these issues in this late of an
RC, but they both seem low risk and high benefit.

 * IE8 VML support outside of compatibility mode
 * IE7 strict mode VML text
 
Additionally, we have:

 * Fix Opera 9.27 support
 * Fix for a minor ArcIMS / ARcXML issue.

The IE8 VML changes are more significant than I would generally allow
for a non-regression, but significant testing thanks to the community
makes me comfortable including the changes in 2.8.

I'd like to propose that once Andreas commits #1910, we roll on 2.8 RC6,
in hopes that it's our last our RC. (I think it better be at this point
:))

 All in favor?
 All opposed?

Regards,
-- 
Christopher Schmidt
MetaCarta

From pspencer at dmsolutions.ca  Fri Jun 12 16:18:05 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <20090612200746.GZ12357@metacarta.com>
References: <20090612200746.GZ12357@metacarta.com>
Message-ID: <B6077CFD-CE20-4627-A8D6-442AC58F0FDA@dmsolutions.ca>

I'm in favour of including all the fixes.

Paul

On 12-Jun-09, at 4:07 PM, Christopher Schmidt wrote:

> Hi,
>
> For 2.8 RC6, we have a copule fixes for important issues affecting the
> community. In general, I'd have avoided these issues in this late of  
> an
> RC, but they both seem low risk and high benefit.
>
> * IE8 VML support outside of compatibility mode
> * IE7 strict mode VML text
>
> Additionally, we have:
>
> * Fix Opera 9.27 support
> * Fix for a minor ArcIMS / ARcXML issue.
>
> The IE8 VML changes are more significant than I would generally allow
> for a non-regression, but significant testing thanks to the community
> makes me comfortable including the changes in 2.8.
>
> I'd like to propose that once Andreas commits #1910, we roll on 2.8  
> RC6,
> in hopes that it's our last our RC. (I think it better be at this  
> point
> :))
>
> All in favor?
> All opposed?
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

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


From schuyler at nocat.net  Fri Jun 12 16:44:18 2009
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <20090612200746.GZ12357@metacarta.com>
References: <20090612200746.GZ12357@metacarta.com>
Message-ID: <1244839459.6412.102.camel@goldman>

On Fri, 2009-06-12 at 16:07 -0400, Christopher Schmidt wrote:
> I'd like to propose that once Andreas commits #1910, we roll on 2.8 RC6,
> in hopes that it's our last our RC.

Roll away! And thanks again to everyone who's contributed to this
release candidate. +1

SDE


From tschaub at opengeo.org  Fri Jun 12 19:40:49 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <20090612200746.GZ12357@metacarta.com>
References: <20090612200746.GZ12357@metacarta.com>
Message-ID: <4A32E781.7000500@opengeo.org>

Christopher Schmidt wrote:
>  All in favor?

+1

>  All opposed?
> 
> Regards,


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From eric.lemoine at camptocamp.com  Sat Jun 13 04:27:48 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <20090612200746.GZ12357@metacarta.com>
References: <20090612200746.GZ12357@metacarta.com>
Message-ID: <ca7da9120906130127k118fad1cg9ab708ded056bcf9@mail.gmail.com>

On Fri, Jun 12, 2009 at 10:07 PM, Christopher
Schmidt<crschmidt@metacarta.com> wrote:
> Hi,
>
> For 2.8 RC6, we have a copule fixes for important issues affecting the
> community. In general, I'd have avoided these issues in this late of an
> RC, but they both seem low risk and high benefit.
>
> ?* IE8 VML support outside of compatibility mode
> ?* IE7 strict mode VML text
>
> Additionally, we have:
>
> ?* Fix Opera 9.27 support
> ?* Fix for a minor ArcIMS / ARcXML issue.
>
> The IE8 VML changes are more significant than I would generally allow
> for a non-regression, but significant testing thanks to the community
> makes me comfortable including the changes in 2.8.
>
> I'd like to propose that once Andreas commits #1910, we roll on 2.8 RC6,
> in hopes that it's our last our RC. (I think it better be at this point
> :))
>
> ?All in favor?
> ?All opposed?

+1 from me

>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From ks at geograf.dk  Sat Jun 13 08:12:58 2009
From: ks at geograf.dk (Kenneth Skovhede, GEOGRAF A/S)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <20090612200746.GZ12357@metacarta.com>
References: <20090612200746.GZ12357@metacarta.com>
Message-ID: <4A3397CA.4000609@geograf.dk>

I would like to request that you also include the patch for issue #2134.
http://trac.openlayers.org/ticket/2134

It's a tiny semicolon fix, but it makes it possible to compress OL
with tools like packer, and recieve a ~300Kib version of OL.

Regards, Kenneth Skovhede, GEOGRAF A/S



Christopher Schmidt skrev:
> Hi,
>
> For 2.8 RC6, we have a copule fixes for important issues affecting the
> community. In general, I'd have avoided these issues in this late of an
> RC, but they both seem low risk and high benefit.
>
>  * IE8 VML support outside of compatibility mode
>  * IE7 strict mode VML text
>  
> Additionally, we have:
>
>  * Fix Opera 9.27 support
>  * Fix for a minor ArcIMS / ARcXML issue.
>
> The IE8 VML changes are more significant than I would generally allow
> for a non-regression, but significant testing thanks to the community
> makes me comfortable including the changes in 2.8.
>
> I'd like to propose that once Andreas commits #1910, we roll on 2.8 RC6,
> in hopes that it's our last our RC. (I think it better be at this point
> :))
>
>  All in favor?
>  All opposed?
>
> Regards,
>   

From eric.lemoine at camptocamp.com  Sat Jun 13 09:11:53 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
In-Reply-To: <4A3397CA.4000609@geograf.dk>
References: <20090612200746.GZ12357@metacarta.com>
	<4A3397CA.4000609@geograf.dk>
Message-ID: <ca7da9120906130611p704ea6f8r606835598dbdf0d0@mail.gmail.com>

On Sat, Jun 13, 2009 at 2:12 PM, Kenneth Skovhede, GEOGRAF
A/S<ks@geograf.dk> wrote:
> I would like to request that you also include the patch for issue #2134.
> http://trac.openlayers.org/ticket/2134
>
> It's a tiny semicolon fix, but it makes it possible to compress OL
> with tools like packer, and recieve a ~300Kib version of OL.

those are in
<http://trac.openlayers.org/changeset/9475>

Thanks,


-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From eric.lemoine at camptocamp.com  Sat Jun 13 16:16:25 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] PostGIS and OL disagree
Message-ID: <ca7da9120906131316q23e8f5cdkaefa059b6dc49532@mail.gmail.com>

Hello

I noticed that PostGIS and OpenLayers don't give the same result when
reprojecting a point from 4326 to 900913.

PostGIS :

mydatabase=# select astext(transform(geomfromtext('POINT(-22.19921875
1.47265625)',4326), 900913));
                  astext
-------------------------------------------
 POINT(-2471205.72725849 162856.069837409)
(1 row)

OpenLayers :

>>> var p = new OpenLayers.Geometry.fromWKT("POINT(-22.19921875 1.47265625)");
>>> p.transform(new OpenLayers.Projection("EPSG:4326"),new OpenLayers.Projection("EPSG:900913"));
>>> p.toString();
"POINT(-2471205.7269145 163953.39689072)"

Note the difference for the y coord (more than 1000 meters).

Does anyone have an explanation for this?

FYI, here's my spatial_ref_sys entry in PostGIS for 900913:

mydatabase=# SELECT * from spatial_ref_sys where srid=900913;
  srid  | auth_name | auth_srid |                     srtext
          |                                        proj4text
--------+-----------+-----------+------------------------------------------------+------------------------------------------------------------------------------------------
 900913 | EPSG      |    900913 | GEOGCS["WGS 84", DATUM["World Geodetic System
1984", SPHEROID["WGS 84", 6378137.0,
298.257223563,AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich", 0.0,
AUTHORITY["EPSG","8901"]], NIT["degree",0.017453292519943295],
AXIS["Longitude", EAST], AXIS["Latitude",
NORTH],AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],PARAMETER["semi_minor", 6378137.0],
PARAMETER["latitude_of_origin",0.0], PARAMETER["central_meridian",
0.0], PARAMETER["scale_factor",1.0], PARAMETER["false_easting", 0.0],
PARAMETER["false_northing", 0.0],UNIT["m", 1.0], AXIS["x", EAST],
AXIS["y", NORTH],AUTHORITY["EPSG","900913"]] | | +proj=merc +a=6378137
+b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
+nadgrids=@null +no_defs
(1 row)


Thanks,

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From crschmidt at metacarta.com  Mon Jun 15 02:52:17 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] PostGIS and OL disagree
In-Reply-To: <ca7da9120906131316q23e8f5cdkaefa059b6dc49532@mail.gmail.com>
References: <ca7da9120906131316q23e8f5cdkaefa059b6dc49532@mail.gmail.com>
Message-ID: <20090615065217.GA16388@metacarta.com>

On Sat, Jun 13, 2009 at 10:16:25PM +0200, Eric Lemoine wrote:
> Hello
> 
> I noticed that PostGIS and OpenLayers don't give the same result when
> reprojecting a point from 4326 to 900913.

Sounds like:
 * proj is out of date or
 * You don't have the 'null' gridshift file.

u=# insert into spatial_ref_sys VALUES (900913, 'EPSG', 900913, '', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs');
INSERT 0 1
u=# select astext(transform(geomfromtext('POINT(-22.19921875 1.47265625)',4326), 900913));
                  astext                   
-------------------------------------------
 POINT(-2471205.72725849 163953.396913541)
(1 row)

/Library/Frameworks/PROJ.framework/Versions/4.6/Resources/proj/null for
me on OS X, presumably /usr/share/proj/null on Linux. I believe that
Debian and Ubuntu no longer include these files (for silly reasons), so
that may be the source of your problem.

-- Chris 

> PostGIS :
> 
> mydatabase=# select astext(transform(geomfromtext('POINT(-22.19921875
> 1.47265625)',4326), 900913));
>                   astext
> -------------------------------------------
>  POINT(-2471205.72725849 162856.069837409)
> (1 row)
> 
> OpenLayers :
> 
> >>> var p = new OpenLayers.Geometry.fromWKT("POINT(-22.19921875 1.47265625)");
> >>> p.transform(new OpenLayers.Projection("EPSG:4326"),new OpenLayers.Projection("EPSG:900913"));
> >>> p.toString();
> "POINT(-2471205.7269145 163953.39689072)"
> 
> Note the difference for the y coord (more than 1000 meters).
> 
> Does anyone have an explanation for this?
> 
> FYI, here's my spatial_ref_sys entry in PostGIS for 900913:
> 
> mydatabase=# SELECT * from spatial_ref_sys where srid=900913;
>   srid  | auth_name | auth_srid |                     srtext
>           |                                        proj4text
> --------+-----------+-----------+------------------------------------------------+------------------------------------------------------------------------------------------
>  900913 | EPSG      |    900913 | GEOGCS["WGS 84", DATUM["World Geodetic System
> 1984", SPHEROID["WGS 84", 6378137.0,
> 298.257223563,AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich", 0.0,
> AUTHORITY["EPSG","8901"]], NIT["degree",0.017453292519943295],
> AXIS["Longitude", EAST], AXIS["Latitude",
> NORTH],AUTHORITY["EPSG","4326"]],
> PROJECTION["Mercator_1SP"],PARAMETER["semi_minor", 6378137.0],
> PARAMETER["latitude_of_origin",0.0], PARAMETER["central_meridian",
> 0.0], PARAMETER["scale_factor",1.0], PARAMETER["false_easting", 0.0],
> PARAMETER["false_northing", 0.0],UNIT["m", 1.0], AXIS["x", EAST],
> AXIS["y", NORTH],AUTHORITY["EPSG","900913"]] | | +proj=merc +a=6378137
> +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m
> +nadgrids=@null +no_defs
> (1 row)
> 
> 
> Thanks,
> 
> -- 
> Eric Lemoine
> 
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac, Cedex
> 
> Tel : 00 33 4 79 44 44 96
> Mail : eric.lemoine@camptocamp.com
> http://www.camptocamp.com
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta

From warlock24 at gmail.com  Mon Jun 15 04:54:15 2009
From: warlock24 at gmail.com (warlock24)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev]  Map with one SVG layer
Message-ID: <1245056055485-3079214.post@n2.nabble.com>


Hello,

im making a map of non existing world (exact coordinates of point doesnt
matter), i drew this map in Inkscape (editor for svg). How can i display my
svg file with OpenLayers? Its amateur project, it must be simple - just
files, i can not afford to buy account on map servers.

this is not working, and i don't know why :(

**************************
var map = new OpenLayers.Map('map');
var svg = new OpenLayers.Layer.GML("SVG",
"http://sites.google.com/site/warlock24/storage/WorldMap.svg", {
format: OpenLayers.Format.SVG
});
map.addLayer(svg);
map.zoomToMaxExtent();
***************************

help :'(


-- 
View this message in context: http://n2.nabble.com/Map-with-one-SVG-layer-tp3079214p3079214.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From bartvde at osgis.nl  Mon Jun 15 05:02:27 2009
From: bartvde at osgis.nl (bartvde@osgis.nl)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Map with one SVG layer
In-Reply-To: <1245056055485-3079214.post@n2.nabble.com>
References: <1245056055485-3079214.post@n2.nabble.com>
Message-ID: <20438.145.50.39.11.1245056547.squirrel@webmail.hostingdiscounter.nl>

Hi,

OpenLayers currently does not read SVG files (it generates SVG).

You can try to use the following but I am not sure it will work for you:

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

Best regards,
Bart

>
> Hello,
>
> im making a map of non existing world (exact coordinates of point doesnt
> matter), i drew this map in Inkscape (editor for svg). How can i display
> my
> svg file with OpenLayers? Its amateur project, it must be simple - just
> files, i can not afford to buy account on map servers.
>
> this is not working, and i don't know why :(
>
> **************************
> var map = new OpenLayers.Map('map');
> var svg = new OpenLayers.Layer.GML("SVG",
> "http://sites.google.com/site/warlock24/storage/WorldMap.svg", {
> format: OpenLayers.Format.SVG
> });
> map.addLayer(svg);
> map.zoomToMaxExtent();
> ***************************
>
> help :'(
>
>
> --
> View this message in context:
> http://n2.nabble.com/Map-with-one-SVG-layer-tp3079214p3079214.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



From falcacibar at gmail.com  Mon Jun 15 07:41:48 2009
From: falcacibar at gmail.com (Felipe Alcacibar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Reprojection from WGS84 to Spherical Mercator
Message-ID: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>

Hi, some days ago the list shows me about google layers and spherical mercator.

everything is works fine, but i cannot do a good reprojection from
WGS84 to Spherical Mercator
i trying with postgis with the statement:

ST_transform(ST_setSRID(geom, 4326), 900913)

but when i see in the map the layer goes a lot km to the north, have
some table to pass parameters
for convertion bethween this projections, i search but i cannot found
any response that tells me
how i can do this.

very thanks in advance.

cheers

Felipe

From eric.lemoine at camptocamp.com  Mon Jun 15 07:51:00 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] PostGIS and OL disagree
In-Reply-To: <20090615065217.GA16388@metacarta.com>
References: <ca7da9120906131316q23e8f5cdkaefa059b6dc49532@mail.gmail.com>
	<20090615065217.GA16388@metacarta.com>
Message-ID: <ca7da9120906150451p3736a6eaufb430be4c2a6161d@mail.gmail.com>

On Mon, Jun 15, 2009 at 8:52 AM, Christopher
Schmidt<crschmidt@metacarta.com> wrote:
> On Sat, Jun 13, 2009 at 10:16:25PM +0200, Eric Lemoine wrote:
>> Hello
>>
>> I noticed that PostGIS and OpenLayers don't give the same result when
>> reprojecting a point from 4326 to 900913.
>
> Sounds like:
> ?* proj is out of date or
> ?* You don't have the 'null' gridshift file.
>
> u=# insert into spatial_ref_sys VALUES (900913, 'EPSG', 900913, '', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs');
> INSERT 0 1

I deleted the srid=900913 row from the spatial_ref_sys table,
reinserted it with the above statement, it works now. I had something
wrong in my proj string or something.

Thanks Chris,

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From falcacibar at gmail.com  Mon Jun 15 07:48:36 2009
From: falcacibar at gmail.com (Felipe Alcacibar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Reprojection from WGS84 to Spherical Mercator
In-Reply-To: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>
References: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>
Message-ID: <72e3fc8f0906150448l35367bdfs49a927b6628496f6@mail.gmail.com>

Sorry, i forgot that...
i'm using proj4.9 "hand" compiled by Gentoo Linux.
postGIS 1.3
postgresSQL 8.3

my proj directory:
arda carto # ls -1 /usr/share/proj/
EPSG
FL
GL27
MD
TN
WI
WO
alaska
conus
epsg
esri
hawaii
nad.lst
nad27
nad83
ntv1_can.dat
null
pj_out27.dist
pj_out83.dist
proj_def.dat
prvi
stgeorge
stlrnc
stpaul
test27
test83
world

i insert the 900913 Spherical Mercator with the info from the URL
http://trac.openlayers.org/wiki/SphericalMercator

From crschmidt at metacarta.com  Mon Jun 15 09:18:33 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Reprojection from WGS84 to Spherical Mercator
In-Reply-To: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>
References: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>
Message-ID: <20090615131832.GB16388@metacarta.com>

On Mon, Jun 15, 2009 at 07:41:48AM -0400, Felipe Alcacibar wrote:
> Hi, some days ago the list shows me about google layers and spherical mercator.
> 
> everything is works fine, but i cannot do a good reprojection from
> WGS84 to Spherical Mercator
> i trying with postgis with the statement:
> 
> ST_transform(ST_setSRID(geom, 4326), 900913)
u=# insert into spatial_ref_sys VALUES (900913, 'EPSG', 900913, '', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs');
INSERT 0 1
u=# select astext(transform(geomfromtext('POINT(-22.19921875 1.47265625)',4326), 900913));
                  astext                   
-------------------------------------------
 POINT(-2471205.72725849 163953.396913541)
(1 row)


works for me. try dumping your current 900913 srs entry and adding it 
like this. 

> but when i see in the map the layer goes a lot km to the north, have
> some table to pass parameters
> for convertion bethween this projections, i search but i cannot found
> any response that tells me
> how i can do this.
> 
> very thanks in advance.
> 
> cheers
> 
> Felipe
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta

From crschmidt at metacarta.com  Mon Jun 15 09:44:57 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 RC6
Message-ID: <20090615134457.GD16388@metacarta.com>

The OpenLayers Development Team is proud to announce the sixth release
candidate of OpenLayers 2.8!

RC6 closes an additional small number of bugs in the 2.8 Release,
most importantly adding support for IE8 VML rendering.

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

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

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

 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 look forward to your feedback on this release.

 [1]
 http://trac.openlayers.org/wiki/Release/2.8/Notes#CompatibilityNotes
-- 
Christopher Schmidt
MetaCarta

From falcacibar at gmail.com  Mon Jun 15 18:13:42 2009
From: falcacibar at gmail.com (Felipe Alcacibar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Reprojection from WGS84 to Spherical Mercator
In-Reply-To: <72e3fc8f0906151512j42f336f0kb6d7d3ddbbf6291f@mail.gmail.com>
References: <72e3fc8f0906150441m131271a2o51c37759e96fa69b@mail.gmail.com>
	<20090615131832.GB16388@metacarta.com>
	<72e3fc8f0906151512j42f336f0kb6d7d3ddbbf6291f@mail.gmail.com>
Message-ID: <72e3fc8f0906151513q30ba7cd4pd57057f6c46ba736@mail.gmail.com>

Christopher:

this is the definition, aparantly the only diference is the srtext field:

orionforestal=# select * from spatial_ref_sys where srid = 900913;
-[ RECORD 1 ]------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
srid ? ? ?| 900913
auth_name | EPSG
auth_srid | 900913
srtext ? ?| GEOGCS["WGS 84", DATUM["World Geodetic System
? ? ? ? ?: 1984", SPHEROID["WGS 84", 6378137.0,
298.257223563,AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich", 0.0,
AUTHORITY["EPSG","8901"]], NIT["degree",0.017453292519943295],
AXIS["Longitude", EAST], AXIS["Latitude",
NORTH],AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],PARAMETER["semi_minor", 6378137.0],
? ? ? ? ?: PARAMETER["latitude_of_origin",0.0],
PARAMETER["central_meridian", 0.0], PARAMETER["scale_factor",1.0],
PARAMETER["false_easting", 0.0], PARAMETER["false_northing",
0.0],UNIT["m", 1.0], AXIS["x", EAST], AXIS["y",
NORTH],AUTHORITY["EPSG","900913"]] |
proj4text | +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m
? ? ? ? ?: +nadgrids=@null +no_defs

maybe you need another test, just tell me... i start to think bad about that...
thanks.

Felipe

On Mon, Jun 15, 2009 at 9:18 AM, Christopher
Schmidt<crschmidt@metacarta.com> wrote:
> On Mon, Jun 15, 2009 at 07:41:48AM -0400, Felipe Alcacibar wrote:
>> Hi, some days ago the list shows me about google layers and spherical mercator.
>>
>> everything is works fine, but i cannot do a good reprojection from
>> WGS84 to Spherical Mercator
>> i trying with postgis with the statement:
>>
>> ST_transform(ST_setSRID(geom, 4326), 900913)
> u=# insert into spatial_ref_sys VALUES (900913, 'EPSG', 900913, '', '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs');
> INSERT 0 1
> u=# select astext(transform(geomfromtext('POINT(-22.19921875 1.47265625)',4326), 900913));
> ? ? ? ? ? ? ? ? ?astext
> -------------------------------------------
> ?POINT(-2471205.72725849 163953.396913541)
> (1 row)
>
>
> works for me. try dumping your current 900913 srs entry and adding it
> like this.
>
>> but when i see in the map the layer goes a lot km to the north, have
>> some table to pass parameters
>> for convertion bethween this projections, i search but i cannot found
>> any response that tells me
>> how i can do this.
>>
>> very thanks in advance.
>>
>> cheers
>>
>> Felipe
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>
> --
> Christopher Schmidt
> MetaCarta
>

From Matthew.Diez at iem.com  Tue Jun 16 20:41:26 2009
From: Matthew.Diez at iem.com (Diez, Matthew)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] VirtualEarth onResize() event.
Message-ID: <217B5942A5026F4780967A6E752C89AB1197BAD9@brmail1.ieminc.com>

I believe that the VirtualEarth layer needs to have the following method
attached:

   	onMapResize: function() {
   		this.mapObject.Resize(this.map.size.w, this.map.size.h);
    },

Unlike other types of 900913 layers, VirtualEarth doesn't automatically
recalculate its bounds on the SetCenter (or SetCenterAndZoom) methods.

This, at least, fixes a handful of my problems. Can anyone else confirm
it? Shall I build out and post a test case to explain my rationale?

Matthew D. Diez
Software Engineer - GIS and Meteorology
Innovative Emergency Management, Inc.
8550 United Plaza Boulevard, Suite 501
Baton Rouge, LA 70809
(225) 952-8279
 


From pspencer at dmsolutions.ca  Wed Jun 17 10:33:11 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] vector drawFeature bug or by design?
Message-ID: <03C62022-B89C-40BB-9952-BDFD42C21537@dmsolutions.ca>

I have a question about Layer.Vector.drawFeature when passing a  
style ...

I used this method to update the label of a point with an existing  
style (set directly on the feature) as the measure tool moved by  
calling this.handler.layer.drawFeature(text, {label: newDistance})  
which worked perfectly until the user zoomed using the mouse wheel  
while measuring.  I've since changed this to set text.style.label =  
newDistance; this.handler.layer.drawFeature(text); which works fine.

But this led me to question whether this is by design or a bug.

The relevant docs are:

     /**
      * APIMethod: drawFeature
      * Draw (or redraw) a feature on the layer.  If the optional  
style argument
      * is included, this style will be used.  If no style is  
included, the
      * feature's style will be used.  If the feature doesn't have a  
style,
      * the layer's style will be used.
      *
      * This function is not designed to be used when adding features to
      * the layer (use addFeatures instead). It is meant to be used when
      * the style of a feature has changed, or in some other way needs  
to
      * visually updated *after* it has already been added to a layer.  
You
      * must add the feature to the layer for most layer-related  
events to
      * happen.
      *
      * Parameters:
      * feature - {<OpenLayers.Feature.Vector>}
      * style - {Object} Symbolizer hash or {String} renderIntent
      */

I think if it is design that the feature's style is not updated with  
the passed in style then the docs should be updated to indicate this.   
I can create a ticket for this with a stripped down example if the  
consensus is that it should update the style.  I may even be able to  
provide a patch ...

Paul
__________________________________________

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


From ahocevar at opengeo.org  Wed Jun 17 10:48:13 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] vector drawFeature bug or by design?
In-Reply-To: <03C62022-B89C-40BB-9952-BDFD42C21537@dmsolutions.ca>
References: <03C62022-B89C-40BB-9952-BDFD42C21537@dmsolutions.ca>
Message-ID: <5b021dd0906170748w1329fb58w1dd6fb5ac8cc9e23@mail.gmail.com>

Hi Paul,

On Wed, Jun 17, 2009 at 4:33 PM, Paul Spencer<pspencer@dmsolutions.ca> wrote:
> I have a question about Layer.Vector.drawFeature when passing a
> style ...
>
> I used this method to update the label of a point with an existing
> style (set directly on the feature) as the measure tool moved by
> calling this.handler.layer.drawFeature(text, {label: newDistance})
> which worked perfectly until the user zoomed using the mouse wheel
> while measuring. ?I've since changed this to set text.style.label =
> newDistance; this.handler.layer.drawFeature(text); which works fine.
>
> But this led me to question whether this is by design or a bug.

This is by design. Styles passed with drawFeature are independent of
the feature's style and are lost with subsequent calls of drawFeature,
which happen on zoomend.

> The relevant docs are:
>
> ? ? ?* This function is not designed to be used when adding features to
> ? ? ?* the layer (use addFeatures instead). It is meant to be used when
> ? ? ?* the style of a feature has changed, or in some other way needs

As it says: when the style *of a feature* has changed. Passing a style
to drawFeature does not change the feature's style. You do it right in
your working version, and you did not do it in your first attempt.

> I think if it is design that the feature's style is not updated with
> the passed in style then the docs should be updated to indicate this.

On the other hand, the docs do not say that the feature's style is
updated with the passed style... Anyway, please add some clarification
if you see the need. As a non-functional change, this can go in
without ticket and review.

Regards,
Andreas.

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From crschmidt at metacarta.com  Wed Jun 17 12:02:03 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
Message-ID: <20090617160203.GJ16388@metacarta.com>

I'm in favor of making RC6 final. All in favor?

 +1

Regards, 
-- 
Christopher Schmidt
MetaCarta

From ahocevar at opengeo.org  Wed Jun 17 12:07:45 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <5b021dd0906170907t9b3d52bs8c46fba07f20d83a@mail.gmail.com>

+1

On Wed, Jun 17, 2009 at 6:02 PM, Christopher
Schmidt<crschmidt@metacarta.com> wrote:
> I'm in favor of making RC6 final. All in favor?
>
> ?+1
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From ahocevar at opengeo.org  Wed Jun 17 12:27:21 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] VirtualEarth onResize() event.
In-Reply-To: <217B5942A5026F4780967A6E752C89AB1197BAD9@brmail1.ieminc.com>
References: <217B5942A5026F4780967A6E752C89AB1197BAD9@brmail1.ieminc.com>
Message-ID: <5b021dd0906170927g4d8cb40cn88ac1231e7ce825c@mail.gmail.com>

Hi Matt,

On Wed, Jun 17, 2009 at 2:41 AM, Diez, Matthew<Matthew.Diez@iem.com> wrote:
> I believe that the VirtualEarth layer needs to have the following method
> attached:
>
> ? ? ? ?onMapResize: function() {
> ? ? ? ? ? ? ? ?this.mapObject.Resize(this.map.size.w, this.map.size.h);
> ? ?},

Our other commercial layer wrappers also have something similar in
onMapResize. I can confirm that the issue exists, and that the above
fixes it.

Can you please create a ticket, provide a patch and submit a
Contributors License Agreement (if you haven't already)? For details,
see http://trac.openlayers.org/wiki/HowToContribute

Thanks!
Andreas.

>
> Unlike other types of 900913 layers, VirtualEarth doesn't automatically
> recalculate its bounds on the SetCenter (or SetCenterAndZoom) methods.
>
> This, at least, fixes a handful of my problems. Can anyone else confirm
> it? Shall I build out and post a test case to explain my rationale?
>
> Matthew D. Diez
> Software Engineer - GIS and Meteorology
> Innovative Emergency Management, Inc.
> 8550 United Plaza Boulevard, Suite 501
> Baton Rouge, LA 70809
> (225) 952-8279
>
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From euzuro at gmail.com  Wed Jun 17 13:10:40 2009
From: euzuro at gmail.com (Erik Uzureau)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <5b021dd0906170907t9b3d52bs8c46fba07f20d83a@mail.gmail.com>
References: <20090617160203.GJ16388@metacarta.com>
	<5b021dd0906170907t9b3d52bs8c46fba07f20d83a@mail.gmail.com>
Message-ID: <6ae3fb590906171010s44fa06b2j2611a0716e48300f@mail.gmail.com>

+0

On Wed, Jun 17, 2009 at 11:07, Andreas Hocevar <ahocevar@opengeo.org> wrote:

> +1
>
> On Wed, Jun 17, 2009 at 6:02 PM, Christopher
> Schmidt<crschmidt@metacarta.com> wrote:
> > I'm in favor of making RC6 final. All in favor?
> >
> >  +1
> >
> > Regards,
> > --
> > Christopher Schmidt
> > MetaCarta
> > _______________________________________________
> > Dev mailing list
> > Dev@openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >
>
>
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
> _______________________________________________
> 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/20090617/cbb2fcb7/attachment.html
From pspencer at dmsolutions.ca  Wed Jun 17 14:15:57 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <2D514549-612E-465A-8A73-7C43B4928E9E@dmsolutions.ca>

+1 Paul

On 17-Jun-09, at 12:02 PM, Christopher Schmidt wrote:

> I'm in favor of making RC6 final. All in favor?
>
> +1
>
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

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


From tschaub at opengeo.org  Wed Jun 17 18:22:41 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <4A396CB1.9050502@opengeo.org>

Christopher Schmidt wrote:
> I'm in favor of making RC6 final. All in favor?

+1

> 
>  +1
> 
> Regards, 


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From vivien.deparday at gmail.com  Thu Jun 18 00:04:43 2009
From: vivien.deparday at gmail.com (Vivien Deparday)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6?  (ticket #1797)
Message-ID: <4A39BCDB.8020303@gmail.com>

Hello,
sorry to talk about this ticket yet again but I still have an issue. 
This issue can be reproduced with the example attached to the ticket 
#1797 with Firefox 3. When clicking the button resize of the example 
(which changes the div size and execute map.updateSize), it now works. 
However, if you resize manually the Firefox window (by manually I mean 
with the handle at the bottom right-hand corner or with the 
resize/maximize button beside the close button or when you use the full 
screen mode by pressing F11) and then switch the layer, all the tiles 
don't get refreshed. You have to resize the window again and then it 
works. You can also reproduce this with the example I attached to the 
ticket #2055. In this case, the vector layer is also misaligned.
Besides, I think related to this bug, I have an application working with 
ExtJS/MapFish (sorry I didn't have time to minimize it) where I use a 
vector layer. If I switch the layer right after the first load (without 
manual resize), all the tiles get refreshed but the vector layer gets 
misaligned until I resize the window again.
Let me know if you can reproduce this issue with the two examples and if 
you would need me to minimize my application to help solving this issue.
Hopefully, it's not worth delaying the release of the 2.8.

Cheers,

Vivien

From eric.lemoine at camptocamp.com  Thu Jun 18 00:05:26 2009
From: eric.lemoine at camptocamp.com (Eric Lemoine)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <ca7da9120906172105kbd733f6x7b6d9962e79048a3@mail.gmail.com>

On Wednesday, June 17, 2009, Christopher Schmidt
<crschmidt@metacarta.com> wrote:
> I'm in favor of making RC6 final. All in favor?
>
> ?+1

+1


>r
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine@camptocamp.com
http://www.camptocamp.com

From cameron.shorter at lisasoft.com  Thu Jun 18 01:22:07 2009
From: cameron.shorter at lisasoft.com (Cameron Shorter)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <4A39CEFF.6080603@lisasoft.com>

+1


Christopher Schmidt wrote:
> I'm in favor of making RC6 final. All in favor?
>
>  +1
>
> Regards, 
>   


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com


From ahocevar at opengeo.org  Thu Jun 18 04:35:23 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <4A39BCDB.8020303@gmail.com>
References: <4A39BCDB.8020303@gmail.com>
Message-ID: <5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>

Hi Vivien,

On Thu, Jun 18, 2009 at 6:04 AM, Vivien
Deparday<vivien.deparday@gmail.com> wrote:
> Hello,
> sorry to talk about this ticket yet again but I still have an issue.
> This issue can be reproduced with the example attached to the ticket
> #1797 with Firefox 3. When clicking the button resize of the example
> (which changes the div size and execute map.updateSize), it now works.
> However, if you resize manually the Firefox window (by manually I mean
> with the handle at the bottom right-hand corner or with the
> resize/maximize button beside the close button or when you use the full
> screen mode by pressing F11) and then switch the layer, all the tiles
> don't get refreshed. You have to resize the window again and then it
> works. You can also reproduce this with the example I attached to the
> ticket #2055. In this case, the vector layer is also misaligned.

Ok, I tried with the example attached to #1797, after removing the
width and height styles of the map div. Works fine. Then I tried with
the exmaple attached to #2055, modified the paths and proxy to make it
work in my environment, and also cannot reproduce the issue.


> Let me know if you can reproduce this issue with the two examples and if
> you would need me to minimize my application to help solving this issue.
> Hopefully, it's not worth delaying the release of the 2.8.

I cannot reproduce the issue. The problem with the GMaps API is that
their JS can change any time, so it is hard to reproduce these things
in general. I do not think it is worth delaying the release of 2.8.

Regards,
Andreas.

>
> Cheers,
>
> Vivien
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From crschmidt at metacarta.com  Thu Jun 18 07:57:49 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
References: <4A39BCDB.8020303@gmail.com>
	<5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
Message-ID: <20090618115748.GK16388@metacarta.com>

On Thu, Jun 18, 2009 at 10:35:23AM +0200, Andreas Hocevar wrote:
> Hi Vivien,
> 
> On Thu, Jun 18, 2009 at 6:04 AM, Vivien
> Deparday<vivien.deparday@gmail.com> wrote:
> > Hello,
> > sorry to talk about this ticket yet again but I still have an issue.
> > This issue can be reproduced with the example attached to the ticket
> > #1797 with Firefox 3. When clicking the button resize of the example
> > (which changes the div size and execute map.updateSize), it now works.
> > However, if you resize manually the Firefox window (by manually I mean
> > with the handle at the bottom right-hand corner or with the
> > resize/maximize button beside the close button or when you use the full
> > screen mode by pressing F11) and then switch the layer, all the tiles
> > don't get refreshed. You have to resize the window again and then it
> > works. You can also reproduce this with the example I attached to the
> > ticket #2055. In this case, the vector layer is also misaligned.
> 
> Ok, I tried with the example attached to #1797, after removing the
> width and height styles of the map div. Works fine. Then I tried with
> the exmaple attached to #2055, modified the paths and proxy to make it
> work in my environment, and also cannot reproduce the issue.
> 
> 
> > Let me know if you can reproduce this issue with the two examples and if
> > you would need me to minimize my application to help solving this issue.
> > Hopefully, it's not worth delaying the release of the 2.8.
> 
> I cannot reproduce the issue. The problem with the GMaps API is that
> their JS can change any time, so it is hard to reproduce these things
> in general. I do not think it is worth delaying the release of 2.8.

Right, even fi it is a bug, it won't be fixed in this release. It didn't
work before, so it can't be a regression against 2.7.

Regards,
-- 
Christopher Schmidt
MetaCarta

From vivien.deparday at gmail.com  Thu Jun 18 11:42:07 2009
From: vivien.deparday at gmail.com (Vivien Deparday)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
References: <4A39BCDB.8020303@gmail.com>
	<5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
Message-ID: <4A3A604F.9000404@gmail.com>

Hi Andreas,
I can still reproduce the error but it doesn't happen at every manual 
resize with the two examples. Sometimes I have to play more with 
resizing the window and the layer switcher. I found a sequence that 
makes it happen every time with the basic example from gregers  (after 
removing width and height style of the map div) :  load the page,  press 
F11, switch to google streets layer, press F11, switch back to google 
physical and there  you should have the bug. It also happens in many 
other resizing and layer switcher uses.
Let me know if you can reproduce.

Viv

Andreas Hocevar wrote:
> Hi Vivien,
>
> On Thu, Jun 18, 2009 at 6:04 AM, Vivien
> Deparday<vivien.deparday@gmail.com> wrote:
>   
>> Hello,
>> sorry to talk about this ticket yet again but I still have an issue.
>> This issue can be reproduced with the example attached to the ticket
>> #1797 with Firefox 3. When clicking the button resize of the example
>> (which changes the div size and execute map.updateSize), it now works.
>> However, if you resize manually the Firefox window (by manually I mean
>> with the handle at the bottom right-hand corner or with the
>> resize/maximize button beside the close button or when you use the full
>> screen mode by pressing F11) and then switch the layer, all the tiles
>> don't get refreshed. You have to resize the window again and then it
>> works. You can also reproduce this with the example I attached to the
>> ticket #2055. In this case, the vector layer is also misaligned.
>>     
>
> Ok, I tried with the example attached to #1797, after removing the
> width and height styles of the map div. Works fine. Then I tried with
> the exmaple attached to #2055, modified the paths and proxy to make it
> work in my environment, and also cannot reproduce the issue.
>
>
>   
>> Let me know if you can reproduce this issue with the two examples and if
>> you would need me to minimize my application to help solving this issue.
>> Hopefully, it's not worth delaying the release of the 2.8.
>>     
>
> I cannot reproduce the issue. The problem with the GMaps API is that
> their JS can change any time, so it is hard to reproduce these things
> in general. I do not think it is worth delaying the release of 2.8.
>
> Regards,
> Andreas.
>
>   
>> Cheers,
>>
>> Vivien
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>>     
>
>
>
>   


From schuyler at nocat.net  Thu Jun 18 12:18:12 2009
From: schuyler at nocat.net (Schuyler Erle)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <5b021dd0906170907t9b3d52bs8c46fba07f20d83a@mail.gmail.com>
References: <20090617160203.GJ16388@metacarta.com>
	<5b021dd0906170907t9b3d52bs8c46fba07f20d83a@mail.gmail.com>
Message-ID: <1245341892.30719.7.camel@goldman>

+1! hooray!

SDE

On Wed, 2009-06-17 at 18:07 +0200, Andreas Hocevar wrote:
> +1
> 
> On Wed, Jun 17, 2009 at 6:02 PM, Christopher
> Schmidt<crschmidt@metacarta.com> wrote:
> > I'm in favor of making RC6 final. All in favor?
> >
> >  +1
> >
> > Regards,
> > --
> > Christopher Schmidt
> > MetaCarta
> > _______________________________________________
> > Dev mailing list
> > Dev@openlayers.org
> > http://openlayers.org/mailman/listinfo/dev
> >
> 
> 
> 


From ahocevar at opengeo.org  Thu Jun 18 14:24:04 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <4A3A604F.9000404@gmail.com>
References: <4A39BCDB.8020303@gmail.com>
	<5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
	<4A3A604F.9000404@gmail.com>
Message-ID: <5b021dd0906181124p5e65e7d3kd9578542b5855453@mail.gmail.com>

Hi Vivien,

On Thu, Jun 18, 2009 at 5:42 PM, Vivien
Deparday<vivien.deparday@gmail.com> wrote:
> I can still reproduce the error but it doesn't happen at every manual
> resize with the two examples. Sometimes I have to play more with
> resizing the window and the layer switcher. I found a sequence that
> makes it happen every time with the basic example from gregers ?(after
> removing width and height style of the map div) : ?load the page, ?press
> F11, switch to google streets layer, press F11, switch back to google
> physical and there ?you should have the bug. It also happens in many
> other resizing and layer switcher uses.
> Let me know if you can reproduce.

Yes, _this_ I can reproduce. And it seems to be a new issue. Until
now, we only encountered problems when making the map _larger_. This
one happens when we make it _smaller_. I cannot help, but I have the
impression that everytime we revisit #1797, there are new issues, and
it always behaves different with OL 2.7 and 2.8, but never completely
right. I doubt that this is just OpenLayers' fault.

Regards,
Andreas.

>
> Viv
>
> Andreas Hocevar wrote:
>> Hi Vivien,
>>
>> On Thu, Jun 18, 2009 at 6:04 AM, Vivien
>> Deparday<vivien.deparday@gmail.com> wrote:
>>
>>> Hello,
>>> sorry to talk about this ticket yet again but I still have an issue.
>>> This issue can be reproduced with the example attached to the ticket
>>> #1797 with Firefox 3. When clicking the button resize of the example
>>> (which changes the div size and execute map.updateSize), it now works.
>>> However, if you resize manually the Firefox window (by manually I mean
>>> with the handle at the bottom right-hand corner or with the
>>> resize/maximize button beside the close button or when you use the full
>>> screen mode by pressing F11) and then switch the layer, all the tiles
>>> don't get refreshed. You have to resize the window again and then it
>>> works. You can also reproduce this with the example I attached to the
>>> ticket #2055. In this case, the vector layer is also misaligned.
>>>
>>
>> Ok, I tried with the example attached to #1797, after removing the
>> width and height styles of the map div. Works fine. Then I tried with
>> the exmaple attached to #2055, modified the paths and proxy to make it
>> work in my environment, and also cannot reproduce the issue.
>>
>>
>>
>>> Let me know if you can reproduce this issue with the two examples and if
>>> you would need me to minimize my application to help solving this issue.
>>> Hopefully, it's not worth delaying the release of the 2.8.
>>>
>>
>> I cannot reproduce the issue. The problem with the GMaps API is that
>> their JS can change any time, so it is hard to reproduce these things
>> in general. I do not think it is worth delaying the release of 2.8.
>>
>> Regards,
>> Andreas.
>>
>>
>>> Cheers,
>>>
>>> Vivien
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From vivien.deparday at gmail.com  Thu Jun 18 15:39:06 2009
From: vivien.deparday at gmail.com (Vivien Deparday)
Date: Wed Sep  1 17:24:16 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <5b021dd0906181124p5e65e7d3kd9578542b5855453@mail.gmail.com>
References: <4A39BCDB.8020303@gmail.com>	
	<5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>	
	<4A3A604F.9000404@gmail.com>
	<5b021dd0906181124p5e65e7d3kd9578542b5855453@mail.gmail.com>
Message-ID: <4A3A97DA.1040503@gmail.com>

It can also be reproduced  when you make it larger: load the page, 
switch to the street layer, press F11, switch back to the physical layer 
and it happens. However, I agree that it's likely not only or maybe not 
at all Openlayers' fault and it's tricky to locate where the issue is. 
It was just to report this issue that hinders the use of google layers.
Concerning the misaligned vector layer after switching layers, I'll try 
to minimize my application but I feel like it's due to an interaction 
with ExtJS so I will post on GeoExt mailing when I find something.

Regards,

Vivien


Andreas Hocevar wrote:
> Hi Vivien,
>
> On Thu, Jun 18, 2009 at 5:42 PM, Vivien
> Deparday<vivien.deparday@gmail.com> wrote:
>   
>> I can still reproduce the error but it doesn't happen at every manual
>> resize with the two examples. Sometimes I have to play more with
>> resizing the window and the layer switcher. I found a sequence that
>> makes it happen every time with the basic example from gregers  (after
>> removing width and height style of the map div) :  load the page,  press
>> F11, switch to google streets layer, press F11, switch back to google
>> physical and there  you should have the bug. It also happens in many
>> other resizing and layer switcher uses.
>> Let me know if you can reproduce.
>>     
>
> Yes, _this_ I can reproduce. And it seems to be a new issue. Until
> now, we only encountered problems when making the map _larger_. This
> one happens when we make it _smaller_. I cannot help, but I have the
> impression that everytime we revisit #1797, there are new issues, and
> it always behaves different with OL 2.7 and 2.8, but never completely
> right. I doubt that this is just OpenLayers' fault.
>
> Regards,
> Andreas.
>
>   
>> Viv
>>
>> Andreas Hocevar wrote:
>>     
>>> Hi Vivien,
>>>
>>> On Thu, Jun 18, 2009 at 6:04 AM, Vivien
>>> Deparday<vivien.deparday@gmail.com> wrote:
>>>
>>>       
>>>> Hello,
>>>> sorry to talk about this ticket yet again but I still have an issue.
>>>> This issue can be reproduced with the example attached to the ticket
>>>> #1797 with Firefox 3. When clicking the button resize of the example
>>>> (which changes the div size and execute map.updateSize), it now works.
>>>> However, if you resize manually the Firefox window (by manually I mean
>>>> with the handle at the bottom right-hand corner or with the
>>>> resize/maximize button beside the close button or when you use the full
>>>> screen mode by pressing F11) and then switch the layer, all the tiles
>>>> don't get refreshed. You have to resize the window again and then it
>>>> works. You can also reproduce this with the example I attached to the
>>>> ticket #2055. In this case, the vector layer is also misaligned.
>>>>
>>>>         
>>> Ok, I tried with the example attached to #1797, after removing the
>>> width and height styles of the map div. Works fine. Then I tried with
>>> the exmaple attached to #2055, modified the paths and proxy to make it
>>> work in my environment, and also cannot reproduce the issue.
>>>
>>>
>>>
>>>       
>>>> Let me know if you can reproduce this issue with the two examples and if
>>>> you would need me to minimize my application to help solving this issue.
>>>> Hopefully, it's not worth delaying the release of the 2.8.
>>>>
>>>>         
>>> I cannot reproduce the issue. The problem with the GMaps API is that
>>> their JS can change any time, so it is hard to reproduce these things
>>> in general. I do not think it is worth delaying the release of 2.8.
>>>
>>> Regards,
>>> Andreas.
>>>
>>>
>>>       
>>>> Cheers,
>>>>
>>>> Vivien
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev@openlayers.org
>>>> http://openlayers.org/mailman/listinfo/dev
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>>     
>
>
>
>   


From ahocevar at opengeo.org  Fri Jun 19 04:05:57 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Bug in the 2.8 RC6? (ticket #1797)
In-Reply-To: <4A3A97DA.1040503@gmail.com>
References: <4A39BCDB.8020303@gmail.com>
	<5b021dd0906180135m7aaa1cf7wfdb3b36a2fcc5013@mail.gmail.com>
	<4A3A604F.9000404@gmail.com>
	<5b021dd0906181124p5e65e7d3kd9578542b5855453@mail.gmail.com>
	<4A3A97DA.1040503@gmail.com>
Message-ID: <5b021dd0906190105r51462eber641ca9463eac36a9@mail.gmail.com>

Hi Vivien,

the solution to these resize problems is maybe to use just one GMap
object and change its map type. This is a bit quirky and non-api at
the moment (i.e. one layer for all types instead of one layer per
type), but maybe future attempts to tackle the issue should go into
this direction:

myGoogleLayer.type = G_SATELLITE_MAP;
myGoogleLayer.setMapType();
// now we have a satellite map

myGoogleLayer.type = G_HYBRID_MAP;
myGoogleLayer.setMapType();
// now we have a hybrid map

Hope this helps, and if anyone wants to create a patch to make this
more consistent with the API, I'd be willing to mentor and review. I
have the feeling that the right way to do it would be to store the
mapObject as property on the prototype when first requested, and
instances only do the mapType handling in setVisibility. This would
also be a good step towards memory efficiency.

Regards,
Andreas.

On Thu, Jun 18, 2009 at 9:39 PM, Vivien
Deparday<vivien.deparday@gmail.com> wrote:
> It can also be reproduced ?when you make it larger: load the page,
> switch to the street layer, press F11, switch back to the physical layer
> and it happens. However, I agree that it's likely not only or maybe not
> at all Openlayers' fault and it's tricky to locate where the issue is.
> It was just to report this issue that hinders the use of google layers.
> Concerning the misaligned vector layer after switching layers, I'll try
> to minimize my application but I feel like it's due to an interaction
> with ExtJS so I will post on GeoExt mailing when I find something.
>
> Regards,
>
> Vivien
>
>
> Andreas Hocevar wrote:
>> Hi Vivien,
>>
>> On Thu, Jun 18, 2009 at 5:42 PM, Vivien
>> Deparday<vivien.deparday@gmail.com> wrote:
>>
>>> I can still reproduce the error but it doesn't happen at every manual
>>> resize with the two examples. Sometimes I have to play more with
>>> resizing the window and the layer switcher. I found a sequence that
>>> makes it happen every time with the basic example from gregers ?(after
>>> removing width and height style of the map div) : ?load the page, ?press
>>> F11, switch to google streets layer, press F11, switch back to google
>>> physical and there ?you should have the bug. It also happens in many
>>> other resizing and layer switcher uses.
>>> Let me know if you can reproduce.
>>>
>>
>> Yes, _this_ I can reproduce. And it seems to be a new issue. Until
>> now, we only encountered problems when making the map _larger_. This
>> one happens when we make it _smaller_. I cannot help, but I have the
>> impression that everytime we revisit #1797, there are new issues, and
>> it always behaves different with OL 2.7 and 2.8, but never completely
>> right. I doubt that this is just OpenLayers' fault.
>>
>> Regards,
>> Andreas.
>>
>>
>>> Viv
>>>
>>> Andreas Hocevar wrote:
>>>
>>>> Hi Vivien,
>>>>
>>>> On Thu, Jun 18, 2009 at 6:04 AM, Vivien
>>>> Deparday<vivien.deparday@gmail.com> wrote:
>>>>
>>>>
>>>>> Hello,
>>>>> sorry to talk about this ticket yet again but I still have an issue.
>>>>> This issue can be reproduced with the example attached to the ticket
>>>>> #1797 with Firefox 3. When clicking the button resize of the example
>>>>> (which changes the div size and execute map.updateSize), it now works.
>>>>> However, if you resize manually the Firefox window (by manually I mean
>>>>> with the handle at the bottom right-hand corner or with the
>>>>> resize/maximize button beside the close button or when you use the full
>>>>> screen mode by pressing F11) and then switch the layer, all the tiles
>>>>> don't get refreshed. You have to resize the window again and then it
>>>>> works. You can also reproduce this with the example I attached to the
>>>>> ticket #2055. In this case, the vector layer is also misaligned.
>>>>>
>>>>>
>>>> Ok, I tried with the example attached to #1797, after removing the
>>>> width and height styles of the map div. Works fine. Then I tried with
>>>> the exmaple attached to #2055, modified the paths and proxy to make it
>>>> work in my environment, and also cannot reproduce the issue.
>>>>
>>>>
>>>>
>>>>
>>>>> Let me know if you can reproduce this issue with the two examples and if
>>>>> you would need me to minimize my application to help solving this issue.
>>>>> Hopefully, it's not worth delaying the release of the 2.8.
>>>>>
>>>>>
>>>> I cannot reproduce the issue. The problem with the GMaps API is that
>>>> their JS can change any time, so it is hard to reproduce these things
>>>> in general. I do not think it is worth delaying the release of 2.8.
>>>>
>>>> Regards,
>>>> Andreas.
>>>>
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Vivien
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> Dev@openlayers.org
>>>>> http://openlayers.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From pspencer at dmsolutions.ca  Fri Jun 19 09:02:43 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Fixed Strategy question
Message-ID: <B2369E69-26E2-4DB6-BA7E-F93E3C35CEE2@dmsolutions.ca>

Is there any particular reason why the Fixed strategy does not use the  
layer filter?  I'd like to be able to use it against a WFS and load  
all the features but with a filter.

I've tested this in my application using this quick workaround:

var fixed = new OpenLayers.Strategy.Fixed({
     load: function(options) {
         OpenLayers.Strategy.Fixed.prototype.load.apply(this,  
[{filter:this.layer.filter}]);
     }
});

and it works as I would like.  I will add a patch to make Fixed work  
like BBOX in applying a filter in the load method unless there is a  
reason why it was left out in the first place.

Cheers

Paul

__________________________________________

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


From pspencer at dmsolutions.ca  Fri Jun 19 11:14:23 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] createLiteral enhancement proposal
Message-ID: <9E57D7B4-B941-448C-84C2-7D00CA47E964@dmsolutions.ca>

In the context of calling functions to compute styles for features  
using the ${functionName} syntax, it would be very useful for me if  
the property being computed was passed to functionName() in addition  
to the feature itself.  I've tested this locally by modifying  
createLiterals to pass an array with [feature,i] (where i is the  
property name) and createLiteral to replace feature with args, which  
is passed to String.format as the third value.  This works perfectly  
for me.  The only other use of createLiteral is in Rule, which does  
not use the third argument at all.

I would like to propose this change as a patch but I am undecided if  
the appropriate change is to pass an array as the third argument to  
createLiteral or to test in createLiteral if the third argument is an  
array or not and modify it appropriately for passing on to  
String.format ...

Currently, I am using this:

OpenLayers.Style.createLiteral = function(value, context, args) {
     if (typeof value == "string" && value.indexOf("${") != -1) {
         value = OpenLayers.String.format(value, context, args);
         value = (isNaN(value) || !value) ? value : parseFloat(value);
     }
     return value;
};

What I could do is:

OpenLayers.Style.createLiteral = function(value, context, feature) {
     var args = typeof(feature) == 'array' ? feature : [feature];
     if (typeof value == "string" && value.indexOf("${") != -1) {
         value = OpenLayers.String.format(value, context, args);
         value = (isNaN(value) || !value) ? value : parseFloat(value);
     }
     return value;
};

Comments?

__________________________________________

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


From ahocevar at opengeo.org  Sun Jun 21 12:29:08 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] createLiteral enhancement proposal
In-Reply-To: <9E57D7B4-B941-448C-84C2-7D00CA47E964@dmsolutions.ca>
References: <9E57D7B4-B941-448C-84C2-7D00CA47E964@dmsolutions.ca>
Message-ID: <5b021dd0906210929g33601fb0m26b4eb15540312a3@mail.gmail.com>

Hi Paul,

On Fri, Jun 19, 2009 at 5:14 PM, Paul Spencer<pspencer@dmsolutions.ca> wrote:
> In the context of calling functions to compute styles for features
> using the ${functionName} syntax, it would be very useful for me if
> the property being computed was passed to functionName() in addition
> to the feature itself. ?I've tested this locally by modifying
> createLiterals to pass an array with [feature,i] (where i is the
> property name) and createLiteral to replace feature with args, which
> is passed to String.format as the third value. ?This works perfectly
> for me. ?The only other use of createLiteral is in Rule, which does
> not use the third argument at all.
>
> I would like to propose this change as a patch but I am undecided if
> the appropriate change is to pass an array as the third argument to
> createLiteral or to test in createLiteral if the third argument is an
> array or not and modify it appropriately for passing on to
> String.format ...
>
> Currently, I am using this:
>
> OpenLayers.Style.createLiteral = function(value, context, args) {
> ? ? if (typeof value == "string" && value.indexOf("${") != -1) {
> ? ? ? ? value = OpenLayers.String.format(value, context, args);
> ? ? ? ? value = (isNaN(value) || !value) ? value : parseFloat(value);
> ? ? }
> ? ? return value;
> };

What about

OpenLayers.Style.createLiteral = function(value, context, feature, property) {
    if (typeof value == "string" && value.indexOf("${") != -1) {
        value = OpenLayers.String.format(value, context, [feature, property]);
        value = (isNaN(value) || !value) ? value : parseFloat(value);
    }
    return value;
};

Then you could have

    createLiterals: function(style, feature) {
        var context = this.context || feature.attributes || feature.data;

        for (var i in this.propertyStyles) {
            style[i] = OpenLayers.Style.createLiteral(style[i],
context, feature, i);
        }
        return style;
    },

and would not have to worry about API changes.

Regards,
Andreas.


>
> Comments?
>
> __________________________________________
>
> ? ?Paul Spencer
> ? ?Chief Technology Officer
> ? ?DM Solutions Group Inc
> ? ?http://research.dmsolutions.ca/
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From pspencer at dmsolutions.ca  Sun Jun 21 12:54:15 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] createLiteral enhancement proposal
In-Reply-To: <5b021dd0906210929g33601fb0m26b4eb15540312a3@mail.gmail.com>
References: <9E57D7B4-B941-448C-84C2-7D00CA47E964@dmsolutions.ca>
	<5b021dd0906210929g33601fb0m26b4eb15540312a3@mail.gmail.com>
Message-ID: <6A2C9ED6-BEA1-404A-9F41-EBAB875C8936@dmsolutions.ca>

Thanks for commenting, Andreas ...

On 21-Jun-09, at 12:29 PM, Andreas Hocevar wrote:

> Hi Paul,
>
> On Fri, Jun 19, 2009 at 5:14 PM, Paul  
> Spencer<pspencer@dmsolutions.ca> wrote:
>> In the context of calling functions to compute styles for features
>> using the ${functionName} syntax, it would be very useful for me if
>> the property being computed was passed to functionName() in addition
>> to the feature itself.  I've tested this locally by modifying
>> createLiterals to pass an array with [feature,i] (where i is the
>> property name) and createLiteral to replace feature with args, which
>> is passed to String.format as the third value.  This works perfectly
>> for me.  The only other use of createLiteral is in Rule, which does
>> not use the third argument at all.
>>
>> I would like to propose this change as a patch but I am undecided if
>> the appropriate change is to pass an array as the third argument to
>> createLiteral or to test in createLiteral if the third argument is an
>> array or not and modify it appropriately for passing on to
>> String.format ...
>>
>> Currently, I am using this:
>>
>> OpenLayers.Style.createLiteral = function(value, context, args) {
>>     if (typeof value == "string" && value.indexOf("${") != -1) {
>>         value = OpenLayers.String.format(value, context, args);
>>         value = (isNaN(value) || !value) ? value : parseFloat(value);
>>     }
>>     return value;
>> };
>
> What about
>
> OpenLayers.Style.createLiteral = function(value, context, feature,  
> property) {
>    if (typeof value == "string" && value.indexOf("${") != -1) {
>        value = OpenLayers.String.format(value, context, [feature,  
> property]);
>        value = (isNaN(value) || !value) ? value : parseFloat(value);
>    }
>    return value;
> };
>
> Then you could have
>
>    createLiterals: function(style, feature) {
>        var context = this.context || feature.attributes ||  
> feature.data;
>
>        for (var i in this.propertyStyles) {
>            style[i] = OpenLayers.Style.createLiteral(style[i],
> context, feature, i);
>        }
>        return style;
>    },
>
> and would not have to worry about API changes.

I thought of this and then decided on passing an array in the (perhaps  
unlikely) event that someone else thought of a need for other  
arguments they would like passed through createLiteral to  
String.format and beyond.  If that won't happen, then passing a fourth  
argument is probably the safer change (even though it is not an  
APIMethod)feat.

I will propose your suggestion as the patch in trac with a comment  
about my alternative and the possible reasons to implement one over  
the other.  I'll add it to http://trac.openlayers.org/ticket/2146  
which proposes to modify createLiterals to combine the context,  
attributes and data.

>
> Regards,
> Andreas.
>


__________________________________________

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


From roselinda.ackermans at ec.europa.eu  Mon Jun 22 05:33:27 2009
From: roselinda.ackermans at ec.europa.eu (Linde Ackermans)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] mapfish print control no longer working with
 2.8-rc6
Message-ID: <1245663207721-3131932.post@n2.nabble.com>


Hi,

The mapfish print control results in this err when using <script
src="http://openlayers.org/api/2.8-rc6/OpenLayers.js"></script> :

geometry.distanceTo is not a function     ( OpenLayers.js line 1452 )

It functions OK with the 2.7 release.

best regards,
linde ackermans

-- 
View this message in context: http://n2.nabble.com/mapfish-print-control-no-longer-working-with-2.8-rc6-tp3131932p3131932.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From roselinda.ackermans at ec.europa.eu  Mon Jun 22 05:45:07 2009
From: roselinda.ackermans at ec.europa.eu (Linde Ackermans)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] mapfish print control no longer working with
 2.8-rc6
In-Reply-To: <1245663207721-3131932.post@n2.nabble.com>
References: <1245663207721-3131932.post@n2.nabble.com>
Message-ID: <1245663907266-3131966.post@n2.nabble.com>


I should specify : when using the xtype: "print-simple" 



Linde Ackermans wrote:
> 
> Hi,
> 
> The mapfish print control results in this err when using <script
> src="http://openlayers.org/api/2.8-rc6/OpenLayers.js"></script> :
> 
> geometry.distanceTo is not a function     ( OpenLayers.js line 1452 )
> 
> It functions OK with the 2.7 release.
> 
> best regards,
> linde ackermans
> 
> 

-- 
View this message in context: http://n2.nabble.com/mapfish-print-control-no-longer-working-with-2.8-rc6-tp3131932p3131966.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From avarab at gmail.com  Mon Jun 22 15:48:33 2009
From: avarab at gmail.com (=?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?=)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Is there an OL application which demonstrates the
	context in which the OL translations are used?
Message-ID: <51dd1af80906221248w5c09f7eub22c0a1164c72ede@mail.gmail.com>

Hi, I'd like to add a new translation to OpenLayers (under
lib/OpenLayers/Lang/). But to do it properly I'd like to see the
translations in the context in which they are used.

Is there an application OpenLayers that triggers the various
errors/dialogs etc. that end up showing these messages? Or do
potential translators need to browse the source to try to figure out
in what context some of the more obscure ones are used?

en.js for reference:
http://trac.openlayers.org/browser/sandbox/madair/lib/OpenLayers/Lang/en.js

From kenneth.lind at logica.com  Mon Jun 22 15:53:21 2009
From: kenneth.lind at logica.com (Lind, Kenneth)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <C5E4853385FEA64198C3048F718D811726814B810D@SE-EX007.groupinfra.com>

+1 for me.


Kenneth Lind
_________________________________________

Logica - Releasing your potential
Pelle Bergs backe 3
Box 1938
79119 Falun
Sweden

T:  +46 (0) 243 93 670
M: +46 (0)76 14 60 572
E:  kenneth.lind@logica.com
www.logica.se
________________________________________
From: dev-bounces@openlayers.org [dev-bounces@openlayers.org] On Behalf Of Christopher Schmidt [crschmidt@metacarta.com]
Sent: 17 June 2009 18:02
To: dev@openlayers.org
Subject: [OpenLayers-Dev] 2.8 Final?

I'm in favor of making RC6 final. All in favor?

 +1

Regards,
--
Christopher Schmidt
MetaCarta
_______________________________________________
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
From crschmidt at metacarta.com  Mon Jun 22 15:58:14 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] 2.8 Final?
In-Reply-To: <20090617160203.GJ16388@metacarta.com>
References: <20090617160203.GJ16388@metacarta.com>
Message-ID: <20090622195814.GH22033@metacarta.com>

On Wed, Jun 17, 2009 at 12:02:03PM -0400, Christopher Schmidt wrote:
> I'm in favor of making RC6 final. All in favor?
> 
>  +1

With full support from the community, OpenLayers 2.8 has now been
released. Thanks for the hard work, everyone.

Best Regards,
-- 
Christopher Schmidt
MetaCarta

From tschaub at opengeo.org  Mon Jun 22 17:08:17 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Is there an OL application which demonstrates
 the	context in which the OL translations are used?
In-Reply-To: <51dd1af80906221248w5c09f7eub22c0a1164c72ede@mail.gmail.com>
References: <51dd1af80906221248w5c09f7eub22c0a1164c72ede@mail.gmail.com>
Message-ID: <4A3FF2C1.9000301@opengeo.org>

Hey-

?var Arnfj?r? Bjarmason wrote:
> Hi, I'd like to add a new translation to OpenLayers (under
> lib/OpenLayers/Lang/). But to do it properly I'd like to see the
> translations in the context in which they are used.
> 
> Is there an application OpenLayers that triggers the various
> errors/dialogs etc. that end up showing these messages? Or do
> potential translators need to browse the source to try to figure out
> in what context some of the more obscure ones are used?
> 

Thanks for the offer to help with translation.

We currently use a global dictionary for translation (as you have seen) 
instead of a dictionary per class (or otherwise).  The easiest way to 
see where specific keys are used is probably to search the lib for 
"OpenLayers.i18n".

Others may have other suggestions.

Tim

> en.js for reference:
> http://trac.openlayers.org/browser/sandbox/madair/lib/OpenLayers/Lang/en.js
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From ahocevar at opengeo.org  Tue Jun 23 04:06:46 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Please vote to start the 0.5 release procedure
Message-ID: <5b021dd0906230106s4f7ffcc3od0d7da4ec692c07a@mail.gmail.com>

Hi,

OpenLayers 2.8 is released, all tickets for the 0.5 milestone are
closed. Thanks to everyone who made that happen!

Now the only thing left to do is release GeoExt 0.5. To start the
release process, we need a vote from the PSC (according to [1]).

So may I have your votes gentlemen?

I am +1.

Regards,
Andreas.

[1] http://www.geoext.org/trac/geoext/wiki/Release/Procedure

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From ahocevar at opengeo.org  Tue Jun 23 04:07:55 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Please vote to start the 0.5 release procedure
In-Reply-To: <5b021dd0906230106s4f7ffcc3od0d7da4ec692c07a@mail.gmail.com>
References: <5b021dd0906230106s4f7ffcc3od0d7da4ec692c07a@mail.gmail.com>
Message-ID: <5b021dd0906230107x45e12b56y16cc2df5197d0454@mail.gmail.com>

Sorry, wrong mailing list. Why does that always happen with such
important mails?

Regards,
Andreas.

On Tue, Jun 23, 2009 at 10:06 AM, Andreas Hocevar<ahocevar@opengeo.org> wrote:
> Hi,
>
> OpenLayers 2.8 is released, all tickets for the 0.5 milestone are
> closed. Thanks to everyone who made that happen!
>
> Now the only thing left to do is release GeoExt 0.5. To start the
> release process, we need a vote from the PSC (according to [1]).
>
> So may I have your votes gentlemen?
>
> I am +1.
>
> Regards,
> Andreas.
>
> [1] http://www.geoext.org/trac/geoext/wiki/Release/Procedure
>
> --
> Andreas Hocevar
> OpenGeo - http://opengeo.org/
> Expert service straight from the developers.
>



-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From esteban.olm at gmail.com  Tue Jun 23 04:13:40 2009
From: esteban.olm at gmail.com (Esteban olm)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] javascript workers
Message-ID: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>

Hello,

Is in the openlayers developers' mind the idea of use javscript workers in
browsers that will support them to improve performance?

I think, for example, to have two "sub-layers" for each layer, so the
workers draws the new data on the hidden sublayer, then when finished, it
calls the main thread and it hides the actual sublayer and shows the hidden
one, or something like that.

For the user, there is no IU lost of performance, and he see the layer
re-drawn only when it has been finished.
Or something like that :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090623/38d4d008/attachment.html
From crschmidt at metacarta.com  Tue Jun 23 09:22:40 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] javascript workers
In-Reply-To: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>
References: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>
Message-ID: <20090623132240.GJ22033@metacarta.com>

On Tue, Jun 23, 2009 at 10:13:40AM +0200, Esteban olm wrote:
> Hello,
> 
> Is in the openlayers developers' mind the idea of use javscript workers in
> browsers that will support them to improve performance?
> 
> I think, for example, to have two "sub-layers" for each layer, so the
> workers draws the new data on the hidden sublayer, then when finished, it
> calls the main thread and it hides the actual sublayer and shows the hidden
> one, or something like that.
> 
> For the user, there is no IU lost of performance, and he see the layer
> re-drawn only when it has been finished.
> Or something like that :)

As far as I know, no browser (apart from Chrome?) natively supports
Javascript workers. The idea of maintaining something that is in such a
small percentage of browsers in the core of OpenLayers worries me, but
would be happy to suppot it as an addin, maintained by the community.

Regards,
-- 
Christopher Schmidt
MetaCarta

From rldhont at gmail.com  Tue Jun 23 11:44:57 2009
From: rldhont at gmail.com (rldhont)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] javascript workers
In-Reply-To: <20090623132240.GJ22033@metacarta.com>
References: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>
	<20090623132240.GJ22033@metacarta.com>
Message-ID: <4A40F879.3070007@gmail.com>

Christopher Schmidt a ?crit :
> On Tue, Jun 23, 2009 at 10:13:40AM +0200, Esteban olm wrote:
>   
>> Hello,
>>
>> Is in the openlayers developers' mind the idea of use javscript workers in
>> browsers that will support them to improve performance?
>>
>> I think, for example, to have two "sub-layers" for each layer, so the
>> workers draws the new data on the hidden sublayer, then when finished, it
>> calls the main thread and it hides the actual sublayer and shows the hidden
>> one, or something like that.
>>
>> For the user, there is no IU lost of performance, and he see the layer
>> re-drawn only when it has been finished.
>> Or something like that :)
>>     
>
> As far as I know, no browser (apart from Chrome?) natively supports
> Javascript workers. The idea of maintaining something that is in such a
> small percentage of browsers in the core of OpenLayers worries me, but
> would be happy to suppot it as an addin, maintained by the community.
>
> Regards,
>   

Firefox 3.5, which is in a public Realese Candidate Version, natively 
supports JavaScript Workers. And it's probably the same implementation 
in google gears like for Geolocation API.

JavaScript Workers will be usefull for reprojection, writing format, 
intersection and other geo-treatment, but it's not possible to use DOM 
in Worker.

Regards,

Ren?-Luc D'Hont
3Liz

From crschmidt at metacarta.com  Tue Jun 23 13:09:43 2009
From: crschmidt at metacarta.com (Christopher Schmidt)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] javascript workers
In-Reply-To: <4A40F879.3070007@gmail.com>
References: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>
	<20090623132240.GJ22033@metacarta.com> <4A40F879.3070007@gmail.com>
Message-ID: <20090623170942.GO22033@metacarta.com>

On Tue, Jun 23, 2009 at 05:44:57PM +0200, rldhont wrote:
> Christopher Schmidt a ?crit :
> >On Tue, Jun 23, 2009 at 10:13:40AM +0200, Esteban olm wrote:
> >  
> >>Hello,
> >>
> >>Is in the openlayers developers' mind the idea of use javscript workers in
> >>browsers that will support them to improve performance?
> >>
> >>I think, for example, to have two "sub-layers" for each layer, so the
> >>workers draws the new data on the hidden sublayer, then when finished, it
> >>calls the main thread and it hides the actual sublayer and shows the 
> >>hidden
> >>one, or something like that.
> >>
> >>For the user, there is no IU lost of performance, and he see the layer
> >>re-drawn only when it has been finished.
> >>Or something like that :)
> >>    
> >
> >As far as I know, no browser (apart from Chrome?) natively supports
> >Javascript workers. The idea of maintaining something that is in such a
> >small percentage of browsers in the core of OpenLayers worries me, but
> >would be happy to suppot it as an addin, maintained by the community.
> >
> >Regards,
> >  
> 
> Firefox 3.5, which is in a public Realese Candidate Version, natively 
> supports JavaScript Workers. And it's probably the same implementation 
> in google gears like for Geolocation API.
> 
> JavaScript Workers will be usefull for reprojection, writing format, 
> intersection and other geo-treatment, but it's not possible to use DOM 
> in Worker.

In that case, it seems unlikely the benefit would be signnificant.
Reprojection, writing formats, and (most) intersection work is fast
enough that I can't see the overhead being worth it. We can reproject
thousands of points a minute, and most of our formats center around the
usage of an XML DOM (don't know if this applies to the 'dom' restriction
or not). I'd suggest finding something that you think is slow and 
profiling it before deciding that workers will actually be worth the
effort :)

-- Chris

> Regards,
> 
> Ren?-Luc D'Hont
> 3Liz

-- 
Christopher Schmidt
MetaCarta

From tschaub at opengeo.org  Tue Jun 23 13:09:47 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] javascript workers
In-Reply-To: <4A40F879.3070007@gmail.com>
References: <1894fac30906230113u16114016nfc91933d80c96bd2@mail.gmail.com>	<20090623132240.GJ22033@metacarta.com>
	<4A40F879.3070007@gmail.com>
Message-ID: <4A410C5B.1020602@opengeo.org>

rldhont wrote:
> Christopher Schmidt a ?crit :
>> On Tue, Jun 23, 2009 at 10:13:40AM +0200, Esteban olm wrote:
>>   
>>> Hello,
>>>
>>> Is in the openlayers developers' mind the idea of use javscript workers in
>>> browsers that will support them to improve performance?
>>>
>>> I think, for example, to have two "sub-layers" for each layer, so the
>>> workers draws the new data on the hidden sublayer, then when finished, it
>>> calls the main thread and it hides the actual sublayer and shows the hidden
>>> one, or something like that.
>>>
>>> For the user, there is no IU lost of performance, and he see the layer
>>> re-drawn only when it has been finished.
>>> Or something like that :)
>>>     
>> As far as I know, no browser (apart from Chrome?) natively supports
>> Javascript workers. The idea of maintaining something that is in such a
>> small percentage of browsers in the core of OpenLayers worries me, but
>> would be happy to suppot it as an addin, maintained by the community.
>>
>> Regards,
>>   
> 
> Firefox 3.5, which is in a public Realese Candidate Version, natively 
> supports JavaScript Workers. And it's probably the same implementation 
> in google gears like for Geolocation API.
> 
> JavaScript Workers will be usefull for reprojection, writing format, 
> intersection and other geo-treatment, but it's not possible to use DOM 
> in Worker.
> 

Yeah, I was going to say the same.  Workers could be used to handle long 
running geoprocessing jobs - but won't help avoid rendering bottlenecks.

Tim


> Regards,
> 
> Ren?-Luc D'Hont
> 3Liz
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From tschaub at opengeo.org  Tue Jun 23 13:14:22 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Fixed Strategy question
In-Reply-To: <B2369E69-26E2-4DB6-BA7E-F93E3C35CEE2@dmsolutions.ca>
References: <B2369E69-26E2-4DB6-BA7E-F93E3C35CEE2@dmsolutions.ca>
Message-ID: <4A410D6E.4050202@opengeo.org>

Hey-

Paul Spencer wrote:
> Is there any particular reason why the Fixed strategy does not use the  
> layer filter?  I'd like to be able to use it against a WFS and load  
> all the features but with a filter.
> 
> I've tested this in my application using this quick workaround:
> 
> var fixed = new OpenLayers.Strategy.Fixed({
>      load: function(options) {
>          OpenLayers.Strategy.Fixed.prototype.load.apply(this,  
> [{filter:this.layer.filter}]);
>      }
> });
> 
> and it works as I would like.  I will add a patch to make Fixed work  
> like BBOX in applying a filter in the load method unless there is a  
> reason why it was left out in the first place.
> 

No good reason.  Please patch.  I haven't looked in a while, but I've 
also been meaning to make sure that we get consistent behavior with 
layer.refresh (as far as possible).

Tim

> Cheers
> 
> Paul
> 
> __________________________________________
> 
>     Paul Spencer
>     Chief Technology Officer
>     DM Solutions Group Inc
>     http://research.dmsolutions.ca/
> 
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From pspencer at dmsolutions.ca  Tue Jun 23 13:30:18 2009
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Fixed Strategy question
In-Reply-To: <4A410D6E.4050202@opengeo.org>
References: <B2369E69-26E2-4DB6-BA7E-F93E3C35CEE2@dmsolutions.ca>
	<4A410D6E.4050202@opengeo.org>
Message-ID: <EE7CDF64-6E29-4D89-B8FD-5CE2FEC279E4@dmsolutions.ca>

thanks for the comment, I've filed this as http://trac.openlayers.org/ticket/2152 
  with a very simple patch

On 23-Jun-09, at 1:14 PM, Tim Schaub wrote:

> Hey-
>
> Paul Spencer wrote:
>> Is there any particular reason why the Fixed strategy does not use  
>> the
>> layer filter?  I'd like to be able to use it against a WFS and load
>> all the features but with a filter.
>>
>> I've tested this in my application using this quick workaround:
>>
>> var fixed = new OpenLayers.Strategy.Fixed({
>>     load: function(options) {
>>         OpenLayers.Strategy.Fixed.prototype.load.apply(this,
>> [{filter:this.layer.filter}]);
>>     }
>> });
>>
>> and it works as I would like.  I will add a patch to make Fixed work
>> like BBOX in applying a filter in the load method unless there is a
>> reason why it was left out in the first place.
>>
>
> No good reason.  Please patch.  I haven't looked in a while, but I've
> also been meaning to make sure that we get consistent behavior with
> layer.refresh (as far as possible).
>
> Tim
>
>> Cheers
>>
>> Paul
>>
>> __________________________________________
>>
>>    Paul Spencer
>>    Chief Technology Officer
>>    DM Solutions Group Inc
>>    http://research.dmsolutions.ca/
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>
>
> -- 
> Tim Schaub
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


__________________________________________

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


From bjorn.harrtell at gmail.com  Tue Jun 23 17:49:26 2009
From: bjorn.harrtell at gmail.com (=?UTF-8?Q?Bj=C3=B6rn_Harrtell?=)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906110019l77cac97fna0fcaa39ddfeb99d@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>
	<4A25A606.1070702@lisasoft.com>
	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>
	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>
	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>
	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>
	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>
	<ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>
	<ca7da9120906110008j290a6297q7fa6269145724f94@mail.gmail.com>
	<ba82f3c60906110019l77cac97fna0fcaa39ddfeb99d@mail.gmail.com>
Message-ID: <ba82f3c60906231449y28ecbbeex364f5a8b4be4ecd8@mail.gmail.com>

Since I made the ticket I've done some additional work available in a
new sandbox (just for my own sake to keep track what I'm doing against
2.8 release)

The new stuff is topologyenforcement when adding or removing vertices,
which means that other features intersecting vertices will be removed
and an edge crossing a new vertex will be split so that another vertex
intersects the new one.

OpenLayers stuff added are vertexadded and vertexremoved events to the
Vector layer and an improvement (?) to containsPoint to give info
about which edge is crossing (if it is crossing).

Example is at:
http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology2/examples/topology.html

I'd also like to say that while I'm more or less where I wanted to get
functionally and have no current plans for further developent, new
patches for #2125 aren't my highest priority, partially because I
think the ticket/patch is good enough to discuss the matter of
if/how/when to continue the work somehow.

/Bj?rn

2009/6/11 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
> I won't argue for the current name, and can see your point so.. we'll
> see what happens :)
>
> Anyway, I put togheter the current code into a patch against current
> trunk for further discussion which might help you review the source
> (which would be highly appriciated):
>
> http://trac.openlayers.org/ticket/2125
>
> /Bj?rn
>
> On Thu, Jun 11, 2009 at 09:08, Eric Lemoine<eric.lemoine@camptocamp.com> wrote:
>> 2009/6/9 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>> Thanks Eric :)
>>>
>>> Details are important, though I would argue that
>>> OpenLayers.TopologyRule is only one char shorter than
>>> OpenLayers.Topology.Rule ;)
>>
>> I'm not trying to save chars here, but to avoid unnecessary deep
>> namespaces. Just a matter of elegance... I'll try to go deeper in your
>> code and come up with more constructive comments ;)
>>
>>
>>
>> --
>> Eric Lemoine
>>
>> Camptocamp France SAS
>> Savoie Technolac, BP 352
>> 73377 Le Bourget du Lac, Cedex
>>
>> Tel : 00 33 4 79 44 44 96
>> Mail : eric.lemoine@camptocamp.com
>> http://www.camptocamp.com
>>
>

From sam_mor at y7mail.com  Tue Jun 23 18:58:59 2009
From: sam_mor at y7mail.com (Sam Mor)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] InfoWindow
Message-ID: <66390.51090.qm@web44701.mail.sp1.yahoo.com>


Hi Guys
We Would like to ask you a question:
do you have InfoWindow or infobox?( it's what google call it) ?
when u use openInfoWindow it display a box with information on the map


if yes , please provide us with example or ...

thanks
Regards
Sam



      Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail

From tschaub at opengeo.org  Wed Jun 24 00:59:43 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Topology proposal
In-Reply-To: <ba82f3c60906231449y28ecbbeex364f5a8b4be4ecd8@mail.gmail.com>
References: <ba82f3c60904220414p12e080fdq63065e6e2b97f9b6@mail.gmail.com>	<4A25A606.1070702@lisasoft.com>	<ba82f3c60906040312q8b81e3ex59a5f063ed5f6af9@mail.gmail.com>	<ba82f3c60906041451y3f5710fby9fe18a89e0877e3d@mail.gmail.com>	<d8259d610906050820x42523a09o7f55e070c3148c01@mail.gmail.com>	<ba82f3c60906051721q451b9979g2953ece02fb1edb9@mail.gmail.com>	<ca7da9120906082301s303419cau48732aba7a9f84ac@mail.gmail.com>	<ba82f3c60906090508w547e3d69h53a2a7d82f559472@mail.gmail.com>	<ca7da9120906110008j290a6297q7fa6269145724f94@mail.gmail.com>	<ba82f3c60906110019l77cac97fna0fcaa39ddfeb99d@mail.gmail.com>
	<ba82f3c60906231449y28ecbbeex364f5a8b4be4ecd8@mail.gmail.com>
Message-ID: <4A41B2BF.9060504@opengeo.org>

Hey-

Bj?rn Harrtell wrote:
> Since I made the ticket I've done some additional work available in a
> new sandbox (just for my own sake to keep track what I'm doing against
> 2.8 release)
> 
> The new stuff is topologyenforcement when adding or removing vertices,
> which means that other features intersecting vertices will be removed
> and an edge crossing a new vertex will be split so that another vertex
> intersects the new one.
> 
> OpenLayers stuff added are vertexadded and vertexremoved events to the
> Vector layer and an improvement (?) to containsPoint to give info
> about which edge is crossing (if it is crossing).
> 
> Example is at:
> http://dev.openlayers.org/sandbox/bjornharrtell/eventbasedtopology2/examples/topology.html
> 

This is really cool Bj?rn.  It looks like you've done some really nice 
work.  I look forward to taking a closer look at the code in the near 
future (likely after July 1).

Tim

> I'd also like to say that while I'm more or less where I wanted to get
> functionally and have no current plans for further developent, new
> patches for #2125 aren't my highest priority, partially because I
> think the ticket/patch is good enough to discuss the matter of
> if/how/when to continue the work somehow.
> 
> /Bj?rn
> 
> 2009/6/11 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>> I won't argue for the current name, and can see your point so.. we'll
>> see what happens :)
>>
>> Anyway, I put togheter the current code into a patch against current
>> trunk for further discussion which might help you review the source
>> (which would be highly appriciated):
>>
>> http://trac.openlayers.org/ticket/2125
>>
>> /Bj?rn
>>
>> On Thu, Jun 11, 2009 at 09:08, Eric Lemoine<eric.lemoine@camptocamp.com> wrote:
>>> 2009/6/9 Bj?rn Harrtell <bjorn.harrtell@gmail.com>:
>>>> Thanks Eric :)
>>>>
>>>> Details are important, though I would argue that
>>>> OpenLayers.TopologyRule is only one char shorter than
>>>> OpenLayers.Topology.Rule ;)
>>> I'm not trying to save chars here, but to avoid unnecessary deep
>>> namespaces. Just a matter of elegance... I'll try to go deeper in your
>>> code and come up with more constructive comments ;)
>>>
>>>
>>>
>>> --
>>> Eric Lemoine
>>>
>>> Camptocamp France SAS
>>> Savoie Technolac, BP 352
>>> 73377 Le Bourget du Lac, Cedex
>>>
>>> Tel : 00 33 4 79 44 44 96
>>> Mail : eric.lemoine@camptocamp.com
>>> http://www.camptocamp.com
>>>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From trondmm-openlayers at crusaders.no  Wed Jun 24 10:03:57 2009
From: trondmm-openlayers at crusaders.no (Trond Michelsen)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] WMSCapabilities - properties and handling
	different versions
Message-ID: <20090624140356.GA16811@crusaders.no>

Hi.

I'm currently looking into parsing of WMSCapabilities, and there are a
few things I'm not completely sure on how to handle.

Besically it boils down to how close the WMSCapability data structure
should resemble the actual XML. Should it be as close to the XML as
possible, or is it desirable for v1_1_1.js and a future v_1_3_0.js to
return identical structures?

Example: In v1.1.1, There are two tags, Dimension and Extent. In
v1.3.0, these tags has been merged to one tag "Dimension". 

In v.1.1.1 it'll look like this:

<Dimension name="TIME" units="ISO8601"/>
<Extent name="TIME" nearestValue="0" default="2009-06-21T12:00">
  2009-06-21T06:00,2009-06-21T12:00,2009-06-21T18:00,2009-06-22T00:00,2009-06-22T06:00
</Extent>

and in v1.3.0 it'll look like this:

<Dimension name="TIME" units="ISO8601" nearestValue="0" default="2009-06-21T12:00">
  2009-06-21T06:00,2009-06-21T12:00,2009-06-21T18:00,2009-06-22T00:00,2009-06-22T06:00
</Dimension>

All attributes from Dimension and Extent has been kept, and Dimension
now takes the same values as the Extent tag did.

What should the data structure for v1.1.1 look like in the object?

{ dimension: {time: {name: "time",
                     units: "ISO8601"},
             },
  extent:    {time: {name: "time",
                     nearestValue: "0", 
                     default="2009-06-21T12:00", 
                     values: ["2009-06-21T06:00",
                              "2009-06-21T12:00",
                              "2009-06-21T18:00",
                              "2009-06-22T00:00",
                              "2009-06-22T06:00"]},
              }
}
                     
or simply: 

{ dimension: {time: {name: "time",
                     units: "ISO8601"},
                     nearestValue: "0", 
                     default="2009-06-21T12:00", 
                     values: ["2009-06-21T06:00",
                              "2009-06-21T12:00",
                              "2009-06-21T18:00",
                              "2009-06-22T00:00",
                              "2009-06-22T06:00"]},
              }
}
                     
Other tags have changed names, but as far as I can tell, the content
is the same:

LatLonBoundingBox -> EX_GeographicBoundingBox
SRS -> CRS
(also the BoundingBox attribute SRS has changed name to CRS)

Should these get new properties in the WMSCapabilities-layer object,
or is it OK to still use the old property names?

Personally, I'd prefer to use the same structure and property names
for 1.1.1 and 1.3.0 objects. 

Any opinions?

-- 
Trond Michelsen

From ahocevar at opengeo.org  Thu Jun 25 07:53:47 2009
From: ahocevar at opengeo.org (Andreas Hocevar)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] WMSCapabilities - properties and handling
	different versions
In-Reply-To: <20090624140356.GA16811@crusaders.no>
References: <20090624140356.GA16811@crusaders.no>
Message-ID: <5b021dd0906250453n7a0e9471v5fe36153d1d7af60@mail.gmail.com>

Hi Trond,

On Wed, Jun 24, 2009 at 4:03 PM, Trond
Michelsen<trondmm-openlayers@crusaders.no> wrote:
> Personally, I'd prefer to use the same structure and property names
> for 1.1.1 and 1.3.0 objects.

Definitely. Like we create the same vector features in Format.GML,
Format.KML, Format.GeoRSS and so on.

Regards,
Andreas.

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.

From tschaub at opengeo.org  Thu Jun 25 14:29:08 2009
From: tschaub at opengeo.org (Tim Schaub)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] InfoWindow
In-Reply-To: <66390.51090.qm@web44701.mail.sp1.yahoo.com>
References: <66390.51090.qm@web44701.mail.sp1.yahoo.com>
Message-ID: <4A43C1F4.5030606@opengeo.org>

Hey-

Sam Mor wrote:
> Hi Guys
> We Would like to ask you a question:
> do you have InfoWindow or infobox ( it's what google call it) ?
> when u use openInfoWindow it display a box with information on the map
> 

OpenLayers.Popup (and subclasses) provide a ui element that displays 
whatever content you like and is (or can be) anchored to a particular 
location on the map.

> 
> if yes , please provide us with example or ...
> 

http://openlayers.org/dev/examples/select-feature-openpopup.html

The content for the popup is up to you to generate.

For an example where some information related to map features is 
requested from the server, see the following:

http://openlayers.org/dev/examples/getfeatureinfo-control.html

The returned content could be used in a popup.

Tim

> thanks
> Regards
> Sam
> 
> 
> 
>       Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
> Show me how: http://au.mobile.yahoo.com/mail
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

From trondmm-openlayers at crusaders.no  Thu Jun 25 17:00:06 2009
From: trondmm-openlayers at crusaders.no (Trond Michelsen)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] WMSCapabilities - properties and handling
	different versions
In-Reply-To: <5b021dd0906250453n7a0e9471v5fe36153d1d7af60@mail.gmail.com>
References: <20090624140356.GA16811@crusaders.no>
	<5b021dd0906250453n7a0e9471v5fe36153d1d7af60@mail.gmail.com>
Message-ID: <20090625210006.GB27807@crusaders.no>

On Thu, Jun 25, 2009 at 01:53:47PM +0200, Andreas Hocevar wrote:
> On Wed, Jun 24, 2009 at 4:03 PM, Trond Michelsen
> <trondmm-openlayers@crusaders.no> wrote:
>> Personally, I'd prefer to use the same structure and property names
>> for 1.1.1 and 1.3.0 objects.
> Definitely. Like we create the same vector features in Format.GML,
> Format.KML, Format.GeoRSS and so on.

Good. I've opened ticket 2151 and submitted a patch that adds parsing
of SRS, BoundingBox, Dimension and Extent for v1.1.1 and v1.1.0. Tests
are included. For some reason, trac won't show my patches, they have
to be downloaded. 

I think everything works properly, and that I got the inheritance
rules right. Reviews are welcomed ;)

There's a couple of things I am a bit unsure of, though. The WMS 1.1.1
standard says this about Dimension:

--8<--
Dimension declarations are inherited from parent Layers. Any new
Dimension declarations in the child are added to the list inherited
from the parent. A child shall not redefine a Dimension with the same
name attribute as one that was inherited.
--8<--

I understand this as it is forbidden for a child layer to include
<Dimension name="elevation"> if this tag is present in the parent
layer. However, in the sample capabilities document in Annex A.2 (also
available at http://schemas.opengis.net/wms/1.1.1/capabilities_1_1_1.xml )
there are layers like this (irrelevant tags and layers removed):

  <Layer queryable="1">
    <Title>Weather Forecast Data</Title>
    <Dimension name="time" units="ISO8601" />
    <Extent name="time" default="2000-08-22">1999-01-01/2000-08-22/P1D</Extent>
    <Layer>
      <Name>Pressure</Name> 
      <Title>Forecast barometric pressure</Title>
      <Dimension name="time" units="ISO8601" />
      <Dimension name="elevation" units="EPSG:5030" />
      <Extent name="time" default="2000-08-22">1999-01-01/2000-08-22/P1D</Extent>
      <Extent name="elevation" default="0" nearestValue="1">0,1000,3000,5000,10000</Extent>
    </Layer>
  </Layer>

and that confuses me a bit.

Same thing with Extent. Here's what the standard says:

--8<--
Extent declarations are inherited from parent Layers. Any Extent
declarations in the child with the same name attribute as one
inherited from the parent replaces the value declared by the parent. A
Layer shall not declare an Extent unless a Dimension with the same
name has been declared or inherited earlier in the Capabilities XML.
--8<--

Which I take to mean that either the layer itself has to define the
named dimension the Extent uses, or it must have been defined by any
of the layer's ancestors. But again, the example includes a layer that
contradicts this:

<Layer opaque="1" noSubsets="1" fixedWidth="512" fixedHeight="256">
  <Name>ozone_image</Name>
  <Title>Global ozone distribution (1992)</Title>
  <LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90"/>
  <Extent name="time" default="1992">1992</Extent>
</Layer>

There is a parent layer, but that does not define any dimensions. The
dimension is defined by its sibling, however. But, the way I
understand the standard, this isn't good enough, and my patch will
simply ignore the extent for this layer. 

I do think it's odd that the sample capabilities document violates the
standard, though, so I'm a little bit confused. v1.1.0 was a lot
vaguer on this subject, and the v1.1.0 sample document is practically
identical to the v1.1.1 document. My best guess is that they decided
to clarify this issue in v1.1.1, and didn't check if this affected the
sample document.

As <Dimension> and <Extent> was merged in v1.3.0, none of these issues
are relevant for that version. 

-- 
Trond Michelsen

From roselinda.ackermans at ec.europa.eu  Fri Jun 26 05:04:36 2009
From: roselinda.ackermans at ec.europa.eu (Linde Ackermans)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] mapfish print control no longer working with
 2.8-rc6
In-Reply-To: <1245663207721-3131932.post@n2.nabble.com>
References: <1245663207721-3131932.post@n2.nabble.com>
Message-ID: <1246007076899-3160463.post@n2.nabble.com>


MapFish trunk version solves the problem.


Linde Ackermans wrote:
> 
> Hi,
> 
> The mapfish print control results in this err when using <script
> src="http://openlayers.org/api/2.8-rc6/OpenLayers.js"></script> :
> 
> geometry.distanceTo is not a function     ( OpenLayers.js line 1452 )
> 
> It functions OK with the 2.7 release.
> 
> best regards,
> linde ackermans
> 
> 

-- 
View this message in context: http://n2.nabble.com/mapfish-print-control-no-longer-working-with-2.8-rc6-tp3131932p3160463.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From roselinda.ackermans at ec.europa.eu  Fri Jun 26 05:06:20 2009
From: roselinda.ackermans at ec.europa.eu (Linde Ackermans)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] mapfish print control no longer working with
 2.8-rc6
In-Reply-To: <1245663207721-3131932.post@n2.nabble.com>
References: <1245663207721-3131932.post@n2.nabble.com>
Message-ID: <1246007180131-3160469.post@n2.nabble.com>


MapFish trunk version solves the problem.


Linde Ackermans wrote:
> 
> Hi,
> 
> The mapfish print control results in this err when using <script
> src="http://openlayers.org/api/2.8-rc6/OpenLayers.js"></script> :
> 
> geometry.distanceTo is not a function     ( OpenLayers.js line 1452 )
> 
> It functions OK with the 2.7 release.
> 
> best regards,
> linde ackermans
> 
> 

-- 
View this message in context: http://n2.nabble.com/mapfish-print-control-no-longer-working-with-2.8-rc6-tp3131932p3160469.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From sam_mor at y7mail.com  Sun Jun 28 05:52:21 2009
From: sam_mor at y7mail.com (Sam Mor)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] InfoWindow
In-Reply-To: <4A43C1F4.5030606@opengeo.org>
References: <66390.51090.qm@web44701.mail.sp1.yahoo.com>
	<4A43C1F4.5030606@opengeo.org>
Message-ID: <176417.91060.qm@web44714.mail.sp1.yahoo.com>




thanks Guys


Cheers

----- Original Message ----
From: Tim Schaub <tschaub@opengeo.org>
To: dev@openlayers.org
Sent: Friday, 26 June, 2009 4:29:08 AM
Subject: Re: [OpenLayers-Dev] InfoWindow

Hey-

Sam Mor wrote:
> Hi Guys
> We Would like to ask you a question:
> do you have InfoWindow or infobox ( it's what google call it) ?
> when u use openInfoWindow it display a box with information on the map
> 

OpenLayers.Popup (and subclasses) provide a ui element that displays 
whatever content you like and is (or can be) anchored to a particular 
location on the map.

> 
> if yes , please provide us with example or ...
> 

http://openlayers.org/dev/examples/select-feature-openpopup.html

The content for the popup is up to you to generate.

For an example where some information related to map features is 
requested from the server, see the following:

http://openlayers.org/dev/examples/getfeatureinfo-control.html

The returned content could be used in a popup.

Tim

> thanks
> Regards
> Sam
> 
> 
> 
>? ? ? Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
> Show me how: http://au.mobile.yahoo.com/mail
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev



      Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail

From ashore3 at verizon.net  Sun Jun 28 10:46:27 2009
From: ashore3 at verizon.net (Arnie Shore)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Local Tiles Storage - Example?
In-Reply-To: <176417.91060.qm@web44714.mail.sp1.yahoo.com>
References: <66390.51090.qm@web44701.mail.sp1.yahoo.com>
	<4A43C1F4.5030606@opengeo.org>
	<176417.91060.qm@web44714.mail.sp1.yahoo.com>
Message-ID: <4A478243.8060107@verizon.net>

Folks, still very much a newb here:  I wonder if anyone cd point me at 
scripts exemplifying OL accessing/using locally stored (same server) 
tiles?  Thanks, all.



From ekkehart at gmx.de  Sun Jun 28 17:39:24 2009
From: ekkehart at gmx.de (Nop)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Map broken by openlayers update?
Message-ID: <4A47E30C.5060806@gmx.de>


Hi!

My openlayers-based map has disappeared since friday. A user has 
suggested that there was an update to openlayers.js which I am using.

Was there such an update on friday?

What can be the reason if the map was working properly and now is 
showing only a blank canvas and does not even attempt to load tiles?

The address is topo.geofabrik.de.

Any ideas on how to fix this?


thanks
	Nop

From grand.edgemaster at gmail.com  Sun Jun 28 18:19:02 2009
From: grand.edgemaster at gmail.com (Thomas Wood)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Map broken by openlayers update?
In-Reply-To: <4A47E30C.5060806@gmx.de>
References: <4A47E30C.5060806@gmx.de>
Message-ID: <1e14d5320906281519u618476cftc39ef5fa3ef649b1@mail.gmail.com>

The OSM.org provided OpenStreetMap.js has changed. You need to add
/${z}/${x}/${y}.png to the end of your URL parameters in your custom
layer definition.

2009/6/28 Nop <ekkehart@gmx.de>:
>
> Hi!
>
> My openlayers-based map has disappeared since friday. A user has
> suggested that there was an update to openlayers.js which I am using.
>
> Was there such an update on friday?
>
> What can be the reason if the map was working properly and now is
> showing only a blank canvas and does not even attempt to load tiles?
>
> The address is topo.geofabrik.de.
>
> Any ideas on how to fix this?
>
>
> thanks
> ? ? ? ?Nop
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Regards,
Thomas Wood
(Edgemaster)

From trondmm-openlayers at crusaders.no  Tue Jun 30 11:12:55 2009
From: trondmm-openlayers at crusaders.no (Trond Michelsen)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Complete parsing of WMS 1.1.1 GetCapabilities
	document
Message-ID: <20090630151255.GG5552@crusaders.no>

Hi.

I just opened a ticket with a patch that adds parsing of (practically)
all remaining tags of the WMS GetCapabilities document.

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

Tests are included.

I've ignored <VendorSpecificCapabilities>, and I haven't made any
effort to handle <DCPType> properly. Other than that, I think it
should be complete.

As this patch also incorporates everything from ticket 2151, I've
closed that as duplicate.

Please review.

-- 
Trond Michelsen

From ehsan85 at yahoo.com  Tue Jun 30 20:47:07 2009
From: ehsan85 at yahoo.com (ehsan)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev]  Openlayers with Mapguide
Message-ID: <1246409227994-3186274.post@n2.nabble.com>


Hi, i need help on getting started openlayer with mapguide..?any link that i
can use to learn...i'm still new with mapguide and OpenLayer..

i just download the OpenLayers-2.8 and sheboygan.php from the code sample at
https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php
https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php 

i try to change map layer defination from the sheboygan.php code, but the
layer does not appear, it just came out with pink layer...any body help..?

Thanks,

ehsan.
-- 
View this message in context: http://n2.nabble.com/Openlayers-with-Mapguide-tp3186274p3186274.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.


From zac.spitzer at gmail.com  Tue Jun 30 23:35:04 2009
From: zac.spitzer at gmail.com (Zac Spitzer)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Openlayers with Mapguide
In-Reply-To: <1246409227994-3186274.post@n2.nabble.com>
References: <1246409227994-3186274.post@n2.nabble.com>
Message-ID: <7a85053e0906302035p175cae4bw6ab6a6855b05abe3@mail.gmail.com>

You need to dive in and find out what the the error was...

Which version of mapguide are you using?
What did the mapguide server error log say?

try right clicking on a pink tile and view the image

z

On Wed, Jul 1, 2009 at 10:47 AM, ehsan<ehsan85@yahoo.com> wrote:
>
> Hi, i need help on getting started openlayer with mapguide..?any link that i
> can use to learn...i'm still new with mapguide and OpenLayer..
>
> i just download the OpenLayers-2.8 and sheboygan.php from the code sample at
> https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php
> https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php
>
> i try to change map layer defination from the sheboygan.php code, but the
> layer does not appear, it just came out with pink layer...any body help..?
>
> Thanks,
>
> ehsan.
> --
> View this message in context: http://n2.nabble.com/Openlayers-with-Mapguide-tp3186274p3186274.html
> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



-- 
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168

From ehsan85 at yahoo.com  Tue Jun 30 23:58:22 2009
From: ehsan85 at yahoo.com (ehsan)
Date: Wed Sep  1 17:24:17 2010
Subject: [OpenLayers-Dev] Openlayers with Mapguide
In-Reply-To: <7a85053e0906302035p175cae4bw6ab6a6855b05abe3@mail.gmail.com>
References: <1246409227994-3186274.post@n2.nabble.com>
	<7a85053e0906302035p175cae4bw6ab6a6855b05abe3@mail.gmail.com>
Message-ID: <1246420702431-3186965.post@n2.nabble.com>


I'm using the mapguide 2.0,
for the pink image layer (the layer does not show),i use the tiled map
when i right click and view the image it's show:
Index is out of range.
Exception occurred in method MgMapBase.GetFiniteDisplayScaleAt at line 283
in file
d:\build\mapguide_open_source_v2.0\build_30.11\mgdev\common\platformbase\MapLayer/MapBase.cpp


zspitzer wrote:
> 
> You need to dive in and find out what the the error was...
> 
> Which version of mapguide are you using?
> What did the mapguide server error log say?
> 
> try right clicking on a pink tile and view the image
> 
> z
> 
> On Wed, Jul 1, 2009 at 10:47 AM, ehsan<ehsan85@yahoo.com> wrote:
>>
>> Hi, i need help on getting started openlayer with mapguide..?any link
>> that i
>> can use to learn...i'm still new with mapguide and OpenLayer..
>>
>> i just download the OpenLayers-2.8 and sheboygan.php from the code sample
>> at
>> https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php
>> https://trac.osgeo.org/mapguide/attachment/wiki/CodeSamples/JavaScript/OpenlayersExample/sheboygan.php
>>
>> i try to change map layer defination from the sheboygan.php code, but the
>> layer does not appear, it just came out with pink layer...any body
>> help..?
>>
>> Thanks,
>>
>> ehsan.
>> --
>> View this message in context:
>> http://n2.nabble.com/Openlayers-with-Mapguide-tp3186274p3186274.html
>> Sent from the OpenLayers Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
> 
> 
> 
> -- 
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
> 
> 

-- 
View this message in context: http://n2.nabble.com/Openlayers-with-Mapguide-tp3186274p3186965.html
Sent from the OpenLayers Dev mailing list archive at Nabble.com.