On Monday, August 16, 2010, christopher.schm...@nokia.com wrote:
On Aug 16, 2010, at 4:00 AM, ext Andreas Hocevar wrote:
Hi,
I stand corrected, at least in part:
On Aug 16, 2010, at 09:37 , Andreas Hocevar wrote:
I am still not sure that
doing this in the renderer rather than in
On 8/19/10 8:34 PM, Phil Scadden wrote:
My comment here was meant to say that I would not be in favor of any
change that made it so the distance between (-170, 0) and (170, 0) was
20 (by default).
Currently, our geometries don't know anything about coordinate reference
systems.
So, yes, the
On Aug 18, 2010, at 23:25 , Phil Scadden wrote:
Please don't try to bake in any assumptions about heading in a line
segment. Our geometry model is based on coordinates on a plane. My
opinion is that crossing the dateline is application logic.
So when I try to draw say a zoom rectangle
On 8/18/10 3:25 PM, Phil Scadden wrote:
Please don't try to bake in any assumptions about heading in a line
segment. Our geometry model is based on coordinates on a plane. My
opinion is that crossing the dateline is application logic.
My comment here was meant to say that I would not be in
Using the geodesic measuring algorithm, this also works already.
Not for area.
Here you could use the sketch handlers after applying my patch, and
then split the polygon at the maxExtent bounds (patches for polygon
splitting welcome :-) ).
Andreas, the code does work but only after
My comment here was meant to say that I would not be in favor of any
change that made it so the distance between (-170, 0) and (170, 0) was
20 (by default).
Am I not correct though in assuming that current geometric model assumes
by default that the angular distance is 340? I am contending
On 8/17/10 7:14 PM, Phil Scadden wrote:
How do you know that the line (179 0, -179 0) is meant to cross the date
line?
You cant as far as I know. And how would you unambiguously specify it?
Please don't try to bake in any assumptions about heading in a line
segment. Our geometry model is
Tim, apologies for the tone of earlier email. I am finding this a
frustrating exercise and believe me, openlayers is best javascript
client I can find. I really appreciate your efforts with this one. The
alternative for us is arc web mapping and I've gone grey making it work.
For the problem
How do you know that the line (179 0, -179 0) is meant to cross the date line?
You cant as far as I know. And how would you unambiguously specify it?
We generally store everything in arcSDE in WGS84 lat/long and depend on
client mapping to sort it out. When you have no unambiguous way of
How do you know that the line (179 0, -179 0) is meant to cross the date
line? It could as well be a line that spans almost all of the globe. I don't
think the coordinates should be ambiguous, so the line that is meant to cross
the date line should have the coordinates that exceed the
Hey Phil,
thanks for your efforts on this! The reason why I recommended to just use the
maxExtent is because for OpenLayers 3.0, we are planning a Location object that
will replace LonLat and Geometry.Point, which will be aware of projections. So
any efforts in that direction done now won't
Worked part of today on the renderer. It seems to me that:
var IDL = (this.extent.right this.map.maxExtent.right);
is a very simple indicator of whether there is an IDL problem to deal with.
this.extent extends the projection coordinates over the 180 line rather
than going to
Okay, I have worked away at doing this in the renderer (drawfeature). I
have hit another problem with this approach. Suppose you have 180 line
down the middle. Draw an object on the right hand side.
geometry.getBounds returns bounds in terms of negative no. (the
underlying longs are negative
13 matches
Mail list logo
