Re: [OSM-talk] Path rendering in the cycleway
Christoph Eckert wrote: > I agree some additional code needs to be written to support multiple tagging > schemes. But IMO it's not an issue (except of conceptual or language issues > of the consumer). A shop=bakery in Great Britain surely will differ from a > shop=boulangerie in France. But I could surely display them both on a map > with the same icon. That is a case of "1 thing having 2 different names". That's an annoyance, but a simple find and replace can 'solve' it. However "2 different things having the 1 name" *is* a problem that can not be easily solved. Rory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Tue, Sep 2, 2008 at 7:24 PM, Gervase Markham <[EMAIL PROTECTED]> wrote: > Erik Johansson wrote: >> Sprinkle your data with note="bla bla" tags so it's possible to see >> what the meaning was. > > So your solution is to have a database which is human-understandable > (with a lot of reading and effort) but not computer-understandable? > > That seems to break rather a large number of usage scenarios for OSM data... I was unclear, I referred to describing my tag data with note="" tags, not way data. Actually that is the solution of Openstreetmap, imperfect data. If the small contributors document why and how they tag something, you will at least be able to use their data for further mapping even though it's ambiguous to a computer. Small time contributors might be driven by how software use the data, though. So that give you the structured data you want. Less creativity though. Have a nice Autum /Erik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, > why fix it later, that creates extra work? and what do you mean > 'fixed'? i thought having them mapped with one of 3 different tagging > schemes was a good thing? I agree with Dave's responses so won't repeat them. Just a few extra points: > no-one's forcing anybody. lots of people use map_features for a > reason. they clearly don't want to spend time coming up with new tags, > cos it's boring and tedious - they want to map, cos it's fun and > interesting and involves being outside. There's nothing against documenting what tags are in use. I'm all for doing that, and if I find a tag in use that's not on Map Features, ord used differently than described in Map Features, I will add it there or make the change. I just reject any normative component - tags are on Map Features because they're used, not tags may be used because they're on Map Features. > if people wanted to come up > with new (duplicate) tags, they would be. thankfully, there are very > few duplicate tags As Dave has said, it really is a matter of your level of abstraction. I agree with you that having two different tags for absolutely the same thing is perhaps unnecessary. But if someone, after having this pointed out to him, would prefer to continue using "his" tag - that's fine, maybe he has a reason; maybe is an expert in the subject matter and knows that the existing tag is misleading or imprecise. He must be allowed to use whathe thinks is right without people requesting him to justify his actions. But most things are not exactly the same, just 95% the same. You say: > i would > put a note, and get one of two responses: "this isn't a duplicate, > it's similar, but different enough" (e.g. cemetery vs. graveyard), I think my main point is just that the decision whether something is duplicate or "different enough" should always remain with the mapper. >> make 49% of them unhappy and/or unwilling to map the item in question. > > hold on, what do you mean unhappy? says who? 49% might well be the > worst case, but what's the actual case? it could be 10%. or 0.1% As you say, people map because they like doing it. Some like to be told what to do, others' enthusiasm is ruined if someone says to them that they should (for example) use "highway=traffic_signals, crossing=traffic_signals, bicycle=no, segregated=no, crossing_ref=pelican" instead of "crossing=pelican". (By the way: I have removed the notion that crossing=pelican was "deprecated" from they Key:crossing page - OpenStreetMap does not have a body that has the power to say a tag was "deprecated". I thought we had this discussion before?) If someone has mapped 500 crossings with crossing=pelican because he finds this sensible and along comes someone to tell him his tag usage was "deprecated" because 10 others who, taken together, have mapped perhaps 50 crossings think so - what do you think, will this person really continue to work with the same enthusiasm? In OpenStreetMap, we do not normally sacrifice individuals for the sake of some greater good - at least not if it is easily avoidable. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Erik Johansson wrote: > Sprinkle your data with note="bla bla" tags so it's possible to see > what the meaning was. So your solution is to have a database which is human-understandable (with a lot of reading and effort) but not computer-understandable? That seems to break rather a large number of usage scenarios for OSM data... Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Christoph Eckert wrote: > What I was meaning was the other way around: IMO there's nothing wrong with > having more than one tagging scheme for one and the same thing. If there was > highway=footway, highway=foot_way and highway=way.foot in the database, > what's the (really huge) disadvantage? The disadvantage here is in renderer complexity, and keeping up with all the rules. But my point is that if you don't have an authoritative central list of what tags to use, you get problems of _both_ kinds. The kind you list may be easier to fix, but the kind I listed is not. > I agree some additional code needs to be written to support multiple tagging > schemes. Have you seen the examples in this thread? Extra tags seem to increase complexity quite quickly. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Tue, Sep 2, 2008 at 1:56 PM, Robin Paulson <[EMAIL PROTECTED]> wrote: > 2008/9/1 Frederik Ramm <[EMAIL PROTECTED]>: >> ... which can be fixed at a later time, if desired. Trying to create rules > > why fix it later, that creates extra work? and what do you mean > 'fixed'? i thought having them mapped with one of 3 different tagging > schemes was a good thing? that's the "if desired" part. > >> upfront runs a high risk of being impractical. And frankly, if our mappers' > > in what sense is it impractical? please be more specific Because the chance that you know what the issues are likely to be are going to be smaller. Once people have tried and tested a few different methods and got them all ironed out and sorted the schemes tend to be a lot more practical to deal with, mostly because they already have been. > >> creativity leads to two or three different ways of tagging the same thing >> (but at least it gets mapped well), what's the big deal? The alternative is > > by definition (well, mine anyway), 'mapping well' and 'two or three > different ways of tagging' are not congruent, so to blithely say the > two can happen together, without explaining how, is missing a rather > large and important point. and how many different ways exactly? two or > three sounds vague. what happens when someone wants to use the data to > do something useful? if there are two or three (or four, or five, or > six) ways of modelling the same thing, at what point do they stop > looking up data structures, to find out how to extract data on, say > rivers, because someone's been 'creative' and made up a new way of > tagging something? Certainly an interesting question. And not one you can ignore with osm in the current state either. There are already two ways of doing many things in the current map features list. Not least because the world out there is complicated and most of the time when using the data I'm happy to simplify it. There are several different ways to say some land is covered by trees: landuse=forest or natural=wood. They might mean different things, but if I'm looking for trees then I need to account for both. The same goes for most "duplicates"... mostly they're not really duplicates at all, they just appear to be at some level of abstraction. Mostly people are addressing a perceived flaw in another scheme, and this is why people become unhappy when they are told they're doin it wrong. Unfortunately people interpret things differently so figuring out when a duplicate really is a duplicate is Hard, as is knowing when telling someone that "no, we do it like this" isn't actually valid. > >> trying to force them to agree on one way of doing it, which (worst case) can > > no-one's forcing anybody. lots of people use map_features for a > reason. they clearly don't want to spend time coming up with new tags, > cos it's boring and tedious - they want to map, cos it's fun and > interesting and involves being outside. if people wanted to come up > with new (duplicate) tags, they would be. thankfully, there are very > few duplicate tags > > i used to spend a lot of time on the wiki, working on tag proposals. > occasionally, i would spot what i thought was a duplicate tag. i would > put a note, and get one of two responses: "this isn't a duplicate, > it's similar, but different enough" (e.g. cemetery vs. graveyard), or > "thanks, i hadn't realised that, i'll remove it" never once did anyone > say "i'll carry on thanks, i'm being creative and want to develop a > new way of tagging this" > >> make 49% of them unhappy and/or unwilling to map the item in question. > > hold on, what do you mean unhappy? says who? 49% might well be the > worst case, but what's the actual case? it could be 10%. or 0.1% Actually I suspect given current voting trends, the worst case could well be closer to 99.999% unhappy :-P And more realistically I suspect it varies wildly depending on the tag concerned, with a significant "don't care" section. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
2008/9/1 Frederik Ramm <[EMAIL PROTECTED]>: > ... which can be fixed at a later time, if desired. Trying to create rules why fix it later, that creates extra work? and what do you mean 'fixed'? i thought having them mapped with one of 3 different tagging schemes was a good thing? > upfront runs a high risk of being impractical. And frankly, if our mappers' in what sense is it impractical? please be more specific > creativity leads to two or three different ways of tagging the same thing > (but at least it gets mapped well), what's the big deal? The alternative is by definition (well, mine anyway), 'mapping well' and 'two or three different ways of tagging' are not congruent, so to blithely say the two can happen together, without explaining how, is missing a rather large and important point. and how many different ways exactly? two or three sounds vague. what happens when someone wants to use the data to do something useful? if there are two or three (or four, or five, or six) ways of modelling the same thing, at what point do they stop looking up data structures, to find out how to extract data on, say rivers, because someone's been 'creative' and made up a new way of tagging something? > trying to force them to agree on one way of doing it, which (worst case) can no-one's forcing anybody. lots of people use map_features for a reason. they clearly don't want to spend time coming up with new tags, cos it's boring and tedious - they want to map, cos it's fun and interesting and involves being outside. if people wanted to come up with new (duplicate) tags, they would be. thankfully, there are very few duplicate tags i used to spend a lot of time on the wiki, working on tag proposals. occasionally, i would spot what i thought was a duplicate tag. i would put a note, and get one of two responses: "this isn't a duplicate, it's similar, but different enough" (e.g. cemetery vs. graveyard), or "thanks, i hadn't realised that, i'll remove it" never once did anyone say "i'll carry on thanks, i'm being creative and want to develop a new way of tagging this" > make 49% of them unhappy and/or unwilling to map the item in question. hold on, what do you mean unhappy? says who? 49% might well be the worst case, but what's the actual case? it could be 10%. or 0.1% have you been reading max weber? this sounds a lot like a weberian critique of rationalisation, which is a bit extreme > If I can get 100 people to map something by allowing three different ways of > doing it, then this is much better than getting only 51 people mapping it > the "one true way". to suggest one is diametrically opposed to the other is pure guesswork. how did you arrive at these figures? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Tue, Sep 2, 2008 at 12:34 AM, Andy Robinson (blackadder-lists) > Frederik Ramm wrote: >>If I can get 100 people to map something by allowing three different >>ways of doing it, then this is much better than getting only 51 people >>mapping it the "one true way". > > here here This is such a bad mantra. Of those 100 people, 99 of them will be gone in a year, and we will not know what they meant. Though it is better have 100 people attempting to describe what they are tagging, than a desktop dictator deciding the direction of data denomination. Sprinkle your data with note="bla bla" tags so it's possible to see what the meaning was. -- /Erik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Frederik Ramm wrote: >Sent: 01 September 2008 9:27 AM >To: robin paulson >Cc: talk@openstreetmap.org >Subject: Re: [OSM-talk] Path rendering in the cycleway > >Hi, > >robin paulson wrote: >>> I think we shouldn't vote on tags at all. Instead, we should monitor >what gets >>> used most by the mappers (see Tagwatch and the tool announced by >>> Schuyler Erle). >> >> one of the problems with this, is that it's highly likely two mappers >> will develop two contrasting, but both valid methods of mapping the same >> object, and use them liberally. then some other mappers will follow one >> way, and some other mappers will follow the other way. then we have a >> jumbled data model. > >... which can be fixed at a later time, if desired. Trying to create >rules upfront runs a high risk of being impractical. And frankly, if our >mappers' creativity leads to two or three different ways of tagging the >same thing (but at least it gets mapped well), what's the big deal? The >alternative is trying to force them to agree on one way of doing it, >which (worst case) can make 49% of them unhappy and/or unwilling to map >the item in question. > >If I can get 100 people to map something by allowing three different >ways of doing it, then this is much better than getting only 51 people >mapping it the "one true way". > here here Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, > OK, so several thousand people are using amenity=foo. Are they all using > it for the same thing? How can you tell? true. There's landuse=farm on the Map Features page. Some used it for farm land, some for farm yards (thus farmyard had been introduced, which only solves half of the issue BTW). It similar to people using highway=footway for both paved and designated footways and just paths in the woods or the mountains. What I was meaning was the other way around: IMO there's nothing wrong with having more than one tagging scheme for one and the same thing. If there was highway=footway, highway=foot_way and highway=way.foot in the database, what's the (really huge) disadvantage? [...] > And the lives of the renderer authors are made miserable if there are > four different ways to tag the same feature, all of which are used in > different areas of the map. I agree some additional code needs to be written to support multiple tagging schemes. But IMO it's not an issue (except of conceptual or language issues of the consumer). A shop=bakery in Great Britain surely will differ from a shop=boulangerie in France. But I could surely display them both on a map with the same icon. Cheers, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Frederik Ramm wrote: > which can be fixed at a later time, if desired. How? Say 100 different mappers are using a particular tag - 50 one way, 50 another way. How do you fix this "at a later time" without going back to the places on the map and working out which of the two possible situations is the one tagged, or asking all 100 mappers what they were doing? This is the point. Tags have insufficient semantic value in and of themselves. You need something which explains what each tag is for and when it should be used. > Trying to create > rules upfront runs a high risk of being impractical. Which is why we create rules as we go along. "Creating rules up front" vs. "Having no rules" is a false choice. > And frankly, if our > mappers' creativity leads to two or three different ways of tagging the > same thing (but at least it gets mapped well), what's the big deal? The big problem is the reverse, when you have one way of tagging two or three different things. (See above.) Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, robin paulson wrote: >> I think we shouldn't vote on tags at all. Instead, we should monitor what >> gets >> used most by the mappers (see Tagwatch and the tool announced by >> Schuyler Erle). > > one of the problems with this, is that it's highly likely two mappers > will develop two contrasting, but both valid methods of mapping the same > object, and use them liberally. then some other mappers will follow one > way, and some other mappers will follow the other way. then we have a > jumbled data model. ... which can be fixed at a later time, if desired. Trying to create rules upfront runs a high risk of being impractical. And frankly, if our mappers' creativity leads to two or three different ways of tagging the same thing (but at least it gets mapped well), what's the big deal? The alternative is trying to force them to agree on one way of doing it, which (worst case) can make 49% of them unhappy and/or unwilling to map the item in question. If I can get 100 people to map something by allowing three different ways of doing it, then this is much better than getting only 51 people mapping it the "one true way". Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Christoph Eckert wrote: > Hi, > >> I think there are two messages here, firstly we should be really careful >> about voting for new features in the core tagging list unless they are >> strictly necessary, > > I think we shouldn't vote on tags at all. Instead, we should monitor what > gets > used most by the mappers (see Tagwatch and the tool announced by > Schuyler Erle). one of the problems with this, is that it's highly likely two mappers will develop two contrasting, but both valid methods of mapping the same object, and use them liberally. then some other mappers will follow one way, and some other mappers will follow the other way. then we have a jumbled data model. not only does this make things difficult for the renderers, as gerv said, but also for data analysts. hopefully, this data will be used for something more than routing between places and drawing nice coloured maps. i would like to think that geographers, social scientists, environmental scientists, historians, all could make use of the data by dragging out useful stats. when there are a number of ways of mapping the same thing, it becomes increasingly difficult to keep up with what relates to what. give everybody a simple list of consistent, unambiguous, non-overlapping data types, and the data becomes so much simpler to use i don't have much confidence that most people will use tagwatch to find out if a tagging scheme already exists. even with the present, partly centralised system, people are creating duplicated/overlapping/inconsistent schemes ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Christoph Eckert wrote: > I think we shouldn't vote on tags at all. Instead, we should monitor what > gets > used most by the mappers (see Tagwatch and the tool announced by > Schuyler Erle). I don't know about Schuyler's tool, but the massive problem with using this "popularity-based" approach is that there are no added semantics. OK, so several thousand people are using amenity=foo. Are they all using it for the same thing? How can you tell? There's no necessary incompatibility between the idea of Map_Features being in some way canonical (in that people can fix bogus tags to conform to it) and the idea that people should be able to invent new tags. > IMO mappers "abuse" our two main renderers as a control mechanism if they > have > done it right. As Spaetz pointed out, neither mapnik nor osmarender will ever > paint the same features. It's always up to the renderer to filter/decide > which attributes it likes. And the lives of the renderer authors are made miserable if there are four different ways to tag the same feature, all of which are used in different areas of the map. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
2008/8/31 Robin Paulson <[EMAIL PROTECTED]>: > i think we could bring a semblance of sanity and consistency to the > tag proposal and voting process quite simply I think by far the largest issue with the current process is unless you push a proposal it probably won't go anywhere. Proposals can sit dormant for more than a year even if there is currently no way to tag the feature in map features. While many missing features sit dormant highway=path access=designated goes to vote twice. A proposal that from the discussion is hard to implement and appears to not really allow anything new to be tagged. This discussion is after all about a path tagged highway=path; foot=designated. I presume that could just as well be tagged highway=footway; foot=yes. Of course since designated breaks the access tag it could just as easily be highway=footway; access=permissive. I think people who are happy with the current tagging scheme would welcome sanity and consistency but who would enforce it? I think the work would be unglamorous, boring and time consuming. Would anybody that didn't have an axe to grind with the current tagging scheme really want to sink so much time into babysitting proposals? I suspect it might end up just giving authority to people trying to reorganise map features and the proplem would end up worse. -- DavidD ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sun, Aug 31, 2008 at 4:08 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote: > and I haven't even mentioned the issue of z-ordering all of this God, z-ordering. I hadn't even thought of that :-( Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sun, Aug 31, 2008 at 3:17 PM, Andy Allan <[EMAIL PROTECTED]> wrote: > On Sun, Aug 31, 2008 at 9:12 AM, spaetz <[EMAIL PROTECTED]> wrote: > >> And second each added tag makes a) parsing slower b) the stylesheet more >> unreadable (for maintainers). > > Yeah - from the mapnik side of things we've already had Steve Chiltern > asking for help. The filter rules become immense quite quickly. > > Lets imagine a basic line, that can be on a bridge or in a tunnel - so > needs three filters > > foo = bar and tunnel = yes > foo = bar and bridge = yes > foo = bar > > but if there's now two ways of tagging the line, and maybe two ways to > tag a tunnel/bridge, then the rules become unreadable: > > (foo = bar or (foo = ben and ben = neb)) and (tunnel = yes or (kol = > lok and lok = web))) > (foo = bar or (foo = ben and ben = neb)) and bridge = yes or (blah = > ack and swe = ob)) > (foo = bar or (foo = ben and ben = neb) And just putting this for the highway=path example, for footpaths on the cycle map.. - we want to primarily render cycle paths - we also want footpaths when they're not cycle paths So a foot path can be: highway=footway highway=path, foot=yes(but only when not a bicycle path) highway=path, foot=designated A cycle path is: highway=cycleway highway=footway, bicycle=yes highway=path, bicycle=yes highway=path, bicycle=designated And a track is: highway=track highway=path, motorcar=yes (possibly... this remains ambiguous to me) So the rule for a foot path that isn't a cycle path would be: ((highway=footway and not bicycle=yes) or (highway=path and (foot=yes or foot=designated) and not (bicycle=yes or bicycle=designated) and not (motorcar=yes or motorcar=designated)) and not bridge=yes and not tunnel=yes which makes the styles completely unreadable and unmaintainable which is part of the reason (along with having other things to do, and not really agreeing with the need) why it hasn't been added. Also I'm not even sure we've imported all the columns to postgres to achieve it, and I haven't even mentioned the issue of z-ordering all of this to make cycle ways appear over the top of footways and residential roads etc. To cope with that we need to encode the same logic either into some SQL or a modified osm2pgsql. I've been playing with some planet preprocessing to hopefully make some of this a bit more sane, but it's still not trivial. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sun, Aug 31, 2008 at 9:12 AM, spaetz <[EMAIL PROTECTED]> wrote: > And second each added tag makes a) parsing slower b) the stylesheet more > unreadable (for maintainers). Yeah - from the mapnik side of things we've already had Steve Chiltern asking for help. The filter rules become immense quite quickly. Lets imagine a basic line, that can be on a bridge or in a tunnel - so needs three filters foo = bar and tunnel = yes foo = bar and bridge = yes foo = bar but if there's now two ways of tagging the line, and maybe two ways to tag a tunnel/bridge, then the rules become unreadable: (foo = bar or (foo = ben and ben = neb)) and (tunnel = yes or (kol = lok and lok = web))) (foo = bar or (foo = ben and ben = neb)) and bridge = yes or (blah = ack and swe = ob)) (foo = bar or (foo = ben and ben = neb) and full of devious bugs like the eagle-eyed would notice in the rules above[1]. And the self same complexity then bubbles up all over the place (like in mkgmap, and the editors...) which simply continually raises the barrier to entry and therefore makes the osm dataset *less* useful, not more. I'm meeting up with Steve Chiltern next week to look at ways to make the style rules for mapnik more easily maintainable when we are both in Aberdeen, and if anyone is interested in helping please jump in and help. Cheers, Andy [1] the second line is missing some brackets, and matches all instances of the alternative bridge tagging, even those not on foo=bar lines). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sun, Aug 31, 2008 at 6:50 AM, Peter Miller <[EMAIL PROTECTED]> wrote: > > I think it is really confusing for tags to appear on the main list of > features (http://wiki.openstreetmap.org/index.php/Map_Features) which then > don't get implemented by core applications I think it is really confusing that tags appear on the main list of features which aren't already implemented by core applications. > I think there are two messages here, firstly we should be really careful > about voting for new features in the core tagging list unless they are > strictly necessary, I think we should be really careful about voting. I think we should be really careful about trying to promote a second (or third or fourth) way of tagging the same thing. New features are different (and cool), but changing existing tagging schemes are almost always a waste of time - there's no feature that we couldn't map before, but now with extra hassle for everyone. > and secondly when a tag does get added then we should > look for rapid adoption across the main applications. Given that we have a lot of effort going into changing things on the wiki, and many fewer people making editors and maps, perhaps we should look for people to leave the wiki alone instead of asking for even more work from the latter, smaller group. > So, I am not really commenting on the path tag as such (although I could > because I have used it and do want it to appear on the cycle layer) I know ;-) But I've got different priorities for the cycle map - I want to show more things that aren't shown already (like cycleway = opposite and opposite_lane arrows, hillshading or even just bridges and tunnels) than spending time supporting more ways of tagging the same thing. And imagine if someone decides next week on a new way to tag rivers or maybe railways the week after, or buildings the week after that, and then woods - the amount of work needed to just stand still becomes ludicrous (and tedious) and the cycle map will never show anything new or interesting. Which would be a waste. And everyone needs to bear in mind that I'm quite happy dedicating most of my waking hours to OpenStreetMap and have done for the last six months. How would someone feel who only has time to work on their map once every few months if the style sheet only lasts for 3 weeks before someone rewrites Map Features for the 20th time? I'm not saying I won't find time to sort out everyone's requests, but I'd rather people left the wheel alone - it might be a bit wonky but it's not worth continually reinventing it instead of getting on with more interesting and useful things. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Peter Miller wrote: [...] > we should be really careful > about voting for new features in the core tagging list unless they are > strictly necessary [...] especially when they overlap with or attempt to supersede existing tags +1 cheers, Chris Send instant messages to your online friends http://uk.messenger.yahoo.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
2008/8/31 spaetz <[EMAIL PROTECTED]>: > OSM is a kingdom divided in pricipalities. And each of this principality is > governed by a "Benevolent Dictator" with very different views on how and what > OSM is and how/what maps should look like. You will never see the same > features rendered on Mapnik as on osmarender. And that is OK, even if it > makes the maps look different. Whether it is the right governance structure s > a different question, but changing that would require employing all of us :-) > i think we could bring a semblance of sanity and consistency to the tag proposal and voting process quite simply i'm of the opinion that osm as a whole would benefit from some discussion as to what it is we're aiming to do, and the generation of some use cases from that point it becomes not too complicated to come up with *guiding* (i.e., not hugely proscriptive) frameworks to help with the various areas of osm, including but not limited to tagging, editors, API, etc. has anything like this been done already? i mean beyond what stevec and others did back when it all started? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, > I think there are two messages here, firstly we should be really careful > about voting for new features in the core tagging list unless they are > strictly necessary, I think we shouldn't vote on tags at all. Instead, we should monitor what gets used most by the mappers (see Tagwatch and the tool announced by Schuyler Erle). > and secondly when a tag does get added then we should > look for rapid adoption across the main applications. IMO mappers "abuse" our two main renderers as a control mechanism if they have done it right. As Spaetz pointed out, neither mapnik nor osmarender will ever paint the same features. It's always up to the renderer to filter/decide which attributes it likes. We could try to set up a further renderer which tries to render everything we have on the Map Features page (or in the database). Mappers could then use it for control purposes. But it wouldn't be a nice map, I guess :) . > So, I am not really commenting on the path tag as such (although I could > because I have used it and do want it to appear on the cycle layer), it is > more that I want to avoid different dialects of tagging being used to > pander to different applications. The rule 'render and they will come' will > become really divisive if different application demand different tagging > for the same features. There's this nice "Don't map for the renderers" paradigm. Theoretically, mappers should "describe the world" in their tags, regardless if it's rendered or even not. But of course you want to see your edits in one of the applications. Mappers will always be tempted to use the tags that their favourite application(s) understand(s). What I want to say is that the people behind the cycle map decide which features they want to render. This decision is based on their personal taste, not on the appearence of tags on the Map Fetures page. And that's just fine. IMO it would be fine to have paths on the cyclemap (as I have mapped several of them and they really belong to biking). But if paths will appear on the cyclemap does not depend if paths are listed on the Map Features page. Cheers, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sun, Aug 31, 2008 at 06:50:46AM +0100, Peter Miller wrote: > I think there are two messages here, firstly we should be really careful > about voting for new features in the core tagging list unless they are > strictly necessary, Hear, hear! +1 > and secondly when a tag does get added then we should > look for rapid adoption across the main applications. speaking for osmarender at least, that would require somebody who feels responsible for the style sheets and takes care of that. Jiri Klement has been doing a good job at improving things. But it still doesn't have a CSO (Chief Style Officer :-)). And second each added tag makes a) parsing slower b) the stylesheet more unreadable (for maintainers). So adding tags as they are added to the core features list would require some confidence that the addition process is sane and careful (which goes against the wiki principle on that page and which goes against the current voting behavior too) I, personally, am not very keen to implement Sundays:OnLeftSide:SkiingRouteWithoutSnowboards:ButHikersOK=path (I think I have stepped on enough toes now ;-)) just because 2 people think it would be nifty and useful. OSM is a kingdom divided in pricipalities. And each of this principality is governed by a "Benevolent Dictator" with very different views on how and what OSM is and how/what maps should look like. You will never see the same features rendered on Mapnik as on osmarender. And that is OK, even if it makes the maps look different. Whether it is the right governance structure s a different question, but changing that would require employing all of us :-) spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
I think it is really confusing for tags to appear on the main list of features (http://wiki.openstreetmap.org/index.php/Map_Features) which then don't get implemented by core applications and I fear that we could end up with a maze of different tags used by different applications which would be really confusing for mappers and expecially newcomers? A new person, reads up, does some cautious editing and them some features don't appear on some applications they get told, well. if you want a walking route to appear on mapnik you should tag it as , but if you want it on osmarender remember that you mustn't use yyy however on the cycle layer it is best to yyy except that free-map prefers zzz and if you want it to route on openrouteservice you should etc etc. I think there are two messages here, firstly we should be really careful about voting for new features in the core tagging list unless they are strictly necessary, and secondly when a tag does get added then we should look for rapid adoption across the main applications. So, I am not really commenting on the path tag as such (although I could because I have used it and do want it to appear on the cycle layer), it is more that I want to avoid different dialects of tagging being used to pander to different applications. The rule 'render and they will come' will become really divisive if different application demand different tagging for the same features. Regards, Peter(Ito) > -Original Message- > From: [EMAIL PROTECTED] [mailto:talk- > [EMAIL PROTECTED] On Behalf Of Christoph Eckert > Sent: 30 August 2008 21:13 > To: talk@openstreetmap.org > Subject: [Spam] Re: [OSM-talk] Path rendering in the cycleway > > Hi, > > > highway=path has never been rendered on the cyclemap. > > > > highway=footway is currently rendered, so if you want it to appear, > > then you'll need to use that tag. > > was it possible to add highway=path? > > Best regards, > > ce > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, > highway=path has never been rendered on the cyclemap. > > highway=footway is currently rendered, so if you want it to appear, > then you'll need to use that tag. was it possible to add highway=path? Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sat, Aug 30, 2008 at 2:24 PM, Elena of Valhalla <[EMAIL PROTECTED]> wrote: > Hi > > I've noticed that paths are no longer rendered on the cycle map (were > they once? i believe so, but i'm not sure) and that is unfortunate for > my abuse of the cycle map as an hicking map, but understandable :) > > however, it seems that the names remained (at zoom level 15 - 17) > > http://openstreetmap.org/?lat=45.86667&lon=8.78932&zoom=16&layers=00BFTF > > it is an highway=path with foot=designated and sac_scale=mountain > > P.S. i looked for a direct contact for cyclemap problems, but i > couldn't find any: did I miss some place? highway=path has never been rendered on the cyclemap. highway=footway is currently rendered, so if you want it to appear, then you'll need to use that tag. The cyclemap home is at http://www.opencyclemap.org/ Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
