Re: [OSM-talk] Ensuring Cyclewyays/Footways are routable?
> Both foot and cycle routes take a long way around (car goes even further > thought an 'access=bus' section). "access=bus"? That tag doesn't match the usual vehicletype=usageright structure, so why would you expect it to be recognized? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] access=destination valid only in one direction
Stanislav Brabec wrote: > Is there a way how to map a street with access=destination valid just > only for one direction? In the reverse direction it is a standard drive > through street. Using my proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags it would be access[forward] = destination (or access:forward = destination, depending on what syntax people like better) Of course that's way direction dependent. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Poll: Syntax for restrictions with conditions
Hi, some of you might know my proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
or its predecessor, "Conditions for access tags". The proposal presents
the idea of adding conditions to existing keys (such as maxspeed, access
...). A tag with conditions will only have an effect if all conditions
are valid. Something like this is necessary to describe many traffic
restrictions encountered in reality: restrictions only valid on wet
roads, at night, ...
The original proposal suggested using colons (":") to separate
conditions from the base key and each other. However, recently discussed
tagging concepts as well as the extensions introduced after the first
proposal have demonstrated some problems with that syntax. Most
importantly, colons
* are used by the {{tag|opening_hours}} syntax which imo would be a good
choice for timed restrictions
* are used as a namespacing solution and some recent ideas (such as
left/right ordering) might also use colons as a separator
* are used in situations where the order of key components matters. The
order of conditions, however, is semantically irrelevant.
Therefore, angle brackets ("[ ]") have been suggested on talk-de as an
alternative to using colons.
Please state your opinion in the poll on the proposal's wiki page:
Which syntax do you prefer?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxspeed tagging Was: Best-practice-idea traffic_sign
Florian Lohoff wrote: > maxspeed:wet:forward:motorcycle=50 > > Afterwards add time based maxspeeds :) > > I think we'd need a generic way to tag conditional ... Have you already participated in the syntax poll for http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags ? It's basically there to decide whether to use colons as in your example or switch to something like maxspeed[wet][forward][motorcycle]. Why? Well, because those time conditions tend to have colons in them, too (such as 15:30-18:00), and because colons are usually used in situations where the order of the substrings matters - which isn't the case for conditions, maxspeed[motorcycle][wet][forward] would be exactly the same. Once we have decided about this, that proposal can be voted on (and, more importantly, used) and we *will* finally have a generic way to tag conditions. Then we can discuss the lane problem again. ;) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] maxspeed tagging Was: Best-practice-idea traffic_sign
John Smith wrote: >> It's basically there to decide whether to use colons as in >> your example >> or switch to something like >> maxspeed[wet][forward][motorcycle]. Why? >> Well, because those time conditions tend to have colons in > > You split based on the equal sign and it doesn't matter that the time > condition or key uses colons. Read the proposal first, please. It requires that you add the condition as _part_ of the key, for example bicycle[10:00-18:00] = no It has been suggested to add them to the value instead, but you will always need to deal with substrings of either key or value string. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Emergency Access Only - How to tag?
Richard Mann wrote: > barrier=entrance > access=emergency > bicycle=yes > foot=yes > > on a node might be better access=emergency? According to http://wiki.openstreetmap.org/wiki/Key:access, emergency is a transport mode key, so it should be access=no + emergency=yes (I don't think *=emergency is necessarily a bad idea, it's just not what is currently documented.) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] conditions as part of value/key (was: Re: [RFC] restriction=school_zone (second email))
Martin Koppenhoefer wrote > I can't really see the point of not putting values in keys > actually. Aren't we already doing this in many tags? > > why is this a value in the key: > maxspeed:wet=40 > couldn't you interpret "maxspeed:wet" as a key? The maxspeed in wet > condition? Could you explain the problem that arises (I am not an > informatics person and maybe for this don't understand these details > adhoc). "Pure" keys are commonly thought of as unique identifiers, not subject to any evaluation. They are often used in data structures that allow easy access to a value if you know the key (give me the "maxspeed" information) but are not really designed for any other operations using keys (give me all tags starting with "maxspeed"). Of course, no one forces you to represent the OSM key/value structure in your application. I'd also like to point out that using bicycle=yes and similar tags, rather than access = no; [biycle]yes; [foot]yes (or a similar solution), is already a deviation from the "pure" approach and is in no way different from, say, maxspeed:wet. Basically, we have the following options I know of: - conditions in keys This has the advantage that it will not break applications that only evaluate the "normal" tags, will work with current API and is relatively easy to edit. - conditions in values: Also possible, but means all information of the same category (e.g. all maxspeeds) will be in a single value, which will result in rather long tags. It will also break existing applications unless you redundantly add both "normal" maxspeed and "modernized" maxspeed tags. - link multiple tags using index in key (such as maxspeed[1]): Does not result in "pure" keys either, so I don't quite see the point. - using relations: Too hard to edit, imo. You may still suggest this if you are willing to implement support for this in all major editors. ;-) There is a proposal in "brainstorming mode" (read: vague collection of ideas) for this, though, but it doesn't seem to make any progress: http://wiki.openstreetmap.org/wiki/Proposed_features/Access_restrictions - hierarchical tagging: Nice but would require major API change. Not possible right now. The issue of keys vs. values was recently brought up on the talk page of the "Extended conditions for access tags" proposal, btw: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extended_conditions_for_access_tags#Move_parameters_from_key_to_value However, I'm still wondering if someone has any *practical* objections to conditions in keys or if it's just the (understandable) "that's not really 'key-ish'" feeling. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] conditions as part of value/key
Roy Wallace wrote: > You don't need "all maxspeeds" to be in a single value. Nor would it > break existing applications. Maxspeed=* is still maxspeed=*. You would > be adding additional keys such as maxspeed:time, or maxspeed:vehicle, > or maxspeed:weather, etc. That seems to be superior to other value-based approaches I've seen so far. However, I can't see how you would handle a situation with multiple conditions for a tag's value, for example what I would express as "maxspeed[hgv][wet]". Did I miss something or is that simply not possible? > The only disadvantage is that if you have > two of the same kind of restrictions, e.g. an "in general" maxspeed, > plus TWO OR MORE maxspeed:time restrictions, for example, you need to > add _1, _2 at the end of the keys, which sucks, although John pointed > out this is apparently already in use. I haven't ever seen this one being used (though I can imagine it as an attempt to set multiple alternative names and the like) and for sure I haven't seen any documentation for it. It definitely isn't really "key-ish", either. ;) > But, I disagree with you that putting conditions in keys has much > advantage over putting conditions in values, so IMHO why not go with > the gut feeling and keep keys key-ish... Well, we already have some keys which are actually conditional tagging in disguise, such as bicycle=yes (which is an access=yes with a vehicle condition, imo). So /keeping/ keys key-ish might not quite work... Btw, it's nice to finally get some ideas about the conditional tagging issue. I only wonder why people didn't provide this sort of feedback when I explicitly requested it for for my proposal[1] and its predecessor. *scratches head* Tobias Knerr [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Mike Harris wrote: > And I still don't think turnstile is in any way a type of stile any more than > a stile is a type of gate. +1 The English word for turnstiles may end with "stile" for some reason I don't understand, but that doesn't mean it actually is a type of stile. barrier=turnstile is clearly the better solution. This really cannot be described by any of the existing barrier values. (Otherwise, I'd of course suggest a sub-tag.) After all, renderers can still use the same icon for different tags if the developers don't consider the distinction relevant for the rendering. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] to all potlatch and JOSM users - automatic simplification of geometry
Richard Fairhurst wrote: > _That_ is why this function is here: to simplify the work of one of the most > tedious parts of TIGER fixup. As always, "it's of no use for my mapping" > should not be extrapolated to "it's of no use and should be banned". But maybe "in those parts of the world where streets are not perfectly straight, it is of no use and even dangerous in the hands of newbies" should be extrapolated to "it should not be included by default but provided by a plugin/option"? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Dave Stubbs wrote: > Now it's an organised, and "approved" confused mess where anyone with > a clue automatically withdraws from discussions to keep their sanity > intact [...] knowing full well that not being there won't make much > difference to the eventual stupid decision. Do you have some examples for bad decisions that were produced by wiki voting? "path" isn't a good example because most of the chaos actually stems from people using the pre-ochlocracy foot-/cycle-/bridleway without having a common definition for what they actually mean. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] A process for rethinking map features
Tom Chance wrote: > - Tags are proposed on the wiki, no change to current practice > - If the proposal throws into question existing, accepted tags, defer the > proposal to small working groups > - These working groups study the wider questions and formulate a complete > proposal for new tags, deprecation, etc. People can do this already, and I'm sure that a good proposal created by a working group would easily be accepted in a wiki vote. > - At SOTM present and discuss their proposals and vote Aka the "people who have time and money to get to SOTM decide" approach? I still prefer the "people who care about the issue decide" approach. > - If proposals are accepted, a combination of carrot (rendering > stylesheets, Potlatch presets, etc.) and sticks (error checking, > auto-correcting bots) to implement the accepted proposals On the one hand, you still cannot force software/stylesheet developers to use your proposal. On the other hand, we could try the same thing right now. The path proposal could have been successful long ago if applications were pushing it instead of refusing to use it (see CycleMap). So where's the difference between your suggestion and the current situation, except that you want to limit participation to people at SOTM? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Tom Hughes wrote: > That's a completely ridiculous quorum when we have 1 active mappers. > If the process says that eight people can get together and tell > thousands of people that they've been "doing it wrong" for the last five > years and should start retagging everything according to some new scheme > then the process is broken. Those eight people can only do this if not even 0.1% of the other 1 care enough to oppose the proposal. If that's the case, then apparently the proposal isn't so bad, is it? Why didn't all those people who apparently hate "path" vote against it? You seem to assume that people who use a tag actually implicitly "vote" for it. In practice, most mappers simply use what's there and don't mind using something else if that's what their editor presets / wiki documentation / neighbors are using now. While path may have been "approved" by a minority, it's also a minority who is complaining about it now. If applications and editors consistently used path, then most of your 1 wouldn't spend a second thought on it. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
David Earl wrote: >> Why didn't all those people who >> apparently hate "path" vote against it? > > (a) because not everyone has the luxury of following all this with the > hundreds of emails a day and all. > > (b) because many people just ignore the voting system as it has no > official status, and do their own thing. The map renderers generally > have more influence on what tags are used IMO than any amount of voting. The people I'm talking about are those who complain about the result of the voting on "path" on this very mailing list. Apparently, they (a) follow this mailing list with the hundreds of emails a day (b) care about the voting result in a way (they don't complain about the fact that highway=path is being rendered, do they?) The proposal concept requires that people who find problems with a proposal voice their opinion. It's everybody's right to refuse participation. But I don't think it's good style to use the problems resulting from that refusal as a proof that that process cannot work. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Shaun McDonald wrote: >> Another property that turnstiles have is that usually one can pass in >> only one direction. But how that is going to be tagged if a turnstile >> is just a node I have no idea. > > A footway going through it with the tag oneway=yes? oneway=yes isn't a good idea, as oneway is generally assumed to /not/ affect pedestrians. (Or how many of you actually add an exception for pedestrians when mapping a highway with oneway=yes?) I'd therefore use something like foot[backward]=no (or whatever syntax for conditional tagging is your personal favourite) on that footway leading through the turnstile. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Martin Koppenhoefer wrote: >> I'd therefore use something like foot[backward]=no (or whatever syntax >> for conditional tagging is your personal favourite) on that footway >> leading through the turnstile. > > does this imply to split the way on the stile? Do you split it on > either side? This can be applied to any way as long as that way needs to be used when passing the stile. The stile should be a node on that way, but whether it is the first/last node or any node inbetween doesn't matter at all. > What about splitting it directly on the stile. By this > you could just tag one snip of the way towards the side you are > allowed to go as "stile_direction=yes" or something similar, without > being dependant on the direction of way. Similarly a relation could be > imagined (like turn_restriction). This is a special case useful *only* for this situation - which is an unnecessary burden for implementation of routing applications. It's preferable to use something that can be used to handle all sorts of different situations (and therefore needs to be implemented anyway). You can do something like stile_direction or a relation if you expect it to be used in rendering, but I'd definitely recommend to also use a tag like the one I suggested on the way to allow a more generic evaluation for routing/navigation. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Martin Koppenhoefer wrote: >> This can be applied to any way as long as that way needs to be used when >> passing the stile. The stile should be a node on that way, but whether >> it is the first/last node or any node inbetween doesn't matter at all. > > I see this differently as the restriction does not apply to the whole > footway but just to the part crossing the style. If the footway is > some kilometres in length, why would you want to map it as oneway for > all this part? I wouldn't, I originally thought about adding something along the lines of "of course, that way shouldn't be kilometres long", but thought it was obvious anyway... In most situations reality will provide a way section with a length of a few meters whose only purpose is to go through the stile, so there will be a "natural" way to use for this. Otherwise, people will probably be intelligent enough to just split it. > IMHO you have to split the way after ~50cm after the > stile (width of the stile) and not to start before your inside the > stile (otherwise you will get "trapped" inside a normal footway (for > routers) not beeing able to return if e.g. the stile is closed. I don't think that this "trapping" situation is relevant in realistic cases (i.e. a few metres of way tagged like that) - it will even be below GPS accuracy. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Shaun McDonald wrote: >> oneway=yes isn't a good idea, as oneway is generally assumed to /not/ >> affect pedestrians. (Or how many of you actually add an exception for >> pedestrians when mapping a highway with oneway=yes?) > > The exception being highways that are for pedestrians, i.e. footway and > pedestrian. That exception isn't documented anywhere, really rare and as such unlikely to be included with all applications. It might make sense to you as a human, but what's the general rule that would describe the desired behaviour? For example: Would oneway apply to pedestrians if used on highway=path? Would this depend on the access tags used together with it? >> I'd therefore use something like foot[backward]=no (or whatever syntax >> for conditional tagging is your personal favourite) on that footway >> leading through the turnstile. > > That's an uggly looking tag. That sort of tag or anything equivalently expressive is required to represent some situations. I'm not proposing it specifically as a solution for this case. However, as a general solution for conditional tagging (depending on direction, vehicle, time, etc.) is needed anyway, it can be used to solve this as well. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
DavidD wrote: > Mapping is enough work as it is without having to frequently check > proposals in the wiki. A proposal should be be announced on the mailing lists, so you don't need to check the wiki. That doesn't help people who don't read the mailing lists, but the lack of a central communcaition channel is a problem of its own. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Country-specific defaults/values (was: Re: Proliferation of path vs. footway)
David Earl wrote: > My feeling is that what we are missing is largely country-specific > defaults. Or rather we have failed to recognise this in the > documentation, but it is what pretty much everyone is doing in practice > already, and that's got a lot going for it. If "cycleway" does mean something different in Germany than it means in UK, why do we try to use the same tag/value in the first place? Why don't we use, e.g., "Radweg" for Germany? (Or differentiate with prefixes or something like that where different nations use the same language?) I feel it would be much easier to document a tag if it had only one meaning. (It would also make the discussions /prceding/ the documentation easier...) Also, using country-specific values would avoid the requirement to map everything onto that "footway/cycleway/bridleway" scheme. It's entirely possible that there are countries whose categories don't fit in there. It wouldn't be harder to evaluate for applications (such as routers). Country-specific defaults require machine-readable information that maps (value + boundary) -> access rights. Country-specific values require value -> access rights. So, in fact, it might even be a bit easier for applications because it doesn't require "were am I" checks. Of course, it becomes harder to create "one size fits all" renderings, which probably is a major reason why we internationally use the same tags. So I'm actually not sure whether country-specific defaults are the ideal solution. Country-specific values /might/ be the better choice. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Country-specific defaults/values
Richard Mann wrote: > Neither is acceptable. How long do you want style-sheets to get? A list of values mapped to a certain style doesn't strike me as particularly complicated to implement. Especially as these lists can be compiled with the help of national communities. I assume if you set up a wiki page with those lists to be filled out by people who know their national tags, it will be ready in no time. We are a community project here, you don't need to do everything yourself. > Plus - what languages are all these tags going to be documented in? English + local language? Should be enough. Add to this a machine-readable template which could list, for example, default access rights, and you can feed that knowledge directly into software. > Somehow we need to get to a common-enough definition that we can all live > with. Which is not to underestimate the scale of the task! It's just that we have failed to create that definition so far. The task would become rather easy if we didn't have to deal with differing legislations at all. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] park barrier
Martin Koppenhoefer wrote: > Therefore I would explicitly recommend that the way starts at the > turn-stile following the direction of passing through it, as you will > never turn back once passed, while you might always turn back before > you pass it. You can add this to the wiki as a recommendation if you want. Of course, this would require that barrier=turnstile was properly documented in the first place. Apparently, it still isn't. (It's mentioned on Key:barrier, but is not part of the table and doesn't have an own page either.) Does anyone object to adding it? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Country-specific defaults/values
Roy Wallace wrote: > "Differentiate with prefixes"? Messy... If "cycleway" means "A" in > Germany and "B" somewhere else, then cycleway is not a good tag. > Instead, we should explicitly tag "A" where it applies and tag "B" > where it applies. This would mean to totally get away from the concept of highway values and move to separate tags, because "cycleway", "motorway", "primary" and all the other values have different meanings in different parts of the world. I don't mean to say that this is a bad idea per se, but it requires * good, universally applicable definitions for these separate tags * exhaustive and complex editor support (having to look up and add a whole bunch of tags for each road isn't an usable concept) * clever rendering rules that can take multiple tags into account Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
Hatto von Hatzfeld wrote: > On http://wiki.openstreetmap.org/wiki/Approved_features/Path you may count > how many people approved the proposal but explicitly opposed the > deprecation of existing tags. Yes, many participants opposed the deprecation, as did I. However, I wanted to keep those tags as clearly defined shortcuts for common key combinations (that is, highway=footway e.g. should be exactly the same as highway=path + foot=designated), simply to ease transition and save some typing effort. Right now, however, people are trying to interpret some additional meaning into the path vs. *way distinction that originally wasn't there at all. (Things like paved surface, urban vs. rural, intentionally maintained etc.) This is definitely *not* what I voted for. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Selecting cycleways
Martin Koppenhoefer wrote: > 2009/8/17 Rahkonen Jukka : >> OR highway=briddleway AND "bridleway", but I guess that's just a typo. >> (bicycle=yes OR bicycle=designated OR bicycle=permissive) >> OR highway is not null AND cycleway is not null You might want check for cycleway=no here, there are a few hundreds of them. > I'd also have a look at tagwatch searching for "cycle" to see all the > possible variations. I wouldn't do this. Just correct those "variations" (aka errors) in the data if you care about them. > I'm not a programmer but it seems to me that you're missing same > parenthesis Assuming AND binds more strongly than OR, the query seems correct. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Selecting cycleways
Rahkonen Jukka wrote: > Cartinus wrote: >> You'd want to exclude cycleway=opposite as well, because that is just >> removing the oneway restriction for bicycles. > > But isn't it still kind of a cycleway and thus worth making it visible > on a cyclemap? I forgot cycleway=opposite in my first reply, but it really isn't a cycleway. Imo, "cycleway" is a bad choice of key for this, something like oneway:bicycle=no would be much more appropriate. Unlike cycleway=opposite_lane and cycleway=opposite_track, there isn't any road or section of road specifically intended for bicycles, so it isn't more of a cycleway than any ordinary road. Of course, a cyclemap should still make sure to visibly indicate whether an oneway rule applies to bicycles. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Lane turn restrictions
Steve Hill wrote: > Is there any suggested way of marking up turn restrictions for individual > lanes of a road to enable sat navs to provide lane guidance (e.g. "keep > right", "move into the left lane", etc)? There is no accepted or widely used approach to do this, and actually I don't think it makes much sense to create a concept for this before we have a good concept for modelling the lanes themselves. If we decide to model lanes as individual ways or relations, these lane turn restrictions would, of course, contain the lanes as members. If we add the lanes as numbered tags (e.g. "right1:", "left3:"), then we should refer to these numbers. If we do something completely different, then the lane turn restrictions need to adapt to that. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Lane turn restrictions
Roy Wallace wrote: > But I agree with Tobias also - we should first create a "good > concept for modelling the lanes themselves". Tobias, could you link to > the latest/most promising proposal, if there is one? If we already had a superior proposal, this would be a lot easier. What we have so far is: * a German-only page that lists some alternatives, mostly tag-based solutions: http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Workshops/Linienb%C3%BCndel * a rather old proposal I've created myself (though I'm no longer convinced it would work in practice, it's probably a bit too complex to be widely used without editor support): http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group * some unconnected suggestions like this talk page entry (that didn't go anywhere so far, but a proposal based on the idea could actually work): http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Advanced_footway_and_cycleway#Expanding_this_proposal_to_include_multi-lane_tagging Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Proposal for tagging the general direction of a way as incline=up/down: http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Lane turn restrictions
Martin Koppenhoefer wrote: > I'm opposing this approach of just tagging different lanes to one way > as this gets too complicated in complex situations (I know situations > with more than 18 "lanes"). I'd prefer to get to a > map-all-lanes-and-dividers-as-separate-ways-approach and then > recombine them with a relation Which is too complicated in simple situations. Maybe "one approach fits all" just doesn't work. Honestly, I don't think any solution that /requires/ lanes to be mapped as ways can be successful, it will cause significant additional work when it comes to junctions, to moving ways and other editing operations. Neither do I think mappers should be required to use relations for simple cases. To me, the most sensible solution would be one that allows representation by a single way with the highway tags and several tags referring to individual lanes (in a way that doesn't even require you to add all lanes - you might only be interested in adding some detail to that cycle lane, for example). At the same time, the solution might offer the /option/ to split lanes off the collective highway (i.e. map them as own ways) and link them to the highway using a single relation as well. I believe it fits the project's general spirit to allow mappers to choose their level of detail (and other mappers to increase it if they are ready to invest the time). Lod steps could be described as 1. road without lane detail 2. road with partial lane data (think cycleway=lane) 3. road with full lane data, but no lane geometry 4. road with full lane data and partial lane geometry (e.g. individual ways only for pavements and bicycle lane, but not for the perfectly parallel car lanes) 5. road with full lane data and geometry Allowing only separate ways would take away the choices #3 and #4 and limit #2 to the sort of tags we already use (i.e. no proper ordering, no sub-tags for lanes). Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
Peter Childs wrote: > http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator > > I'm trying to work out how to tag Escalators I'm not sure the current > tagging it clear, or even partially useful. I wouldn't call this "current tagging". That page is a proposal in "draft" state, i.e. its not even in the "please look at my proposal, try it and comment" state (aka "RFC"). So if we find something better, we can just use that instead. > There seams to be no clear way to tag "Moving Walkways" or Travelators > these are Esclators without steps, so the current tagging steps with > an extra tag just does not work, spouse you could tag a path, but that > just makes it worse. I believe the best way to solve this is to create a new top-level (that is, highway) value for all variants of conveyor transport. So, for example, we could do: highway = conveyor conveyor = escalator / travelator incline = up / down / (nothing for horizontal travelators) If required also something like: conveyor:direction = forward (default) / backward / on_demand Using a highway value is justified because applications that don't know about this kind of feature would use it wrong anyway (e.g. route in the wrong direction). Would that solution work? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Hi, it's a good thing that someone finally tries to clarify access documentation - it definitely needs some care. I agree with your reasoning to replace the image with editable content and some of your definitions (such as avoiding to put an entry into the hierarchy multiple times and separating water/land). Nevertheless, some changes require a bit of discussion, but I guess you expected this, didn't you? ;) Christiaan Welvaart wrote: > Added a separate tag for cars, because AFAICT any routing app computing > routes for cars uses this transportation mode. If routing would be done > for 'motorcar', ways tagged as hazmat=no, for example, could not be used > because the motorcar *could* be a hazmat vehicle. This reasoning is not quite valid. The restrictions for a vehicle category are affected by categories higher up in the hierarchy, not by those below. At least this is the idea behind current documentation such as http://wiki.openstreetmap.org/wiki/Computing_access_restrictions , and I don't see why we should be restricted to leaves of the category tree. Therefore, considering an automobile a generic "motorcar" that is affected by those restrictions applying to generic motorcars should work well, it doesn't need an own category. > * Direction specific restrictions > > I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags While direction may be considered as something special when constructing a routing graph (unlike most other parameters it will have different values during creation of the same routing graph; unless you are really sophisticated and use changing time, it will be the only parameter like this), it's not a special case for *evaluation*: It's just another parameter needed to get the value of a base tag for the current situation. As evaluation is the aspect that needs to be documented (routing graph creation is up to the application), I believe forward/backward shouldn't be introduced or documented separately but instead as a part of conditional tagging. > * Evaluating access tags Your use of "category" and "(transport) mode" confuses me, especially as they both seem to be things that can be a key. I know from experience that it is hard to find good terms for these concepts, but maybe you can help me a bit to understand it. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
Stephen Hope wrote: > 2009/8/23 Tobias Knerr : >> I believe the best way to solve this is to create a new top-level (that >> is, highway) value for all variants of conveyor transport. > [...] > Is this intended to be only for human transport? I know of some quite > lengthy conveyors for goods - eg coal, grain etc. There's two main > types, belt and screw, and I've seen a mix of both. Escalators and > travelators are both belt conveyors. I don't know if we want to try > and differentiate for goods use, or just lump them together under > something like "conveyor=goods, type = grain/coal/gravel/etc". We > certainly want to make it easy for routing programs to differentiate > between goods and human ones. Using the same top level tag (e.g. highway=conveyor) would only make sense if applications could use both the same way, and I don't believe there are apps that can. Routers don't need conveyors for goods for their calculations, and a rendered map displaying it like a pedestrian conveyor transport would certainly irritate users. So using the same tag would only result in making evaluating (and tagging) the conveyor=* tag required. Therefore, I'd prefer to restrict highway=conveyor to human transport (or human+bicycle or some kind of vehicle, if this exists somewhere, by using access tags) and use a separate top level tag for goods - for example man_made=conveyor. Maybe it would be better to use different values, too, such as goods_conveyor vs. "human_conveyor"*? Tobias Knerr * I'm not sure whether this is a name at all, maybe someone is more creative... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
John Smith wrote >> So using the same tag would only result in making >> evaluating (and tagging) the conveyor=* tag required. > > Which already happens with those pushing path tags instead of footway etc... > highway=path, foot=designated... No, it doesn't happen there. Evaluating access tags is already necessary for highway=footway, too (bicycle=yes etc.), so path doesn't require evaluating additional tagging. > So I don't see that as a good enough reason to have multiple highway tags. Nobody suggested "multiple highway tags". The highway tag currently only contains features that are relevant for routing pedestrians or vehicles, and I prefer it to stay like that. Things like pipelines or goods conveyors don't belong into this category. What's the disadvantage of using highway=conveyor and man_made=conveyor for human vs goods conveyors? If there isn't any, then how can a reason not be "good enough" to do it? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Mike Harris wrote: > If everyone agrees that the architects' convention should be adopted, could > we document this? Even if people on the mailing list agree, most mappers will still not know about the convention. There will be no way to distinguish the steps of those who do know it from those who don't. Is there any realistic chance of reaching a situation where almost all steps will point in the same direction? It would at least require every editor to unambiguously convey the directionality of steps and its meaning - an entry in the wiki will not be read by someone using that seemingly obvious "steps" preset. Personally, I still think adding that little incline=up tag would be worth the effort... Tobias Knerr PS: How about adopting inline quoting for your mails to the list? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
David Paleino wrote: > I'd like to start discussion on the deprecation of the Tag:highway=stop in > favour of using stop=yes/both/-1. How about adding forward/backward information to each stop sign node instead? Would depend on way direction, of course, but as the stop nodes would be placed on single ways rather than intersections, it would be possible. Is there a reason why you didn't choose this approach? (I do not have an opinion yet, I'm just interested in arguments for the different options.) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
Stephen Hope wrote: > Can I suggest that the documentation for the human > conveyor has a section that states clearly that it is not for goods, > and pointing to the goods tagging. And maybe the reverse in the other > tag. This can and should be done this way. Hopefully, editor preset makers and translators will also take care not to choose misleading descriptions. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Christiaan Welvaart wrote: >> http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags > > This proposal does not seem specific enough. Shouldn't it list exactly > which simple keys can be modified this way, especially for the > : extension? There is no need to list keys because it can be used for every access-related key. Nevertheless, I'll probably create a more detailed page about conditional tagging in the future which can include base keys. > For example, with this proposal it is > possible to create both bicycle:backward and oneway:bicycle, while I > would really prefer to only have the former. If we don't try to abolish oneway completely, I would prefer the latter in most situations. My opinion is that a base key should not be able to remove a restriction introduced by another base key. For example, hgv=yes should not be able to remove a maxweight=3.5 restriction. Similarly, an access tag (such as access:bicycle:*=* or short bicycle:*=*) should not be able to remove an oneway tag. This principle makes understanding and evaluating the tags much easier, imo. To get a value for maxheight, you check all maxheight:* keys and nothing else. The same goes for oneway and all other base keys. One example why I think oneway and access (including the transport mode and category tags) should not affect each other: In front of a station, there is a road that must not be used by motor vehicles except busses. This road also is an oneway road, with no exceptions. Therefore, I consider it natural to tag this - oneway = yes - (access:)motor_vehicle = no - (access:)bus = yes This can easily be understood if oneway isn't influenced by the other tags. If, however, we consider oneway=yes just another way of saying (access:)vehicle:backward=no, then we suddenly have a problem: Neither of the two conditional expressions "vehicle:backward" and "bus" is more specific than the other one, so we cannot determine whether the yes from "bus" or the no from "vehicle:backward" is relevant here. To sum up: Yes, both bicycle:backward and oneway:bicycle are direction-dependent restrictions for bicycles. However, they are still different because only oneway:* keys should be able to overwrite other, less specific oneway keys. In practice, this means that :backward will rarely be useful for bicycle, it makes more sense in combination with maxspeed and sometimes other base keys. >> As evaluation is the aspect that needs to be documented (routing graph >> creation is up to the application), I believe forward/backward shouldn't >> be introduced or documented separately but instead as a part of >> conditional tagging. > > Is it really a problem if work is one in this respect as long as it does > not contradict the conditional tagging proposal? There were some suggestions to use brackets instead of colons for this (such as bicycle[backward]=no or hgv[06:00-10:00]=delivery) because conditions are not what colons have been used for before - for example, they don not have a defined order. Probably, though, colons are better anyway because using different syntax for different postfix semantics would only lead to confusion and inconsistent uses... > A (transport mode) category is simply a group of transport modes and/or > other categories that are sometimes treated similarly regarding road > access (by law). Ok, thanks, I now understand what you mean. I thought it had something to do with the access values (forestry, delivery and so on), because except for destination, they are not mentioned by your description at all. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Christiaan Welvaart wrote: >> In front of a station, there is a road that must not be used by motor >> vehicles except busses. This road also is an oneway road, with no >> exceptions. Therefore, I consider it natural to tag this >> - oneway = yes >> - (access:)motor_vehicle = no >> - (access:)bus = yes >> This can easily be understood if oneway isn't influenced by the other >> tags. > >> If, however, we consider oneway=yes just another way of saying >> (access:)vehicle:backward=no, then we suddenly have a problem: Neither >> of the two conditional expressions "vehicle:backward" and "bus" is more >> specific than the other one, so we cannot determine whether the yes from >> "bus" or the no from "vehicle:backward" is relevant here. > > This can be defined. As I described it one would have to write > bus:forward=yes , but people may indeed expect bus=yes to work. Yes, it can be defined, of course. I believe that the results of an "independent evaluation per base key" rule comes close to what many people assume about the tag's meaning (its impossible to match all current expectations, unfortunately, because different people have different, sometimes contradicting opinions in absence of clear definitions) and are rather easy to understand. > It is not clear from the text on the proposal page that > oneway: is more specific than > :forward ... It would be nice to have an explicit > description of how all the different tags can be evaluated. I'm going to put together a comprehensive description of how I think access evaluation w.r.t. conditional tagging could work as soon as I have the time. I hope that this will make things clearer. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=construction
Liz wrote: > http://wiki.openstreetmap.org/wiki/Tag:highway=construction > > this page says that you have highway=construction along with any other > highway > tag eg highway=trunk No, it doesn't (unless I'm missing something). It says that construction uses the /value/ of other highway tags: "Values of construction=* can be all values from highway=*, railway=*, waterway=* and landuse=*." So what you do to mark a trunk under construction is to use two tags: highway=construction + construction=trunk As you use the construction instead of the highway key to store the highway value "trunk", this is possible even with API 0.6. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Proposed feature: Directional node
Andrew MacKinnon wrote: > This is a proposal for a generic way of tagging a node which > represents an object which faces a certain way - e.g. a traffic sign > such as a stop sign. It lacks an example where this complex modelling would even be necessary. In all examples mentioned so far, a node modelling the direction-dependent objects is part of a single way, so directions (forward/backward) can be based on the direction of that way. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to tag lanes, not ways, was: Deprecating the use of Tag:highway=stop in favour of Key:stop
John Smith wrote: > Actually no, you can still tag stop signs on a way like people always > have, then when lanes get sorted out they can be dealt with properly. I believe that stop signs have usually nothing to do with lanes (though there probably are exceptions). They apply to everyone travelling into a certain direction, no matter on what lane. This becomes apparent in streets where there are no distinct lanes for the two directions of traffic: Stop signs will still apply to everyone moving towards a junction. They will not apply to certain lanes, obviously, because there are none. So except for truly lane-based stop signs, I think that expressing stop signs using lane-based methods would be a bad idea - as they are direction based, not lane based, in reality. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - conveyor
Proposal that suggests to use highway=conveyor for conveyors that transport persons, namely escalators and travelators (moving walkways). http://wiki.openstreetmap.org/wiki/Proposed_features/Conveyor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Software Freedom Day
Liz wrote: > SFD is using a well known proprietary map on their web site. > Is there anything in this which OSM or one of its derivatives can't do > already? How about "offer reliable service with good uptimes"? After the recent maintenance weekend it was stated that our services are not really intended for the public (at least if they need them and don't just experiment with them) and we are only about data. If that's still the case, recommending the use of these services to the public doesn't seem like a good idea. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] lists and # of subscribers
Alex S. wrote: >> I often find myself wondering how many are subscribed to the various >> osm lists. > [..] >> Is this information that can be easily extracted from mailman[..]? > > No.. Many people (including myself) subscribe to the lists through a > gateway like gmane.org, so those numbers are off. Even if the number of subscribers is slightly flawed, it would still be able to show *relative* list size (talk_a is six times larger than talk_b) and growth (we now have 50 % more subscribers) - if we assume that the percentage of gateway users doesn't vary wildly. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] source=(survey, yahoo, gps...)
Liz wrote: > On Tue, 8 Sep 2009, Shaun McDonald wrote: >> I'm not going to waste my time updating a source tag on every node, >> way or relation that I touch. However I'm happy to add ti to the >> changeset where it belongs. > > It's actually quite easy in JOSM > you mass select them and add the tag If mass selecting is possible, the changeset would have been the better place, imo. Tags on individual objects do only make sense if you need to add different source information for each object (or maybe even each tag). And that's as much work in JOSM as everywhere else. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: source=(survey, yahoo, gps...)]
David Earl wrote: > On 08/09/2009 13:16, Tobias Knerr wrote: >> Liz wrote: >>> It's actually quite easy in JOSM >>> you mass select them and add the tag >> If mass selecting is possible, the changeset would have been the better >> place, imo. Tags on individual objects do only make sense if you need to >> add different source information for each object (or maybe even each >> tag). And that's as much work in JOSM as everywhere else. > > It does differ: while most of a survey will be survey, I am also > estimating and interpolating and using landsat and joining things up > with npe. It's not a property of the changeset. So how do you mass-select exactly those objects you created based on a given source (mass-selection was the topic of the mail I replied to)? Regardless of mass-selection, "I used npe, landsat and survey" is a valid property of the changeset. It may be possible to give more detailed information, of course. But most mappers don't add source tags, and a changeset source would provide at least some information. You can continue to add source tags to individual objects if you think it's worth the effort - it's your decision, as with all tags in OSM. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Address interpolation
Ed Loach wrote: >> possible ways, where data can be. Please use only >> addr:interpolation on >> the way and everything else on the nodes. > > http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_interpolation_to_mark_many_houses_along_a_way > (shortened to http://is.gd/34St1 ) > That example shows ONLY the house number on the nodes, and > everything else on the way used for interpolation. That was added to the example one month ago, after the proposal was marked as approved, without discussion, by a single user and above all hidden in a heap of edits (so people were unlikely to even notice the change). http://wiki.openstreetmap.org/index.php?title=Proposed_features/House_numbers/Karlsruhe_Schema&diff=next&oldid=318077 I am going to revert this. That's a very sneaky way to change the example, and even if we were to agree now that adding the tags to the interpolation way is better, we shouldn't change the original proposal page but modify current documentation instead (e.g. http://wiki.openstreetmap.org/wiki/Key:addr ). Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to map cemetery ?
David Earl wrote: > I think the original distinction was that a graveyard is the burial > ground around a church, while a cemetery is a separate pice of land set > aside for burials, not necessarily associated with a church, or a > denomination - in the UK, many of these are operated by local > authorities not religious institutions, while the graveyard around a > church is exclusive to the church. > > Having said that, I kind of agree with you, that the distinction is > subtle and probably adds little. Apparently someone overestimated the importance of little details that could well have been expressed by an additional tag. There is hardly a good reason for most applications - and for most mappers - to differentiate, so this doesn't warrant a different top-level tag. Is there still some chance to get them merged? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing over barrier nodes
lulu-...@gmx.de wrote: > Currently the problem with routing is, that routing applications can not > check for millions of nodes, but only for thousands of ways without > performace problems. No, the problem is that programmers haven't implemented it yet. If the software can deal with turn restrictions, it shouldn't have a problem with barriers at all. Performance problems instantly disappear with appropriate preprocessing. > I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways I disagree. It is possible to take barriers into account without that tag (I've implemented it for the GraphView plugin, for example), so the tag obviously wouldn't add or improve information. Mappers shouldn't do the job of a software preprocessor. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Address interpolation
>> So I should remove: >> addr:city = Osijek >> addr:country = Croatia >> addr:postcode = 31000 >> addr:street = Starigradska >> >> from way and put it back on nodes? Imo, yes, you should put all those details onto the objects that carry addr:housenumber (either nodes or building outlines). That's the method intended by the documentation and I don't see a good reason for not sticking to it in this case. Brian Quinion wrote: > However there are > plenty of cases where people have used it as I suggested because it > makes sense It does not make much sense to add information to a temporary construct (interpolation way) that will be replaced with individual tags on each building outline in the long term anyway. > and any one implementing reading OSM data for addresses > will have to deal with both I think an evaluator can ignore addr:street on interpolation ways - with documentation and tools (such as JOSM presets) supporting consistent tagging you will be able to extract most data this way. Unless, of course, enough people prevent consistent tagging by denying its possibility. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to map cemetery ?
Valent Turkovic wrote: > Please make clear if there is going to be used only cemetery tag or will > there be two tags; cemetery and graveyard. I can't tell you what tags will be used in the future. I (and some others) would prefer to remove the distinction between the two tags and use the same tag for all burial places, but that's only a suggestion and does not (yet) reflect tagging reality. Current documentation suggests that there are two tags and that there is a vague distinction between cemetery and grave_yard: grave_yards tend to be smaller, older - sometimes even disused -, more likely to be property of a religious organisation and are usually in proximity to a place of worship. There is no exact definition, though. > What is the difference between graveyard and grave_yard tag? "graveyard" does not exist as a documented tag. > Here on the wiki: > http://wiki.openstreetmap.org/wiki/Proposed_features/graveyard > says that cemetery tag is to be obsoleted?!? This is really confusing. This is a proposal that didn't get far, so it isn't really relevant for now. Not everything someone has written on the wiki is relevant documentation, especially if they have written "proposal" over it and no one has touched the page for almost two years. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=steps ramp=yes mapping stairs.
Erik Johansson wrote: > I added ramp=yes|no to highway=steps, for steps where strollers and > bikes can pass. > [...] > http://wiki.openstreetmap.org/wiki/Key:ramp > http://wiki.openstreetmap.org/wiki/Tag:highway%3Dsteps As you don't mention the "Steps_features" proposal, did you miss it? See: http://wiki.openstreetmap.org/wiki/Proposed_features/Steps_features It proposes exactly this (a ramp=yes|no tag), as well as ramp:stroller=yes ramp:bicycle=yes ramp:wheelchair=yes ramp:luggage=yes|automatic|manual to further differentiate the types of ramps - a ramp for bicycles might not be usable for strollers, for example. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=steps ramp=yes mapping stairs.
Shaun McDonald wrote: > I have used bicycle=yes where there is a guide rail to help people take > their bike up and over the steps/bridge. It's a matter of definition, I guess. My opinion is that the OSM vehicle class "bicycle" doesn't include pushed/carried bicycles, so it is not appropriate for steps with bicycle ramps. Otherwise, we'd need to tag a lot of pedestrian streets/areas where pushing bicycles is legal (while cycling is not) with bicycle=yes. Of course, this would be misleading. I prefer ramp:bicycle=yes. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Address interpolation
Brian Quinion wrote: >> Imo, yes, you should put all those details onto the objects that carry >> addr:housenumber (either nodes or building outlines). That's the method >> intended by the documentation and I don't see a good reason for not >> sticking to it in this case. > > inconsistent duplication. I'd accept inconsistent duplication as an argument against using addr:street at all and in favor of associatedStreet relations. I'd also accept it for addr:city vs. boundary polygons. But as an argument for moving address details to the interpolation ways? It's at most a factor 2 for duplications, that doesn't really change much. You will want some checks no matter whether it's 1 or 2 addr:street entries in a city. Considering that this question is not decisive for the amount of duplication, other aspects are more relevant here. Namely: - 1 way of doing it is better than 2 ways of doing it - usability (for example: use the same JOSM presets for housenumbers with and without interpolation way attached to them; no partial copy of attributes required when removing an interpolation way) > Discarding all data that doesn't perfectly conform to the > specification would remove quite a large percentage - this case alone > accounts for around 3% of the data. These percentages might decrease if people actually had an incentive to create data conforming to the specification (such as applications only accepting data that does). 3% doesn't sound that impressive, btw. Is that before or after performing interpolation? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] wiki: number of people watching a page
Gary68 wrote: > is there a function available now to find out how many users are > watching a certain page? I don't know a way to access that information right now. Maybe someone can adapt this Wikipedia tool http://toolserver.org/~mzmcbride/cgi-bin/watcher.py for the OSM wiki? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Changeset history - hide 'big' edits?
Martin Koppenhoefer wrote: >> Is it possible at least add "area (big)" in RSS feeds of changesets so it >> is filterable via external services (yahoo pipes)? > > do you know ito? It is a proprietary service but subscribing is free > and it offers this feature you are requesting (see all changes in a > certain area ... as long as they affect ways, rather than just nodes or relations. Also, there often with a delay of several days, and it doesn't show edit comments (as it apparently isn't changeset based). However, with the changeset history barely usable due to "big edit" spam it's probably the most useful provider of watchfeeds. Here's the link: http://www.itoworld.com/static/osmmapper Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Overlay showing wikipedia links
Pieren wrote:
> I never understood people who wants to have wikipedia urls in OSM
> data. It is not OSM role to point to wikipedia articles but wikipedia
> to point to OSM geodata. And this has to be done through lat/lon
> coordinates.
lat/lon coordinates aren't an ideal solution for this. Imagine some live
rendering (using JavaScript, Flash or whatever). The programmer wants to
add the following features:
- different color for buildings with Wikipedia article
- mouseover highlighting of buildings
- clicking on highlighted building opens Wikipedia article
Can the programmer do that with lat/lon? No. Because lat/lon doesn't
offer a connection between an article and a certain OSM primitive.
Similarly, in a map with icons for POIs, you will need to add additional
icons for Wikipedia links, so you will end up with two icons for the
same POI. And so on.
So what can we do to store that connection? We can
- link to a Wikipedia article from OSM
-> does work, but of course this causes a "notability" problem if links
to other sites are added, too
- link to an OSM id from Wikipedia
-> ids are probably too fragile
- invent some new way of adressing OSM objects;
for example: lat/lon + tag(s) that will be looked up in some region area
around the lat/lon ("The pub with name=Foo near that location")
-> could be a rather robust solution, but doesn't exist right now
Therefore, I can understand very well why people are adding wikipedia=*
tags. It might cause problems later, but the other solutions have
apparent flaws right now.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] address interpolation
Peter Körner wrote: >> But, when you see an interpolation "25 to 25c". How do you know that this >> means "25, 25a, 25b, 25c"? You again remove the number. That gives you the >> first entry. But what happens then? > You count to the end of this interpolation-way (there are 4 nodes in, 1 > is the start and 1 is the end, so 2 in between) and substract this > number (2) from the last char (c). What you have is a way with _two_ nodes: start and end node. The first node has an addr:housenumber=25 tag, the last node =25c. The last node could also be addr:housenumber=25f. The number of houses represented by an interpolation way doesn't have anything to do with the number of nodes in the way. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - Voting - boolean values
James Livingston wrote: >> http://wiki.openstreetmap.org/wiki/Proposed_features/boolean_values > > How precisely is that going to end the debate? > > a) Voting isn't the way to do this. It either needs consensus or a > dictator. It will probably demonstrate that there already *is* a consensus to use "yes" for this. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - incline up down
Tagging the general direction of a way as incline=up/down: http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down Vote-Start: 2009-10-03 Vote-End: 2009-10-17 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions
Valent Turkovic wrote: > I have used wiki for getting to know how to use turn restrictions, and > there the examples given on the page: > http://wiki.openstreetmap.org/wiki/Relation:restriction > type tag is not used. The type tag is listed in the tags section on that page. The examples were added later - http://wiki.openstreetmap.org/index.php?title=Relation%3Arestriction&diff=216338&oldid=216003 - and it's likely that the type tag was simply forgotten because the examples were primarily intended to demonstrate usage of no_* and only_* tags. > I added type=restriction to it now, but is is necessary or not? Should > the wiki be updated? Imo: Yes, it is necessary (other tools such as JOSM expect it, too), and the examples should be updated to reflect this. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] cloud made routing and turn restrictions
Igor Shubovych: > CloudMade definitely has some support for turn restrictions. > [...] > Unfortunately there are a lot of bugs there. CloudMade is going to fix it > during next couple of months. Is it a known bug that restrictions with restriction=only_* tag are apparently handled as if they were restriction=no_*? There recently was a German forum thread where someone encountered that problem (http://forum.openstreetmap.org/viewtopic.php?id=5022). One of the examples was this route http://maps.cloudmade.com/?lat=51.243972&lng=6.78645&zoom=18&directions=51.243609690021025,6.787233352661133,51.2442275913119,6.786621809005737&travel=car&styleId=1 that probably was influenced by this restriction relation: http://www.openstreetmap.org/browse/relation/183709 (There are some other links with examples in this thread, which are all related to only_*-restrictions.) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Instead of voting
Frederik Ramm:
> (5) Never ever invent a tag that you don't have a concrete use for.
"Never plan ahead, always wait until there are thousands of existing
tags that make creating a better solution harder"?
Recently, I encountered a crossing where there were both traffic lights
and an island for pedestrians. This could easily be expressed if whoever
invented the tag had done some thought experiment along the lines of
"but if there is a crossing that has BOTH traffic lights AND islands?
Seems like I shouldn't put these into the same tag!"
Of course, I simply invented something to express this, but it means
that there are two ways of expressing "there's a pedestrian island at
this crossing" - while not much of a problem, that certainly isn't
"nice" from a modelling point of view.
> We already have too many computer people who get carried away by thought
> experiements ("yes but if the spot where the road and railway intersect
> also happens to be a station and have a traffic light and a river
> flowing underneath, what are you going to do THEN").
Maybe we should use common sense to distinguish between plausible
possibilities and irrelevant hypothetical constructs?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Instead of voting
Generally, I like your idea - it's important that there is only one meaning per tag (that's why they should be documented), whereas synonymous tags are not a serious problem, so there is no reason to restrict mappers ability to use and define new tags. I therefore think it should be considered a valid way of establishing tags. Russ Nelson: > "As an alternative to voting, consider doing this instead." It should be clear that it's only an alternative to voting when introducing new tags. It doesn't offer a solution if there already are different ideas about what a certain tag means - we'd still need a way to handle those situations: voting, councils, dictators, whatever. > 5) If you disagree with the definition of the key or value, then > create a new key or value with a different name, This can potentially lead to some conflicts when the "good" names are already taken... Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Instead of voting
Russ Nelson: > Tobias Knerr writes: > > Frederik Ramm: > > > (5) Never ever invent a tag that you don't have a concrete use for. > > > > "Never plan ahead, always wait until there are thousands of existing > > tags that make creating a better solution harder"? > > I believe this to be a misconception. If there are five tags, all of > which have the same semantics, what harm is caused? There are minor disadvantages (additional effort for people creating rules, mappers can't decide as easily how they should tag something, ...) that aren't really serious problems, but aren't desirable either. If I can realistically expect a situation to exist and can take it into account without negatively affecting the usability of a tagging scheme, I will do so - even if there is no example for the situation in my area. > > Of course, I simply invented something to express this, > > And did you document it in the wiki? I'm going to do this soon. So far, I've made an attempt to discuss it on the wiki talk page for the feature (I could have used the tagging mailing list or some other place, doesn't really matter). After all, someone else might offer a better idea right away. I've noticed that your steps don't take communication into account at all. Generally, though, it's a good idea to discuss tagging bit. I can still ignore other people's opinions, but often I will like their ideas better than the one I originally had. A simple "has someone already tagged X?" also makes it less likely that people simply don't *find* an existing solution they would be perfectly happy with. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC -(man_made=mineshaft)
Dave F.: > Shaun McDonald wrote: >> If you just add a disused=yes, pretty much nothing that works with the >> OSM data will recognise that it is no longer a cafe. > Don't map for the renderer, router etc. etc. > > You should be writing a post asking why they don't recognise such a > widely used tag. Because tags like disused=yes conflict with a general principle in OSM: We don't have a fixed set of tags and mappers can invent and use their own tags, so it should be possible for software to ignore tags it doesn't know without causing problems. If I don't support distinguishing between different variants of amenity=parking, I just ignore parking=* tags entirely, and while the result is less useful, it's still correct. If I don't support disused features, I can just ignore disused=yes tags ... no wait, I can't. Of course, in order to make mapping convenient, it's sometimes necessary to break that concept (with access tags, for example), and probably we won't be able to get rid of disused/abandoned/construction/planned/proposed/etc anymore. Unfortunately, people didn't seem to like my status=disused/... proposal very much. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC -(man_made=mineshaft)
Dave F. wrote: > I can't work out if you're agreeing or disagreeing with me, but anyway... > > Are you suggesting there's no exception rule for renderers?: > Ignore all subsequent keys except for ones label disused or abandoned" I agree that a renderer should be able to deal with tags like disused=yes. I also agree that disused is widely used, so it cannot reasonably be ignored anymore, and replacing it with an alternative way of tagging probably is no longer an option. However, I believe that using a common key instead of disused/construction/abandoned/...=yes and distinguishing these using different *values* would have been the better alternative. Once applications would have learned about the key, they would have been able to handle new values immediately. I also recommend that, when tags are created in the future, they should be designed so that they can be ignored unless there are important reasons for breaking that rule. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC -(man_made=mineshaft)
Dave F.: >> However, I believe that using a common key instead of >> disused/construction/abandoned/...=yes and distinguishing these using >> different *values* would have been the better alternative. > Common Key? Can you give an example? > > If you mean status=disused, I'm not sure how that get around the problem > of ignoring all other keys. Yes, I mean status=*, and I'm aware that it doesn't avoid the problem - however, the problem would have to be solved only once for all possible status values. A check for status will filter out objects with e.g. status=planned, too, even if only construction, disused and abandoned were known when status was introduced. A check for c./d./a.=yes will not filter out planned=yes, thus increasing the required effort for monitoring tagging trends and adapting applications. Therefore, I'd consider a common key an improvement, but of course the problem of ignoring keys would still exist. The problem could only be avoided completely by using things like disused_KEY = VALUE or KEY = disused + disused = VALUE, but the widespread use of disused/...=yes seems to demonstrate that not all mappers like these. The idea was that maybe the common key approach could be some kind of compromise. As I said, though, I don't believe that an attempt to establish an alternative to disused=yes could be successful. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] alley - for tree-lined roads?
Liz wrote: > On Wed, 4 Nov 2009, Morten Kjeldgaard wrote: >>tree_lined=right >>tree_lined=left >>tree_lined=yes (meaning both left & right) I don't like it that much (don't like the cycleway:left/right tags either, though). I'd prefer an integration into a generally usable lane model with information about lane ordering. Then I could also map that road with tree lines *between* pavement and car lanes properly. I guess it's ok as a temporary solution ... > left and right compared to what?? > I'm going to go one way down the street and mark the trees on the left, and > you are going to go the other way down the street and mark the trees on the > right. As with all left/right tags (as well as forward/backward, up/down, oneway, incline, etc.), this would certainly refer on the way's direction in the OSM database. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] positioning of barrier = stile
David Groom writes: > My query relates to where a footway joins a road and there is a stile. > > say a- b is footway , and c - d is road > > Should the stile be placed at "b" > [...] > or should I put in a node "e" and tag that with barrier = stile: > [...] The additional node e is necessary. If there is a barrier on a node that is part of the c-d road, that barrier does block traffic on c-d. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] HELP: signing problem on wiki ( different user-name wiki <-> osm-server)
colliar wrote: > I have different user-names on osm-wiki and osm-server. (only capital as first > letter and not) > The link on my wiki-user-page works well. Only signing does not. It should be: > [User:username|Username]]. > In stead it turns out: > [[User:Username|[[User:username|Username You probably have written "[[User:username|Username]]" to the "Signature" option field in your wiki preferences, but haven't enabled the "Raw signatures" check box. Without the "Raw signatures" option, the "Signature" field will only modify the visible part of your signature, that is, the part after the "|". And it will convert all special characters, such as "[", "]" and "|". By the way: The wiki doesn't distinguish between the pagenames User:username and User:Username anyway, so I don't think you even need to modify the link target. I hope this helps you solve your problem. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping everything as areas
Jean-Marc Liotier wrote: > Ævar Arnfjörð Bjarmason's diary entry last week (http://j.mp/8ESP8o) > stired my interest. Using a few examples, he showed how mapping > everything as an area - or as a volume - makes ultimate sense. Should we > go for it now ? Imo, area mapping is too advanced for now. After all, - it's quite hard to get the data (several width measurements required) - there aren't many practical applications - you can't work around some editing problems with shared nodes anymore - we don't have software support for it As the next step for areas where most of the basics are done, I'd rather start lane mapping. It has some very attractive use cases (detailed routing instructions for cars, routing and maps for pedestrians/bicycles) and it's relatively easy to gather the data (you just look at the street, no tools required - not even a GPS). Actually, I don't believe most mappers will be able and willing to produce data that is more precise than what can represented with width tag + lane info any time soon. Of course, if you *want* to map areas in addition to linear road representations, just do it. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping everything as areas
Martin Koppenhoefer schrieb: > 2009/11/25 Tobias Knerr > >> Jean-Marc Liotier wrote: >>> Ævar Arnfjörð Bjarmason's diary entry last week (http://j.mp/8ESP8o) >>> stired my interest. Using a few examples, he showed how mapping >>> everything as an area - or as a volume - makes ultimate sense. Should we >>> go for it now ? >> Imo, area mapping is too advanced for now. After all, >> - it's quite hard to get the data (several width measurements required) >> > well depends on the quality you want to achieve (can do it with aerial > images just now) [...] That's an additional requirement, though, so it's not possible everywhere. >> - there aren't many practical applications > there is one key application: rendering For most maps (or most zoom levels of most maps), it's not that useful to use real outlines for ways. A linear abstraction with exaggerated (and possibly importance-dependent) widths is common and usually more practical. >> - you can't work around some editing problems with shared nodes anymore >> > don't understand what you intend There have been several discussions whether area borders - such as landuse areas - should use the same nodes as streets they are adjacent to. Iirc, some participants complained that sharing nodes causes editing problems - making it hard to select individual ways, requiring the relatively unknown unglue operations when editing the ways etc. With streets represented as areas, the "way=middle-of-the-road" argument wouldn't apply, so we probably would have to start dealing with overlapping ways and/or shared nodes. (I'm not necessarily saying this is a valid concern, I just remember it being raised. I assumed that "shared nodes" would remind everyone of those recurring discussions - apparently, that wasn't correct.) >> - we don't have software support for it >> > you simply add area=yes to your closed way. Which won't be supported properly by renderers (for many highway types - and not at all for directional features like steps or oneways) or routing applications (it might use the outline of the area, which is equivalent to ignoring the area=yes). A simple area=yes could even be considered wrong. I'd interpret a highway=* area with area=yes is an area where there's no regulated direction of traffic. There should be an easy way to identify areas which are outlines of ways so you can decide not to draw these. After all, abstracting roads to lines with uniform, non-realistic width can be a sensible design decision. (See above.) Even if you believe it would be correct, there would still be problems with directional features, left/right/forward/backward tags etc. Therefore, I think this statement is very important: > The only thing: don't delete the > current centre-ways. Maybe it would be best to tag the road-areas as > landuse=road instead of highway=something to avoid conflicts. >> As the next step for areas where most of the basics are done, I'd rather >> start lane mapping. It has some very attractive use cases (detailed >> routing instructions for cars, routing and maps for >> pedestrians/bicycles) and it's relatively easy to gather the data (you >> just look at the street, no tools required - not even a GPS). >> > yes sure, but A doesn't exclude B. Not at all. I'm just stating my personal preferences. Of course, the perfect solution is to map everything. >> Actually, I don't believe most mappers will be able and willing to >> produce data that is more precise than what can represented with width >> tag + lane info any time soon. > > no problem, who wants to do it, can do it. Look here: > http://www.openstreetmap.org/?lat=51.300723&lon=11.427789&zoom=18&layers=B000FTF That's interesting! Luckily, a single example doesn't prove my "most mappers" statement wrong yet. ;) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bridge on Hiking Trails
Dave F. wrote: > I didn't think the layer=1 was necessary when there's only one bridge - > it defaults to display above other objects. This assumption isn't defined anywhere (afaik). Therefore, it relies on arbitrary and undocumented implementation details of specific renderers, which should be avoided. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Roy Wallace wrote: > >> Routing software that is aware of the local laws of each country seems >> obvious. > > Um...what??? That will not write itself. Do you expect us to > successfully digitize and maintain a database of all laws of all > countries? In a wiki, even? That's ambitious! I'd prefer to stick to > mapping what's on the ground. If we map what's on the ground, then we create a map database containing "here is an oneway sign, over there is a cycleway sign". That's nice, but if I want to do routing with this, I need information such as "can I use way w in direction d with vehicle v?" - and in order to know this, I need another database that tells me what a sign means in that part of the world (for example: are pedestrians allowed to walk on ways with a cycleway sign?). If we don't want a traffic law database, then we need to tag the required information directly. But then mappers don't just map physical reality. They interpret the signs (and other information) using their - hopefully correct - knowledge of the laws. Both can work, but /someone/ has to do the transfer from reality to road network attributes - either software (using a traffic laws DB) or humans (mapping more than just what's on the ground). Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path vs footway vs cycleway vs...
Roy Wallace wrote: > The point I was making was that it should *not* be necessary to > *require* "a database of all laws of all countries" to know what > highway=cycleway means. There should be one definition that is > consistent for the whole world. For example, "this path is marked with > a sign with a bicycle symbol on it". If people also want to put in > exhaustive information inferred from a law book, I'd prefer they go > ahead and use "foot=no + source:foot=lawbook". If people prefer to > leave out the inferred information, and instead write routers with > country-specific defaults, that's cool, too. > > But highway=cycleway tags in the OSM database should all mean the same thing. Do you only suggest that there should be exactly one meaning per tag, or would you also want the same tags to be used all over the world? It makes a difference for possible approaches like using highway=Fahrradweg (or DE:cycleway or any other value that isn't exactly "cycleway") for German cycleways, as that would still be "one meaning per tag". Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] opencyclemap and car directions
Ben Laenen wrote: > Richard Mann wrote: >> If there's no >> lane marked (eg the zillions of oneway exceptions in Belgium that have >> appeared in the last few years) then it probably needs to be tagged >> oneway:bicycle=no, but that won't show up either (AFAIK). > > bicycle:oneway=no is used much more in Belgium (and the whole planet) -- > about > ten times more often. Imo, this shouldn't be considered in isolation. There's a whole lot of situations where the value for a key, such as oneway, maxspeed, maxweight, access, is different depending on vehicle or other conditions - a common example is maxspeed:hgv (note that nobody is using hgv:maxspeed). And it's a bad idea to create a different solution for each of these. There is a concept that covers all of these and uses oneway:bicycle: http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags The bicycle:oneway variant, to my knowledge, hasn't been part of a solution that can be used to express all of these cases yet and is mostly just there as a solution for this single situation (opposite traffic on oneway ways). Imo, that's a too limited perspective. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] access tagging concepts (was: Re: opencyclemap and car directions)
Ben Laenen wrote: > Tobias Knerr wrote: >> There is a concept that covers all of these and uses oneway:bicycle: >> http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_fo >> r_access_tags >> >> The bicycle:oneway structure, to my knowledge, hasn't been part of a >> solution that can be used to express all of these cases yet and is >> mostly just there as a solution for this single situation (opposite >> traffic on oneway ways). Imo, that's a too limited perspective. > > So that's completely incorrect, bicycle:oneway=no already appeared on > http://wiki.openstreetmap.org/index.php/Proposed_features/Access_restrictions > a long time before the extended conditions for access tags proposal was > created (although, indeed, not a definite proposal for such a syntax -- it > still could all change -- but in the mean time it was seeing some usage while > testing it out). But that's far from an "isolated situation for oneway only". Nevertheless, it "hasn't been part of a solution that can be used to express all of these cases yet". It has been part of a brainstorming process - but that's not a solution. Maybe it can lead to a solution. > Yeah, so that proposal of mine hasn't seen much change recently. Basically > because I have the impression almost no-one else but me seems interested in > creating formal definitions of access tags, and because proposals like yours > would come up without really looking at what was written on that page. I'm not sure what exactly you would consider a formal definition. Description of the structure using some kind of grammar? Evaluation rules? Something I didn't even think of? Certainly, all of these would be entirely possible for "Extended conditions" tags and their evaluation, though. > But now with your syntax which is advocated as good > syntax to use and superseding other possibilities just because it is a > proposal, it makes life harder to create the formal framework because we now > have a whole new set of tags that have to be taken into account, and would > rule out a lot of possibilities of perhaps a better syntax. I'm always open for better solutions. I also believe that a syntax being used isn't an argument for not replacing it if something better comes along. I wouldn't expect you to necessarily take "Extended condition" syntax into account when creating your own concepts, and I don't think it's a practical necessity, either, as none of these cases is very widespread yet. Also, what would you have expected me to do in that situation back then? Yes, there was this page that hadn't been very active even then and didn't offer much except some "brainstorming". Yes, maybe someone would come up with a solution based on it, but there was no indication that it would develop into anything. So I what I did was this: I spent hours thinking about other solutions, discussing syntax, writing software prototypes for different syntax variants and so on. No, I'm not convinced that my proposal is the ideal solution. I'm now convinced that it is a *working* solution, though, which integrates most of the existing tags and allows them to be defined consistently. Still, if you can come up with something better, please do. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Create two new categories for lawyers, architects, plumbers, etc
Pieren wrote: >> We've long since passed the point where "amenity" is an accurate >> description for the value that comes after it. In the OpenStreetMap >> database "amenity" is best pronounced as "a thingy" :) > > Is that a reason to not improve things (or try to )? Is introducing somewhat arbitrary categories really an improvement? It's just another thing I need to memorize. What I want to enter is actually "lawyer" "museum" "brothel" and so on. These aren't two "atoms" of data, just one. Unfortunately, there is the technical requirement to provide two strings - key and value. A "thingy" key (could be "type" or "poi" or whatever just as well as "amenity") is a method to work around this. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Announce] OSMF license change vote has started
Steve, SteveC wrote: >> How is insulting people going to help things? > > By letting them know FUD and BS will be shot down. I understand that most statements you are responding to seem stupid, unnecessary or inappropriate to you. You might even think that those who posted them should really know better. But please take into account that many people reading this know much less than you do about the license change. Also, most people here don't know you, either. Your mails to OSM-talk might be their first impression of you. They also might be their first impression of the Foundation and the ODbL switch. You can't expect them to invest a lot of time to understand international copyright and database law. For them, it's all about trust - do they trust the calmly worded concerns (that sound perfectly valid to them, even if they in fact are BS - which isn't true for all of them, either, many are legitimate) or that angry guy who keeps telling them it's all nonsense? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Opinion poll about the new licence Odbl 1.0
Pieren wrote: > Could someone deliver a script that could make this automatically for > me :"take all elements where I am the last contributor but not the > only one then delete and recreate them identically under my user > account then all my efforts are saved at the licence transition" ? In my opinion, whether your data is derived from other data isn't determined by having the same object ID. If I completely remove all tags from a node, move it somewhere else and add new tags, then it's most likely not derived from the previous work. If I add a tag to a road, then it is derived from previous work, and this doesn't change at all if I choose to copy the road and delete the original. Using the object history is just an approximation based on the assumption that mappers will usually keep an object if they are improving existing data, and create new objects if they add completely new information. It's not really possible for an automated process to do anything else. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] OBbL and forks
Grant Slater wrote: >> A quick question for the legal people: does ODbL allow the project to >> be forked? > > Yes it does. The LWG sought specific legal advise on this. We wouldn't > be an open project if this was not allowed. That fork would have less options than OSMF has, though. Most importantly, it could only use the published ODbL data. It wouldn't have the rights granted by the Contributor Terms, namely publishing data as CC-by-sa or (with contributor support) any other open license. Considering that the LWG seems to consider these options strategically important, the fork would be at a disadvantage. I'm not sure about attribution, either. Wouldn't the fork have to attribute OSM as well, making attribution significantly less convenient? Tobias Knerr ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Opinion poll about the new licence Odbl 1.0
Brendan Morley wrote: > All for addressing, as far as I can tell, a theoretical problem, with no > real-world "exploits". I understand that actual exploits would make the problem more obvious, but I find the underlying logic questionable nevertheless. No one has broken into my house for 5 years now. Does this mean my door locks are secure? No, it might easily just mean that * most people are honest enough not break into my house * the stuff I have in here is not valuable enough * I was simply lucky Of course, it doesn't necessarily mean that the locks are insecure either, it's just that you need experts checking the locks to decide this. Similarly, that no one (we know of) has abused weaknesses in CC-by-SA so far could be because * most users of OSM like the project anyway, so they voluntarily comply * OSM is still inferior to other data sources in most places, so we aren't an attractive target; especially as we could cut off update by switching licenses (I'd expect clear support for that after an exploit) * we were simply lucky Again, just from looking at this, CC-by-SA might or might not work. It takes legal experts who check at the license to decide this. If the license has problems (and there are legal arguments indicating that they exist), just waiting until an exploit occurs is detrimental. After all, if we try to relicense in a few years, we will lose much more data (more contributors will have left/died/changed their e-mail address until then, each object will have been touched by a larger number of contributors, and of course there will be a larger amount of data in the database overall). So unfortunately, we need to decide soon - and in absence of reliable empirical data available, only theory is available. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dual/Multiple licencing
Brendan Morley wrote: > Why must there be migration to the new licence? Why can't we run both > indefinitely? A major reason for introducing ODbL is that many believe CC-by-SA to only inadequately protect our data (so that it might be possible in some jurisdictions to use our data without respecting attribution and share-alike requirements). If we dual-license, someone with the intention to take our data can simply pick the "weaker" license, so this wouldn't help at all. Adopting a dual-licensing scheme would also require us to remove data added by contributors who don't agree to this change, just like switching to ODbL (unless we want to create two different sets of data and essentially fork the project, which imo is the least attractive option of all). And finally, it would become impossible to re-import modified information from uncooperative users. In order to do this, we'd need permission to distribute it under both licenses, but a user can of course decide to only publish modifications under one of the two licenses. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Suggestion: fallback tag
Steve Bennett wrote: > Solution: tag it like this: > landuse=reserve > fallback:leisure=park Lets assume that your fallback tag isn't just a less specific type of object than the real tag (in that case, a tag hierarchy - as it is used with amenity=parking + parking=*, for example - would solve the problem). In this situation, a fallback is based on certain assumptions how renderers display a tag. It only works in your example because you make the assumption that parks are rendered as a green area or something like that, and that would be appropriate for reserves, too. But some other renderer might write "park" all over the area or do something else that makes the rendering completely inappropriate for the feature. What if I use "beach" as the fallback for my golf bunkers and get ice cone and beach ball icons, rather than the yellow area I had expected? Another problem with your approach is that it only works in renderers designed with the intention to display /everything/. I'd expect good rendering styles to be limited to a selected subset of the available information. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM rewriting history : France is now part of Germany !
John Smith wrote: > Cartography is an art form, and you will never be able to do this sort > of thing perfectly by extrapolation from the boundary. Unless you are working with one specific rendering style on a known zoom level and with fixed font size, you won't be able to perfectly do this by manually positioning a label, either. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not-properly-Open-but-called-Open
Dair Grant wrote: > showcasing useful and innovative things that have been done with > OSM data is more important than trying to split ourselves into "open" (terms > and conditions will apply) and not. If it is there to show what can be done with OSM data, it does a very poor job. The only thing it shows is an inferior Google Map clone: pre-rendered tiles that cannot even be configured or modified in any meaningful way. It doesn't help to demonstrate the the advantages of having access to raw map *data* at all. In order to truly show what's possible, we would need to completely redesign that front page into a "featured products" catalogue that could list routing applications, Garmin converters, OSM clocks, renderers, paper maps and so on. This would, of course, include "closed" applications. As it is, that page doesn't really serve the purpose of presenting OSM products. Instead, it presents OSM data *itself* - with features such as changeset list, data layer, XML export, etc.. And for that purpose, we don't need "closed" rendering styles. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not-properly-Open-but-called-Open
Dave F. wrote > Tobias Knerr wrote: >> In order to truly show what's possible, we would need to completely >> redesign that front page into a "featured products" catalogue [...] > It doesn't have to be completely redesigned, just a link saying: > > "And here's some other great ways in which OSM can be used..." > > http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services I'd prefer a somewhat nicer presentation than a raw table (and a more selective approach, the full list can always be accessible using a "more ..." link or something like that), but the wiki page would be a good first step. IIRC there already were some suggestions and designs a few months ago, either on this list or talk-de, but I'm currently unable to find them. > Excuse my ignorance - OSM Clock? http://www.opengeodata.org/2009/11/25/openstreetmap-clocks/ Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New "Highways" view in OSM Inspector
Dave F. wrote: >> Long ways are a potential problem if you have long segments with no nodes in >> it. One problem is when you draw a small part of the map that has a line >> going >> through it but no nodes in it (because they are all outside), the line might >> not show because the software doesn't recognize this. You can run into this >> when >> using Osmarender for instance. > I don't really like saying this, but isn't this a "don't map for the > renderer" case? "Mapping for the renderer" is a problem when you incorrectly represent reality in order to produce a certain rendering. When there are different representations (such as long segments and short segments) that represent reality equally well, choosing the one that is easier for applications isn't a problem at all, but rather a good idea. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] node vs. area for amenities in wiki templates
Map Features as well as the info boxes on the individual pages list many "building" amenities (cafe, cinema...) and other usually area-like amenities (grave_yard) as node features, while others (brothel, crematorium...) allow for node or area representation. In some cases, areas are listed as possible on the individual pages, but not on Map Features. The situation is similar for shop (apparently, shop=shoes can be an area, but shop=hardware can't), man_made etc. In mapping practice, however, I see those features used on nodes and areas, no matter what's in the wiki. Does everyone agree that these are simply documentation errors and should be corrected? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] RFC - Scope for access tags
http://wiki.openstreetmap.org/wiki/Proposed_features/Scope_for_access_tags Intention: solve some tagging problems related to restrictions (restrictions on wet roads, restrictions only for some vehicle types, direction-dependent restrictions). Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Abandon voting (was Wiki: chriscf vandalism)
Jonathan Bennett schrieb: > A good system for reaching consensus is based on discussion, not mere > voting. I agree. However, our system _is_ mostly based on discussion. The propsal + RFC process serves this very purpose: Present ideas, discuss them and improve them based on discussion. The "vote" isn't really a vote, because it doesn't decide anything. No one is forced to use an "approved" feature when mapping or writing software, no one is prevented from using a "rejected" feature. So I don't think we need to abandon "voting". Probably we should just relabel that to "poll" or something and make clear that it isn't binding in any way. It's merely a quick indicator whether consensus has been reached and a way of getting some more discussion started. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - "Voting" - Scope for access tags
I'd like to find out whether people agree with conditional access information as described in my proposal, so I started "voting": http://wiki.openstreetmap.org/wiki/Proposed_features/Scope_for_access_tags The proposal suggests using tags like maxspeed:wet=80 or maxspeed:hgv=100 to state that a maxspeed is valid only on wet roads (example 1) or only for hgv traffic. Please add your opinion to the poll and discuss related ideas as well as problems with the concept on the talk page. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] License plan
Gustav Foseid wrote: >> This could potentially alienate anyone who wonders why they are doing >> surveying for free so that cartographers can sell all-rights-reserved >> map images based on their data. > > It could, potentially, even if I agree with Richard. I think it is important > to explain why this change is to the better in the majority of the cases. > [...] > With the ODbL, the image of the map does not have to be free, but the data > have to be shared. This means that the design elements are proprietary, but > the data are easily available. I agree. However, judging from some feedback on the German forums (where I have explained exactly this situation), it seems that some users are not going to accept the possibility of creating produced works under non-free licenses, pointing out that the added value might not even be because of a change to the data, but the (unpublished) tools creating the images, thus nothing of use would be contributed back to the "free world" with ODbL. I don't think explaining that data is more useful for us than images will help (I've already tried that), because that won't stop them from demanding both. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] License plan
Simon Ward wrote: > I have had to explain to free software advocates before (I am one) that > OpenStreetMap is about free geodata, not necessarily free software. The problem is that while the distinction between software and geodata has been around from the start, the one involving images is to be introduced only now. Imagine this in the software example: If we had been requiring that all software using OSM data had to be GPL until now and decided to drop this requirement, telling people that they simply misunderstood the project's goals and that it never was about free software -- I'd imagine that there would be some mappers who firmly opposed that move. > It turns out that much of > the software for OpenStreetMap is free software. Which isn't surprising because few people outside the OSM and free software/content communities are using OSM-based software so far. This doesn't make it reasonably attractive for authors of proprietary software. I expect that to change once we are competitive in terms of data quality and coverage. Same for not-so-free produced works. >> I don't think explaining that data is more useful for us than images >> will help (I've already tried that), because that won't stop them from >> demanding both. > > Similarly, we can put enough free images out there for them to be useful > to all, and make the non‐free ones hardly worth the pixels/vectors. Well, this doesn't really help to explain why we should allow those non-free ones to be created in the first place. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] License plan
Frederik Ramm wrote: > I have never mapped anything thinking > "hey, maybe someone else is going to make a nice map from this that I > can then use". Not one single time. I don't know if that makes me an > exception. Most people I talked to were enthusiastic about the data > being collected, and were talking about cool things *they* could do with > the data, but I might be moving in the wrong circles ;-) My (completely unscientific) observation is that liberal opinions about licensing (esp. PD-advocacy) are more common with people who actually write software / make map styles / do other "advanced" things with OSM data. Support for liberal licensing also appears to be more prevalent on the mailing lists than anywhere else in the project. One possible explanation might be that these "liberals" have experienced the problems of incompatible licenses etc. themselves. However, I'm starting to think that there's something else: If people are able to create cool OSM stuff themselves, they care most about licensing not getting in their way. Mappers who don't have the technical or artistic skills or simply the time to do so will still want cool stuff to be done with OSM. Of course, they have to rely on others creating it, and, more importantly, others allowing them to use it under attractive conditions. A license that guarantees the last part might seem rather appealing for many of them. Just a side note because I found this aspect of the statement especially interesting. Most probably overly generalizing, misleading and/or simply wrong. ;-) Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Extended conditions for access tags
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags This proposal is an add-on to my "conditions for access tags" proposal. It extends the "access conditions" approach to multiple conditions and documents some additional conditions. Most improvements suggested during the original proposal's RFC and poll processes have made it into the extension. With this way of tagging, we'd probably be able to represent almost all maxspeed and access restrictions. See the proposal page for examples. Comments welcome! Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikipedia definition in tag page template
Sam Vekemans schrieb: > Why is it that all of the templates for the detail box on the right > have "Google definition" and a link to a search for that tag on google > search? I'd even ask: Why do we have such a link at all? What matters is how a term is defined in OSM context, not how it is defined by Google, Wiktionary or whoever. If "highway" in OSM is a collective key for everything from footway to motorway, *that's* the relevant information, not the "A highway is a main road intended for travel by the public between important destinations, such as cities and towns" that you get from Google. Therefore instead of cluttering the box with even more links (that are placed excessively prominently above far more interesting information) to probably contradicting definitions, we should simply eliminate the definition links from these boxes. If the OSM meaning is indeed based on some external definition of the term, then exactly that definition should be linked in the descriptive text. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] turn restriction relations: via
I've been implementing turn restriction support for some (still unpublished) software recently -- and, of course, have also added every restriction I could find to OSM. While the concept of "restriction" relations generally works well, there is one thing in particular I'm not really happy with: the effort that is required to handle via members. Can/should I assume * that there will always be exactly one finite sequence per restriction that includes all via members? * that via ways will be split to connect with each other and with from/to only at start/end nodes (this is recommended for from/to, but not mentioned anywhere for via ways)? * that a relation using via nodes will always contain all nodes as via nodes one would travel along * that a restriction will include either via ways or via nodes, but not both? Making these assumptions wouldn't prevent the description of any real-life-situation. It would, however, make evaluating restrictions (as well as understanding the effects of a restriction as a mapper) more easy. I also wondered whether it is really necessary to allow both (multiple) nodes and ways as via members, as each possibility alone can perfectly handle all situations and there is no significant difference in mapping effort either. So why don't we restrict the via role to ways (except maybe for the popular single-via-node case)? Tobias Knerr PS: I'm perfectly aware that there is no authoritative documentation, that I can implement and map whatever I want etc. I'm just interested in other people's opinions. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
