[OSM-talk] topomaps in qct file format
I have several copyright-free topomaps in qct format I plan to trace roads for OSM Philippines . Any ideas how I can convert them into a georectified raster like geotiff? -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] just feels like time for a poem
I will not confirm or deny the cake rumor! -Mikel (phone) On Mar 26, 2009, at 16:40, Łukasz Jernaś wrote: 2009/3/26 Simon Ward : On Thu, Mar 26, 2009 at 03:31:51PM +, John McKerrell wrote: edible map? nom nom nom Cake! \o/ The cake is a lie! -- Łukasz [DeeJay1] Jernaś ___ 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] just feels like time for a poem
2009/3/27 Łukasz Jernaś > 2009/3/26 Simon Ward : > > On Thu, Mar 26, 2009 at 03:31:51PM +, John McKerrell wrote: > >> edible map? nom nom nom > > > > Cake! \o/ > > The cake is a lie! > Pie? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - Voting - (man_made=dyke)
On Thu, Mar 26, 2009 at 8:25 PM, Sam Vekemans wrote: > Hi all, > It looks like this tag also could be set to a vote, i think there is > agreement that it gets spelled this way, as the OSM standard is for > british english, ... and not a "waterway" because it is man_made and > usually concrete.. like a 'dam' yet it's purpose is not to retain > water from flowing into a river. .. > For some reason in the canvec feature set it's also listed as an area, > perhaps it could be if the dyke was wide enough to be used for other > purposes (such as a trail, if it was covered in gravel) It would indeed be an area here in Clemson, SC where we have two dikes that each have a track on top of them. They are actually quite large because of the long slopes on the non-water side. Cheers, Adam > http://wiki.openstreetmap.org/wiki/Proposed_features/Dyke > > Anyway i think it's ready for a vote, it's been over a year. > > Cheers, > Sam > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap in "The Times - atlas of the world" book
Hi all, i just wanted to let you all know that on page 57 of this big atlas book, openstreetmap is listed! (a big heavy book) So kids studing geography will see it! Its ISBN 978 0 00 7236701 - "The greatest book on earth" www.timesatlas.com twelfth edition 2007 -it shows "collaborative mapping of Bedford, UK" This makes me excited because by the end of this year, all of Canada will be complete! Have a great day! Sam Vekemans Across Canada Trails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] man_made=fish passage (tag proposal too)
Thanks, just in comparing GeoBase with TIGER, its handy to keep consistant (as much as possable) Sam On 3/26/09, Ævar Arnfjörð Bjarmason wrote: > On Fri, Mar 27, 2009 at 12:43 AM, Sam Vekemans > wrote: >> I think it's worth creating a tag for a man_made=fish_passage >> [...] >> I know that not all features that are available MUST get imported >> but i do think that each feature deserves some discussions before >> being dismissed >> >> Any comments? > > Just that regardless of what you call this particular feature, be it > man_made=fish_passage or man_made=xyyz you should, when in doubt, just > go ahead and make something up when importing external datasets > instead of dropping it from the import. > > A tag is created as soon as you start using it, it can always be > discussed further or changed later, the data being there is the > important part. > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] man_made=fish passage (tag proposal too)
On Fri, Mar 27, 2009 at 12:43 AM, Sam Vekemans wrote: > I think it's worth creating a tag for a man_made=fish_passage > [...] > I know that not all features that are available MUST get imported > but i do think that each feature deserves some discussions before > being dismissed > > Any comments? Just that regardless of what you call this particular feature, be it man_made=fish_passage or man_made=xyyz you should, when in doubt, just go ahead and make something up when importing external datasets instead of dropping it from the import. A tag is created as soon as you start using it, it can always be discussed further or changed later, the data being there is the important part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] man_made=fish passage (tag proposal too)
Hi, Just looking at the http://wiki.openstreetmap.org/wiki/National_Hydrography_Dataset which is similar to the Canadian http://wiki.openstreetmap.org/wiki/GeoBaseNHN_Map_Features dataset, There are a few other features also, that it would be worth some discussion to see if i should be adding these also Your help is needed. I think it's worth creating a tag for a man_made=fish_passage (personally, i like 'passage, rather than ladder' describing what the feature DOES than what the feature IS. 8 Fish LadderA constructed series of pools arranged like steps to enable fish to pass an obstacle. Fish ladders are also referred to as fish ways, fish passes, and fish passage facilities. I know that not all features that are available MUST get imported but i do think that each feature deserves some discussions before being dismissed :-) ... valid reasons (and posting them) are good enough for me :-) Any comments? Thanks, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Square gridlines appeared on slippy map
On Thu, 2009-03-26 at 15:42 +, Ed Avis wrote: > On the OSM front page the map now has what look like square gridlines, making > Greenland look made out of graph paper. Is this a permanent change? > > The pattern of the grid is square throughout the map, which doesn't match the > Mercator projection, so what are they intended to show? No. It is what happens if you generate the coastline shapefiles with the default parameters. I have fixed it to use the larger overlap but it might take a couple of days for them to re-render. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - (man_made=dyke)
Hi all, It looks like this tag also could be set to a vote, i think there is agreement that it gets spelled this way, as the OSM standard is for british english, ... and not a "waterway" because it is man_made and usually concrete.. like a 'dam' yet it's purpose is not to retain water from flowing into a river. .. For some reason in the canvec feature set it's also listed as an area, perhaps it could be if the dyke was wide enough to be used for other purposes (such as a trail, if it was covered in gravel) http://wiki.openstreetmap.org/wiki/Proposed_features/Dyke Anyway i think it's ready for a vote, it's been over a year. Cheers, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - (man_made=breakwater)
Hi all, It looks like this feature is ready for voting (sorry, im not yet an expert in the process) :-) and has been for some time, the wiki help page says 2 weeks... it's been 2 years :-) Am i supposed to post a comment on the original contributors page? (to get it moving faster) Cheers, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Best for routing ? [Implementing driving directions like Google Maps-with text assistance]
You could also try CloudMade Routing API. http://developers.cloudmade.com/projects/show/routing-http-api It is based on OSM data, so when you add roads, it will give you more exact result. This routing API is very fast, simple, and has some convenient options like result type (the fastest or the shortest), transport type (bicycle, pedestrian, car) and transit points. You could see the results here http://maps.cloudmade.com Just press "Get direction" and set points "A" and "B". There are bindings of Routing API in Java, Ruby and Python languages. More programming languages are coming soon. Regards, Igor 2009/3/26 rajan vaish > Hi,For a project in my mind,which implements driving directions like > Google Maps ,as in, along with route on map,we get text along the same > describing the path/route from the source to destination,step by step.What > do you guys think will be the best routing technique/library/API ? > (language not a problem at all) . > > I have been exploring OSM Routing page and related for more than an hour > now,and came across some very cool stuff,but since there are so many,wanted > to get feedback to help me choose to best for the purpose. Also,I found many > Sourceforge links broken/empty,which stopped me from further exploring. > I totally understand the need of OSM Tags for Routing everywhere. So,there > are various libraries which caught my attention : > 1- OSMNavigation and LibOSM. > 2- GraphServer . > 3-Pyroute Lib. > I also explored YOURS and ORS .Under ORS,its mentioned about ORS APIs which > seems very cool,on getting desired results through URL manipulation,however > ,it does not solves the purpose to grab the name of streets ,exact > directions etc which can be converted into text,which is what I want.I have > attached a snapshot of google maps,with text in left explaining the > route,something which I intend to implement. > > Will greatly appreciate any help or guidance,regarding the same.Thank you. > Rajan > > ___ > dev mailing list > d...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] just feels like time for a poem
2009/3/26 Simon Ward : > On Thu, Mar 26, 2009 at 03:31:51PM +, John McKerrell wrote: >> edible map? nom nom nom > > Cake! \o/ The cake is a lie! -- Łukasz [DeeJay1] Jernaś ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] just feels like time for a poem
On Thu, Mar 26, 2009 at 03:31:51PM +, John McKerrell wrote: > edible map? nom nom nom Cake! \o/ Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] The Jon Burgess edit of osm2pgsql.exe disappeared
Jon Burgess wrote: > On Thu, 2009-03-26 at 17:44 +, Jukka Rahkonen wrote: >> Hi, >> >> Jon Burgess compiled sometimes in November 2008 Windows executable of >> osm2pgsql. >> It used to be at http://tile.openstreetmap.org/direct/osm2pgsql.zip but now >> it >> has been disappeared. Does anybody know where to find it now? >> >> -Jukka Rahkonen- > It moved to: > http://tile.openstreetmap.org/osm2pgsql.zip > Jon Thanks. There was another Windows looser asking for help in OSM forum, I hope this helps him in importing some extra tags into PostGIS. -Jukka- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Jon Burgess edit of osm2pgsql.exe disappeared
On Thu, 2009-03-26 at 17:44 +, Jukka Rahkonen wrote: > Hi, > > Jon Burgess compiled sometimes in November 2008 Windows executable of > osm2pgsql. > It used to be at http://tile.openstreetmap.org/direct/osm2pgsql.zip but now > it > has been disappeared. Does anybody know where to find it now? > > -Jukka Rahkonen- It moved to: http://tile.openstreetmap.org/osm2pgsql.zip Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Best for routing ? [Implementing driving directions like Google Maps-with text assistance]
Hi,For a project in my mind,which implements driving directions like Google Maps ,as in, along with route on map,we get text along the same describing the path/route from the source to destination,step by step.What do you guys think will be the best routing technique/library/API ? (language not a problem at all) . I have been exploring OSM Routing page and related for more than an hour now,and came across some very cool stuff,but since there are so many,wanted to get feedback to help me choose to best for the purpose. Also,I found many Sourceforge links broken/empty,which stopped me from further exploring. I totally understand the need of OSM Tags for Routing everywhere. So,there are various libraries which caught my attention : 1- OSMNavigation and LibOSM. 2- GraphServer . 3-Pyroute Lib. I also explored YOURS and ORS .Under ORS,its mentioned about ORS APIs which seems very cool,on getting desired results through URL manipulation,however ,it does not solves the purpose to grab the name of streets ,exact directions etc which can be converted into text,which is what I want.I have attached a snapshot of google maps,with text in left explaining the route,something which I intend to implement. Will greatly appreciate any help or guidance,regarding the same.Thank you. Rajan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
On 26/03/2009 17:14, Richard Mann wrote: > highway=cycleway+designation=public_bridleway does the job with the > minimum of fuss. and requires us either to change the renderers or mislead horse riders. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Richard Mann wrote: > Only the British > use "bridleway". The Dutch have markedly few footways (which probably > indicates "cycleway" is being used quite loosely). My recollection of both urban and rural bits of the Netherlands is that there actually are fewer footways than cycleways - I've had a look at the map of a couple of bits that I'm familiar with (Maarssen, Scherpenzeel and the German border near Enschede FWIW) and (with a couple of exceptions) what's mapped matches pretty much I'd expect to be if the same feature were mapped in the UK. My experience of the Netherlands, Germany and Scandinavia is that it's the UK that's the odd one out in having fewer cycleways than the norm for northwestern Europe. Obviously this has no bearing on whether a particular route in Oxford should be labelled as a bridleway or a cycleway (I've never been there and can't comment). Maybe arrange a meeting in a local pub and have a show of hands? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
On Thursday 26 March 2009, Richard Mann wrote: > I thought a quick tagwatch of "footway/path/bridleway/cycleway" might > be pertinent. > > Europe: footway 556k - cycleway 166k - path 66k - bridleway 11k > Germany: footway 268k - cycleway 57k - path 45k - bridleway 1k > Netherlands: footway 19k - cycleway 38k - path 1k - bridleway 0k > Great Britain: footway 116k - cycleway 14k - path 2k - bridleway 8k > > The Dutch aren't using "path" at all, and the British not much. > Unfortunately tagwatch doesn't seem to cover Wisconsin. Only the > British use "bridleway". The Dutch have markedly few footways (which > probably indicates "cycleway" is being used quite loosely). I've often seen highway=pedestrian where footway/cycleway/path would be more appropriate in the Netherlands, some relic of the AND import. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
On Thu, 2009-03-26 at 14:43 +, Andy Allan wrote: > On Thu, Mar 26, 2009 at 12:00 PM, Shaun McDonald > wrote: > > This is the weekly re-import of the data, when the render daemon is > > stopped for the duration. > > I'm not entirely sure that it is, especially since I'd have expected > it to restart yesterday morning (or maybe this morning - again, not > sure when Jon does things). But looking at the munin graphs [1] I can > see that the eth0 load is high, the CPU has been flat out earlier > today, and the load average is spiking pretty high too. There was a spike in the number of Apache threads and render daemon crashed when it used up all 1024 available file descriptors. I have known about this for a while, the render daemon has hit this a couple of times over the past year. I have restarted the process with the ulimit on the descriptors raised to 4096. Longer term I think I either need rethink how we handle >1k Apache connections or make the process increase the descriptors itself. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] The Jon Burgess edit of osm2pgsql.exe disappeared
Hi, Jon Burgess compiled sometimes in November 2008 Windows executable of osm2pgsql. It used to be at http://tile.openstreetmap.org/direct/osm2pgsql.zip but now it has been disappeared. Does anybody know where to find it now? -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
I thought a quick tagwatch of "footway/path/bridleway/cycleway" might be pertinent. Europe: footway 556k - cycleway 166k - path 66k - bridleway 11k Germany: footway 268k - cycleway 57k - path 45k - bridleway 1k Netherlands: footway 19k - cycleway 38k - path 1k - bridleway 0k Great Britain: footway 116k - cycleway 14k - path 2k - bridleway 8k The Dutch aren't using "path" at all, and the British not much. Unfortunately tagwatch doesn't seem to cover Wisconsin. Only the British use "bridleway". The Dutch have markedly few footways (which probably indicates "cycleway" is being used quite loosely). I have a hunch the German use of "path" is for non-obligatory (ie not fully signed) cycle tracks, since the tagging of these is a particular problem in Germany, but that's just a hunch (please advise anybody). Why do I privilege cycleway over bridleway, given a conflict - see tagwatch. Bridleway is just an interesting GB historical accident. Why do I think highway=bridleway+surface=something is inadequate to tag Willow Walk - because there are 16 cited values for surface (and you'd have to look at tracktype & smoothness too). Whereas highway=cycleway+designation=public_bridleway does the job with the minimum of fuss. Richard (West Oxford) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Thanks Richard - my oops! _ From: Richard Mann [mailto:richard.mann.westoxf...@googlemail.com] Sent: 26 March 2009 15:37 To: Mike Harris Subject: Re: [OSM-talk] highway=cycle&footway Oops, slipped off including "talk". I've forwarded my last to the list; you may like to do so also... Richard On Thu, Mar 26, 2009 at 3:11 PM, Mike Harris wrote: Richard - again helpful - after reading your comments I think the main area of disagreement between Dave and me is the around the use of highway=path. I am sure I have read somewhere (wiki, mailing lists?) a fairly strong plea to minimise the use of highway=path whenever something more specific (such as highway=footway) is available? Perhaps someone has a better memory than I do? This is one of three reasons why I have tended to favour highway=footway for ways that are clearly unsuitable for more than pedestrian traffic. By observation of the developing map itself - and also from the mailing lists - a second reason might be that there seem to be two schools of thought around the meaning of 'path': those who regard it as something less well-defined on the ground than a 'footway' and those - apparently like yourself - who see it as something 'more than just a footway'. I've taken the middle course of avoiding it wherever possible -- at least where there is an alternative tag for which there seems to be more consistency in established practice - and keeping =path for vague paths that are 'there' but are not public footpaths. Maybe I'm wrong! But who's right? My third reason for avoiding highway=path is that someone could walk a route one day and find that the path has not been reinstated across a ploughed field or a crop. If this is a public footpath, pressure (and ultimately legal action) will be used - sooner or later - by the highway authority. The landowner may then reinstate and the path may become very clear indeed - even a day or two later. Also, in many cases a farmer is allowed a grace period (conditions too complex to matter here!) before reinstating. So a judgement based on lack of reinstatement - as Dave seems to suggest - while objective, may be very ephemeral - and I'm hoping our maps are of lasting value! As I've already said, I'm in agreement with Dave on several of his points and am pretty much in agreement with the points that you are now making (other than on =path). I would certainly vote against highway=cycle&footway as this can be done with foot= and bicycle= - as seems usually to be existing practice. I would also probably vote against highway=cycleway + cycleway=shared as I can expect arguments galore as to whether it is highway=cycleway cycleway=shared (cycling viewpoint) or highway=bridleway and bridleway=shared (equestrian viewpoint) etc. ad nauseam! I still feel that cycleway is only well-defined in a limited set of cases that I have mentioned earlier (with the usual grey area round the edges! - of the definition, that is, not the cycleway (:>)) and that beyond these cases the use of this tag does indeed tend to become somewhat subjective according as the mapper is primarily a cyclist, walker or horse rider! Mike (Cheshire) _ From: Richard Mann [mailto:richard.mann.westoxf...@googlemail.com] Sent: 26 March 2009 12:58 To: Mike Harris Subject: Re: [OSM-talk] highway=cycle&footway Before we all get too depressed, I think I agree with both of you (Dave / Mike) that any changes to tagging should be backwardly-compatible, as far as practical (or at least minimise the "wrongness" if the old tagging is unchanged). But we also need a scheme that is simple, effective and shows what's on the ground, not just what's on the sign. I think the nub of it is the tagging of path/bridleway/cycleway. I think "path" serves a useful function for ways that are more than just footways, but where usage/access for horses/mtb/bicycles is uncertain. I think "bridleway" serves a useful function in those countries where access for horses is well-established (and thereby is becomes a useful shorthand for highway=path+designation=public_bridleway), but in practice there may be little to distinguish a bridleway from a path (and there might be sense in rendering them quite similarly). Whereas, highway=cycleway is an explicit assertion that the surface is somewhat better than you might expect on a bridleway/path, without going into the minefield of the multiple values that might be tagged for tracktype/surface/smoothness. I think I'm concluding that highway=cycle&footway is unnecessary; perhaps highway=cycleway+cycleway=shared would be a better bet (and leave it to the renderers whether they do anything with that). But if highway=cycleway is to be used for shared cycleways, then the wiki definition will need to be more inclusive than currently. Richard (West Oxford) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
On 26/03/2009 15:35, Richard Mann wrote: > Before we all get too depressed, I think I agree with both of you (Dave > / Mike) that any changes to tagging should be backwardly-compatible, as > far as practical (or at least minimise the "wrongness" if the old > tagging is unchanged). > > But we also need a scheme that is simple, effective and shows what's on > the ground, not just what's on the sign. Fine, but put it in a new tag or tags rather than changing the meaning of the existing ones from objective to subjective. A subjective judgement about surface quality doesn't make something a bridleway or a cycleway (any more than the narrowness of some Scottish roads doesn't suddenly make them not primary). Though I know you're thinking about other factors, surafce quality already has a tag for it. So if something is signed as a cycleway but really doesn't have the surface quality to support it (in your judgement), that doesn't make it not a cycleway. The original designation stuff arose where the sign contradicts the actual legal status (something signed e.g. as primary when information from the local council or whatever says no, that's not true). I know it's not always obvious and sometimes there are value judgements to be made when there is no other evidence to support something, but if the sign says bridleway, that is what it is and should be recorded as. Any data consumer should know that in that location, bridleways are legally usable by bikes and if surface is set properly, can assume it is or isn't suitable for cycling and act appropriately. If you're rendering a cycle map, you may well choose to render bridleway with a good surface in the same style as something marked cycleway. Why do you think cycleways are special in some way? primary roads are shared too - cycles, horses and usually pedestrians too can use them. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] just feels like time for a poem
>edible map? nom nom nom It's hard to see how an inedible map could be "deliciously open". :-) On 26 Mar 2009, at 15:11, Mikel Maron wrote: > > > ooo-dee-bee-ell > sure does feel like hell! > lightning rods, lengthy flames > where we going to assign the blame? > hey! forget the naming names > finger points all out of joint > > again > > eye-aaa-enn-aaa-ell > doesn't that ring your bells? > a little courtesy, tip of the hat > forget the fail, go lolcat > > we have the freely edible map > deliciously open, not proprietary crap > it is made by people like you > only need a license true > to our free hopes and dreams > and OSM will reign supreme > > -mikel > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Square gridlines appeared on slippy map
On the OSM front page the map now has what look like square gridlines, making Greenland look made out of graph paper. Is this a permanent change? The pattern of the grid is square throughout the map, which doesn't match the Mercator projection, so what are they intended to show? -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Before we all get too depressed, I think I agree with both of you (Dave / Mike) that any changes to tagging should be backwardly-compatible, as far as practical (or at least minimise the "wrongness" if the old tagging is unchanged). But we also need a scheme that is simple, effective and shows what's on the ground, not just what's on the sign. I think the nub of it is the tagging of path/bridleway/cycleway. I think "path" serves a useful function for ways that are more than just footways, but where usage/access for horses/mtb/bicycles is uncertain. I think "bridleway" serves a useful function in those countries where access for horses is well-established (and thereby is becomes a useful shorthand for highway=path+designation=public_bridleway), but in practice there may be little to distinguish a bridleway from a path (and there might be sense in rendering them quite similarly). Whereas, highway=cycleway is an explicit assertion that the surface is somewhat better than you might expect on a bridleway/path, without going into the minefield of the multiple values that might be tagged for tracktype/surface/smoothness. I think I'm concluding that highway=cycle&footway is unnecessary; perhaps highway=cycleway+cycleway=shared would be a better bet (and leave it to the renderers whether they do anything with that). But if highway=cycleway is to be used for shared cycleways, then the wiki definition will need to be more inclusive than currently. Richard (West Oxford) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] just feels like time for a poem
edible map? nom nom nom On 26 Mar 2009, at 15:11, Mikel Maron wrote: > > > ooo-dee-bee-ell > sure does feel like hell! > lightning rods, lengthy flames > where we going to assign the blame? > hey! forget the naming names > finger points all out of joint > > again > > eye-aaa-enn-aaa-ell > doesn't that ring your bells? > a little courtesy, tip of the hat > forget the fail, go lolcat > > we have the freely edible map > deliciously open, not proprietary crap > it is made by people like you > only need a license true > to our free hopes and dreams > and OSM will reign supreme > > -mikel > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-legal-talk] just feels like time for a poem
ooo-dee-bee-ell sure does feel like hell! lightning rods, lengthy flames where we going to assign the blame? hey! forget the naming names finger points all out of joint again eye-aaa-enn-aaa-ell doesn't that ring your bells? a little courtesy, tip of the hat forget the fail, go lolcat we have the freely edible map deliciously open, not proprietary crap it is made by people like you only need a license true to our free hopes and dreams and OSM will reign supreme -mikel ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] more OSM coming soon
On Thu, Mar 26, 2009 at 12:00 PM, Shaun McDonald wrote: > This is the weekly re-import of the data, when the render daemon is > stopped for the duration. I'm not entirely sure that it is, especially since I'd have expected it to restart yesterday morning (or maybe this morning - again, not sure when Jon does things). But looking at the munin graphs [1] I can see that the eth0 load is high, the CPU has been flat out earlier today, and the load average is spiking pretty high too. Mod_tile has a load average cutout where it stops trying to render tiles in the few seconds it normally gives renderd to respond (hence the usual few seconds before the "coming soon" logo appears. When that threshold is exceeded, mod_tile responds immediately with a 404 (and the osm.org Javascript shows the "coming soon" logo straight away). I don't know what the threshold is on tile.openstreetmap.org So a fair amount of speculations - the server is busy, but not that much more busy than it normally gets during the week, and I think it's triggering the mod_tile overload protection. Cheers, Andy [1] http://munin.openstreetmap.org/openstreetmap/tile.openstreetmap.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
David I'm not sure I understand your comment. What is avoidably subjective? The highway= tags and the foot/bicycle/horse= tags are all based on what is observable objectively on the ground - either physical or signage (supplemented sometimes by local knowledge of legal status - also objective). The only thing that I can see in my practice that could be described as subjective is my use of the tracktype= tag. This tag is listed in the wiki (which is why I use it) and I use only the values listed in the wiki, with the definitions listed in the wiki, as to track grade. This is technically partly subjective I suppose - but no more so than for anyone else using tracktype= as a tag (or - dare I say for fear of starting another war - smoothness= ). In what way do you see my use of highway= tags as being subjective? I am sticking to the definitions in the wiki - just using all of the objectively available information. I find it a little hard to be accused of "undermining work done so far" when I have put so much effort into surveying and mapping the off-road routes in my area - and have at every stage consulted through the mailing lists when in doubt as to tagging practice - and indeed willingly adapted my practice in the light of good advice received. There are bound to be minor differences in approach in any wiki system - all in good faith - and I am currently feeling somewhat demotivated. Perhaps that was not your intention but it is unfortunately the result ... (:<) Mike -Original Message- From: David Earl [mailto:da...@frankieandshadow.com] Sent: 26 March 2009 09:48 To: talk@openstreetmap.org Subject: Re: [OSM-talk] highway=cycle&footway On 26/03/2009 09:29, Mike Harris wrote: > Richard > > Thanks for this ... very helpful - a few comments - > > 1. Path: I would prefer to use highway=footway for a path that has > (almost always illegally) not been reinstated across a ploughed field > IF ... I think by trying to switch the interpretation of the highway=... tags from an objective recording of what the signs say to a subjective one of some personal measure of "suitability" you are undermining the work that's been done one the map so far. If you want to include subjective value judgements, I really think you should do that in tags invented for the purpose, not undermine the existing ones. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] more OSM coming soon
Thanks, though I can't say I've noticed it before. cheers, Chris - Original Message > From: Shaun McDonald > To: Chris Hill > Cc: Talk OSM > Sent: Thursday, 26 March, 2009 12:00:04 > Subject: Re: [OSM-talk] more OSM coming soon > > This is the weekly re-import of the data, when the render daemon is stopped > for > the duration. > > Shaun > > On 26 Mar 2009, at 11:45, Chris Hill wrote: > > > > > I've been getting a lot of tiles with the 'more OSM coming soon' message on > Mapnik, both yesterday and today at various zoom levels. The tiles appear > quickly rather than after a long delay as occasionally happens. Is anyone > else > seeing this? Does it need attention? > > > > cheers, Chris > > > > > > > > > > > > ___ > > 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] more OSM coming soon
This is the weekly re-import of the data, when the render daemon is stopped for the duration. Shaun On 26 Mar 2009, at 11:45, Chris Hill wrote: > > I've been getting a lot of tiles with the 'more OSM coming soon' > message on Mapnik, both yesterday and today at various zoom levels. > The tiles appear quickly rather than after a long delay as > occasionally happens. Is anyone else seeing this? Does it need > attention? > > cheers, Chris > > > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] more OSM coming soon
I've been getting a lot of tiles with the 'more OSM coming soon' message on Mapnik, both yesterday and today at various zoom levels. The tiles appear quickly rather than after a long delay as occasionally happens. Is anyone else seeing this? Does it need attention? cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tactile Paving - Pflastersteine für B lindenstöcke
Hello, please have a look at http://wiki.openstreetmap.org/wiki/Proposed_features/Tactile_paving Thanks. Lulu-Ann -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] i-gotU GPS logger and Linux: bad news
Hi, > During the recent Perugia Mapping Party, Cristiano Givando bought > us a batch of [1] i-gotU GPS logger. > > I tried to use them in Linux, but with no luck till now. Igotu2gpx 0.1.1 has been released. Igotu2gpx is a linux command line program to dump the internal flash of the gps tracker and decode the stored tracks and waypoints. It uses libusb, so you shouldn't use the navman kernel module. Changes in 0.1.1: - more reliable usb connection to the gps tracker - new command line paramter --verify to get an idea what data is sent to the gps tracker - Debug messages are send to stderr per default Homepage: https://launchpad.net/igotu2gpx Source tarballs are available from https://launchpad.net/igotu2gpx/+download Ubuntu packages are available from https://launchpad.net/~igotu2gpx/+archive Report bugs at https://bugs.launchpad.net/igotu2gpx Let me know how it goes. Comments, contributions, bugs, bug fixes and feature requests welcome! Best regards Michael ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
On 26/03/2009 09:29, Mike Harris wrote: > Richard > > Thanks for this ... very helpful - a few comments - > > 1. Path: I would prefer to use highway=footway for a path that has > (almost always illegally) not been reinstated across a ploughed field IF ... I think by trying to switch the interpretation of the highway=... tags from an objective recording of what the signs say to a subjective one of some personal measure of "suitability" you are undermining the work that's been done one the map so far. If you want to include subjective value judgements, I really think you should do that in tags invented for the purpose, not undermine the existing ones. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Richard Thanks for this ... very helpful - a few comments - 1. Path: I would prefer to use highway=footway for a path that has (almost always illegally) not been reinstated across a ploughed field IF I know it to be a public right of way, e.g. from the black and yellow waymarks that people like me put onto public footpaths! (After all, after intervention this path may well get restored to its legal condition!) Similarly for other situations where the path is not good or clear but IS waymarked as a public footpath. I would tend to minimise usage of highway=path - and use it mostly for paths that are not well-defined and not known to be a right of way - typically in rural or upland areas. I would not add foot=yes - as, if I know this to be true, I would then be using highway=footway. Most rural public footpaths are not easily seen on the ground - but most are waymarked at intervals; I want to give these highway=footway status to distinguish them from informal paths - which are also numerous in undeveloped and unfarmed rural areas. 2. Footway: I broadly agree. I would also use this for any way that is clearly unsuitable for higher levels of user (cyclists, horses, etc.) and known (e.g. from signage or otherwise) to be a public footpath - urban or rural. I would add foot=yes. 3. Bridleway: I only use this for ways that I know to be a public bridleway (and thus have rights for pedestrians, horse riders and - almost always - cyclists). This is because the word 'bridleway' has legal meaning (in England and Wales) - unlike 'footway'. If I do not know (from blue and yellow signage or otherwise) that it is a public bridleway I would tend to use only highway=track and add a tracktype= tag to indicate the surface for the benefit of cyclists etc. (I don't wish to imply a legal right by using the tag 'bridleway' unless I know this to be true). I would add foot=yes, bicycle=yes (unless known to be untrue) and horse=yes. 4. Cycleway: In the countryside I tend to use this for paths that are clearly physically suitable for, and are signed for, cyclists and seem on the ground to have been primarily created as a cycle route but are not known to be public bridleways (where I would give precedence to highway=bridleway as a more well-defined category). I would also use it in urban areas for appropriately blue signed cycle paths and also for dedicated cycle tracks more or less alongside roads etc. (As said before I would not regard ncn/rcn etc. as a reason for highway=cycleway - I would use a relation for this). I would add foot=yes (unless known to be untrue) and bicycle=yes. 5. Track: Broadly agree - unless the track is known (e.g. from signage) to be a public bridleway - in which case I would prefer to use the more well defined highway=bridleway. I also usually try to add a tracktype= tag (grade1 to grade5) as per the wiki to give a bit more information about the surface (and thus suitability for various types of user) - where I have recorded or remember this from the survey. I would not add foot/horse/bicycle=yes etc. unless known to be true. 6. Byway: I also use the tag highway=byway for tracks that are known, e.g. from plum or red signage or from finger posts (or from personal knowledge in my area) to be a 'Restricted Byway' (RB, the term that has replaced 'Road Used as Public Path' or RUPP - no longer exist) or a 'Byway Open to all Traffic' (BOAT) - again adding tracktype= if possible. I would add foot=yes, horse=yes, bicycle=yes. For a RB I might add motorcar=no, motorcycle=no if it looked as if it could be driven but was signed as an RB (i.e. motorised traffic banned). For a BOAT I would stay silent on motorcar/motorcycle= unless I had specific local knowledge as the use of a BOAT by motorised traffic is defined on a case by case basis. In summary: Despite the length of my response, I do not think we are very far apart. Where there is no signage (and no other non-copyright way to determine legal status) I would be in pretty close agreement with you. Where there is additional evidence regarding legal status I would generally try to use this - in particular (a) to add the information that a path is in fact a public footpath (highway=footway, foot=yes) rather than just a 'path' (highway=path), (b) to avoid highway=bridleway unless I had evidence that it was a public bridleway (because 'bridleway' - unlike 'footway' - carries legal implications), (c) to use 'track' in a parallel way to 'path' - i.e. to distinguish a track that is known to be a public right of way of some kind (by using highway=bridleway or highway=byway), (d) to add the use of highway=byway for known RBs and BOATs. I am obviously a bit biased by being one of the people who spend time putting up those multi-coloured waymarks on public rights of way of various kinds! I have found this exchange very useful and will be continuing to strive to get the balance right between 'basic physical status' and 'rights' information drawn from sig
[OSM-talk] Proposed feature: natural=rocks
Hi, proposed feature: natural=rocks this is related to waterways & waterbodies these are mostly nodes & areas. Good for water navigation. Is there another tag already in use that would do the same thing? Thanks, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
