Could you do a post talking through the process of locating other villages suitable for this treatment? I tried exploring the NARA archive but couldn’t make much headway.

The vast majority of NRHP properties are individual buildings, which are also worth mapping, but if you want a good concentration of buildings to map, look for entries with “historic district” in the name. Many, but not all, of these historic districts were long ago imported from GNIS as https://wiki.openstreetmap.org/wiki/Tag:leisure=park points. (The Oldenburg Historic District is missing from GNIS, so it wasn’t imported.)

If you’re looking for a particular historic district but can’t find it in the NARA archives, these pages list some alternative places to look. (Some of the linked sites have temporarily gone down due to the federal government shutdown.)

Also, it would be great to hear more details about how to translate the written architecture descriptions into 3D building tags.

The descriptions aren’t standardized; they’ll vary from submission to submission based on the author. In the Oldenburg submission, many of the terms are also found in the simple 3D buildings specification or F4’s mapping guide, for example:

• “Gable roof” is https://wiki.openstreetmap.org/wiki/Tag:roof:shape=gabled
• “Hipped roof” is https://wiki.openstreetmap.org/wiki/Tag:roof:shape=hipped
• “Gambrel roof” is https://wiki.openstreetmap.org/wiki/Tag:roof:shape=gambrel
• “Salt box roof” is https://wiki.openstreetmap.org/wiki/Tag:roof:shape=saltbox

(One of the spires in Oldenburg is topped by a German-style onion dome, but F4 apparently doesn’t render https://wiki.openstreetmap.org/wiki/Tag:roof:shape=onion.)

There are lots of details about dormers and gables. This helpful diagram appears in the specification:

Some other assorted notes:

• “Ranch style” implies a single-story house.
• A “lean-to” is a room-sized extension to the house, often a sunroom.
• “Frame” means wooden frame, but many of the buildings had brick nogging, which meant https://wiki.openstreetmap.org/wiki/Tag:wall:material=wood;brick. I don’t think renderers support that value yet.
• I was unsure how to tag aluminum siding, which was common on “non-contributing intrusions” – more modern, historically insignificant buildings that happened to lie within the historic district. https://wiki.openstreetmap.org/wiki/Tag:wall:material=metal would understandably lead renderers to pick a shiny material for the building’s faces, but aluminum siding is usually covered with matte paint.
• As far as I can tell, there aren’t established tags for windows (such as transoms), decorative elements on façades (such as lintels and cornices), or foundation materials. building:material can indicate interior structural materials, but then you have to make sure to tag wall:material and roof:material as well.

Hope this helps!

The wiki’s Ohio page suggests https://wiki.openstreetmap.org/wiki/Tag:highway=trunk based on some physical characteristics, but I think it would be more convenient to say that each of Ohio’s trunks meets one of the following definitions:

1. Urban expressways built before construction began on the Interstate system and never upgraded to freeway standards (e.g., due to space and funding constraints). The quintessential example in Cincinnati is Columbia Parkway, a four-lane, undivided, 45-mph expressway.
2. Rural highways somewhere along the decades-long process of being brought up to freeway standards, starting with limited access along rural segments and freeway bypasses around major towns (which are tagged https://wiki.openstreetmap.org/wiki/Tag:highway=motorway). Examples in Southern Ohio include US 23, US 35, and SR 32.

Unlike a lot of the trunk definitions I’ve seen so far, these definitions are intentionally flexible about grade separations, speed limits, lane counts, or length. Every urban expressway in #1 was built to a different set of (now obsolete) standards and every rural highway in #2 is in a different stage of development, yet all of them are essentially stand-ins for freeways.

Despite long stretches of simple two-lane roadway, the AA Highway in Kentucky satisfies #2; I think that would better meet the needs of map users in that rural area than any strict definition based on physical characteristics. This makes me think these definitions might be flexible enough for other parts of the country too. However, one challenge is that they require local knowledge – a bit of historical context beyond what you could necessarily glean just by driving down the road.

Just discovered the lanes:both_ways and turn:lanes:both_ways tags over the weekend – this is much better than cent{er,re}_turn_lane. 👍

The OSM mailing lists are notoriously hard to search.

It used to be a lot easier when Gmane’s Web interface was still around. If you use a newsreader like Thunderbird, you can subscribe to gmane.comp.gis.openstreetmap.region.us and search threads using the built-in search function.

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 https://wiki.openstreetmap.org/wiki/Tag:wikipedia=en:* tags – or even https://wiki.openstreetmap.org/wiki/Tag: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 https://wiki.openstreetmap.org/wiki/Tag: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 https://wiki.openstreetmap.org/wiki/Tag: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).