Hi solongago,

I think most issues are with the naming of features. When you give a name to something, it should be an actual name. Preferably a name that’s visible in real life (on a sign).

You should not name things like “swamp and marsh” (see osm.org/way/821859381 as an example). That is part of the descriptive tags wetland=marsh, not of the name.

osm.wiki/Names#Name_is_the_name_only

To get a correct history of a way, it’s probably better to get the history of the nodes.

And check who created those nodes, and who altered it.

The first nodes should typically relate to the first way creation. But in many cases, it can be crude sketch from aerial imagery, or something imported.

So if you see a majority of nodes was added or refined later, it’s clear that person is responsible for the current geometry.

Though at the moment, this is pretty hard to do. It would require a bit of tooling to get insight into who made the geometry as it is.

You can launch a sandbox editor.

But generally, it’s not needed because in a good editor, you can see what you’re doing. And beginner mistakes are often easy to correct even if they get uploaded.

Mistakes that are often made by beginners, are usually convention mistakes (like naming a feature in all-caps, or being overly descriptive), and those won’t be caught in sandboxes either.

Just a note, for anyone wanting to import anything, the import guidelines should always be met.

How does Ordonance Survey gather the data? If it’s really by surveying, maybe it had a wrong sign somewhere in the past?

My own street had a wrong sign for a long time. The correct name is “Vyvestraat”, but for many years it said “Vijvestraat” on one of the signs. For historians, ‘ij’ used to be a single glyph in Dutch, but after the invention of the printing press, it was costly to produce that glyph, and generally was printed ‘ij’ in the Netherlands, but ‘y’ in Flanders. Later on, Flemish spelling evolved to follow the Netherlands, but old names still have a lot of ‘y’ characters in them.

I once even found a street with 3 different spellings (also ij vs y related): osm.org/way/132846607

Regarding the Chancel Park/Way. I wonder if it’s some copyright easter egg that got included into OSM.

It’s an ideal easter egg, as the original name can still be found. And very few people will notice that street has two names.

Perhaps the data was once meant to be under a closed license, but later released, and the easter egg got in that way?

Not all governments want to share that data (or it can be very expensive).

In Belgium, the government had top-class imagery (25cm pixels, inaccuracy of max 10cm, taken every year in the spring), and top-class GIS data (buildings with an accuracy under 1cm on the streetside, road areas, …) .

It was all done with tax money, yet it took a few years of lobbying to get access to it.

but OSM wouldn’t be at this level today without using data and satellite images from companies.

You could also say we have access to that data thanks to early mappers using GPS to map streets. I still remember how I tested out my GPS antenna, and tried to map roads as good as I could without imagery. I also remember the first imagery we got from Yahoo, which was pixelated to a point where you could barely see buildings, and in places very cloudy.

But thanks to the efforts of the early mappers, companies also started to see the advantages of crowdsourced data, and eventually released aerial images.

More and more OSM mappers are paid mappers too.

There is a wiki page about organised mappers (though not all of those are actually paid).

And Pascal Neis reports these in OSM Stats, the number of organised mappers is consistently above 50%.

You have to realise the Linux kernel is way older than OSM. So the kernel has worked its way into many and big companies, The same will happen with OSM over time. The more companies that rely on it, the more paid mappers will arive.

Landuse being excommunicated? I guess it’s just the last type of data that gets mapped, because it’s hard to map. The borders are often not that clear, and you need to combine local knowledge with aerial images to get it correct.

Usually, streets as ways are added first. It’s easy to trace those with a GPS, and to see those on aerial images. After that, points of interest (shops, pubs, …) are usually added, since (as the name describes) they are interesting to many people.

Only after those features are rather complete, the community usually starts with mapping area-type objects. First the big and important areas (important buildings, big landuse around cities, river and lake outlines, …), until more and more smaller areas follow.

Highways are of the smallest area types. There have been proposals to map highways (like osm.wiki/Proposed_features/area:highway), and you are allowed to map highway areas. But it’s usually the very last thing that gets mapped, and it needs a very active community to keep that maintained.

So while every mapper can decide for himself what his priorities are, the above is the usual order things happen in.

I mostly use “path” for everything that allows both cycling and walking. So a lot of urban passage ways are mapped as paths by me.

It also matches with the Dutch language, where “pad” just means a road too narrow for a car, but doesn’t imply anything about surface or access restrictions.

Regarding the walking or cycling quality, I have sometimes used the tracktype tag on paths (even though the name implies it’s more for tracks) to describe how well you can cycle on them. As a mountainbiker, that’s nice information to have.

But I like the smoothness key even more. It gives information about the soil in a more descriptive way than “surface”. I’ve seen paths where a surface=concrete tag should be used, but they were surfaced in horrible concrete tiles with big gaps making them almost impossible to use for a regular cyclist. Surface=gravel also doesn’t tell you anything about the riding quality: gravel can be quite firm and ride as good as fresh asphalt, it can have potholes in it, or it can be loose and almost impossible to ride.

But both tags are more important to mountainbikers or other offroad vehicles than to hikers. They are passable for all hikers, though perhaps you can get an idea of how dirty your shoes will be.

Ugh, that code got unformatted as shit. But hopefully you can figure it out.

Regarding generating the comments in JSON, why not code it in JS and let it output JSON. Any JSON is a valid JS object (hence the name), so you can just copy-paste parts of what you have. And in a main JS script, you can join them up into a single object (with comments in the code about what a certain part does), and print that object.

The added advantage is that you can have variables and simple calculations.

If you include it in a Mapbox GL JS website, you don’t even have to print out the JSON to a separate file, but you can pass the JS object directly to their map constructor. So during development, it’s just as well refreshing a page.

You can put your style in a file like this: export default const style = { // Your current style with added comments, can be loaded directly into mapbox too }

And to generate the actual JSON using a simple script like this: ``` import style from ‘./style.js’ import fs from ‘fs’

fs.writeFileSync(‘style.json’, JSON.stringify(style, null, ‘\t’)) ```

I just want to discuss the addr:street=* tags versus associatedStreet relations.

While associatedStreet relations seem nicer, and I also tried to use them in the past, they have some nasty properties I now try to avoid.

Relations by themselves have no geographical location, in JOSM they’re just displayed in a list, and it’s harder to find them (need to right click, select in list, …). Other editors even have more issues with the relations.

Certainly when you have a lot of relations in the list (multipolygons, associatedStreet, boundaries, …) it becomes very difficult to select the right objects and add them to the right relations. I’ve seen mistakes where a single street had two relations, or houses of two streets were added to the same relation. And I must say it’s a nightmare to clean up such relations.

On the other hand, addr:street=* tags are not that bad as you might think. Adding the tag to a group of houses is simple. Just select the buildings together, and add the tag. JOSM will even suggest names of nearby features (so street names) as values for addr:street, so it will avoid spelling mistakes.

Selecting all houses in a street is also no problem in JOSM, you can easily do a search for addr:street=xxx and see which houses have the correct street name, or even use the resulting selection to do a mass update of the street name by altering the tag.

In most query tools (like overpass API or plain SQL queries), it’s easy to search for addr:street=xxx tags in a certain boundary (all based on names of villages and streets). So it’s easy to find all houses in a street. When you have to go via relations, it gets harder (again because relations have no geographical info, so you first need to find the street, the relation associated, and only then you can find the houses).

The only real advantage I see to the relations, is that it’s easy to link to and visualise via the OSM home page. That visualisation can indeed be satisfying, but that doesn’t outweigh the drawbacks IMO.

Just a note, OSM data is licensed under the ODBL license now, not CC-BY-Sa: osm.org/copyright

Amenity=* tags should go on what they define. Around here, most schools have multiple buildings, and the playground is clearly part of the school. So the amenity=* tag defines the perimeter and not the building.

The same holds for other big features like industrial sites. If you can accurately define a feature with a single building (like pubs and restaurants in most cases), it’s fine or even preferred to put the tag on the building.

This looks like great imagery for remote areas … however, most people use maps in crowded areas, and most people also map in crowded areas.

So I wonder how useful this is for OSM as a whole. In contrast to some high-res, recent and accurate imagery of a small crowded area we might get by lobbying some (local) governments.

I read the documentation, but the documentation changed while I was using it …

http://overpass-turbo.eu/s/fSN

Thanks for saying my opinion is irrelevant. But I say that the current schema works very well.

First of all, you’re mentioning the big number of different shops. And then you’re nitpicking on some of the most used values. I know people who complain about the amount of different tags they need to parse, and I know people who complain about the lack of values to describe a feature. I’ve never met someone who complains about both at the same time.

The shop=* works good. I can perfectly see if something is a supermarket, a bakery, a clothes shop or whatever. If it’s some exotic shop, I just invent some tag for the shop, and it gets parsed by most tools as just being “a shop”. That’s perfectly reasonable.

Next to that, there’s no problem with having local definitions for values. I live in Belgium, and I know perfectly well what a supermarket or a convenience store is (we don’t use kiosk or mall very often). And so do all users in Belgium. So it doesn’t matter that our definition is somewhat different to other definitions. People here will want a supermarket to the local definition, and find one.

But as the almighty intelligence ofc already knows, tags don’t change in OSM because someone things some tag is better. Tags change because they are being used by a growing group of users. I wish you good luck with changing the shop tags.

Try Overpass API (via the Overpass Turbo interface): http://overpass-turbo.eu/

See this to learn the syntax: osm.wiki/Overpass_API/Overpass_QL ,

Or just use the “Wizard” to search features in a certain area.