People do try - “unmapped small-town USA” is one that was started relatively recently.
2 Likes
I wouldn’t want to add more noise to this topic that has focused on discussing very individual solutions or implementations, but I think @SimonPoole reply here is very to the point.
When reading the proposal I found myself somewhat confused. It appears that the approach outlined in the proposal does not align with what I understand as a comprehensive strategic vision.
The notion of “completing the map” as a premise raises concerns for me, as it overlooks the dynamic nature of the mapping process. I believe it would be more effective to prioritize a vision that brings value and impact to the individuals who utilize the map.
By focusing on completion alone, there is a risk of diminishing the relevance of OSM and potentially driving users away.
1 Like
Maybe it was just my reading of the proposal, but I don’t think he meant it to be taken that literally or as the only thing that should matter. That said, I don’t it’s necessarily against the vision of OpenStreetMap to strive for “completion” of certain objects that have a very low chance to change over time. For instance major water bodies globally or state borders, which at least for state borders for all intents and purposes are essentially “complete” outside of a few conflict zones. Should we all be endlessly fiddling with country borders just so the relevance of OpenStreetMap isn’t diminished or we don’t drive users away? No, of course not. It’s perfectly fine to essentially let them sit where they lay for now unless there’s any major changes to the international order. Same goes for addresses.
As a side to that, I think there’s an expectation at least on the local level that certain classes of objects are eventually going to mapped to “completion” if mappers work toward that. And I don’t know what else we would be working towards. Incompletion? OK. How is that going to motivate anyone? I know at least for me and the people from my local area that I’ve talked to we would like to be done with roads, addresses, and a few other things we can move on to mapping other stuff. The endless cleanup in the United States of the bad Tiger import has taken more then time and energy away from other things we could be focused on. Same goes for the 100th ground survey of an address that we really shouldn’t be dealing with at this point.
I think some people’s comments come from a super privileged place where these things aren’t important to to them because the map is mostly completely where they live. It’s easy to say “completion” shouldn’t matter when for example most of Europe is already there and it’s extremely easy to fill in the small gaps where it isn’t. The “completeness” thing would probably make a lot more sense, or at least not be as easily dismissible, to those people if they considered other perspectives and areas of the world then their own.
2 Likes
My point is coming from my humanitarian open mapping experience, where the focus is on making the map useful for people to use and solve their needs, and that’s not most of the times having a 100% complete map, but prioritize mapping the elements that are most useful for local people to advance or inform the solution of their needs (i.e clean water-points mapped more important than street names or numbers, which might not even exist in a lot of places)
That’s fair. Humanitarian mapping is kind of a narrow niche though. One that, at least from what I’ve seen, doesn’t really retain users to begin with. So I guess I assumed you were talking about something else when you said that driving for completeness would drive users away. Whatever the case, I still think it’s myopic to dismiss the importance of completeness as a potential motivator or north star. One of many sure, but again I didn’t really see anything in the “plan” to indicate that was the only thing Steve Coast thought the project should focus on going forward.
That’s a good point. Everyone has different priorities when it comes to what is important for them to map. I think what instigated Steve’s “plan” was Overture Maps and a need to lose people to it, which in that case “completing” the mapping of addresses would have it’s upsides. I could be wrong, but I don’t think there’s much threat of Overture Maps syphoning off people in remote African villages who are mapping clean water-points in OpenStreetMap. At the end of the day you have to meet the problem where it’s at, and that just doesn’t seem to be where the potential threat is. It’s mainly in people using Overture Maps instead of OpenStreetMap because their address, road, and building data is more complete. Otherwise, sure. I guess “completeness” doesn’t matter that much and things can just be business as usual.
(BTW, nice to see the pro censorship people are hiding posts they disagree with. Way to be open to a range of opinions)
The idea is good, but since it’s still in its infancy I think it’s shortsighted to devote one of our most precious resources - the time and energy of the OSMF board - to it at this point in time. Rather, it’s an idea that belongs on the agenda of a Working Group or a less formal group of enthousiasts.
Any system that makes it easy for you to put your data in should make it equally easy for you to take your data out. https://twitter.com/billdollins/status/1660962579894743040
One of the significant challenges with OpenStreetMap (OSM) is the difficulty in splitting the data into smaller, manageable areas and keeping up with updates specifically for those areas.
See more here – Problems with maintaining the regional extract in an up-to-date state - #10 by andygol
OSM serves as a centralized repository of global geospatial information, encompassing a vast amount of data from all around the world. While this comprehensive dataset has numerous benefits, it can present difficulties when attempting to extract and maintain data for specific regions or smaller areas.
For local communities, organizations, or businesses that have localized needs, managing the entire global dataset of OSM becomes unnecessary and cumbersome. Extracting only the relevant data for a particular area can be a time-consuming and complex task, requiring substantial effort and technical expertise. Furthermore, once a subset of data is obtained, it becomes challenging to keep it up to date with the ongoing updates and changes in the global OSM dataset.
Staying synchronized with these updates for a small, localized area can be demanding, especially for individuals or organizations without dedicated resources or technical support. The process of monitoring changes, merging updates, and ensuring data accuracy becomes a considerable challenge, potentially resulting in outdated or inconsistent data for the specific area of interest.
Addressing the problem of data being a single pool that is hard to split and keep up with updates for small areas requires a multi-faceted approach. It involves the development of more efficient tools and techniques for extracting localized datasets, refining existing data management workflows, and enhancing collaboration within the OSM community.
Improving the accessibility and usability of tools specifically tailored for extracting and maintaining localized OSM data would greatly benefit individuals and organizations working on smaller scales. These tools should simplify the process of selecting and retrieving data for specific areas, automatically track updates, and enable seamless integration of local updates into the larger OSM dataset.
Additionally, fostering collaboration and knowledge sharing within the OSM community can help address this challenge. Encouraging the development and adoption of best practices, guidelines, and standards for managing localized data would enhance the ability of users to maintain accurate and up-to-date datasets for their specific regions.
The cohesive nature of OSM’s global dataset poses a challenge when it comes to splitting the data and keeping up with updates for small areas. Overcoming this problem requires the development of user-friendly tools, refining data management workflows, and fostering collaboration within the OSM community to ensure that localized datasets can be effectively extracted, updated, and utilized.
Reevaluating the OSM data model and data storage infrastructure is crucial in order to effectively address the challenges discussed above. For those interested, there is is my ideas about organization data storage and processing - OpenStreetMap 2.0 API using git.
1 Like
It is at least a teenager.
Thank you for rephrasing this. I do agree with the point that the densely and relatively well-mapped countries of Western Europe likely impart their communities with a different perspective as to the priorities of the map compared with the rest of the world.
2 Likes
@Adamant1, posts are not hidden because of differences of opinion. They are hidden due to violations of the Etiquette Guidelines, such as ad hominem attacks on community members. That is not censorship. It is enforcement of the Etiquette Guidelines.
Since you removed the ad hominem attack, your post has been unhidden, and your opinion is again available for discussion.
2 Likes
Maybe I’m wrong about this, but from my understanding posts are hidden if someone flags them, which can be just because they disagree with what was said in the message. Sure, it can be un-hidden later after it’s reviewed by an administrator or edited by the user, but it’s not like someone flagging a post as inappropriate guarantees that it actually is. Nor at least from what I’ve seen does it really matter if the user edits out the “inappropriate” part of the message for it to be un-hidden again. Although I guess it could be re-flagged in that case, but it doesn’t negate my point. That said, I’m no expert on how the system works either. So I might be completely wrong 
As to if it’s censorship or not, I think it is on the part of the person who originally flags the message. Censorship as in the message being suppressed. Since that’s literally what happens. Does that mean the platform is intentionally going out of it’s to prohibit certain opinions? No, of course not and I never claimed it was. I think people would do well to not read bad intent behind we say that isn’t there. Censorship is a pretty offensive word unless the person reading it is easily offended and wants to fear monger about the platform being authoritarian or something. That’s not how I meant it though. It was just the word that came to mind at the time to describe the situation. Nothing more, nothing less. Hopefully I’ve clarified it now so the conversation can get back on topic instead of being about me or needlessly scrutinizing what I said 
False about how posts are hidden. For the record flagged posts are not automatically hidden. However, when a post is flagged, it is brought to the attention of moderators. After reviewing the flagged post, the moderators elect to hide the post if it is determined to be in violation of the etiquette guidelines.
Can you please show how to do “well-crafted Overpass query that does the same thing?”? I didn’t had time for think about it yet, but I could be useful to match with external datasets what already exist in OSM as poorly geocoding can be more wrong than street names, so both algorithms could be used.
Thanks!
1 Like
That one is quite easy as to answer: speed 
That one is trivial to do: overpass turbo (needs to add more tiger tags, but the principle is the same).
That one is more difficult (and even slower), and involves use of sets, around() and an iterator (could probably be done smarter, but I’m just a beginner in overpass queries): overpass turbo
If you want to make a map that only has roads that meet certain conditions, that’s easy:
Query for highways with a surface tag
Query for highways without tiger: tags
A comprehensive analysis of addr:* tags is beyond my Overpass skills, but you can query addresses in an area and then perform an analysis in many ways, e.g. with QGIS. I tried to show an example query with MapCSS, but unfortunately MapCSS doesn’t like it when I try things with [!"addr:postcode"].
You can also use a query with MapCSS to show where certain tags are still missing.
With speed you always lose accuracy. In this case that means you’ll have to generalise, and you don’t have the benefit of being able to filter out all the corner cases. A map that only shows roads that meet certain conditions may omit highway=busway completely, whereas in Overpass you have full control over the tags you choose and do much better and more complete QA.
Steve really doesn’t have to convince the OSMF to build their strategy around “completing” the map.
I already helped out TomTom with precisely this topic this way by querying motorways without a surface tag, downloading them into JOSM, following these roads on Mapillary to define the surface and then tagging 130 km of motorways in one session, making most of their MapRoulette challenge for this theme obsolete. I say this to make my point that we already have all the tools we need to do this.It would therefore be a waste of resources to devote OSMF resources to problems that will solve themselves. On top of that, there isn’t even a proper definition of “complete”, because this is totally different for each user/consumer of OSM data.
See also the query I sent in my previous message.
Interesting. Do you know how to do the opposite for QA purposes?
1 Like
Um, not really. Even if you changed your renderer on a daily basis and dropped all previously generated tiles every time (so they will be generated from scratch by new/updated rules), this would still be several order of magnitude faster and more efficient than if each editor hammered overpass API servers with queries on different areas over and over again on each area download.
I’m just saying overpass is slow. Horribly slow compared to rendered TMS.
Note that I’m not taking defensive position for Steve Coast idea of “empty map” here (although I do think his idea of showing OSM Notes by default is good; and definitely should be enabled – it is simple to do, simple to revert if need be, users can easily opt out with single click, and it should help clean up the notes and update the map, and would be a good forecast if more drastic changes to the map might be good idea or not. So win-win in any case. But if not even that simple “Notes enable by default” idea is tried first, there is no point for even considering bringing any more drastic ideas into the picture - that would just waste manhours on creating outrage and noise, as we can already see 
).
Maybe? If you lay out clearly what you want to accomplish, I can give it a try (if it is not beyond my abilities). There are many “Overpass as QA” examples around, what I do most of the time is try to mix and match them to get result that I want.
Ha! Tell that to the Carto maintainers who avoid doing DB rebuilds at all costs, including the cost of not having highly requested features on the map.
I agree.
Your previous query is about finding addresses where addr:street matches the name of a nearby road. For QA I’d like to have addresses where that’s not the case.
By the way, just a quick update. And I’m sad with iD because not viable know several spots which really have no name as default editors don’t help this easily 
QA layer on iD for streets without names / building without addresses
While the http://qa.poole.ch/ layers (which to my knowledge are great to signal for example near exact issue which Steve point out) are on https://osmlab.github.io/editor-layer-index/, the iD does not have some button to users enable it.
If I’m wrong, please someone correct me, but not even the QA group of iD shows this as an option.
QA layer on JOSM for streets without names (TUTORIAL)
It works! But is not default. Here the step by step images
josm_qa-noname_1.png
josm_qa-noname_2_filter-by-poole.ch.png
josm_qa-noname_3_click-activate.png
josm_qa-noname_4_QA-noname-is-on-list.png
josm_qa-noname_5_on-main-windon-select-imagery-them-QA-no-name.png
josm_qa-noname_6_done-missing-roads-are-red-now.png
Edit
For / building without addresses on JOSM, on step 2, select a different layer from the filtered poole.ch (in English is “QA No Address” but other languages have other names)
Update: this was simpler than I thought with this Overpass query, although I admit it can probably be done more efficiently.