Hi metatech. Those are good questions.

You can compare restrictions side by side and I think you will find that OSV is less restrictive. Both have CC-BY-SA on images, so attribution requirements are the same. Unlike Mapillary, OSV does not have a ‘private’ walled garden of images that OSM does not have access to, nor does OSV place special restrictions on commercial use (in line with OSM which does not do that either). Also, OSV allows you to easily delete your account and with that, your uploaded images. Please check but I don’t think you can do this with Mapillary either. Also OSV has LGPL on most of the underlying software. See the comments above.

As for competitors vs collaboration, I think having two players in the field should result in a better outcome for everyone. It keeps everyone focused on the shared objective, which is to create a truly open street level imagery resource for OSM. We are happy to collaborate with anyone if it supports our that objective. We made an attempt to collaborate with Mapillary for one of our previous initiatives (the ScoutSigns plugin for JOSM) but that didn’t work out so great. That is in part what sparked the idea to start OSV in the first place.

That is a fantastic milestone to hit! Congratulations. (Just curious, which town is it?) Let me know what you think of OSV and how it is / could be more useful to your mapping.

Hi Narigondelsiglo, the Android app right now only supports the Bluetooth Low Energy (LE) protocol, so unless the dongle specifically says ‘Bluetooth LE’ it is probably not (yet) compatible. We are working on ‘normal’ bluetooth support. Wifi dongles should also work.

You definitely do not need OBD2 to use the apps in any way. It just helps enhance the trip trace. The apps work perfectly fine without the OBD2 dongle.

If you want to check out the relevant source code, https://github.com/openstreetview/android/tree/0358658ed76911263320c24b860afb5f02f3068c/bluetoothobd/src/main/java/com/telenav/vehicledatacollector/obd is probably a good place to start.

yvecai - at the moment: the backend, the map editor and the image recognition component in the apps. Some of this has to do with third party licenses that we need to figure out. We are looking into open sourcing the remaining components.

Hi nakaner, We don’t have the intention at all of making OSV into a data silo. Right now we do not yet have an easy way to download everything. I will post an update when that changes.

Have you had any success with ImproveOSM data?

I don’t know why utilsplugin was not made part of the core a long time ago…

mtc: Sure! I am in add mode (keyboard a). Then I click on the way where I want to add the node. A node will be added. Then I hit Shift-r to apply the ped crossing tags. Then I hit Esc to end this add. (Otherwise you will draw a way.)

One thing to keep in mind is that Shift-r will repeat the tags of the last selected object, so you have to make sure that you do not select anything else inbetween, or it will copy the tags from that object.

Cool that you’re using MapRoulette for this!

Are you new to OSM? In which case – a warm welcome! If you have questions, don’t hesitate to ask. A good place is the OSM US Slack chat, for which you can sign up here: https://osmus-slack.herokuapp.com/

Nice!

You could also make a MapRoulette challenge out of it pretty easily and have everyone help out :)

Joost - that’s what I am hoping for. It is really a challenge about revisiting those initial mapping attempts based on then available imagery. Another look at those through MapRoulette may trigger a new wave of mapping in these areas if better resources are available now. At least that is my hope. (That gives me an idea. Perhaps it’s better to filter out the ‘floating ways’ that have not been touched in at least a year or so.)

Let me know if you would like to process this query for Peru, Bolivia or other countries.

Glassman - let’s be in touch about that.

katpatuka – I didn’t look into that specifically. Do you have reason to believe that this was mainly done by one user?

Not yet. I asked Grant a few times but he is pretty backed up on other OSM systems tasks. Once we get a new dump, I will start working on it.

Stereo, we do not currently use it for Scout, see https://taginfo.openstreetmap.org/keys/sidewalk#projects

Piskvor – indeed there may be false negatives (or positives depending on how you look at it) because of this. I used to map sidewalks as separate geometries, but I stopped doing it in favor of just mapping sidewalk tags. Some folks argue that separate geometries for sidewalks can help with specific use cases like wheelchair mapping. If anyone can explain to me how separate geometries would help those use cases in a way that sidewalk tags (perhaps augmented by more specific sidewalk:*:* tags) could not, I may change my mind again.

I used to be in the ‘map sidewalks separate’ camp. I don’t think it’s bad, but I am not convinced it’s always necessary either. Adding sidewalk=no|right|both|... is much quicker. How does mapping sidewalks as separate geometries aid wheelchair routing in ways that couldn’t be accomplished with the sidewalk tag?

Still tons of stuff to do. You can have your own MapRoulette challenge for it now. Add your city and get people to join!

OK, reading it again…It looks like it is clear. the wording no is preferred, despite this tag being in wide use appears in the description for the value none. So I edited this post and the original post to reflect that preference. I will also update the challenge and the sample config file in the github repo.