Almost one year ago, I decided to take a crack at fixing something that bugged me in the way golf courses were rendered in carto. And now that fix – or what it evolved into – is finally merged and getting deployed!

If you look at the wiki page for leisure=golf_course, you’ll find a rich vocabulary for how to (micro)map many aspects of the layout: tees, holes, pins, bunkers, so on and so on. And in many of these tags, there’s an admonition: don’t tag for the renderer just to get these features to show up. Naturally, mappers will do what they want to do, and most fairways, greens, and bunkers have accompanying landuse=grass and natural=sand tags. In fact, in iD, creating a fairway, green, rough, or tee automatically adds landuse=grass to the tags. Likewise, bunkers add natural=sand.

This is useful for making a case that carto needs to render these tags, and that there’s a general agreement on what they should look like. After much back and forth and discussion in the PRs, a consensus emerged. golf=tee, fairway, driving_range, and rough would get the same fill color as landuse=grass. rough would also get a subtle pattern on top of its fill to highlight the different length of grass. The green would get a darker shade to differentiate it from the surrounding fairway, and so golf=green would get the same color as leisure=pitch. And golf=bunker would get a natural=sand color.

On top of that, agreement was reached on rendering golf=hole, a line that shows the playing path, along with a label of its ref or name. And finally, the actual location of the hole – golf=pin – would get an icon, labeled where applicable.

One final change was updating the fill of leisure=golf_course. The original green background was a single-use color. Carto is already a green-heavy color scheme, and the opportunity was taken to remove one shade, instead using the same color as campsites.

… See full entry

I saw on the OSM-talk mailing list that Osmose is now available for North America. This is a great tool for finding issues with existing OSM data, and the interface is chock-full of helpful links and functionality. I was able to get off the ground almost immediately, starting from a position of no knowledge about Osmose whatsoever.

Most of the errors it finds are described pretty well, and the links to the OSM wiki help fill in most of the blanks. I was able to fix quite a few little problems around my city.

One error that I haven’t been able to figure out is one of the multipolygon-category errors: “Should be polygon or part of multipolygon”. The wiki describes it thusly:

Class 4 “Should be polygon or part of multipolygon” : the nature of the way indicates that it is a surface, the way would be a polygon or of a part of a multipolygon as outer role.

It may be the translation that is making it difficult for me to parse that. The places I see this error are almost all buildings, but not multipolygons. I don’t really see any obvious commonalities between them, or differences between them and other nearby similar buildings. In one case, the error references a landuse=residential.

Can anyone shed light on this error? Can these examples be marked as false positives, or is there some aspect of these ways that trigger the error?

There are three sculptures within biking distance that are actually composed of separate sculptures, but named and presented collectively. What was the correct way to tag these, I wondered? Sculptures are pretty straightforward to map but these didn’t seem to directly map to the concepts of points, ways, or areas.

Photo by Phil Roeder (CC BY 2.0)

The first time I ran across this was with this piece at the Des Moines Art Center. As the name implies, it’s actually three parts that are not physically connected in any way. At the time I had only a vague notion of what a relation was in OSM. It didn’t make intuitive sense to tag each piece with the same data, duplicating information. So I just dropped a point on the center piece of the artwork and moved on.

… See full entry