The map should fire a "resize" event when the provided container size changes.

Firefox does not display images without CORS headers that have the crossorigin attribute set. After b872b5a, when using the WebGL renderer, tiles still do not display and a Security Error ('This operation is insecure') is thrown in webglmaprenderer.js#L286.

Following #37, the WebGL shaders should be modified to have the same behaviour as the CSS-based filters used by the DOM.

https://github.com/twpayne/webglmaps/blob/master/src/webglmaps/tilequeue/priority.js

jsdoc doesn't like empty descriptions, which is causing builds to fail.

Following 5c5a58a, white lines are visible between tiles when the transformation requires sub-pixel positioning of the elements. This is noticeable in:

• Firefox when using matrix() or matrix2d() (always, probably this bug)
• Chrome when using matrix() (always)
• Chrome when using matrix3d() (rarely)

Currently, tiles are added to the doc fragment when generated. They instead should be added to the renderer's target after loading and in an animation frame.

Hi,

Is it already possible to start a project which should be on line around May 2013 with ol3?

Thanks,

Nico

Currently, the DOM map renderer uses a transform for translating and rotating the layers pane. This same transform could be used to scale the layers pane when setting the resolution. This would change the logic in the TileLayer renderer a bit (it would only append new tiles and not scale existing ones).

Ticket #35 suggests adding a scale transform on resolution changes. After this, a css transition could be added for the transform. As far as I know, the transition would apply to the whole transform (translation, rotation, and scale) - so this may lead to undesired results.

http://davidwalsh.name/css-transform-rotate

demo: http://mapbox.com/demo/running/

When doing zoomToExtent,

OpenLayers move map center to new extent, and THEN do HTTP request to get the image.

Will it make sense to to instruct the map to HTTP load certain extent and when 'tileloaded' is fired, THEN load new WMS image and zoomToExtent() ?

Doing it this way will be more granular, as we decouple:

1. the centering of map
2. http request to fetch image.

Double tap to zoom does not prevent default and make the browser zooms in the page. Observed in iOS 6 Safari.

As of e700ed9, you cannot use alt-drag to rotate in the side-by-side example (at least in Chrome/OSX).

http://about.travis-ci.org/docs/user/gui-and-headless-browsers/

Example use case: use the The Network Information API to adapt the size according to the connection type.

Currently, when an ol.tilegrid.TileGrid instance is created without configuring a tileSize, a tileSize instance with 256x256 is created. The ol.tilegrid::createForProjection factory function does not configure a tileSize.

Suggestion: no default in ol.tilegrid.TileGrid, and instead apply a default in the ol.tilegrid::createForProjection factory function.

We might want to discuss where to apply defaults in general. Convenience factory functions seem like a good place to me.

the Alt modifier is already used by the window manager. What about using Ctrl instead?

Test if setting context.imageSmoothingEnabled = false may speedup the image rendering.

spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing

perf test: http://jsperf.com/imagesmoothingenabled

On the iPad2 at least, there are severe flashes and misplaced tiles when using the DOM renderer. My guess is that this is due to the mix of CSS translate for the layer container and top/left style for the images. Indeed it looks like c120c03 is where the trouble begins.

It looks like a double-click on the zoom control will zoom in three times and recenter the map.

It seems like there's a very high bar to entry to getting this to work:

• java for the dev server
• python for generate-exports and the google closure tools
• ruby for git-update-ghpages.

Since the autocompilation of google closure bits seems to be pretty straightforward, maybe that bit could be dropped or replaced with something that doesn't require a jvm?

Dragging on iPad seems not very good. After some debugging I found that clientX is zero after every touchend event and I think it's main cause of this error. Problem is deeper in Closure Library. Do you have any ideas, how to fix it?

Currently, building the gh-pages target to update the GitHub pages is really slow because it clones the full ol3 repository. It can be made faster by first fetching from the existing local repo and then fetching from the gh-pages branch.

when roated the map
then using the shift+drag to select the zoom area
it zooms in but resets the rotation to 0

expected behaviour
zoom in to area and stay at current rotation

browser: chrome 25 windows
example: http://openlayers.github.com/ol3/master/examples/side-by-side.html

As reported by @elemoine in relation to 4ee411e:

In this example if I zoom in (with for example one click on the + button) and out (one click on the - button) the canvas tiles become invisible in the DOM map. Wondering if this is related to the tiles being shared between the two maps.

jsdoc fails to build the ol3 api doc on Travis. I've updated jsdoc to the latest master on my laptop, and I now get the same failure:

jsdoc/jsdoc -t doc/template -r src -d build/gh-pages/exports-files/apidoc
org.mozilla.javascript.EcmaError: TypeError: Cannot find function orderBy in object 
function () {...}.
        at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3785)
        at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3763)
        at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3791)
        at org.mozilla.javascript.ScriptRuntime.typeError2(ScriptRuntime.java:3810)
        at org.mozilla.javascript.ScriptRuntime.notFunctionError(ScriptRuntime.java:3881)
        at org.mozilla.javascript.ScriptRuntime.getPropFunctionAndThisHelper(ScriptRuntime.java:2360)
        at org.mozilla.javascript.ScriptRuntime.getPropFunctionAndThis(ScriptRuntime.java:2327)
        at org.mozilla.javascript.gen.file__home_elemoine_public_html_openlayers_ol3_doc_template_publish_js_32._c_anonymous_19(Unknown Source)
        at org.mozilla.javascript.gen.file__home_elemoine_public_html_openlayers_ol3_doc_template_publish_js_32.call(Unknown Source)
        at org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:86)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1._c_main_8(Unknown Source)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1.call(Unknown Source)
        at org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1._c_script_0(Unknown Source)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1.call(Unknown Source)
        at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:426)
        at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3178)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1.call(Unknown Source)
        at org.mozilla.javascript.gen._home_elemoine_public_html_openlayers_ol3_jsdoc_jsdoc_js_1.exec(Unknown Source)
        at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:654)
        at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:552)
        at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:507)
        at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:499)
        at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:215)
        at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:134)
        at org.mozilla.javascript.Context.call(Context.java:521)
        at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:535)
        at org.mozilla.javascript.tools.shell.Main.exec(Main.java:198)
        at org.mozilla.javascript.tools.shell.Main.main(Main.java:174)

In the side-by-side example, the mouse wheel doesn't work as expected when trying to zoom the map (instead the page scrolls and the map pans).

http://openlayers.github.com/ol3/master/examples/two-layers.html

Error message is:

Uncaught TypeError: Object #<M> has no method 'ob'

While zooming, the tilelayer renderer will only remove tiles from the dom that are outside of the rendered tile range for the rendered resolution. Tiles at alternate zoom levels remain in the dom until all the tiles at the target resolution have loaded. This is not a problem (visually) as long as these alt tiles are appropriately resized and repositioned. However, the resizing and repositioning only happens for tiles that intersect the rendered extent. This means that while zooming in, tiles at alt zoom levels that fall outside of the current extent can be incorrectly positioned and scaled.

The attribution control displays a small blue box in the lower-right corner of the map if the layer's source has no attribution. Instead, it should display nothing.

The XYZ source should accept a minZoom option.

I'l build api with command ./build/ol build
Then i'l try open hello-api.html demo in browser:
http://localhost/ol3/demo/hello-api.html

Then i saw the error in browser console:

$layers$$ is null
[Break On This Error]

... this.$map_$.$layers_$, $layerAttribution$$, $i$$76$$ = 0, $ii$$2$$ = $layers$$....

someone please undo my last push!!

trying to set up my dev environment at home and didn't expect to get so many changes

Currently the WebGL tile layer renderer uses goog.structs.PriorityQueue to prioritize texture uploads to the GPU.

It should use ol.TileQueue if possible, both to reduce code size and because the fundamental problem being solved is the same. This may require a review of the WebGL tile layer renderer code.

Tom and I have talked about the TileLayer/Renderer interface, which is currently a bit unclear and messy (the HTML renderer uses getTileForXYZ, while the WebGL uses getData).

Based on discussions with Tom, and Tim during the code sprint, the getTile way seems to be the way the go. We've also mentioned introducing the notion of TileMatrixSet (TilePyramid below).

Below is the list of types and interfaces we've come up with - comments welcome.

TileCoord
   z
   x
   y

TileBounds
   minX
   minY
   maxX (exclusive)
   maxY (exclusive)
   z
   contains(tileCoord) -> boolean
   overlaps(tileBounds) -> boolean
   touches(tileBounds) -> boolean
   isEmpty -> boolean
   include(tileCoord)

TileGrid
   id string
   origin Loc
   corner TOP_LEFT | BOTTOM_LEFT
   resolution number
   extent Bounds
   getTileCoord(Loc) -> tileCoord

TilePyramid
   projection Projection
   grids Array.<TileGrid>
   extent Bounds
   getResolutions -> Array.<number>
   getParents(tileCoord) -> Array.<TileCoord>
   getChildren(tileCoord) -> Bounds
   *getTileExtent(tileCoord) -> Bounds
   getTileBounds(Bounds, resolution) -> TileBounds

   (* find better name)

Tile
   tileCoord TileCoord
   url string

TileLayer
   tilePyramid
   extent Bounds
   getTile(tileCoord) -> Tile

iOS reports that it supports WebGL, but the map does not load and one gets a blank page.

With this issue I'm suggesting making our ol base classes inherit from goog.events.EventTarget.

This will bring a number of advantages:

• Our objects are directly observable, making it easier, and more natural, to dispatch events, and register listeners. For example, to register a tile load listener I think goog.events.listen(tile, 'load', listener) makes more sense than goog.events.listen(tile.getEvents(), 'load', listener).
• Our objects are disposable (EventTarget inherits from Disposable). This, in itself, brings some nice properties. Disposable objects can be connected together, so if one object is disposed of then the others get disposed of too. The Disposable class also provides a nice debugging feature, with undisposed objects being monitored when the ENABLE_MONITORING variable is set.

Inheriting from TargetEvent won't increase the build size, as the ol.event.Events class already uses it. Nor will it increase overhead and memory usage at runtime – the EventTarget and Disposable constructor don't set values on the instance.

Inheriting from EventTarget implies removing ol.event.Events, and replacing the sequence framework by something else. I've been experimenting with that, I'll open a separate issue for that.

Currently, the zoom control calls requestRenderFrame (in two places) immediately before asking the view to zoom. The view then calls requestRenderFrame (if currentResolution and opt_duration are defined) immediately before calling addPreRenderFunction. Then in addPreRenderFunction, requestRenderFrame is called again.

A similar thing happens in ol.interaction.KeyboardZoom where requestRenderFrame is called before asking the view to zoom. Also in this case, requestRenderFrame is called again by the view.

It is subtly different in ol.interaction.DragRotateAndZoom where requestRenderFrame is called before zoomToResolution. In this case, withFrozenRendering is called, which (surprise for me) fires rendering immediately (not waiting for an animation frame where available).

In these cases, it's very difficult to know if the developer is doing the right thing, if the library is doing the right thing, both, or neither.

If the idea is that requestRenderFrame is never the wrong thing to do (so it's ok to call it many times as in the case of the zoom control), then it raises the question of why it isn't always the right thing to do. And if it is always the right thing to do, then that suggests to me that it should be done at a lower level.

If calling requestRenderFrame is not always the right thing to do, then we should be able to state very clearly when not to call it.

An other issue can be seen with the zoom control: go to http://openlayers.github.com/ol3/master/examples/full-screen.html and press the zoom in button very fast: the center of the map is wrong.

I'm not sure if the title is accurate or not bit the idea is that it might be useful to allow the dynamic (user driven, or flight along a path) changes to the camera position and orientation. This might require server support to generate images or tiles based on the new camera position. So for example, given a camera change OL3 could initiate a request for a new image like it does today, but would include camera information. Obviously this needs to be supported on the server-side so some discussion with mapserver or geoserver teams might be needed. This was generated from the following email thread:

I can think of a couple of use cases that this might come in handy for:

1. one is the obvious one of something like Street View
2. another is being able to do a walk through or fly through the environment. This could be done via user controls like look right, left, up, down and move forward, backwards, right left. Or it could be done by creating a path or route through the scene and then flying the camera along the path. This might be a sequence of points in space where each point has attributes for the camera, like azimuth, elevation, camera angle, etc.

Hey Steven,

the purpose of adding camera and scene support to OpenLayers 3 is indeed 2.5D views for use cases like tilting and street views. The idea is to tilt 2D tiles and combine them with an elevation model or other height/elevation information that is associated with the tiles. But we will also be working on 3D vector rendering, in which case the 3D information is used directly from the geometries, and all rendering is done on the client.

It seems the use case that you are envisioning is to request tilted tiles from the server, i.e. to send requests for new tiles whenever the camera properties change, which will then get rendered on the server and returned to the client? Is this correct? If so, let's make sure it gets ticketed on http://github.com/openlayers/ol3, so it won't be forgotten.

Andreas.

On Mon, Dec 3, 2012 at 10:36 PM, Stephen Woodbridge [email protected] wrote:

Hi All,

Sorry for the cross posting. The following article which is thin on details raise some interesting questions in my mind related to Mapserver and OpenLayers.

http://www.zdnet.com/google-dives-deeper-on-vector-based-maps-with-api-update-7000008233/?s_cid=e550

I know OpenLayers 3 is looking at potentially adding camera model to support tilted views. Would this be a static definition to support tiling? Or would the camera be able to be dynamically changed? This seems a lot like Google Street View.

Has any thought been given to support for 2.5D or 3D features? Is there a need for this?

If mapserver supported rendering orthogonal views or even a camera view model them a guess a layer could be defined to pass that information to mapserver to render in the same.

Mapserver devs - there was some discussion about supporting 2.5D objections like buildings. In light of Google and Apple moving in these directions is this an area that we should be discussing for a future version. Should be be looking at a more flexible viewing model like a camera model as an option.

It looks like the OGC is working on this also, google "ogc web 3d service".

Seems like these questions should be discussed if they are not already being discussed.

Thanks,
-Steve

I'd be happy to contribute to ol3, but I'm unsure about what functions should be implemented and what the naming scheme will be.

For example, in ol2 there was a zoomToExtent function in the Map class. Say I want to implement this functionality for ol3, what would be the correct way to start? I guess just copying the ol2 names would not be beneficial. Is there any place where the future API is proposed or discussed?

See https://github.com/blog/1184-contributing-guidelines. (Thanks @tschaub for mentioning this.)

The built examples should be hosted on gh-pages.

When you zoom/pan with the canvas renderer, this means you see artifacts from the previously rendered frame (see 54327fb#L3R134).

To reproduce the issue, go to http://openlayers.github.com/ol3/master/examples/side-by-side.html and press m: the top tile has the data from the bottom one (south pole). Only with the webgl renderer.