In your sample rendering the drawing order of the roads looks odd, kind of random.

It is in fact random, because Tegola is trying to do some things it shouldn’t with queries which makes ORDER BY hard to use in queries. This is similar to how a bad Mapnik query can result in a sequential scan on start-up. Because Tangram is a lot more flexible with ordering than Mapnik thanks to its GL origins, I could avoid needing to ORDER BY within a layer by including a z ordering within the query output, but I don’t like this technique as much.

Road ordering is important for using the map, but doesn’t impact designing the cartography of the rest of the features, so I’m leaving the issue aside until it becomes more important or the Tegola bug is resolved.

I find it easier to express cartographic design once I have a baseline to work on. A few things I want to experiment with are bringing back stronger road colours, stronger casings, and how much I want to vary road thickness by classification.

But now it’s obvious that nobody knows where to go next. Well, Paul Norman gives talks exactly about this for two years.

Please don’t use my name this in support of your views, which my talks do not support.

Shocking loss of work. There has to be a better way to revert than just deleting the work of everyone.

Not to diminish the work you all did, just horrible that DWG couldn’t save any of it, such as at least the tags that have been added over the years (not in the original import). There has to be a less ham-fisted approach to reverting data.

The redaction code saved as much as was possible. The problem is that there wasn’t much that could be saved.

I’d much prefer option 2, since it more accurately represents what exists on the ground. Options 1 and 3 start introducing angles and corners (“Warning! Sharp bend ahead!”) that don’t exist.

Option 2 is the best approximation of the route that a fully informed driver will take, namely a straight line from the point of lane departure to the exit. Imagine instead that drivers follow option 3 - 45 degree turns just before the gore? I don’t think that would be right.

This echos what I’ve found - if someone were systematically creating 45 degree angles for offramps locally, I’d ask them to stop.

We tried holding a short meeting at SOTM in Brussels last year. It didn’t work well. All of us were exhausted from either running or attending the conference and didn’t accomplish much over a normal board meeting. I know I always feel like I have no time at the OSM conferences, and am rushing between presentations and trying to meet with everyone who wants to talk.

Holding the board meetings before/after a non-OSM conference that most of us are attending might be an option, but finding one of these is harder.

All four layers use Mapnik. The layer osm.org calls “Standard” is the OpenStreetMap Carto style.

As a first step, I always recommend starting a changeset discussion. If the users do not reply, two options to consider are reverting their changesets or contacting the Data Working Group. In the case of a user ignoring discussions or messages about their mapping the DWG can require a user to respond to the discussion before continuing mapping.

Which tool did you used to generate vector tiles?

The vector tiles were pre-rendered Kosmtik, using Mapnik. I just scraped my local development setup with curl. There are better ways to do this, but this had the advantage of being easy.

It takes some time to render the demo

I looked at the network timeline, and the slowness is coming from a few causes

• Some vector tiles are large and unoptimized
• The server isn’t the fastest and has no CDN
• All access is done on one domain, so there are limits on how many parallel connections browsers will do

The purpose of tile.osm.org and the other OSMF-run rendering infrastructure is to serve mappers. Other OSMF infrastructure may be different, e.g. planet.osm.org is primarily used by data consumers. The purpose of OpenStreetMap Carto which is the default style on osm.org is different but related:

There are multiple primary purposes of the map style, which pull in different directions

• It’s the primary feedback mechanism for mappers to validate their edits - so detail is useful
• It’s a major part of the impression visitors to osm.org receive - so clear design is useful
• It’s an examplar stylesheet for rendering OSM data - so easy customisation is useful

It must always be borne in mind that a map style cannot show every detail of the OSM data, and in many cases it is more appropriate to show the detail in other, more specialist styles.

Hence, sending a message to those mappers is rather useless because they are not aware of the fact that there is such a thing as a private mail-box in their account

It’s not useless since it’ll go to their email. Response rates aren’t great, but that’s not unique to maps.me.

Finding no difference in retention rate between those messaged and those not backs up the analysis out of Poland which found no difference. 50% of new users were messaged based on their user id, and there was no statistically significant difference between the two groups. In fact, the percentages had those who had received messages slightly less likely to be retained as mappers.

For a long time now I’ve been thinking on a problem: OSM data sometimes contains riverbanks that have no centerline. This means that someone mapped (part of) the coasts of a river (or stream!), but didn’t care about adding a line that would mark its centerline.

When I looked at this problem I concluded it would be far simpler to add the missing data then add a complex step to data transformations. The tools have gotten better since then, but I’d still rather fix the data once for everyone.

For now, no mainstream renderer or router knows how to process road route relations

They are certainly processable in Mapnik with SQL. The problem with OpenStreetMap Carto is the need to support more than just the US and the need to by default colour the way’s highway tag. If you are only worried about supporting route relations it’s fairly trivial, and route relations + way ref tags isn’t too hard if you don’t care about the way’s highway tag.

Instead, when an OSM way is baked into a vector tile, a spatial query determines the relevant ISO 3166-2 code (the country code plus the postal abbreviation), which goes into an iso_3166_2 field

Where can we see this logic?

The SkyTrain is a railway=subway as defined in OSM. As the text usually underground indicates, most railway=subway systems are underground, but this one isn’t for much of the length.

The Evergreen line was originally planned to be light rail, but was changed to use the same technology as Skytrain. There are also tentative plans for light rail sometime in Surrey

Can’t really recommend one over the other since I have not tried generating vector tiles myself. My guess is that the standard osm2pgsql/postgres setup should work.

That’s a database setup, not a vector tile setup. The issue isn’t the software, but the source definitions.

pnorman, the first step is to create vector tiles of the data you want to render. One can do this from a regular mapnik source using https://github.com/mapbox/tilelive-bridge .

What Mapnik source do you recommend to generate vector tiles with so that the tiles will work with the work you describe in this post?

It’s good to see native language rendering.

One question is if someone wanted to reproduce this themselves without relying on third-party services, is there any way, or is it tied into components which can’t be reproduced like the Mapbox Streets vector tile set?

Are you using the Garmin Virb X or XE? I’ve found GPS problems when taking photos with the XE at a 2 second interval, how often do you take them?

highway=track isn’t about road surface and never has been. Unfortunately, some people use it for unpaved roads, which is wrong, and leads to these problems.

I regularly tag 5-digit addresses with the Karlsruhe schema for addresses and it works fine. There are no problems with addresses that jump by large numbers when there is a crossing street.

The last few years have had drops around end of year/start of year, but this one is about twice the absolute size of previous drops.