With what happened with all that Facebook takeover stuf… I thought that Mapillary was that (single) one company that had a high moral that actually was able to be commercial and be able to have a genuine warm relation with the open source community. It feels like I have just lost a dear friend…
But could it be: the king is dead, long live the king!
I fear, to my immeasurably large regret, this proves that in cases like these we need to go open source…
Isn’t the basic code opensource? Could we be able to build an open source alternative?
I have been working for several years in my spare time on a project that uses (360) images I uploaded for an implementation. Obviously this is “front end”. This all already works rather well. I am willing to opensource that part. But I need that smart and nifty back-end… that part that is able to calculate and correct the geo-location, so that the track… Well, tracks.
AD: also privacy issues need to get addressed, blurring licence plates and people’s faces. Part of my project includes face-recognition… so I think I can help there…
PS: Mapillary, please, come with a more extensive statement, interact, can you ease the dismay members of your community have?
For five years Mapillary has been winning prizes for best startup. It could have won the price for longest living startup. It attracted partners and venture capital.
But I don’t know of any customers. It was very expensive to use the APIs.
I like Facebook and its freedom of speech.
I even boycot the boycotters.
The outcome could have been much worse.
I profoundly dislike the attitude Facebook has towards privacy… I do use Facebook, but I now rarely share personal stuf… I don’t need to see advertisements everywhere about stuf I share…
A mapillary open source would be great! The problem is the cost of the storage.
Very interesting would be develop a software with support to federation and join it to the fediverse! Fediverse - Wikipedia
After that, anyone can upload your own node, may be each with imagery dedicated to one country or one city.
An other very important thing I think is develop an upload tool with bluring of faces and license plates BEFORE upload.
Im backend developer and I would like to help developing that software.
Storage could be node based (I think that is what you said )
My project was a bit on hold (busy & do need to pay the mortgage ) I’ll see if I can find the time this week to share an access here…
@juanman could you check out the software Mapillary has made opensource? I’m quite good with database structures and front-end (js, php, Perl ) The most important thing I’m not good at is the part “SfM”, the part where Mapillary is able to adjust the geo-position…
Us normal Mapillary users only get to see the results of SfM in the nice transitions between one image and the next. The geo-position is retrieved from the embedded geodata, not from SfM. (You can see that in areas where there are many photos, individual photos of the same street section made in different sessions are still spread out.)
Most of Mapillary’s (award-winning) SfM is not available for us normal users. Corporate users however can download 3-dimensional point clouds and do spatial measurement from the photos, all generated from SfM data.
My conclusion is that SfM would be nice to have in an (open-source) alternative to Mapillary, but not at all a requirement.
Yes and no. The main thing I loved and love about Mapillary is it’s capability to correct geo-location. And the main tool to do this is with their amazing technique “Structure from motion”. This creates the possibility and enormous potential of combining and placing imagery perfectly to it’s geospatial position.
With this technique, in the long run, with enough imagery, one could render a 3D model of the entire earth… That is simply impossible without the corrections SfM offers…
The big question is, are the uploaded geo-locations accurate enough of all the separate additions to create a coherent whole. I fear not. In my opinion one of the greatest advantages of Mapillary is it’s (potential) capability to effectively merge the enormous diverse set of imagery.
Are you talking about a theoretical, or an actual, correction of geo-location? Because I have also heard talk about this, but I have never actually seen Mapillary correcting the geolocation of any photos (on the map). Even though I do see Mapillary creating valid SfM data, through smooth transitions between photos in separate sessions.
Mapillary is actually already creating 3D models of “larger” areas, but the results of that are not available to us contributors.
I agree with pbb , the theoretical advantage of SfM in determining improved location estimation due to many images in a area, has never been used to update the image geoposition for the normal users on the map (as far as I know). So, in my opinion that should not be a main goal for a Mapillary 2.0 ( I just want an improved openstreetcam / basic mapillary site )
I created a video from within my project I am working on. Now the SfM geo location can be retrieved via the API for a complete dataset, but there was a time that was not possible, so I created a “per image solution”. For the fun of it all I created some animation around that… The nice part is that this gives a great impression of the power of SfM, behold:
(forgive me my searching for words sometimes, I am not native English speaking)
AD: I forgot to mention, each “spot” is an image with a geo-location. Also the difference in recorded geo location at the end is massive (most likely because of poor geo location due to the large hills)
This is very interesting! But are you certain this information is also used on the public Mapillary map? Or is this information only available in the API? Because I have never seen any of my images location being corrected on their map.
Absolutely, 100%.
Every time you see a smooth transition between two images, I think it is 100% certain both images have been successfully processed by SfM. With that including the geo location correction.
I have only contributed 360 degree images, all of them have corrected geo locations (except some earlier sets done with a less good 360 camera under relatively poor lighting conditions) I can see the corrected tracks on the Mapillary app also, so that information is absolutely public.
I can imagine that “flat images” are harder for SfM to process… but I have not done research there since my goal has been 360 images from the start…
I think you are misunderstanding me. At least based on your “Absolutely, 100%” reaction.
I do notice the smooth transitions, and I know they are because of the successful SfM processing. But that is not what I am asking about.
My question is, are the corrected geo locations visible on the map? That is, the placement of those little green dots on the map, for example here: Mapillary Because I am quite certain the green dots that you see there, are NOT the positions calculated from SfM, but the original GPS coordinates stored when recording the images.
Ah, yes, I stand corrected; the part I showed you in my little film:
Apparently they do not use the corrected locations for their “green dot overview”. Not to long ago they made that info more easily available. so I think they could now fix that… since they in essence use the same API I do… (they added that “green dot overview”, that is part of their system and not publicly available)
I’m actually more fan of the OpenStreetCam approach in that regard. On OpenStreetCam you can select a purple line on a street and then all the images available on that point on that road are visible below. On Mapillary when a street is ‘visited’ several times you can see a dozens of green points and lines which makes the map very busy and unclear. Sure you can filter on date. But on OpenStreetCam it’s easier to navigate to select the image of a certain date at a certain point.
I wonder how that works for the backside of buildings. How can dashcam footage reveal that? I think for a true 3D image you need satellite photos. Unless Mapillary has found some clever solution that uses both satellite photos and dashcam footage.
Openstreetcam uses a not-so-good algorithm to ‘match’ your images to roads (and then colors the full road). But it does not work correctly with bicycle tracks and near places without any roads. Its not good enough for me.
It’s not perfect. But Mapillary definitely needs a solution for overcrowded maps. To avoid things like this: Mapillary Good luck finding the most recent image there. Or the one you look.
Going slightly of topic (but I don’t mind, this far to interesting)
If they reposition The ‘green dots’ to the SfM position, I expect the lines will converge quite a bit… then the ‘only thing’ one would need to do is make it much easier to see/select the available image for that position.
This is only partially important for my project, since the number of (selected) users there will be quite minimal as to the overall Mapillary… but I have thought about this too; first when an image has been selected the in-image arrows should primarily remain within that user. When not possible use the current system, then stick to that user… also a sort of time-scale should be available on multiple imagery on one location. This because in my opinion ‘time’ is the primary variable in this case.
AD: there is a global search tool in the std. Mapillary app, where you can search for a time and/or a user…
)
