Re: [OSM-talk] Wide tracks with cycle access
pe, 2008-05-02 kello 00:28 +0200, Martin Simon kirjoitti: > Am Donnerstag, 1. Mai 2008 13:37:32 schrieb Andy Robinson (blackadder): > OK, you're totally right at this, it seems difficult to define structure of > road surfaces - several proposals in the wiki exist, but none seems to have > seen broad use in actual mapping - in short, I do'nt have a solution. > But the need for some reliable, robust and versatile surface tagging method > seems to be there, as there are ~3 proposals in the wiki to renew/extend > surface tags. > And I really do think its better to do this now than to re-tag specific > vehicle-based tags in the future. Just an idea: what about having a separate tag for the "driveability" of the surface. Even when the surface material is basically the same, the driving experience with a bicycle my vary relatively much. The driveability tag could be used when driving experience is different from what one might expect based on the track type or the surface material of the track. For example, grades like -1, -2, or +1 and +2 could be used when the driving experience is worse or better than expected. This is indeed just an idea - I'm not making a more detailed suggestion, because I have very little experience with tagging (or anything else regarding OpenStreetMap :-) Cheers, Ari Torhamo ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
On Fri, May 02, 2008 at 12:24:35AM +0100, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > "Tom Carden" <[EMAIL PROTECTED]> wrote: > > > I think the fact that it has its own API is a much bigger concern than > > it being written in AS 1.0 is. If Potlatch was using the main API, > > development of API-backed features in Potlatch could be shared by > > other editors too. Any tests written for the API would help Potlatch. > > Any changes to the schema would only have to happen once. etc. etc. > > I think most of us (with the possible exception of Richard) would > agree here. > > Well actually I don't mind the existence of the AMF API as such so > long as it is just concerned with decoding the RPC calls and encoding > the results, and it uses the rails object model to do all the work > so that important code is shared with the XML API. There's an important difference between this and "Potlatch using the main API". There are, I believe, some things that Potlatch can do that no other client can do, because the API to do it is not available. Specifically: * whichways_deleted gets deleted ways in a bbox, which the main API doesn't provide * getway_old has a "last deleted version", which seems different More problematic than the specific methods which do or don't exist, however, is the fact that the Potlatch way of interacting with them is *entirely* different -- so when a bug is fixed in the main API, the fix has to be duplicted in the Potlatch/amf_controller. This affects development of the server side APIs. You, at one point, put forward a significant amount of effort in improving the Rails code in amf_controller: that work benefited only Potlatch. If Potlatch was using the same backend rails calls (rather than just objects/models), then that development time could have benefited other clients as well. Potlatch has a very different way of interacting with the API. This way of interacting with the API has some benefits, and could allow for other clients similar to Potlatch to be developed without being tied explicitly to amf_controller, which is (at least at the moment) essentially Potlatch specific. (Things like 'masterscale' and 'potlatch_lon' seem to be indicate this anyway: maybe I'm wrong here.) I don't know amf: I see from the code that it's Actionscript Message Format. If there is a desire for supporting Actionscript Message Format for API actions, I don't see a problem with that at all: In fact, other encodings of OSM data delivered via the API seem a natural progression to me. (I'm biased here, having done this with TileCache, FeatureServer, WPServer, etc.) But I don't see that that means that Potlatch should have access to API methods which simply don't exist to any not potlatch-clients (or that clients would have to speak the same language as Potlatch to use them). > We have in fact started moving towards that goal with some work > that Steve did on some of the AMF calls. This is a different goal, that of replacing SQL with rails objects. A valuable goal, but not the same as abstracting the data selection calls to a single set of code, and then using that code to serve both the main API and amf_controller. > The problem is that it turned out that, even after I had optimised > the code, it is significantly slower to go through the rails object > model that to make direct SQL queries. This is interesting, but (imho) less relevant: The value of the above is actually doubled by this statement, since if Potlatch and the API were using the same function, one could optimize this, and since the code is used by *all* clients (not just one) you would see any problems with SQL calls more generally, and perhaps find it easier to debug them. (I think this is compounded by the fact that AMF is a format which is hard to replicate outside of a flash client, which makes server side developers less likely to have the technical chops to debug them.) A common library for API functionality between amf_controller and the various api_controller methods would help resolve this to some extent. > I think even Richard wouldn't mind too much making the AMF API use > the rails object model if it wasn't for the performance issues. Using the Rails Object Model is solving an *internal* API issue, but there still continue to exist two external APIs that use different backend data manipulation to achieve their goals. This seperation is what I see as more problematic -- and I think that's what Tom was addressing as well, though I could be wrong. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
In message <[EMAIL PROTECTED]> "Tom Carden" <[EMAIL PROTECTED]> wrote: > I think the fact that it has its own API is a much bigger concern than > it being written in AS 1.0 is. If Potlatch was using the main API, > development of API-backed features in Potlatch could be shared by > other editors too. Any tests written for the API would help Potlatch. > Any changes to the schema would only have to happen once. etc. etc. I think most of us (with the possible exception of Richard) would agree here. Well actually I don't mind the existence of the AMF API as such so long as it is just concerned with decoding the RPC calls and encoding the results, and it uses the rails object model to do all the work so that important code is shared with the XML API. We have in fact started moving towards that goal with some work that Steve did on some of the AMF calls. The problem is that it turned out that, even after I had optimised the code, it is significantly slower to go through the rails object model that to make direct SQL queries. Of course that probably affects the main API as well, it's just that it doesn't appear as a regression in that case in the way that it does with the AMF API. I think even Richard wouldn't mind too much making the AMF API use the rails object model if it wasn't for the performance issues. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New Potlatch
[EMAIL PROTECTED] wrote: >> - When you add a point into a way where it crosses another way, >> Potlatch automatically makes an intersection. > > Is this 'feature' able to be turned off? Otherwise I would consider > it a > bug as it means that you can't do bridges over other ways. It's only when you shift-click (to insert a point) on a way directly over another way. In other words, if you have | --- | then shift-clicking the 'crossing' will create a junction. That's the only difference. Previously, you'd have to go through all sorts of shenanigans with splitting the way etc. It certainly doesn't automatically make a junction when you're drawing, so you can create bridges exactly the same way as you would previously. Typically, for a bridge, you wouldn't have nodes at the same place anyway - you'd usually have one at the start and one at the end of the bridge. Assuming a straight bridge, that is! cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New Potlatch
> - When you add a point into a way where it crosses another way, > Potlatch automatically makes an intersection. Is this 'feature' able to be turned off? Otherwise I would consider it a bug as it means that you can't do bridges over other ways. Mungewell. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Am Donnerstag, 1. Mai 2008 13:37:32 schrieb Andy Robinson (blackadder): > > It was because of the difficulty of defining unpaved surfaces that this > thread branched off. If you can come up with a method for tagging the > make-up of natural surfaces then great, but its not easy in my view or I'd > be using them already. > > Cheers > > Andy OK, you're totally right at this, it seems difficult to define structure of road surfaces - several proposals in the wiki exist, but none seems to have seen broad use in actual mapping - in short, I do'nt have a solution. But the need for some reliable, robust and versatile surface tagging method seems to be there, as there are ~3 proposals in the wiki to renew/extend surface tags. And I really do think its better to do this now than to re-tag specific vehicle-based tags in the future. -Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-dev] The future of Potlatch
2008/5/1 Richard Fairhurst <[EMAIL PROTECTED]>: > > CloudMade (Steve and Nick's VC-funded company set up to commercialise > OSM data, www.cloudmade.com) wants to commission a new online Flash > editor for OSM. It would, I believe, probably be written by developers > from Stamen Design (www.stamen.com): some of you will remember that > Stamen's Tom Carden wrote OSM's early Java editing applet, and they've > also written a slippy map in Flash called Modest Maps. > I'll be up front here - I have spoken informally to Steve about the potential of us working on this, but nothing formal has been arranged. I'm not sure whether Stamen would take this project on, or what our availability is, or any of that - I only speak for myself here and not the company. If Stamen did work on it, there'd be no guarantee that I would be personally involved. Steve (or anyone else you've talked to) shouldn't be talking about a potential business relationship that doesn't exist yet, nor should they be holding it over you as a (dubious) incentive to improve Potlatch to their liking. I'm sorry if that's what's happened. > As you can imagine, this has taken me aback a bit. > > As I understand it, their main issue is a technical one. Potlatch is > written in ActionScript 1, which is the same language as JavaScript, > but for Flash. The latest version is ActionScript 3, which is much more > like Java for Flash. The end user doesn't notice a difference, but the > programming style is very different. > > CloudMade believes this is holding back the development of OSM: that if > the editor were written in the latest version of the language, more > Flash designers would come to work on it, resulting in a better editor. > Steve cites OSM's move from pure Ruby to Ruby on Rails as an example of > how a contemporary language encourages more people to contribute. And > they're also worried that if I were run over by a bus then no-one would > be able to speak ActionScript 1 and maintain Potlatch. > Since I'm here, I will offer my own opinion about perceived hurdles to developing Potlatch. I'm aware that this might be an inappropriate place to do so, given that I'm somehow implicated in your taken-aback-ness, above, but I think it's worth adding... I think the fact that it has its own API is a much bigger concern than it being written in AS 1.0 is. If Potlatch was using the main API, development of API-backed features in Potlatch could be shared by other editors too. Any tests written for the API would help Potlatch. Any changes to the schema would only have to happen once. etc. etc. > I'm not so sure. I think people are beginning to contribute code to > Potlatch; that as essentially JavaScript it's approachable enough; and > that the problems of attracting developers is symptomatic of core OSM > in general (as per http://trac.openstreetmap.org/log/sites/rails_port). > > I hope that Potlatch, as something maintained by an active community > participant _for_ the community, has demonstrated a pretty rapid rate > of improvement anyway. It's meant to be small and compact, of course, > not a a bells-and-whistles editor like JOSM: nonetheless, in the last > few months, for example: it's become the only editor yet to offer > revert/history, gained very good relations support, background layers, > flexible GPX import, etc. And there's a lot of stuff on the way, mostly > focusing on usability - from a generic 'undo' and pop-up help panel to > a new, super-user-friendly tagging panel with draggable POI icons and > things like that. It's got faults, everything has, but it's come a long > way in the last year. For what it's worth I think it's the best thing > I've ever coded. > It's certainly leaps and bounds ahead of the applet I wrote, I have no problem admitting that! > For most purposes AS3 probably is a better language - except for the > fairly major proviso there's no open-source player even in development. > Indeed, if I were starting all over again I'd probably do it in AS3, > and in a couple of years I may well migrate Potlatch to AS3 (or 4, or > whatever) anyway. But right now it's more important to spend time > improving usability for mappers, given that - like most people here - I > do have a full-time job which isn't OSM (which isn't computer-related > at all, in fact) and consequently time is not unlimited. > You're right I think. API aside, the main reason to move to AS3 would be speed, the availability of more libraries and better development tools, and the larger developer community that Couldmade cites. Certainly though, the lack of a solid open source platform to run AS3 code on is an issue for a project like OSM. Not so much for a business like Cloudmade though, I expect. I think the rest of this thread has already covered the fact that there has to be room for more than one editor in the OSM eco-system (and I point people to OAuth as a way to open that up), but that the Edit tab o
Re: [OSM-talk] [OSM-dev] The future of Potlatch
Hi, > [warning - long ponderous e-mail follows!] I don't really see much of a problem with mutliple Flash editors being available. If they get something done that's better than Potlatch, why then it's good for all is it not? In general I have a problem with the built-in "uniqueness" of Potlatch or anything that might replace it; Potlatch is "the" OSM editor, the one that comes up if you click "edit" on the main OSM page. Until now Potlatch has enjoyed this privilege because there was no other suitable editor. If there are many competing editors - which one will get the "pole position" on osm.org? The editor and the features it supports will always very strongly influence what people map and how they do it. With JOSM, the concept is reasonably open; anyone can compile and run their own JOSM and make it available to third parties (as anyone using JOSM will not have difficulties running a program obtained from somewhere else), and plugins can be written and distributed. So even if JOSM were the only editor around, its grip on what people map and how they do it would not be very strong, since anybody with, say, an interest in turn restriction relations could provide a plugin that would make them editable nicely. Correct me if I'm wrong but Potlatch is, and any AS3 replacemend would be, a much more controlled environment, where the user has much less say in what editor and what features they want - you cannot simply run your own version of the editor against the live API, nor can you have local plugins or so. So that's the one doubt I would have - it must not come to CloudMade dictating what's behind the "Edit" tab on openstreetmap.org. But that could easily be alleviated by creating a set-up where *anybody* can operate an OSM editor on their site. In fact I would prefer that even now; give the user a choice whether his "edit" tab leads to Potlatch on RichardF's host or to the AS3 flash editor at cloudmade.com or the 100% javascript editor from crschmidt (or maybe even the JOSM applet), and anybody who thinks their editor is even better may add it to the list. If this core issue is resolved - i.e. the osm.org web site does not specifically endorse one editor and fail to list others - then I'd really say competition is good for all of us. I could imagine that if anything suppresses creativity in the current setup, it is not the fact that you use AS1; it is the fact that anything anybody wants to do has to be run by you and/or the people with [EMAIL PROTECTED] and only if you say yes then it gets into "the" editor, whereas with a project that doesn't depend on integration with the osm.org site (like Merkaartor or JOSM), you can simply try out something and offer it to people for immediate live use, even if the maintainer has completely different plans and doesn't like the concept. (But then again, look at the one-digit number of developers even with JOSM and Merkaartor... so don't excpect a boost if you make Potlatch less monopolistic.) > Part of me thinks that the most important thing is that Potlatch is > still available and users are offered the choice. Part of me thinks, > well, if there's going to be a new Flash editor, there's no point in me > doing any development on Potlatch from today forward. Part of me wants > to say "well, screw you" and walk away. And part of me wants to take > CloudMade up on its OSM Grants scheme (http://blog.cloudmade.com/) and > say, ok then, I'll announce a medium-term feature freeze, take a few > weeks' holiday, learn AS3 and recode it for a large amount of $$$. I'm > utterly stumped and would welcome suggestions. As an OSM community member I would like you to continue with your work and someone else do an AS3 editor for CloudMade, and then I want them both available on osm.org so that I can choose the one I like best (or the one that runs with my hardware/OS best, ot whatever). If you stopped working on Potlatch altogether, or if you re-did Potlatch in AS3, then that would leave me (the user) with less choice. Diversity is good. If I were in your shoes however, I might go for the $$$. $$$ is also good. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] The future of Potlatch
Richard This is an interesting dilemma. First you should be proud of the fact that Potlatch is such a well regarded part of OSM. In some strange way it is flattery that CloudMade want to do this. Everybody knows how hard you have worked on Potlatch, and it is a very emotional thing to have someone want to take your baby away. If there is room for two editors within the OSM project, then there's probably room for three. You might find that it gives you the opportunity to take Potlatch in a slightly different direction. Try to see it as a positive thing. More editors means more competition, which will surely result in more innovation and better tools for everyone. 80n On Thu, May 1, 2008 at 6:35 PM, Richard Fairhurst <[EMAIL PROTECTED]> wrote: > [warning - long ponderous e-mail follows!] > > Hi all, > > A fairly weighty issue concerning the future of Potlatch has arisen, > and I'm completely baffled as to what to do - so I thought I'd "ask the > community" for thoughts and advice. > > CloudMade (Steve and Nick's VC-funded company set up to commercialise > OSM data, www.cloudmade.com) wants to commission a new online Flash > editor for OSM. It would, I believe, probably be written by developers > from Stamen Design (www.stamen.com): some of you will remember that > Stamen's Tom Carden wrote OSM's early Java editing applet, and they've > also written a slippy map in Flash called Modest Maps. > > As you can imagine, this has taken me aback a bit. > > As I understand it, their main issue is a technical one. Potlatch is > written in ActionScript 1, which is the same language as JavaScript, > but for Flash. The latest version is ActionScript 3, which is much more > like Java for Flash. The end user doesn't notice a difference, but the > programming style is very different. > > CloudMade believes this is holding back the development of OSM: that if > the editor were written in the latest version of the language, more > Flash designers would come to work on it, resulting in a better editor. > Steve cites OSM's move from pure Ruby to Ruby on Rails as an example of > how a contemporary language encourages more people to contribute. And > they're also worried that if I were run over by a bus then no-one would > be able to speak ActionScript 1 and maintain Potlatch. > > I'm not so sure. I think people are beginning to contribute code to > Potlatch; that as essentially JavaScript it's approachable enough; and > that the problems of attracting developers is symptomatic of core OSM > in general (as per http://trac.openstreetmap.org/log/sites/rails_port). > > I hope that Potlatch, as something maintained by an active community > participant _for_ the community, has demonstrated a pretty rapid rate > of improvement anyway. It's meant to be small and compact, of course, > not a a bells-and-whistles editor like JOSM: nonetheless, in the last > few months, for example: it's become the only editor yet to offer > revert/history, gained very good relations support, background layers, > flexible GPX import, etc. And there's a lot of stuff on the way, mostly > focusing on usability - from a generic 'undo' and pop-up help panel to > a new, super-user-friendly tagging panel with draggable POI icons and > things like that. It's got faults, everything has, but it's come a long > way in the last year. For what it's worth I think it's the best thing > I've ever coded. > > For most purposes AS3 probably is a better language - except for the > fairly major proviso there's no open-source player even in development. > Indeed, if I were starting all over again I'd probably do it in AS3, > and in a couple of years I may well migrate Potlatch to AS3 (or 4, or > whatever) anyway. But right now it's more important to spend time > improving usability for mappers, given that - like most people here - I > do have a full-time job which isn't OSM (which isn't computer-related > at all, in fact) and consequently time is not unlimited. > > So I really don't know what to do. > > Part of me thinks that the most important thing is that Potlatch is > still available and users are offered the choice. Part of me thinks, > well, if there's going to be a new Flash editor, there's no point in me > doing any development on Potlatch from today forward. Part of me wants > to say "well, screw you" and walk away. And part of me wants to take > CloudMade up on its OSM Grants scheme (http://blog.cloudmade.com/) and > say, ok then, I'll announce a medium-term feature freeze, take a few > weeks' holiday, learn AS3 and recode it for a large amount of $$$. I'm > utterly stumped and would welcome suggestions. > > Thanks for reading. :) > > cheers > Richard > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] The future of Potlatch
[warning - long ponderous e-mail follows!] Hi all, A fairly weighty issue concerning the future of Potlatch has arisen, and I'm completely baffled as to what to do - so I thought I'd "ask the community" for thoughts and advice. CloudMade (Steve and Nick's VC-funded company set up to commercialise OSM data, www.cloudmade.com) wants to commission a new online Flash editor for OSM. It would, I believe, probably be written by developers from Stamen Design (www.stamen.com): some of you will remember that Stamen's Tom Carden wrote OSM's early Java editing applet, and they've also written a slippy map in Flash called Modest Maps. As you can imagine, this has taken me aback a bit. As I understand it, their main issue is a technical one. Potlatch is written in ActionScript 1, which is the same language as JavaScript, but for Flash. The latest version is ActionScript 3, which is much more like Java for Flash. The end user doesn't notice a difference, but the programming style is very different. CloudMade believes this is holding back the development of OSM: that if the editor were written in the latest version of the language, more Flash designers would come to work on it, resulting in a better editor. Steve cites OSM's move from pure Ruby to Ruby on Rails as an example of how a contemporary language encourages more people to contribute. And they're also worried that if I were run over by a bus then no-one would be able to speak ActionScript 1 and maintain Potlatch. I'm not so sure. I think people are beginning to contribute code to Potlatch; that as essentially JavaScript it's approachable enough; and that the problems of attracting developers is symptomatic of core OSM in general (as per http://trac.openstreetmap.org/log/sites/rails_port). I hope that Potlatch, as something maintained by an active community participant _for_ the community, has demonstrated a pretty rapid rate of improvement anyway. It's meant to be small and compact, of course, not a a bells-and-whistles editor like JOSM: nonetheless, in the last few months, for example: it's become the only editor yet to offer revert/history, gained very good relations support, background layers, flexible GPX import, etc. And there's a lot of stuff on the way, mostly focusing on usability - from a generic 'undo' and pop-up help panel to a new, super-user-friendly tagging panel with draggable POI icons and things like that. It's got faults, everything has, but it's come a long way in the last year. For what it's worth I think it's the best thing I've ever coded. For most purposes AS3 probably is a better language - except for the fairly major proviso there's no open-source player even in development. Indeed, if I were starting all over again I'd probably do it in AS3, and in a couple of years I may well migrate Potlatch to AS3 (or 4, or whatever) anyway. But right now it's more important to spend time improving usability for mappers, given that - like most people here - I do have a full-time job which isn't OSM (which isn't computer-related at all, in fact) and consequently time is not unlimited. So I really don't know what to do. Part of me thinks that the most important thing is that Potlatch is still available and users are offered the choice. Part of me thinks, well, if there's going to be a new Flash editor, there's no point in me doing any development on Potlatch from today forward. Part of me wants to say "well, screw you" and walk away. And part of me wants to take CloudMade up on its OSM Grants scheme (http://blog.cloudmade.com/) and say, ok then, I'll announce a medium-term feature freeze, take a few weeks' holiday, learn AS3 and recode it for a large amount of $$$. I'm utterly stumped and would welcome suggestions. Thanks for reading. :) cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] New Potlatch
0.8c is one of those "little things that mean a lot" updates: - When you add a point into a way where it crosses another way, Potlatch automatically makes an intersection. - Points and ways are now bigger at high zoom levels for those people without superhuman fine motor skills. (But you can turn this off using a new preference.) - Double-clicking to end a line doesn't restart the line if you've already clicked. - Click/drag detection is much improved. And in some related news, the Gnash (GNU Flash Player) devs - in particular Sandro 'strk' Santilli - are doing really well in improving Gnash to work with Potlatch. strk has even become an OSM mapper which can't be bad. :) It's going to be interesting to see how Adobe's removal of licensing restrictions on SWF, just announced, benefits Gnash. Will post more on Potlatch in a minute. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Searching and alt_name
On 01/05/2008 13:11, Dan Karran wrote: > On Thu, May 1, 2008 at 11:44 AM, David Earl <[EMAIL PROTECTED]> wrote: > >> It's usually POIs affected, and it is usually just variations in names >> rather than completely different names (when you would probably want >> them rendered anyway). Occasionally though street names also have this >> problem. Consider one I came across recently: signs say "Long Horse >> Croft". You can imagine someone might search for "Longhorse Croft" >> (especially as that's how the district council list it on their refuse >> collection days list). > > What should happen in situations where different names are used in > different contexts? I can think of at least one example on the Isle of > Man where the B39 Corlea Road ([1], and in post office database) is > also known as the Ronague Road [2], the Solomons Corner to Ronague > Road [3], and on the road sign on the ground as the Road of the Grey > Hill (or in Manx Bayr Yn Chor Lheeah). > > Presumably the main name is the one on the ground (despite not being > referenced in any official documents available online), and each of > the others should be referred to in an alt_name tag? I'd have thought it depends what you want to appear where. If you want it to appear in all the forms on the map, then I guess you'd put both in the name (like I did here maybe: http://www.openstreetmap.org/?lat=52.17627&lon=-0.03335&zoom=17&layers=B0FT ), but if you only want one of them to appear but the others to be located by searching, you could use alt_name. "Bayr Yn Chor Lheeah" would go under name:gv presumably. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
At 01:01 PM 1/05/2008, Martin Simon wrote: >Am Donnerstag, 1. Mai 2008 11:56:16 schrieb Andy Robinson (blackadder): >> Perhaps this is the better way to think about it. I generally don't like >> subjective tagging, but in this instance giving an opinion about how usable >> a section of way is might be better. If you simplified bike types into >> "road", "hybrid" and "mtb" then I guess you could reasonably add say >> suitability_road / suitability_hybrid / suitability_mtb tags, or join them >> together as bicycle_suitability=road|hybrid|mtb and leave out any of the >> values where you consider its not suitable. >> >> Cheers >> >> Andy > >Hmm I think its way better to have a good description of the surface than >introducing vehicle-type specific usability-tags. > >This way the client (printing/routing-app, etc) can decide which sort of >surface to use. > >For example I have no problem using fine/medium gravel tracks with my "normal" >bike at all, while others on this list would tag such ways >as "bicycle_suitable=mtb"... >And what about incline? is it part of the "bicycle_suitable" tag or not? > >I think its better to invest the time in better surface tagging than, rather >than subjectively tagging things that are only of use for one specific group >of users. I get around subjective tagging / specific groups by doing description:bicycle=Ridable with a road bike but short stretches with tree roots ... looking ahead to the day when pop-ups become all the rage. Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] new potlatch issues
At 01:29 PM 1/05/2008, Richard Fairhurst wrote: >Robin Paulson wrote: > >> richard, i see you've rolled out some changes as part of potlatch >> 0.8c, including huge thick ways...could you roll them back please? >> they're very obtrusive and obscure a lot of the yahoo imagery >> underneath. > >Heh, you can't please all the people all the time - the >easier-to-click ways/nodes were a feature request from a user too. I >guess it depends whether you use Yahoo or not. > >I've now added a preference so that you can turn them off. It's in the >usual place in the options dialogue (the 'tick' at the bottom). Works great, thanks. Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] clipboard on handlebars
When I got home some of my notes for my waypoints didn't make sense. I realized I was trying to take note only every third or forth waypoint and misremembering them. Sometimes the simple solution is the answer. I grapped some big clips from the office and a folder with a lever action clip. I bent back the cover, trimmed it down to a triangle shape, cut a notch for the speedometer cable etc. My data is much better. -- http://bowlad.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] [CARTO-SoC] BCS AWARDS deadline 30 May 2008 (fwd)
I think we should nominate OSM for the 'Ordnance Survey MasterMap Award for Better Mapping' . cheers martin -- Forwarded message -- Date: Thu, 1 May 2008 15:09:30 BST From: C Neal <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list CARTO-SOC <[EMAIL PROTECTED]> Subject: [CARTO-SoC] BCS AWARDS deadline 30 May 2008 BCS Awards deadline The BCS Awards will close to entries on May 30th 2008. The British Cartographic Society (BCS) recently revamped the Awards scheme to encourage entrants from all disciplines in cartography, and to showcase products created through traditional or new, even experimental, techniques. The BCS aims to help promote the best of cartographic products and highlight good cartographic design in the UK and abroad. As part of the changes, two awards were added to the programme to assist in covering all disciplines. Firstly, The Stanfords Award for printed mapping is designed to encourage any printed products to enter, from coffee table atlases to wallpaper or maps featured in leaflets and topical articles. The Avenza Award for electronic mapping was also added to allow digital products such as interactive and web maps to also compete. Entries can include power-point presentations, interactive CD-ROMS, or websites. These two awards join the established John C Bartholomew Award for Small Scale Mapping and the Ordnance Survey MasterMap Award for Better Mapping. Not only will the winners of these awards receive a crystal trophy and certificate, but they also go head-to-head with each other to receive the prestigious honour of being crowned the Best Mapping entry and presented with The BCS Award. (Closing date for all the above entries is 30th May 2008) We are delighted to announce the introduction of a new award for UK children, to run in alternate years to the ICA Barbara Petchenik Children's Map Competition. The UKHO Junior Mapmaker Award is designed to encourage map making in children aged 7 - 16. (Closing date is Saturday 19th July 2008) We also continue to support the NGS New Mapmaker Award in conjunction with The National Geographic Society (same closing date), and The Henry Johns Award for the best Cartographic Journal article sponsored by Lovell Johns. If you would like to enter any of these awards, entry forms are available on the BCS website. See the Awards section on http://www.cartography.org.uk Information about the winners from 2007 is also available on the website -- Clare Neal BCS Webmaster http://www.cartography.org.uk -- Distributed by CARTO-SoC, the Society of Cartographers Mailing List. For more details about this List and the Society, visit our web site: http://www.soc.org.uk Join the Society on-line now: http://www.soc.org.uk/member.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bulk Data Import how-to and tips
El Jueves, 1 de Mayo de 2008, Patrick Weber escribió: > Also, whats the best procedure for the conversion. I suspect we will get > the data as shapefiles. Can JOSM read shapefiles? I usually use GDAL to convert the shapefile into GML, then fine-tune the gml2osm script by hand and run it. -- -- Iván Sánchez Ortega <[EMAIL PROTECTED]> Proudly running Debian Linux with 2.6.24-1-amd64 kernel, KDE 3.5.9, and PHP 5.2.5-3 generating this signature. Uptime: 16:04:22 up 19:24, 1 user, load average: 0.51, 0.36, 0.36 signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Bulk Data Import how-to and tips
Hi, Patrick Maybe there is a better way, but this is what I would do: - get a shapefile of Luxembourg (or a simple polygon shapefile that contains all of Luxembourg). Let's call it lux.shp. - download the roads for Luxembourg currently in OSM from http://download.geofabrik.de/osm/europe/ Now you will need a GIS application: - select the roads tagged as motorway, motorway_link, trunk, trunk_link, primary or primary_link from that shapefile and export them to another shapefile. - perform a buffer of that shapefile (for example, use 100 meters for the radius) - perform a difference operation: lux.shp minus the buffer you have just created - finally, clip the official shapefile of the Luxembourg roads with the result of that substraction and export the resulting shapefile to the OSM format with that python script. And then, you will have to carefully connect those ways with the current ways in OSM, and revise the tags, of course. Lucas De: [EMAIL PROTECTED] en nombre de Skywave Enviado el: jue 01/05/2008 14:47 Para: talk@openstreetmap.org Asunto: [OSM-talk] Bulk Data Import how-to and tips JOSM can't read shape files, you will have to adapt this script http://boston.freemap.in/osm/files/mgis_to_osm.py to convert shapefiles to osm. On Thu, May 1, 2008 at 12:59 PM, Patrick Weber <[EMAIL PROTECTED]> wrote: Hi list I have been mapping my home country Luxembourg for the past 6 months. I recently have been offered by another OSM user who works at the national road works agency (not shure about the translation but anyway), to get the national road network (all primary highways, trunk and motorways) imported into OSM. Apparently they are okay with it. Great News! Now I am trying to figure out how this will work in practice, as we are not importing into a blank canvas, but a sizable bit of the road network has been done already. How can we merge the two datasets, and keep the best bits of both? Also, whats the best procedure for the conversion. I suspect we will get the data as shapefiles. Can JOSM read shapefiles? Thanks for helping us. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Bulk Data Import how-to and tips
JOSM can't read shape files, you will have to adapt this script http://boston.freemap.in/osm/files/mgis_to_osm.py to convert shapefiles to osm. On Thu, May 1, 2008 at 12:59 PM, Patrick Weber <[EMAIL PROTECTED]> wrote: > Hi list > > I have been mapping my home country Luxembourg for the past 6 months. I > recently have been offered by another OSM user who works at the national > road works agency (not shure about the translation but anyway), to get the > national road network (all primary highways, trunk and motorways) imported > into OSM. Apparently they are okay with it. Great News! > > Now I am trying to figure out how this will work in practice, as we are > not importing into a blank canvas, but a sizable bit of the road network has > been done already. How can we merge the two datasets, and keep the best bits > of both? > > Also, whats the best procedure for the conversion. I suspect we will get > the data as shapefiles. Can JOSM read shapefiles? > > Thanks for helping us. > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] GIS in the public sector
do they mention prices for the nonprofit sector? On Wed, Apr 30, 2008 at 4:04 PM, graham <[EMAIL PROTECTED]> wrote: > Anyone with some money to burn going to this? I imagine just walking > around with an osm t-shirt would probably generate quite a bit of > interest... > > Graham > > > +++GIS in the Public Sector: 14 May 2008, Central London > - Two Weeks To Go > - Countdown To EU's INSPIRE Directive > - Speakers from LGA, IDeA, Defra > http://www.headstar-events.com/gis08/ . > > The European Union's INSPIRE Directive, which paves the way for > all geospatial data to be shared by public bodies across the EU, is set > to come into full force in the UK in May 2009, but the countdown > begins now. The directive is the focus for Headstar's fourth annual > conference and exhibition on Geographical Information Systems (GIS) > in the Public Sector, supported by the Association for Geographical > Information (AGI), on 14 May 2008 in central London. > > Plenary speakers will include representatives from the Local Government > Association; the Improvement and Development Agency (IDeA); and > the Department for the Environment, Food and Rural Affairs (Defra). > > Our event promises to be essential day for anyone involved in the > collection, management or use of geospatial data, from policymakers > looking at statistics across a region to those charged with putting > user-friendly map content onto a website. Places cost 295 Pounds plus > VAT for public sector and 395 plus VAT for private sector. > Register today at: > http://www.headstar-events.com/gis08/ > > > -- > Sponsor me from London to Brighton on http://www.justgiving.com/grahamseaman > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Searching and alt_name
On Thu, May 1, 2008 at 11:44 AM, David Earl <[EMAIL PROTECTED]> wrote: > It's usually POIs affected, and it is usually just variations in names > rather than completely different names (when you would probably want > them rendered anyway). Occasionally though street names also have this > problem. Consider one I came across recently: signs say "Long Horse > Croft". You can imagine someone might search for "Longhorse Croft" > (especially as that's how the district council list it on their refuse > collection days list). What should happen in situations where different names are used in different contexts? I can think of at least one example on the Isle of Man where the B39 Corlea Road ([1], and in post office database) is also known as the Ronague Road [2], the Solomons Corner to Ronague Road [3], and on the road sign on the ground as the Road of the Grey Hill (or in Manx Bayr Yn Chor Lheeah). Presumably the main name is the one on the ground (despite not being referenced in any official documents available online), and each of the others should be referred to in an alt_name tag? [1] http://www.gov.im/lib/news/transport/transportpublicn230.xml [2] http://www.gov.im/lib/news/transport/transportpublicn153.xml [3] http://www.gov.im/lib/news/transport/transportpublicn50.xml Cheers, Dan -- Dan Karran [EMAIL PROTECTED] www.dankarran.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Martin Simon wrote: >Sent: 01 May 2008 12:02 PM >To: talk@openstreetmap.org >Subject: Re: [OSM-talk] Wide tracks with cycle access > >Am Donnerstag, 1. Mai 2008 11:56:16 schrieb Andy Robinson (blackadder): >> Perhaps this is the better way to think about it. I generally don't like >> subjective tagging, but in this instance giving an opinion about how >usable >> a section of way is might be better. If you simplified bike types into >> "road", "hybrid" and "mtb" then I guess you could reasonably add say >> suitability_road / suitability_hybrid / suitability_mtb tags, or join >them >> together as bicycle_suitability=road|hybrid|mtb and leave out any of the >> values where you consider its not suitable. >> >> Cheers >> >> Andy > >Hmm I think its way better to have a good description of the surface than >introducing vehicle-type specific usability-tags. > >This way the client (printing/routing-app, etc) can decide which sort of >surface to use. > >For example I have no problem using fine/medium gravel tracks with my >"normal" >bike at all, while others on this list would tag such ways >as "bicycle_suitable=mtb"... >And what about incline? is it part of the "bicycle_suitable" tag or not? > >I think its better to invest the time in better surface tagging than, >rather >than subjectively tagging things that are only of use for one specific >group >of users. It was because of the difficulty of defining unpaved surfaces that this thread branched off. If you can come up with a method for tagging the make-up of natural surfaces then great, but its not easy in my view or I'd be using them already. Cheers Andy > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] new potlatch issues
Robin Paulson wrote: > richard, i see you've rolled out some changes as part of potlatch > 0.8c, including huge thick ways...could you roll them back please? > they're very obtrusive and obscure a lot of the yahoo imagery > underneath. Heh, you can't please all the people all the time - the easier-to-click ways/nodes were a feature request from a user too. I guess it depends whether you use Yahoo or not. I've now added a preference so that you can turn them off. It's in the usual place in the options dialogue (the 'tick' at the bottom). Will post more on the new Potlatch later. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Am Donnerstag, 1. Mai 2008 11:56:16 schrieb Andy Robinson (blackadder): > Perhaps this is the better way to think about it. I generally don't like > subjective tagging, but in this instance giving an opinion about how usable > a section of way is might be better. If you simplified bike types into > "road", "hybrid" and "mtb" then I guess you could reasonably add say > suitability_road / suitability_hybrid / suitability_mtb tags, or join them > together as bicycle_suitability=road|hybrid|mtb and leave out any of the > values where you consider its not suitable. > > Cheers > > Andy Hmm I think its way better to have a good description of the surface than introducing vehicle-type specific usability-tags. This way the client (printing/routing-app, etc) can decide which sort of surface to use. For example I have no problem using fine/medium gravel tracks with my "normal" bike at all, while others on this list would tag such ways as "bicycle_suitable=mtb"... And what about incline? is it part of the "bicycle_suitable" tag or not? I think its better to invest the time in better surface tagging than, rather than subjectively tagging things that are only of use for one specific group of users. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Bulk Data Import how-to and tips
Hi list I have been mapping my home country Luxembourg for the past 6 months. I recently have been offered by another OSM user who works at the national road works agency (not shure about the translation but anyway), to get the national road network (all primary highways, trunk and motorways) imported into OSM. Apparently they are okay with it. Great News! Now I am trying to figure out how this will work in practice, as we are not importing into a blank canvas, but a sizable bit of the road network has been done already. How can we merge the two datasets, and keep the best bits of both? Also, whats the best procedure for the conversion. I suspect we will get the data as shapefiles. Can JOSM read shapefiles? Thanks for helping us. begin:vcard fn:Patrick Weber n:Weber;Patrick org:University College London adr:;;Gower Street;London;;WC1E 6BT;United Kingdom email;internet:[EMAIL PROTECTED] title:Engineering Doctorate Student tel;work:02077185430 tel;cell:07854840450 url:http://www.ucl.ac.uk/cemi version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Searching and alt_name
I'd like to encourage you, when editing the map, to think about how people might search for the features you are adding to the map and try to accommodate them, to try to be helpful to future consumers of the map data. Using alt_name is one way to do this. The namefinder already deals automatically with some mechanical variations(*). But there's often variations in what something is known as which can't (easily) be accommodated automatically. For example, I was reading Richard's blog from a few weeks ago about Heathrow Terminal 5, where he says that we correctly yield the result in a search. Yes we do, but what if someone had asked for "Heathrow Airport Terminal 5". Yesterday, that wouldn't have got a hit; today it does because I added an alt_name tag to it to accommodate this variation. Namefinder recognises alt_name. Of course you could put variations in the name tag (maybe separated by semicolons, or in square brackets, or some such), but then it will all render, possibly rather verbosely. You might want just "Terminal 5" to show up on the map rendering, given that "Heathrow Airport" would be rendered separately in the middle of the ring of terminals and so be obvious, but searches for "Heathrow Terminal 5" still be successful. Another example: the search test for tourist attractions has "British Airways London Eye" and "V&A" as test searches. There's arguably no need for the rendering to say other than "London Eye" (or "The London Eye"?) but a search would ideally respond to its full title. Similarly, the map is rightly labelled "Victoria and Albert Museum", but searches should respond to V&A. Incidentally, variations aren't needed for just for the presence or absence of the word "the" (or le, la, el, il, die, das, der), which is automatically dealt with. Another example might be function vs name. The name of an office block in Cambridge is "Eastbrook", but if someone searches for "Inland Revenue, Cambridge" it might be nice to be able to offer "Eastbrook" as the answer. (That works, but "HMRC, Cambridge" or "Tax office, Cambridge" don't and arguably should. Conversely "Chailey House, Bedford" doesn't work - today - but "Inland Revenue, Bedford" does). It's usually POIs affected, and it is usually just variations in names rather than completely different names (when you would probably want them rendered anyway). Occasionally though street names also have this problem. Consider one I came across recently: signs say "Long Horse Croft". You can imagine someone might search for "Longhorse Croft" (especially as that's how the district council list it on their refuse collection days list). I guess in principle, I could automate this at some point, but it is hard, especially the other way round (signs say "Longhorse Croft", searcher asks for "Long Horse Croft"), so a variation would be helpful here, though purists will say "don't code for the inadequacies of the tools". David (*) in things like case, abbreviations (Rd vs Road), accented characters and diacriticals (München vs Munchen or Muenchen), ligatures, possessives (St John's vs St John or St Johns) and some Germanic concatentations (Potsdammerplatz vs Potsdammer Platz). We are also used to dealing with alternative languages with the name: tags, so 'Londres' will find 'London'. Also, the item description is included, so you don't necessarily need to say "school" in the name - "King Edward School" will match name=King Edward, amenity=school (though not at present Konig Albert Schule" unless schule is recorded as part of the name). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM in Europe Statistics
Hi, > Could you do a stats on Denmark as well, since we still are considered > part of Scandinavia ;) 5.5M inhabitants, 5.3M bytes - roughly 1.0. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Richard Fairhurst wrote: >Sent: 01 May 2008 11:13 AM >To: talk@openstreetmap.org >Subject: Re: [OSM-talk] Wide tracks with cycle access > >Andy Robinson \(blackadder\) wrote: > >> Perhaps this is the better way to think about it. I generally don't like >> subjective tagging, but in this instance giving an opinion about how >usable >> a section of way is might be better. If you simplified bike types into >> "road", "hybrid" and "mtb" then I guess you could reasonably add say >> suitability_road / suitability_hybrid / suitability_mtb tags, or join >them >> together as bicycle_suitability=road|hybrid|mtb and leave out any of the >> values where you consider its not suitable. > >Indeed - and you probably just need one value, given that an MTB can >use anything a hybrid can, and a hybrid can use anything a road bike >can. bicycle_minimum maybe. even better. +1 to that. Cheers Andy > >cheers >Richard > > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Andy Robinson \(blackadder\) wrote: > Perhaps this is the better way to think about it. I generally don't like > subjective tagging, but in this instance giving an opinion about how usable > a section of way is might be better. If you simplified bike types into > "road", "hybrid" and "mtb" then I guess you could reasonably add say > suitability_road / suitability_hybrid / suitability_mtb tags, or join them > together as bicycle_suitability=road|hybrid|mtb and leave out any of the > values where you consider its not suitable. Indeed - and you probably just need one value, given that an MTB can use anything a hybrid can, and a hybrid can use anything a road bike can. bicycle_minimum maybe. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Stephen Gower wrote: >Sent: 01 May 2008 10:39 AM >To: talk@openstreetmap.org >Subject: Re: [OSM-talk] Wide tracks with cycle access > >On Wed, Apr 30, 2008 at 08:39:15PM +0100, 80n wrote: >> >> bicycle=yes and surface=gravel are an incompatible combination in my book >;) > > There's gravel and there's gravel though - pea gravel like my > grandfather had on his drive (in the New Forest!) and had to rake > after cars had been over it is absolutely no good for cycling, > while a self-binding gravel such as seen on > http://www.pavingexpert.com/gravel05.htm is perfectly fine. I > cycle a section of the Thames Path on my daily commute that comes > into the latter category, and apart from the puddles tending to get > larger each time it rains, it's just as good as the asphalt > sections. > > The cycle paths in the New Forest are somewhere in between these > two categories - while the Thames Path one could reasonably be > labeled surface=dirt, the New Forest ones are definitely gravel, > but it's well compacted and many of them will be cycled on by > hundreds of people a week during the summer. > > http://www.geograph.org.uk/photo/35904 > http://www.geograph.org.uk/photo/388784 > http://www.geograph.org.uk/photo/35915 > http://www.geograph.org.uk/photo/87018 > http://www.geograph.org.uk/photo/381057 > http://en.wikipedia.org/wiki/Image:New_Forest_Cycle_path.jpg > > From these photos it can be seen that there's quite a variety even > within the National Park and depending on your style of bike you > might want to avoid some or all of them. Perhaps this is the better way to think about it. I generally don't like subjective tagging, but in this instance giving an opinion about how usable a section of way is might be better. If you simplified bike types into "road", "hybrid" and "mtb" then I guess you could reasonably add say suitability_road / suitability_hybrid / suitability_mtb tags, or join them together as bicycle_suitability=road|hybrid|mtb and leave out any of the values where you consider its not suitable. Cheers Andy > > s > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM in Europe Statistics
Frederik Ramm [mailto:[EMAIL PROTECTED] wrote: >Sent: 30 April 2008 8:56 PM >To: Andy Robinson (blackadder) >Cc: 'Frederik Ramm'; talk@openstreetmap.org >Subject: Re: [OSM-talk] OSM in Europe Statistics > >Hi, > >> Can someone point me to some simple code/ideas on how to turn the xml osm >> data into way length? I'll then be able to report some findings. I'll >also >> write up how I gathered the information needed so that other areas can be >> compared. > >There's a script in SVN: > >/applications/utils/filter/osm-length/osm-length-2.pl > >You'd have to call this like so: > >perl osm-length-2.pl < myfile.osm > foo.osm 2> result > >and then you'll have in "result" a text file that gives road lengths >for every type of highway contained in the input file (other data is >disregarded). (foo.osm has a copy of myfile.osm with way lengths >added.) > >Unfortunately this will also count ways that have an "action=delete" >tag because you deleted them in JOSM. You can work around this by >either making sure that the deleted objects are actually removed from >the file (#12 in JOSM/Advanced_Tricks in the wiki) or, instead of >removing the bits you don't want, just tag them "highway=deleted" and >they'll count towards the extra category "deleted" which you can then >ignore. Thanks for this, very helpful alternative to the rough and ready way I have achieved the same thing using the measurement plugin in JOSM. Your method however is able to refine the statistics considerably if that is needed. Cheers Andy > >Bye >Frederik > >-- >Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
On Wed, Apr 30, 2008 at 08:39:15PM +0100, 80n wrote: > > bicycle=yes and surface=gravel are an incompatible combination in my book ;) There's gravel and there's gravel though - pea gravel like my grandfather had on his drive (in the New Forest!) and had to rake after cars had been over it is absolutely no good for cycling, while a self-binding gravel such as seen on http://www.pavingexpert.com/gravel05.htm is perfectly fine. I cycle a section of the Thames Path on my daily commute that comes into the latter category, and apart from the puddles tending to get larger each time it rains, it's just as good as the asphalt sections. The cycle paths in the New Forest are somewhere in between these two categories - while the Thames Path one could reasonably be labeled surface=dirt, the New Forest ones are definitely gravel, but it's well compacted and many of them will be cycled on by hundreds of people a week during the summer. http://www.geograph.org.uk/photo/35904 http://www.geograph.org.uk/photo/388784 http://www.geograph.org.uk/photo/35915 http://www.geograph.org.uk/photo/87018 http://www.geograph.org.uk/photo/381057 http://en.wikipedia.org/wiki/Image:New_Forest_Cycle_path.jpg From these photos it can be seen that there's quite a variety even within the National Park and depending on your style of bike you might want to avoid some or all of them. s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] OSM in Europe Statistics
Frederik Ramm skrev: > Hi, > >a very crude statistic: > > Country osm.bz2 sizepopulationratio (bytes per capita) > > UK73M60M1.2 > Germany 110M82M1.3 > Netherlands 51M16M3.2 > France29M60M0.5 > Finland 20M 5M4.0 > Italy 14M58M0.2 > Norway21M 5M4.2 > Sweden24M 9M2.6 > Spain 17M40M0.4 > Could you do a stats on Denmark as well, since we still are considered part of Scandinavia ;) Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Selecting nodes on a way
Dirk-Lüder Kreie <[EMAIL PROTECTED]> wrote: >Sent: 01 May 2008 10:11 AM >To: OJ W >Cc: OSM Talk >Subject: Re: [OSM-talk] Selecting nodes on a way > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >OJ W schrieb: >| Is it possible in JOSM to select all the nodes on a way? e.g. if you >| have a long power line and you want to tag all the nodes as towers. >| > >I had a similar problem and used the up-to-dateness from OSMXAPI as a >workaround for that... (checked timestamp inside the xml file of course) > crafty ;-) > >- -- > >Dirk-Lüder "Deelkar" Kreie >Bremen - 53.0952°N 8.8652°E ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Wide tracks with cycle access
Karl Eichwalder wrote: >Sent: 01 May 2008 7:36 AM >To: 80n >Cc: talk@openstreetmap.org >Subject: Re: [OSM-talk] Wide tracks with cycle access > snip > >Wondering whether using surface=gravel is already understood by the >renderers? Thus far, I was using "unpaved" exclusively. I too have been using "unpaved" to date and will continue to do so, however I accept that in some instances I also want to state what the surface is made up of and haven't really got to grips with that for unpaved surfaces. Paved surfaces are easy enough (including those covered with chippings). These type of scenarios crop up: Farm tracks in Norfolk where dry sand fills the ruts making cycling near on impossible. Farm tracks in Cumbria where natural boulders and cobbles protrude regularly through the surface. Tracks that have had potholes filled in with railway ballast. These are just a few scenarios, none of which I find an easy way to tag, thus to date I have ignored doing so. Cheers Andy > >-- >Karl Eichwalder > > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Selecting nodes on a way
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OJ W schrieb: | Is it possible in JOSM to select all the nodes on a way? e.g. if you | have a long power line and you want to tag all the nodes as towers. | I had a similar problem and used the up-to-dateness from OSMXAPI as a workaround for that... (checked timestamp inside the xml file of course) - -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIGYkKFUbODdpRVDwRArKWAJ9a0PeZ0I5qPWsjWP+zLG3XAfTrSACfadEZ FOqg+41oupXEUa3g+TBZKVs= =37B4 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapnik viewer for OSM data - UI suggestions?
>> One of the OSM projects I'm hoping to work on is a Mapnik GUI renderer for >> ..osm files (and live API data, cached locally, and PostGIS databases), >> based on the Mapnik viewer. However what would be good is to get some user >> interface suggestions from people. The aim is to try and make it as easy >> as possible for people to render, and print, custom Mapnik maps. >Are you asking people which of Mapnik's many knobs you think need >exposing in your UI? Or have you chosen a set of knobs but want to know >how best to present those capabilities in a usable way? >If the former, where can we find a list of knobs to choose from? If the >latter, which knobs have you chosen? My idea is to try and shield the user from the XML file altogether. Rather than get a user to open an XML file, I'd like users to be able to simply open an OSM file, download data from the API, or retrieve data from a PostGIS database, and then use the UI to define styles for OSM key/value combinations. Ideally also I'd like users to be able to select high level types (which map to certain key/value combinations) as Potlatch already does. I'd also like an "OSM browser" mode, where a user can pan the map and new data gets downloaded from the API, and then cached locally. I'd also like the users to be able to define, and order, layers for their map. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] railways/roads/canals/rivers/etc. inside buildings
Robin Paulson wrote: >Sent: 30 April 2008 10:27 PM >To: talk@openstreetmap.org >Subject: [OSM-talk] railways/roads/canals/rivers/etc. inside buildings > >a situation has come up, where i've been mapping some railway lines >that go through a maintenance shed. the problem is, the railway is >drawn on top of the shed, rather than shown dotted too imply it's >underneath/inside. is there a tag i could use, to show that it's >inside? something like the tunnel tag If you want it dashed I think the only option is to set the section as if it's in a tunnel (effectively it is). Alternatively you can hide the section completely by rendering the shed over the top of the railway by appropriate use of the layer tag. they are the only options I know of right now and cant really think of a good alternative anyway. Cheers Andy > >http://openstreetmap.org/?lat=-36.88633&lon=174.76474&zoom=15&layers=B0FT > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Selecting nodes on a way
Is it possible in JOSM to select all the nodes on a way? e.g. if you have a long power line and you want to tag all the nodes as towers. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
