Hi, thanks for your edits around Cockermouth. Have those fence boundaries changed since the houses were constructed?

I’m using the newer imagery at https://ecn.t{switch:0,1,2,3}.tiles.virtualearth.net/tiles/a{u}.jpeg?g=587&n=z and aligning it to the OSMUK Cadastral Parcels (since not all aerial imagery is correctly aligned). It shows the boundaries as they were mapped before your edit, and also the buildings not rotated.

Hi, please don’t delete this path. It’s listed in Wainwright’s guidebooks and has a fairly strong trace on Strava heatmap.

Just because it’s listed in a mountain rescue callout doesn’t mean it shouldn’t be on the map.

It’s correctly tagged with sac_scale=demanding_mountain_hiking.

The problem with that mountain rescue callout was that AllTrails doesn’t indicate the sac_scale of a path to the user. That is a problem with AllTrails, not OSM.

Deleting the path will not fix the problem with AllTrails (there are likely other paths in the Lakes which could cause mountain rescue callouts like this), and it will likely be added back in future by someone who wonders why the path in their guidebook isn’t on OSM.

I’m going to revert this changeset. The path exists.

It’s for mapping the canal corridor: the land beside a canal which is associated with it. The tag is analogous to landuse=railway and landuse=highway.

While it’s not rendered by the default renderer, it can be useful for calculating land area used by canals, or similar GIS tasks

Deleting the path off the map is not the solution to some people getting cragfast on it. It is a valid path, and is tagged appropriately with sac_scale to indicate its difficulty.

The appropriate fix is to ensure that consumers of OSM data correctly render sac_scale.

For carto, that means helping fix https://github.com/gravitystorm/openstreetmap-carto/issues/1500

For other mapping apps, that means filing bug reports with them to ensure they render difficult sac_scale paths with appropriate warnings.

The correct position relative to what map/coordinate system/imagery?

Hi! The trig pillar has a note attached to it:

“Accurate location import for imagery offset calibration. Please do not move.”

Just checking, but were you aware of this and its implications? Are you using offset imagery, or the default satellite imagery alignment in iD?

Thanks

Morning :) I suggest going with width=5' and surface=unpaved to start with.

If you know the surface more accurately then you could use that rather than ‘unpaved’. There are some recognised values listed just above here: surface=*#Surface_for_motor_roads. Similarly if the surface differs along the road, split it into multiple sections and vary the surface= tagging between them.

You might also want to use smoothness=very_bad (or another value from smoothness=*) if that seems relevant.

Similarly, maxspeed:practical=* may also be useful.

Adding those tags together, I suspect that will cause satnavs to not use the roads.

I hope that makes sense, happy to discuss further if anything’s unclear or if I’ve got anything wrong :)

Heya, are you sure this is correct? As I understand it, these are unclassified roads, so there is a legal right of vehicle access, and they should be motor_vehicle=yes not motor_vehicle=private.

What makes them unsuitable for being routed down by a sat nav? Are they too narrow, missing passing places, poorly surfaced, etc.? If so, it would be better to add tags for that information, so the sat navs can make more informed routing decisions.

Oops, it’s a typo. I started typing farmland=pasture and evidently the tab completion didn’t work and I didn’t notice. Thanks for pointing it out.

Fixed in changeset/130065497

That sounds like it would be a good improvement to the map, thanks for taking the time to do so :)

I think I replied before seeing your latest reply. Yeah, from my point of view I don’t think they (or the similar names on other relations) add anything to the map that isn’t already given by the ref= tag. 🤷

But what value does it add to the map?

Hi, I’m not sure this is a useful change. From spot-checking a few of them, the ref is already tagged separately on these relations, and the country can be determined by spatial data.

See osm.wiki/Names#Name_is_the_name_only

What was your reasoning for adding descriptive names to these relations?

Thanks

Thanks for clarifying

If you’re going to automatically resolve validator warnings, can you please constrain the edits to a small geographical area? Nobody is going to be able to review this changeset.

osm.wiki/Changeset#Geographical_size_of_changesets

Can you please also say *what* validator warnings you are fixing in your changeset description, otherwise it’s hard to work out whether particular changes are intentional or not.

Thanks

Hiya, thanks for adding some detail to the Bay Cycle Way.

I’ve removed ‘NCN700’ from the name, though, as it’s already tagged using the ref= and network= tags, and there are tagging guidelines about the name being the name only: osm.wiki/Names#Name_is_the_name_only

My changes are here: changeset/129604559

Cheers :)

Hi, I think the same comments as in changeset/129527914#c950706 apply here.

This changeset appears to delete pedestrian crossing information and replace it with traffic signal information. Both need to be present.

Please can you read the wiki? highway=traffic_signals#Traffic_signals_for_pedestrians

This doesn’t revert changeset/129273331, but it does change the classifications of several of those roads again.

Market Place back to the crossroads on Main Street are now tertiary, as the street is quite wide and well surfaced, and does take some through traffic. It’s not a B-road, though, so isn’t secondary.

Saint Helens Street is back to being unclassified, as it’s a small mostly residential road which takes a little bit of through traffic to/from the east. It doesn’t have a B or C classification.

Kirkgate is now tertiary for the same reasons as Main Street/Market Place.

Station Road is now a secondary road (it was tertiary) because it’s the B5293.

Lorton Street is back to being a secondary road (it’s the B5292).

See osm.wiki/Highway:International_equivalence for the conventions behind this.

I’ve changed the classifications a bit in changeset/129471578

It would be great if everyone who used OSM was also a skilled geologist, but that’s not the case and having a volcano marked on the map is going to make most people expect to see a big crater or caldera.

See natural=volcano#Tags_to_use_in_combination which explicitly says that unverifiable volcanos shouldn’t be mapped.

There’s no need to be rude :)