Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Wed, 26/8/09, Roy Wallace waldo000...@gmail.com wrote: Only if the lanes are marked as separate ways, which they normally wouldn't be for a narrow road. They should be, anything other than lanes=2 should be tagged properly, lanes=2 is implied as that is the usual case for most roads. A single lane piece of way should be tagged lanes=1 and it usually coincides with layer=1,bridge=yes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fw: Re: Wiki Spam
deleted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
wynndale at lavabit.com writes: The new Bad data proposal is a scheme to mark traced aerial photography or maps as out of date or otherwise unreliable so that they can be obscured in editors and users dont copy details into the OSM database reducing its accuracy. http://wiki.openstreetmap.org/wiki/Bad_data Hi, Instead of calling it Bad data I would say it inaccurate or outdated data. Map data traced from Yahoo imagery is better than no data at all. But some common schema for tagging the quality of mapped features would be useful. Or is there already some, in addition to using FIXME and source tags? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Wed, 26/8/09, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: Instead of calling it Bad data I would say it inaccurate or outdated data. Map data traced from Yahoo imagery is better than no data at all. But some common schema for tagging the quality of mapped features would be useful. Or is there already some, in addition to using FIXME and source tags? Anything tagged source=yahoo* or source=landsat should be treated worst than source=survey and people should source the data properly otherwise others will assume the data was traced if hi-res imagery is available. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
Hi, 2009/8/26 John Smith delta_foxt...@yahoo.com Anything tagged source=yahoo* or source=landsat should be treated worst than source=survey and people should source the data properly otherwise others will assume the data was traced if hi-res imagery is available. are you sure? What about really old survey and newest image from yahoo? :) It doesn't implied that yahoo is older then survey! -- S pozdravem/Best regards Bc. Ondrej Novy Email: n...@ondrej.org Jabber: on...@njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On 26/08/2009, at 1:38 PM, John Smith wrote: I agree, we need more tags to describe the railway crossing's feature set, boom_gate=no, lights=no etc, however this is a special case for stop signs because they will exist either side of the junction and never applies to the railway line. Unlike junctions of road traffic which needs to be differentiated from the way. This brings up an interesting question, when you're finding the nearest junction to use for stop key on a node, what counts as a junction? It's going to be a node which belongs to the current way and at least one other way satisfying certain conditions, but what are those conditions? If we are to use the stop key, I think those conditions will need to be explicitly spelt out, so that you can process the data. One obvious possibility would be ways that have highway=* tags - should footway/cycleway/path crossing count as junctions? If we're going to automagically determine which junction the Stop applies to, why do we even need a new key with yes/both/-1 values? Surely we could just say that if the existing highway=stop tag is applied to a node belonging to a single way (and not an intersection, which has the current meaning), then the Stop applies to traffic on the current way approaching the closest junction. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On 26/08/2009, at 1:10 AM, Lester Caine wrote: I think the point here is that of being able to see easily what has been applied to the data. Nodes and ways are easy to see, but this extra data is probably not so obvious as you would not know that a node ON the way actually has extra data, or perhaps that some other relation is involved? This is starting to head in the territory where it depends on what editor you're using, or what tool you use to visualise the data. I'd argue that is your chosen tool doesn't tell you when something is a member of a relation, it should be fixed :) Using Potlatch, a node in a way belonging to a relation is just as easy to notice (blue outline) as a node in a way which is marked with tags (black fill). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
On Wed, 26 Aug 2009, Ondrej Novy wrote: Anything tagged source=yahoo* or source=landsat should be treated worst than source=survey and people should source the data properly otherwise others will assume the data was traced if hi-res imagery is available. are you sure? What about really old survey and newest image from yahoo? :) It doesn't implied that yahoo is older then survey! we've had a lot of trouble in Au because group X decided that unmarked was landsat and they would mark survey, and group Y decided that unmarked was survey and they would mark landsat so we had no idea what was good and what was bad data. of course no one is going to own up to bad data could we simply extend source=survey with a year and source=landsat similarly? source=survey09 source=landsat_trace09 source=yahoo_trace08 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Wed, 26/8/09, Ondrej Novy n...@ondrej.org wrote: are you sure? What about really old survey and newest image from yahoo? :) It doesn't implied that yahoo is older then survey! New sat imagery isn't exactly new, Yahoo recently added hi-res imagery for an area near here, and the imagery must be at least a couple of years old as it doesn't show road works that took 18-24 months to complete. So even though it's new it's well out of date, maybe they got it cheap because it was out of date? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Wed, 26/8/09, James Livingston doc...@mac.com wrote: This brings up an interesting question, when you're finding the nearest junction to use for stop key on a node, what counts as a junction? It's going to be a node which belongs to the current way and at least one other way satisfying certain conditions, but what are those conditions? If we are to use the stop key, I think those conditions will need to be explicitly spelt out, so that you can process the data. Which is tagging for routing software, if you aren't supposed to tag for rendering software why should router software be different? Anything that needs to know which junction a stop sign applies to will know what junctions are what because they need to already for generating routing already. One obvious possibility would be ways that have highway=* tags - should footway/cycleway/path crossing count as junctions? These are usually before the junction, routing software usually should ignore these since cars can't go on foot paths, and cyclists/pedestrians have their own signage etc. If we're going to automagically determine which junction the Stop applies to, why do we even need a new key with yes/both/-1 values? Exactly. Surely we could just say that if the existing highway=stop tag is applied to a node belonging to a single way (and not an intersection, which has the current meaning), then the Stop applies to traffic on the current way approaching the closest junction. That's exactly what I've been saying :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Wed, 26/8/09, Liz ed...@billiau.net wrote: could we simply extend source=survey with a year and source=landsat similarly? source=survey09 source=landsat_trace09 source=yahoo_trace08 I'd seperate the information out into 2 key pairs: source=survey survey_date=20090826 or source=yahoo imagery_date=20070101 or just source:date=* ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
On 26/08/2009, at 7:31 PM, Liz wrote: we've had a lot of trouble in Au because group X decided that unmarked was landsat and they would mark survey, and group Y decided that unmarked was survey and they would mark landsat I take the approach that unmarked is landsat, yahoo, or something else that deserves to be checked/improved unless there is a public GPS trace. could we simply extend source=survey with a year and source=landsat similarly? source=survey09 source=landsat_trace09 source=yahoo_trace08 That sounds like a good plan. I was going to suggest source:date=*, but it seems that things that way around are already used by source:name to say where the name came from. It sounds backwards to me, but date:source? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
Ondrej Novy wrote: 2009/8/26 John Smith delta_foxt...@yahoo.com Anything tagged source=yahoo* or source=landsat should be treated worst than source=survey and people should source the data properly otherwise others will assume the data was traced if hi-res imagery is available. are you sure? What about really old survey and newest image from yahoo? :) It doesn't implied that yahoo is older then survey! There's also the issue of accuracy. I can only speak for the UK, but Yahoo pictures of most areas here are too low resolution to do anything useful with beyond saying that feature X exists, and it's within a hundred metres or so of here. It's better than nothing, but only just. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
On Wed, 26 Aug 2009, John Smith wrote: --- On Wed, 26/8/09, Liz ed...@billiau.net wrote: could we simply extend source=survey with a year and source=landsat similarly? source=survey09 source=landsat_trace09 source=yahoo_trace08 I'd seperate the information out into 2 key pairs: source=survey survey_date=20090826 or source=yahoo imagery_date=20070101 or just source:date=* some places i have been over so many times (like the road to canberra, the roads to adelaide, and the road to work) that the actual date is meaningless, but the last year i did the journey is we also can't date the satellite imagery accurately. for example landsat is supposedly the 7 year old set, but it is about 10 years old at home, judging from the dates of new housing estates ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New dimension of vandalism
There was a change on the highway key wiki page, that interferes with the concept presented here. http://wiki.openstreetmap.org/index.php?title=Key%3Ahighwaydiff=317630oldid=317451 User Dieterdreist has changed the description so the highway tag is no longer used for the objective physical description but for a subjective feeling of importance. Millions of highway tags would need to be reviewed if this change without proposal and approval would become valid. Two important aspect of routing, the estimation of time to arrival and finding the fastest route, will fail if the highway tag does not stick to physical facts. Several other established or proposed tags like maxspeed defaults are negatively affected by changing the highway concept of tagging. New OSM contributors learn bad practice from the start when the first tag they learn is switched from hard facts so unsure estimation. Probably new users have already done large damage to the map by mapping or changing highway tags from the facts to the feeling schema, resulting in worse quality of calculated routes. IMHO this is a new dimension of vandalism. I don't think that this is done by concurring commercial map providers, but this subtile method of weakening the OSM tagging schema and therefor lowering the quality of OSM data would be a really cool attack against OSM, because it is not possible to search for and revert such changes systematically. I think that we, the community, should not accept such severe changes made to extremely used and highly established without the proposal + approval workflow. I ask you to support the reverting of the unapproved changes in the wiki and in the mailing lists. I also think we need a consensus that tag descriptions for tags that are used more than 100.000 times shall not be changed without a proposal. Regards Lulu-Ann -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
On Wed, 26 Aug 2009, lulu-...@gmx.de wrote: I also think we need a consensus that tag descriptions for tags that are used more than 100.000 times shall not be changed without a proposal. Regards Lulu-Ann it needs something stronger than a proposal which is why earlier this month we discussed working parties ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
On Wed, Aug 26, 2009 at 12:23:22PM +0200, lulu-...@gmx.de wrote: User Dieterdreist has changed the description so the highway tag is no longer used for the objective physical description but for a subjective feeling of importance. [...] I ask you to support the reverting of the unapproved changes in the wiki and in the mailing lists. Count me in as supportive. When I'm using OSM data I want to be sure (well, as sure as you can get) that I'm using facts, and not some lazy person's interpretation of them. Well spotted. Cheers, -- Sybren Stüvel http://stuvel.eu/ http://www.flickr.com/photos/sybrenstuvel signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Wed, 26/8/09, Elizabeth Dodd ed...@billiau.net wrote: some places i have been over so many times (like the road to canberra, the roads to adelaide, and the road to work) that the actual date is meaningless, It's not meaningless, and if it changes just update the survey date. but the last year i did the journey is we also can't date the satellite imagery accurately. for example landsat is supposedly the 7 year old set, but it is about 10 years old at home, judging from the dates of new housing estates With google earth you can figure out the age of the imagery for a particular location, I've no idea if there is anything similar for yahoo imagery, but you could always estimate it: imagery_date:estimate=20070101 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Hi, lulu-...@gmx.de wrote: There was a change on the highway key wiki page, that interferes with the concept presented here. Have you read the following relevant thread on talk-de: http://lists.openstreetmap.org/pipermail/talk-de/2009-August/052258.html Since both you and dieterdreist are speakers of German, I'm surprised that you didn't speak up when the issue was raised on talk-de three weeks ago and now start a discussion on this list. IMHO this is a new dimension of vandalism. The acronym IMHO is not well placed if you throw around such accusations. What you're saying here is not a humble opinion. I also think we need a consensus that tag descriptions for tags that are used more than 100.000 times shall not be changed without a proposal. That seemed to be the consensus on talk-de as well (or at least without prior discussion, not necessarily on the Wiki - personally I dislike proposals, discussions and voting on the Wiki). Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
Why tag survey date on every single object? Why not give survey date when uploading a changeset, and then the 'history' window displayed by most OSM editors could show it. That way it won't get out of date if someone else comes along and makes a change but omits to carefully update 'source' on all the objects they changed; finding out which changesets have touched an object can be done automatically. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] State of the NameFinder
Hi! Congracts everyone with amount of input OSM recieves this year. Volunteers join us every day and changesets grow in detaility and quality. However, there is one set back and those are two things - mapnik render and NameFinder. While mapnik slowly gains additional renders for POIs and stuff, people can't find anything newer than January in NameFinder. I also think it is time to redesign it and make default version more good looking. Yes, I know, commercial vendors are here for selling services, but stil, as a geek, I contribute to OSM and want to use OSM slippy map. Anyway, so far I have heard about two efforts of getting NameFinder running again. First one is just performance improvement for old one (done by David Earl) and second one is completely new effort (by Twain). How far both projects are? Is there anything someone with moderate Linux/sysadmining/Python/Postgresql/whatever knowledge can help? Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
On Wed, 26 Aug 2009, Ed Avis wrote: Why tag survey date on every single object? Why not give survey date when uploading a changeset, and then the 'history' window displayed by most OSM editors could show it. That way it won't get out of date if someone else comes along and makes a change but omits to carefully update 'source' on all the objects they changed; finding out which changesets have touched an object can be done automatically. good idea ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Hi Frederik, lulu-...@gmx.de wrote: There was a change on the highway key wiki page, that interferes with the concept presented here. Have you read the following relevant thread on talk-de: http://lists.openstreetmap.org/pipermail/talk-de/2009-August/052258.html Since both you and dieterdreist are speakers of German, I'm surprised that you didn't speak up when the issue was raised on talk-de three weeks ago and now start a discussion on this list. That is because I, other than you, personally like the wiki better than the list. I have been talking with several people about it and they recommended to put the topic back on the list. Maybe late, but hopefully not too late. IMHO this is a new dimension of vandalism. The acronym IMHO is not well placed if you throw around such accusations. What you're saying here is not a humble opinion. I wanted to say that this is my opinion. Sorry if the abbreviation was not chosen to your satisfaction. I am not a native speaker. I also think we need a consensus that tag descriptions for tags that are used more than 100.000 times shall not be changed without a proposal. That seemed to be the consensus on talk-de as well (or at least without prior discussion, not necessarily on the Wiki - personally I dislike proposals, discussions and voting on the Wiki). I counted 4 pro votes on the talk list - I do not consider this to be commen consensus. As Dieterdreist wrote himself, he considers his changes as a proposal. All I demand is that it is treated as one, and people who only read rfc threads in this mailing list because of a lack of time have the chance to take notice. Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). Regards, Lulu-Ann -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
On 26/08/2009 12:44, Peteris Krisjanis wrote: Anyway, so far I have heard about two efforts of getting NameFinder running again. First one is just performance improvement for old one (done by David Earl) I have been trying to rebuild the index, but the first two attempts failed (well, the second worked but the changes meant it took an impracticably long time(*)). I was going to start a third attempt today (it's best to start on a Wednesday with a fresh planet file). Beyond getting the index updated using the existing technology, my next step is to try using postgres instead of mysql to (hopefully) increase the search speed (I use self-joins a lot and these should be faster in postgres; there may also be scope beyond that for replacing my low level word search algorithm with postgres' flexible free text searching but still retaining the multiple variations the system copes with at present). While the current index is January, that's from daily updates. The last time the index was completely reloaded was February 2008, so the amount of data has increased enormously since then, and that means everything takes a lot longer. David (*) I was trying InnoDB tables, but the overhead on these was tremendous, and the load process was taking order of magnitude longer. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
2009/8/26 Jonas Krückel o...@jonas-krueckel.de: Nestoria (Ed Freyfogle) also offered help for a new search/namefinder on SOTM. And Geocommons made their geocoding service open source. So maybe we should start a kind of working group who looks at all the offers and possibilities and then get one running. Maybe this could also be one topic for a hacking session on wherecampeu. I would join a working group, who else is interested? Me :) Have some nice expierence with server systems and would be nice to have such challenge to deal with. And ohhh, I would like to push OSM to next level, when all our contributed data are easily found by simple search string. Cheers, Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
On 26/08/2009 13:19, Peteris Krisjanis wrote: 2009/8/26 Jonas Krückel o...@jonas-krueckel.de: Nestoria (Ed Freyfogle) also offered help for a new search/namefinder on SOTM. And Geocommons made their geocoding service open source. So maybe we should start a kind of working group who looks at all the offers and possibilities and then get one running. Maybe this could also be one topic for a hacking session on wherecampeu. I would join a working group, who else is interested? Me :) Have some nice expierence with server systems and would be nice to have such challenge to deal with. And ohhh, I would like to push OSM to next level, when all our contributed data are easily found by simple search string. We set up a geocaching mailing list just after SOTM. We haven't had much traffic on it so far. Please feel free to join: http://lists.openstreetmap.org/listinfo/geocoding David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Wed, 26/8/09, Ed Avis e...@waniasset.com wrote: Why tag survey date on every single object? Why not give survey date when uploading a changeset, and then the 'history' window displayed by most OSM editors could show it. So until editors update to include that info you could use the changeset comment to do this... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Lulu-Ann wrote: User Dieterdreist has changed the description so the highway tag is no longer used for the objective physical description but for a subjective feeling of importance. Millions of highway tags would need to be reviewed if this change without proposal and approval would become valid. Dieterdreist isn't far from being right. Importance is what the highway tag was created for, and in fact that's more what Map Features originally said. Where I'd differ is that it's not a subjective feeling - it should be verifiable, often by reference to your country's highway system. Objective physical descriptions are good. But you shouldn't use the highway tag for them: that can't ever work. Combinations of physical attributes vary so wildly between countries that you'd end up with 200 different values for the highway tag. That would be a nightmare for renderers and routers to parse. Rather, you should add unambiguous physical tags like surface=, lanes=, that sort of thing. That way, those routers and renderers that need them can reliably parse the information. If your editor of choice doesn't make it easy to enter such tags, then nag the authors until it does (did I really say that? :) ). Fortunately, any edit war here shouldn't make any difference either way to how anyone maps, and there's no need for retagging. This is because the best authority for what highway value should I use? is, in fact, the International equivalence table on the wiki. This documents, at least in theory, the consensus within your country: for example, in the UK, we've had a settled set of definitions for several years now and they are summarised in the International equivalence table. You should map according to that. (Wiki Actually Useful Shock Horror!) cheers Richard -- View this message in context: http://www.nabble.com/New-dimension-of-vandalism-tp25150223p25151132.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Diary Spam, was: Wiki Spam
--- On Wed, 26/8/09, Erik Johansson e...@kth.se wrote: deleted There seems to be some diary spam too... http://www.openstreetmap.org/user/lararefaeli/diary/7668 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). But the point is that the users already have voted by the way they actually use the highway tag. What dieterdreist did was just change the wiki to match the reality, so that it is actually useful as a documentation. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
running again. First one is just performance improvement for old one (done by David Earl) and second one is completely new effort (by Twain). The one I've been working on (suggestions for a name for the project gratefully received off list BTW) is mostly functional. I was expecting to open it for testing on the geocoding list some time next week when it has finished indexing the most recent planet import however given the timing of this I've started an import of just a uk extract (which will take 3 to 4 hours to run assuming it all works first time) so people can have a quick preview. I'll post a URL to the list when it is complete. The main problem with the project, and reason it has been so slow, is the sheer size of the data. A complete test cycle for the whole planet data takes around a week assuming that nothing goes wrong and working on less than a country sized area is pointless because you don't get a true indication of performance. There is still considerable work to be done - the system doesn't just support diff updates, the code is very messy and in need of considerable cleaning up and there are a few known bugs with long strings running out of memory. I also want to move a lot more of the core search code into the database to make it less dependant on php. If people are keen it is possible that some of this work could be shared with other people. Cheers, -- Brian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
On 26/08/09 13:12, Jonas Krückel wrote: Nestoria (Ed Freyfogle) also offered help for a new search/namefinder on SOTM. And Geocommons made their geocoding service open source. So maybe we should start a kind of working group who looks at all the offers and possibilities and then get one running. Umm... Like the geocoding mailing list you mean? The one that was created after discussion with the interested parties at SOTM... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
On Wed, Aug 26, 2009 at 02:39:12PM +0200, Marc Schütz wrote: But the point is that the users already have voted by the way they actually use the highway tag. What dieterdreist did was just change the wiki to match the reality, so that it is actually useful as a documentation. The wiki should not only match the reality, it should suggest proper behaviour to (new) users. Text like If a section of road in the US looks like a motorway then it can be tagged as a motorway without researching its funding sources or driving up and down the road looking for an Interstate sign. to me suggests lazy tagging. In The Netherlands there are two types of motorway, autoweg (max speed = 100 km/h, could have same-level crossings) and snelweg (max speed = 120 km/h, no same-level crossings), which are quite difficult to discern without driving up to the entrance and checking the signs. However, they are sufficiently different that I think it's worth it to either tag it as highway=road and let someone else determine the proper tag or just to make sure what kind of road something is before it is tagged. Just my two €0,01 Sybren -- Sybren Stüvel http://stuvel.eu/ http://www.flickr.com/photos/sybrenstuvel signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Hi, lulu-...@gmx.de wrote: Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). I think that a discussion on the mailing list reaches more people than a proposal on the Wiki, so I don't see why the latter should be preferred ;-) Granted: talk-de is not the place to discuss stuff that is internationally relevant, even if the .de community makes 40% of all edits. But if ever people on talk should agree on something I don't think it is required to make a Wiki proposal as well. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
Am 26.08.2009 um 14:49 schrieb Tom Hughes t...@compton.nu: On 26/08/09 13:12, Jonas Krückel wrote: Nestoria (Ed Freyfogle) also offered help for a new search/namefinder on SOTM. And Geocommons made their geocoding service open source. So maybe we should start a kind of working group who looks at all the offers and possibilities and then get one running. Umm... Like the geocoding mailing list you mean? The one that was created after discussion with the interested parties at SOTM... Tom Yep, sorry, I don't know why i missed that list, David already gave me a hint know. I will subscribe asap. Jonas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
Hi, 2009/8/26 Peteris Krisjanis pec...@gmail.com: Anyway, so far I have heard about two efforts of getting NameFinder running again. First one is just performance improvement for old one (done by David Earl) and second one is completely new effort (by Twain). I started working on a different search engine for OSM but didn't have time to make it really work yet. I'll try to do it in the next week or two. The idea is a little different from the NameFinder in various aspects and it can search for all data in the database not only names. In some aspects it's dumber than NameFinder but it stresses being usable for non-latin alphabet searches, mixed alphabets, and nice presentation of the results. It indexes the planet file, which is a rather heavy task for my desktop but I think it would still be able to cope if the size of data in OSM grew up to about 10 times. The idea was also for it to be very cheap computationally and so that a search with N search terms takes exactly N reads of 1 sector from my harddisk, so N moves of the disk's head and I've not fully achieved this. (this is all how it was supposed to work, not how it will end up working) :) Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging vague, ill-defined, or unfriendly paths
I suppose this brings up all the stuff about path tagging again, but, how do people in general tag vague, ill-defined countryside paths? The sort of things I'm talking about are either very narrow and occasionally hard to follow paths through woods, or, firebreaks in forests where there is some evidence of foot use but there isn't a nice path as such. Generally I've been using width=narrow for such instances. However, that description not always accurate as sometimes the width of the way isn't narrow, it's more that it's an unfriendly path e.g. a firebreak covered in rough grass, or a churned-up mud track used perhaps more by logging vehicles than pedestrians. Nonetheless the way is open to pedestrians, and often horses, typically on a permissive basis. Because there are lots of these in the New Forest, near where I live, I'd like to come to a definitive conclusion on this so that rendering can distinguish between nice and not nice paths. Thanks, Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
Hi, Jonas Krückel wrote: Yep, sorry, I don't know why i missed that list, David already gave me a hint know. I will subscribe asap. I'm not on that list either (yet) so let me continue abusing talk: There's also an OpenSearch Suggestion Service by Wolfram Schneider wsc...@googlemail.com (done with OSM data for the bbbike project) here: http://bbbike.elsif.de/streets.html He says that it can easily be run for whole countries/continents. It is still somewhat beta (if I understood correctly, the largest problem is that it can currently only handle one same-named street per region but he's working on that). He says his software is open source in principle and he'll share the status quo if anyone is interested, otherwise he'll bring it into a better shape before releasing it. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Frederik wrote: I think that a discussion on the mailing list reaches more people than a proposal on the Wiki, so I don't see why the latter should be preferred ;-) The wiki workflow includes the talk list several time, for the rfc and for the start of voting, so the wiki process includes all users, the ones from the wiki and the ones on the mailing list. So you are surely wrong here. This could be extended by taking a field into the proposal template with the links to the talk archive on rfc and voting start. On the other hand the mailing list agreement (which did not exist in this case) usually does not reach the wiki readers. At least a link to the mailing list archive is needed on the tag's talk page *befor* any edits to the tag page are performed. The wiki has a great advantage in comparison with the mailing lists: You only watch the topics you are interested in, what is very helpful if you don't spend your fulltime job with OSM. ;-) Granted: talk-de is not the place to discuss stuff that is internationally relevant, even if the .de community makes 40% of all edits. But if ever people on talk should agree on something I don't think it is required to make a Wiki proposal as well. You can think so, but surely the wiki proposal process was not invented and established to be ignored by others. I know that many users give a dam about votings, but I think this will only provoke edit wars. In case of changing the rules for the usage of a well established tag, it will not only cause edit wars in the wiki, but also in the map! Mikel convinced me to take time and discuss this on the list, I hope we can convince mailinglist-only users to do the same and drop a line in the wiki befor doing important edits from time to time - Why not post the link to the mailing list archive?! Regards Lulu-Ann -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or unfriendly paths
I suppose this brings up all the stuff about path tagging again, but, how do people in general tag vague, ill-defined countryside paths? The sort of things I'm talking about are either very narrow and occasionally hard to follow paths through woods, or, firebreaks in forests where there is some evidence of foot use but there isn't a nice path as such. I use http://wiki.openstreetmap.org/wiki/Tag:highway=path/Examples and have concluded to use highway=path, wheelchair=no The first tag classifies the way as being an unpaved and small path while the second clarifies that you can't use it for anything on wheels. Cheers, Roland ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or unfriendly paths
I use http://wiki.openstreetmap.org/wiki/Tag:highway=path/Examples and have concluded to use highway=path, wheelchair=no The first tag classifies the way as being an unpaved and small path while the second clarifies that you can't use it for anything on wheels. Are you sure? http://wiki.openstreetmap.org/wiki/Key:wheelchair says nothing about anything on wheels. I don't think wheelchair is the right tag for this, as http://wiki.openstreetmap.org/wiki/Tag:highway=path does'nt say anything about it. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or unfriendly paths
Roland Olbricht wrote: I suppose this brings up all the stuff about path tagging again, but, how do people in general tag vague, ill-defined countryside paths? The sort of things I'm talking about are either very narrow and occasionally hard to follow paths through woods, or, firebreaks in forests where there is some evidence of foot use but there isn't a nice path as such. I use http://wiki.openstreetmap.org/wiki/Tag:highway=path/Examples and have concluded to use highway=path, wheelchair=no The first tag classifies the way as being an unpaved and small path Not quite, it just says that it's not accessible for vehicles with more than two wheels. It says nothing about the surface or how wide it is. while the second clarifies that you can't use it for anything on wheels. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or unfriendly paths
you may add a visibility tag, if it's rough terrain also sac_scale may apply http://wiki.openstreetmap.org/wiki/Key:trail_visibility On 26 Aug 2009, at 7:25 , Nick Whitelegg wrote: I suppose this brings up all the stuff about path tagging again, but, how do people in general tag vague, ill-defined countryside paths? The sort of things I'm talking about are either very narrow and occasionally hard to follow paths through woods, or, firebreaks in forests where there is some evidence of foot use but there isn't a nice path as such. Generally I've been using width=narrow for such instances. However, that description not always accurate as sometimes the width of the way isn't narrow, it's more that it's an unfriendly path e.g. a firebreak covered in rough grass, or a churned-up mud track used perhaps more by logging vehicles than pedestrians. Nonetheless the way is open to pedestrians, and often horses, typically on a permissive basis. Because there are lots of these in the New Forest, near where I live, I'd like to come to a definitive conclusion on this so that rendering can distinguish between nice and not nice paths. Thanks, Nick ___ 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] New dimension of vandalism
The wiki should not only match the reality, it should suggest proper behaviour to (new) users. Text like If a section of road in the US looks like a motorway then it can be tagged as a motorway without researching its funding sources or driving up and down the road looking for an Interstate sign. to me suggests lazy tagging. No, that's the way OSM works. Knowledge of local users count's more than signs - at least as far as I understood it. In The Netherlands there are two types of motorway, autoweg (max speed = 100 km/h, could have same-level crossings) and snelweg (max speed = 120 km/h, no same-level crossings), which are quite difficult to discern without driving up to the entrance and checking the signs. However, they are sufficiently different that I think it's worth it to either tag it as highway=road and let someone else determine the proper tag or just to make sure what kind of road something is before it is tagged. In my opinion the value of the highway-tag is determind by the importance of the road as seen from a local user. If the autoweg is much more important in a place as a snelweg nearby, it should be tagged higher, regardless of any signs. You are free to add a maxspeed with 100/120 if you want to. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
Le mercredi 26 août 2009 à 09:56, John Smith a écrit : Anything tagged source=yahoo* or source=landsat should be treated worst than source=survey and people should source the data properly otherwise others will assume the data was traced if hi-res imagery is available. What does survey mean? The page http://wiki.openstreetmap.org/wiki/Key:source doesn't list that value. -- Renaud Michel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] avp2wpt : audio/photo mapping utility
I just made this tool that I think can help for audio/photo mapping : It parses a gpx trace, scans a folder for audio/photo (and why not video) files, and creates waypoints accordingly. I have been looking for such a tool, and thought I would do it myself, since I couldnt find one. I decided to learn java, so that more people can use it (I used vb.net before). You can find it at http://www.tilt-services.com/batchtoys/avp2wpt/ I'll be glad if some find it useful to help the map. Gilles ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
--- On Thu, 27/8/09, Renaud MICHEL r.h.michel+...@gmail.com wrote: What does survey mean? The page http://wiki.openstreetmap.org/wiki/Key:source doesn't list that value. http://wiki.openstreetmap.org/wiki/Map_Features#Annotation ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
2009/8/26 Peter Körner osm-li...@mazdermind.de: The wiki should not only match the reality, it should suggest proper behaviour to (new) users. Text like If a section of road in the US looks like a motorway then it can be tagged as a motorway without researching its funding sources or driving up and down the road looking for an Interstate sign. to me suggests lazy tagging. No, that's the way OSM works. Knowledge of local users count's more than signs - at least as far as I understood it. In The Netherlands there are two types of motorway, autoweg (max speed = 100 km/h, could have same-level crossings) and snelweg (max speed = 120 km/h, no same-level crossings), which are quite difficult to discern without driving up to the entrance and checking the signs. However, they are sufficiently different that I think it's worth it to either tag it as highway=road and let someone else determine the proper tag or just to make sure what kind of road something is before it is tagged. In my opinion the value of the highway-tag is determind by the importance of the road as seen from a local user. If the autoweg is much more important in a place as a snelweg nearby, it should be tagged higher, regardless of any signs. You are free to add a maxspeed with 100/120 if you want to. Peter Agreed. The French state declassified a lot of national roads (routes nationales) in the last few years because they were not state funded anymore. So the N89 for example became the D 2089 (D is for departmental roads) but it is still a much more important road that all the D roads around it. The D 2089 is still tagged as primary and all the other original D roads around are highway=secondary. Doing otherwise would have been an error in my view. I guess that the highway tag used to describe physical features of different types of roads back when OSM was quite UK-centric. But it's not anymore and tying the meaning of the highway tag to physical features would just make it impossible to use widely. Renaud. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Renaud Martinet wrote: I guess that the highway tag used to describe physical features of different types of roads back when OSM was quite UK-centric. Nope - UK highway tagging, which was of course the original, has always largely been aligned to administrative classifications. highway=motorway - UK motorway (Mx or Ax(M)) highway=trunk - UK primary A-road (Ax with green signs) highway=primary - UK non-primary A-road - yes, really (Ax with black/white signs) highway=secondary - UK B-road (Bx) We do have a super special, very rarely used exemption known as the Oxford High Street Exemption, though. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or unfriendly paths
On 08/26/2009 10:19 AM, Roland Olbricht wrote: I use http://wiki.openstreetmap.org/wiki/Tag:highway=path/Examples and have concluded to use highway=path, wheelchair=no The first tag classifies the way as being an unpaved and small path... It does nothing of the sort. unpaved would require surface=unpaved/dirt/mud/etc., while small would require the width tag, I think. -Alex Mauer hawke signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
There seem to be three issues here: 1. Vandalism - perhaps we'd have a better discussion without the emotive language. 2. Wiki vs mailing list: I use both - but the mailing list appears automatically in my in-tray every day and gets read whenever I have time to log on; the wiki seems to need me to watch a particular page and, simple person that I am, I haven't found out how to get changes notified to me - probably missed a 'watch this page' link or something! Whichever one prefers, common courtesy perhaps dictates that before making major changes to the wiki a check is also made with the mailing list community - overlapping but not identical. 3. Highway tag: I won't reopen the very long and intense discussion we've had in the last 2-3 weeks on the mailing list (during which many of us probably concluded that the subject was so complex and important that it would be a breach of netiquette to make major edits to the wiki until the discussion had gelled a bit more. The suggestion of a working group was a good one that got some support - and then faded away into cyberspace - pity. For the present I will stick to the concept that highway= is essentially a tag to describe the physical characteristics of the way (and remember it applies to ways other than roads - where it is perhaps very important for other reasons than routing). There are other tags (probably too many of them!) to describe usability, access rights, legal standing etc. ... and finally - a tag that is largely subjective is likely to lead to more problems and conflict than one that is largely objective - and this suggests we should avoid words (in any language) that are largely subjective (especially when translated). IMHO (and remember that 'humble' can be a descriptor of the quality of the opinion - like 'humble abode' - as much as the attitude of the writer! - so there's no need to take this all too seriously (;)) ... let's stay civil and objective! Mike Harris -Original Message- From: Frederic Ramm [mailto:frede...@remote.org] Sent: 26 August 2009 14:10 To: lulu-...@gmx.de Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] New dimension of vandalism Hi, lulu-...@gmx.de wrote: Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). I think that a discussion on the mailing list reaches more people than a proposal on the Wiki, so I don't see why the latter should be preferred ;-) Granted: talk-de is not the place to discuss stuff that is internationally relevant, even if the .de community makes 40% of all edits. But if ever people on talk should agree on something I don't think it is required to make a Wiki proposal as well. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
Thanks Mike, wise council. What I think we have here is a disagreement, a deep seated discussion which has been taking place over the entire history of the project, and in many forums. IMO, the wiki should reflect the current collective thinking. If the collective thinking is in disagreement, then the wiki should show both sides, equally, with _respectful_ disagreement. Certainly a proposal can be worked out, and discussion can lead towards a practical solution satisfactory to all, just like we always do it! Whatever historically the Tag:Highway page has recommended should continue to be the main recommendation, for the time being. Discussion on changes can take place in the Talk page, and in separate proposals. Tag:Highway can give a general description of the discussion, with a link to other proposals. How does that sound? Best Mikel - Original Message From: Mike Harris mik...@googlemail.com To: Frederik Ramm frede...@remote.org; lulu-...@gmx.de Cc: talk@openstreetmap.org Sent: Wednesday, August 26, 2009 11:16:56 AM Subject: Re: [OSM-talk] New dimension of vandalism There seem to be three issues here: 1. Vandalism - perhaps we'd have a better discussion without the emotive language. 2. Wiki vs mailing list: I use both - but the mailing list appears automatically in my in-tray every day and gets read whenever I have time to log on; the wiki seems to need me to watch a particular page and, simple person that I am, I haven't found out how to get changes notified to me - probably missed a 'watch this page' link or something! Whichever one prefers, common courtesy perhaps dictates that before making major changes to the wiki a check is also made with the mailing list community - overlapping but not identical. 3. Highway tag: I won't reopen the very long and intense discussion we've had in the last 2-3 weeks on the mailing list (during which many of us probably concluded that the subject was so complex and important that it would be a breach of netiquette to make major edits to the wiki until the discussion had gelled a bit more. The suggestion of a working group was a good one that got some support - and then faded away into cyberspace - pity. For the present I will stick to the concept that highway= is essentially a tag to describe the physical characteristics of the way (and remember it applies to ways other than roads - where it is perhaps very important for other reasons than routing). There are other tags (probably too many of them!) to describe usability, access rights, legal standing etc. ... and finally - a tag that is largely subjective is likely to lead to more problems and conflict than one that is largely objective - and this suggests we should avoid words (in any language) that are largely subjective (especially when translated). IMHO (and remember that 'humble' can be a descriptor of the quality of the opinion - like 'humble abode' - as much as the attitude of the writer! - so there's no need to take this all too seriously (;)) ... let's stay civil and objective! Mike Harris -Original Message- From: Frederic Ramm [mailto:frede...@remote.org] Sent: 26 August 2009 14:10 To: lulu-...@gmx.de Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] New dimension of vandalism Hi, lulu-...@gmx.de wrote: Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). I think that a discussion on the mailing list reaches more people than a proposal on the Wiki, so I don't see why the latter should be preferred ;-) Granted: talk-de is not the place to discuss stuff that is internationally relevant, even if the .de community makes 40% of all edits. But if ever people on talk should agree on something I don't think it is required to make a Wiki proposal as well. Bye Frederik ___ 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] [tagging] Feature Proposal - RFC - incline up down
2009/8/25 Mike Harris mik...@googlemail.com: I just tried to apply the 'architects' convention' of steps 'always' being from bottom to top. Then for unrelated reasons I reversed the way. Unlike 'oneway' this does not reverse the direction of the steps - i.e. the software doesn't know about the architects' convention. So I have to conclude that - at present at least - the assumption of an implicit sense is risky. yes, I know it is risky. I wanted to write this convention to the wiki some time ago, but then a discussion on talk-de started, why it could be more natural/logical to do it the other way round, and in the end no conclusion could be achieved. It is just a convention, all architects know about it. It has IMHO nothing to do with logics or nature. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Is this OSM map used in an advertisement?
Hello, I have seen an advertisement on german website mobile.de I made a screenshot: http://imgur.com/Rej1m Is the map on background from OSM? Ali ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [voting] geological=palaeontological_site
Deal all, voting is opened: http://wiki.openstreetmap.org/wiki/Proposed_features/geological=palaeontolog ical_site Best regards Marcello B. Proposal-RFC Start: 2009-08-12 http://lists.openstreetmap.org/pipermail/talk/2009-August/040238.html Vote-Start: 2009-08-27 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
2009/8/26 lulu-...@gmx.de: Hi Lulu, I'm happy that you finally put your edits to this list. Actually before I was changing the page I was trying to involve as many contributors as possible. I not only posted on talk but also on talk-de and also on talk-it there was a note about this discussion. Therefore I think that vandalism is not really adequat. After some time of discussion I was pointing out on the list (referring also to the diff) that I changed the page. It was not hidden, but announced (many changes in the wiki do neither follow voting nor are announced to the lists). Besides this, the German highway-definition already stated the tagging according to importance. Please also note, that physical state is not absolute but highly relative to the surrounding/context, and that it didn't work neither (there was the need for exceptions). There was a change on the highway key wiki page, that interferes with the concept presented here. http://wiki.openstreetmap.org/index.php?title=Key%3Ahighwaydiff=317630oldid=317451 User Dieterdreist has changed the description so the highway tag is no longer used for the objective physical description but for a subjective feeling of importance. Millions of highway tags would need to be reviewed if this change without proposal and approval would become valid. come on, they don't have to be reviewed, because a) this is already common practise b) people refer more to the specific definition than to the general one. Two important aspect of routing, the estimation of time to arrival and finding the fastest route, will fail if the highway tag does not stick to physical facts. No, I could say the contrary. Several other established or proposed tags like maxspeed defaults are negatively affected by changing the highway concept of tagging. No. It seems you didn't look at the changes. AFAIK maxspeed defaults are about in town and out-of-town and (in Germany) about dual-carriageways and motorways. They are all not affected. New OSM contributors learn bad practice from the start when the first tag they learn is switched from hard facts so unsure estimation. Well, it was after an open discussion. What do you mean by hard facts? I added a reference to physical tags (width, lanes, surface) to the page that was missing before. In which way do physical facts help you to classify a road? Is a unsurfaced road always a track? Is a road with 4 lanes always a primary road? Probably new users have already done large damage to the map by mapping or changing highway tags from the facts to the feeling schema, resulting in worse quality of calculated routes. please. I didn't change a single specific tag and adjusted the main vague definition to common practise, you are not only exagerating, you are IMHO completely wrong. IMHO this is a new dimension of vandalism. I don't think that this is done by concurring commercial map providers, but this subtile method of weakening the OSM tagging schema and therefor lowering the quality of OSM data would be a really cool attack against OSM, because it is not possible to search for and revert such changes systematically. Personally I see it contrary. I think that we, the community, should not accept such severe changes made to extremely used and highly established without the proposal + approval workflow. I ask you to support the reverting of the unapproved changes in the wiki and in the mailing lists. Did you set up a proposal to do so, that I can vote about? I also think we need a consensus that tag descriptions for tags that are used more than 100.000 times shall not be changed without a proposal. OK, I agree (and I would set the limit not to 10 but maybe 2000). But I am not sure, if the wiki is a better place than the mailing-lists to do so. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
2009/8/26 Mikel Maron mikel_ma...@yahoo.com: Whatever historically the Tag:Highway page has recommended should continue to be the main recommendation, for the time being. Discussion on changes can take place in the Talk page, and in separate proposals. Tag:Highway can give a general description of the discussion, with a link to other proposals. what do you mean by historically? The situation before physical was introduced? The situation in 2005? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GSoC End: signFinder
On Wed, Aug 19, 2009 at 3:44 PM, Martin Koppenhoeferdieterdre...@gmail.com wrote: In Italy (at least in Rome) they are often engraved marble plates. Standard signs in italy are supposed to be black on white with a thin blue border, but there are still lots of old marble plates and even names painted on the walls. -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Wed, Aug 26, 2009 at 7:22 PM, James Livingstondoc...@mac.com wrote: On 26/08/2009, at 1:38 PM, John Smith wrote: This brings up an interesting question, when you're finding the nearest junction to use for stop key on a node, what counts as a junction? It's going to be a node which belongs to the current way and at least one other way satisfying certain conditions, but what are those conditions? If we are to use the stop key, I think those conditions will need to be explicitly spelt out, so that you can process the data. It would have to be ANY junction, I think (the nearest node that belongs to more than one way, as you say). There should be as little dependence on other tags as possible. Otherwise - a maintenance nightmare... If we're going to automagically determine which junction the Stop applies to, why do we even need a new key with yes/both/-1 values? Surely we could just say that if the existing highway=stop tag is applied to a node belonging to a single way (and not an intersection, which has the current meaning), then the Stop applies to traffic on the current way approaching the closest junction. I thought that was what we were talking about already. Remember there's three options. 1) your description above, which John seems to like 2) http://wiki.openstreetmap.org/wiki/Key:stop 3) http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
2009/8/26 lulu-...@gmx.de: I counted 4 pro votes on the talk list - I do not consider this to be commen consensus. As Dieterdreist wrote himself, he considers his changes as a proposal. and there were no (0) Con-votes. There is (till now) no formal procedure to change the definition of a Key, all documented procedures are about proposing features (k/v). If you support a voting on the wiki about this, why don't _you_ write a formal proposal for the revert, instead of reverting silently and with no note to anybody? If I hadn't spotted your undo the day after, all efforts in the discussions on the lists would maybe have been without visible effect to the wiki. I did an undo to your undo. Please write a proposal to undo. Please note: there are roughly 130 edits to this page, and none of them was ever voted upon. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Wed, Aug 26, 2009 at 7:31 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Wed, 26/8/09, James Livingston doc...@mac.com wrote: If we are to use the stop key, I think those conditions will need to be explicitly spelt out, so that you can process the data. Which is tagging for routing software, if you aren't supposed to tag for rendering software why should router software be different? I can't see why you keep bringing up tagging for routing software. We need to model the world. We need to define the meaning of the tags we use, *explicitly* (need I remind you of the path/footway/cycleway debacle?). That's all James is saying. A *side effect* is that it is able to be processed. Anything that needs to know which junction a stop sign applies to will know what junctions are what because they need to already for generating routing already. Knowing what junctions are what is not the same as knowing which junction a stop sign applies to. I don't see why you think this shouldn't be defined explicitly... Please let us know your definition, if you have one. You also seem to be saying that routing software should work out *for itself* which junction the stop sign applies to. I disagree - the mapper on the ground should be able to enter this information in the database. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is this OSM map used in an advertisement?
El Miércoles, 26 de Agosto de 2009, Alilo escribió: Hello, I have seen an advertisement on german website mobile.de I made a screenshot: http://imgur.com/Rej1m Is the map on background from OSM? Yep, it looks perfectly like a screenshot of the mapnik rendering at zoom level 6. I think the company behing the advertisement should know about the OSMF knowing about this, just in case. I don't think that an advertisement is a big deal for the attribution of OSM data, but it's enough to get in touch. -- -- Iván Sánchez Ortega i...@sanchezortega.es http://ivan.sanchezortega.es MSN:i_eat_s_p_a_m_for_breakf...@hotmail.com Jabber:ivansanc...@jabber.org ; ivansanc...@kdetalk.net IRC: ivansanchez @ OFTC freenode signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the NameFinder
The one I've been working on (suggestions for a name for the project gratefully received off list BTW) is mostly functional. I was expecting to open it for testing on the geocoding list some time next week when it has finished indexing the most recent planet import however given the timing of this I've started an import of just a uk extract (which will take 3 to 4 hours to run assuming it all works first time) so people can have a quick preview. I'll post a URL to the list when it is complete. As promised, you can try a uk test system here: http://katie.openstreetmap.org/~twain/ And a couple of sample queries: http://katie.openstreetmap.org/~twain/?q=london http://katie.openstreetmap.org/~twain/?q=91+upper+ground%2C+london http://katie.openstreetmap.org/~twain/?q=pub+near+upper+ground%2C+london If you want to know how the address was created click the 'details' link at the end of the search result. Some of the values are my debug info but it will also provide links to the osm node/way/relation. Please be aware that this extract is about 4 weeks old and there have been quite a bit of improvements to the UK county data since then. Please email me bug reports off list, but be aware that I'm going to be away from my email for a lot of the weekend and that there are still known issues - so don't be that surprised if you break it. -- Brian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is this OSM map used in an advertisement?
2009/8/26 Iván Sánchez Ortega i...@sanchezortega.es: El Miércoles, 26 de Agosto de 2009, Alilo escribió: Hello, I have seen an advertisement on german website mobile.de I made a screenshot: http://imgur.com/Rej1m Is the map on background from OSM? Yep, it looks perfectly like a screenshot of the mapnik rendering at zoom level 6. I think the company behing the advertisement should know about the OSMF knowing about this, just in case. I don't think that an advertisement is a big deal for the attribution of OSM data, but it's enough to get in touch. Looks like the company behind is ebay (since 2004), so I'd say it is a big deal ;-), they should have attributed correctly. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New proposal: Bad data
2009/8/26 James Livingston doc...@mac.com: On 26/08/2009, at 7:31 PM, Liz wrote: we've had a lot of trouble in Au because group X decided that unmarked was landsat and they would mark survey, and group Y decided that unmarked was survey and they would mark landsat I take the approach that unmarked is landsat, yahoo, or something else that deserves to be checked/improved unless there is a public GPS trace. I'd say the only thing you know for sure is that the source is unknown unless it is explicitly tagged. I wouldn't assume anything besides that. There are people who don't upload their traces (i personally always do) and who have all rights to not do it. could we simply extend source=survey with a year and source=landsat similarly? source=survey09 source=landsat_trace09 source=yahoo_trace08 That sounds like a good plan. you can easily get this information by looking at the history (or even render a custom map to display the age), but feel free to add it ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
I thought we already discussed here on the talk mailing list a few weeks ago that highway=* is usually based on road importance in most countries? I know that that the change to the wiki was even announced here. So I'm quite surprised by the delayed contrary reaction. On Thu, Aug 27, 2009 at 5:53 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/8/26 lulu-...@gmx.de: I counted 4 pro votes on the talk list - I do not consider this to be commen consensus. As Dieterdreist wrote himself, he considers his changes as a proposal. and there were no (0) Con-votes. There is (till now) no formal procedure to change the definition of a Key, all documented procedures are about proposing features (k/v). If you support a voting on the wiki about this, why don't _you_ write a formal proposal for the revert, instead of reverting silently and with no note to anybody? If I hadn't spotted your undo the day after, all efforts in the discussions on the lists would maybe have been without visible effect to the wiki. I did an undo to your undo. Please write a proposal to undo. Please note: there are roughly 130 edits to this page, and none of them was ever voted upon. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- http://vaes9.codedgraphic.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
From: Martin Koppenhoefer dieterdre...@gmail.com 2009/8/26 Mikel Maron mikel_ma...@yahoo.com: Whatever historically the Tag:Highway page has recommended should continue to be the main recommendation, for the time being. Discussion on changes can take place in the Talk page, and in separate proposals. Tag:Highway can give a general description of the discussion, with a link to other proposals. what do you mean by historically? The situation before physical was introduced? The situation in 2005? Your change earlier this month was pretty substantial. It changed meanings on the page which have persisted for at least 1.5 years. http://wiki.openstreetmap.org/index.php?title=Key%3Ahighwaydiff=315699oldid=92681 Personally, I'm not partial to either side of the argument, but willing to work with whatever the consensus is. But I'm not sure there is yet a consensus here, beyond what has existed on this page prior to this month's discussion. My opinion, the best way to move this discussion forward is by taking the controversial topics into the Talk page, proposals, and note the disagreement on the Highway page. Make sense? Mikel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: You also seem to be saying that routing software should work out *for itself* which junction the stop sign applies to. I disagree - the mapper on the ground should be able to enter this information in the database. Then we should add is_in tags to every node and every way and every relation to show what is where so software doesn't need to guess which boundary applies to which node, way, relation. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Thu, Aug 27, 2009 at 1:15 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: You also seem to be saying that routing software should work out *for itself* which junction the stop sign applies to. I disagree - the mapper on the ground should be able to enter this information in the database. Then we should add is_in tags to every node and every way and every relation to show what is where so software doesn't need to guess which boundary applies to which node, way, relation. There are two important differences: 1) The meaning of a particular way or node is separate from the value of is_in. On the other hand, the meaning of a requirement to stop is NOT separate from knowledge of the junction to which it applies. 2) ANY kind of way/node could be marked with is_in. On the other hand, marking the junction to which a requirement to stop applies is only relevant to that particular requirement to stop. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: There are two important differences: 1) The meaning of a particular way or node is separate from the value of is_in. On the other hand, the meaning of a requirement to stop is NOT separate from knowledge of the junction to which it applies. I fail to see the difference, they are all distance based calculations. 2) ANY kind of way/node could be marked with is_in. On the other hand, marking the junction to which a requirement to stop applies is only relevant to that particular requirement to stop. And marking all nodes, ways and relations with is_in is relevant to where in the world that node, way or relation is, it's a non-nonsensical argument that just isn't true. Besides why should you care about needing this explicit information, if it's rendered you will see a sign, you will also see the nearest junction and your mind can put 2 and 2 together. A computer can do the exact same thing. This is why I keep saying this is tagging for software, you are explicitly tagging for software to know which junction the stop sign applies to, where as just like you it can see a junction and it can see a stop sign and it will know that the stop sign applies to that junction. So if we can't tag for rendering we aren't allowed to tag for routing software either. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Thu, Aug 27, 2009 at 2:06 PM, John Smithdelta_foxt...@yahoo.com wrote: Besides why should you care about needing this explicit information, if it's rendered you will see a sign, you will also see the nearest junction and your mind can put 2 and 2 together. A computer can do the exact same thing. You're asking why should we tag things explicitly? Because we're building a database. A huge, complex database that's used by lots of different people and software all over the world. And as I've said before, fudging a solution always seems like a great idea at the time (e.g. oh, this'll do the job, it's easier, and it's good enough - why bother doing it properly/explicitly) - until it breaks due to unforeseen circumstances. This is why I keep saying this is tagging for software, you are explicitly tagging for software to know which junction the stop sign applies to, where as just like you it can see a junction and it can see a stop sign and it will know that the stop sign applies to that junction. So if we can't tag for rendering we aren't allowed to tag for routing software either. Please listen to me. A requirement to stop *intrinsically involves a way AND an intersection*. A requirement to stop **IS** an interaction between a way AND an intersection. This is why I would suggest using a relation. Not because a relation is easier for software, but because a relation describes the **nature** of the thing to be described. But hey, I'll go along with the majority in whatever's decided. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: You're asking why should we tag things explicitly? Because we're building a database. A huge, complex database that's used by lots of That's just a straw man argument, you keep building the same thing up again and again but it keeps blowing away the first sign of a logical argument. Besides, I asked you personally why you cared, why do you care, or how will it benefit you personally how a stop sign is marked? Unless you can answer that question logically without all the hand waving and implications about how there might be a problem, you really don't have a good argument. different people and software all over the world. And as I've said before, fudging a solution always seems like a great idea at the time (e.g. oh, this'll do the job, it's easier, and it's good enough - why bother doing it properly/explicitly) - until it breaks due to unforeseen circumstances. Utter hand waving and doom and gloom. I'm yet to see any situation that tagging roads properly, eg number of lanes, and tagging a single node will fail. Please provide a valid example of a situation where a proximity based searching will fail. Please listen to me. A requirement to stop *intrinsically No you listen to me and stop trying to envoke emotive arguments when you have no rational or logical ones to back your position. involves a way AND an intersection*. A requirement to stop **IS** an interaction between a way AND an intersection. This is why I would suggest using a relation. Not because a relation is easier for software, but because a relation describes the **nature** of the thing to be described. Utterly useless hand waving about doom and gloom, but absolutely no substance either. But hey, I'll go along with the majority in whatever's decided. Yet another straw man argument that has no basis in fact or logic because you seem to be siding with a vocal minority, the majority has never spoken on such issues. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Thu, Aug 27, 2009 at 3:14 PM, John Smithdelta_foxt...@yahoo.com wrote: --- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: Besides, I asked you personally why you cared, why do you care, or how will it benefit you personally how a stop sign is marked? My apologies, I misinterpreted your question why should you care about needing this explicit information. To answer your question, I do not care personally. It will not benefit me personally whatsoever how a stop sign is marked. I'm just trying to contribute to OSM into the long-term future. I'm yet to see any situation that tagging roads properly, eg number of lanes, and tagging a single node will fail. Please provide a valid example of a situation where a proximity based searching will fail. I cannot. I can only contribute some hand waving and warn of unforeseen circumstances, and advocate tagging things explicitly - if you don't see any value in that, feel free to ignore it. Don't forget - I actually think the method you're suggesting is not too bad. If using a proximity search, it will be necessary to clearly define nearest junction, though. And if a way travels through an intersection but has stop signs on both sides, it will need to be split and two stop nodes will need to be added. There may be issues like this that need sorting out that only arise when a full proposal is written up and/or it's in use. But no, I can't think of any fail examples right now. No you listen to me and stop trying to envoke emotive arguments when you have no rational or logical ones to back your position. Sorry if I've offended you. I believe I understand and respect your position but it appears I'm not stating mine clearly enough. Apologies. And feel free to ignore my input where you think it is irrational and/or illogical. Yet another straw man argument that has no basis in fact or logic because you seem to be siding with a vocal minority, the majority has never spoken on such issues. I'm not siding with anyone, just contributing my thoughts. I too look forward to hearing from everyone else :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Thu, 27/8/09, Roy Wallace waldo000...@gmail.com wrote: My apologies, I misinterpreted your question why should you care about needing this explicit information. To answer your question, I do not care personally. It will not benefit me personally whatsoever how a stop sign is marked. I'm just trying to contribute to OSM into the long-term future. Ok, so your goal is to contribute to OSM in a meaningful way, that's fair enough but lets not get emotive over an issue but look at the logical outcome from simplest to most complex and test if they fail at all to address the issue, we shouldn't just pick the most complex for the sake of it because it might be more extensible than a simpler answer, which is only useful if that extensibility is actually useful. I cannot. I can only contribute some hand waving and warn of I don't have a problem with playing devils advocate, but to conduct these things rationally and logically we need conditions to test against, if we can't find a test that fails than it's a valid solution. If using a proximity search, it will be necessary to clearly define nearest junction, though. And if a way travels through an intersection but has stop signs on both sides, it will need to be split and two stop nodes will need to be added. There may be issues like this that need sorting out that only arise when a full proposal is written up and/or it's in use. But no, I can't think of any fail examples right now. That's just it, there is no need to split the way, you just put a stop sign node either side of the junction, or on 3, 4 or more ways that intersect with applicable stop sign nodes. Any software needing to know junctions will already have this coded. Then it's just a case of applying a proximity search when it parses stop signs to know which junction a stop sign applies to. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Tentative data source - Sunshine Coast Council
2009/8/26 Jeff Price jeff.pr...@rocketmail.com: The council are also interested in correcting errors in their own data given that today they are largely corrected via public complaints and subsequent site surveys. If someone has some wizzy ideas on how to determine the difference between the datasets then you'd have some happy council campers. A while ago (late last year, early this year?) a group in Germany did something like this, where they checked all the data on a completed area (I'm thinking Munich, but I may be wrong) against some standard database. Then they doublechecked all the differences to make sure they were real, and gave the resulting list back to the council. It was talked about on the talk list. I think they were checking roads existence and naming, rather than the actual shape, but I could be wrong. If we can find that, I'm sure those involved would be happy to give us some pointers on how they did it. Stephen ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Navteq mapping AU
Probably been looking at the quality of the OSM data... http://www.theage.com.au/digital-life/cartech/mapping-australia-one-road-at-a-time-20090825-extj.html ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
On Wed, 26 Aug 2009, Cosmic Charade wrote: OSM however is stalling woefully on my humble 2GB Atom powered Ubuntu netbook. Has anyone had any success with JOSM on such a platform? yes, but I use debian and xfce as desktop. however the screen is so small you need to learn about fullscreen, the keyboard shortcuts and see the optometrist as well ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Navteq mapping AU
--- On Wed, 26/8/09, 80n 80n...@gmail.com wrote: I've RTFA ;) They aren't going to do all rural and remote towns like this, just cities. If they do do all rural/remote towns it will cost a lot of money and take a lot of time and effort and I don't see a commercial justification for it. I also doubt they are going to do hiking trails, everything they're planning to do in city areas is already done on OSM for the most part. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Navteq mapping AU
On 26/08/2009, at 7:44 PM, John Smith wrote: One example given was do you search on google to rent a house, generally no one does, they use a specialist search engine that is built for rent listings. That reminds me of something I was wishing for a couple of months ago, trying to find a rental place after moving to Brisbane - one of those web sites that made better use of geodata. Some of the good ones will shop you a map with a house icon for each property that is for rent/ sale, but a lot don't do even that. What I really wanted was a site that would do the above, and also tell me how long it would take to talk to the nearest public transport, catch it, and walk to my work at the other end[0]. Plus where the nearest shops were, if there were any parks or sports facilities nearby and so on. Now, if only I had a freely available source of data for something like that... I guess I should probably shut up and actually do something about it, although it probably wouldn't work to well without decent house number data. [0] Copying and pasting the address into the Translink web site gets tiring after a while. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Navteq mapping AU
In Switzerland they have a site called http://www.search.ch even though most of it is only available in German or French, like the wikipedia or weather integration. The real-estate map is great but they have not been able to get all the local companies to use their service. http://immo.search.ch/ maybe because of the cost? Public transport timetable information is great, even works from each bus- stop, just hover over a stop and see the information pop-up. On Wednesday 26 Aug 2009 12:13:18 James Livingston wrote: On 26/08/2009, at 7:44 PM, John Smith wrote: One example given was do you search on google to rent a house, generally no one does, they use a specialist search engine that is built for rent listings. That reminds me of something I was wishing for a couple of months ago, trying to find a rental place after moving to Brisbane - one of those web sites that made better use of geodata. Some of the good ones will shop you a map with a house icon for each property that is for rent/ sale, but a lot don't do even that. What I really wanted was a site that would do the above, and also tell me how long it would take to talk to the nearest public transport, catch it, and walk to my work at the other end[0]. Plus where the nearest shops were, if there were any parks or sports facilities nearby and so on. Now, if only I had a freely available source of data for something like that... I guess I should probably shut up and actually do something about it, although it probably wouldn't work to well without decent house number data. [0] Copying and pasting the address into the Translink web site gets tiring after a while. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Navteq mapping AU
Forgot to mention that if you hover over a public swimming pool it even gives you the water temperature, something very important in Switzerland ;-) On Wednesday 26 Aug 2009 13:14:43 Evan Sebire wrote: In Switzerland they have a site called http://www.search.ch even though most of it is only available in German or French, like the wikipedia or weather integration. The real-estate map is great but they have not been able to get all the local companies to use their service. http://immo.search.ch/ maybe because of the cost? Public transport timetable information is great, even works from each bus- stop, just hover over a stop and see the information pop-up. On Wednesday 26 Aug 2009 12:13:18 James Livingston wrote: On 26/08/2009, at 7:44 PM, John Smith wrote: One example given was do you search on google to rent a house, generally no one does, they use a specialist search engine that is built for rent listings. That reminds me of something I was wishing for a couple of months ago, trying to find a rental place after moving to Brisbane - one of those web sites that made better use of geodata. Some of the good ones will shop you a map with a house icon for each property that is for rent/ sale, but a lot don't do even that. What I really wanted was a site that would do the above, and also tell me how long it would take to talk to the nearest public transport, catch it, and walk to my work at the other end[0]. Plus where the nearest shops were, if there were any parks or sports facilities nearby and so on. Now, if only I had a freely available source of data for something like that... I guess I should probably shut up and actually do something about it, although it probably wouldn't work to well without decent house number data. [0] Copying and pasting the address into the Translink web site gets tiring after a while. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
Liz wrote: On Wed, 26 Aug 2009, Cosmic Charade wrote: yes, but I use debian and xfce as desktop. however the screen is so small you need to learn about fullscreen, the keyboard shortcuts and see the optometrist as well I use Ubuntu with xfce so a similar setup but it runs like a dog on mine for some reason maybe I installed the wrong version of Java or I need to run with some command line options? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] government-owned mapping company PSMA data
--- On Thu, 27/8/09, Mike Smith mikesm...@dominoconsultant.org wrote: Has anybody explored the possibility of getting access to data from the Australian government owned mapping company PSMA? Link is here... http://www.psma.com.au/ I think most of us would be aware of PSMA, but I think any requests to them would need to be handled tactfully and delicately and this is one reason I'm trying to establish a legal entity so we can say we're an organisation not just a bunch of hobbyists. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Coastlines, was: Rivers
Sorry to drag up this thread, but it's become relevant again. --- On Wed, 20/5/09, Ian Sergeant iserg...@hih.com.au wrote: There is some contention where the coastline ends, and where the river begins. From a practical stand point, coastlines are treated differently to other similar ways in that they can be non-closed ways and still render. Things like natural=land must be closed or it won't render, same with waterway=riverbank, I'm guessing but I doubt these are the only examples. natural=coastline is dealt with by shape files, shape files don't update with the same frequency as other OSM data. Any way, back to how this is relevant, at present if you have over 2000 points outlining a body of water it won't be accepted by the current limitations of the API and so you'd have multiple closed ways/areas which is also a hack to get this to render. So the river/coastline thing is also technically contentious, not just distance from the ocean or if there is salt water present in the water :) ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Anfrage Geolocating
Hallo, Michael Buege wrote: Folgende Anfrage ist bei mir eingegangen. Kann dem Manne jemand helfen? Geocoding gibts bei OpenRouteService und bei Cloudmade (also Adresse - lat/lon), und den Rest kann er sich mit OpenLayers selber dazubasteln (lassen) - eine plug play-Loesung fuer die angeforderte Funktionalitaet (er sucht ja praktisch sowas wie ein fertiges Widget, das er einfach einbauen kann) ist mir nicht bekannt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Hallo. Am Mittwoch, 26. August 2009 schrieb Peter Körner: Wir haben in unserem Ort eine Landsrtraße, welche kurvig mitten durch den Ortskern führt (aka Alzeyer/Mainzer/Wormser Straße). Zusätzlich gibt's eine Umgehungsstraße (aka Bahnstraße), jedoch nur als gut ausgebaute Ortsstraße definiert ist. Die Richtlinie K = tertiary, L = secondary ist kein Gesetz. Es ist eher so, dass meistens diese Einstufung auch die Verkehrsbedeutung passend wiedergibt und es daher keine Zweifel gibt. Ist das an einer Stelle nicht so, ist also die Verkehrsbedeutung abweichend von der Klassifizierung, dann würde ich bevorzugt die Verkehrsbedeutung für die Kategorie-Auswahl nutzen. Insbesondere als Einheimischer weiß man ja recht genau, wie oft die eine oder die andere Straße genutzt wird und kann das entsprechend eintragen. Bei Unklarheiten nutze ich zudem noch die Wegweiser als Indiz. Zeigt also in deinem Fall bei Gau-Köngernheim der Wegweiser nach Biebelnheim über die Bahnstraße, dann sollte man damit rechnen, dass dort wesentlich mehr Durchgangsverkehr stattfindet und diese höher einstufen als die alte Landesstraße. In deinem Fall scheint es mir so als könnte man einfach die Klassifizierung vertauschen. Interessant wäre dann noch, wie der normale Verkehrsfluss von Süd-Ost (L 414) aussieht. Gibt es da nennenswerten Verkehr nach Richtung Alzey? Jedenfalls sollte eine secondary auch nicht einfach aufhören ohne dass eine weitere secondary weiter geht. Gruß, Bernd -- Aus Anonymitätsgründen nennen wir sie Lisa S. Oder nein doch lieber L. Simpson. - Skinner, Die Simpsons signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seebruecke = Pier ?
Am 25. August 2009 22:15 schrieb Markus liste12a4...@gmx.de: Also: man_made=pier + access=... (für Landverkehr, so ne Art pedestrian area) + mooring=... (Anlegestellen, abschnittsweise für Seeverkehr) Dieser Vorschlag sorgt für Inkonsistenzen im vorhandenen Schema. Die haben wir zwar auch an anderen Stellen, aber man muss sie ja nicht unnötig vermehren. Bisher wird der weit überwiegende Teil aller Stege in Marinas mit man_made=pier eingetragen. Nach dem Vorschlag von Markus würde sich zukünftig daraus nicht mehr ergeben, dass man da auch anlegen darf. Die Mehrheit der bisherigen man_made=pier bedürfte also der Überarbeitung. Da finde ich den Vorschlag von Heiko besser: Am 25. August 2009 16:47 schrieb Heiko Eckenreiter he...@eckenreiter.de: Nach der Definition der IHO wäre die Seebrücke eine Unterkategorie von Pier; in OSM könnte ich mir eher ein man_made=pier + pier_type=promenade_pier oder ähnlich vorstellen. Die Seebrücke wäre dann zunächst mal der Sonderfall. Bei allen bisherigen man_made=pier bliebe erst einmal alles beim alten. Man müsste nicht anfangen die Tags zu ergänzen, damit es wieder stimmig wird. Für diese Lösung spricht im Übrigen, dass Seebrücken gegenüber normalen Stegen zum Anlegen von Schiffen immer in der Minderheit bleiben werden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
fastfood waere das letzte, womit ich so eine eisdiele in verbindung bringen wuerde. warum nicht amenity=ice_cream? Weil du fast-food mit Hamburgern Pommes in verbindung bringst? Was ist mit dem China-Mitnehm-Imbiss - auch fast-food? Oder dem kleinen Pizza-Hut hier, der auch nur Straßenverkauf macht? Was ist mit Brezelbuden? Das ist zwar alles kein fast-food ala McDonalds Burger King, aber es ist auch fast-food im Sinne der Wikipedia: Fastfood [ˈfɑstˌfud] (engl. fast food = schnelle Nahrung, Schnellimbiss) sind zubereitete Speisen, die für den raschen Verzehr produziert werden. Die Zeitspanne zwischen Bestellung und Erhalt des Produktes beträgt meist weniger als zehn Minuten http://de.wikipedia.org/wiki/Fast-Food#Umsatzsteuer Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seebruecke = Pier ?
Falk Zscheile schrieb: man_made=pier + access=... (für Landverkehr, so ne Art pedestrian area) + mooring=... (Anlegestellen, abschnittsweise für Seeverkehr) Dieser Vorschlag sorgt für Inkonsistenzen im vorhandenen Schema. Die haben wir zwar auch an anderen Stellen, aber man muss sie ja nicht unnötig vermehren. Wenn man mooring=no für den Promenadenteil nutzt passt alles. Dann braucht man keinen neuen Tag erfinden. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfrage Geolocating
Frederik Ramm schrieb: Hallo, Michael Buege wrote: Folgende Anfrage ist bei mir eingegangen. Kann dem Manne jemand helfen? Geocoding gibts bei OpenRouteService und bei Cloudmade (also Adresse - lat/lon), und den Rest kann er sich mit OpenLayers selber dazubasteln (lassen) - eine plug play-Loesung fuer die angeforderte Funktionalitaet (er sucht ja praktisch sowas wie ein fertiges Widget, das er einfach einbauen kann) ist mir nicht bekannt. Teilweise ist das hier vorhanden: http://yournavigation.org/ Wenn man z.B. auf den From-Button klickt kann man anschließend in der Karte seinen Marker setzen. Drag'n'Drop wäre natürlich viel schöner. Geocoding gibt's auch direkt bei OpenStreetMap: http://wiki.openstreetmap.org/wiki/Namefinder Leider ist die komplexität der Queries sehr begrenzt. Wenn ich beispeislweise nach Gustav-Heinemann Straße, Gau-Odernheim suche, bekomme ich die entsprechende Straße in Alzey - obwohl es eine gleichnahmige in Gau-Odernheim gibt. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Hallo In deinem Fall scheint es mir so als könnte man einfach die Klassifizierung vertauschen. Interessant wäre dann noch, wie der normale Verkehrsfluss von Süd-Ost (L 414) aussieht. Gibt es da nennenswerten Verkehr nach Richtung Alzey? Jedenfalls sollte eine secondary auch nicht einfach aufhören ohne dass eine weitere secondary weiter geht. Aus dieser Richtung ist die L406 noch immer relevant, da hast du recht. Der Verkehr hält sich in Grenzen da an der L406 nur kleine Käffer (500 Einwohner, kein nennenwertes Gewerbe oder Industrie) liegen, bis sie dann an die L425 angeschlossen ist, die dann den Hauptteil des Verkehrs übernimmt. Ich hab mich entschieden die Umgehungsstraße auch auf secondary zu setzen, da ich denke dass, wenn man alle Richtungen in betracht zieht, beide eine etwa gleiche Bedeutung haben. Danke für eure Kommentare! Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Moin Georg, Moin, Rainer Knaepper schrieb: Moin Martin, restaurant ist daher auch in unserem Vorschlag nicht vorgesehen, wir sehen es als eine Untergruppe von café bzw. fast_food fast_food finde ich recht grenzwertig. In welchen Landstrichen bekommt man in Eiscafés was anderes als (vornehmlich) Eisspezialitäten, Kaffee/Espresso/etc, eventuell Waffeln, Kuchen oder Kleingebäck? Ein Schnellrestaurant, in dem es /auch/ Eis gibt, ist für mich kein Eiscafé. Martin schrieb von cafe (mit Sitzgelegenheit) und fast_food (ohne Sitzgelegenheit). Bei amenity=fast_food cusine=ice_cream geht es also um einen Imbiss, wo es *nur* Eis gibt. Also einen Eis-Stand/Kiosk, ohne Sitzgelegenheiten, nur die Eisausgabe. So etwas gibt es ja durchaus auch häufiger - und trifft es ganz gut finde ich. Mit fast_food=keine_Sitzgelegenheit zur Unterscheidung habe ich dann aber mal ein ernstes Problem. Soll ich alle die MacDoofs und BKs jetzt als Restaurant taggen? Sorry, da klappen sich mir die Fußnägel hoch. Für die richtigen Eis-Cafés wird ja auch amenity=cafe cuisine=ice_cream verwendet. Dann gibt es hier in UN halt ausschließlich richtige Eiscafés :-) Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Am 26. August 2009 09:34 schrieb Rainer Knaepper rain...@smial.prima.de: Mit fast_food=keine_Sitzgelegenheit zur Unterscheidung habe ich dann aber mal ein ernstes Problem. Soll ich alle die MacDoofs und BKs jetzt als Restaurant taggen? Sorry, da klappen sich mir die Fußnägel hoch. hehe... +1! -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Wege - Untersuchung
Hallo doppelte Wegesucher, Andre Hinrichs schrieb vor einiger Zeit: Am Montag, den 17.08.2009, 11:31 +0200 schrieb Steffen Wolf: Was Euch noch fehlt, und da weiss ich auch keinen rechten Weg, ist die Moeglichkeit, die Beseitigungen einzutragen, d.h. die GPX-Datei zu kuerzen. Ich denke, es reicht, wenn Du die Generierung der Datei automatisieren kannst und dann tagesaktuell hältst. Für diejenigen, die die Fehler bearbeiten und JOSM verwenden, gibt es ein schönes Plugin, welches GPX-Dateien bearbeiten kann. Ich hab mein Skript mittlerweile automatisiert. Es lief jetzt taeglich in der Mittagspause, wenn der Buerorechner lief, d.h. am Wochenende nicht. Ich hab neben der Liste von Wegen mit 3 ueberlappenden Knoten noch Listen fuer 5, 9 und 29 aktualisiert. Die Daten liegen hier: http://www.unix-ag.uni-kl.de/~stw/osm/ Die 29er sind eigentlich immer falsche Eintragungen. Mich hat gestern aber gewundert, dass da scheinbar immer mehr hinzukommen, egal wieviel ich selbst versuche zu beseitigen. Richtige Doppelungen sind es nicht, meist wurden Wege geteilt oder kombiniert, aber die alten Wege nicht geloescht. Ein Programm scheint beim Kombinieren verschiedenwertige Tags mit Semikolon getrennt zusammenzulegen (tracktype=grade1;grade2 etwa). Mal beispielshaft zwei Wege mit 111 gemeinsamen Knoten: http://www.openstreetmap.org/browse/way/38583228/history http://www.openstreetmap.org/browse/way/23068726/history Huh, die sind ja noch interessanter, gut 79 Knoten auf derselben Position: http://www.openstreetmap.org/browse/way/22787735/history http://www.openstreetmap.org/browse/way/39483682/history Danke uebrigens fuer den Tip mit mittlerer Maustaste und Strg in JOSM. Da ich nicht weiss, wie intensiv die Daten genutzt werden, hab ich mich entschlossen, die Aktualisierungen erstmal auf drei pro Woche zu beschraenken: Mo+Mi+Fr jeweils so mittags. Viel Spass damit, stw -- Press any key to continue or any other key to quit. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflugplatz
Am 25. August 2009 23:54 schrieb Claudius Henrichs claudiu...@gmx.de: Zwei kleine Ergänzungen: - Statt aerialway ([Luft]seilbahnen) bitte aeroway Natürlich, so war's auch gemeint. :-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflugplatz
Hallo, Martin Simon wrote: Gerade dort wäre es sinnvoll, mit einem eigenen Wert für Modellpisten unterhalb des Schlüssels aeroway zu arbeiten - gerade wenn, wie du schreibst, die Übergänge teils fließend sind. Der Unterschied wäre dann Der Platz hat zwei Landebahnen vs. der Platz hat eine Landebahn und eine Modellflug-Piste. +1. Ein Minigolfplatz ist kein Golfplatz, sondern ebenso wie ein Golfplatz eine Freizeit- oder Sporteinrichtung. Der Golfer kann mit einem Minigolfplatz nichts anfangen (Sie suchten nach einem Hotel mit Golfplatz, wir haben hier fuer Sie ein Hotel mit Minigolfplatz gefunden...), und der Minigolfer kann mit einem Golfplatz nichts anfangen. Ebenso verhaelt es sich mit Flugplaetzen - weder ist ein Verkehrslandeplatz oder gar Verkehrsflughafen fuer die Modellfliegerei geeignet noch umgekehrt. Daher wuerde ich, wenn ich einen Modellflugplatz mappen wuerde, neue Werte im leisure, sport oder von mir aus auch aeroway-Schluessel erfinden, keinesfalls aber die Tags fuer Verkehrslandeplaetze und deren Pisten wiederverwenden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Rainer Knaepper schrieb: Soll ich alle die MacDoofs und BKs jetzt als Restaurant taggen? Sorry, da klappen sich mir die Fußnägel hoch. McDo hatte ja früher mit dem Slogan Das etwas andere Restaurant geworben... ;-) MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflugplatz
Garry schrieb: wie taggt man einen Modellflugplatz? Habe dazu nichts gefunden. [...] Es macht Sinn für die Startbahn ganz normal eine runway zu taggen, wie bei jedem anderen Flugzeug auch. Dies stellt sicher das sie auch in den bestehenden Anwendungen dargestellt werden - auch in den Garmin Geräte was so schon seit einger Zeit angewendet wird! Also bitte nicht als irgenwelche Sport- und Spieleinrichtungen mappen, zumindest die Landebahn sollte sichtbar sein! Für das Gesamtgelände kann man dann einen geeigneten Tag finden. Das kann's eigentlich nicht sein. Alle Achtung für die Modellbauer, aber es macht einen DEUTLICHEN Unterschied zwischen einem Modellflugzeug und einem echten Flugzeug. Versucht mal mit einem echten Flugzeug (z.B. Segelfliger) auf einer kurzen Modelflug-Graspiste zu landen - das wird sehr wahrscheinlich schief gehen. Ich weiß wir mappen nicht für die Renderer, notfalls muß der Renderer angepaßt werden. Aber was der Renderer aktuell aus so einem Miniflugplätzchen macht ist einfach daneben. Und woher soll der Renderer seine entsprechede Info haben (daß es ein Modellflugplatz ist und kein Flugplatz), wenn keine entsprechenden Tags vohanden sind = für mich ist klar, daß ein Modellflugplatz anders getaggt werden muß (!) als ein normaler Flugplatz - trotz aller luftverkehrstechnischen und sonstigen Vorschriften! BTW: Beispiel bei mir in der Gegend: http://www.openstreetmap.org/?mlat=48.15984mlon=11.35975zoom=16layers=0B00FTF Das sieht einfach völlig bescheuert aus! Als ich das gesehen hatte, habe ich mir die Daten mit JOSM angesehen bzw. ansehen müssen, um zu verstehen was da gemappt/getaggt ist... :-((( Eine simple Bezeichnung Modellflugplatz XYZ reicht da nicht aus, da müssen entsprechende Tags dahinter. MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflugplatz
Mirko Küster schrieb: Bring dafür meinetwegen etwas spezielles für den Modellflug auf den Weg. Das kann ja unter Aeroway bleiben. Oder besser noch unter Sport oder Freizeit. Aber erstens ist das absolut irritierend wenn ich in der Karte Minilandebahnen vorfinde die quasi breiter als lang sind und eigentlich garnichts mit dem regulären Flugbetrieb zu tun haben. Und für die Auswertung ist das mal ganz daneben. Ein wichtiger Punkt wurde ja schon genannt. Wenn ich die Daten auf Flugplätze auswerte, suche ich auch nach Flugplätzen, nicht nach Spielplätzen. +1! MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflugplatz
Am Mittwoch 26 August 2009 11:07:50 schrieb Michael Kugelmann: für mich ist klar, daß ein Modellflugplatz anders getaggt werden muß (!) als ein normaler Flugplatz - trotz aller luftverkehrstechnischen und sonstigen Vorschriften! +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
