mapbox / osm-navigation-map Goto Github PK

From #51 #53 #54 #56 the Mapillary detected restriction location has changed from the location of image capture, to predicited signage location.

This is confusing for the reviewer as it is difficult to understand from which location the photo was taken and to which road the restriction applies.

As per the API documentation #48 (comment) we should be able to use the Image Layer tiles to find the display the photo location on the map.

Ideal interaction would be:

1. Click on detected object marker
2. Highlight image locations that correspond to that restriction
3. If more than one image for the restriction, hovering/clicking over image locations should load the corresponding Mapillary image

Reference: Mapillary Vector tiles docs #48 (comment)

cc @amishas157 @ajithranka @oini @srividyacb

When more than one person is editing the same location, it will help to have a sense of changes being made by other users. One approach to this now could be to auto-refresh the browser each 5 minutes or so and get the updated dataset. We should also give an indication on the UI for long along the map was updated.

cc: @planemad @geohacker @amishas157

Usernames have to be entered manually. Adding OSM login will make this easier.

cc: @planemad @geohacker @amishas157

Simple text box for the reviewer to add their name when submitting/updating a review. This will help in stats collections.

Expected behavior: Clicking on Mapillary thumbnail should display full size image in the same view.

cc @nikhilprabhakar

Adding this information will help with stats and providing feedback to the mapillary team.

cc @planemad @geohacker @amishas157

Showing existing OSM turn restrictions on the map help to easily compare with Mapillary restrictions and add/update the data onto the map.

@rasagy can you review the issues with this styling from a reviewer perspective and post your notes on how it should ideally look?

cc @andreasviglakis

@planemad It would be great if there is a straight way to pull out stats straight from the Navigation Map from set time to time. This would allow us to have day to day stats(Valid,Redundant,Invalid) for that city during Canada mapping sprint.

Even better. From the data team usernames on this page it would be awesome if we can pull out stats only for our data team and total reviews seperately. So we can have a clear idea of how much community participation was involved and how much data team activity is involved.

cc @poornibadrinath

cc @maning

@planemad - It would be great if we could expand a Mapillary imagery in the navigation map itself by double clicking on the small image shown in the tool. This would mean that we don't have to open the image separately in a new tab.

Current output:

We only have a small image on the left bottom corner which is not interactive. It is difficult to determine a turn restriction as the image is small.

Expected output:

When we double click on the mapillary image it should expand the image to full-screen size inside the navigation map tool itself so that we don't have to open the image in a new tab or JOSM.

Possibly related to #51

Many detected signages don't appear to coincide with the coverage layer traces. This particular object does not seem available through either iD or JOSM.

cc @srividyacb @oini @gyllen

Due to #4 and other human errors, it is useful to be able to update the state of a previous review.

cc @ramyaragupathy

The points marked as done are not showing up on the map when in Chrome browser. It shows this error message:
XMLHttpRequest cannot load https://api.mapbox.com/datasets/v1/planemad/ciotrgzko002ew8m29jh4lvhf/featu…aXlsbnd5dCJ9.7Ui7o2K3U6flUzDGvYNZJw&start=1060ece262ab71c00aacc1310349c72b. The 'Access-Control-Allow-Origin' header has a value 'http://127.0.0.1:4000' that is not equal to the supplied origin. Origin 'http://planemad.github.io' is therefore not allowed access.
map.js:906 Error: Input data is not a valid GeoJSON object.

This happens only with Chrome.

When in other browsers, eg. safari, the clusters that are previously worked are seen clearly

Mapillary images shown in the osm-navigation-map are not being loaded in JOSM. I came across this issue quite a few times, so thought of ticketing this.

Mapillary image detected in osm-navigation-map

No mapilary image in loaded on JOSM

Imagery location:

• http://mapbox.github.io/osm-navigation-map/#17.88/45.45784/-73.82010
• http://mapbox.github.io/osm-navigation-map/#18.58/45.42085/-73.97119

This issue is already mentioned in our previous mapping task aswell

cc:/ @planemad @geohacker

Adding a new layer that shows blocks like in tasking manager inside the city boundaries that can help map in a more organized way when more than 2 mappers are involved. A lock and release function would be a bonus.

cc @planemad @geohacker @ajithranka @amishas157

Image location mismatch

http://mapbox.github.io/osm-navigation-map/#18.33/49.23247/-123.01175

Here the location of the image showing in Mapillary layer is not matching with the OSM data present around. Seeing the same difference in both iD and JOSM editors.

@gyllen It would be great if you have a look at this and see what is making this difference of location.

cc @planemad

Similar to iD, we can show the location of the image, the camera angle and a sprite for the traffic signs.

Related issue: Use restriction sprites instead of circles

cc: @planemad @geohacker @amishas157

From #36

• https://www.mapillary.com/sprites/sprites.png
• https://www.mapillary.com/sprites/[email protected]
• https://www.mapillary.com/sprites/sprites.json and
• https://www.mapillary.com/sprites/[email protected]

The click button for hiding the existing turn restrictions is not working for nodes. It only hides the line features and leaves the nodes. It would be great if we can hide and unhide both point and line features as well.

cc/ @planemad

There should be a way to add mapper details to each TR. Also if the TR has already been reviewed, along with the review status, reviewer name should be highlighted as well.

cc @planemad

There should be a way to show the current review status of a turn-restriction. At present, this is not detected, instead we have multiple entries created for the same point.

@planemad

Upgrade mapillaryTrafficSigns to have min/max zoom to 14 this layer will contain all information. Quering lower zoom levels will just make unecessary tile requests.

Upgrade mapillaryCoverage to have maxzoom 14 (its the last tile you ever need)

The navigation-map is not remembering the reviewer's name here. http://planemad.github.io/osm-navigation-map/?review=valid&reviewer=Chetan_Gowda#19.51/38.90555/-77.07452

• Browser: Google Chrome: Version 50.0 (64-bit)

@planemad

Sometimes the detected restrictions from Mapillary fail to load, there are these errors in the console:

cc: @planemad

From #36

Looks like some issue requesting the reviewed restriction data from the Mapbox Dataset API. Reloading after a few times seems to fix this. Initial count of 5 needs to be checked.

@planemad - The zoom in button in the right top corner of the OSM navigation map is not working. As as a resuIt, I am unable to zoom-in inside the map using the button.

Can you please fix this issue?

Currently, the tilesets used by osm-navigation-map need to be updated manually. There are two approaches we can take to automate this:

• Have an EC2 instance than runs a scheduled process that uses shaktimaan to update the tilesets.
• Have a more generic tool that listens to a dynamosm stream for incoming features, filters it based on a set of tags and updates a tileset or dataset API.

cc: @planemad @geohacker @amishas157

The map has been highly useful to quickly add missing turn restrictions from Mapillary. There is significant time saved by avoiding the use of JOSM. Requests:

• A method to add a marker to the map indicating the location has been reviewed - added, redundant, false positive
• Navigation controls to reorient the map if rotated
• Integration of mapillary-js for interactive photo browsing

The map currently only highlights turn restrictions in US and Canada based on this signage list.

This list needs to be expanded to highlight restriction in Europe and the rest of the world. Need to do some digging on what are the expected values of turn restrictions in the Mapillary layer for the other geographies.

@gyllen what the best place to get full list of possible Mapillary objects, is it https://github.com/mapillary/traffico/tree/master/mapillary-mappings ?

A recurring pain point while adding turn restrictions is not being able to have a high level overview of detected restrictions in a city, since the Mapillary vector tiles start at z14.

Would be great to have detected turn restrictions available at lower zoom levels from z10, and other objects available at higher zoom levels.

cc @gyllen @geohacker @ajithranka

Need to implement pagination to fetch more than 100 results. Reference: https://github.com/osm-in/flood-map/blob/gh-pages/js/chennai.js#L148-L178

@planemad Thanks for the live stats counter.
Continuing from #34, it would be awesome to have live stats counter per country as well in the OSM navigation map.

cc: @poornibadrinath

Ref #53 and #54

Mapillary seems to have updated it's traffic-sign vector layer with the probable location of the object (traffic sign) rather than the location from where the image was taken. This is great except that without the knowledge as to which side the sign is facing, it is quite difficult to gauge which two roads the restriction is applying to. Also, many a times, this detection is not accurate. Thus, it would be of extreme help if we could see both the location of the object as well as the location from where the image containing that object was taken in the osm-navigation map itself. This would simplify and fasten up our process of adding turn restrictions manifold.

• Example of an Incorrect Detection: http://mapbox.github.io/osm-navigation-map/#17.72/49.25876/-123.02055

• Example of a Correct Detection: http://mapbox.github.io/osm-navigation-map/#19.14/45.41285/-75.71271

In both the above cases, we had to look around in iD and JOSM to get the location of the same image containing the traffic sign to try and add it to OSM.

cc @planemad @gyllen @maning @geohacker @srividyacb @abhisheksaikia

Lets start thinking about how we can get a feed going with the latest detected objects from Mapillary. The database lookup would be quite expensive. So maybe we can cache something every hour and send back through an API.

We are rewriting our v3 API to use netflix falcor. Is that something you would be able to consider using for getting data from the feed. We will have an easier API REST API as a part of v3. But falcor will give you more abilities to tweak your requests.

@planemad Currently, the road signage that are detected in the Navigation map are represented in small sized green colour dots. These are only visible beyond zoom level 14.

Problems:

• The dots are too small to spot on green colour mapillary path background. After zoom level 14 we spend a lot more time in panning over the map in search of the ones which are not reviewed

Proposed changes:

• A colour change in the signage detected dots and bigger size of the circle that represents it
• Allowing them to be visible in higher zoom levels such as 10 or 12

cc @poornibadrinath

Dataset API is quickly getting overloaded due to multiple reviews for the same restriction. We need to be able to delete unnecessary reviews to reduce the payload.

It'd be great to have a cluster layer with numbers for reviewed TRs. This would make it possible to just look at an area and get an approximate number of reviewed features.

@planemad

Here the Mapillary layer is detecting two turn-restriction in the images.

When opened in JOSM/iD the Mapillary image sequence (Next/Previous picture) shows multiple photos of the road ahead but the image marker won't move forward or backward and the images continues to appear (upto 10-15 and more). With this group of images, its hard to find the image where the sign was detected.

Seeing the same in Mapillary website too where the marker is not moving but image sequence keeps changing.

@gyllen Is this the GPS problem or anything else?

cc @oini @manoharuss @planemad

It would be great if we could have different colours to identify or differentiate between valid, invalid and redundant TR nodes or points, so that it becomes easier while adding, checking and validating.

cc @maanyaumashaanker

Geocoder will easily help us to jump to a map location, instead of just panning through the map.

This would help with

• Separating stats for different countries #46
• Loading data only specific to the country being mapped
• Not overloading a single dataset with all restrictions data

cc: @planemad @geohacker @amishas157

While marking a reviewed turn restriction as redundant, feature seems to be picking valid status instead of redundant. Same is the case with invalid option too.

Status field for a feature, should be populated with the chosen option.

@planemad

It will be great to have the blocks we are working on for SF turn restrictions in the navigation map instead of the tms layer in JOSM. Will help us get a better idea of where we are rather than verifying the roads and the borders.

The layer is tms[99]:https://api.mapbox.com/v4/pratikyadav.3a2c11f9/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w

cc @planemad

Here the location of the detected signage (on the right) does not correspond to iD and JOSM. Both iD and JOSM locates the same image where the left dot is (on the left). Also, the left dot is no longer clickable.

cc @planemad @amishas157

From #1, @kepta lets figure out how to integrate mapillary-js for providing more context of photos to mappers.

The objective is to help a user establish the correct position and orientation of a photograph on the map.