[OpenLayers-Dev] GeoWebCache layer

[Bart van den Eijnden]

Hi list, especially Tim,

what is the status of the GeoWebCache layer (from Tim's gwc sandbox)? Is it almost ready for trunk?

http://dev.openlayers.org/sandbox/tschaub/gwc/lib/OpenLayers/Layer/GeoWebCache.js

Best regards,
Bart
--
Looking for flexible support on OpenLayers or GeoExt? Please check out http://www.osgis.nl/support.html

Bart van den Eijnden
OSGIS
***@osgis.nl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100812/3f8047e3/attachment.html

[Phil Scadden]

Following on from Piero's regularpolygon code for drawing across the 180
line, I have modified path.js and
polygon.js to manage this feat as well. (ATTACHED FILES) My code is
somewhat simpler. The basic idea is that if the right margin of the map
have coordinates that are less the left margin of the map, then you have
a 180 degree line hassle somewhere in there, and the lat/lon returns
need to be modified. So far so good. This let me use say distance and
area tools on google maps which include the 180. I still havent mastered
the box drawing so you can zoom in on an area that includes the 180
lines somewhere in it.

However, the code is not general. The properties (repeated unnessarily
in both classes) are for google projection only. Calculating these for
using the map projection is straightforward so can improve that but
where should these properties reside? It seems to me from structure of
openlayers, that they should be map properties but I am somewhat
reluctant to add to this. Advice from developers please. I would like to
get this working (including for box) and submitted as a patch.
--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph [phone], fax [phone]

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Polygon.js
Type: application/x-javascript
Size: 5231 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100813/85fde024/Polygon.js
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Path.js
Type: application/x-javascript
Size: 10310 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20100813/85fde024/Path.js

[Andreas Hocevar]

Hi Phil,

I took a quick look at the path that Piero and you took. The problem I see with this approach is that you take the coordinates from Map.getLonLatFromPixel (which are already fixed to repsect the date line), and make them invalid again (i.e. putting the x value outside the projection's maxExtent.

The place where dateline handling should be solved for vector features is in the vector renderers, probably in Renderer.drawFeature. There you should check if the currently visible extent crosses the date line, and process x coordinates of the geometries that are about to be drawn - just like you do now in the handlers.

I don't think you need to store LIMIT and GLOBE_LON anywhere. You can use the maxExtent, just like all the other date line wrapping code does (see e.g. Layer.getLonLatFromViewPortPx).

I hope this helps a bit. Thanks for your efforts to make features work that cross the date line.

Regards,
Andreas.

Post by Phil Scadden
Following on from Piero's regularpolygon code for drawing across the 180
line, I have modified path.js and
polygon.js to manage this feat as well. (ATTACHED FILES) My code is
somewhat simpler. The basic idea is that if the right margin of the map
have coordinates that are less the left margin of the map, then you have
a 180 degree line hassle somewhere in there, and the lat/lon returns
need to be modified. So far so good. This let me use say distance and
area tools on google maps which include the 180. I still havent mastered
the box drawing so you can zoom in on an area that includes the 180
lines somewhere in it.
However, the code is not general. The properties (repeated unnessarily
in both classes) are for google projection only. Calculating these for
using the map projection is straightforward so can improve that but
where should these properties reside? It seems to me from structure of
openlayers, that they should be map properties but I am somewhat
reluctant to add to this. Advice from developers please. I would like to
get this working (including for box) and submitted as a patch.
--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph [phone], fax [phone]
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.
<Polygon.js><Path.js>_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Phil Scadden]

Post by Andreas Hocevar
The place where dateline handling should be solved for vector features is in the vector renderers, probably in Renderer.drawFeature. There you should check if the currently visible extent crosses the date line, and process x coordinates of the geometries that are about to be drawn - just like you do now in the handlers.

Okay, I have looked further into this.

At some point, the geometry has to be adjusted so it draws properly. The
world coordinates arent converted to screen coordinate until down into
the SVG layer. It would seem that this is an inappropriate place to deal
with the 180 because it is renderer dependent.

Better would seem to be in drawGeometry in Elements.js because then can
fix once for a range of different geometries. A side effect would be
that adjusted geometry is being fed to the indexer, what that does.
Slightly further up would be in drawFeature of Renderer.js. One
possibility here would be that if geometry needs adjustment, then we can
clone features.geometry, adjust the clone and pass that to drawGeometry
leaving the original geometry untouched. I am not sure that is as
efficient as fixing the geometry just first time it is rendered.

For the moment, I am looking at fiddling the 180 in drawFeature and
hoping that doesnt impact the indexer.

[Phil Scadden]

Got another question here. I dont think you can use maxextent to get the
required correction to apply since a user may change it. I also notice
that the logic used seems to apply to rectilinear projections - it
wouldnt be accurate for say conic projections. It seems that accurate
way to transform geometry crossing the 180 is unproject to pixel then
reproject again but without 180 corrections.

[Andreas Hocevar]

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 live long. For now, if you use wrapDateLine: true, you just should use the maxExtent of the whole world. If you want to restrict where the user can pan to, configure restrictedExtent on the map.

Regards,
Andreas.

Post by Phil Scadden
Got another question here. I dont think you can use maxextent to get the
required correction to apply since a user may change it. I also notice
that the logic used seems to apply to rectilinear projections - it
wouldnt be accurate for say conic projections. It seems that accurate
way to transform geometry crossing the 180 is unproject to pixel then
reproject again but without 180 corrections.
--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph [phone], fax [phone]
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Phil Scadden]

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 going into the projection). However the
extent of the viewport, (used in if
(!bounds.intersectsBounds(this.extent)) ) has the right hand side in
positive coordinates. The net result is that nothing is visible until
you add a point on the left hand side of the date line and suddenly all
is visible.

Now - should I fix intersectBounds to handle a much more complicated
case and then get bounds in same coord. Or should I convert the bounds
to consistant coordinates first (my choice)? I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing. I also have to modify the measure controls which dont
handle coordinates jumping from positive to negative and back very well.

[Andreas Hocevar]

Hi,

Post by Phil Scadden
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 going into the projection). However the
extent of the viewport, (used in if
(!bounds.intersectsBounds(this.extent)) ) has the right hand side in
positive coordinates. The net result is that nothing is visible until
you add a point on the left hand side of the date line and suddenly all
is visible.
Now - should I fix intersectBounds to handle a much more complicated
case and then get bounds in same coord.

The part of drawFeature that determines whether features should be drawn or not according to intersectBounds will have to be rewritten anyway, because it keeps point features at the edge of the viewport from being drawn if their center is outside the viewport.

Post by Phil Scadden
Or should I convert the bounds
to consistant coordinates first (my choice)?

Sounds good.

Post by Phil Scadden
I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing.

I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent.

Post by Phil Scadden
I also have to modify the measure controls which dont
handle coordinates jumping from positive to negative and back very well.

In Spherical Mercator, you get this for free if you configure the measure controls with geodesic: true.

Regards,
Andreas.

Post by Phil Scadden
--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph [phone], fax [phone]
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Andreas Hocevar]

Hi,

Post by Andreas Hocevar

Post by Phil Scadden
I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing.

I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent.

I just asked Andrea Aime from GeoServer how GeoServer handles features that cross the date line. So if you store a feature with coordinates like -181 0, -179 0, GeoServer will accept that by default (but not in cite testing mode). And it will also return coordinates like this as stored, i.e. not as 179 0, -179 0.

I do not know how other WFS implementations, or MapFish, or FeatureSever handle this.

Regards,
Andreas.

[Andreas Hocevar]

Hi,

to save you efforts in persuing your original attempt to modify the sketch handlers, I have created http://trac.openlayers.org/ticket/2787 with a patch.

This does not solve all vector layer and date line issues though. If you play with the spherical-mercator example after applying my patch, you will see that features crossing the date line can turn invisible when zoomed out and the map extent changes.

Regards,
Andreas.

Post by Andreas Hocevar
Hi,

Post by Andreas Hocevar

Post by Phil Scadden
I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing.

I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent.

I just asked Andrea Aime from GeoServer how GeoServer handles features that cross the date line. So if you store a feature with coordinates like -181 0, -179 0, GeoServer will accept that by default (but not in cite testing mode). And it will also return coordinates like this as stored, i.e. not as 179 0, -179 0.
I do not know how other WFS implementations, or MapFish, or FeatureSever handle this.
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Phil Scadden]

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 negative numbers.

Changing feature.geometry in renderer works pretty well. Only zoombox
continues to do the wrong thing because the pixel to latlon creates
negative numbers. Easily fixed. However, this still modifies the values
of the feature.geometry rather than a clone because various other parts
of the system (the handlers) independently modify the geometry so
modifying a clone doesnt work.(rubberbanding stops working). I have
little idea what effect that would have on other parts of openlayers.
The critical thing will be for a polygon created for the purposes of
selecting features through WFS but havent tested this yet. Geoserver
handling of the 180 line is in a version that is giving us a problem
with arcsde.

Will do more work on this tomorrow hopefully.

geodesic true fixes the distance calculation for measure control but
area isnt working. I have yet to investigate why.





Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

[Andreas Hocevar]

After doing more investigation, there is one thing I am concerned about with the renderer approach:

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 world bounds. This is not cite compliant, but works with GeoServer and, as I hear from Chris, also with FeatureServer.

So a possible plan of attack would be two-fold:
* Use my patch for http://trac.openlayers.org/ticket/2787. Now the above line geometry will either be (179 0, 181 0) or (-179 0, -181 0).
* Continue your renderer work, but do not convert (179 0, -179 0) to a geometry that crosses the date line.

Regards,
Andreas.

Post by Phil Scadden
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 negative numbers.
Changing feature.geometry in renderer works pretty well. Only zoombox
continues to do the wrong thing because the pixel to latlon creates
negative numbers. Easily fixed. However, this still modifies the values
of the feature.geometry rather than a clone because various other parts
of the system (the handlers) independently modify the geometry so
modifying a clone doesnt work.(rubberbanding stops working). I have
little idea what effect that would have on other parts of openlayers.
The critical thing will be for a polygon created for the purposes of
selecting features through WFS but havent tested this yet. Geoserver
handling of the 180 line is in a version that is giving us a problem
with arcsde.
Will do more work on this tomorrow hopefully.
geodesic true fixes the distance calculation for measure control but
area isnt working. I have yet to investigate why.
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Phil Scadden]

Post by Andreas Hocevar
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
specify which way the line goes, the obvious convention is take the
shortest distance. ship track/air track are overwhelming source of data
in this catagory while I cant really think of a mapping application
where you would want 179,0, -179,0 to be circle the globe.

[Tim Schaub]

Post by Phil Scadden

Post by Andreas Hocevar
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 based on coordinates on a plane. My
opinion is that "crossing the dateline" is application logic.
Geometries should be split when the user tries to draw beyond the domain
of the coordinate system.

Post by Phil Scadden
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
specify which way the line goes, the obvious convention is take the
shortest distance. ship track/air track are overwhelming source of data
in this catagory while I cant really think of a mapping application
where you would want 179,0, -179,0 to be circle the globe.

[Phil Scadden]

Post by Tim Schaub
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 across the date line, or
measure a distance between two points which happen to be on opposite
sides of the dateline, how do I put that logic in my application to cope
with this without altering OL? Or draw a selection polygon to choose
some data in a WFS layer? This is where problems occurs. The reason for
looking at the renderer approach is that there remain problems with just
doing it in the handlers. Obviously its pointless for me to continue
work on renderer model if it wont be accepted into OL, so I'll the study
the remaining issues with the handlers in Andreas's patch today. But I
dont believe there is a solution to the problem without altering OL.

Post by Tim Schaub
Geometries should be split when the user tries to draw beyond the domain
of the coordinate system.

Well to be honest I am sick to death of geometry models based on a plane
when we live on a spherical earth, and its especially a pain when you
live close to the 180 lines and nightmare if you are working near the
pole. I would really like to see OL get onto a sphere. There is dearth
of tools for working on a sphere. Our inhouse software always manages it
because its taken into account from day 1 but reengineering flat earth
software to work with real world geometry is a mega pain. Would you be
so keen on applications having to split geometry if you lived on the 180
line?

[Andreas Hocevar]

Post by Phil Scadden

Post by Tim Schaub
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 across the date line,

You mean using the ZoomBox control? This works fine. Try it out in our spherical-mercator.html example.

Post by Phil Scadden
or
measure a distance between two points which happen to be on opposite
sides of the dateline,

Using the geodesic measuring algorithm, this also works already.

Post by Phil Scadden
how do I put that logic in my application to cope
with this without altering OL? Or draw a selection polygon to choose
some data in a WFS layer?

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 :-) ).

Post by Phil Scadden
This is where problems occurs. The reason for
looking at the renderer approach is that there remain problems with just
doing it in the handlers.

You may want to try the SVG2 renderer I am currently working on. There is a chance that it works with geometries that exceed the world bounds (like the ones you get from my patched sketch handlers when drawing over the date line with sciteCompliant set to false). The new renderer development is an ongoing process and can be found in this sandbox: http://svn.openlayers.org/sandbox/ahocevar/renderer-ng

Regards,
Andreas.

Post by Phil Scadden
Obviously its pointless for me to continue
work on renderer model if it wont be accepted into OL, so I'll the study
the remaining issues with the handlers in Andreas's patch today. But I
dont believe there is a solution to the problem without altering OL.

Post by Tim Schaub
Geometries should be split when the user tries to draw beyond the domain
of the coordinate system.

Well to be honest I am sick to death of geometry models based on a plane
when we live on a spherical earth, and its especially a pain when you
live close to the 180 lines and nightmare if you are working near the
pole. I would really like to see OL get onto a sphere. There is dearth
of tools for working on a sphere. Our inhouse software always manages it
because its taken into account from day 1 but reengineering flat earth
software to work with real world geometry is a mega pain. Would you be
so keen on applications having to split geometry if you lived on the 180
line?
--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph [phone], fax [phone]
Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Phil Scadden]

Post by Andreas Hocevar
Using the geodesic measuring algorithm, this also works already.

Not for area.

Post by Andreas Hocevar
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 applying your patches. There
was no way for application to "solve" the problem by splitting geometry
without them. Also the patch is making an assumption about 179 0, -179
0. If extent is across dateline, then the joining line you would make
with say the path handler crosses the dateline, rather than going around
the world (which is what it used to do).

Post by Andreas Hocevar
You may want to try the SVG2 renderer I am currently working on. There is a chance that it works with geometries that exceed the world bounds (like the ones you get from my patched sketch handlers when drawing over the date line with sciteCompliant set to false). The new renderer development is an ongoing process and can be found in this sandbox: http://svn.openlayers.org/sandbox/ahocevar/renderer-ng

I would also need to put same logic into canvas.js. However, this must
make assumptions on line directions for 179 0, -179 0 if you are doing
this at this level. For the moment, I am working with your patches and
seeing what are the unresolved issues. I had next to no time on this
over last few days but should be able to get back to it this afternoon.

[Tim Schaub]

Post by Phil Scadden

Post by Tim Schaub
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 favor of any
change that made it so the distance between (-170, 0) and (170, 0) was
20 (by default).

Post by Phil Scadden
So when I try to draw say a zoom rectangle across the date line, or
measure a distance between two points which happen to be on opposite
sides of the dateline, how do I put that logic in my application to cope
with this without altering OL? Or draw a selection polygon to choose
some data in a WFS layer? This is where problems occurs. The reason for
looking at the renderer approach is that there remain problems with just
doing it in the handlers. Obviously its pointless for me to continue
work on renderer model if it wont be accepted into OL, so I'll the study
the remaining issues with the handlers in Andreas's patch today. But I
dont believe there is a solution to the problem without altering OL.

Post by Tim Schaub
Geometries should be split when the user tries to draw beyond the domain
of the coordinate system.

Well to be honest I am sick to death of geometry models based on a plane
when we live on a spherical earth, and its especially a pain when you
live close to the 180 lines and nightmare if you are working near the
pole. I would really like to see OL get onto a sphere. There is dearth
of tools for working on a sphere. Our inhouse software always manages it
because its taken into account from day 1 but reengineering flat earth
software to work with real world geometry is a mega pain. Would you be
so keen on applications having to split geometry if you lived on the 180
line?

I understand the frustration. If you can get involved in (or have
suggestions for) OpenLayers 3.0 with regard to a different geometry
model (or changes at some other level), that would be great.

Tim

[Phil Scadden]

Post by Tim Schaub
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 that this
is a very poor default because I cannot think of a real world line
structure where this is likely to be the correct way to construct the line.

Post by Tim Schaub
I understand the frustration. If you can get involved in (or have
suggestions for) OpenLayers 3.0 with regard to a different geometry
model (or changes at some other level), that would be great.

Well the question of the how a line represented by only two points 170
0, -170 0 is surely key. It is inherently ambiguous so some convention
must be applied. Inhouse we use shortest angular difference. In
principle, rendering on the sphere means operating in angles but
pragmatically projected coordinates can often be used. I dont like
coordinates where abs(lon) > 180 but can the projection system be
confident that servers will not supply this? I think OL can be
re-engineered to do this in several way without a rewrite into angular
geometry which I agree would be slow. There is generally only a problem
when
a/ ESPG indicates that OL is dealing with an earth projection (a not say
a building map or drawing schematic).
b/ the 180 line is within the viewport. (which is automatically the case
when either pole in within the viewport.

Detection of this need only happen when extent or projection changes and
a variable "IDL in viewport" true/false can be set in the map object.

When IDL in viewport, then special handing is required in a number of
places and it would be good to have utility routines to make the
programming reasonably uniform. The issues as I see it ( and I dont know
enough to answer them).

1/ should extent be allowed to exceed to baselayer.maxextent? At moment,
this is a good way to detect the presence of 180 line. It would make an
extent of (170, -10, -170 10) (or strictly projected equivalent) legal.
I actually think this is bad idea. Extents should forced so right
exceeds left or maths gets way too messy. A property for extent of
includesIDL to indicate that coordinates being tested need to be
corrected for IDL prior to test.

2/ interaction with server. this applied to coordinates passed to WFS
spatial queries and any calls that would create geometry in the server.
Only geoserver, (and only in experimental config) as far as I know
handles IDL. ArcGIS server does okay provided projection has horizons
(ie not a whole earth projection).

3/ Location of IDL handling code for vector rendering. Is it high level
(eg in the handler at moment, but this doesnt deal with GML/KML/etc)? or
is it low level (eg elements or right down in the renderers). I
personally dont think you can deal with IDL on a per point basis,
ignoring the line relationship or you will get the issue of 170 0, -170
0 making life difficult. If map extent exceeded 180 degrees, then you
are surely left with having to check for shortest path? I'm inclined to
try a suck-and-see approach with lowest part of elements but
verification looks tricky. The problem with doing it in the renderer.js
is that you change geometry. This could be a problem if passed back to a
server.

[Tim Schaub]

Post by Phil Scadden

Post by Tim Schaub
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 distance between (-170, 0) and (170, 0) is 340. And this
is not an angular measure. And there are no units.

And, the distance between (-170000, 0) and (170000, 0) is 340000. And
these are perfectly valid geometries.

Again, in the future, geometry calculations may be smarter. I'm just
describing the way things are now.

Post by Phil Scadden
Am I not correct though in assuming that current geometric model assumes
by default that the angular distance is 340? I am contending that this
is a very poor default because I cannot think of a real world line
structure where this is likely to be the correct way to construct the line.

Post by Tim Schaub
I understand the frustration. If you can get involved in (or have
suggestions for) OpenLayers 3.0 with regard to a different geometry
model (or changes at some other level), that would be great.

Well the question of the how a line represented by only two points 170
0, -170 0 is surely key. It is inherently ambiguous so some convention
must be applied. Inhouse we use shortest angular difference. In
principle, rendering on the sphere means operating in angles but
pragmatically projected coordinates can often be used. I dont like
coordinates where abs(lon)> 180 but can the projection system be
confident that servers will not supply this? I think OL can be
re-engineered to do this in several way without a rewrite into angular
geometry which I agree would be slow. There is generally only a problem
when
a/ ESPG indicates that OL is dealing with an earth projection (a not say
a building map or drawing schematic).
b/ the 180 line is within the viewport. (which is automatically the case
when either pole in within the viewport.
Detection of this need only happen when extent or projection changes and
a variable "IDL in viewport" true/false can be set in the map object.
When IDL in viewport, then special handing is required in a number of
places and it would be good to have utility routines to make the
programming reasonably uniform. The issues as I see it ( and I dont know
enough to answer them).
1/ should extent be allowed to exceed to baselayer.maxextent? At moment,
this is a good way to detect the presence of 180 line. It would make an
extent of (170, -10, -170 10) (or strictly projected equivalent) legal.
I actually think this is bad idea. Extents should forced so right
exceeds left or maths gets way too messy. A property for extent of
includesIDL to indicate that coordinates being tested need to be
corrected for IDL prior to test.
2/ interaction with server. this applied to coordinates passed to WFS
spatial queries and any calls that would create geometry in the server.
Only geoserver, (and only in experimental config) as far as I know
handles IDL. ArcGIS server does okay provided projection has horizons
(ie not a whole earth projection).
3/ Location of IDL handling code for vector rendering. Is it high level
(eg in the handler at moment, but this doesnt deal with GML/KML/etc)? or
is it low level (eg elements or right down in the renderers). I
personally dont think you can deal with IDL on a per point basis,
ignoring the line relationship or you will get the issue of 170 0, -170
0 making life difficult. If map extent exceeded 180 degrees, then you
are surely left with having to check for shortest path? I'm inclined to
try a suck-and-see approach with lowest part of elements but
verification looks tricky. The problem with doing it in the renderer.js
is that you change geometry. This could be a problem if passed back to a
server.

[Phil Scadden]

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 of combining vector data across the 180 line with google
imagery, ESRI's response could be summarised as "bite your bum".

Post by Tim Schaub
Please don't try to bake in any assumptions about heading in a line
segment.

But surely you are already making an assumption on 179 0, -179 0 - to
draw it right around the globe? I cant think a of single application
where this would be correct. An assumption surely has be made some time
as a two point segment like this is inherently ambiguous on a globe. The
shortest path assumption might not be the most economical from a
programming points of view but is surely the one most likely to be correct?

[Phil Scadden]

Post by Andreas Hocevar
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 world bounds. This is not cite compliant, but works with GeoServer and, as I hear from Chris, also with FeatureServer.

Further to this, consider a ship track starting in LA and proceeding to
say Sydney. The track coordinates would start with negative longitude
for LA and for now, would change to positive coordinates when it crossed
the dateline. To resolve the ambiguity you cite, it would have to change
one or other set of coordinates to so that abs(lon) >180 for the
renderer approach to work. This is not how the data is traditionally
stored and while we still resort to using 0-360 longitude references to
overcome flat earth software, I look forward to the day when we dont. I
am still in favour of converting to shortest path.

There are two aspect to the problem. One is how vector geometry is
rendered given that OL cant really dictate the conventions of how
geometry will be presented when coming from a server. The second is how
geometry created in OL (by handlers in particular) will be presented
back to servers, eg as geometry for a spatial query or to create new
geometry on the server.

I havent had much time on this today, but I have briefly reconsidered
the option of doing the renderer type conversion but at the SVG level.
This avoids the problem that renderer actually changes the geometry, but
means it has to be implemented in every renderer. A utility function for
converting x,y to local coordinates (but checking for IDL issues) would
smooth this - canvas.js already has such function. It also means that if
you have 179 0, -179,0 line with IDL in the screen area, then it will
draw a line crossing the IDL. This doesnt bother me.

There is a need for a similar function to convert geometry created in OL
to compensate for IDL (converting say the bounds in zoombox).

[christopher.schmidt at nokia.com ()]

Post by Andreas Hocevar
Hi,

Post by Andreas Hocevar

Post by Phil Scadden
I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing.

I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent.

I just asked Andrea Aime from GeoServer how GeoServer handles features that cross the date line. So if you store a feature with coordinates like -181 0, -179 0, GeoServer will accept that by default (but not in cite testing mode). And it will also return coordinates like this as stored, i.e. not as 179 0, -179 0.
I do not know how other WFS implementations, or MapFish, or FeatureSever handle this.

FeatureServer returns exactly what you give it; it doesn't know
what a world is.

-- Chris

Post by Andreas Hocevar
Regards,
Andreas.
--
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.
_______________________________________________
Dev mailing list
http://openlayers.org/mailman/listinfo/dev

[Eric Lemoine]

Post by christopher.schmidt at nokia.com ()

Post by Andreas Hocevar
Hi,

Post by Andreas Hocevar

Post by Phil Scadden
I am still not sure that
doing this in the renderer rather than in path.js, polyon.js is the
right thing.

I am. Fixing this in the handlers won't help for features that cross the date line that come e.g. from a WFS, because there you will likely have coordinates that don't exceed the world extent.

I just asked Andrea Aime from GeoServer how GeoServer handles features that cross the date line. So if you store a feature with coordinates like -181 0, -179 0, GeoServer will accept that by default (but not in cite testing mode). And it will also return coordinates like this as stored, i.e. not as 179 0, -179 0.
I do not know how other WFS implementations, or MapFish, or FeatureSever handle this.

FeatureServer returns exactly what you give it; it doesn't know
what a world is.

Catching up on this thread... Same for MapFish.
--
Eric Lemoine

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

Tel : [phone]
Mail : ***@camptocamp.com
http://www.camptocamp.com