Unfortunately, the blurring AI does too much booboo.
@caglarpmeta How about working on something that actually matters? Please, do not waste your time on something that nobody needs, can be done simpler, and is doomed to fail anyway. Polish blurring and traffic sign recognition first before you move on to the next level of difficulty. People need verifiable and extractable imagery data more than knowing what mode of transportation was used to capture a picture. What is sponsoring an expensive 360° camera (like MAX2) and contributor effort good for when blurring AI poops all over critical parts of imagery?
@Lowiekse thanks for the report, I will take a look.
Also, the links are broken; the images are not loading unless I remove the “&zoom=” parameter at the end. Funny that when I have this tab open, no matter which other image I open, it will be black as well. Just FYI.
In the @Lowiekse provided links the zoom query value has a trailing backslash \ which effectively is converted into a NaN value. The zoom query expects like a floating point number in C notation. Nobody knows what exactly the number format is or is supposed to be because unfortunately Mapillary API documentation is rather mute on this topic.
The Mapillary server (or website) should gracefully replace non-number string values to valid default values like 0. I guess that the same should happen for lat, lng, x, y, and z queries. Strangely enough, the website produces NaN values for x, y, and zoom queries, which should never happen and is something I have already reported multiple times to @nikola.
Something tells that there seems to be happening the wrong stuff in JavaScript:
Number("0\\") // == NaN
// where it should be:
Number.parseFloat("0\\") // == 0
Note that this is not enough to fix this issue. Values have to also be clamped, like 0 <= x <= 1.0 and 0 <= y <= 1.0
@GITNE is absolutely right, and the backslash is the key (to the issue). I quickly checked our image sharing, and in all the combinations I clicked, at no point was I able to get a backslash in my link. If at some point you will be able to reproduce it, please share the details (how, which browser, OS, idk what might be the root cause). One note, as if one doesn’t zoom in on the image, we have no zoom param in a shared link. We add it only when you zoom in or out.
Regarding Nan, I will check whether we have a task and create one to fix it. I will also cc @Anders, and there’s a great chance he will be the owner of this one.
PS Despite having used links with zoom previously, I’ve never noticed the “zoom” parameter in the link before, lol. Thanks for opening my eyes
25 days since this was posted and I just noticed the program is open Hope I’m not too late to apply, my current 2019 Max has already scratched lenses because of capturing on nature trails and worn up batteries.
Excellent! Please tell us what you think of it. Is it worth the effort and money? Personally, I am still waiting for the official GoPro MAX2 hard case to get restocked.
I only use the silicone case and the battery compartment cover. It’s worth the money (€ 13,-). Just be careful when mounting the camera on the selfie stick so the silicone case doesn’t get pinched in between. We’ll have to wait and see if the camera can dissipate its heat properly while downloading and/or charging.
Exactly, this is what I have been concerned about too with this silicone case. MAX2 heats up much more quickly than MAX. In fact, one can see that GoPro engineers have thought and taken care of it because unlike MAX, MAX2 has radiator fins on the front.
Generally speaking, the camera is quite sturdy. Though, when you put it on a car even the tiniest dust particles are quite abrasive when driving at speed. So, I can only recommend to everybody capturing by car with the camera mounted on the outside to have the camera (and lenses) protected. It does not have to be this or any other particular silicone case. A plastic bag with cutouts for the lenses may suffice too. Just keep the camera (and lenses) protected when moving at speed.
No, he means the mapillary keys in the OSM database that used to have alphanumeric image key values but Mapillary has silently transitioned to using numeric only image keys. Since then the existing mapillary image key values have sort of become obsolete. @filipc wants Mapillary to update the legacy alphanumeric mapillary key values to current numeric only key values through an automated edit of the OSM database, despite this being a purely OSM matter.
@filipc Mapillary is not going to update legacy mapillary key values in the OSM database because it is not their business. Ever. If it bothers you, you have to do it yourself together with the OSM admins. You may also want to know that the OSM contributor @Kmpoppe has set out to accomplish exactly what you want: