Re: [Talk-transit] Naptan import
Plusbus zones are polygons which are unrelated to the road network - so for Rye it covers a large polygon defined by straight lines linking each pair of adjacent nodes on the source list of defining points. The representation of this along the roads is inappropriate - and certainly not how it should be should be shown in terms of the zone definition intended. The Rye example is a particularly extreme example, as there are few roads in the area with bus routes - and lots of marshland and open countryside covered by the Plusbus zone. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme Sent: 02 August 2009 00:24 To: Thomas Wood Cc: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Naptan import Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/30 Christoph Böhme christ...@b3e.net: Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/29 Christoph Böhme christ...@b3e.net: I transformed the Plusbus Zones into a josm-file (XSLT is cool :-). Thomas can you import it using the naptan-user if no one objects to the tagging scheme? http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz Cheers, Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit That looks fine, the only issue is that none of the polygons are closed! Oh, good that you noticed this. I fixed the file and uploaded it again. Christoph I have run JOSM's validator over it to clean up some duplicate ways, and the more obviously incorrect polygon geometries (West Mids had a weird doubleback by the look of it) a few have overlapping segments, but I've chosen to ignore their 'errorness'. http://www.openstreetmap.org/browse/changeset/2008301 Good idea to use JOSM's validator, I should have done it myself ... The incorrect geometries are converted directly from the NPTG data. Some of the polygons there have duplicate nodes. Removing the duplicate nodes was a sensible choice, I think. I had a look at the very distorted Plusbus Zone for Rye. Its strange shape seems to stem from the fact that it simple spans four villages and follows the road between them. I think there are similar reasons for the other errors. Thank you checking and importing the changeset! Christoph -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
Roger Slevin ro...@slevin.plus.com schrieb: Plusbus zones are polygons which are unrelated to the road network - so for Rye it covers a large polygon defined by straight lines linking each pair of adjacent nodes on the source list of defining points. The representation of this along the roads is inappropriate - and certainly not how it should be should be shown in terms of the zone definition intended. The representation of the plusbus zones in OSM is still as it should be. Except for merging duplicate nodes they are the same as defined in the NPTG data. I just tried to describe why the zone for Rye has such an unusual shape compared to other zones. I didn't modify it to actually follow the roads. Sorry for causing confusion! Christoph The Rye example is a particularly extreme example, as there are few roads in the area with bus routes - and lots of marshland and open countryside covered by the Plusbus zone. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme Sent: 02 August 2009 00:24 To: Thomas Wood Cc: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Naptan import Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/30 Christoph Böhme christ...@b3e.net: Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/29 Christoph Böhme christ...@b3e.net: I transformed the Plusbus Zones into a josm-file (XSLT is cool :-). Thomas can you import it using the naptan-user if no one objects to the tagging scheme? http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz Cheers, Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit That looks fine, the only issue is that none of the polygons are closed! Oh, good that you noticed this. I fixed the file and uploaded it again. Christoph I have run JOSM's validator over it to clean up some duplicate ways, and the more obviously incorrect polygon geometries (West Mids had a weird doubleback by the look of it) a few have overlapping segments, but I've chosen to ignore their 'errorness'. http://www.openstreetmap.org/browse/changeset/2008301 Good idea to use JOSM's validator, I should have done it myself ... The incorrect geometries are converted directly from the NPTG data. Some of the polygons there have duplicate nodes. Removing the duplicate nodes was a sensible choice, I think. I had a look at the very distorted Plusbus Zone for Rye. Its strange shape seems to stem from the fact that it simple spans four villages and follows the road between them. I think there are similar reasons for the other errors. Thank you checking and importing the changeset! Christoph -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import
Christoph Thanks - if that's the case then I need to look again at the definition of this particular zone I had alerted the people who had created the data a long time ago that it could be defined much more simply. So let me check why this hasn't happened. From memory it should only need about 12 points defining a blob rather than the very strange detail that is being defined by the more extensive list of points that I now see is still in the source data. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme Sent: 02 August 2009 11:40 To: talk-transit@openstreetmap.org Subject: Re: [Talk-transit] Naptan import Roger Slevin ro...@slevin.plus.com schrieb: Plusbus zones are polygons which are unrelated to the road network - so for Rye it covers a large polygon defined by straight lines linking each pair of adjacent nodes on the source list of defining points. The representation of this along the roads is inappropriate - and certainly not how it should be should be shown in terms of the zone definition intended. The representation of the plusbus zones in OSM is still as it should be. Except for merging duplicate nodes they are the same as defined in the NPTG data. I just tried to describe why the zone for Rye has such an unusual shape compared to other zones. I didn't modify it to actually follow the roads. Sorry for causing confusion! Christoph The Rye example is a particularly extreme example, as there are few roads in the area with bus routes - and lots of marshland and open countryside covered by the Plusbus zone. Roger -Original Message- From: talk-transit-boun...@openstreetmap.org [mailto:talk-transit-boun...@openstreetmap.org] On Behalf Of Christoph Böhme Sent: 02 August 2009 00:24 To: Thomas Wood Cc: Public transport/transit/shared taxi related topics Subject: Re: [Talk-transit] Naptan import Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/30 Christoph Böhme christ...@b3e.net: Thomas Wood grand.edgemas...@gmail.com schrieb: 2009/7/29 Christoph Böhme christ...@b3e.net: I transformed the Plusbus Zones into a josm-file (XSLT is cool :-). Thomas can you import it using the naptan-user if no one objects to the tagging scheme? http://www.mappa-mercia.org/nptg/plusbuszones.osm.gz Cheers, Christoph ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit That looks fine, the only issue is that none of the polygons are closed! Oh, good that you noticed this. I fixed the file and uploaded it again. Christoph I have run JOSM's validator over it to clean up some duplicate ways, and the more obviously incorrect polygon geometries (West Mids had a weird doubleback by the look of it) a few have overlapping segments, but I've chosen to ignore their 'errorness'. http://www.openstreetmap.org/browse/changeset/2008301 Good idea to use JOSM's validator, I should have done it myself ... The incorrect geometries are converted directly from the NPTG data. Some of the polygons there have duplicate nodes. Removing the duplicate nodes was a sensible choice, I think. I had a look at the very distorted Plusbus Zone for Rye. Its strange shape seems to stem from the fact that it simple spans four villages and follows the road between them. I think there are similar reasons for the other errors. Thank you checking and importing the changeset! Christoph -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [talk-ph] changes of raod types
Pardon my ignorance, but how do you classify road types? In the case of Mindanao Ave compared to Quirino Highway, apparently the former is a wider road so i reclassified the. Anthony From: maning sambale emmanuel.samb...@gmail.com To: talk-ph@openstreetmap.org Date: 08/03/2009 10:06 AM Subject: [talk-ph] changes of raod types I'm not objecting but I'm somehow curious about recent reclassifications of several major roads lately: 1. Portions of Commonwealth from trunk to primary: http://www.openstreetmap.org/?lat=14.66209lon=121.06976zoom=15layers=B000FTF 2. Mindanao Ave from primary to trunk: http://www.openstreetmap.org/?lat=14.67085lon=121.03234zoom=15layers=B000FTF 3. Some parts of Quirino are either primary or trunk: http://www.openstreetmap.org/?lat=14.69974lon=121.03273zoom=15layers=B000FTF 4. MacArthur Hiway from primary to trunk: http://www.openstreetmap.org/?lat=14.6755lon=120.982zoom=15layers=B000FTF If we follow this trend, then I think Roxas Blvd should also be trunk as well: http://www.openstreetmap.org/?lat=14.53551lon=121.00028zoom=15layers=B000FTF Which means Metro Manila roads will be a whole lot greener (in the map at least). PS. Apologies for non-manila members -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] changes of raod types
I suggest that the tags for highway=trunk,primary,secondary,tertiary,unclassified be considered as a function of traffic patterns and not of DOTC designation nor physical appearance or condition. These values should also be considered relative to local traffic patterns. This means that levels will be different in an urban and rural setting: a trunk in Metro Manila does not have to be equivalent in function to a trunk in Nueva Vizcaya. Here are some descriptive interpretations I might suggest (subject to discussion): trunk (rural) : long-distance route to traverse across provinces primary (rural) : mid-distance route to travel between towns in a province secondary (rural) : major streets within rural towns tertiary (rural) : major streets within areas of rural towns unclassified,residential (rural) : other roads in rural towns trunk (urban) : long-distance route across the metropolis primary (urban) : major road within a metropolitan city secondary (urban) : mid-level road within a metropolitan city tertiary (urban) : minor road in a metropolitan city unclassified,residential (urban) : other roads in metropolitan cities I'll admit that I have no fixed idea as to how to tag roads such that relative functional importance within Metro Manila (Cebu, Davao) is consistent when you get outside Metro Manila (Cebu, Davao). The problem is that in urban areas, the road density is so high such that we need to differentiate the roads a lot, whereas in rural areas, the density is low. For Metro Manila, EDSA and *parts* of C-5 are definitely trunk. Commonwealth, Quirino (QC) and McArthur Highway are arguably trunk. Quezon Avenue-Espana, Aurora-Marcos Highway, Ortigas-Ortigas Ext., Quirino (Manila), and Roxas Blvd are not so clear. What do you guys think? On Mon, Aug 3, 2009 at 10:22 AM, anthony.bal...@neraphil.com.ph wrote: Pardon my ignorance, but how do you classify road types? In the case of Mindanao Ave compared to Quirino Highway, apparently the former is a wider road so i reclassified the. Anthony From: maning sambale emmanuel.samb...@gmail.com To: talk-ph@openstreetmap.org Date: 08/03/2009 10:06 AM Subject: [talk-ph] changes of raod types -- I'm not objecting but I'm somehow curious about recent reclassifications of several major roads lately: 1. Portions of Commonwealth from trunk to primary: http://www.openstreetmap.org/?lat=14.66209lon=121.06976zoom=15layers=B000FTF 2. Mindanao Ave from primary to trunk: http://www.openstreetmap.org/?lat=14.67085lon=121.03234zoom=15layers=B000FTF 3. Some parts of Quirino are either primary or trunk: http://www.openstreetmap.org/?lat=14.69974lon=121.03273zoom=15layers=B000FTF 4. MacArthur Hiway from primary to trunk: http://www.openstreetmap.org/?lat=14.6755lon=120.982zoom=15layers=B000FTF If we follow this trend, then I think Roxas Blvd should also be trunk as well: http://www.openstreetmap.org/?lat=14.53551lon=121.00028zoom=15layers=B000FTF Which means Metro Manila roads will be a whole lot greener (in the map at least). PS. Apologies for non-manila members -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk] tag:amenity=doctor
This is a picky little point. Tagging: amenity=doctor remains a proposed feature http://wiki.openstreetmap.org/wiki/Proposed_features/Doctor Proposed features/GP Surgery (tagged as amenity=doctors), which is invalid according to Rejected features. and apparently abandoned http://wiki.openstreetmap.org/wiki/Proposed_features/GP_Surgery the principles for naming amenity tags clearly state butcher not butchers but JOSM has in presets amenity=doctors which violates that principle. I expect some equally picky person to tell me that this is not the JOSM talk list but before annoying everyone on that list, I thought that which is the preferred tag should be decided. Liz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
--- On Sun, 2/8/09, Liz ed...@billiau.net wrote: I expect some equally picky person to tell me that this is not the JOSM talk It's the talk-au list ;) list but before annoying everyone on that list, I thought that which is the preferred tag should be decided. JOSM has numerous tags that aren't official Speaking of which, can anyone think of a better way to put aren't listed on the map features wiki page in a concise manner? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] tagging roads
Hi, I have noticed intense discussion about changing how roads should be tagged. It seems that some people devised their own way how to apply different values for highway tag and now attempt to force this on everybody. On the other hand some people are attempting to introduce new values for highway tag (http://wiki.openstreetmap.org/wiki/Proposed_features/residential_narrow and http://wiki.openstreetmap.org/wiki/Proposed_features/residential_narrow/old). Both approaches seem wrong. Changing how roads should be classified will break existing OSM data. Introducing new values will only add to confusion choosing road classification. It seems that both issues are caused by desire to achieve certain rendering in mapnik or TAH. I guess best way to solve such problems would be to render streets differently based on value of tag width. This would encourage use of tag width. This way we would also gain useful data that can be used by routing software. Another tag that is currently not supported by rendering engines is surface. I think renderers should make distinction between paved and unpaved roads. Otherwise you are risking that people will classify unpaved road as track just to achieve desired rendering effect. I am aware that highway=unsurfaced is rendered differently. But this value is supposed to be deprecated. Besides, unsurfaced roads can have different classifications (http://wiki.openstreetmap.org/wiki/Highway#Exceptions_to_physical_attributes). I also propose extending instructions for road classification to use width tag when road is narrow. Instructions should also suggest what is considered narrow. For instance less than 4 meters for residential and unclassified roads, less than 6 meters for tertiary roads, less than 8 meters for secondary and primary roads. For trunks and motorways this limit should probably apply to lane width. Proposed limits on when certain type of road is considered narrow should match rendering rules. Blaž ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
--- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: I also propose extending instructions for road classification to use width tag I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, Aug 2, 2009 at 10:59 AM, John Smithdelta_foxt...@yahoo.com wrote: I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. +1 I prefere to add narrow=yes combined with residential or unclassified (or any other) highways. It should be interpreted as between 75% to 50% narrower than the default width of this highway type. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sunday 02 August 2009 10:59:08 John Smith wrote: --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: I also propose extending instructions for road classification to use width tag I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. Unfortunately lanes only specifies number of lanes. In general every road that is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters. But you are right. Actually measuring road width is cumbersome and dangerous. We really don't want any OSM mapper to be nominated for Darwin award. :-) Still, you must get width data somehow. But, since width is more important in case of narrow road, you can limit gathering of width data only on narrow roads. Which has additional benefit that width for narrow road is easier to estimate than for wide road. Obviously it would be a good idea to add recommendation that only width of narrow roads should be estimated to tagging instructions. Some good practices on how to accurately estimate road width could also came handy. Which leaves us with problem how accurate is width data. Wiki suggest using tag est_width. But this means that software needs to check two tags: width and est_width. Maybe additional tag (width_estimated=yes|no) could solve this problem. Default value for tag would be yes, since we can assume that someone that did not bother to acquire accurate data won't bother to add the tag to record such fact. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
--- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: Unfortunately lanes only specifies number of lanes. In general every road that is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters. Even one way roads can have multiple lanes. Like dual carriage ways :) Some good practices on how to accurately estimate road width could also came handy. I feel you could get road widths accurately enough based simply on the number of lanes and the type of highway. For example, a residential road with 2 lanes, one in each direction is usually about 6-7m wide. Motorways are usually the numbers of lanes times 3m + 3m each side of the road way to allow for break downs, or maybe you could even have lanes=* breakdown_lanes=* to make this more accurate, but in any case a 3 lane motorway will be about 15m wide (3 * 3 + 3 + 3). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
--- On Sun, 2/8/09, Pieren pier...@gmail.com wrote: I prefere to add narrow=yes combined with residential or unclassified (or any other) highways. It should be interpreted as between 75% to 50% narrower than the default width of this highway type. +1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
Am Sonntag 02 August 2009 11:49:11 schrieb Blaž Lorger: On Sunday 02 August 2009 10:59:08 John Smith wrote: --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: I also propose extending instructions for road classification to use width tag I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. Unfortunately lanes only specifies number of lanes. In general every road that is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters. Yes, but equally unfortunately width only specifies width, and not the number of lanes. Therefore, it would be nice to have both. Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On 01/08/2009, at 7:38 AM, Martin Koppenhoefer wrote: Well, you can do this, but most routers will try not to use residential roads if there is another way. Maybe things are different over in Europe than here in Australia. My Garmin when using commercial maps and a friend's NavMan are both more than happy to take you down what we have been taggin as residential streets, if it will save you a few seconds time. The exception is roads marked as local traffic only, which I'd tag as access=destination. both of these are IMHO not valid for industrial areas, that's why your aussie-way might produce slightly worse routing results (don't know, just an idea). If we ignore the Australian tagging guidelines, what should we use for roads that are the same as residential ones but in an industrial area? According to the wiki, unclassified roads are wider than residential ones, and while roads in industrial areas are often wider than residential ones, that's not always the case. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Title bars (dynamic updating of)
that's easy enough to do It would need to be in rails to go on the main page though, so if any ruby programmer wants to implement it, I can tell them what needs doing? (use the zoom level to choose 3 appropriately-spaced points around the lat/lon, lookup the placenames at each point (optionally choosing a language for the placenames), and return a list of placenames that appear in all 3 points) You have to make some assumptions about screen size though - 50.5,-0.2 @z11 on a mobile phone might be 'central london', while the same query on Al Gore's array of monitors might be 'europe' On Sun, Aug 2, 2009 at 5:45 AM, Stefan Baeblerstefan.baeb...@gmail.com wrote: Cool! For SEO reasons it could be really nice if this title would be present in html title tag already while the html is being sent to the client...and not delaying the initial response at the same time :) Stefan On Sat, Aug 1, 2009 at 7:43 PM, Ed Avise...@waniasset.com wrote: OJ W ojwlists at googlemail.com writes: Imagine if it said OpenStreetMap Oxfordshire, United Kingdom instead... http://dev.openstreetmap.org/~ojw/TitlebarDemo/?zoom=11lat=51.76lon=-1.282 You mean instead of OpenSteetMap Oxfordshire, United Kingdom? Yes that would be cool! Spelling apart, this is a really neat feature. Perhaps 'Oxfordshire, United Kingdom - Openstreetmap' would be even better. -- Ed Avis e...@waniasset.com ___ 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] Multiple nodes for one country
I noticed that for some countries there seems to be more than one node. E.g. for Slovakia there are 5: http://www.openstreetmap.org/browse/node/424313572 http://www.openstreetmap.org/browse/node/432425079 http://www.openstreetmap.org/browse/node/424315420 http://www.openstreetmap.org/browse/node/243851695 http://www.openstreetmap.org/browse/node/424310798 all at the same coordinate, most of them with the same names. Is this intended or just a mistake? Would it be ok to build a bot that correct this? Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, Aug 2, 2009 at 12:03 PM, James Livingstondoc...@mac.com wrote: If we ignore the Australian tagging guidelines, what should we use for roads that are the same as residential ones but in an industrial area? According to the wiki, unclassified roads are wider than residential ones, and while roads in industrial areas are often wider than residential ones, that's not always the case. The wiki talks about residential or unclassified roads inside a residential area: This tag is used for roads accessing or around residential areas but which are not a classified or unclassified highway. Tagging roads inside industrial or commercial areas with highway=residential sounds really bad, sorry. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Title bars (dynamic updating of)
--- On Sun, 2/8/09, OJ W ojwli...@googlemail.com wrote: You have to make some assumptions about screen size though - 50.5,-0.2 @z11 on a mobile phone might be 'central london', while the same query on Al Gore's array of monitors might be 'europe' Can't you get screen resolution and then calculate the zoom from that? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sunday 02 August 2009 11:49:06 Pieren wrote: On Sun, Aug 2, 2009 at 10:59 AM, John Smithdelta_foxt...@yahoo.com wrote: I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. +1 I prefere to add narrow=yes combined with residential or unclassified (or any other) highways. It should be interpreted as between 75% to 50% narrower than the default width of this highway type. Pieren Wiki clearly states why tag narrow=yes would be a bad idea (http://wiki.openstreetmap.org/wiki/Key:width#Using_relative_sizes). Basically, what is wide for bicycle is narrow for a car, what is wide for a car is narrow for a truck ... Besides, I am not much bothered by narrow roads when driving a car. On the other hand some drivers will drive very slow when lane width drops under twice the width of their vehicle. Whose estimation of whether road is narrow or not is appropriate? Specifying actual or at least estimated width is only way to ensure that data is universally usable. I guess heavy truck driver would not be amused when navigation system would direct him in 3m wide residential street, while car driver would only see it as a problem when passing another car. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Title bars (dynamic updating of)
On 02/08/09 11:06, OJ W wrote: It would need to be in rails to go on the main page though, so if any ruby programmer wants to implement it, I can tell them what needs doing? (use the zoom level to choose 3 appropriately-spaced points around the lat/lon, lookup the placenames at each point (optionally choosing a language for the placenames), and return a list of placenames that appear in all 3 points) Implementing it is easy. Predicting the resource usage of hundreds of browsers asking for a new title every few seconds is not. The gain here seems trivial - how many people are actually studying the title bar of the browser while they pan around the map? and the potential to impose a significant load on the server is high. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple nodes for one country
On Sun, Aug 2, 2009 at 12:10 PM, Peter Körnerpe...@mazdermind.de wrote: I noticed that for some countries there seems to be more than one node. E.g. for Slovakia there are 5: http://www.openstreetmap.org/browse/node/424313572 http://www.openstreetmap.org/browse/node/432425079 http://www.openstreetmap.org/browse/node/424315420 http://www.openstreetmap.org/browse/node/243851695 http://www.openstreetmap.org/browse/node/424310798 all at the same coordinate, most of them with the same names. Is this intended or just a mistake? Would it be ok to build a bot that correct this? Peter Read this: http://lists.openstreetmap.org/pipermail/talk/2009-July/038931.html It seems that one person is not able to revert all the crap he created. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
--- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: Specifying actual or at least estimated width is only way to ensure that data is universally usable. I guess heavy truck driver would not be amused when navigation system would direct him in 3m wide residential street, while car driver would only see it as a problem when passing another car. Actually the only way to get consistent road width estimates is to calculate it based on lanes, otherwise you will get a wide range of subjective values because people will estimate differently no matter what you do or say or write on a wiki. Counting lanes = easy estimating road width = nightmare ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sunday 02 August 2009 11:57:12 John Smith wrote: --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: Unfortunately lanes only specifies number of lanes. In general every road that is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters. Even one way roads can have multiple lanes. Like dual carriage ways :) Some good practices on how to accurately estimate road width could also came handy. I feel you could get road widths accurately enough based simply on the number of lanes and the type of highway. For example, a residential road with 2 lanes, one in each direction is usually about 6-7m wide. Motorways are usually the numbers of lanes times 3m + 3m each side of the road way to allow for break downs, or maybe you could even have lanes=* breakdown_lanes=* to make this more accurate, but in any case a 3 lane motorway will be about 15m wide (3 * 3 + 3 + 3). Main point here is to identify narrow roads. This is where road width matters the most. It is obvious that narrow roads will have 2 lanes. Unfortunately, those lanes will be narrow (2m or less). So number of lanes will in no way indicate road width, especially for narrow roads. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, Aug 2, 2009 at 12:18 PM, Blaž Lorgerblaz.lor...@triera.net wrote: Wiki clearly states why tag narrow=yes would be a bad idea (http://wiki.openstreetmap.org/wiki/Key:width#Using_relative_sizes). Basically, what is wide for bicycle is narrow for a car, what is wide for a car is narrow for a truck ... The wiki says without clear definition about narrow. We just need a clear definition on the wiki and mine is a proposal. It is just proportional to the default width for all highway types for all countries. The advantage is that you don't have to tag all highways, just the ones you consider narrower. Otherwise, if you use the width=x , you have to do it on all roads or it will never be used by any application since they don't know if this segment is wider or narrower than the 95% of the highways where this width is missing. Here we could start again the discussion about the default width or default lanes and so on per highway type per country. That's the advantage of the key narrow, it is easy to use for mappers and it works for all countries. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
--- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: Main point here is to identify narrow roads. This is where road width matters the most. It is obvious that narrow roads will have 2 lanes. Unfortunately, those lanes will be narrow (2m or less). So number of lanes will in no way indicate road width, especially for narrow roads. If the main issue is to identify narrow roads, you explicitly state narrow compared to what, and narrow=yes simple. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, 2 Aug 2009, Pieren wrote: On Sun, Aug 2, 2009 at 12:03 PM, James Livingstondoc...@mac.com wrote: If we ignore the Australian tagging guidelines, what should we use for roads that are the same as residential ones but in an industrial area? According to the wiki, unclassified roads are wider than residential ones, and while roads in industrial areas are often wider than residential ones, that's not always the case. The wiki talks about residential or unclassified roads inside a residential area: Which wiki page ? the last one or the earlier ones? This tag is used for roads accessing or around residential areas but which are not a classified or unclassified highway. Tagging roads inside industrial or commercial areas with highway=residential sounds really bad, sorry. lots of things sound bad, but we need more than feel good answers to make good maps. So the question is: is there anything about a road inside an industrial or commercial area which would be important inside a renderer or a routing engine and is different to a residential road? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
2009/8/1 James Stewart j.k.stew...@ed.ac.uk: Classifying roads in central asia, it is easier, and makes more sense in my opinion to use the highway ref in the administrative sense. Some countries or regions have 5 or 6 main roads with are the national trunk system. In places they are almost reduced to tracks through the mountains, through which all traffic flows - it makes little sense to mark then as a track though- physical attribute tags can do this, and using dual carriage way technique when relevant. Many central asian roads have fallen into disrepair in the last 20 years, but nonetheless remain trunk roads. These roads are generally the object of investment to improvement, so so will remain the principal highways, but improved over time. so this is another example, that the main focus for the highway-class should be on importance, true? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, 2 Aug 2009, John Smith wrote: --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: I also propose extending instructions for road classification to use width tag I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. this is a sensible suggestion, but may i note that there is the road reserve which is a certain size - here in Australia actually surveyed in chains ( a very old, old measure) and then a visible road inside that which may be much narrower so i'm not really sure what is the road width when i see these ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sunday 02 August 2009 12:36:48 Pieren wrote: On Sun, Aug 2, 2009 at 12:18 PM, Blaž Lorgerblaz.lor...@triera.net wrote: Wiki clearly states why tag narrow=yes would be a bad idea (http://wiki.openstreetmap.org/wiki/Key:width#Using_relative_sizes). Basically, what is wide for bicycle is narrow for a car, what is wide for a car is narrow for a truck ... The wiki says without clear definition about narrow. We just need a clear definition on the wiki and mine is a proposal. It is just proportional to the default width for all highway types for all countries. The advantage is that you don't have to tag all highways, just the ones you consider narrower. Otherwise, if you use the width=x , you have to do it on all roads or it will never be used by any application since they don't know if this segment is wider or narrower than the 95% of the highways where this width is missing. Here we could start again the discussion about the default width or default lanes and so on per highway type per country. That's the advantage of the key narrow, it is easy to use for mappers and it works for all countries. Let's see: 1. There is no clear definition what is narrow. 2. There is no specification for default width of road type. 3. If narrow=yes is not applied everywhere where it should be it is equally useful/useless as with width tag. 4. At the end it is always up to the individual mapper to decide what is narrow. While 1 meter is 1 meter. 5. Should definition of default road width ever change. All narrow=* tagging will be completely useless and will have to be reevaluated from scratch. Actually it will be useless before that due to subjective nature of value assigned to tag. 6. You will actually require large number of values for narrow to even approach granularity offered by one simple tag width. Either you will have to have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could not be used, since it does not specify how narrow the road is or it could be equivalent for narrow=car. 7. You must prepare clear enough instructions how to select value for narrow, to reduce subjective factor to minimum. 8. You must get renderers to support it. On the other hand, if you use tag width, which is already established tag if I may add, you have to accomplish following: 1. You must get renderers to support it. 2. Prepare some guidelines how to estimate road width. Of course using measuring equipment is always preferred but less realistic. 3. Deprecate tag est_width and always store width data in tag width. Add additional tag that would state accuracy of width data. This is really not necessary, but will be easier to use by the software and probably also easier to map. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
2009/8/1 Christiaan Welvaart c...@daneel.dyndns.org: On Sat, 1 Aug 2009, Martin Koppenhoefer wrote: It seems to be an interpretation problem for the phrase 'administrave class' then because I clearly argued that who is the maintainer of the road should not directly influence the value of the highway tag. What I was trying to say is that I'd prefer to tag the importance that the road maintainer sets for a road. OK, still importance it is. This *class* can usually be derived from how it was built, the maximum speed on the road, etc., not from how many cars actually drive on it or even its position in the grid. Road maintainers also take other things into account like how many houses are near the road, but that's more or less another way of estimating how many cars actually drive on it how much pollution and noise will be generated by traffic on the road, etc. and that's also most dependant on how many cars actually drive on it (besides speed and partially surface) So in the context of Germany I say take 'Autobahn' and 'Kraftfahrstrasse' as a classes for the highway tag (not 'Bundesstrasse' and 'Landesstrasse'). These terms are defined in law, so it is not something OSM invented or a vague importance of the road. Bundesstraße is of course also defined in law: http://bundesrecht.juris.de/fstrg/BJNR009030953.html as is Landesstraße http://rlp.juris.de/rlp/gesamt/StrG_RP.htm and most probably also Kreisstraße and others (use google if you don't believe me). But we already agreed a long time ago in Germany not to use these administrative classification to derive the OSM highway-class for good reasons already reported here. The problem with 'importance' is that it is too vague and it is the task of the road maintainer to determine/define a road's function. Also, if there is a mismatch between a road's classification and its 'importance', we should tag the classification. what do you mean by classification? Administrative, physical or importance? There is clearly all the three of them, and of course I want to tag the administrative classification (inside ref-tag) but not as the parameter for the highway-class. I mean how the road maintainer designates the road. it is not the road maintainer to designate the road but the designation sets the road maintainer. That's the case at least in Germany and Italy (but most probably also in other countries). Well I disagree. IMHO we should tag what is 'on the ground', not invent things or try to tag what's in people's minds. If a government body gives a road it maintains some importance (or class/type) we should tag it accordingly. yes. We should tag the importance it receives. But that's what this is about. Class and type put equally aside are not helpful in this discussion. Classes there are also in law more than just administrative classes. Maybe you can read German, so have a look at this: http://de.wikipedia.org/wiki/Stra%C3%9Fenkategorie and this http://de.wikipedia.org/wiki/Stra%C3%9Fenbaurichtlinien (the latter is a more detailed summary of laws and directives according to roads. Another example is Bicycle streets. These are designated by municipalities in .nl (and .de) but they do not have a uniform importance: for cars they are e.g. a living street but for bicycles they are part of an important and much used route. These roads are classified specially by the road maintainer, and this should be reflected in the highway= value. What is the conclusion according to your proposal? I was talking about the main definition for the highway tag. Please note, that also on the English page there is explicitly written, that administrative classes are NOT the way to derive the highway-class. Please have a look. This discussion is about substituting physical (actual state) to importance. To your case (bikeroads): for these special cases (also motorway) we still have the particular definition where the criteria would remain designation in these cases. Anyway how do you determine if something is a cycleway, from its importance and its position in the grid? That does not work while it would be nice to have a uniform definition for the highway key. no, see above. I think the distinction between the general definition and the special ones is to be kept. I can't really see a point here. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
2009/8/2 Liz ed...@billiau.net: So the question is: is there anything about a road inside an industrial or commercial area which would be important inside a renderer or a routing engine and is different to a residential road? yes. A residential road should be avoided if possible (slow, dangerous and noisy for residents / playing kids), while I don't see this in industrial or commercial context. Furthermore industrial areas are built according to standards that allow easy use with trucks, while in residential areas you will more often have smaller streets and straighter curves, which will cause problems to big trucks. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, Aug 2, 2009 at 1:39 PM, Blaž Lorgerblaz.lor...@triera.net wrote: Let's see: 1. There is no clear definition what is narrow. 2. There is no specification for default width of road type. 3. If narrow=yes is not applied everywhere where it should be it is equally useful/useless as with width tag. Adding narrow=yes to your unclassified highway meaning it is 50% to 75% narrower than the usual unclassified highway width in my country is universal and doesn't have to be added everywhere. When you add oneway=yes to a road, do you add oneway=no to all others ? When it is not attached, then it is the usual width of the unclassified highway in your country. And this can be used by any renderer who could draw thinner roads when the tag is present. But renderers will never draw the exact width=* of a road excepted at the very high zoom levels. 4. At the end it is always up to the individual mapper to decide what is narrow. While 1 meter is 1 meter. You always have some subjectivity when you map, look the other thread about residential vs unclassified. Below you say yourself it must be estimated, so your 1 meter can be 1.5 meters for someone else. Your just give the impression that a number is more accurate than an adjective but it is just an impression (excepted if you really measure the width with a tape). 6. You will actually require large number of values for narrow to even approach granularity offered by one simple tag width. Either you will have to have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could not be used, since it does not specify how narrow the road is or it could be equivalent for narrow=car. I only suggest narrow=yes. I don't understand what means narrow=foot|etc. It is narrower than the default width of the road. It has nothing to do with vehicules. 7. You must prepare clear enough instructions how to select value for narrow, to reduce subjective factor to minimum. no values for narrow, it is a rough estimate that the road you are adding as residential is not the usual residential width in your country but is narrower. A typical example here in Europe is in towns or villages centers where some old streets are very narrow and usually oneway because two cars cannot cross. Tagging them as highway=service is improper because it is real streets and not alleys. 8. You must get renderers to support it. On the other hand, if you use tag width, which is already established tag if I may add, you have to accomplish following: 1. You must get renderers to support it. 2. Prepare some guidelines how to estimate road width. Of course using measuring equipment is always preferred but less realistic. 3. Deprecate tag est_width and always store width data in tag width. Add additional tag that would state accuracy of width data. This is really not necessary, but will be easier to use by the software and probably also easier to map. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, Aug 2, 2009 at 1:56 PM, Martin Koppenhoeferdieterdre...@gmail.com wrote: yes. A residential road should be avoided if possible (slow, dangerous and noisy for residents / playing kids) Add for cars. It could be the opposite for cycling as it is writen here: http://wiki.openstreetmap.org/wiki/Cycleway#On-Road_Cycling_.28Cycle_Friendly_Streets.29 Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
2009/8/2 Pieren pier...@gmail.com: On Sun, Aug 2, 2009 at 1:56 PM, Martin Koppenhoeferdieterdre...@gmail.com wrote: yes. A residential road should be avoided if possible (slow, dangerous and noisy for residents / playing kids) Add for cars. It could be the opposite for cycling as it is writen here: http://wiki.openstreetmap.org/wiki/Cycleway#On-Road_Cycling_.28Cycle_Friendly_Streets.29 Yes, thank you Pieren. For bikes it's the other way round. I put this topic on a separate thread, because it is not about the main-tag-definition for highway. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sunday 02 August 2009 14:40:09 Pieren wrote: On Sun, Aug 2, 2009 at 1:39 PM, Blaž Lorgerblaz.lor...@triera.net wrote: Let's see: 1. There is no clear definition what is narrow. 2. There is no specification for default width of road type. 3. If narrow=yes is not applied everywhere where it should be it is equally useful/useless as with width tag. Adding narrow=yes to your unclassified highway meaning it is 50% to 75% narrower than the usual unclassified highway width in my country is universal and doesn't have to be added everywhere. When you add oneway=yes to a road, do you add oneway=no to all others ? When it is not attached, then it is the usual width of the unclassified highway in your country. And this can be used by any renderer who could draw thinner roads when the tag is present. But renderers will never draw the exact width=* of a road excepted at the very high zoom levels. To my knowledge there is no such thing as usual highway width. There are certain standards for width of newly built roads, but those usually increase over time, which means you will be forced to periodically reevaluate *ALL* narrow tagging. Obviously you haven't read my original message carefully. I suggested that only two widths are used by renderer and that border value is determined by renderer based on highway type. Absence of width tag is interpreted as road having usual width. This is exactly same as absence of tag narrow. Having actual road width is always more useful than having just some subjective estimate whether road is too narrow or not. Besides rendering you can use it to improve routing based on actual vehicle width/size. 4. At the end it is always up to the individual mapper to decide what is narrow. While 1 meter is 1 meter. You always have some subjectivity when you map, look the other thread about residential vs unclassified. Below you say yourself it must be estimated, so your 1 meter can be 1.5 meters for someone else. Your just give the impression that a number is more accurate than an adjective but it is just an impression (excepted if you really measure the width with a tape). Well yes, but with width it is only estimation error. While with narrow you must decide what is usual width for specific type of road, you make estimation error for road width, you make calculation error in percentage of usual road width and you must decide whether calculated percentage width is low enough to justify narrow=true. some subjective factor is inevitable, but at least it should be kept as low as possible. Besides in case of dispute or for whatever reason, road can actually be measured. Whether road is narrow or not is always matter of opinion, there is no way to improve accuracy here. 6. You will actually require large number of values for narrow to even approach granularity offered by one simple tag width. Either you will have to have narrow=no|foot|bicycle|motorcycle|car|suv|lgv|hgv|... Vale yes could not be used, since it does not specify how narrow the road is or it could be equivalent for narrow=car. I only suggest narrow=yes. I don't understand what means narrow=foot|etc. It is narrower than the default width of the road. It has nothing to do with vehicules. Again, what is default width of the road? And it has everything to do with vehicles, because what you need to now is whether your vehicle, which can be 1, 2, 4 ... meters wide will be able to drive along road in question. Specifying narrow=yes|no can only be used to render a map. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
2009/8/2 John Smith delta_foxt...@yahoo.com: list but before annoying everyone on that list, I thought that which is the preferred tag should be decided. JOSM has numerous tags that aren't official Speaking of which, can anyone think of a better way to put aren't listed on the map features wiki page in a concise manner? I would in this particular case agree with Liz: the principles for naming amenity tags clearly state butcher not butchers but JOSM has in presets amenity=doctors which violates that principle. Let's change this for consistency. tagwatch has ~2700 doctors and ~200 doctors. If JOSM-Preset was changed this would IMHO change rapidly. It is absolutely strange that Mapfeatures (complete compilation) has the entry amenity=doctors (plural) but then redirects to Proposed features/Doctor (not in plural). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
Martin Koppenhoefer schrieb: 2009/8/2 John Smith delta_foxt...@yahoo.com: list but before annoying everyone on that list, I thought that which is the preferred tag should be decided. JOSM has numerous tags that aren't official Speaking of which, can anyone think of a better way to put aren't listed on the map features wiki page in a concise manner? I would in this particular case agree with Liz: the principles for naming amenity tags clearly state butcher not butchers but JOSM has in presets amenity=doctors which violates that principle. Let's change this for consistency. tagwatch has ~2700 doctors and ~200 doctors. If JOSM-Preset was changed this would IMHO change rapidly. It is absolutely strange that Mapfeatures (complete compilation) has the entry amenity=doctors (plural) but then redirects to Proposed features/Doctor (not in plural). Well, when I introduced doctors in JOSMs mappaint (and Christoph to the Presets), there was a clear majority of doctors and not doctor. If people use the term doctors, we shouldn't force them to use doctor just to fit some guideline (not rule) in the wiki. Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
2009/8/2 Ulf Lamping ulf.lamp...@googlemail.com: Well, when I introduced doctors in JOSMs mappaint (and Christoph to the Presets), there was a clear majority of doctors and not doctor. If people use the term doctors, we shouldn't force them to use doctor just to fit some guideline (not rule) in the wiki. Do you remember the quantity of doctors prior to putting it into JOSM-Standards? Because once present in JOSM, it is obvious that lots of preset-tags will be created. Furthermore you are forcing noone, people are still able to disregard JOSM presets. There is a big inconsistency created by this situation anyways: 1. it is agains recommended guidelines (butcher, not butchers) 2. the mapfeatures-page (doctors) links to a different tag (doctor). mainly because of 2.: I don't think that doctors has a different meaning than doctor, so why should it not be consistent with recommendations? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
http://lists.openstreetmap.org/pipermail/talk/2009-February/034241.html -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
2009/8/2 Cartinus carti...@xs4all.nl: http://lists.openstreetmap.org/pipermail/talk/2009-February/034241.html unfortunately the action taken didn't help to improve consistency and since Feb the number increased from 1700 to 2700. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
Martin Koppenhoefer schrieb: 2009/8/2 Ulf Lamping ulf.lamp...@googlemail.com: Well, when I introduced doctors in JOSMs mappaint (and Christoph to the Presets), there was a clear majority of doctors and not doctor. If people use the term doctors, we shouldn't force them to use doctor just to fit some guideline (not rule) in the wiki. Do you remember the quantity of doctors prior to putting it into JOSM-Standards? Because once present in JOSM, it is obvious that lots of preset-tags will be created. Furthermore you are forcing noone, people are still able to disregard JOSM presets. There is a big inconsistency created by this situation anyways: 1. it is agains recommended guidelines (butcher, not butchers) 2. the mapfeatures-page (doctors) links to a different tag (doctor). mainly because of 2.: I don't think that doctors has a different meaning than doctor, so why should it not be consistent with recommendations? Because it *IS IN USE* otherwise. Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
--- On Sun, 2/8/09, Ulf Lamping ulf.lamp...@googlemail.com wrote: Because it *IS IN USE* otherwise. It takes very little time to do such a mass change on nodes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag:amenity=doctor
On Sun, Aug 2, 2009 at 4:03 PM, Ulf Lamping ulf.lamp...@googlemail.comwrote: If people use the term doctors, we shouldn't force them to use doctor just to fit some guideline (not rule) in the wiki. IMHO you should change the wiki. rantIt's much to easy for an newbie to change something on the wiki, without him or her realizing how much time it will require from the developers to actually implement the change and for the mappers to learn the change./rant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Announcement] talk-alps - European Alps mailing list
There is now a talk-alps mailing list. This is for mapping parties, topics and general discussion for anyone mapping in the European Alps. This is experiment for a multi-language list for discussion in Italian, French, German, Slovenian, Romanche and, oh, may be English too. If it does not work, we can split it up. Thank you to Simone Cortesi for thinking up the idea and for hosting. Mike For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists About the Alps: http://en.wikipedia.org/wiki/Alps But, hey, who needs Wikipedia when you can see the Alps in our great Cycle Maps view: http://www.openstreetmap.org/?lat=46.09lon=10.79zoom=7layers=00B0FTF I am really going to cycle across the Alps one day. Any day now. Anyone got a spare pair of legs? Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SoC 2009 - static maps API - prototype version
Hi all According to feedback I recived I have add some new featurs to static API. So now there is a better way of controlling how drawings are drawn (transparence, thickness, color could be defined for each object separately, there is a way to put image onto the map). It is also possible to put scale bar and to put map request parameters into a file instead puting them into url (take a look at *paramFileUrl *in API description) etc. http://dev.openstreetmap.org/~pafciu17/ Let me know your opinion:) Paweł* * ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Announcement] talk-alps - European Alps mailing list
I'm in the Alps right now (summer vacation), mapping Westendorf, Austria :) Anyone around here? --Ciprian On 8/2/09, Mike Collinson m...@ayeltd.biz wrote: There is now a talk-alps mailing list. This is for mapping parties, topics and general discussion for anyone mapping in the European Alps. This is experiment for a multi-language list for discussion in Italian, French, German, Slovenian, Romanche and, oh, may be English too. If it does not work, we can split it up. Thank you to Simone Cortesi for thinking up the idea and for hosting. Mike For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists About the Alps: http://en.wikipedia.org/wiki/Alps But, hey, who needs Wikipedia when you can see the Alps in our great Cycle Maps view: http://www.openstreetmap.org/?lat=46.09lon=10.79zoom=7layers=00B0FTF I am really going to cycle across the Alps one day. Any day now. Anyone got a spare pair of legs? Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Announcement] talk-alps - European Alps mailing list
Ciprian Talaba schreef: I'm in the Alps right now (summer vacation), mapping Westendorf, Austria :) Anyone around here? Well, I found out this weekend: Maps of Austria, Switzerland, Germany ... for free, oh well, by the russian site: http://www.topomaps.eu/europe/ some 1/100.000 to 1/200.000 maps, in BSB format, but convertible to geotiff with gdal-translate, see http://gdal.org Is also found 1/25000 maps of Russia itself... Marc -- Shortwave transmissions in English, Francais, Deutsch, Suid-Afrikaans, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://users.fulladsl.be/spb13810/radio/swlist/ Stations list: http://users.fulladsl.be/spb13810/radio/txlist/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, Aug 2, 2009 at 9:12 PM, Lized...@billiau.net wrote: lots of things sound bad, but we need more than feel good answers to make good maps. So the question is: is there anything about a road inside an industrial or commercial area which would be important inside a renderer or a routing engine and is different to a residential road? This sounds like tagging for the renderer and/or tagging for the router. If it isn't a residential road, don't tag it as a residential road. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Does this mean we could launch our own OSM satellite?
http://spacefellowship.com/2009/08/01/interorbital-syatems-tubesat-personal-satellite-kit/ From the article: Total Price of the TubeSat Kit including a Launch to Orbit is $8,000! ... Examples of add-on experiments or functions include the following: ▼ Earth-from-space video imaging ▼ Earth magnetic field measurement ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple nodes for one country
Hi Peter, I don't think anybody has a reason to object to merging them. At least me and User:Mala have been merging some of these nodes last week and we got no blackmail so far :) I believe we went through all the country nodes which didn't have a name:pl= or name:it= assigned yet so out of your list at most 15 or so countries should still remain duplicated. Cheers On 02/08/2009, Peter Körner osm-li...@mazdermind.de wrote: Pieren schrieb: On Sun, Aug 2, 2009 at 12:10 PM, Peter Körnerpe...@mazdermind.de wrote: I noticed that for some countries there seems to be more than one node. E.g. for Slovakia there are 5: http://www.openstreetmap.org/browse/node/424313572 http://www.openstreetmap.org/browse/node/432425079 http://www.openstreetmap.org/browse/node/424315420 http://www.openstreetmap.org/browse/node/243851695 http://www.openstreetmap.org/browse/node/424310798 all at the same coordinate, most of them with the same names. Is this intended or just a mistake? Would it be ok to build a bot that correct this? Peter Read this: http://lists.openstreetmap.org/pipermail/talk/2009-July/038931.html It seems that one person is not able to revert all the crap he created. Pieren Ok, so here is an index of all duplicated countries: http://toolserver.org/~mazder/duplicate-countries/ This is *not* the current state of osm, it's of 2009-07-05 which is the age of the postgis-database on cassini, the wikimedia osm-toolserver. It would be easy to extend the script generating this list, so that it merges those nodes into a single one. I just want to ask if that would be ok to everybody. If there is no contradiction until Monday, 10th August, I'll do so. Peter ___ 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] definition of the main highway-tag
On Sun, 2 Aug 2009, Martin Koppenhoefer wrote: Furthermore industrial areas are built according to standards that allow easy use with trucks, while in residential areas you will more often have smaller streets and straighter curves, which will cause problems to big trucks. That does not apply in our country The roads are all built to the one standard. We don't have mediaeval cities, with narrow streets, overhanging upper stories and other problems like that. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
Patrick Aljord schreef: http://spacefellowship.com/2009/08/01/interorbital-syatems-tubesat-personal-satellite-kit/ From the article: Total Price of the TubeSat Kit including a Launch to Orbit is $8,000! ... You can try the quadcopter too.. http://www.quadcopter.org/index.php5?title=Quadcopter_Home Marc -- Shortwave transmissions in English, Francais, Deutsch, Suid-Afrikaans, Urdu, Cantonese, Greek, Spanish, Portuguese, ... http://users.fulladsl.be/spb13810/radio/swlist/ Stations list: http://users.fulladsl.be/spb13810/radio/txlist/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple nodes for one country
andrzej zaborowski schrieb: Hi Peter, I don't think anybody has a reason to object to merging them. At least me and User:Mala have been merging some of these nodes last week and we got no blackmail so far :) I believe we went through all the country nodes which didn't have a name:pl= or name:it= assigned yet so out of your list at most 15 or so countries should still remain duplicated. Cheers The main problem is that I'm unable to produce an up-to-date list from database since I don't have the resources to import an up-to-date dump. I'll try to process an up-to-date planet.osm tomorrow to generate an up-to-date list from it. It's a pity that cassini is not updated via the diffs right now. At the next step I'll generate a list for each wikimedia-language containing all countries and their names in this language, so people can correct the locale names more easy. It seems you've already done this for pl and it -- I'm about to do it for de. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, Aug 2, 2009 at 11:38 PM, Blaž Lorgerblaz.lor...@triera.net wrote: To my knowledge there is no such thing as usual highway width. There are certain standards for width of newly built roads, but those usually increase over time, which means you will be forced to periodically reevaluate *ALL* narrow tagging. +1 Having actual road width is always more useful than having just some subjective estimate whether road is too narrow or not. Besides rendering you can use it to improve routing based on actual vehicle width/size. +1. some subjective factor is inevitable, but at least it should be kept as low as possible. +1 Tagging width=* is more faithful to what actually exists on the ground, which is always the better long term approach. And the meaning is much clearer than narrow=*, especially for those who only skim the wiki. Also, width=* interacts nicely with lanes=* - from these two tags you can see the width of the entire way, and also calculate the width of each lane. Whereas with narrow=*, it's not quite as clear whether this refers to narrow lanes or a narrow way... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
And by the way, the Key:width wiki page is horrible and could do with a rework after this discussion. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
On Sun, Aug 2, 2009 at 10:03 PM, Marc Coevoetsintsix...@gmail.com wrote: You can try the quadcopter too.. how would launching a quadcopter into orbit help? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Nationnal websites
Hi, I'm trying to build a list of the national osm websites available. Here is the list I ended with : Domains with content: http://www.openstreetmap.org http://www.openstreetmap.ch http://www.openstreetmap.cl http://www.openstreetmap.cz http://www.openstreetmap.de http://www.openstreetmap.es http://www.openstreetmap.org.et http://www.openstreetmap.fr http://openstreetmap.it http://www.openstreetmap.jp http://www.openstreetmap.nl http://www.openstreetmap.org.ph http://www.openstreetmap.pl http://www.openstreetmap.se http://www.openstreetmap.sk http://openstreetmap.tw Don't work with www http://www.openstreetmap.org.za Domains with just a map http://www.openstreetmap.at http://www.openstreetmap.ro other domains: http://www.openstreetmap.beRedirect to main website http://www.openstreetmap.ca Down for at least one month. Is there any chance for it to work one day ? http://www.openstreetmap.cn http://www.openstreetmap.com.cn Cybersquatting :( http://www.openstreetmap.fiRedirect to main website http://www.openstreetmap.hu Display osm.pl but with map centered on Budapest http://www.openstreetmap.ieRedirect to main website http://www.openstreetmap.no Nothing here http://www.openstreetmap.kr DNS Error http://openstreetmap.ru Just an empty forum Any comment, suggestion, addition… ? -- Vincent MEURISSE ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] residential and unclassified in Australia WAS definition of the main highway-tag
/moved this discussion to another thread as it is not about the topic in the headline/ 2009/8/2 Elizabeth Dodd ed...@billiau.net: On Sun, 2 Aug 2009, Martin Koppenhoefer wrote: Furthermore industrial areas are built according to standards that allow easy use with trucks, while in residential areas you will more often have smaller streets and straighter curves, which will cause problems to big trucks. That does not apply in our country The roads are all built to the one standard. sorry, but I can't believe that. All roads in your country have the same width? The same minimum radius for curves? We don't have mediaeval cities, with narrow streets, overhanging upper stories and other problems like that. some call it problems, I'd call it a feature ;-) I had a quick look and here's 2 examples: (IMHO) residential: http://maps.google.it/maps?hl=deie=UTF8ll=-37.675859,145.165879spn=0.000252,0.000597t=hz=21 (IMHO) unclassified (~25% wider in the aerial): http://maps.google.it/maps?hl=deie=UTF8ll=-37.769521,145.02807spn=0.000504,0.001195t=hz=21 cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
Patrick Aljord schrieb: http://spacefellowship.com/2009/08/01/interorbital-syatems-tubesat-personal-satellite-kit/ From the article: Total Price of the TubeSat Kit including a Launch to Orbit is $8,000! ... The article also says: It has three-quarters of the mass (0.75-kg) and volume of a CubeSat = quite small and the capacity will not be suficcient for appropriate lens/camera. And I'm shure it is not 3 axis stabilisation = no alignment to the desired target. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Sun, Aug 2, 2009 at 11:14 PM, Roy Wallacewaldo000...@gmail.com wrote: On Sun, Aug 2, 2009 at 11:38 PM, Blaž Lorgerblaz.lor...@triera.net wrote: To my knowledge there is no such thing as usual highway width. There are certain standards for width of newly built roads, but those usually increase over time, which means you will be forced to periodically reevaluate *ALL* narrow tagging. +1 I'm not sure that the width of what we consider unclassified roads will double in the next century. Having actual road width is always more useful than having just some subjective estimate whether road is too narrow or not. Besides rendering you can use it to improve routing based on actual vehicle width/size. +1. some subjective factor is inevitable, but at least it should be kept as low as possible. +1 Tagging width=* is more faithful to what actually exists on the ground, which is always the better long term approach. And the meaning is much clearer than narrow=*, especially for those who only skim the wiki. I never mentionned narrow=* but narrow=yes, where did you see narrow=* ? Also, width=* interacts nicely with lanes=* - from these two tags you can see the width of the entire way, and also calculate the width of each lane. Whereas with narrow=*, it's not quite as clear whether this refers to narrow lanes or a narrow way... Why don't you think width is for a lane ? oh, ok it is documented on the wiki. Again, width is not less subjective because it is always estimated (deprecating est_width just hides this point), it is missing in most of the highways, it is changing continuously along the roads and a width of 6 meters does not say if an hgv can pass or not, it will never replace the access restriction tags. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple nodes for one country
On 02/08/2009, Peter Koerner osm-li...@mazdermind.de wrote: andrzej zaborowski schrieb: Hi Peter, I don't think anybody has a reason to object to merging them. At least me and User:Mala have been merging some of these nodes last week and we got no blackmail so far :) I believe we went through all the country nodes which didn't have a name:pl= or name:it= assigned yet so out of your list at most 15 or so countries should still remain duplicated. Cheers The main problem is that I'm unable to produce an up-to-date list from database since I don't have the resources to import an up-to-date dump. I'll try to process an up-to-date planet.osm tomorrow to generate an up-to-date list from it. It's a pity that cassini is not updated via the diffs right now. Oh, now that I think of it, it might be possible to just load the last month's list of nodes as received from XAPI into JOSM and tell it to Update data and it might be able to make a couple of group requests for the current versions of these nodes. If this doesn't work then it might work if you add bounds elements at the top of the xml file for each country node. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
2009/8/3 Pieren pier...@gmail.com: Again, width is not less subjective because it is always estimated (deprecating est_width just hides this point), actually according to the German ML there is some guys around with laser-distos to measure the real width. it is missing in most of the highways, it is changing continuously along the roads and a width of 6 meters does not say if an hgv can pass or not, it will never replace the access restriction tags. well, not replace, it is a different datum. And it is quite useful. Certainly it would be even more useful, if there was a definition how to measure (inside road marking, complete with pavement, does the lateral paved area outside the road marking count, etc.). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] revert.pl
Replying to my own email ... I tried to revert the changesets again, via ssh from a server with much faster internet connection ... on second try revert.pl terminated without an error message now, but the ways of the respective changesets are still there when I download parts of the area in JOSM; the changesets also haven't disappeared from the history page :-( Suggestions? Ulf On Sun, 2009-08-02 at 10:14 -0300, Ulf Mehlig wrote: I tried to revert two large changesets of mine (double import of municipal borders in Pará/north Brazil due to a local network problem) via revert.pl (fresh from svn); in the middle of the reversal process, I got the message GET http://www.openstreetmap.org/api/0.6/node/451437544/history... 500 Internal Server Error (369b) and now my try to resume the revert process ends after a number of deletions with relation 183111 cannot be retrieved: 500 read failed: Connection reset by peer The two changesets in question are 1980659 and 1980698. Is there anybody who can help? Many thanks! Ulf -- Ulf Mehlig ulf.meh...@gmx.net -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] revert.pl
On 2 Aug 2009, at 23:26, Ulf Mehlig wrote: Replying to my own email ... I tried to revert the changesets again, via ssh from a server with much faster internet connection ... on second try revert.pl terminated without an error message now, but the ways of the respective changesets are still there when I download parts of the area in JOSM; the changesets also haven't disappeared from the history page :-( The changesets won't disappear from the history page. Reverting creates a new version with same tags/lat/lons of the one that you are reverting to, except the version number is incremented and the changeset is the one that you have used. This way w can revert your revert if required. Shaun Suggestions? Ulf On Sun, 2009-08-02 at 10:14 -0300, Ulf Mehlig wrote: I tried to revert two large changesets of mine (double import of municipal borders in Pará/north Brazil due to a local network problem) via revert.pl (fresh from svn); in the middle of the reversal process, I got the message GET http://www.openstreetmap.org/api/0.6/node/451437544/history... 500 Internal Server Error (369b) and now my try to resume the revert process ends after a number of deletions with relation 183111 cannot be retrieved: 500 read failed: Connection reset by peer The two changesets in question are 1980659 and 1980698. Is there anybody who can help? Many thanks! Ulf -- Ulf Mehlig ulf.meh...@gmx.net -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Mon, Aug 3, 2009 at 8:08 AM, Pierenpier...@gmail.com wrote: I'm not sure that the width of what we consider unclassified roads will double in the next century. Nevertheless, anything referring to what we consider is more variable across time and people than the length of a metre. I never mentionned narrow=* but narrow=yes, where did you see narrow=* ? I just meant using narrow as a tag, sorry, didn't realise narrow=* had a special meaning. Again, width is not less subjective because it is always estimated (deprecating est_width just hides this point), Precision is not synonymous with objectivity. This is important. Width is less subjective because the length of a metre is well-defined. If someone says I think a metre is this long, and holds out their hands, they can be proven correct or incorrect. If someone says I think this street is more narrow that what I would consider usual, they cannot be proven correct or incorrect. That is what it means when someone says width in metres is less subjective than a concept of narrowness and of usual width. it is missing in most of the highways This does not mean it is not a good tag. it is changing continuously along the roads So? So does the number of lanes, but that doesn't mean lanes is not a good tag. A way can be split where necessary (obviously a trade-off is necessary between precision of width value and number of splits, which would be same in the case of the use of narrow=yes). a width of 6 meters does not say if an hgv can pass or not, it will never replace the access restriction tags. So? No one is suggesting it should. narrow=yes has the same issue, but it is even less clear. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] revert.pl
Hi, Ulf Mehlig wrote: I tried to revert the changesets again, via ssh from a server with much faster internet connection ... on second try revert.pl terminated without an error message now, but the ways of the respective changesets are still there when I download parts of the area in JOSM; the changesets also haven't disappeared from the history page :-( Please do not try to use the undo/revert Perl scripts if you do not know exactly what you are doing. I don't want to sound too harsh but let me quote from the README file which you must have read or you wouldn't have been able to run the scripts: Be sure that you feel confident to fix anything you might break. If you do not know your PUTs from your GETs, if you do not know the details of API 0.6, or know what changesets are and how they work, then DO NOT USE THIS SOFTWARE. First of all, changesets will never disappear from the history page. All you do when reverting is you add a new version that re-creates the state something was in before a change. Second, the revert code is not really optimized for large-scale deletions like the one you're attempting. If I am not mistaken it will try and download the history of every one of the 20k nodes in your changeset when instead it should simply try and delete them... Why it didn't work I don't know, it is entirely possible that some error conditions do not lead to proper error messages. I'll try and fix it. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] revert.pl
2009/8/2 Ulf Mehlig ulf.meh...@gmx.net: I tried to revert two large changesets of mine (double import of municipal borders in Pará/north Brazil due to a local network problem) via revert.pl (fresh from svn); in the middle of the reversal process, I got the message GET http://www.openstreetmap.org/api/0.6/node/451437544/history... 500 Internal Server Error (369b) and now my try to resume the revert process ends after a number of deletions with relation 183111 cannot be retrieved: 500 read failed: Connection reset by peer The two changesets in question are 1980659 and 1980698. Is there anybody who can help? Since the changeset only contains creations, the easiest way I found to revert those is manually: * download the changeset xml (wget http://www.openstreetmap.org/api/0.6/changeset/1980698/download ...) * replace occurrences of create with delete (in vim :%s/create/delete/) * upload resulting changeset, you can use the upload script at http://www.openstreetmap.pl/balrog/bulkupload/upload.py for that (./upload.py newchangeset.osc) Similarly deletions can be reverted easily, only modifications need looking up the node history like revert.pl does. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
OJ W schrieb: On Sun, Aug 2, 2009 at 10:03 PM, Marc Coevoetsintsix...@gmail.com wrote: You can try the quadcopter too.. how would launching a quadcopter into orbit help? That's a small step for openstreetmap, one giant leap for quadcopters ;-) Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
2009/8/3 Roy Wallace waldo000...@gmail.com: On Mon, Aug 3, 2009 at 8:18 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: Certainly it would be even more useful, if there was a definition how to measure (inside road marking, complete with pavement, does the lateral paved area outside the road marking count, etc.). I think this is very important, and probably the biggest issue with a width tag. I would suggest: Tag the width of the surface on which users of the way are expected to travel. I agree and would like to add: and that is not constricted in the full usable height Sorry for my English, feel free to put it better, I try to explain: it is not about the height but the surface must be available in the full height, if there are obstacles protruding into the way, this width does not count. For plants I'm less sure here, as they tend to grow (yes, really) and after a while are cut though. So maybe it will only be about solid obstacles (say incl. trees) but not bushes and the like. For paved ways (roads, cycleways, footpaths, etc), this would normally be between the parallel edges of the paved area (i.e. not including road shoulder, etc). For roads with line marking, users of the way are expected to travel between the lines, so area outside the road marking would not count toward the value of the width tag. well, why not outside the lines? If you really have to know the width of the road (transport or similar, or you want to calculate the sealed area), you won't care about lines. Otherwise you won't need the width tag, because as I pointed out in another post: all usual vehicles (in Germany and probably Europe) must be inside 2,55 width and 4,00 m height. Otherwise they can not travel without beeing accompanied by policecars and other expensive stuff (like special permits, ...). For unpaved ways, the definition does not change - the surface on which users of the way are expected to travel. yes, in this case the tag will be highly subjective. Besides that unpaved ways tend to change continuously their width (be it along them as in different seasons), there will also be need of interpretation about the limits. Still a very useful tag, and good to distinguish a 30 cm footway from a 1,50 m one. If someone else sees them as 50 cm and 1,65 m, it still remains usefull. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, Aug 2, 2009 at 06:56, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/2 Liz ed...@billiau.net: So the question is: is there anything about a road inside an industrial or commercial area which would be important inside a renderer or a routing engine and is different to a residential road? yes. A residential road should be avoided if possible That's your opinion. If I'm in a car, I prefer residential areas to industrial ones. If I'm on foot or cycling, I prefer residential to any other class of road. Furthermore industrial areas are built according to standards that allow easy use with trucks, while in residential areas you will more often have smaller streets and straighter curves, which will cause problems to big trucks. In my part of the USA, the fire engine is the large vehicle of choice when designing roads, and it's about as big as un-manouverable as it gets. If your residential street isn't accessible to big trucks, people's houses burn down. The real issue here isn't trucks. It's that the prevailing standard of OSM is that unclassified is a higher level than residential, and that leaves no tag for places (including most everywhere I've been in the Americas, as well as, apparently, Australia) where roads in industrial areas not appreciably different from a residential street, but not abutted by houses. -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
--- On Sun, 2/8/09, Michael Kugelmann michaelk_...@gmx.de wrote: The article also says: It has three-quarters of the mass (0.75-kg) and volume of a CubeSat = quite small and the capacity will not be suficcient for appropriate lens/camera. And I'm shure it is not 3 axis stabilisation = no alignment to the desired target. If someone can rectify images taken out the side window of a plane as it comes in for landing, and taken by astronauts on the space station they could probably rectify images from a sat without stablisation. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 01:29:19 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Sun, 2/8/09, Michael Kugelmann michaelk_...@gmx.de wrote: The article also says: It has three-quarters of the mass (0.75-kg) and volume of a CubeSat = quite small and the capacity will not be suficcient for appropriate lens/camera. And I'm shure it is not 3 axis stabilisation = no alignment to the desired target. If someone can rectify images taken out the side window of a plane as it comes in for landing, and taken by astronauts on the space station they could probably rectify images from a sat without stablisation. Somebody please host the WMS But it can also result in an OpenLunaMap :D -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Help Deleting Changeset
Hi everyone, I was looking at importing some cemetery borders from Iowa today. I did the SHP-OSM conversion and fired up JOSM and started uploading. At the end, JOSM gave me an error saying that the server returned a 500 error code, so I gave up and went about my business. Fast forward to just now, when I get a message from someone telling me that the changeset [1] was indeed successful and resulted in thousands of nodes with no ways. I downloaded the osmChange file from [1], changed all the create to delete and tried to upload it with JOSM. JOSM says there's no data to upload. How do I remove all these created nodes? [1] http://www.openstreetmap.org/browse/changeset/2016885 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM satellite?
--- On Sun, 2/8/09, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: But it can also result in an OpenLunaMap :D You'd also get a star map too ;) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help Deleting Changeset
Ian Dees wrote: I downloaded the osmChange file from [1], changed all the create to delete and tried to upload it with JOSM. JOSM says there's no data to upload. I would think you'd have to open a new changeset and upload the osmChange directly to the API, not from JOSM. PS: Why did you tag all those nodes with landuse=cemetery? -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging roads
On Mon, Aug 3, 2009 at 9:39 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: Tag the width of the surface on which users of the way are expected to travel. I agree and would like to add: and that is not constricted in the full usable height I think the maxheight tag should be used here. There is no need to complicate the definition of width. If there is a large obstacle, then the width under that obstacle would not be included if and only if users of the way are NOT expected to travel under that obstacle. For paved ways (roads, cycleways, footpaths, etc), this would normally be between the parallel edges of the paved area (i.e. not including road shoulder, etc). For roads with line marking, users of the way are expected to travel between the lines, so area outside the road marking would not count toward the value of the width tag. well, why not outside the lines? If you really have to know the width of the road (transport or similar, or you want to calculate the sealed area), you won't care about lines. Because users are not expected to travel outside the lines. It also removes the need to consider the quality of the road outside the lines, e.g. if there's gravel next to a paved road, does that count? What about a drop-off? etc., etc. The lines are there for a reason, and that is to mark the width of the road that is designated as suitable for driving on. I think that's the most suitable width to tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Does this mean we could launch our own OSM s atellite?
On Mon, 3 Aug 2009 01:47:23 + (GMT), John Smith delta_foxt...@yahoo.com wrote: --- On Sun, 2/8/09, Aun Johnsen (via Webmail) skipp...@gimnechiske.org wrote: But it can also result in an OpenLunaMap :D You'd also get a star map too ;) Hubble go home, I have a compact cam :D -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help Deleting Changeset
(Sorry, should have reply-all'd): On Sun, Aug 2, 2009 at 8:56 PM, Lennard l...@xs4all.nl wrote: I would think you'd have to open a new changeset and upload the osmChange directly to the API, not from JOSM. How would I go about doing that? I suppose I could use curl or something similar, but is there a better way? PS: Why did you tag all those nodes with landuse=cemetery? I didn't. The original OSM 0.5 file had no tags on the nodes and landuse=cemetery on the ways. I would file a bug, but I don't have any logs or screenshots of the issue. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Help Deleting Changeset
Ian Dees wrote: How would I go about doing that? I suppose I could use curl or something similar, but is there a better way? If you can run perl scripts, have a look at: http://trac.openstreetmap.org/browser/applications/utils/revert -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] een amsterdam zonder keep right issues - bijna dan
Hi, Ik heb de laatste paar weken gewerkt aan het wegwerken van Keep Right issues binnen de A10 ring van Amsterdam. Dat is best gelukt, er zijn nog wat dingen die ik niet kan oplossen zonder er langs te fietsen of omdat ik domweg niet weet hoe ik het moet oplossen. Op dit moment zijn er geen issues meer voor: - non-closed ways - deprecated tags - missing tags - motorways without ref - places of worship without religion - ways without nodes - railway crossings without tag - wrongly used railway crossing tag - relations without type - overlapping ways - loopings - misspelled tags - Anderhalve issues bestaan er nog voor: - Voor dead-ended one-ways is er een issue [1] bij het Amstel station in de buurt. Dat is domweg het begin van een fietspad dat kilometers eerder hoort te beginnen. Ga ik ooit eens fix0ren. - Er is een issue voor ways without nodes, zie [2]. Geen idee hoe dat gedaan hoort te worden. Een way over de area's? Iets anders? Iemand? - Er is een fixme tagged item voor iets dat ik gewoon eens ter plekke moet beoordelen. Het gaat om een klein stukje van de tram rails bij het Centraal Station in de buurt, zie [3]. - Er is een intersections without junctions issue aan de Sixhavenweg, vlakbij de aanlegstijger van de veerpont bij het Centraal Station. Zie [4]. Onsite survey nodig. - Er zijn nog drie layer conflicts op verschillende plaatsen en op een manier waarvan ik niet weet hoe ik het hoor op te lossen. [5] - Er zijn nog twee motorways connected directly bij het Amstel Business Park in de buurt, zie [5]. Kan ik niet oplossen zonder er even te kijken. Komt nog wel eens. Er zijn nog veel issues voor dingen die minder belangrijk vind: - De almost-junctions. Het probleem is dat veel ervan gewoon false positives zijn of op zijn minst een on-site survey vereisen. - De point of interest without name issues. Persoonlijk vind ik deze categorie een stuk minder interesant, tenzij we hier iets structureel voor weten te bedenken. Slechts hier en daar eens een kroeg aanwijzen vind ik niet erg boeiend (niet om te doen, niet in gebruik). Dus. Als iemand de opstaande issues weet op te lossen (uitgezonderd de laatste twee categorieen), dan graag. Ik zal verder vanaf nu nieuwe issues proberen bij te houden, zodat het er niet meer meer worden. Ciao! [1] http://keepright.ipax.at/report_map.php?error=11991 [2] http://keepright.ipax.at/report_map.php?error=4561246 http://keepright.ipax.at/report_map.php?error=4561245 [3] http://keepright.ipax.at/report_map.php?error=548653 [4] http://keepright.ipax.at/report_map.php?error=4605962 http://keepright.ipax.at/report_map.php?error=4605963 [5] http://keepright.ipax.at/report_map.php?error=4745309 http://keepright.ipax.at/report_map.php?error=4778305 http://keepright.ipax.at/report_map.php?error=4785587 [6] http://keepright.ipax.at/report_map.php?error=4865780 http://keepright.ipax.at/report_map.php?error=4865782 -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] een amsterdam zonder keep right issues - bijna dan
++ 02/08/09 21:26 +0200 - Stefan de Konink: - Er is een issue voor ways without nodes, zie [2]. Geen idee hoe dat gedaan hoort te worden. Een way over de area's? Iets anders? Iemand? Die kunnen we wel handigmatig fixen. Spelen op meer locaties. Kleine verwarring van mijn zijde. Die ways without nodes zijn er niet meer binnen de A10 ring. De footnote verwijst ook naar een ander soort probleem, floating islands. Daarvan zijn er ook geen meer, behalve die twee die ik in de footnote noemde. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Australian Rendering
--- On Sun, 2/8/09, Liz ed...@billiau.net wrote: move the coral sea islands ;-) Actually there was no state place tag for Queensland, I've added one since, and the tiles will update sooner or later. I also moved the ACT tag, it was going over the top of Canberra, also Canberra was being hidden by Queenbyean so I updated the mapnik style sheet to prefer capitals over regular cities at lower zoom levels. There will probably be a lot of tweaks just to make things display properly for Australia even before changing the way roads look. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
I updated the rendering to show all villages, towns and cities and now the map is a lot more cluttered to the point of too much clutter, I think I'll make villages render at a higher zoom, not sure about towns. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] location tagging
Up until recently, that is today, I was tagging regional centres as place=city, however it might be worth while tagging this as place=regional_centre, or tagging them correctly and adding regional_centre=yes However I haven't figured out the zoom levels and how it relates to metres per pixel and so the town names are still unreadable as you zoom in :/ I'm going to email someone for a quote to do all this for me... ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] location tagging
On Sun, 2 Aug 2009, John Smith wrote: Up until recently, that is today, I was tagging regional centres as place=city, however it might be worth while tagging this as place=regional_centre, or tagging them correctly and adding regional_centre=yes Wilkipedia has a list of australian cities, as determined by the administrative bodies. So if the State determined list of cities says it is a city, then it is. Even though we just don't have a million people in each. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] location tagging
--- On Sun, 2/8/09, Liz ed...@billiau.net wrote: Wilkipedia has a list of australian cities, as determined by the administrative bodies. So if the State determined list of cities says it is a city, then it is. Even though we just don't have a million people in each. That doesn't help with designing map layout though, something might be tiny but still be a regional centre. I finally found the talk on the map styles, it was with the walking papers talk: http://www.vimeo.com/5593879 Stamen Design is the company, they specalise in map design among other things, going to email them about getting a quote on Aussie map layout for mapnik. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Draft: Looking for a mapstyle quote
Forgot to mention can I get URLs of what people expect a map to look like, I don't want to get into the whole copyright infringment thing, but links to other people that have won't be our problem. eg http://www.bilbys.org/session/maps/ubd_sat_ride.jpg While something like that would be nice, it looks a little out dated still so there should be a lot of wiggle room for us. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
I just tweaked things to show traffic lights at zoom levels 15-18, are there any other tags not being rendered that people would want to see on a map? eg speed camera? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
Are amenity=bench and amenity=bbq being rendered? I don't think there are many of these around but if they're rendered hopefully people will bother to tag them. - Original Message - From: John Smith delta_foxt...@yahoo.com Date: Sunday, August 2, 2009 6:33 pm Subject: Re: [talk-au] Australian Rendering To: talk-au@openstreetmap.org I just tweaked things to show traffic lights at zoom levels 15- 18, are there any other tags not being rendered that people would want to see on a map? eg speed camera? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
Oh, and is it easy to increase the font size on the suburb (locality?) names? I think they appear at z10 but they're *way* too small to read. Rendering the town names at lower zoom levels looks really good by the way. - Original Message - From: John Smith delta_foxt...@yahoo.com Date: Sunday, August 2, 2009 1:55 pm Subject: Re: [talk-au] Australian Rendering To: talk-au@openstreetmap.org I've been tweaking things on the mapserver I'm currently running. http://maps.bigtincan.com/ State borders now show at an appropriate zoom level, and I've made it so a picnic table icon shows, but the image I'm using atm needs changing so it looks awful at present. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
Hey, amenity=bbq would be an useful one. railway=platform would be a nice one as well. If you can come up with a style (I'd suggest one that renders exactly the same way as highway=footway;area=yes,) you can probably even submit it for inclusion in the main OSM render. :) If you're interested, I've been working somewhat on some 16*16px symbols which you're free to use. You can get the latest lot from http://barstool.ash.ms/osm/icons/ and though they're not labeled, the filenames are the same as the amenity=x values. Cheers, Ash. On Sun, 2009-08-02 at 20:20 +1000, b.schulz...@scu.edu.au wrote: Are amenity=bench and amenity=bbq being rendered? I don't think there are many of these around but if they're rendered hopefully people will bother to tag them. - Original Message - From: John Smith delta_foxt...@yahoo.com Date: Sunday, August 2, 2009 6:33 pm Subject: Re: [talk-au] Australian Rendering To: talk-au@openstreetmap.org I just tweaked things to show traffic lights at zoom levels 15- 18, are there any other tags not being rendered that people would want to see on a map? eg speed camera? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Ashley Kyd • Web Software Development in Brisbane, Australia. • Phone (07) 3129 2332, or visit http://kyd.com.au/ signature.asc Description: This is a digitally signed message part ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
On 02/08/2009, at 8:20 PM, b.schulz...@scu.edu.au wrote: amenity=bbq being rendered? Does anyone know if how to tag those has been discusses before? Australia seems to contain about an equal number of amenity=bbq and amenity=barbeque, with a handful of amenity=barbecue thrown in. There are a negligible number of them tagged in other countries. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
--- On Sun, 2/8/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: Are amenity=bench and amenity=bbq being rendered? I don't think there are many of these around but if they're rendered hopefully people will bother to tag them. Any graphic suggestions? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
David Dean, Hughbris, and I had a discussion on IRC recently, and decided that amenity=bbq is the best. It's the easiest to spell, and least ambiguous because both barbecue and barbeque are acceptable spellings depending on locality. Additionally, David proposed that the additional tag fuel=wood/gas/electric may be used to tag the fuel source. None of this has gone through any kind of official vote or anything, but I believe it's the de-facto standard in Brisbane at least. _ Cheers, Ash. On Sun, 2009-08-02 at 20:46 +1000, James Livingston wrote: On 02/08/2009, at 8:20 PM, b.schulz...@scu.edu.au wrote: amenity=bbq being rendered? Does anyone know if how to tag those has been discusses before? Australia seems to contain about an equal number of amenity=bbq and amenity=barbeque, with a handful of amenity=barbecue thrown in. There are a negligible number of them tagged in other countries. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Ashley Kyd • Web Software Development in Brisbane, Australia. • Phone (07) 3129 2332, or visit http://kyd.com.au/ signature.asc Description: This is a digitally signed message part ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
--- On Sun, 2/8/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: Oh, and is it easy to increase the font size on the suburb (locality?) names? I think they appear at z10 but they're *way* too small to read. Rendering the town names at lower zoom levels looks really good by the way. It's a lot of trial and error at the moment, zoom in the map eg z0-z18 needs to be converted to metres per pixel for mapnik. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Zoom levels
I finally figured out what the zoom levels equate to in metres per pixel, although it's probably 100ths or 1000ths of metres per pixel judging by z18. z0 = 313774583-627549167 z1 = 156887291-313774583 z2 = 78443645-156887291 z3 = 39221822-78443645 z4 = 19610911-39221822 z5 = 9805455-19610911 z6 = 4902727-9805455 z7 = 2451363-4902727 z8 = 1225681-2451363 z9 = 612840-1225681 z10 = 306420-612840 z11 = 153210-306420 z12 = 76605-153210 z13 = 38302-76605 z14 = 19151-38302 z15 = 9575-19151 z16 = 4787-9575 z17 = 2393-4787 z18 = 1196-2393 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
--- On Sun, 2/8/09, cam_...@fastmail.fm cam_...@fastmail.fm wrote: http://www.openstreetmap.org/?lat=-34.075996lon=150.803651zoom=18layers=B000FTFT Same thing with BBQ's showing. http://maps.bigtincan.com/?zoom=18lat=-34.07608lon=150.8037layers=B Just need an icon for benches. Also admin_level=10 no longer shows on maps. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
John Smith wrote: --- On Sun, 2/8/09, Darrin Smith bel...@beldin.org wrote: Why remove suburb boundaries? Because they aren't suburb boundaries, they're ABS boundaries. In 95% of cases they're close enough, are you going to throw out the baby with the bath water and dispose of the cases where people have adjusted them to be correct? Even in the places where they aren't they're the closest we're going to get for a long time. Darrin ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Australian Rendering
--- On Sun, 2/8/09, Darrin Smith bel...@beldin.org wrote: In 95% of cases they're close enough, are you going to throw out the baby with the bath water and dispose of the cases where people have adjusted them to be correct? Even in the places where they aren't they're the closest we're going to get for a long time. What about the 90% of Australia that isn't metro areas and these boundaries are all over the place and don't line up with towns, they're usually smaller or larger depending if the town grew, they also appear all over the place in rural areas where there is no town. It's the last point that I found them just noise they don't provide any meaningful information in rural areas, other than being boundaries for the ABS. I realise there is a need to show town and suburb boundaries. One way would be to elevate them to admin_level=9, another would be to alter the boundaries in rural areas to a lower admin_level. Either way the amount of work needed would be about the same. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
