I suspect Every Door will become one of the top 3 editors for OSM in the near future.
I've been using it a lot since State of the Map 2022 for data capture. There are some many low hanging fruit to capture that its really efficient to improve coverage with minimal effort.
It does of course help to know the data model and tag guidance well for the amenities / data you are capturing. But there are opportunities for novice mappers too.
It helps that Every Door builds on the presets of iD, which are localized well and can often easily be found with searching, even by novice users. For me it has replaced OSM Go! as the app of choice for quickly adding details or changing a few things when outside.
For very novice mappers that don't want/need to add new elements, StreetComplete is probably still the best way to start out, at least if you're on Android.
I am in a walkabout through the Balkans and Central Europe. I’ve been using Maps.Me, which is great. I would love to contribute places and corrections.
Do you think Every Door is a good way to do that? Is this [1] wiki the right place to look for the data model/tag guidance you are talking about?
I heavily suggest to switch to https://organicmaps.app/, which is a maintained fork of Maps.me, without user tracking and the whole wallet shenanigans.
You can just enter an amenity:bench poi, but it's useful to include additional information in tags. StreetComplete, for example, has a quest that adds the backrest information.
Osmand lets you add pois, but offers little guidance which tags are appropriate for which kind of poi. Every door seems a bit more helpful in that regard.
I should add that when you add or edit a bench in Every Door, it shows the backrest and the material attributes at the top. So hundreds of benches in my area have these mapped :)
Absolutely! I agree with another user that you should switch to Organic Maps, but if you want to do more mapping, Every Door helps with that. It uses iD editor presets, so you can contribute even without knowing OSM tagging, although that would help.
Having benches mapped was recently very helpful for me on a long tiring day of touristing. Knowing I could have a rest in 300m was a huge help. Google Maps fails at this: either they don't have the data 0r they don't display it. OrganicMaps was great.
Entrances also are really useful. Without that data many apps like Uber assume the entrance to a building is at its centroid snapped to the nearest street. Which is usually wrong, often by a whole block.
To your second point, google seems to have ramped up their efforts on micro mapping a lot in the last year. I frequently get a little questionnaire after using google maps to get somewhere that asks me to pinpoint exactly where the entrance of the building is, if there are multiple entrances, are they accessible, etc etc.
Google also started rolling out more details on sidewalks, parks, etc in some cities, so I'm guessing they might transition that to more cities in the future.
There are definitely gaps in some areas where google is quite far behind compared to OSM though. Trails is one area, I personally have spent a lot of time in OSM accurately mapping out trails in my local parks.
How is this different from StreetComplete, which is on F-Droid, and seems to be the same thing, but for everything instead of just “POIs and entrances”?
Every Door and StreetComplete seem to do different things, with a bit of overlap.
StreetComplete works by asking you for more details about certain things that are already on the map. It seems like Every Door doesn't ask you specific questions but lets you add any details you like, and also add new points to the map, which StreetComplete doesn't let you do.
StreetComplete is meant to be usable by a complete novice. Every Door looks like it's for mappers who already have a bit of an idea of what's going on and want more control over what they can add to the map.
StreetComplete has actually been adding a new feature called “overlays” recently, which let you switch the map to a special mode for editing a certain class of features. The upcoming version 48 has an overlay for shops and street addresses, which might cover much of what Every Door is aiming at: https://github.com/streetcomplete/StreetComplete/releases
I'd say that is closer to what Maps.Me / Organic Maps do than to Every Door. The latter has a huge focus on updating amenity attributes, which involves doing away with the interactive map for the main UI element. In a shopping mall, for example, StreetComplete's view would be cluttered and mostly unusable, while Every Door is perfectly fine for adding or confirming every shop.
> StreetComplete is meant to be usable by a complete novice. Every Door looks like it's for mappers who already have a bit of an idea of what's going on and want more control over what they can add to the map.
I just discovered this app today; that's my understanding as well. It's also easier to all kind of nodes; with StreetComplete we're limited to add shops with the dedicated overlay.
Also, compared to my previous editor of choice to add nodes (OSM Go!), it seems to offer a better source of background imagery. I can actually my local government imagery source (swisstopo) instead of mapbox.
Micro-mapping manholes and benches seems like something that would really benefit from the precision of RTK/PPP GPS. The built-in GPS provider in my phone is absolutely not up to the task.
Suppose I have a bunch of hardware sitting around, a base/CORS reference, etc. Is there an accepted best-practice way to pipe it into my phone to let this app use it? Or to take logs in my backpack and post-align the data when I get home?
On Android, in Developer Settings, it's possible to register an app as a Mock Location provider. I'm not sure the interface your app needs to surface to show up in that list for selection, but in theory that API existing means there's a potential path for this.
Your app could interface with more accurate external sensors, and then set the phone's GPS fix to be what the sensors read. Assuming that the issue is lack of accuracy at the sensor level and not lack of precision at the software / API level.
This is the way. I had a lot of success using Mock Location for a mapping project this spring. I'm pretty sure mapping applications have to explicitly allow it, though. For some reason Google Maps refused to acknowledge my mock location IIRC. But I've never had issues with OSM mapping apps.
If the hardware you've got sitting around is a proper high-precision GPS system like a Trimble R2 or suchlike, the normal practice would be to use the data logging features built into it.
But are you sure the GPS in your phone isn't good enough to map the location of benches? I've seen phones get within a meter or so, under good conditions - more than sufficient to get someone close enough to see a bench.
Close enough to see a bench is one thing, but close enough for the bench to be located properly in relation to the manhole, is something else entirely.
I'm sitting on a couple Ublox F9P's, one of which I need to get back in service as a Galmon monitor station but which also serves as my RTK base, and the other is on a quad that I'm not flying anymore so that's my rover.
Personally I try to align new POIs that I cannot see on aerial imagery as well as I can to existing geometry like building outlines or streets/paths. Either one of those may we wrong since aerial images often have an offset that varies depending on where you are and you can't really tell from the map which points are accurate and which ones aren't. So your bench that's accurate to 10 cm may just as well be moved by someone else again because it's "clearly near that path intersection and not 10 m away from it".
Maps basically lie all the time and every map is an imperfect approximation of reality. Of course if your envisioned data consumers are blind people that are guided by surveying GPS equipment to that bench so they can just sit and be confident in actually sitting on the bench ... well, yeah, that might work. But I don't think that's a particular compelling use case and most people when they're looking for the bench that's on their map will find it just fine if it's not that accurate.
Interesting tidbit: Hiking guideposts around here all have UTM coordinates written on them and a few of them are a bit wrong, at least compared with other geometry sources that should in theory also be accurate (like cadastre data).
This is a great app. Reminds of Street Complete. I found Street complete to be a bit annoying to use with asking so many questions. This is much simpler and gives better control.
Someone should make an OS map editor/view which basically looks just like Google maps but uses open street maps under the hood. That will probably make it seemless to switch to open street maps.
Note that in Street Complete you can go into the settings and turn off some of the things it asks about (E.g. I turned off street material very quickly).
But street complete gamifies the data entry... steet materials give you a bunch of points for basically zero work.. .just walk to work, and "left... asphalt... right? asphalt.. left? asphalt... right? Paving stones.. left? asphalt..."
A lot less work than editing opening times for restaurants, cointing the floors on high rises, the stairs and bike racks.
This is the beauty of OSM! Editors can prioritize what type of data they want to help improve. Some people are focused on wheelchair accessibility data, others on landuse, etc.
The OSM datamodel still revolves around a single datafile containing all data. At most it can be chopped up intogeographical bounded areas: the entire file for a country, state, city or neighborhood.
So, while I applaud and love micromapping (every door, bench, manhole or street lamp) it no longer scales.
There are great apps to map every single tree, speed bump, lamp, bycicle stand, surface, roof and such. All great apps. All data accumulating in a still rapidly growing datafile.
OSM really could use a form of layering. Especially when great apps like these here take off. So that users of the data can extract relevant data without having to parse giga, or terabytes of XML or PBFs.
No. OSM could _not_ have grown this big if we had layered everything. Far from it - the big power of OSM is the integration of all those 'layers'.
Furhtermore, layering would needlessly complicate everything.
Take a railway crossing for example. Should it go in the layer "railways", in the layer "roads" or in the layer "railway crossings"? Should we make a new layer for paths, so that they are separate from car-only roads? What if something changes? How should an object be moved from one layer to another?
What with benches that double as a piece of artwork? What about this place that is a boardgame shop, a café and a social project for mentally disabled people?
What if a river doubles as administrative boundary?
If you want to extract data that is relevant for you, there is overpass-turbo.eu for this, where you can write a precise query and only get and download the data you need.
I certainly agree it wouldn't have grown as big as it is with a less pragmatic approach. Entirely.
But there must be a moment when some simplicity or pragmatism must be exchanged for scalability.
Layering is one option. While indeed railroads and roads probably want to be on the same layer, opening hours or pavement need not be.
I'm not saying a node may only ever be on one layer. They can easily be duplicated over layers. Just like at boundaries of geographical chunks, (i.e. over the borders of luxembourg.osm.pbf) there are (tens) of thousands of nodes that also appear in Germany, Belgium, the Netherlands once even.
But "making an entire ecosystem change being a huge effort" does not prove that it's unnecessary. It just says that it is hard.
I've never seen the OSM community back away from projects because they are "hard". And the moment this community starts doing that, it can just as well abolish oneself, IMO.
> The OSM datamodel still revolves around a single datafile containing all data.
You could make an argument that this is not true: at an implementation level, the more fundamental OSM data model is a really big PostGIS database, which has the appropriate indexes to let you query whatever subsets you want.
The big flat-file XML/PBF dumps are just one way that this data is exposed. You can also query the API for objects within a bounding box (and thereby benefit from the DB indexes), or you can use the daily/hourly/minutely incremental diffs to run your own database replica.
I have a snapshot of all of OSM for a given date (conveniently called planet-XXXXXX.osm.pbf) and the compressed version is 62GB. And the format is optimized for reading certain chunks (as well as updating with new data). Plus there are libraries that do the heavy lifting for you in little time at all.
The size is really not as big of an issue as you think it is.
The developer is working on it and it's on the roadmap for the next release. The only stumbling block seems to be that they can't get location to work without Google Play services and there don't seem to be Flutter solutions for that around.
I am seeing lots of entries that could be better (or at least partially) updated using data from company websites. For example, the local pharmacy chain or fast food restaurant's hours are on their site.
Does anyone more clued in to OSM know why/if these can't be updated via web site scraping?
They can! That's a different process called importing, and people do that a lot. For example, I've imported all of Walmarts in the US a few years ago by request. See OSM wiki on imports: https://wiki.openstreetmap.org/wiki/Import
Hmm. Can someone explain why there's no search function and the zoom only goes out to maplevel 16, meaning it's absolutely impossible to use without transmitting GPS info (and also effectively impossible to make edits on a place you were a day or two ago but no longer are nearby)?
> 100% OpenStreetMap editor with no dependencies on third-party endpoints.
Except the mandatory Android or iPhone you need to install the app.
I was actually really excited to give this a try, maybe annotate some local areas, but I'm not switching over to my phone to try. I really don't understand this trend of making multi-platform apps that can't also be webapps. If you passed the Apple UI review for this to be approved for iPads, then from a UI perspective, why can't this run in a browser?
If you're on desktop, openstreetmap.org has a full editor that can do all of these things. That editor doesn't work on mobile (at least, not practically speaking) so there's only really a need on mobile.
Aye. While plenty of desktop editors exist, having the same UI on desktop and mobile would be valuable, especially for someone learning before they set out on foot.
I've been using it a lot since State of the Map 2022 for data capture. There are some many low hanging fruit to capture that its really efficient to improve coverage with minimal effort.
It does of course help to know the data model and tag guidance well for the amenities / data you are capturing. But there are opportunities for novice mappers too.