Gates #323

Open
bitnapper opened this Issue Jan 30, 2014 · 59 comments

Comments

Projects
None yet

Gates in fences are often much to present on the map. In my region I mapped several fences with smaller gates in it and they are very annoying on smaller zoom levels. I thing it would be better not to render them in zoom-levels lower than 18.
Same with information boards. I've mapped plenty of them and I believe all those small info-board belong into the osm database but rendering them on zoom-level lower than 18 seems also to much.

For example see this area: http://www.openstreetmap.org/#map=16/51.7123/10.5129

Collaborator

matkoniecz commented Jan 30, 2014

Collaborator

matkoniecz commented Jan 30, 2014

example of gate at level 16 where displaying makes sense http://www.openstreetmap.org/?mlat=50.0612&mlon=19.9136#map=16/50.0612/19.9136

I think that it is clear that displaying it at level 15 is really not necessary, displaying it from 17 is also generally a good idea. I am not 100% sure about displaying it only at 18 and higher.

Ok. Maybe the tagging should be adapted. For those gates on small footways leading onto private ground (a garden or backyard) or in fences between building leading to a privat parking spot or a path to the backyard its not neccessary to be rendered on zoom level 18 and smaller. On level 16 many of them look like they are blocking a street not a small way leading from a street into the garden (see http://osm.org/go/0GtqzMGk?m=).

But the info-boards are definately not necessary on zoom-level <=18.

Collaborator

matkoniecz commented Jan 30, 2014

What about adding access=private to private gates and not displaying gates with this tag (or displaying it on lover zoom levels)? Private gate is functionally the same as fence.

@info-boards - can you create a separate issue for this one?

Rendering gates with access=private not before zoom level 19 sounds reasonable to me.

Collaborator

matkoniecz commented Jan 30, 2014

Treating access=no like access=private is also a good idea.

2014-01-30 Bulwersator notifications@github.com:

What about adding access=private to gates on private footways and not
displaying gates with this tag? Private gate is functionally the same as
fence.

this is a really complex topic, and no simple solution is in reach (as long
as we don't encourage different tagging). In some areas knowing that there
is a gate should already be possible by looking at zoom 12 (rmaybe even
below, low densitiy rural areas where your way is obstructed after some
time), while in others everything below 19 seems clutter (in high density
urban areas), and even then you'd most likely be more interested in the
housenumber than the gate.

There are also similar situations e.g. a path in the mountains where there
is no other path close should be displayed very early while a path in the
inner city should not display below level 16 or maybe 15.

In any case, not displaying gates with access=private or access=no is not
the solution, as it is above all those gates that you are interested to
know about, while the open ones don't matter.

Collaborator

matkoniecz commented Feb 2, 2014

@dieterdreist

Can you give an example of a private access gate that should be prominently displayed? I never encountered one, but maybe it is again something strongly depending on location.

Collaborator

matthijsmelissen commented Feb 2, 2014

In Luxembourg it would also be desirable to not render private access gates at a low zoom levels:
http://www.openstreetmap.org/#map=15/49.6129/6.1329

Collaborator

matkoniecz commented Feb 3, 2014

And example from my city of private gates that really should not appear on this zoom level of map: http://www.openstreetmap.org/?mlat=50.0704&mlon=19.8846#map=16/50.0704/19.8846

javbw commented Feb 4, 2014

The example of gates that should appear on large maps are usually road gates in rural access. When I look at maps of state parks, knowing the fire road has a gate (which usually means it's locked) means there is no car access into the area we want.

http://media.sdreader.com/img/photos/2008/12/30/roammap_lead_t670.jpg?b3f6a5d7692ccc373d56e40cf708e3fa67d9af9d

which is http://www.openstreetmap.org/#map=14/32.9635/-116.5815

Just like the parking areas, we need to separate their render on either access, size, or some other parameter.

Maybe a dark green gate for public/customers/designated, dark red for private, and black for a basic gate=yes tag?

This also is similar to the parking isle labels that get rendered before the parking isles do - does the fence itself get rendered with the gate? I guess there is no easy solution to map them to each other.

Every time we come back to rendering, I always get the feeling we should implement an "Importance" or "prominent" tag to positively or negatively affect what zoom level an item is first rendered at.

The Mt Fuji would render at +5, and the little Mt Fuji next to my house (all 100m of it) would be -3. Similar with rural access gates (or the park gates, +2) and fence gates (-2).

I know that this is not the place for implementing a new tag, so at least rendering on access (and additionally changing the color based on access), should be be a good first step.

Collaborator

matkoniecz commented Feb 5, 2014

"knowing the fire road has a gate (which usually means it's locked) means there is no car access into the area we want"

Maybe this can be done by setting proper access tag on road like at http://www.openstreetmap.org/?mlat=50.06755&mlon=19.91168#map=18/50.06755/19.91168 ? I see nothing set for road at http://www.openstreetmap.org/?mlat=32.98334&mlon=-116.57031#map=17/32.98334/-116.57031

Some roads with emergency access only for vehicles are tagged as highway=pedestrian ( example: http://www.openstreetmap.org/?mlat=50.0403&mlon=19.9053#map=16/50.0403/19.9053 ).

It may be also possible to consider only private gates on footways as not so important and not render it at lower levels, it would avoid changing anything in situations like this.

Manual importance tag is a bad idea, we would have edit wars within 10 minutes. But it is possible to find this value in an automatic way (very easy example: is wikipedia tag present? This one may work for mountains, for gates primitive version may be based on what is blocked (see paragraph above).

javbw commented Feb 5, 2014

  • Sorry about the gate example - it's from my home town - the gate icons on the old maps were very vivid in my memory, but I haven't mapped that area yet.
  • The idea of rendering footway gates differently than motorways is a good idea.

You are right, access afterwards would be a good way, although changing them to pedestrian (in a rural area) is not - they are always shown as larger access roads (tracks) on maps (local knowledge), and often labeled as roads, though there are no cars allowed. however, they usually connect into a very large (and not very well mapped) track road system, where you could start off 20 miles away on a dirt road, and not realize halfway over the mountains there is a locked gate where it turns from private/ forestry lands where you can drive into into a state park where you can't.

To continue the talk about tags in general:

There has to be some form of simple grading of importance, or some kind of nuance added to more of the tag, doing it one tag at a time by voting means that most of the necessary tags end up as abandoned proposals, which not only discourages the creator (because his work is not "validated" by the group) but future people who find it abandoned.

my mind keeps coming back to mountains. There is no "hill" tag, "prominence" tag, or "mount" tag, so everything gets mountain. There are 7 super famous mountains (jn Japan) in my region, all of them have 3+ sub-peaks (they are caldera volcanoes, so they have rim of little hills) but there is no way to force the "volcano" tag to be shown instead of these little peak names, nor to make it show at low zoom levels. meanwhile the 100m little blob sticking out of the rice field has the same name importance as Mt Fuji. I know it is an extreme example, but it illustrates the extreme end of the scale.

mountain = hill / prominence/ yes / mount would solve the issue for 99% of mountains, but it seems that most everything needs a similar sort of sliding scale for size.

There has to be someway to tag nuance or importance - we grade roads from motorway to 5th grade track - thats 14 different grades of roads - pedestrian has 4. there are 5 different kinds of wetlands. There has to be something to denote importance on some basic level. Does this mean making a gate=[?] tag? Same thing with mountain=[?]

I'm new to OSM, and new to wiki based code submission projects, so maybe my frustration is common with newbs. I wish I knew CSS to write code for the project, just to help make OSM/carto the best it could be.

Owner

gravitystorm commented Feb 5, 2014

Some quick thoughts:

  • 'Importance' and related concepts fails the absolutely vital verifiability test, so it's not a suitable concept for OSM.
  • Mountain prominence can be figured out using DEMs. Since every cartographer will have their own ideas of the results of prominence calculations, then it's best done in post-processing rather than tagging
  • Learning CartoCSS and Tilemill is straightforward, and is worth doing. The ratio of comments to pull requests here is already high, and I'd strongly encourage (and am very willing to support) more people experimenting with hands-on activities.

2014-02-05 Andy Allan notifications@github.com:

Some quick thoughts:

still, as you know for sure, we do use data that is structured like this
for the rendering (RANK=0 cities from natural earth dataset for low zoom
cities).

  • Mountain prominence can be figured out using DEMs. Since every
    cartographer will have their own ideas of the results of prominence
    calculations, then it's best done in post-processing rather than tagging

+1

Collaborator

matkoniecz commented Feb 5, 2014

@gravitystorm
I thought about doing this but it seems that it is typical for pull requests to wait for months without any feedback, what is rather discouraging so at this moment I am only doing easy and relatively unproductive part of reporting issues (I would classify #82 #113 #187 #227 #305 #314 #316 as dusted pull requests that deserve some feedback from developer(s))

javbw commented Feb 5, 2014

Rant on importance:

11091334824_bfed9c3ee2_c

I can tell one is more important than the other, and it is verifiable to others. One is a 200m hill, one is a 2600m Volcano. '

11091110715_6afa2d315a_b

Mt Akagi is:

The little peaks around the Mt Akagi cadera? no one knows them whatsoever, unless you are a hiker.

And for our discussion, a massive landmark for navigation. It's posted on signs all over the trunk roads and motorways.
screen shot 2014-02-05 at 10 06 54 pm

Why wouldn't I want a method to reflect that importance on a map?!

Why is there a "landmark" icon tag then? The wiki suggest tagging important trees and large moraine boulders. Didn't they have to gauge the importance between rocks? People gauge the importance with tertiary roads as well.

if you are talking about making a database of everything, in purely OSM terms, then there is no importance. I get it. in -carto, they are turning that data into a useful map. and creating a map means making decisions of what and what not to show, and it seems to me that all what this action page is - changing things to match the importance people feel they should be, solving errors to make the map better.

  • Apparently using the word prominence was wrong, thats one of those climbing people's words. How about sub-peaks, or call them hills. whatever. I'm not worried about it's prominence rating for climbers.

OSM talks about Local knowledge, which of course makes the OSM DB great, and local importance helps makes the -carto map more useful. It can be locally or regionally verifiable, but they may not be verifiable in a source or language your familiar with.

It maybe be abusable, but OSM is trusting that people wont abuse it, right? that I won't tag everything motorways and draw a Godzilla building on Mt fuji, right?

PS: I'm very interested in the carto CSS. I want to help out to make the map the best it can be.

Collaborator

matthijsmelissen commented Feb 6, 2014

I thought about doing this but it seems that it is typical for pull requests to wait for months without any feedback

That doesn't sound very good. @gravitystorm, is the bottleneck the amount of time you have available to evaluate the requests, or is it a hint to us for setting our priorities to different issues? Perhaps it would again be a good moment for strategical guidance/discussion, for example by extending the roadmap in README.md?

Owner

gravitystorm commented Feb 6, 2014

@math1985 yes, my time is limited.

@Bulwersator some pull requests wait for a while, some are merged within a day. But there's no way to do git merge comment#12354, so someone needs to actually try things in carto first. That's why I'd encourage more people to fire up Tilemill and try creating PRs, rather than adding ever more discussions and waiting for me to do the work.

@math1985 with regards to priorities, I'm interested in everything except for adding dozens more features. Given the limited amount of time I have (somewhere between 0 and 168 hours per week, by definition, but more usually 2-3 hours) I could end up doing nothing except review pull requests for the tens of thousands of features in OSM that we don't currently render, and get nothing else done. I don't know whether it's more appropriate to leave valid PRs open while I work on other things, or close them. I find doing anything to them - whether commenting or closing - just leads to more comments and fewer commits. Perhaps assigning them to a "new features" milestone is a compromise?

Contributor

Rovastar commented Feb 6, 2014

@gravitystorm

It might be make more sense if you gave example of what things you are interested in.

All things are new feature one could argue. Do you mean 'bugs' in the existing rendering? Things not rendered correctly? Some of those I would argue that new rendered features are more useful then a rendering bug where footpath tunnels at level -15 or not rendered correctly.

If we mean more re-factoring do you have a list of specific tasks in mind?

@everyoneelse

For this issue of Gates, Yeah we likely do render too far out and ones for private especially should be rendered even lower.

For mountains (how on earth did we get onto that) the most sensible way of rendering these is for looking at the elevation (elv) tag and the higher the are they prominently they can be rendered at different zoom levels.

Collaborator

matthijsmelissen commented Feb 6, 2014

@gravitystorm It is totally understandable that you can only do so many things in a given time.

Because this discussion is getting off-topic, I opened a new topic issue for this discussion: #328.

javbw commented Feb 6, 2014

@Rovastar Sorry, I used mountains as an example of how OSM has different grades of things for some things and not others, and I thought instead of making these grades for everything, an importance tag would be goo, but @gravitystorm says that really isn't a good idea.

Sorry to pull it off topic.

Collaborator

matkoniecz commented Jul 6, 2014

Additional problem: gates may block display of more important objects, for example at http://www.openstreetmap.org/?mlat=49.4713&mlon=21.3812#map=16/49.4713/21.3812 cemetery gate blocks display of cemetery name.

I think this is a significant problem. E.g., the centre of my home town at level 15 http://www.openstreetmap.org/#map=15/52.2033/0.1175 is now a cluttered mess, with gates sprinkled everywhere like confetti. That's a pity, because otherwise it would be a very nice map. I don't see any point in displaying (at this zoom level) the fact that every little (or even big) building off the road is private property, and so the access may be barred. Naturally buildings off roads are generally private, so the gate symbol isn't really adding anything. But at this zoom level it is a big distraction and also makes it look like the road is blocked every few metres.

I'm too new to OSM to have an opinion on the best solution, but in the above example restricting gates to level>=18 would work OK. It seems like some kind of importance rating on gates could be useful, but I don't know what all the consequences of such a system would be. Perhaps this could be made more objective by distinguishing gates that separate public roads from public roads, those that separate public/private and those that separate private/private, with the first being most important.

Alternatively (or additionally), is it possible for the renderer to automatically use a "density (per square pixel) of information" heuristic to detect built-up areas? So, for example, it might only render gates when there are less than (say) 100 features in a tile, or something like that but smoothed over space so that it doesn't oscillate when close to the limit. The gates would then automatically kick in at a sufficient zoom level, but the threshold zoom level would be higher in built-up areas.

Collaborator

matthijsmelissen commented Sep 23, 2014

E.g., the centre of my home town at level 15 http://www.openstreetmap.org/#map=15/52.2033/0.1175 is now a cluttered mess,

Wow, that looks really bad.

javbw commented Sep 23, 2014

there has to be some kind of minor/major Gate tag implemented.

I mean, when I go to the airport, I assume there is a locked gate keeping me from driving on the runway. I don't need to see it at z15

But maybe the main gates to a gated community, gates to access a mountain off the main road, etc, may need to be rendered at z15, but do the fast majority of gates need to be seen above z18?

Javbw

On Sep 24, 2014, at 8:01 AM, math1985 notifications@github.com wrote:

E.g., the centre of my home town at level 15 http://www.openstreetmap.org/#map=15/52.2033/0.1175 is now a cluttered mess,

Wow, that looks really bad.


Reply to this email directly or view it on GitHub.

Collaborator

matkoniecz commented Sep 24, 2014

And another example: http://www.openstreetmap.org/?mlat=50.0503&mlon=19.9250#map=15/50.0503/19.9250

argh

To improve my earlier idea:

What about adding access=private to private gates and not displaying gates with this tag that are placed as nodes on barriers (or displaying it on lover zoom levels)? Private gate along fence is functionally the same as fence.

Similarly, it may be reasonable to do not display gates on highways with access=private. Inaccessible road is well, inaccessible anyway.

Contributor

HolgerJeromin commented Sep 24, 2014

i really like "...not display gates on highways with access=private..."

2014-09-24 1:22 GMT+02:00 javbw notifications@github.com:

there has to be some kind of minor/major Gate tag implemented.

I mean, when I go to the airport, I assume there is a locked gate keeping
me from driving on the runway. I don't need to see it at z15

in situations like the linked one (urban setting) you'd usually not want to
see gates even in zoom 17, while in the countryside it could be useful to
have them in zoom 14 or 15 to avoid long detours. In these cases there is
another issue though, that you can't tell to which road a gate belongs in
these zoom levels, have a look here for reference:
http://www.openstreetmap.org/?mlat=52.1413&mlon=0.0740#map=15/52.1413/0.0740

javbw commented Sep 24, 2014

yea, talking about rendering rural gates, I mentioned access gates in giant parks or reserves, where a locked gate could mean hours of detours. But those are generally access yes to everything but cars - so they wouldn't be on access=private ways, so they should not be affected by the fix that was proposed.

since the idea of importance / rating is not allowed, I'm unsure of what to suggest to deal with the leftover (totally guessing) 10-20% of gates that will render incorrectly, but rendering the access=private way gates only at ~z17 seem appropriate to me.

yea, good catch on that rendering issue - is there a way for the renderer to "push" the gate onto the way it belongs to, and off of an adjectively rendered way?

those two things put together might take care of a lot of issues with gates. Then we can start collecting feedback on what do do next.

Javbw

On Sep 24, 2014, at 6:17 PM, dieterdreist notifications@github.com wrote:

2014-09-24 1:22 GMT+02:00 javbw notifications@github.com:

there has to be some kind of minor/major Gate tag implemented.

I mean, when I go to the airport, I assume there is a locked gate keeping
me from driving on the runway. I don't need to see it at z15

in situations like the linked one (urban setting) you'd usually not want to
see gates even in zoom 17, while in the countryside it could be useful to
have them in zoom 14 or 15 to avoid long detours. In these cases there is
another issue though, that you can't tell to which road a gate belongs in
these zoom levels, have a look here for reference:
http://www.openstreetmap.org/?mlat=52.1413&mlon=0.0740#map=15/52.1413/0.0740

Reply to this email directly or view it on GitHub.

Collaborator

pnorman commented Sep 24, 2014

We don't actually have way membership information available. We can detect when a line is within a very small distance of a point like we do for turning circles

Collaborator

matkoniecz commented Sep 24, 2014

We don't actually have way membership information available. We can detect when a line is within a very small distance of a point like we do for turning circles

Is it possible to look for a very small distance, so de facto one will check "is this node on a way that is {criteria}"?

Collaborator

pnorman commented Sep 24, 2014

We can detect when a line is within a very small distance of a point

Is it possible to look for a very small distance

Yes.

gravitystorm added a commit that referenced this issue Sep 25, 2014

Merge pull request #980 from mkoniecz/gates
display gates from z16 like other barriers. related to #323
Contributor

dkniffin commented Oct 1, 2014

Here's another example of gates that are poorly rendered, in respect to zoom: http://www.openstreetmap.org/#map=16/51.3028/11.4307

Contributor

dkniffin commented Oct 1, 2014

I think in 90% of cases, gates could be removed from < z17. In the case where there's a gate that blocks off a road, shouldn't that road be mapped as private anyway? Does anyone have a good example where a gate is necessary at < z17?

Collaborator

matthijsmelissen commented Oct 1, 2014

Can anyone give an example of gates that should be rendered at low zoomlevels, let's say zoom17 and lower?

Edit: @oddityoverseer13 beat me by 9 seconds.

@RobJN: do you have an opinion on this? Do UK public footways need gates renderered earlier than z17?

Contributor

Rovastar commented Oct 2, 2014

Gates in rural area are likely needed.
true maybe 90% of the time it is clutter in crazy micro mapped areas. Please remember not everywhere is as micro mapped as some of these places you keep bringing up. Let's get a balance here.

Collaborator

matkoniecz commented Oct 2, 2014

I know about a single example of useful gate at z16 - http://www.openstreetmap.org/?mlat=32.9580&mlon=-116.5800#map=16/32.9580/-116.5800 (linked by @javbw in #323 (comment) )

Can somebody find something else?

micro mapped as some of these places you keep bringing up

It is easy to display OSM data in region where nearly nothing is mapped - just show everything, as soon as possible. In fully mapped areas it gets more complicated.

I expect that showing gates so early is also not useful, it mostly harms places where somebody really mapped all gates - that is why it is hard to find useful ones.

Also, most people working on style have their areas thoroughly mapped, it results in an obvious bias.

Collaborator

matkoniecz commented Oct 2, 2014

Also, there is problem with tradeoffs. In my opinion one of the most important things is that adding correctly tagged object should never, ever reduce quality of the map.

Owner

gravitystorm commented Oct 2, 2014

Can anyone give an example of gates that should be rendered at low zoomlevels, let's say zoom17 and lower?

As @Rovastar says, in rural areas. If I'm planning a bike ride around e.g. http://www.openstreetmap.org/#map=15/51.4526/-1.7017 then seeing the gates is useful. To zoom in to z17 (or z18 as seems to be suggested here) would mean an awful lot of panning around to look for any.

2014-10-02 1:33 GMT+02:00 Derek Kniffin notifications@github.com:

In the case where there's a gate that blocks off a road, shouldn't that
road be mapped as private anyway?

no, this is orthogonal. You can have a gate that is locked but the roads on
either side could be accessible.

Stalfur commented Oct 2, 2014

My issue with gates is that they are rendered at z15 while the fences are not, leaving standalone gates like these I put into #1009 everywhere.

For some places it does not matter, like standalone gates in middle of roads, but it urban areas this clutters the map.

Collaborator

matthijsmelissen commented Oct 2, 2014

If I'm planning a bike ride around e.g. http://www.openstreetmap.org/#map=15/51.4526/-1.7017 then seeing the gates is useful.

What are the access restrictions on that gate? The access tags are missing.

I also noticed that we currently have no tagging to distinguish between gates that are usually open, and gates that are usually closed (but unlocked).

Collaborator

pnorman commented Oct 2, 2014

My issue with gates is that they are rendered at z15 while the fences are not, leaving standalone gates like these I put into #1009 everywhere.

We should probably be showing gates and linear barriers at the same zoom. My gut feelign is z16 is suitable for that - at z15 we're still in more of an overview of the area

Owner

gravitystorm commented Oct 2, 2014

What are the access restrictions on that gate? The access tags are missing.

I've no idea, I've never been there I just picked somewhere at random. It was more just to use it as an example - when using the map, we don't want people to have to zoom in too far to examine huge areas for gates if they only show up on z17.

Collaborator

matthijsmelissen commented Oct 2, 2014

when using the map, we don't want people to have to zoom in too far to examine huge areas for gates if they only show up on z17

It depends. If it is a gate that is always in open position, and passage is allowed for anyone, I don't see a reason for prominent rendering on z16 or lower, even in otherwise empty areas.

Contributor

dkniffin commented Oct 2, 2014

no, this is orthogonal. You can have a gate that is locked but the roads on
either side could be accessible.

What's the point of the gate then? Do you have an example of this? I'm sorry if I seem pushy. I'm just trying to really understand the usecase where gates at < z17 are useful.

So far, we've been talking vaguely about it and I haven't found a single instance where it's actually needed. The case @mkoniecz gave on 1/30 (http://www.openstreetmap.org/?mlat=50.0612&mlon=19.9136#map=16/50.0612/19.9136) is a decent one, but I think I'd zoom in before visiting the area anyway.

As for the example @javbw I still don't think I understand. Wouldn't you only be able to approach that gate from the east, if it's closed? In what scenario would you find yourself at the west side of that gate when it's locked?

Here's the overpass turbo link for this key pair, btw: http://overpass-turbo.eu/?key=barrier&value=gate&template=key-value I've been searching around trying to find a good example, and I haven't found any yet, but I'll keep looking.

Collaborator

matkoniecz commented Oct 2, 2014

My issue with gates is that they are rendered at z15 while the fences are not, leaving standalone gates like these I put into #1009 everywhere.

Rendering gates starts now at z16 (see merged, not deployed #980 "display gates from z16 like other barriers")

Collaborator

matkoniecz commented Oct 2, 2014

no, this is orthogonal. You can have a gate that is locked but the roads on
either side could be accessible.

What's the point of the gate then? Do you have an example of this? I'm sorry if I seem pushy. I'm just trying to really understand the usecase where gates at < z17 are useful.

Gate in this case would be a barrier that is not allowing passage through this road. Note that with current display it includes gate that may be opened by anyone, so it is only a potential barrier. http://www.openstreetmap.org/?mlat=50.0612&mlon=19.9136#map=16/50.0612/19.9136 partially fits, as it is closed during nights.

Contributor

dkniffin commented Oct 2, 2014

Oh, cool. Glad to see a pull request merged for z15. So really, what we're discussing here is just z16.

I may have found a good case to show it at higher zooms. In some areas, there are gates that close during flooding. For example, there's one for this bike path that only closes during floods. Some of those might be important to know, but this particular one is not relevant until about z18. (It's also not mapped at the moment, because I'm trying to figure out the best way to tag it)

javbw commented Oct 3, 2014

The only examples I can think of are large forest reserves, such as national parks. many of them are covered with fire roads, which are generally open to hikers, mountain bikers, and horses - but not to cars. The track will have access to cars restricted at that point.

A) the gate is a landmark of sorts, because it is shown on hiking maps. Some gates are very far away from civilization, where the road crosses from private property ( or unrestricted public use) into the park, so the gate is a good one to show at low zoom levels so you can orient yourself.

B) many of those tracks start miles and miles away, and finding a locked gate on 15 miles of track is something that can completely ruin a drive, so showing that the gate is there is very important.

I know this may only affect a small percent of gates, in mostly rural ( or uninhabited) places, but it is the example that springs to mind.

I hope there is some kind of separation of gates, like a major-minor separation so the tagger has more input in its rendering than the renderer. We trust them to draw the ways correctly, tag the ways correctly, and align the ways correctly, we should be able to trust them with their opinion on the gate too.

Javbw

On Oct 2, 2014, at 10:45 PM, Mateusz Konieczny notifications@github.com wrote:

no, this is orthogonal. You can have a gate that is locked but the roads on
either side could be accessible.

What's the point of the gate then? Do you have an example of this? I'm sorry if I seem pushy. I'm just trying to really understand the usecase where gates at < z17 are useful.

Gate in this case would be a barrier that is not allowing passage through this road. Note that with current display it includes gate that may be opened by anyone, so it is only a potential barrier. http://www.openstreetmap.org/?mlat=50.0612&mlon=19.9136#map=16/50.0612/19.9136 partially fits, as it is closed during nights.


Reply to this email directly or view it on GitHub.

RobJN commented Oct 3, 2014

I spoke to @math1985 at our Midlands social last night about this. For transparencey my comment was essentially that I felt that it would be a shame to remove things from the render/change the zoom level due to some micro mapping creating (rendering) clutter in a few cities in our most mapped part of OSM.

In rural locations gates are an important feature and landmark (when walking on the UK's rural footpaths, I often look for the gate on the other side of the field when there is no obvious paths/desire lines).

Since speaking to @math1985 I have remembered that we also have some gated public roads in the UK. I'm sure there are quite a few examples, but the ones I could find quickly are in the Yorkshire Dales:

https://www.google.co.uk/maps/@54.3748972,-1.0552395,3a,45.7y,205.7h,84.35t/data=!3m4!1e1!3m2!1sv6416bwv-LMtI-ved_dbpw!2e0
-> http://www.openstreetmap.org/node/1394202186

https://www.google.co.uk/maps/@54.4663429,-0.8627076,3a,75y,214.54h,70.17t/data=!3m4!1e1!3m2!1s8m5jH-FyTC9-Csj_BEGI_A!2e0
(This ones not actually mapped in OSM)

Roads with a bit more traffic get a cattle grid with a gate to the side for horse riders to use:
https://www.google.co.uk/maps/@54.3426925,-2.0913394,3a,75y,320.05h,74.96t/data=!3m4!1e1!3m2!1swROO7mhHULrCHKJsZI54EA!2e0

Finally roads with Winter closures (due to snow etc) often have a gate that can be closed when conditions become too poor to safely drive on them.

Collaborator

pnorman commented Oct 6, 2014

I think we can defer further discussion until the z15 change is rendered everywhere, making gates consistent with other barriers.

Collaborator

matkoniecz commented Oct 6, 2014

I am even considering closing this ticket and opening new one - with summarized discussion and applicable examples. Many current examples are from z15 and therefore currently misleading.

alex1770 commented Oct 6, 2014

I'd vote to keep this thread open (not that I get a vote - but this is my opinion, for what it's worth). Most of the examples given above are still quite bad at z16, and the issues are much the same. E.g., http://www.openstreetmap.org/#map=16/52.2033/0.1175, http://www.openstreetmap.org/?mlat=50.0503&mlon=19.9250#map=16/50.0503/19.9250, http://www.openstreetmap.org/#map=16/51.2998/11.4330. Apart from being just cluttered, the symbols are comparable in size to the width of the road and it's sometimes hard to see if the road itself has a gate across it.

Addressing a point from above: I don't think it's possible to dismiss the problem as due to micromapping. These highly mapped areas are presumably where the "early adopter" enthusiasm is and we may expect that more places will follow the lead of these. So the problem of clutter will become progressively more widespread and will have to be addressed at some point.

[Edit: spurious tree comment deleted]

Collaborator

kocio-pl commented Dec 15, 2016

Maybe we should render gates much later when tagged on some types of way (like private access and service roads)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment