Mapillary 2.0 ? (opensource)

21

Back to the subject, couldn’t we All just work together? Couldn’t Mapillary create an opensource System where the basic functions exist in a ‘node kind of way’, where SfM, uploading, management and database functions exist… and a publish function to Mapillary where the ‘selectively blurred images’ are published?

Advantages:

  • privacy
  • software get’s updated also by the community
  • stability for the future

I must be missing other advantages (and needed functions) but, for now, it’s the idea that counts… :wink:

22

I found this project that has some SfM (open source but its not clear the license)

Frontend: GitHub - enricofer/wide_sight_frontend
Backend: GitHub - enricofer/wide_sight: Street level images management system backend

Another project, full open source, very simple and designed for walking trails:
https://www.opentrailview.org

And other related to walking trails:

For bluring faces and license plates:

In this mailing list thread there are people talking about build a open source street level imagery:
https://lists.openstreetmap.org/pipermail/talk/2020-June/084994.html

regards

1 Like
23

Thanks for the links, I’ll look into that, especially your last one.

The darn thing is time, of which I have way to little this moment…

24

Most recent images: :grin:

25

Hi everyone!

I’m the founder of Trek View. I have also been working with Nick Whitelegg on OTV, also linked in @juanman’s post.

Our joint focus is on off-road 360 imagery and we have some plans for the next few months to ship some new features to our respective open-source code.

That said, for the most part, the underlying tech is similar, regardless of what is being captured (roads / paths / etc).

We use a lot of tools that already exist in some open-source form (e.g. ffmpeg for processing video files, exiftool for metadata, Pannellum for 360 viewing, opensfm for image transitions, etc.).

For us, the end destination after this processing is Mapillary and Open Trail View.

I am still a firm supporter (still) of Mapillary. They have done a lot for the industry (and continue to do so with integration into OSM). Don’t get me wrong, I get the anti-FB sentiment, but the sad truth is, hosting a platform like Mapillary is very expensive. For large tech companies spending 100k EUR / mo (or more) on hosting is nothing, for a private company this is a lot of money. The larger you are, the more it costs, which can make growing harder and harder.

It would be great to have a much clearer statement about Mapillary and FB’s intentions. I also know, having worked at companies that have been acquired, the road map is not always very clear. In many cases the acquired company/product disappears entirely within a year or two (this is my biggest fear)

All being said, I am all for working together on improved solutions (with openess and privacy at the core). I know many in the OSM community are having similar discussions around similar points to those raised in this thread.

How about we take this discussion away from Mapillary and into a public forum elsewhere (with the OSM community)? I’ll set this up today (probably a Slack team) – if you are interested in joining the discussion (all welcome, even if you’re not technical), please email me and I will send out an invite: dgreenwood@trekview.org).

2 Likes
26

Hello everyone,

To follow up Dave’s post, I am the developer of OpenTrailView (OTV). This project is still in early stages but is likely to see significant further development in coming months.

OTV has a more specific focus than Mapillary, namely walking trails and 360 panoramas only, but the underlying software could potentially be used as a starting point to develop an open source street viewer tool.

OTV deals with the problem of connecting panoramas together using underlying OpenStreetMap data: nearby panoramas within a certain distance of the current panorama are found, and then routes calculated to each using GeoJSON Path Finder (GitHub - perliedman/geojson-path-finder: Find shortest path through a network of GeoJSON) with OSM GeoJSON data.

Each route is associated with an OSM way leading from the current panorama (by grouping initial bearings to each) and the nearest panorama along each OSM way is selected.

Pannellum is used to display the panoramas.

The Gitlab repo is linked above, alternatively if anyone is interested in more details I can be contacted on nickw4426@gmail.com.

Nick

2 Likes
27

Hi Nick. Does your system have any “smart geo position correcting”?

28

Hi eesger, do you mean ‘snapping’ the panoramas to the OpenStreetMap data? If so, it does do that, yes: firstly, panoramas are inserted into OSM ways (to ensure the panos are on the routing graph), and, once the graph is generated, panos are further ‘snapped’ to junctions within 5 metres (I’m going to experiment with 10 metres as I sometimes get unsatisfactory results). This ensures that a panorama which is supposed to be on a junction is indeed on the junction so that the connectivity is correct.

29

hi, I tried your tool yesterday. Uploaded 10 images and they were nicely snapped on the pedestrian road. Interested in the algorithm: does it use a shortest path calculation to find feasible OSM ways to use for each of a string of images, or only ‘dumb’ snapping to the closest roadway?

30

I did a little test also, I’m not getting it :face_with_raised_eyebrow:

(I think I am expecting something different somewhere, somehow)

31

That “Wide Sight” looks seriously promising! (License: I get the impression that the developer mostly wants his name mentioned when you use his software ;))

The main benefit of SfM (in my opinion) is that it “stabilizes” images (pitch/yaw) and that it corrects GPS location (lat/lon) based upon image recognition (example: SfM sees sign A on image B and image C (etc.) and calculates that the yaw & pitch needs little of this and that the latitude & longitude needs a little of that). This automates and perfects date to a great extent. And most of all it improves the “walking around” experience! (check that little film I shared earlier)

32

Yes, I saw those as I moderated them yesterday. It does use a shortest path calculation… firstly, it finds all panoramas within a certain distance of the current one (500 metres I think, but I need to check) and then calculates a route (Dijkstra) to each. This is done with GeoJSON Path Finder which I mentioned in my original message. OSM data is downloaded from the server as GeoJSON and then converted to a graph using GeoJSON Path Finder.

If multiple panoramas are on the same route (have the same bearing) from the original, then the closest one is selected, and joined to the current panorama.

You will need to rotate your panoramas using the map interface so that the camera icon is pointng in the same diretion as the centre of the panorama.

33

Hi @eesger what did you do? There were some new panoramas uploaded this morning, e.g

https://opentrailview.org/?id=1303
https://opentrailview.org/?id=1340

Either of those look like yours?

34

Just to update: I’ve had two test uploads in the past 24 hours with the panos very close to each other, which have some issues with connectivity (generally, all panos submitted up to this point were at least 10 metres apart so the problem hasn’t arisen until now). I will need to investigate this bug - apologies for this. It should be easily resolved.

35

1340 is me. And my test were images quite close to each other (I was curious as hout the “pointers” would show on the pano)

36

See message above, close-together panos are causing some issues but should be straightforward to resolve, likely to be an artefact of snapping to the OSM way.

37

OK, I seem to have fixed this. Close-together panoramas are now linked correctly, at least the two sets uploaded today (IDs between 1303 and 1340).

The issue was actually not to do with the fact they were close together. It was that panoramas further than 5 metres from an OSM way were not being added to the routing graph. I have increased the limit to 10 metres and it’s now fine. @eesger @micmin1972 You will also need to rotate your panoramas using the map interface to ensure that the bearing (heading) of the camera icon corresponds to the direction of the bearing centre point of the image , as currently the link arrow is in the wrong place on the panorama.

38

Re face detection… not sure if anyone’s seen this:

Seems to work very nicely. Takes maybe 10-15 seconds to download the model but after that it seems pretty good at face detection. Tried a few photos of mine (both regular photos and panos),
I find you have to reduce the confidence a bit (down to around 0.2) but would be a start for pre-upload blurring and shifting some of the processing to the client.

Haven’t yet found a similar thing for license plates.

1 Like
39

I tried this GitHub - understand-ai/anonymizer: **ARCHIVED** An anonymizer to obfuscate faces and license plates. and worked good for faces and license plates. Its memory hungry for big pictures. Only works with python 3.6 (I tried with newer versions and tests fail)

I’ll start a new thread for this topic

1 Like
40

I have had a nice talk / ‘brainstorm session’ with @nickw a few days back.
Also had a 11 hour brain draining workday…

But I’m full with ideas and I think all/most of the buildingblocks are there…
Also I’m sensing momentum here:)

When I find the time, I’ll work things out and get back to y’all.

PS @nickw, sent you some links & ideas over Skype

[EDIT] Thanks nick for that JS face detection link! That is awesome! That way I could make that part client side and save a sh.tload of cpu cycles :slight_smile:

For “mapillary 2.0” this is less suitable though. here we need “automation to the max” to make this workable. So for testing this could work, but in the end this’ll need to go server side

1 Like