Thanks, maxerickson, that’s a good tip! Does Mapwarper require the uploaded images to be openly licensed or in the public domain?

Relation Analyzer can be useful for detecting gaps in a route relation after the fact.

I had to find a named object near the origin and an other one near destination, type the names and hoped it finds the right places.

Note that you can also drag the green and red pins next to the To and From boxes to the route’s start and destination. This context menu is more convenient, of course – thanks for this improvement, mcld!

Now how do I mark a particular tile dirty? Before I could do Open image in a new tab and mark it…

In Firefox, you can go to Tools ‣ Page Info, switch to the Media tab, and look for the tile you want to dirty. You can also use this tool to determine the coordinates to insert in http://c.tile.openstreetmap.org/{z}/{x}/{y}.png/dirty. See this article for more details on tile URLs.

Ideally, only mappers would ever see the original, unlocalized link in their editors or perhaps on osm.org, whereas people using OSM-based tools would always see a link to an article at the Wikipedia of their choice (based on a language preference and interwiki links). I suspect that’s already the case, but if there are tools that link users to Wikipedia without taking advantage of interwiki links, it would benefit everyone to have that bug fixed – not only speakers of the three official languages, but everyone else too.

I haven’t witnessed edit wars over languages on OSM, but I’d imagine that they’d be edit wars over name tags rather than Wikipedia tags, which are a bit more obscure. If things get too tense, it seems to me that the solution would be removing the Wikipedia tags in favor of a language-neutral wikidata tag, which many data consumers can handle just as well. Wikidata has the benefit of being more immune to article title edit wars that actually do happen at Wikipedia (Gdansk/Danzig, anyone?).

@escada, what’s the practical benefit of having wikipedia:fr and wikipedia:nl on the same feature? If the intent is to practice language neutrality, wikidata is the ultimate language-neutral tag. I don’t think mappers should feel any obligation to pair each name:* tag with a corresponding wikipedia:* tag.

For context, a great many of the original wikipedia:* tags were added with WIWOSM in mind. WIWOSM, which predates Wikidata, happily takes a wikipedia:de tag and displays a link to an English Wikipedia article that it discovered via an interwiki link. What wikipedia:*-consuming tool doesn’t do that? Would unlocalized Wikipedia links even be useful to an end user? (WIWOSM now recognizes wikipedia and wikidata tags as well, by the way.)

Personally, when I map places in Vietnam, I’m perfectly comfortable with seeing wikipedia=en:* tags – or even wikipedia=zh: tags in the disputed South China Sea – because I know the data consumers will localize as needed, and it takes only a couple clicks to verify that the tag is correct in terms of providing access to the local language’s Wikipedia article on the subject.

I use my real name here, nothing fancy. But when I first joined the project in 2008, my first inclination was to use “Minh Nguyễn”, diacritics and all. A week later, the old Tiles@Home Osmarender style updated with my first edits. This style used to display a tiny copyright notice next to every road at z17 that credited the last editor, but each of the roads I touched instead said “© Minh Nguyá»…n”. Frustrated with the mojibake, I stripped the diacritics off. Thankfully it’s so easy to rename yourself at OSM.

In the urban screenshot above, the HIFLD hospitals would probably correspond to hospitals that were originally imported into OSM from GNIS, usually (but not always) with “(historical)” in the name tag. A lot of them have been cleaned up (usually deleted) in urban areas, but GNIS cleanup continues in rural areas.

Historical GNIS POIs are common for schools and post offices, too. Before OpenHistoricalMap started, I made a habit of retagging these POIs with historical=yes (as long as they didn’t represent extant, repurposed buildings). Using HistOSM, you can get a sense of how prevalent these POIs are in the parts of Ohio where I did GNIS cleanup.

none of the mainstream stylesheets depict pictoral route shields or even badges based on route relations

Just to be clear, I’m referring to road route relations here. I’m aware that OpenCycleMap uses route relations to badge cycle route numbers, but for roads there’s a lot more to consider than three network values.

@pnorman, if it’s indeed fairly trivial to support route relations, then that’s really encouraging to hear! I was rather commenting on the fact that none of the mainstream stylesheets depict pictoral route shields or even badges based on route relations. If pictoral route shields are out of scope for openstreetmap-carto, what would it take to get the OSMUS Shield Renderer or a more robust successor onto osm.org as an alternative layer?

Elliott, using the postal abbreviation as you describe is the most common approach, in part because of (in my opinion shortsighted) concerns about renderers being able to choose the right state shield without using spatial queries or route relations. In a few states, such as Ohio as I mentioned above, the convention is to use the SR prefix instead to reflect the facts on the ground. I don’t know what the right answer is for Maryland.

Tagging refs on both the relations and their member ways may seem redundant, but both types of ref tag serve a purpose: route relations allow us to unambiguously indicate the network, signposted cardinal direction, and other information about a route, and it’s a cleaner way to indicate that multiple routes travel over the same way (known as concurrency or multiplexing). Meanwhile, for concurrencies, the ref tag on a way can say the order in which the routes are signposted (because one of the routes on a given way is the primary one that influences the mile markers).

For now, no mainstream renderer or router knows how to process road route relations. (OpenCycleMap and Lonvia’s map do process cycle route relations.) For that reason, we’re kind of stuck in limbo, having to tag in both places, one to ensure that the map is still usable, the other as a sounder long-term strategy.

Are you referring to the map at mapquest.com? At a glance, the U.S. portion of that map appears to use a proprietary data set rather than OSM. Due to how OSM route data is formatted, OSM renderers require regular expressions or spatial queries to select shields half decently, at least until relations are fully supported. But it’s entirely possible for other data sources to be formatted in a way that OSM mappers would balk at but that renderers would find more straightforward.

In the past, the OSM community made a lot of tagging decisions that were largely driven by a need to make it comfortable and efficient to type out raw tags by hand. These days, those considerations are less important, now that the most popular editors all rely heavily on presets to maximize discoverability.

Parallels can be found in other aspects of tagging too. For a long time, proponents of route relations met quite a bit of resistance from mappers who felt that they were tedious and redundant to information already found on each way. But as we increasingly need to express additional information about routes, and as ways get split more and more granularity for lane tagging, resistance to route relations has become less vocal – at least in the U.S., where there’s a demonstrated need for them.

The multicombo UI in iD produces exactly the type of tags that BushmanK is arguing in favor of (multiple tags with colons in the keys). But visually, it’s all on one line, so it’s more convenient to work with this UI than it would be to type a semicolon-delimited list (since the control can autocomplete each item in the list). I would hope that everyone involved in discussions about the OSM data model keep in mind the needs and benefits of intelligent editor software.

I knew I’d be called out for hand-waving! My idea was more to drive home the idea of an ever-more intricate map and a constantly rising standard for mapping, not so much the technical aspects of mathematical fractals.

Borges’ 1:1 scale map, which folks in the OSM community bring up from time to time, may be a warning about maintainability. But I think it’s also an argument that there’s real value to the work that armchair mappers produce – an abstract yet super-detailed representation of the world’s infrastructure – in an age when software may be able to automatically generate more realistic, point-cloud-based 3D models of the same infrastructure at greater scale, but with fewer insights. Hopefully that wasn’t too much psuedophilosophy for a late night. ;^)

See also this talk-us thread from a year ago.

The two nodes detailed in the above screenshots were added by users of JOSM and iD, respectively. Although it sounds like this is a case of correct tagging, you could imagine that imprecisely translated presets in these editors could lead well-meaning mappers to mistag features en masse. In translating the Rails Port and iD into Vietnamese, I found it fairly tricky to come up with simple translations for the various highway and place preset names that capture all the nuance OSM has assigned these English words. Hopefully the people translating the editors at translatewiki.net, Launchpad, and Transifex are all experienced mappers.

Here’s the most recent discussion on the talk-us mailing list (crossposted to talk-ca). It sounds like natural=coastline is indeed preferred by the community.

The Wikipedia community does this kind of outreach via public user talk pages, which has tradeoffs. It prevents multiple users from spamming the new user exactly the same way (which is probably a good kind of problem to have anyhow), makes it easy to have small group conversations, and makes it clear when a lot of talking is happening. On the other hand, the private message system here on osm.org is great for one-on-one guidance, especially for timid users who’d rather not post their first-day questions for all to see. So a checklist tool would help to make sure no one falls through the cracks. (I just hope no one decides to then automate the process with bots the way Wikipedia has!)

Beyond the initial mentor system, I agree with Omnific that we need a better communication channel for the kinds of groups that form around a city or (in less-mapped countries) a region. None of the mappers in my area are willing to spam the country list about regional issues, and I think casual mappers would be more willing to join a Web-based discussion group than subscribe to a mailing list or join an IRC channel. Offsite services like Facebook have very little visibility on osm.org. An OSM wiki page might work for this purpose if it were federated with OSM logins and made it easier to follow discussions (like with the Echo extension Wikipedia uses).

I often wish there was a way to look at a map and filter on the type of POI. Perhaps I want to look at all restaurants or all schools.

ITO Map has domain-specific maps for this kind of thing. If you’re interested in accessing the raw data, overpass turbo has a wizard that generates basic queries for you and allows you to visualize the results.

smsm1: I’ve been mapping in areas that have enough work left to do that even removing tiger:reviewed=no tags is too tedious. However, it does sound like really well-mapped communities will eventually want some way to periodically mark features as reverified without making perfunctory edits.

rayKiddy: I was writing about San José proper. Some of the Peninsula cities are reasonably well-mapped, as you’ve observed. I wonder why such a gap in coverage developed between San José and its suburbs.

The issue of boundaries comes up on the talk-us mailing list fairly regularly. Some mappers have advocated mapping special-purpose districts (like school districts), while others have argued that boundaries generally should not be in OpenStreetMap. The disagreement arises because you can’t always spot a border on the ground to verify it, unlike much of the data in OSM. In the case of city limits, you can almost always find a marker along the road; by contrast, school district boundaries are rarely marked. (Fire districts sometimes are, depending on the jurisdiction.) Personally, I wouldn’t really mind seeing school districts mapped as boundary=school relations, but expect a lively discussion when you are ready to formally propose importing this data.

Potlatch 2 is still unusable in Shumway due to missing text input support (GitHub issue, Bugzilla).