Are we adding to a map or a database?

Obviously it’s both, but surely the map is the main priority?

Why do I ask? Well, I’ve noticed one specific fellow mapper has been undoing a lot of my edits for my local area. This guy lives hundreds of miles away but seem hell-bent upon removing information from my locality, I don’t know why he can’t find more productive things to do without picking on my area. He seems hyperfocused on getting the database “correct”, but this is spoiling the usefullness of the standard website map. I have been trying to make the normal map informative for 99% of users, but if he removes descriptions of features from within names (names that us locals use), this useful data will not be seen by the majority of users. What are we trying to achieve here? Users don’t browse the database, they look at the map, surely?

In one comment exchange he says “It is also incorrect to add data just so that it appears on the standard OSM rendered map, so you should not make a change based on that. We are contributing to a database, not a map. The OSM renderer is just one of a whole variety of renederers of the data. If you feel a feature should be rendered by the standard renderer, then you need to take it up with the rendering team, rather than attempt to work around it.”

While I can see his point there, it does seem to me to be extremely nitpicking, so I ask again - what are we doing here? Making the standard map as useful as possible or compiling a database where much of the data would be almost pointless as less than 1% of users will ever see it?!

I can put aside my indignation here and see things from both sides, so I’m interested to hear other views on this. But if I can’t find a way to make useful information appear on the normal map, I simply won’t bother. Thanks.

In the sense of your question, it is a database. There is no such thing as a “normal” map. Maps are drawn for a variety of purposes.

Since your issue is with names, I suggest that you read the article on names.

There is a proper method to accomplish what you are trying to do. The method has several components. The first part is to find or establish appropriate tags on the elements of the entities you are trying affect. The second part to to locate and modify an appropriate style file to present those data in an appropriate manner. Then, you need to render the map in the style you want.

I had a similar experience. A “fixer upper” from several thousand miles/kilometers, looking at old Bing aerial views kept “repairing” my changes to a nearby intersection, not knowing that the intersection had been rebuilt entirely to change it from a bridge over a motorway to a double diamond intersection over the motorway since the Bing picture had been taken. I finally got the “fixer upper” to understand by telling [him] to just sneak a peek at Google Earth, which had much newer imagery. By this time, I was exhausted. Since then, someone else fixed the intersection after Bing finally updated their imagery for that intersection.

Your critic is correct. Putting meta data into names is wrong, as it is mapping for the renderer.

The main web site rendering is not a map for the general public. It is primarily an aid to people contributing to the database, and secondly a technology demonstrator.

As hinted at in the other reply, if you want particular meta data to be reflected in the rendering, you should either construct your own tool chain to do that, or encourage someone else to do so (after working out a business model that will properly fund it).

It is usually possible to work out when meta data has been, erroneously, included in names, but there is a risk that there may be exceptions, so I would leave changeset comments, and/or add map notes, rather than fixing them up. Unfortunately, in many cases they may not get fixed up properly.

The map is the database. The standard rendering is not the map. There is a lot of information in the map that doesn’t appear on the standard rendering, because doing so would make it too cluttered. In any well mapped area, the rendering will have to arbitrarily select what to render because text and icons would otherwise overlap.

Note. People should not be removing correct information. If they change an object, they should add information, by moving the data to a more correct tag.

Here is an example work flow. The part left not described is the style file itself. You can use the default style file in mkgmap as your basis from which to build what you want. This work flow targets maps for Garmin GPS receivers. In this work flow, there are several renderers, Garmin software and Garmin GPS receivers.

Looking at your recent mapping, you have been mapping disused bunkers, with no indication that they are disused and with names that look like information about the style of construction, or that they are bunkers or shelters, so should not be in the name tag. They are really sub-types of the building tag, (Using them directly for the building tag requires non-specialist renderers to know too much about second world war architecture. building:architecture doesn’t really work, and I cannot find a suitable tag, but subject to further research, building:description might be a starting place for information on construction style. If there is a good taxonomy of bunker construction types: maybe start a bunker:construction_style tag).

I think you’ve got your numbers the wrong way round there!

Probably less than 10% of people viewing OpenStreetMap data are doing so on Most people are exposed to it through maps hosted by Mapbox, Apple, Garmin, Strava, or a thousand other commercial or enthusiasts’ sites.

Those maps all choose a different selection of features to show. So you absolutely shouldn’t make your mapping decisions based on what the default style at will show. Instead, the principle is that you map what’s there, and each map chooses what to show. You never know, someone might make a map that shows bunkers (or you can create your own!).

In this particular case, however, the user who I think you might be referring to is being a bit over-reaching in some of his changes, and you can see other issues under discussion here: . A good general rule in OSM is “be liberal in what you add, careful in what you change”. I’m not convinced that this user is being particularly careful in his edits.

Here is an example of the mapping of a bunker near Noordwijk aan Zee (NL):

So the operator of the museum is “Germany” ? :confused:

I would place the operator:nl in the operator field and the operator in something like old_operator

I just looked for an example of a building as “bunker” and have not reviewed the tagging. Indeed odd to see “Germany” as the operator. There are many more bunkers along the Dutch coast and I’ll try to find somebody who can take care of them on OSM.

Hi Escada & BikePC I could be guilty, the trouble starts if the museum typos are added to the building instead of to a node. If your living at Soetermeer, please start adding bunkers at the area of Le Hage. Like a old mapper told me, in the early days objects were a node and in time it would get more attention and specific tags and more information or the complete structure.