Re: [Tagging] Data redundancy with ref tag on ways vs relations
These are all good arguments but I think we should give more credit to mappers. Sorry if I'm being boring but I will again come back to OSMonitor reports that Polish community is now using for fixing roads - since I started publishing the reports every day I am shocked by how quickly people fix stuff based on these reports. Our Polish community is quite small and still we are making impressive progress towards all green. One thing I agree with is problem for the API/server-side. Though so far I haven't seen a relation in Polish roads that cannot be downloaded because it's too big, I know these things exist and that's a problem. As for breaking relations by newcomers - we plan to have a regression reporting as well so that once a road (relation) goes from green to yellow or red then it will be reported to wiki/mailing list/whatever and people can quickly fix it. I'm not trying to shamelessly promote my tool - I'm just sharing my thoughts and impressions after few short weeks and what I have seen the community can do when they have two things: 1. A baseline simple agreement on how we map - in this case we said we want to clean up relations for major roads in Poland. 2. Tool that will help with that - give up-to-date insight into data - otherwise you cannot see what's going on. Also as a bonus the tool can provide small motivations like coloring, statistics etc. - this really works and we enjoy it. Paweł On Tue, Jul 31, 2012, at 23:32, Pieren wrote: On Tue, Jul 31, 2012 at 10:41 PM, LM_1 flukas.robot+...@gmail.com wrote: Actually almost any proposal containing relations is criticised from this perspective (relations being too complex/complicated for mappers). If you explain OSM to an average newcomer, not a geek or a s/w dev: - yes, concept of relation is complicated (I'm even not talking about super-relations) - yes, it is not easy to edit (e.g. hte JOSM relation editor is fine, but hey, you need a special editor dialog with special features just for relations...) - yes, big relations are a problem for the API - yes, relations are difficult to maintain in long term because it's often broken... by newcomers. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ferry routes, what's the correct approach?
On Wed, 2012-08-01 at 00:22 -0400, David ``Smith'' wrote: I think access=fee, or access=yes + fee=yes would be appropriate. How do access=fee compare with access=customers in existing usage? (I tried to look it up myself on tagwatch, but my phone didn't like it much) The entry barriers were not, usually causing problems. They are tagged as toll barriers and routing works fine. The ones causing problems were usually on the exit, and will be very rarely closed (certainly will be open when a ferry arrives). Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] on the name of a tag for landcover
2012/7/31 LM_1 flukas.robot+...@gmail.com: When you search wiki for grass, you get landuse=grass. When you type grass in JOSM's preset search box, you get landuse=grass. Potlatch does not offer any direct way to tag grass. landuse=grass was probably used before anyone thought about the difference between landuse and landcover (in osm tagging). Today's renderers support landuse=gras and do not support landcover=anything. That being the reasons for landuse=* domination it is hardly enough to proclaim it the better way. +1 It hardly is the better way. The key landuse is contaminated with a lot of values that simple don't fit or are used in an inconsistent way. Most prominent example for sure is landuse=forest, which currently is used in case the land is covered with trees. But this is not a landUSE. If the land is used for growing trees than landuse=forest is correct, but there may not be any trees at all at the current time because they are just being planted (landuse=forest + landcover=grass). On the other hand there could be a lot of trees but completely unmanaged (landcover=trees + no landuse). That's the main reason why landuse (and also natural) needs some heavy cleanup which of course would deprecate some tags and for sure take some time. But I don't see any other way. I started an overview on my user page of the current usage of landuse/natural and how it might look if we use landcover. If someone is interested take a look. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC: Names localization
Hello, I've summarized [1] the ideas that were recently discussed in talk@ regarding the names, their different language mutations, ... I would like to hear some comments, additional pros/cons I could not think of myself, etc. Although I was arguing for the don't repeat yourself solution, I can see that it has its drawback in that it's not that intuitive. So right now, personally, I'm not really sure which solution is better. Best regards, Petr Morávek aka Xificurk PS: CC to talk@ because the ideas were born there, but I kindly ask you to send any responses directly to tagging@. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Names_localization signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Names_localization +1, generally; but I'm not keen on deprecating the bare name=* tag, because for many (perhaps most) named features, there is only one name. For example, a minor rural road in England will probably have a name (in English), but it won't have names in other languages, and no-one will really describe its name as its English name --- it's simply its name. Multiple names are really an issue for multilingual countries and for major features (typically large cities, rivers, and perhaps mountains) in monolingual countries, and I suspect those are well under half of all the features that will ever be mapped. Having just suggested keeping it simple, I'll suggest a complication as well: multiple scripts for the same language. In particular, I'm thinking of mainland China, as it opens up more to interaction with the West; and, when I did an introductory course on Chinese language and culture, my teacher said the Chinese people begin learning to read and write using pinyin, rather than in Chinese script, so maybe we should ask Chinese mappers whether they're interested in it being convenient to have names in both. __John ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
2012/7/31 Apollinaris Schöll ascho...@gmail.com Instead of saying don't impose your views on others, you should provide an argument why the proposal is bad and ideally, propose alternative solution to the presented problem. This way, I can react with counter-argument, or admit that the original proposal was bad, and after few iterations a real solution can be reached. arguments will not help much here. osm has somewhere around 2 active users http://wiki.openstreetmap.org/wiki/Stats a small fraction is reading these lists or forum posts. Whatever you propose here will not even reach most mappers. You cant teach them how to map your way. They don't even now how great your proposal was. And they will break your perfect data and you have to fix it or we are back where you started. Oh, please! Good, tidy data is self-mantaining. People working with it, unless they're utterly incompetent (and I don't mean incompetent at OSM, but at any thing ordered and clean), will easily recognize a pattern, and will act consequently. On the other hand, if they see that some street names are written all caps, others capitalized, others all lowercase, others capitalized wrong, they'll easily assume there's no rule at all (they won't even think about the fact that there might be one!), and will add confusion to the confusion. ad 2) This is actually not an argument against any tagging proposal, but argument for improving relation handling in editors. Do you know how many editors are out there? and there are bots all kinds of scripts with API upload support ... Feel free to fix all of them. As far as I know not a single editor for mobile applications has any relation support. ...and here's why CSS is now a forgotten, pityful attempt that has justly been abandoned. No, wait. I use mostly JOSM which has good relation support. But still it's a pain and a challenge. Just downloading a huge relation takes too much time. No editor can fix this because it's the nature of the data model. What's painful and challenging in double clicking and using a window which is exactly the same tag table as the one you have for nodes and ways, plus an obvious self-explaining list of members with roles? The problem of roads tagging, was brought up in talk-cz several times. The problem is that current tagging scheme is semantically wrong - e.g. we have only one primary road number 2, but OSM data says we have several hundreds of them. The same for named residential streets in cities. This causes several problems. It makes it hard for data producers to edit the road, because you have the information about it duplicated over several hundreds of segments. It makes it hard for data consumers to present the data in a meaningful way - really? I can't see that. there are many map rendering solutions, routing algorithms for desktop, web service, mobile devices ... Must be a miracle that they all function. btw I am not aware of many using relations. What would consumers' assumptions be, reasonably? That any ways with the same value in a given tag would have to be considered a single thing? I have examples of separate streets with the same name in the same city, not separate, non-connected parts of the same street, mind you. A relation here would describe the reality without fail, and much more elegantly. . When I see this thread (and others like this) and all the resistance (with little arguments) that any proposed change causes at global OSM level, I'm starting to think that we (in Czech Republic and other communities as well) should simply go ahead and play by our own rules at our own backyard and just ignore the global consistency. nothing wrong with that. But be aware that all these local communities have to come up with their own solutions to use the data. Is the Czech community large enough to offer maps, routing in all flavors and other useful applications? probably it's much easier to go with the flow and bear a with some oddities. According to your reasoning, Germans should tell us how to map because they make tools and consumers. Is this correct? Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Petr Morávek [Xificurk] wrote: On the other side of the spectrum is Potlach, which makes anything involving relations overly complicated. I've fixed my share of relation bugs, that I dare to say came from these poor editing capabilities. Wow. When was the last time you used Potlatch? 1873? To add a way to, say, a cycle route relation: 1. Click the tab with a picture of a bicycle 2. Under National Cycle Route, click 'Add to a route' 3. Choose the one you want and press 'Select' If that's overly complicated then I guess maybe we could look at sending a holographic avatar round to the user's house to do it for them. I'm sure ActionScript has an API for that somewhere. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Data-redundancy-with-ref-tag-on-ways-vs-relations-tp5719083p5719266.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] on the name of a tag for landcover
Am 01.08.2012 um 17:09 schrieb John Sturdy jcg.stu...@gmail.com: I think it's a good idea to fix this, but it may have gone too far to be fixable. Oh come on! Be a little bit optimistic! ;-) I started an overview on my user page of the current usage of landuse/natural and how it might look if we use landcover. If someone is interested take a look. Could you send a link (sorry, I can't remember your username, and can't find your page using the search facility although I may have used the wrong search)? Ups - forgot to add the link: http://wiki.openstreetmap.org/wiki/User:Imagic/landcover Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
2012/8/1 Peter Wendorff wendo...@uni-paderborn.de Am 01.08.2012 16:01, schrieb Simone Saviolo: Do you know how many editors are out there? and there are bots all kinds of scripts with API upload support ... Feel free to fix all of them. As far as I know not a single editor for mobile applications has any relation support. ...and here's why CSS is now a forgotten, pityful attempt that has justly been abandoned. No, wait. There are two big differences between CSS and the proposed relation stuff. 1) The inventors of CSS provided a working implementation for core CSS features 2) For a considerably long time css was used only very sparse and most of the time with a html4 styling fallback. Nobody arguments about the proposed use of relations per se, but it's far from enough to propose something. 1) Proposing one option is not the same as deprecating another, and that's what some want to do here. 2) Support in editor software does not rely on fixed rules only to use relations, so that could be added even before switching, and both variants may co-exist for some time. The arguments mainly are: relations are the better data model therefore let's deprecate ref tags on ways. instead of: relations are the better data model let's make editors great enough that relations are on top of that easier to use for mappers let's make the API better by fixing the performance issues that occur regularly when dealing with big relations (or very long ways) Let's then encourage by arguments instead of rules to use relations - as there's no good counter argument any more: At this stage they are as easy to use, better to maintain and the cleaner data model. This is a big difference. The first approach is what's tried here, and get's bad critics from some others, because usually these attempts end up with new proposals and questions to the old developers why don't you support that? it's the 'only' way to do it right - or something like that. It's the same thing as CSS, actually. It's not a matter of providing a first implementation. It's a matter of saying this is how you can expect data to be. If you don't say that (which is what OSM keeps doing) no-one will *want* to use inconsistently-modelled data. Also, we shouldn't be afraid if only two applications out of 500 support the full data model. Also, as long as we keep the good way together with the limited way, most consumers won't bother switching to the better model. The problem of roads tagging, was brought up in talk-cz several times. The problem is that current tagging scheme is semantically wrong - e.g. we have only one primary road number 2, but OSM data says we have several hundreds of them. That's wrong, as you don't read it correct. It's based on the assumption, that one named street is one object in OSM, But the osm object isn't the main street, it's a part of street that has the name main street. Other parts of the street, connected to that part, have the same name. The same for named residential streets in cities. This causes several problems. Let's use the residential street example. How do you as a human being decide where a street ends? At every intersection there's a new street sign - repeating the same street name, so you as a human decide that the next segment is part of the same street. Well... that's easily to be implemented in software, too: collect connected streets with the same name and you're done. But that's not the only argument? Sure: sometimes you don't want to deal with one street as one street, e.g. because a part of it is a pedestrian area, and you want to deal with that differently - well, then use the same approach based on additional parameters, e.g. only use parts of that street that can be used by cars etc. Sure: We could add different relations for that, but is it really helpful, as soon as that algorithm is once implemented in your software? It makes it hard for data producers to edit the road, because you have the information about it duplicated over several hundreds of segments. May be hard, but as mentioned before: most common attributes aren't changed very often, and once tagged that's no problem again. Editor software supports to repeat last used tags nowadays, and so on. On the other hand: Consider a route relation. A changing ref may be changed easily now, as it's only editing the relation once. What about a speed limit implemented for some kilometers for a while, e.g. because of a bad surface? Do you add that to the individual segments now? or do you add a new relation, because it's - as you say - easier to handle that? As you want to deprecate the on-way-variant, that would the way you go, if I understand it right. Now let's assume there are two construction sites that join together two weeks later. You have two relations now, that are connected when you look on the members. Do you join these to one? If so: how
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Petr Morávek [Xificurk] wrote: On the other side of the spectrum is Potlach, which makes anything involving relations overly complicated. I've fixed my share of relation bugs, that I dare to say came from these poor editing capabilities. I've resurrected about half a dozen relations since the start of the year, and honours are about even, I think, between Potlatch and JOSM users. Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Petr Morávek [Xificurk] xificurk@... writes: [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Names_localization OK, so if I understand this right lang=language_code is supposed to tell what languages that are used in the tag name=place_name May I propose to use lang:name=language_code instead of lang=language_code (or is it name:lang=language_code) Then the key lang: could be used even if there happens to be more tags that need its language stated. By the way, is it only meant as an internal OSM-thing or is it supposed to also be a mapping of official languages in the place (or official languages expected on road signs)? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Johan Jönsson wrote: lang=language_code is supposed to tell what languages that are used in the tag name=place_name May I propose to use lang:name=language_code instead of lang=language_code (or is it name:lang=language_code) I don't like name:lang simply because it conflicts with the established scheme for tagging names in different languages, e.g. name:en=London. Then the key lang: could be used even if there happens to be more tags that need its language stated. lang:name=en might make sense, but do you have an example where this would be useful? By the way, is it only meant as an internal OSM-thing or is it supposed to also be a mapping of official languages in the place (or official languages expected on road signs)? Could you provide an example, where those two are different? The proposal was primarily meant to fix the unclear meaning of bare name tag, but it's still just the first draft. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Petr Morávek [Xificurk] wrote: I apologize if my words sounded harsh or offending. I admit that I'm not regular user of Potlach, so my knowledge of it is kind of limited. I can tell... you can't even spell it. ;) (Sorry, cheap shot. But it's PotlaTch.) 1) Pointless members of relations, e.g. a German train station added to the Czech administrative boundary relation. My guess is that the user mistyped the relation id when he/she wanted to add that station to some route relation. I have no idea, why he/she did not use the method, you've described, but it happens. There's not a whole bunch that P2 or any editor can do to stop people mistyping numbers (i.e. when loading a relation by id that's not in memory). I think this goes back to the point I made earlier in the thread: that if relations are to be adopted as the replacement for the ref tag, then we need to give the API a fast, efficient bbox-limited search function, such that the editor can automatically load the Czech admin boundary relation via the API rather than having to copy out an id from the wiki. 2) Generally broken relations, e.g. the user deleted a way that was part of large forest polygon, probably because the way itself had no tags. I presume this is caused by not very good visualization of relations in Potlach, thus most of the time users are simply unaware that they are breaking something. A simple task like seeing that the way/node is part of some relation requires a user to switch to Advanced mode and look at the list. Ok. So I've just five minutes ago committed this: https://github.com/systemed/potlatch2/commit/54e3ae56e128523104aa786363b5337f9f5a68e9 which builds on the earlier https://github.com/systemed/potlatch2/commit/6df69becdd6990294c964b2e469c76631a3e312a to give an indication of unrecognised relation memberships in Simple view. That should fix that. So can I ask you for a quid pro quo? tagging@ is not the Potlatch 2 bugs channel, especially when phrased in flamebait terms such as poor editing capabilities and overly complicated. There is a potlatch-dev@ mailing list and a P2 trac component. Use them. Venting elsewhere might be therapeutic and make you feel happier, but it generally doesn't get things fixed (it's just by chance I'm reading this thread). By analogy, it used to be really very common for relations to be deleted by accident with JOSM. I posted to josm-dev@, the developers responded helpfully, we had a conversation, and things improved (see http://gis.19327.n5.nabble.com/Another-66-relations-bite-the-dust-td5333242.html for the right thread). If you have a suggestion for P2 or any other component of OSM, that's great: but write it constructively, and in the right place. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Data-redundancy-with-ref-tag-on-ways-vs-relations-tp5719083p5719286.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Petr Morávek [Xificurk] xificurk@... writes: Johan Jönsson wrote: By the way, is it only meant as an internal OSM-thing or is it supposed to also be a mapping of official languages in the place (or official languages expected on road signs)? Could you provide an example, where those two are different? The proposal was primarily meant to fix the unclear meaning of bare name tag, but it's still just the first draft. Sorry if I am getting to theoretical on the subject of how to write tags. I was wondering about the reason for this tag, *is it to explain the languages in the tag name: (if, like in your bruxelles-brussel example, is two names I guess that the order is important) *or is it aimed at noting information from wikipedia on the official languages of this place (probably ordered after number of speakers but with administrative language first or something). *It could also be meant to explain something that might not exist on wikipedia, in what languages and scripts the road signs usually are on the place. In the greece capital Athens there are usually the name in greek letters first and then in roman letters (gr and gr_rom maybe). I do not say that these things generally differ much, I just say that which of these that is supposed to be tagged could be good to know. p.s. If we leave the cities I could think of a nice example. A pub or maybe camping place where they have a sign outside telling what languages the staff speaks, seen these on swedish camping places. d.s. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 01.08.2012 17:24, schrieb Simone Saviolo: 2012/8/1 Peter Wendorff wendo...@uni-paderborn.de mailto:wendo...@uni-paderborn.de Am 01.08.2012 16:01, schrieb Simone Saviolo: Do you know how many editors are out there? and there are bots all kinds of scripts with API upload support ... Feel free to fix all of them. As far as I know not a single editor for mobile applications has any relation support. ...and here's why CSS is now a forgotten, pityful attempt that has justly been abandoned. No, wait. There are two big differences between CSS and the proposed relation stuff. 1) The inventors of CSS provided a working implementation for core CSS features 2) For a considerably long time css was used only very sparse and most of the time with a html4 styling fallback. Nobody arguments about the proposed use of relations per se, but it's far from enough to propose something. 1) Proposing one option is not the same as deprecating another, and that's what some want to do here. 2) Support in editor software does not rely on fixed rules only to use relations, so that could be added even before switching, and both variants may co-exist for some time. The arguments mainly are: relations are the better data model therefore let's deprecate ref tags on ways. instead of: relations are the better data model let's make editors great enough that relations are on top of that easier to use for mappers let's make the API better by fixing the performance issues that occur regularly when dealing with big relations (or very long ways) Let's then encourage by arguments instead of rules to use relations - as there's no good counter argument any more: At this stage they are as easy to use, better to maintain and the cleaner data model. This is a big difference. The first approach is what's tried here, and get's bad critics from some others, because usually these attempts end up with new proposals and questions to the old developers why don't you support that? it's the 'only' way to do it right - or something like that. It's the same thing as CSS, actually. It's not a matter of providing a first implementation. It's a matter of saying this is how you can expect data to be. If you don't say that (which is what OSM keeps doing) no-one will *want* to use inconsistently-modelled data. Also, we shouldn't be afraid if only two applications out of 500 support the full data model. One difference is backwards compatibility - that's what I say when I want you to at most encourage to do as you suggest, but not forbid to do as you don't. When introducing CSS it was not designed to fail if the old html style was present, it was added to the old data model, and the overall strength of the CSS design lead slowly - in a timespan of around 10 years!!! - to more and more CSS usage and less and less html formatting usage. And even there something in between went incredibly wrong, as the people forgot to use semantic tagging in HTML, because everything could be done by div, span, img and a tags, before search engines started to deal with semantics for search. Nobody as far as I know throwed CSS into the world saying you have to deal it that way, and we propose that - that's what we guess - someone will support it in some time., but that's what you suggest here. The CSS people - I talked to Hakon Wium Lie some time ago after he gave a talk here at the university - didn't expect someone else to support CSS at first, they implemented it additionally to the stylesheet, e.g. to Opera. That's what I suggest you to do: don't say do it this way, and some times even the devs of josm, potlatch, meerkator, osmand and so on will support it in a better way (because it's better to support), but provide that support. All major software components around OSM are open source. You are allowed and invited to provide that better support in any editor you like; but currently all you do is this is the better way because it's supposed to be possible to give better support in editors. Currently that's not the case in the editors (before someone asks: sure, there's relation support, but it's not easier than using tags as far as I know). Also, as long as we keep the good way together with the limited way, most consumers won't bother switching to the better model. Well... sounds as the only reason why someone should want to is that there is no data any more for the old way. If that's the only reason, then it's no reason provided by the model, but provided by the data we can provide; it's not this is the better model then, but sorry, but we decided to don't give you the old model any more, you have to switch or you don't get data. Sure, we can do that - but it's not an argument for a model being better, but an argument for take it or leave it, and I fear, some will leave it -
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Hi, On 08/01/2012 04:01 PM, Simone Saviolo wrote: What would consumers' assumptions be, reasonably? I think that we are talking too much about consumers here. OpenStreetMap mappers are *already* providing a tremendous value to many consumers around the world, no matter how limited and chaotic their data model might be. It is possible that consumers would like to have data in a different format but I believe that it is not asking too much if we expect them to invest a little work themselves, to bring the data into the shape they want. There are many situations where the demands of consumers are out of line with what comes easy to mappers. And honestly, I think it is rather brazen to come along and demand that mappers do something differently just because it would make life even easier for one specific use case or one specific consumer. That any ways with the same value in a given tag would have to be considered a single thing? I have examples of separate streets with the same name in the same city, not separate, non-connected parts of the same street, mind you. A relation here would describe the reality without fail, and much more elegantly. You are free to *create* such a relation if you think it is useful. The only thing we don't want is that you start telling everyone else that *they* should be creating relations for that. (Xificurk quote) When I see this thread (and others like this) and all the resistance (with little arguments) that any proposed change causes at global OSM level, The hubris lies in proposing anything at the global OSM level. There are *very* few things that are truly global - the fact that we have nodes and ways, or that a tag can only be so long, or that you mustn't copy stuff from copyrighted maps or invent fantasy data. According to your reasoning, Germans should tell us how to map because they make tools and consumers. Is this correct? Tools must serve mappers. Everything in OSM must be geared towards making contribution easy for mappers. Anything else is secondary; consumers are totally unimportant. Not because we don't want OSM to be usable - but because there is such a tremendous value in OSM that any difficulties in usability *will* be overcome by those who want to use OSM - we don't even have to waste time thinking about that. As for Germans, I don't know what you are talking about. There are three major OSM editors and Germans don't form the majority of contributors to any of them. JOSM's inventor and current maintainer are from Germany but as far as I can see, the active JOSM developer group is fairly international, or at least pan-European. Major quality checking tools are from the UK (ITO), Germany (OSM Inspector), Austria (Keepright), France (Osmose) and others. As for rendering software, none of the major renderers (Mapnik/TileMill, Maperitive, kothic) have had significant German input, and neither have the widely-used map styles. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
On Wed, Aug 1, 2012 at 10:37 AM, Apollinaris Schoell ascho...@gmail.comwrote: Obviously you haven't used it enough otherwise you would know better. It had so many bugs over time the list of broken relations is endless. Read the archives and you will see. It has been improved over the years but still far from comparable to editing nodes and ways. I have used many types of CAD tools and trained people using them. If you or I am able to use JOSM doesn't mean others can. So fix the other editors. Potlatch is notoriously painful when it comes to relations, and it really shouldn't be. Relations really are the way to go on this because the advantages outweigh the drawbacks by a lot. Validation tools and editors really need to catch up to this. The ref= on way model works great in Europe where you only have one route per way and assume only road routes, but breaks when you start considering other networks (bicycle, etc), and just gets totally unmanageable in North America (where you might have a half dozen road routes, one or two bike routes and a public transport route or two for good measure sharing the same way). This is a stupid argument to have at this point. Get over it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Frederik Ramm wrote: Tools must serve mappers. Everything in OSM must be geared towards making contribution easy for mappers. Anything else is secondary; consumers are totally unimportant. I think, this is the point on which we fundamentally disagree. Consumers and data usability is important as well. It's not always easy to walk the thin line between the needs and preferences of contributors and consumers, but we should try to. I mean, what's the point of producing the data, if they are unusable or really hard to use? If we go down this road, we should employ a bunch of monkeys that will bang into the keyboards and produce more data for OSM. Who cares those data are unusable? The consumers are totally unimportant as long as the monkeys contribute to the project. Having the data in more or less usable state is important makes it easier to build new amazing tools and projects upon them. And these projects are vital for OSM - just ask yourself, what was the initial reason for starting to contribute to OSM? Was it something like Hey, we're crunching a bunch of geo data into this big database called OSM, wanna join us? Or was it something like Hey, look at this map/navigation SW/..., isn't it great? What? Your house's not there? But look, you can add it simply like this. Data consumers and their projects are crucial in attracting new contributors, that's why we shouldn't make it unnecessarily complicated for them and say that they are totally unimportant. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Paul Johnson wrote: So fix the other editors. Potlatch is notoriously painful when it comes to relations, and it really shouldn't be. Sigh. Are you going to quantify that and offer some suggestions (or, hey, some code), or just throw around unsubstantiated assertions? Richard -- View this message in context: http://gis.19327.n5.nabble.com/Data-redundancy-with-ref-tag-on-ways-vs-relations-tp5719083p5719302.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
On 01/08/12 18:41, Petr Morávek [Xificurk] wrote: Frederik Ramm wrote: Tools must serve mappers. Everything in OSM must be geared towards making contribution easy for mappers. Anything else is secondary; consumers are totally unimportant. I think, this is the point on which we fundamentally disagree. Consumers and data usability is important as well. It's not always easy to walk the thin line between the needs and preferences of contributors and consumers, but we should try to. I mean, what's the point of producing the data, if they are unusable or really hard to use? If we go down this road, we should employ a bunch of monkeys that will bang into the keyboards and produce more data for OSM. Who cares those data are unusable? The consumers are totally unimportant as long as the monkeys contribute to the project. As a lowly monkey who contributes and a super important consumer who uses the data I know that most people who make grand statements about how important it is to have consistent data have never actually tried to seriously use any OSM data. As soon as you do use the data you realise that some kind of preprocessing to extract what you are interested in is always required. You write that code once and use it again and again so dealing with anomalies in the data becomes easy - really. How would we render maps, write editors, routers, data analysis or any other stuff with the existing data if it was so hard to do? Of course my maps, analysis and other outputs would be very small without the monkeys, as you call us, adding data. Discussions are useful and can be fun, but real proposals need to be grounded in reality. The reality is that OSM has to focus on mappers. Data consumers have to accept what they are given. You will find it's not as hard as you think. If the product you write ignores people's (sorry monkeys') work and they want it to appear they will adapt or ask you to adapt and if you are smart enough to understand that computers are a tool for people, not the other way round, you will sometimes respond. Having the data in more or less usable state is important makes it easier to build new amazing tools and projects upon them. And these projects are vital for OSM - just ask yourself, what was the initial reason for starting to contribute to OSM? Was it something like Hey, we're crunching a bunch of geo data into this big database called OSM, wanna join us? Or was it something like Hey, look at this map/navigation SW/..., isn't it great? What? Your house's not there? But look, you can add it simply software writer like this. Data consumers and their projects are crucial in attracting new contributors, that's why we shouldn't make it unnecessarily complicated for them and say that they are totally unimportant. Data consumers are important, but never at the expense of OSM's most precious resource: mappers. Complex tagging schemes, restrictions on what to tag and bots that change people's work to homogenise nuanced data are sure to drive mappers away. Without them data consumers will be whistling in the wind. -- Cheers, Chris user: chillly ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Chill guys. Refs and street names on ways are OK in most countries. So leave well alone. Data consumers can and do cope. If you're one of the few places that use multiple refs on a single street, then code them by local agreement - probably using relations. Yes, relation support should improve. But don't hold your breath. Richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 01.08.2012 19:41, schrieb Petr Morávek [Xificurk]: Frederik Ramm wrote: Tools must serve mappers. Everything in OSM must be geared towards making contribution easy for mappers. Anything else is secondary; consumers are totally unimportant. I think, this is the point on which we fundamentally disagree. Consumers and data usability is important as well. It's not always easy to walk the thin line between the needs and preferences of contributors and consumers, but we should try to. Consumers and data usability is important if and only if we want to sell the data, if we benefit from more and more people using our data. It's great to see more and more parties to consume osm data, but there are different types of data consumers. The group that most benefits from your suggestion of better - or even perfect - data usability is the group of people who don't want to work with the data, but use it. These aren't willing to put effort into osm to make it better, and often come to us (through every possible channel) and ask questions, but don't provide results back to the project. To be able to provide results back one has to understand how it works, so I have to deal with OSM as a whole, not only with the data to do that. If you have a company and ask I want to do this and that, who can do me that, I pay X for it, I think somebody is there who would do the job - if it's a reasonable amount of money for the task. If you don't want to pay, then do it yourself or go away. Mappers are so to say part time egoists: Most of them want to provide data to everybody, but not for every price. If it's too hard fiddling around with bad editors or a too complex data model, some may go away and leave osm, because it's the fun of mapping and creating a big whole why I and most others are mappers. If you rise a flag for the consumers side and decrease the mapping useability with that, these mappers will go away - and afterwards most probably the data consumers will follow, because there's no (updated) data any more in a reasonable quality and quantity. Feel free to provide the supporting middleware to make osm data useable for your customers, and if you want, let them pay for this service. Feel free to make a better data model, that serves consumers needs better, as long as it serves mappers needs at least equally than before - without adding strict rules for that. I mean, what's the point of producing the data, if they are unusable or really hard to use? If we go down this road, we should employ a bunch of monkeys that will bang into the keyboards and produce more data for OSM. Who cares those data are unusable? The consumers are totally unimportant as long as the monkeys contribute to the project. It's not unuseable. There are working routing engines, There are working renderings - 2D, 2.5D, 3D. There is at least one working search engine. There are several routing apps, online, offline, mobile, saas, even in hardware. There are exports even to closed data formats like garmin, that there are restrictions sometimes is not the fault of osm data. Yes, that's not easy to achieve, but the software is free, code inclusive (with very very few restrictions). You don't have to invent the wheel again, but if you want, you have to deal even with the less easy to consume data model. Having the data in more or less usable state is important makes it easier to build new amazing tools and projects upon them. And these projects are vital for OSM - just ask yourself, what was the initial reason for starting to contribute to OSM? I don't know any project that has not been build because of the complex or unuseable data model. There are some small projects that reject(ed) to use osm because we don't provide ready to use tiles, and they drive better using google, because there they don't need their own tile servers; something that has changed since then. Do you have examples for amazing tools that have been stopped in development due to the data model? If so, I'm pretty sure the inventors didn't talk to the osm community, as usually there's help from different sides. Hints where pieces of software are done already, that can be reused, help with even simple coding problems sometimes. If one doesn't communicate with the community, of course there cannot be anyone to help, but that's not the fault of the data model. Was it something like Hey, we're crunching a bunch of geo data into this big database called OSM, wanna join us? Or was it something like Hey, look at this map/navigation SW/..., isn't it great? What? Your house's not there? But look, you can add it simply like this. It was the map, yes, but your data don't make maps better. Show us the code where map renderers prefer to use relations for streets. The public transport and hiking maps are the only ones I know of that render relations, but as far as I know these most often drop the attributes of the relations down to the ways to do
Re: [Tagging] Data redundancy with ref tag on ways vs relations
On 8/1/2012 2:51 PM, Peter Wendorff wrote: Bing I think provided the imagery, but I don't think we really got much mappers through bing. Apart from the news we got due to that in the press, I don't even believe many bing users REALIZE that they use an open project where they could contribute. Bing does not yet use OSM for any of its map products. I see the Bing imagery donation as a strategic possibility for them to use OSM in the future when it is as useful as Navteq overall, with the added benefit of insane detail in some locations that competes well against Google. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 01.08.2012 21:02, schrieb Mike N: On 8/1/2012 2:51 PM, Peter Wendorff wrote: Bing I think provided the imagery, but I don't think we really got much mappers through bing. Apart from the news we got due to that in the press, I don't even believe many bing users REALIZE that they use an open project where they could contribute. Bing does not yet use OSM for any of its map products. I see the Bing imagery donation as a strategic possibility for them to use OSM in the future when it is as useful as Navteq overall, with the added benefit of insane detail in some locations that competes well against Google. http://www.bing.com/community/site_blogs/b/maps/archive/2010/08/02/bing-maps-added-open-street-maps-layer.aspx I'm not sure if that's still actual information, but that's what I had in mind. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Hello Chris, please, do not put words into my mouth. I did not call you or any other OSM contributor a monkey. And I did not call any consumer super important. If you think, I did, I kindly ask you to read my email again and more carefully. Chris Hill wrote: most people who make grand statements about how important it is to have consistent data have never actually tried to seriously use any OSM data. I can tell you straight away, I'm not most people. Data consumers are important, I'm glad we agree on this particular point. Best regards, Petr Morávek aka Xificurk signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Peter Wendorff wrote: If you rise a flag for the consumers side and decrease the mapping useability with that, these mappers will go away - and afterwards most probably the data consumers will follow, because there's no (updated) data any more in a reasonable quality and quantity. I did not say that perfect usability should be our holy grail, or that we should do everything we can to make things easy for consumers. That's the other extreme that's not healthy either. I simply object to the claim that consumers are totally unimportant. If we can agree this is a wrong attitude, I would be happy ;-) I don't know any project that has not been build because of the complex or unuseable data model. Do you have examples for amazing tools that have been stopped in development due to the data model? Are you seriously asking me the question that falls into the same category as When was the last time you saw an invisible dragon? :-) This will happen if we will call consumers totally unimportant and if we will produce _unnecessarily_ hard to use data just because we can and they must deal with it. Best regards, Petr Morávek aka Xificurk PS: Although this is still in thread about ref tags, it was a simple reaction to Frederik's statement about totally unimportant consumers without any relation to the ref topic. signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Wed, 01 Aug 2012 19:48:37 John Sturdy wrote: [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Names_localization +1, generally; but I'm not keen on deprecating the bare name=* tag, because for many (perhaps most) named features, there is only one name. For example, a minor rural road in England will probably have a name (in English), but it won't have names in other languages, and no-one will really describe its name as its English name --- it's simply its name. Multiple names are really an issue for multilingual countries and for major features (typically large cities, rivers, and perhaps mountains) in monolingual countries, and I suspect those are well under half of all the features that will ever be mapped. I like the proposal in general, but I don't think it's necessary to introduce a lang=* tag, and I don't think we should lose the name=* tag. It's also not true that in a 'monolingual' country that there is only one name for something. For example, London is 'London' to a British person, but 'Londres' to a French person. I still think it's simple enough to have name=* to be the 'default' name you get if you don't specify a language, or the name you get if your selected language is not available. For example, for London: name=London name:en=London name:fr=Londres Then a person requesting a French version of the map would see 'Londres', but a person requesting the German version would see 'London'. If no language is specified a person would see 'London'. A simple algorithm can also make bilingual maps by concatenating tags, i.e. name:xx (name:yy) and making sensible decisions if name:xx=* or name:yy=* is missing, or if name=* contains name:xx=* or name:yy=* (such as in Japan or Korea where name=* contains Japanese (or Korean) followed by English in brackets). Best wishes, Andrew ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Data redundancy with ref tag on ways vs relations
Am 01.08.2012 22:56, schrieb Petr Morávek [Xificurk]: Peter Wendorff wrote: If you rise a flag for the consumers side and decrease the mapping useability with that, these mappers will go away - and afterwards most probably the data consumers will follow, because there's no (updated) data any more in a reasonable quality and quantity. I did not say that perfect usability should be our holy grail, or that we should do everything we can to make things easy for consumers. That's the other extreme that's not healthy either. nice to agree here ;) I simply object to the claim that consumers are totally unimportant. If we can agree this is a wrong attitude, I would be happy ;-) fine. I don't know any project that has not been build because of the complex or unuseable data model. Do you have examples for amazing tools that have been stopped in development due to the data model? Are you seriously asking me the question that falls into the same category as When was the last time you saw an invisible dragon? :-) Well, I don't think we don't provide enough possibilities to get in contact. Mailing lists, forum, local meetings... Whoever wants to do such a project usually has to get in contact with the data providers, and there it's independent if it's OSM or navteq or anyone else. At Navteq and other companies you even are not able to get a glance on the data without getting in contact to them. OSM provides you the data even anonymous, and you're free to ask for help and further information. Hundrets get in contact with osm as newbies every week, I'm sure, I think, around 10 we have in average per week, that visit the german IRC channel alone and ask questions, as mappers, as possible web map users, as possible coders, as possible companies thinking about more sophisticated solutions. Some go away again, some even ask for someone doing something for money, some stay as active contributors, and some provide patches and ideas to code. If someone wants to do an amazing tool using geodata alone without getting in contact, he most probably will fail - independent of the data source used. So I claim that most of these tools either didn't think about using OSM seriously or they don't exist, but they are, I guess, not purely invisible. This will happen if we will call consumers totally unimportant and if we will produce _unnecessarily_ hard to use data just because we can and they must deal with it. Nobody want's to produce unneccessarily hard to use data, but it's still your unproven and for some of us unbelieved claim that it's easier to use with relations, summarized over data consumers and mappers. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
On Wed, Aug 1, 2012 at 10:28 PM, Andrew Errington erringt...@gmail.com wrote: On Wed, 01 Aug 2012 19:48:37 John Sturdy wrote: It's also not true that in a 'monolingual' country that there is only one name for something. For example, London is 'London' to a British person, but 'Londres' to a French person. This is what I was referring to in the second part of this sentence: Multiple names are really an issue for multilingual countries and for major features (typically large cities, rivers, and perhaps mountains) in monolingual countries, i.e. London may be London to an English person and Londres to a French person, but Stourport-on-Severn is Stourport-on-Severn to both of them (just picking a smallish town randomly; no potential slur intended). And a lot of names in OSM are street names; as far as I know, it's rare for people from another country to have different names for a country's streets. (I thought I had found one example, Via Devana as the Latin name for Huntingdon Road, Cambridge, but when I searched to check that, I found it's 18th-century Latin and not actually Roman.) I still think it's simple enough to have name=* to be the 'default' name you get if you don't specify a language, or the name you get if your selected language is not available. Agreed. __John ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC: Names localization
Richard Fairhurst wrote: *ahem* It's Llundain in one of Britain's two official languages. Two? You could make a case for both Irish and Ulster-Scots as well, based on the Anglo-Irish Agreement: http://www.nio.gov.uk/agreement.pdf :) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
