mapillary / mapillary-js Goto Github PK
View Code? Open in Web Editor NEWInteractive, extendable street imagery map experiences in the browser, powered by WebGL
Home Page: https://mapillary.github.io/mapillary-js
License: MIT License
Interactive, extendable street imagery map experiences in the browser, powered by WebGL
Home Page: https://mapillary.github.io/mapillary-js
License: MIT License
Before disable animation starts and after button is clicked (this is the waiting time for initiating the background library).
Create functionality in state regarding motionless transitions and handle when showing image planes in GLUI.
Clean up documentation for 1.0 release my suggestion is.
1. Remove all classes except Viewer
2. Add the IViewerOptions Struct
When calling and subscribing to Navigator.moveDir
for a direction that is not represented among the edges for the current node the application crashes with the following error message:
Uncaught TypeError: Cannot read property 'subscribe' of null
The subscriber gets null back instead of an observable where the first item is null.
This happens everywhere where a direction is not represented, e.g. when moving in the STEP_LEFT
direction for the K0vg7We6gvg4xbN0ubve1g
node.
This is currently handled in the keyboard handler by checking if the direction actually exists before calling Navigator.moveDir
.
Keyboard navigation should handle all directions as well as panorama edges.
A suggestion and implemantaion
It would be great if we could start deciding what set of UIs should be enabled by default in mapillary-js
. Below is my take on what's essential for the initial version. Bear in mind that some of these could be disabled, with an option flag when initializing the viewer.
Current list of UI/features we should take into consideration:
320px
photo, sets it as a background cover above all the other UI elements in the viewer container. Displays a button which will activate other UIs and will start fetching data in the future (doesn't work yet)./or
endpoint for the given photo, displays rectangles with detected traffic signs on top of the viewer.mapillary-js
user can hook intomapillary-js
πProposition: I think, we should have a set of sane defaults for most uses. Let's start with the most important UIs: GlUI
and SimpleUI
. I would say that we should also have GlUI enabled by default, and SimpleUI should be its' fallback in case the system where mapillary-js
is displayed doesn't support WebGL. Next, DirectionsUI
should always be displayed, but we should provide means to toggle it. For the SimpleUI
, when no WebgGL has been detected, we fall back to SimpleNavUI
, since this viewer won't display panoramas. CoverUI
should be also enabled by default, since it prevents loading unnecessary data and handles the scenario when multiple viewers are within the one view. AttributionUI
is essential too as we want to give credit to the community (username links to the profile) and there is also a link to the photo on mapillary.com. We should display loading progress by default through LoadingUI
. SimpleCacheUI
should be enabled by default too, so we don't make unnecessary requests. EventUI
is a no brainer, we want everyone to be able to hook into the events without doing any extra work on their side.
Proposed essential UIs/features: GlUI
, CoverUI
, LoadingUI
, Directions
, SimpleCacheUI
- SimpleUI
would be used only after internal feature check.
Regarding optional UIs⦠KeyboardUI
is a tricky one, since the library consumer might have event handlers attached to keys already. I would say this should be enabled when specified. Last, SimplePlayUI
, this is a really cool feature, but I'm totally unsure whether it should be enabled by default? mly.Viewer.play()
is an appealing option, though.
WDYT?
When the latitude or longitude of the node that is to be set on state changes a lot the graph should be reset and the reference lat lon updated according to the new node.
The trajectory of the state needs to be handled, probably reset.
Also make sure to share as little as possible from object instances.
Not sure this is a bug, but Im running a screen thats on 30hz, this causes my animations to be half the speed of what you probably see them in.
Spatial lib is used in many places and needs to be instantiated on every place. Sine its keeping no state consider making all functions static.
If the navigator is loading it is possible to request the same node again causing immediate motionless transitions to the node once cached.
Fake tiles woul be generated on every /h
API request.
Unworthy nodes should be created at the edges of tiles. When navigating to the unworthy nodes the surrounding tiles should be fetched and the edges for the unworthy nodes should be recalculated.
Lets find some better sequences and also update js to the latest version
It should be possible to set the trajectory type, e.g. Linear and Spline, on the state.
Example pvuThYMsqOz1syYCXDaiHQ
, going real linked images will only take you that far.
However if there is a good amount of alternatives we might not wanna show sequence arrows.
Subscribe to state and fire movestart and moveend events appropriately.
The events should be based on the trajectory length, the current trajectory index and the alpha value.
I created a naive PlayerUI. However Im not sure how to handle the state API. The solution might be to remove passed nodes in the trajectory per default.
For easier debug only uglify sourcecode in production
Locally the Typescript compiler gives the following error when running gulp ts
:
TypeScript error: src/viewer/UIService.ts(59,35): Error TS2511: Cannot create an instance of the abstract class 'UI'.
This is not logged when running in CircleCI.
It is still possible to run the library in the browser.
The world motion azimuth angle is incorrect for perspective images which makes creating a UI based on these angles impossible. Fix the angle.
Create a passive state implementation with a method for changing alpha. This state will be used for functionality like dragging through sequences.
Input is sequences and images. Start image in a sequence and end image in a sequence. Also add images that could be annotated with text. Journey should make a shorter stop on these images.
Meshes does not exist for non merged nodes so the node should handle this when caching image and mesh.
Fix a CDN urls for various releases. Update README.md
to reflect that change
It seems to be slightly scewed towards NE.
After running with the UI concept for a while its pretty clear that we need a better place for rendering both for gl and DOM content. I suggest we create two renderers a GlRenderer and a DOMRender and instead of seeing the UIs as endpoints they will have access to a service where they can push data to render.
+----------------+
| |
| State Context |
| |
+-------.--------+
.
.
.
.
+-------.--------+
| |
| UI |
| |
+----------------+
-/ \--
--/ \--
--/ \--
-/ \--
+-------o-------+ +--------\-------+
| | | |
| DOMRenderer | | GlRenderer |
| | | |
+---------------+ +----------------+
The renderer will have a rx pipeline as input for the Renderers, using the AnimationFrame as scheduler for the GlRenderer is probably a good idea.
Right now the GLUI is hardcoded to a 4:3 aspect ratio. Enforcing the container to a 4:3 ratio can by done in CSS. This is not what we want though.
The GLRenderer and the WebGL handlers should be able to handle all aspect ratios, either through letterboxing or through filling the screen in the optimal way depending on image type, image orientation and current aspect ratio.
Preferably the letterbox/fill behaviour should be configurable.
We want to display objects located in images. There will be many sources of objects that we want to display. They do share some common attributes though.
I suggest the current construction of a new UI
+----------------+
| |
| State Context |
| |
+----------------+ +-------.--------+
| | .
Service X -> | Service X Glue .. .
| | .. . CurrentNode
+----------------+ .. .
.... +-------.--------+
.... | |
Generic Object API ... ObjectUI |
... | |
+----------------+ ... +-------.--------+
| | ... .
Service Y -> | Service Y Glue .. . Render in Three.js canvas
| | . (How is to be decided)
+----------------+ .
By using a generic Object API we are able to integrate new components by just creating a new glue
component.
To avoid crash.
It should be possible to zoom in and out when looking at a panorama. Zoom should be a property on the state and the state should expose a method for changing the zoom. There should be max and min zoom levels.
The mouse handler should handle wheel events and zoom accordingly.
A decision needs to be taken regarding if it should be possible to move when in zoomed state.
Zoom should be reset when arriving at a perspective image.
Handle cache better
With unified navigation it is hard to know if you are looking at a panorama or a perspective image. An indication of some sort is needed to let the user understand what is possible to do at the current image.
Often then sky is white. Then loading bar is not visible.
The main purpose of this UI would be to prevent from loading unnecessary data, until activated.
Proposition: a container covering the whole area of the viewer, which is clickable and where clicked it initializes the viewer. Doing it that way requires finding some metaphor for activating the viewer. It's easy for platforms like YouTube or Vimeo where the play button makes sense.
What action/metaphor should we use, so we don't throw unnecessary decisions at the user? Let's discuss it here.
Add button that will be either stop symbol or plat symbol.
Create an orbit state implementation with methods for changing the camera position through different camera deltas.
Create a navigation UI with step arrows pointing in the correct world direction with respect to the current camera.
To to launch if none are specified at initialization of Lib. Make use of this in examples so we get gl effect.
Make it possible to either set the image size in the viewer constructor or handle it internally based on the execution environment.
Make 640 the default size.
It should be possible for a DOMUI to clear its hash and therefore its content in the virtual DOM with an method on the DOMRenderer similar to the functionality in the GLRenderer:
mapillary-js/src/render/GLRenderer.ts
Lines 308 to 310 in ea9e928
mapillary-js/src/render/GLRenderer.ts
Lines 132 to 140 in ea9e928
DOMUIs should clear their hash (and release potential memory) on deactivation.
Avoid using the TextureLoader because it relies on the images being cached in the browser. Use the cached image element on the node class to create the texture directly using the Texture constructor.
Create a class for the URLs used in the library to avoid duplication.
Continuing the discussion started by @knikel in #19. Think it is important enough to merit its own issue.
The name UI is not really capturing the whole concept of the components that live in the UI folder.
We currently have components/classes doing essentially one of the following five things in the UI folder:
As said most of these components are not really UIs by them self. What these components do when combined together though is creating a User Experience. A GLImagePlane component, a DOMNavigation, a MouseHandler and a KeyboardHandler as well as a CacheBot and a PlayBot together creates a UX.
With this view of things the UI folder should be renamed to UX, base classes or interfaces should be named UXComponentBase or IUXComponent respectively.
For GL and DOM components the convention could be to prefix or suffix with GL or DOM. Handlers can be suffixed by Handler and bots by Bot. There could be five folders initially under the UX folder:
GL
DOM
Handler
Bot
General
A UI that will both work with panoramas and normal photos. It will consist of direction arrows (panoramas and perspective photos) and turn left/right arrows (perspective photos). This will be a default UI. For the time being the experience will be similar to what is at mapillary.com.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.