Steve Coast's proposal for OSMF strategic plan

Would it be possible to at least rename the title so it doesn’t have his name in it? Not that I think it’s necessarily on the forum, but it is a little ridiculous to have him and the plan connected to each other that way. Like I don’t see how it would be allowed for me to start a forum post called “So and so users opinion of X” when apparently I can’t even mention specific people by name in a message without it being hidden as abusive.

I’m not inclined. This case is different because the only reason this thread is so popular is because it is Steve’s proposal. His history with the OSM project precedes him like very few other people. That is why their is even a draw to this thread. There would be significantly less interest, likely none, if it were my plan or mostly anyone else who has not at least held a seat on the OSMF board.

Unfortunately the alternative of making openstreetmap.org some kind of one-stop shop would have major cost implications in terms of support. One of the reasons OSM has been successful is that it hasn’t dissipated scarce volunteer, and lately, employed sysadmins/devops across too many distinct systems. Trying to do everything which your user base wants has been the downfall of many a tech start-up (or at least 4-5 I’ve been involved with).

It’s also worth reflecting that some software tools which stood out 10 years ago are not as popular now (OSRM is a good example). The Mapnik/Carto-CSS toolchain might be considered another. Picking ‘winners’ to integrate into the website inevitably ends up with migration problems later down the line. The lightweight way in which routing engines were added to the website undoubtedly minimised this type of issue.

Then we certainly shouldn’t be making them collect addresses as step one. I personally find it rewarding, but not “fun”. We know that even with mappers who have been active for years only a small proportion map addresses.

Addresses are probably most useful for SMEs working in a local area: firms making deliveries, taxi and private hire companies, some local marketing & campaigning (e.g., elections), etc. Ideally, we’d have areas with enough addresses to be useful to some of these firms that they themselves decide to add more. Of course they have to find that data in a form they can use, but I don’t think the main OSM website is that place.

2 Likes

That would be the " actually quite the opposite." bit. Being presented with QA as a new mapper is going to be difficult to do in any kind of welcoming way.

It has little to do with Steve as a person (outside of the deliberate attempt at sabotaging the discussion of the OSMFs plans), but more with how much time to you want to spend on ideas that are a dozen years old, repeated by somebody who has been out of touch with OSM for just as long, and of which the good bits have been ongoing activity for a very long time.

I would note that you didn’t need Steve to tell you to start your address collection activities in the UK

It’s about balance. Sure we shouldn’t add too much but in my opinion we could add a little more which would deliver significant value. It’s all about what “delivers the biggest bang for your buck”. Put it another way, is there anything you’d like to see on OSM.org?

Well in the first few years you were presented with a mostly blank map; that’s a form of QA. Outright dismissing the idea as it’s difficult feels like giving up to me!

That’s debatable. The UK address project was funded by several very generous companies and individuals. It would have been great to have Steve as one of them but we eventually found enough others to get the project off the ground. Unfortunately the project effectively failed as we didn’t get an adequate software solution in place. If we had, we would have spent considerable effort promoting it to attract non-mappers (and as noted, this is hard as your competing for attention in such a fragmented environment). I think we can still turn the project around and make a success of it but not without resources.

It depends on what you understand by QA-Tools. Sure, if you present a (potential) new guy some sort of OSM Inspector or some kind of Changeset analyzer I agree with you. But something like heatmaps in regards “missing surface”, “missing house numbers”, “potential outdated data”,… something to make a new guy easily understand in his area X,Y and Z is missing and he can join the project and help collecting this data. Something like your layers of missing street names,… But not hidden somewhere (where only experienced mappers can find it) :wink:

I don’t see this as a show stopper at first. Though as it’s related to the main page of OSM, OSMF (or one of the working groups) should somehow coordinate, split the hole project in smaller junks…

So, I attempted to go further on the ideas here. Feature matching which depends on inference of near road is quite resource intensive (e.g. get near roads for all PoIs which already don’t have addr:street). Simple cases might work using Overpass, but don’t scale. I do agree it is a good idea to move for custom layers which can be pre-computed and that some layers could be more than visual hints. Let me explain.

While testing overlay layers, instead of raster (color + shape) which could be computer for everyone, I not fully aware of what expect, tested both export the roads layer and the pre-computed geojsons (which by the way, are heavily inspired on @Zverik work on OSM Conflator,https://wiki.openstreetmap.org/wiki/OSM_Conflator) of what to add on OpenStreetMap, but if using vector. No idea how vector tiles would work on JOSM, but just to mention that iD on QA layer fully expose (allowing to copy and paste) the attributes like this:

So I think most people here mention vector tiles considering merely the schema used to render them in the browser, but maybe most are not considering that, if used as overlays data layer, the editor can actually expose the metadata as if was suggestion to add/edit!!!

This is a technological difference from a decade ago (all other ideas might still be fully reusable). I mean, a raster version of a data layer with names of streets needs the user to write names manually, but vector not only uses less network, but could copy and paste the name. And yes, just copy and paste the name might not seems too much time, but for a very intense feature match whose external data already is decent (like full detailed hospital metadata from DATASUS updately monthly, which can easily have over 20 tag=values) some kinds of data layer could be not merely warnings, but on-screen suggestions for metadata :slight_smile:

I think the second biggest candidate for POI conflation listed on the Wiki (which wasn’t added to OpenStreetMap by healthcareio because it was too hard) is from Brazil, DATASUS to be more specific, which is this month’s 500mb zip file ftp://ftp.datasus.gov.br/cnes/BASE_DE_DADOS_CNES_202304.ZIP (yes, is FTP, not HTTP, but does not use password, the FTP is used by all software related to healtcare in the country which needs and work with universal healthcare here). Do exist other PoIs like schools, but often metadata rich are poorly geocoded. My argument is that it is just a matter of time to need to survey because OSM still incomplete and armchair mapping + street photos are insufficient. It would be far easier do import/synchronization on Wikidata but OpenStreetMap the position need to be exact.

The next point is mostly what might be different from what already exists and could simplify programming.

Main question: do exist vector schema for something which does not render the layer, but for QA?

While this is not a replacement for the raster layers (which without customization on editors, at least immediately allows colors) I think some kinds of conventions on the keys for the variables should only control how the editor would show the suggestions (maybe even control color), or have some tag to allow user enable/disable what information that vector layers could show.

One kind of convention that could be relevant is the following: vector layers optimized for QA should at least have a know conventions to editor know where to submit errors/false positives on the suggestions (like a URL to post comments or hint of and email with predictable title)

Use case: One kind of information (for example, in case of streets names like the ones from IBGE) is if user read the history and discover that such street was recently updated by a new municipality laws, in addition to now show (or require second confirmation) that information could be given back to the external provider. This optimizes time.

Another thing I really miss is having more than one layer (which is why I find it so frustrating to have only a single custom layer on iD). For example, sometimes both OpenStreetMap and the government layer for street names for agreed on a street name, but if getting rich PoI metadata, another layer from another agency from the government, like data from hospital or school, the street name of the PoI might be misspelled (or the suggestion have a position which that you just want feedback that such place would be a ideal candidate for survey).

In case of survey apps, a feature which editors such as iD (maybe JOSM) already is labeled as requiring survey not even display for armchair mapper could then be shown differently. But as these apps the person is near the place, the extra feedback they could do which is not merely just the exact place, but submit that the place really doesn’t exist, is a feedback that would not be saved on the main server.

Thats it!

Side comments

Anything after here is mostly are not my main focus

OdbL can have strong influence on how me and likely few others might design software to work with OpenStreetMap

What I will say might be familiar to OpenStreetMap-US attempts to increase use of OpenStreetMap and the US government, works from the federal government here in Brazil enforced by law are similar to public domain. OpenStreetMap already is quite used/updated directly, in special at municipality level, and for geocoding and other federal agencies which use OSM as base map, but groups which compile geographic Information if not at province level, definitely at federal level (e.g. IBGE), assume OpenStreetMap is not open data which they could use. And they take this very serious.

For who’s not aware of the big picture, I guess these links are good to read https://wiki.openstreetmap.org/wiki/OpenStreetMap_for_Government and joost schouppe's Diary | Using OSM to improve government data | OpenStreetMap . The last one cites one condition to not require share alike

Example 1: You notice that a street is called one name on your map and another in OpenStreetMap. You should visit the street and check the name, then you are free to put that name in your data as it is your own observation

While this requirement may seem too extreme to comply, in case of government, still feasible, because at municipality level is viable ask public servants to survey places and any new information which government already not know or have conflict which can be solved remotely (let’s say, phone= is not the same) could simply trigger manual review so the person both review on reference and then correct OpenStreetMap if necessary. So…

This license context might also give a hint of why here I might be a bit optimistic of not being hard doing survey and considering building software for any missing piece, because anything already not an import from government would need to be surveyed/revalidated otherwise collaborating to OpenStreetMap might help outsiders, but not local government which by law cannot adopt OdbL. To maximize impact, the work done on software is small compared to data cleaning. If the issue is merely building a data pipeline and have means to prove when it was plagiarized, then let me know what these missing pieces are.

Also, correct me if my wrong, but in addition of tooling to help prepare to synchronize, to minimize rework (in special because some very active mappers which decent skill to not need review do not work at government at all) the average contributor to consider not need review (again, not by quality, but for licensing) need to be known upfront otherwise this would trigger too much recheck (so asking random people which would not stay longer on OSM would take more time to do the bureaucracy than worth). And similar to Wikipedia, even people who somewhat is employee of government, they’re often do this like on their free time (like a librarian editing Wikipedia while on work computer), so I don’t believe the risks of paying explicitly anyone do add data or review conflicts with external dataset what someone else’s added on OpenStreetMap worth the risks of causing crowding out effect.

Anyway, the argument here is the following: is important to people willing to help keep specific PoIs accurate on OpenStreetMap that the government can use the work to fix own data. And I do prefer discuss this in public than have to use Wikidata as proxy and donations go to WikiMedia Foundation instead of OSMF.

Talk vs doing

I do agree. The doing part is obvious (but this takes more time to test than reply on this thread)

However, especially for newcomers like me (e.g anyone’s willing to push forward, which is quite common as several mappers also do some coding), the “talking part” if done in an objective way for those who actually attempted and seems to have failed in the past is still relevant.

By “objective”, for those who failed, I mean focus (even if opinionated) on what could do better or what assumption was the reason for failure. Not for example just assume anyone in the future will fail it try again.

For example, potentially ok or good ideas in the past without clear reason to be bad than lack of interest (for example, initial maintainers get other more interesting things to do), would be a good candidate to revive.

Rather than “revive,” I’d like to “remind” that Geofabrik’s excellent Inspector tools have been available for many years. I rather slowly make use of them to improve my local area, but over the years I have made progress. While there is nothing wrong with developing specific (new) tools (maybe they revive old tools, maybe they address new QA tasks), there is also nothing wrong with blowing the dust off of well-established, perfectly good, absolutely applicable to the here-and-now tools like Geofabrik’s Inspector tools. Try them! OSM Inspector | Geofabrik Tools

3 Likes

That’s probably because they can just be imported in mass a lot easier and safer then mapping them individually on the ground. I image most things that just be imported from exiting sources are only mapped other ways by a small percentage of subject enthusiasts because there’s no incentive otherwise. Like I mentioned how I use to map addresses doing on the ground surveying and only got about 15% coverage for my county in 6 years. Then someone came along, did an import in a matter of minutes, and now it’s up to 50 or 60 percentage and I have zero urge to go walk around for another what, 18 years to map the rest. Regardless, on the ground mapping of anything that can just be imported or mapped using AI is a complete dead end at this point and I assume people who have been active for years know that, which is why only a small preparation of them bother mapping addresses.

1 Like

tangentially related, but a few years ago I opened an issue to have a link to Rapid added to the edit drop down menu on the main site, which as I’m sure everyone reading this can guess was immediately rejected for reasons that I don’t really want to relitigate here. Except to say, it’s kind of hard for anyone but long-term, established users to dust off well-established, perfectly good, Etc. Etc. tools when there’s no easy way to find them.

Unfortunately doing a Google search for “Openstreetmap QA tool” isn’t much help. You’d have to know the name of the tool for that to be useful, which most people aren’t going to know. Sure, there’s Quality assurance, but you’d have to admit it’s rather obtuse and probably only helpful to people who like to read and know what a Wiki is. Anyway, I think you get my point. We can talk amongst ourselves about QA tools and dusting them off all we want, but the fact is that most regular users don’t know they exist or care. Let alone do new users. Which wouldn’t be an issue if the QA tools were built into the main site, or at least there were links to them from it. There isn’t even that though.

So is your average user going to “blow the dust off of well-established, perfectly good, Etc. Etc. tools”? Probably not. I’d love to see what the usage rates for said tools are compared to how many active users of OpenStreetMap is. My guess is that the disparity would be pretty large and the QA tools would trend on the extreme lower end.

My point is that excellent tools are available, and there seems to be both support and even enthusiasm for new ones that would promulgate higher quality map data. AND, (with good discussion and good tool development, we have some, though perhaps not enough) of both: we can integrate elements of any (yes, any) “strategic plan” that improves our data.

The previous points (speciously) made are that “there’s no easy way to find” (such tools), lazy searches aren’t “much help,” besides “most people aren’t going to know” (these). No assumption that a particular point is made can be reached. And we get the pouring of cold water on things with “there’s no easy way to find them” and “there isn’t even that, though.” I doubt people are heartened, cheered, encouraged by such talk. But, even “average Joes” can be motivated with the exciting promise of “hey, we’re actually working together on something and we have enthusiasm, good tools, a blueprint and a timeline.” I’ve worked on projects where we didn’t even have all of those elements, and because of other (good) ingredients, the goals succeeded wildly.

The mechanics of “links from the main site” or “built-in” (in some particular fashion) aren’t really what is important (right now). We discussed the mechanics and specifics of “a strategic plan,” and this thread went vroom! with some traction (I don’t often get six likes) when I mentioned that making the “full feedback loop” of mappers being empowered (initially) by the spark of agreement that we tackle some particular problem (like “addresses being substantially more correct, and ‘here’ in three years and ‘there’ in five years,” for example) and then coupling that somehow to our natural crowdsourcing is powerful rocket fuel. That remains true, despite one mapper poo-pooing much about the idea.

The first step has happened: such “feedback loop improvement” distinctly interests people, as I think many see it as a success chain (“we can do this, so let’s”). Second and subsequent steps would be deciding on the specifics and then coupling the mechanics of exactly what and exactly how. The latter are difficult (both consensus-wise and technical-wise), I agree. But I am 100% confident we can do so, as I have enjoyed similar success in my many years of achieving real goals in this project. On smaller scale, true, but I’ve also (more rarely) seen it work on a large scale, such as the license transition, (to a lesser degree) TIGER cleanup in the USA and other big efforts like coastline and disputed boundary consensus.

It might happen in ways similar to how I’ve suggested, it might not. Though, I’m going to say something when weak efforts blithely offer nothing but reasons why it could fail: pah!

My sleeves are rolled up, @Steve Coast. How might I help?

iD* already has 3 QA issue sources integrated (keepright, ImproveOSM and OSMOSE). It would be a small change technically to turn say OSMOSE on by default, but it just needs so much explanation and at least some experience before you can realistically expect a good outcome. IMHO beginner mappers have to digest a lot of things in general, piling it on is going to have negative effects. Even just a “potentially” missing addresses layer requires significant context to employ correctly.

* everything else is essentially irrelevant if we are discussing the entry point for future dedicated mappers.

5 Likes

Sure, I don’t disagree with that. And my point was that the excellent tools aren’t going to solve the problems that instigated Steve to create the proposal if no one knows they exist, which at least from what I’ve seen mostly seems to be case. They aren’t mutually exclusive of course. We can integrate elements of the “strategic plan” (including better QA tools) into the main site, make the current QA tools easier for the average user to find, and still use said tools. It’s not an either or thing.

I wouldn’t call pointing out that it’s currently hard for most people to find the exiting tools pouring cold water on anything. It’s just a neutral, objective analysis of the current situation. One that your free disagree with of course, but in no way does your disagreement with it mean the analysis is at all unsupportive of anyone or anything. In no way am I poo-pooing people using the tools we already have. If anything I want them to use the tools more, which is exactly why I think they should be easier for the average user to access.

Maybe I miss-read certain messages, but it seems like at least some people think building at least some basic QA features into the main site is important. I don’t think anyone is suggesting it be done right this instant though. I know I’m not, but that doesn’t mean it shouldn’t at least be part of some kind of long-term plan and that’s the discussion is about. Not immediately implementing something just because a few people asked for it in a random discussion thread. @fititnt’s work in that area above is definitely a good and interesting step in the direction of “doing” versus “talking”, but I don’t that means we can’t flesh things out more in the meantime. So I’m not sure what exactly your taking issue with. By all means roll up your sleave though. But different people have different roles to play. Mine is more to be a realist and pragmatically state what I think the barriers to entry are and brainstorm solutions. Whereas you like to go on aspirational excursions and act like a cheer leader. That’s fine. It’s not a competition and the tent is big enough for everyone. At least I’d like to think it is :man_shrugging:

  • different time
  • different data
  • different audience

We tend to forget that when OSM started up there was no dominant map provider outside of Navteq and Teleatlas for automotive navigation. Lots of things about how we use and access geodata has changed since then, and the change has mainly been fueled by google and OSM.

Now days OSM contains the thing that it was missing most back then: roads, yes there was a certain fascination with adding roads to an empty map, and you can still get that in large amounts by editing in India and China (with all the caveats associated with remote editing).

Anybody in Western Europe and the US under the age of forty doesn’t have the experience of geo data being a scarce and expensive resource as a grown up, as I wrote, -we- changed that. We can’t simply assume that the motivation to contribute to OSM for new mappers will be the same as nearly 20 years ago.

6 Likes

Maybe (certainly?) not exactly. But I’m certain that “hey, we’re doing ‘this’ together…” (by the dozen, hundreds, even thousands), whatever ‘this’ might be, has the same excitement as 20 (well, 18+) years ago when OSM was in its early days.

We’ll have to tweak whatever toolchain “excites” and gives the feedback of “a map that blossoms” (with being ‘done’ with the street you just added). We’ll have to agree among ourselves whether it is addresses, or whatever, and where those data come from, and how they are entered (just so, following at least some rough blueprint) and what tools enable this.

But the motivation, even the excitement, will most certainly be there, especially when this is “done right.” This isn’t cheerleading, it is a kind of motivating force itself, a way to steer the map into its natural future.

Maybe it’s just me, but personally I’d take it as a complement if someone said my comments were aspirational. There’s nothing wrong with encouraging people to be successful. As I think someone else said further up in the discussion we are all here because we want the platform to succeed. We just have different ideas of how to do that and we express ourselves differently, that’s not a bad thing though. As I said, it’s a big enough tent for everyone. Cheerleading is just as important as honest criticism. I could probably be a little more encouraging myself sometimes. I tend to be more analytical about these things then other people though. There’s nothing wrong with that. Again, different strokes for different folks. There is no single “right” way to communicate. At least not outside of obvious incivility, but no one is acting that way in this discussion.

1 Like

This is what fascinates me about OSM and also motivates me. Not regarding roads, but regarding tracks and paths. When I’m out by foot or bike, I still regularly find tracks and paths that haven’t been mapped yet or that are completely wrong. Even in Germany there are still forests that appear in OSM like an “empty map”.

I also know that many people use apps like Strava, Komoot, Outdooractive or other Hike/Bike-apps and often they even notice that a track or path is missing or wrong, but they have no idea that these app rely on OSM and that it would be super easy to fix these problems themselves.

If these apps could admit to themselves that OSM, by its very nature, can never be completely flawless or up to date, and they would promote the idea of OSM more to their users, that would certainly be a good way to attract new mappers as well. And maybe some of them would be motivated to participate for the same reasons I am.

7 Likes

Lots of words but other than dismissing my ideas, I’m not sure what this means. Would you like to suggest what you think new mappers are motivated by nowadays? I would argue it is the same as before. As in, people want to know that they are contributing in a way that is making a positive difference. This was easy to visualise in the past (blank map becomes map of roads). If we can find a good way to visualise it now, then we may have a better chance of recruiting and retaining new mappers.

5 Likes

A heads up: From this point on anything not tangentially related to one of the points of Steve’s plan will be exported to another thread. Any post that fits the mold of “my contribution is more reasonable and rational than yours for x reasons” will be flagged as off-topic and hidden. This type of talk does not contribute to this thread in any meaningful way. I have decided against splitting the thread as there are too many tangents to make that feasible.

1 Like

Then you might wish to subscribe to this thread: Update OSM Software Watchlist

or just use it directly: OSM Software Watchlist