I don’t see any reason why you couldn’t have duplicate key-value pairs in the current api; however, I think it’s disallowed because of limitations elsewhere. Also, this would violate current expectations that other tools have (for example, the rendering of a road shows the name of the road along side of it, but if there are two names, which name does it pick?)

On the other landuses such as grass parks and forests, they can have textures added like the forest currently has.

While this may work for the forest “landuse” (I’m not even sure what that means), natural=wood would have to be changed too.

The further problem with green roads, apart from their shear distinguish ability, is that they fail at being iconic (in a semiotic sense). In other words, the other green things on the map are all generally indicators of some level of plant life, or protection of such life, and highway=trunk has nothing to do with plant life. A green highway=trunk works fine in places that have largely been deforested (i.e. Western Europe, big cities), but not well in many other places.

For UK use, it’s vital that the style distinguishes between highway=trunk and highway=motorway, as the two roads have different rules and restrictions.

I think more practically, it may be useful to just have a separate map rendering for UK users (much like openstreetmap.de for German users).

Nice job. Looks like only a few US states are rendered right now. Would be interested in seeing Washington too.

as otherwise what’s the point of putting something in the database if it’s not going to show on the map

Well you can still find it when searching for it.

I think the main concern though is not “Whether we should show all the data” but “At what zoom level should we start showing data and how prominent should it be”?

For what it’s worth, except for the terrible tree coloured highways, openstreetmap-carto is great for mountainous areas, for example: http://tools.geofabrik.de/mc/#14/48.7743/-121.8236&num=2&mt0=mapnik&mt1=google-map

I think data-density shouldn’t be a great problem for roads if you just make the smaller ones less visible, since in cities, most of the roads tend to be residential/service roads, where as in a rural area most of the roads have a more significant classification.

Unfortunately, the above breaks down for non-motorized “highways”. There is currently no good way to designate if a highway=path is a major-trail/walkway, or if it just a small off-shoot.

I just took a quick look at the vicinity, and all the rivers I saw were in valleys (based on OpenCycleMaps SRTM data). I probably missed some though, so it’s best to share a link to your example.

It’s pretty easy when looking at topographical lines, to get oriented upside down though, so that may have been your problem..

the question i have is can governments use OSM data, then make it classified.

I am not a lawyer, but it seems to my that while you you could sue the government for copyright infringement, you probably won’t get the remedy you’re looking for (government opening up data) based on some sort of vague “not in the public interest” or “issue of national security” reason.

Probably just a polygon with the tag sport=swimming where the actual swimming takes place (i.e. in the water).

If it’s a road to a park then I think at least highway=unclassified would be normal.

In British Columbia, many of our roads (regardless of their use) go through forests, because there are forests all over the place.

Obviously the best solution would be for your to burn down all the forests around Moscow.

At the risk of derailing this important issue, I would like to mention that I think this problem is a lot more pertinent to OSM than current coffee prices.

To some degree, this sort of linking has already be done with a lot of imported data. For example, the tiger:tlid tag. Of course these tags are specific to their imports. I see two problems with this approach:

• First, it requires users to copy the tags when recreating objects. A lazy or ignorant user probably won’t. I think expecting users to do this is going to create a lot of headaches when some invariably don’t.

• Second, this requires the mapper to decide when the identity of an object changes. For, example, if there is a McDonalds, and it moves into a building across the road, is it still the same McDonalds? What if the building is on the other side of town? What if two campsites are merged, who’s id is used then? On OMS, a road often gets broken into segments because there is a bridge, or the speed limit changes, do these segments get the same id? In real life, there are often unconnected roads with the same name that were historically the same road, do these get the same id?

One fuzzy solution that will probably work reasonably well for your use case is to match campsites based on the location of the campsite (or an average of the nodes in its polygons). If that value changes significantly, you probably want to to consider it a separate camp site anyway.

In Canada these are called runaway lanes and I found two cases that were tagged as highway=service, they’re now changed.

Just hire an employee/contractor who’s job is to do mapping.

It’s my personal feeling is that things that are “on a map, factual, and current” should be welcome on OpenStreetMap but not necessarily endorsed or rendered.

This is a bit of an extreme, but something like “the location of the President of the United States” is “on a map, factual, and current”. It might even be something you might make a map of, but it’s obviously not something you want in OSM.

For a less absurd example, how about “Elvis Presley” sightings, or “UFO sightings”. These are semi-geographical bits of data, but still not things that I think belong in OSM.

I think here are some better guidelines of what belongs in the main OSM db.

1. Is it likely to be used in more than one map?
2. Is it possible to keep the data up-to-date without regular imports?

If the answer to either of these is no, than there is a good chance your data is better off as a separate data source.

If you’re still not seeing the changes, this is probably related to your browser cache.

You can try pressing CTRL-SHIFT-R to clear your browser cache and reload the map. I think it’s more likely that the map server is just taking it’s time to regenerate the tiles.

If I remember correctly, It’s mostly deciduous trees in the Smoke Bluffs, so SimonPoole’s suggestion of going in the winter is probably good. December-February is probably your window for minimal foliage.

On fairly labor intensive solution would be to use a rangefinder and calculate positions based on existing known positions.

Regarding grades, I think they are pretty verifiable. Much more so than road grades, at least. Routes will get graded by consensus, usually based on typical condition. Unlike roads, waterways don’t require constant human maintenance, and so baring an significant weather event that changes the landscape, the grade is fairly consistent from year to year. Grades of often published and so they can probably be sourced from outside OSM too.

I haven’t been involved in any edits in your country, but there’s a few ways you might be able to stop the fighting:

• Message the offending user or users (it’s possible the users don’t understand what they’re doing).
• Add comments to your changes to explain them.
• Add source=local knowledge tags to your changes.

I haven’t been involved in any of the tagging, but I can tell you how these happen to be tagged (at least in some cases) in Western Canada and the US.

US

• National Park: boundary=national_park and boundary:type=protected_area
• State Park: neither, just leisure=park

Canada

• National Park: boundary=national_park (no protected tags)
• Provincial Park: boundary=national_park (no protected tags)

Note that parks in Canada are protected (at least till someone with enough money convinces the government to move the borders), it’s just the tags that are missing.