Sorry, that was cryptic of me. F4Map apparently uses crown_type=I to mean palm tree. I only found out by accident when looking at the browser console, desperate to get a palm tree to come out.

Actually the solution is: “Make it like F4map.org”, because most existing edits are “tagged for the F4-renderer”. But as it is closed source, we have to find things out by examples.

All I have to say about that is:

🌴

the pre-processed cascading was intended for the days before data-driven styling and is probably less crucial now, so could perhaps be dropped.

Yes, in general, you’d want to minimize the number of layers in the stylesheet for performance reasons. For example, if you can draw roads using only one layer, then the style’s size and power usage decrease dramatically and rendering becomes noticeably smoother. The two obstacles are some properties’ lack of support for data-driven styling and some tilesets being overstratified into too many layers.

Other style projects like openstreetmap-americana have taken a different route. Their developers have written a program in JavaScript that generates the style.

The Americana project has certainly run with this idea, but it started with some very specific pain points, which code generation or preprocessing helps to mitigate but doesn’t solve completely:

1. Some features like roads and railways need to be repeated, along with accessory layers like casing and dashes, in order to depict vertical order (i.e., layer=*).
2. line-dash-array doesn’t support data-driven styling, so the very many kinds of railways need very many separate layers.
3. Route shields are implemented as icons generated on demand per route for more fine-grained text layout. (These modifications don’t make it into the generated style JSON.)
4. To conflate name=* with a dynamically selected name:*=* for our glossed labels, we needed to parse semicolon-delimited lists. This requires basic text processing functionality that was declined. Instead, we reimplemented string find and replace by generating a string tokenizer made of recursively nested slice and case expressions. 😱 In principle, some of this work could be offloaded to a tile server that returns personalized tiles, but that would reduce the tile server’s portability.

The more we can streamline these steps in static style JSON, the more portable Americana would be, especially to other platforms.

Having to repeat definitions instead of using a variable.

Something like a color or symbol definition might appear a dozen times in the style. If you want to change it, you need to make sure you got all the occurrences.

For what it’s worth, this MapLibre proposal would introduce the notion of global state, which effectively also allows for design-time consolidation as a side effect. If it goes in, it could simplify your preprocessor somewhat. It could also reduce the need for maintaining (or generating) separate styles based on color scheme.

Lately I’ve been taking to calling it “fudging the data”. 😋 A bit less accusatory, but still gets the point across that one is playing games with the data out of expediency.

The page was briefly renamed to “Lying to the renderer” in order to more clearly limit the admonition to data hacks. But it soon got renamed back to the original title because “lying” sounded too accusatory and most people had gotten used to saying “tagging”. Imagine commenting on a new mapper’s changeset, saying they’re “lying” – not a particularly welcoming message.

That said, “Tagging for the renderer” remains a widely misunderstood phrase. The gist of the article is that we need to balance the needs of all kinds of data consumers, current and future. Essentially that means preferring semantically accurate mapping over something more presentational and shortsighted.

Good idea. “Ignore this issue” is an accurate description of what happens, but some users may perceive ignoring to be an act of laziness or even malice, whereas it can actually be more neutral than that.

“I don’t know” would be similar to the options available in StreetComplete and MapRoulette, two alternative editing environments that prioritize human factors in their workflow designs. “Can’t be determined at this time” isn’t terribly verbose. There’s already a “Not the same x” option on the warning about missing brand tags, where x is an arbitrarily long brand name. If it gets long enough, it simply wraps to the next line.

Please open an issue in the iD issue tracker so it can be triaged and given further consideration. Thanks!

Thank you for this important message. Validators work with very little context and even less intelligence. This goes for not only iD’s validator but also JOSM’s, Osmose, etc. “Ignore this issue” is absolutely a valid response. If something is so bad that you shouldn’t ignore it, it would be an error and iD would actively block you from saving your changeset.

I’ve been concerned for years about the tendency for these issues to become “gamified” because mappers perceive HDYC as their permanent record, as if editcountitis wasn’t enough of a problem. (At this point, I wear my Osmose issue count as a badge of pride.)

Aside from possible UX improvements to iD, we should figure out how to identify any bridges or culverts that were created hastily or carelessly. By default, the “Add a bridge” and “Add a tunnel” suggestions create bridges and tunnels of a certain length based on factors such as the tags on the crossing way and the angle of the crossing. When iD introduced this feature, the developers expected the mapper to manually adjust the bridge to match the real-world length. However, this is unlikely to happen if the mapper can’t see the bridge in imagery. Maybe we can reverse-engineer these heuristics in an Overpass or QLever query.

I very belatedly noticed this diary post after you recently mentioned it on a forum thread and someone later pinged me.

I’m the one who added the entry for Avalon to NSI. Avalon not only develops and owns apartment complexes but also heavily brands everything about them. The monument sign out front is just the start of it. When I briefly lived at an Avalon apartment complex, their then-ubiquitous fleur-de-lis-like logo really came to aggravate me.

The only reason this brand goes with landuse=residential is that landuse=residential residential=apartments is the de facto tagging combination for a multi-structure apartment complex. Fortunately, only a few other “apartment chains” McDonaldize apartment living to such an extent. It’s nothing more than an annoying edge case.

Back in 2008, when the community simultaneously voted on highway=road and highway=path, we mapped these features based on field surveys, GPS traces, and Yahoo! imagery that was barely legible at zoom level 17 in the U.S., to say nothing of Europe. We couldn’t be as nitpicky about navigation mapping as we are today. Yet at the time, some countries’ tagging guidelines insisted that tags such as highway=primary and unclassified were strictly tied to official designations, which may or may not be signposted. This created a situation where someone could have valuable data to contribute to OSM but be unable to express it.

In part, highway=path had the same motivation: someone could see a path in GPS traces and be sure that it wasn’t a road, given its location or curvature, but unsure whether it was intended for pedestrians, cyclists, or horseback riders. Neither of these proposals accounted for the idea that someone might need to trace some smudge in imagery without knowing whether it was a road or path… or aeroway or waterway. The advice would’ve been to leave a note in OpenStreetBugs or MapDust instead.

highway=path was simultaneously approved for shared use paths. So even though most countries have relaxed their road classification rules and we can see more clearly in street-level imagery, highway=path has endured while highway=road was largely forgotten – until someone noticed that the latter got redefined to include paths.

Anyways, sorry for digressing. As you were saying: the couple married and rode off into the sunset… on a golf cart path. 🤪

So much has been written about how to distinguish one kind of path from another, but the truth has been staring us in the face: everything is a footway.

A set of steps is just a very bumpy footway on an incline. A cycleway is just a footway along which your feet push pedals. A busway is just a footway along which you stand, feet astride for stability, because all the seats are occupied. A motorway is just a footway along which your lead foot slams the gas pedal and never lets up.

The only exception is bridleways: you don’t really do much of anything with your feet, other than sticking them in stirrups. And obviously the horse has hooves, not feet. Yet in my country, all of these ways – even the bridleways – are measured in feet.

Based on the source tag, that building probably came from the French cadaster import. Many government building datasets have errors of this sort because the data collection is based on remote sensing technologies like LiDAR. Cleaning up these errors is the very reason why imports are more difficult than simply loading the data and uploading.

Whether an external building dataset comes from computer vision, machine learning classification, LiDAR, or other automated techniques, data consumers tend to prefer OSM data wherever it’s present because we’ve typically paid more individual attention and performed quality control on it. If you use an automated dataset in your product, you need to filter out low-confidence features or else you wind up with an impressive statistic but lots of junk.

It’s not just buildings. Every now and then, a navigation software vendor gets the bright idea to detect one-way streets automatically based on whether they have telemetry of people mostly going in one direction along the street but hardly in the other. Great – finally solved the problem of routing people the wrong way down a street! Invariably, they have to back away from this approach, because it turns out that many one-way streets don’t have the traffic volume needed to make a confident prediction about the traffic direction. Instead, they get complaints about having to circle around the entire city just to turn right. This data still makes for a great QA tool with a human in the loop, but it’s only a matter of time before someone sees that QA tool and gets a bright idea…

I’m guessing this is the Microsoft building dataset, which applies computer vision to aerial imagery. Some data consumers like Mapbox and Overture Maps are using this dataset to backfill areas where OSM building coverage is lacking or nonexistent. From their perspective, the increase in coverage in places with fewer OSM mappers probably outweighs individual bloopers like this, and I guess from our perspective, we’d rather not face a bulk automated import of this dataset due to these bloopers.

Another thing that commonly occurs is that a building has been demolished, so we’ve deleted the building from OSM. But a data consumer working off outdated aerial imagery can’t distinguish that from a never-before-mapped building, so it restores the building from the Microsoft dataset. Of course, a human mapper could make the same mistake if they happen to be using the same outdated imagery with no local knowledge.

To address both cases, I’ve gotten into the habit of retagging buildings as demolished:building=*, at least until the local default imagery layer gets updated. These data consumers will omit any Microsoft building that intersects a building one OSM, so I hope they’ll do something similar with demolished:building in the future. This key also has the benefit of serving as a to-do list for OpenHistoricalMap and as a pre-cleanup step for any building import planned for the area.

In theory, we could go around mapping no:building=yes for thr buildings on wheels you spotted, but my hands are full already without worrying about something that Microsoft could fix by tuning their noise filter.

Yes, this page and the main “Names” page could use a thorough rewrite. There are a lot of intentional nuances in the text that matter but need to be organized better in order for readers to come away with what they need.

The article uses “primary name” in order to give an idea of when to use name versus some other name-related key such as name:en or alt_name. All of these keys hold proper nouns, or proper names as you put it, so replacing “primary name” with “proper name” would be correct but beside the point.

Excited would be an understatement! I know it’s just a demonstration with no guarantees, but it just came in handy for the epic abandoned railway discussion we’re having. It was super simple to take your demo and extend it to demonstrate a mashup of minutely OpenStreetMap tiles and minutely OpenHistoricalMap tiles. There’s nothing quite like a live-updating, interactive map to convince others that it’s more than just talk.

The possibility of minutely updates was one of the nice things about Sophox back when it was functional.

Sophox is functional again!

I see. The possibility of minutely updates was one of the nice things about Sophox back when it was functional. It also queried Wikidata directly instead of keeping a local copy, at the expense of running time.

Have you checked out QLever yet? It’s a fast alternative for federated queries on the server side. This diary post provides some examples to work off of.

I think setting it up would require as first step to dump the data items as RDF but I can’t find any documentation on that in the wiki.

You can get a full dump of the wiki’s pages and data items from this directory. I added a passage about it to the wiki page.

To your first point above: the close button on the banner was not about you. A number of us experienced the bug, yours truly took the time to calmly report the bug, you had some suggestions for fixing it, and it got fixed a different way. I’m sorry it didn’t get fixed in quite the way you suggested. Personally, I was pleasantly surprised at the turnaround time, and I don’t see any motive behind the bug that can be tied to the incident about AWS credits.

To your other points: I’m just a simpleton to whom clouds are welcome relief from the incessant sun in this part of the world. Simpletons like me don’t know what to do with all this melodrama.