I’m sorry to write in English, my German is good enough to read it, but I make too many mistakes when writing.

This is a very interesting experiment. But I wonder to what extend the speed has an impact on the feel. Belgian cycle races are famous for their cobblestones. And the trick to ride on cobblestones is to ride fast enough (which is why it makes great races, as all riders need to keep pushing during the cobblestone sections).

I would guess that the frequency of the vibration also impacts the smoothness. If the frequency is low, you would still consider it smooth. But if the frequency is very high, it turns into some sort of buzzing feel. But when the frequency is in between, it becomes very unsmooth.

A slow rider might ride at 14km/h (4m/s). If you take an estimated cobblestone size of 15cm, you get a frequency of 4/0.15 = 26Hz. A practiced rider might ride at 36km/h (10m/s). And this would result in 60Hz vibrations. At that point, it becomes a nice buzzzing feeling.

Also, when expressing vibrations, it’s typically done in amplitude (or displacement) and frequency. But this has a curious relationship to acceleration (which can be easily measured with G-sensors).

I’ve never been to Scotland, the closest I got was around Manchester.

Anyway, if you map it accidently, it’s probably not an issue. What I was talking about were refuge houses like these: https://www.caw.be/hoe-wij-helpen/opvang/opvang-voor-vrouwen/ (you may need to translate it)

Those are just houses somewhere in the city, but their location is secret. You only get to know the address when there’s a threat of domestic violence. If you happen to get to know one of these houses, it obviously wouldn’t be appreciated if you put it on a map. And it’s not about mapping the house and address, it’s about tagging it as a refuge that shouldn’t be done (in this case).

It’s completely different from something that can be seen from aerial imagery. Even a decent image recognition algorithm could deduce there’s an industrial site on that photo. And when it isn’t mapped, it may be even more suspicious to foreign powers…

As far as I know, the OpenStreetMap foundation is registered in the UK, so follows UK laws. These are quite liberal when it comes to freedom of information. Mapping such a facility would most likely fall under freedom of information, and thus would be fine for OSM.

Generally, if a government wants to prevent something from being mapped. They can easily ban all air traffic over the facility to ensure no imagery can be taken, and ban people from coming too close.

But when mapping, you have to take local legislation into account too though. A famous example is China, where all GPS based mapping is legaly forbidden. So while OSM doesn’t care about Chinese law, local mappers in China should be careful when mapping.

And for some things it’s just not nice or moral to map those. Some features should remain hidden, like hidden camp sites. Or a more extreme example: a refuge place for violated women should definately not be on the map.

So it’s your call as a mapper to decide whether it’s legal, or moral.

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.