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.

And so, as of carto 5.4.0, all of these details are now visible in the standard rendering. This can make a pretty big difference in how golf courses appear.

It’s not perfect, but in my eyes it’s a big improvement. One remaining criticism I have is that there’s not a lot of contrast between the new blue-green of a golf=green and the blue of a water hazard, so in some cases it can be difficult to discern the difference between where you’re putting and what you’re avoiding. But overall I’m very happy with the changes, and learned a lot about the considerations and thought process behind the colors and symbols in carto.

Follow up work would include getting iD to change its tag-suggestion behavior, and perhaps picking a new shade of leisure=pitch that’s a little bit further away from water. Of course, as I learned, even something as seemingly simple as changing some colors takes a lot of thought and consideration.

Thanks to Christoph Hormann, Paul Norman, Joseph E., and Paul Dicker. They were all extremely helpful offering feedback, answering beginner questions, and giving extra context on why decisions were made. This was my first PR, and I’m extremely happy to get it across the finish line.

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.

Just north of that installation is an even better example – “Standing Stones” comprises six separate enormous blocks of granite distributed all across the front lawn of the museum. Again I wasn’t sure what made the most sense, so I tagged one of them and called it good.

By the third time I found a multi-piece sculpture, I realized I needed to figure out a better way to handle mapping. I had gained a little more confidence in OSM concepts and had switched to using JOSM for serious editing, and realized that a relation would probably make sense here. Unfortunately, the wiki makes no concrete recommendations on using relations with artwork.

A little bit of searching did reveal a mailing list post that implied I was on the right track:

2014-04-02 16:56 GMT+02:00 Andy Mabbett

There is also the case of sets; for example, four carvings which form a single artwork, but which are mapped as separate entities.

2014-04-02 21:34:39 UTC Janko Mihelić

You could put the four carvings into a relation, and put the wikidata tag there (along with the name=* and tourism=artwork).

I took that as validation that I wasn’t totally off-base, and set off to make it work. The first thing I found was that relations need to be given a type. What kind of type makes sense for a group of sculptures? The only one that didn’t seem obviously wrong was “site”, so I went with that.

After making the update, I realized I should have checked to see what everyone else has been doing. Taginfo verified that yes, people have been using relations with artwork. And the handy link over to overpass turbo revealed an example (relatively) close in Chicago.

The Chicago result was actually very similar to what I had wanted to do – group more than one sculpture together. I was gratified to see the relation type was the same as what I had settled on. In this instance, each node in the relation was also tagged with tourism=artwork and artwork_type=sculpture. This made more sense to me than leaving them bare, so I added the tags to my relation members as well.

Most of the other examples of relations used for artwork were multipolygons rather than groups of distinct pieces. But there were a couple other instances of site relations of artwork, so I felt justified in the mapping scheme I arrived at.

Now I need to back and update the first two scuptures to use the better solution. I do wish there was a more appropriate relation type than “site”, but I suppose it will do.