Re: [OSM-talk] Tracks and there place in society
On 05/24/2011 01:49 PM, Richard Fairhurst wrote: > Um, we have that already. > > For physical tags, we have: > highway=footway, or > highway=cycleway, or > highway=bridleway, or > highway=track > > See http://wiki.openstreetmap.org/wiki/Duck_tagging. "If it quacks like a > duck, looks like a duck, and walks like a duck, call it a duck." It’s unfortunate then that footways, cycleways, and bridleways, and even some tracks, all fall within the same range of appearance. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM data used for X-Plane 10
On 04/18/2011 11:03 AM, M∡rtin Koppenhoefer wrote: > Yes, that's cool. There is also a screenshot here: > http://wiki.openstreetmap.org/wiki/Main_Page No, that’s a screenshot of data imported using OSM2XP. OSM2XP is a third-party tool which imports buildings and certain scenery objects into X-Plane. It doesn’t touch the roads. Integration of OSM roads into X-Plane proper is new. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM data used for X-Plane 10
I just saw this blog post yesterday, saying that OSM data will be used for showing road networks in the terrain data for the X-Plane flight simulator in version 10. http://www.x-plane.com/blog/2011/04/openstreetmap-and-x-plane-10/ Cool stuff! —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On 02/21/2011 11:26 AM, Kevin Peat wrote: The point isn't whether or not your tool will create correct route relations but what the point of doing that would be. I can understand creating route relations for long distance cycling/hiking paths that people actually want to navigate and historic routes (Route 66 comes to mind as a non-American) but what is the point of creating a route relation for every highway? Getting highway shields to render, for one. No-one gets up in the morning and decides to navigate "State Highway 483" from one end to the other and even if they did a decent routing engine could create the route on the fly, so adding it to OSM is a waste of time and would just add pointless complexity to the data-set. No one? Really? Pretty sure that some people do in fact do this sort of thing… —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=unsurfaced
On 01/12/2011 11:39 AM, Anthony wrote: Which I suppose is one of my main questions. If a way is tagged with highway=road, and nothing else, should a router route motor vehicle traffic down it? I would think the answer is yes, which means that paths which are not meant for motor vehicle traffic shouldn't be tagged with highway=road. Well, nothing should end up tagged as highway=road, it’s an interim tag only. It means exactly “we don’t know what this is, except it looks like a road from the aerial photos”: It could be private or pedestrian-only, there could be a gate or one-way spike strips, or bollards (rising or otherwise), or any number of other things which make it unsuitable for routing. So at best it could be routed with strong “use at your own risk” warnings. But in general it’s probably best if routers do not send people down them. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=unsurfaced
On 01/10/2011 11:27 AM, Richard Fairhurst wrote: Alex Mauer wrote: Which one were you thinking of? I count two road types in your list: highway=track and highway=unclassified. And it could be other highway=* types too. highway=track doesn't imply a road round here; clearly YMV. Sounds like the usage is wrong “round there” then. The example image on the wiki[1] clearly shows a road, and one which is pretty typical of a highway=track around here (green grassy field aside, given that it’s winter here) Obviously I can't speak for (and don't really care about) your part of the world, but I would consider a mass change of highway=unsurfaced to highway=road in the UK as vandalism, and would take steps to revert it. That seems quite extreme: while it might be better to do a best-guess+fixme, it’s not clearly “wrong” to change from one form of unknown road classification, to another form of unknown road classification. —Alex Mauer “hawke” 1. http://wiki.openstreetmap.org/wiki/File:Fr%C3%BChlingslandschft_Aaretal_Schweiz.jpg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=unsurfaced
On 01/09/2011 12:01 PM, Richard Fairhurst wrote: No. highway=unsurfaced could be what's now commonly tagged as highway=track, or highway=unclassified, or highway=bridleway. Only one of those three is a road. Which one were you thinking of? I count two road types in your list: highway=track and highway=unclassified. And it could be other highway=* types too. It’s still better to use highway=road even if it turns out to be a bridleway, because highway=road is basically “we don’t know what it is, only that there’s something there; this needs to be (re-)surveyed”. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Amenity key
On 10/22/2010 03:16 PM, David Murn wrote: On Fri, 2010-10-22 at 19:06 +0200, Claudius wrote: You could propose that footpaths should no longer use the highway= tag, as they’re not highways, using a similar argument. Sure they are. From Wikipedia: A highway is a public road, especially a major road connecting two or more destinations. Traditionally highways were used by people on foot or on horses. In English law, […] the term is used to denote any public road used which include streets, lanes as well as main road, trunk roads and motorways In American law, the word "highway" is sometimes used to denote any public way used for travel, whether major highway, freeway, turnpike, street, lane, alley, pathway, dirt track, footpaths, and trails, and navigable waterways. —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging Scheme Recommendations: highway=path, footway, trail?
On 08/30/2010 10:41 AM, Graham Jones wrote: I think we might need some finer grained assessment of c, because as my son gets bigger (or I get older!) I am finding I give up on more tracks than I used to... Does anyone know if there is such a scheme in use already, or would we need to invent a new one? You may want to have a look at the (much-maligned) smoothness tag: http://wiki.openstreetmap.org/wiki/Key:smoothness#Values —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Shared nodes between non-routable objects?
On 07/12/2010 03:22 PM, Alan Mintz wrote: > Exactly. +1. In the case described (building and attached parking lot), > it makes sense, as it usually does for adjacent land parcels (landuse=* > closed ways) and administrative subdivisions (boundary=administrative > closed ways) too. If they really are two polygons of a similar type that > share a single interface (edge), then glue them. If they just happen to > have parts that seem to lie in the same place, don't. Another case where I’ve found it especially useful to share nodes, even between routable and non-routable objects, is for speed limits. In at least one case that I’m aware of, the speed limit is defined in the law as “on XXX street, from YYY street westerly to the city limits”. The node where the speed limit-changing way split is located should also be part of the polygon that describes the city limits. —Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapquest launches site based on OSM!
On 07/09/2010 04:42 PM, Ian Dees wrote: > Presumably because the data's not good enough in the US to market it to the > whole world. Sure, but it’s beta anyway, so I think people wouldn’t be expecting too much from it. Still nice that they render it at least. —Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapquest launches site based on OSM!
On 07/09/2010 03:50 AM, David Ellams wrote: > The company, a subsidiary of AOL, plans to announce Friday > morning that it is launching a site in the U.K. based on a > project called OpenStreetMap, which is dedicated to > user-created mapping. I wonder why they seem to suggest that it’s UK-only? Scroll far enough West and the US shows up, sure enough. —Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Public notary (Map feature POI proposal)
On 01/05/2010 11:42 AM, Pieren wrote: > I suggested some time ago to use a new general key for such things > (when it's not really an amenity, a shop or a leisure like for > lawyers, architects, designers, etc) : office=notary service? Though that conflicts slightly with the service=* for describing a highway=service... -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tiger data and county lines
On 09/30/2009 09:46 AM, Mike N. wrote: > > JOSM - > How to select a way underneath another way? Usually admin boundaries are > selected when trying to select the way. When there are 2 duplicate ways > and nodes under an admin boundary, this is very time consuming. middle-click and hold to bring up a context menu; begin holding Ctrl key; mouse over the way you’re trying to select; release mouse button; release Ctrl. -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Patch to render names from routes and custom highway shields on a per country basis
On 09/21/2009 10:31 AM, John Smith wrote: > If we want to encourage others to be involved those others expect maps > to look a certain way, and if we can do it why shouldn't we to > encourage more people to participate, a world wide bland map is a turn > off. On the contrary, I think a unified look to the whole world is wonderful. It would be nice to have appropriate shields rendered though. -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Should Bridges be independent of their ways?
On 09/21/2009 09:20 AM, Anthony wrote: > On Mon, Sep 21, 2009 at 8:21 AM, d f wrote: > amenity=bridge (or would it be landuse=bridge?), to be attached to a way or > polygon. manmade=bridge? signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to map quarters?
On 09/11/2009 11:25 AM, Pieren wrote: > No, it's not a renderer problem, it is just different things. I'm not > a native english speaker but if I translate "suburb" and "quarters", > it is two different things. I can’t actually find any definition of “quarters”, but the definition that people have used in this thread fits with the definition of “suburb” as used within OSM. It’s not helped by the multiple definitions of “suburb”: Either a separate city (legally) which is in a sense a “satellite” of a larger one, or merely a subsection of a city. The relevant wikipedia article explains it fairly well. -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to map quarters?
On 09/11/2009 10:54 AM, Craig Wallace wrote: > Why? How does the renderer know whether its a large suburb that's within > a city, or a small suburb that's part of a town or village (or part of a > larger suburb). As you would want these to be shown at different zoom > levels, with different font sizes etc. > I know you can map the suburb as an area, to show its size, but that > isn't always practical. Many suburbs don't have clearly defined > boundaries, so its easiest just to use a node in the middle of it. I don’t think it's necessary to map the suburb as an area; only the place it’s within. If a suburb (node) is within a town (area), then render it smaller than one which is within a city (area). -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to map quarters?
On 09/11/2009 10:06 AM, Vlatko Kosturjak wrote: > Jonathan Bennett wrote: >> Valent Turkovic wrote: >>> Currently on wiki I only found place=suburb tag and I see that it is used >>> also for mapping city's quarters. >>> >>> Only issue is that when you map quarter of some town or village currently >>> the quarter has bigger font than name of village or town. >> > Maybe, it's time for tag microsuburb? which can be used with place=town > and place=village? Sounds to me like a renderer problem, not a case for a new tag. -Alex Mauer “hawke” signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] GPX tagging problem
On 09/01/2009 01:59 PM, Ed Loach wrote: > I think you can already do this. When someone added the comma > separator support recently I went through all my old traces adding > the commas at appropriate places Now that I know this, I'm trying to go back and re-tag some GPX tracks, but it keeps treating them as space-delimited instead of comma-delimited. Is something wrong with the tag interpreter? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Trace type
On 09/01/2009 01:59 PM, Ed Loach wrote: >> Two things that I think would be the most helpful, would be the >> ability >> to apply additional tags after the fact, > > I think you can already do this. Ah, so you can. I was only looking for edit links (which all went to Potlatch) and assumed that the "Edit this track" button went to the same place as all the edit links. Perhaps this could be changed, so that it's more obvious what exactly is being edited. Thanks -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Trace type
On 09/01/2009 12:25 PM, Peter Körner wrote: > I have not thought about adding that I used a bicycle for that. Without > having some kind of documentation about what *could* be added, people > won't add the information nor get developers to use them. > > So maybe a documentation about the possibilities would be a better start. Two things that I think would be the most helpful, would be the ability to apply additional tags after the fact, and some sort of way of showing common already-used tags (e.g. a completion dropdown while typing a tag value) -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
On 08/28/2009 03:46 AM, Gervase Markham wrote: > If dieterdriest has found a number of people who've been ignoring the > definition, Nobody (that I know of) has been ignoring the definition. It's just that the definitions didn't match the top-leveldescription. *None* of the definitions of the highway values has ever described the physical characteristics of the road, apart from motorway in a very limited sense. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging vague, ill-defined, or "unfriendly" paths
On 08/26/2009 10:19 AM, Roland Olbricht wrote: > I use > http://wiki.openstreetmap.org/wiki/Tag:highway=path/Examples > and have concluded to use > highway=path, wheelchair=no > The first tag classifies the way as being an unpaved and small path... It does nothing of the sort. unpaved would require surface=unpaved/dirt/mud/etc., while small would require the width tag, I think. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New dimension of vandalism
On 08/26/2009 05:23 AM, lulu-...@gmx.de wrote: > There was a change on the highway key wiki page, that interferes with the > concept presented here. > > http://wiki.openstreetmap.org/index.php?title=Key%3Ahighway&diff=317630&oldid=317451 > > User Dieterdreist has changed the description so the highway tag is no longer > used for the objective physical description but for a subjective feeling of > "importance". Millions of highway tags would need to be reviewed if this > change without proposal and approval would become valid. IMHO, this is just putting the description in line with actual usage. The highway tag is inadequate as a physical description of the way. The only one that takes physical structure into account at all is motorway, and that's only in how other roads connect to it; not how the road itself is built. Please consider http://wiki.openstreetmap.org/wiki/Proposed_features/Highway_administrative_and_physical_descriptions if you need a tag which actually does cover physical structure. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
On 08/13/2009 01:24 PM, David Earl wrote: > realise we are missing a use case (say we discover motorways in Ecuador > permit learner drivers to use them [please don't tell me this isn't the > case - it's only an example]) we have to add tags to every other highway you don't even have to go that far -- at least some, probably most or all, states in the US allow learner drivers to use the motorway/freeway/interstate. -Alex mauer "Hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/12/2009 12:46 PM, Martin Koppenhoefer wrote: > so the routers don't send the ambulances that way if it's shorter? That's meant to be interpreted "as emergency=destination". As far as I know, emergency vehicles are pretty much allowed to go where they need to; this gets back to the idea of "suitability", which people are keen to remove from the access=* tags. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/12/2009 05:14 AM, Pieren wrote: > see why we should add "foot=no" now in all cycleways in France. I read > somewhere that some motorways in US gives access to bicycles. Does it > mean that we have to add "bicycle=no" to all other motorways in the > world ? No, that would make no sense because most motorway-equivalents around the world do not allow bicycles. We have to add bicycle=yes to the motorways that allow it. designated means "with a sign" in most cases; however I am sure there are some places in the world where it's only defined in the local law, without actually being signed. Hence the lack of "it needs a sign" in the wiki for access=designated. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag proposal surface=gravel; concrete: dirt; grass
On 08/11/2009 07:41 PM, Sam Vekemans wrote: > So anyway, i propose to add surface=gravel;dirt;grass;concrete, to go > along side highway=value. (which listed more generally, what the way > is generally used for (type of travel between 2 points) We already have those values, see http://wiki.openstreetmap.org/wiki/Key:surface -- or am I missing something? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/11/2009 01:58 PM, DavidD wrote: > 2009/8/11 Tobias Knerr : > >> Those eight people can only do this if not even 0.1% of the other 1 >> care enough to oppose the proposal. If that's the case, then apparently >> the proposal isn't so bad, is it? Why didn't all those people who >> apparently hate "path" vote against it? > > I originally did vote against it. Then when it looked like the vote > would go the wrong way it was stopped before being started again some > time later after tweaking the proposal. Yup. Problems were brought up (primarily the idea of deprecating footway/bridleway/cycleway), so they were corrected. Seems like a good practice to me, and a large part of the purpose of the whole voting system. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/10/2009 05:27 AM, Frank Sautter wrote: > Tom Chance wrote: >> I'm 100% unclear about the distinction between highway=path and >> highway=footway. > > the whole "highway=path"-thingy was victim of a "hostile takeover" ;-) It was? when did that happen? can you point to it in the wiki? > at the beginning highway=path was proposed as a something like a NARROW > highway=track for use by bike, foot, horse, hiking, deer (mainly in > non-urban areas). No it wasn't. Read the history at http://wiki.openstreetmap.org/index.php?title=Approved_features/Path&dir=prev&action=history Prior to that, I created the proposal "Trail" which was also not like you describe. http://wiki.openstreetmap.org/wiki/Proposed_features/Trail From the very beginning, it did not mean what you say it did. Maybe you're thinking of something else? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/10/2009 05:31 PM, Liz wrote: > On Mon, 10 Aug 2009, Dave Stubbs wrote: >> Anarchy in tagging died a bit back when some guys on the wiki decided >> ochlocracy was the way to go. >> Tagging used to be occasionally a confused mess. >> Now it's an organised, and "approved" confused mess where anyone with >> a clue automatically withdraws from discussions to keep their sanity >> intact (and to give them some more time to go and actually map >> something), knowing full well that not being there won't make much >> difference to the eventual stupid decision. >> >> Gah... must... be... more... positive... > > I would consider that if we have thousands of mappers, that we should set a > quorum for a vote > so that unless at least x hundred people vote the vote is not valid From http://wiki.openstreetmap.org/wiki/Proposed_features#Proposal_Status_Process: "8 unanimous approval votes or 15 total votes with a majority approval" It seems to me that we have one. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
On 08/10/2009 07:28 AM, Martin Koppenhoefer wrote: > highway=cycleway > foot=official > > that latter was introduced (probably by the same people that already > forced path) Nope. Cbm and I were the ones behind highway=path, as you can see from the wiki. Access=official has nothing to do with me. I agree that it's redundant -- it seems like it's just a combination of travelmode=designated and access=no. Not sure how you think path was "forced" though. It had 34 votes, 22 for and 9 against (3 abstain). Nobody forced anything, we just used the standard procedure. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On 08/04/2009 07:17 PM, David Lynch wrote: > The USA has no such sign, nor do Canada and Mexico (AFAIK.) Do we have > no motorways? > http://en.wikipedia.org/wiki/File:I-95.svg -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-au] maxheight/height
On 07/28/2009 11:45 AM, Christoph Böhme wrote: > According to Wikipedia "clearance" [1] is the free space between a > vehicle and the structure (i.e. bridge) it is passing through. The > maximum height (and width) of the vehicle is -- at least for railways -- > called "loading gauge" [2] while the dimensions of the structure are > called "structure gauge [3]. Thus, what we find on signs is the loading > gauge. It may also be worth mentioning that there's another meaning of "clearance" when referring to vehicles: that of the free space beneath a vehicle (ground clearance). So it would seem that "clearance" always refers to "free space below" -- meaning that it's the bridge's clearance that is marked. This does not contradict that it is also the loading gauge of the vehicles passing underneath it... -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Communications tower/transponders
Simon Wood wrote: > On Wed, 1 Jul 2009 23:17:37 -0600 > Simon Wood wrote: > >> I have had a go at tidying the proposed tags for communication towers and >> would welcome any comments. >> >> http://wiki.openstreetmap.org/index.php/Proposed_features/Communications_tower >> http://wiki.openstreetmap.org/wiki/Proposed_features/Communications_Transponder >> > > If no-one has any objections I'd like to formally move these to the 'RFC' > stage. Do I do it just by setting the date field? > > Simon, Yup. That and send a message to the list, for which the above message will do the job nicely. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Hatto von Hatzfeld wrote: > Russ Nelson wrote: > >> On Mar 28, 2009, at 1:50 AM, Stephen Hope wrote: >> >>> I don't feel right calling it a cycleway if they >>> have to give way to other users. >> Cyclists ALWAYS have to give way to other users. It's a simple matter >> of the laws of physics. > > At least here in Germany there are cycleways which are not allowed for > pedestrians and others which are shared by cyclists and pedestrians. This is also true in at least some parts of the US. I suppose it's technically still true that cyclists have to at least try to give way (I assume that if a pedestrian is walking down the motorway, motorists shouldn't just casually run them down; the cycleway situation is similar) -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Stephen Hope wrote: > OK, so while we're talking about this, there are a number of paths > near me. Nice smooth concrete, about 2m wide. They run through parks, > and there are signs on the park as a whole that say "No motorised > vehicles". These paths are marked with a sign that has a pedestrian > and a bicycle, and another sign that says "Cyclists give way to > Pedestrians". How would you normally mark these? I've used footway, > plus bicycle=yes. I don't feel right calling it a cycleway if they > have to give way to other users. I would tag it as highway=path+bicycle=designated+foot=designated. highway=cycleway+foot=designated would also make sense, IMO. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Richard Mann wrote: > We all contribute in our own way. For instance I found 1467 instances of > snowmobile=no in Germany in tagwatch. It isn't clear whether each of those > had the proper No Snowmobiles sign (the wiki seems to be a bit vague on the > criteria) :) Even aside from signs it's hard to say whether this is correct or not. Maybe snowmobiles are always illegal on some type of route in Germany -- is it then incorrect to tag it with snowmobile=no? I'd say not. In fact, it might be most correct to put snowmobile=no on nearly every road in Germany...I know this is true in Wisconsin. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Richard Fairhurst wrote: > Alex Mauer wrote: >>> Richard Fairhurst wrote: >>>> Map Features says that highway=cycleway should be used for ways that >>>> are mainly/exclusively for bicycles. >>> Map Features is wrong. :) >> So you're saying that highway=cycleway is not intended for ways >> which are for bicycles? > > Thanks for putting words into my mouth. Clearly I'm not. You went too far in your change, "A path on which bicycle access is permitted." What makes a way a cycleway, other than being mainly for bicycles? > "mainly/exclusively" is the difference. Access permissions cascade down[1]. Down from what, to what? What's the hierarchy? As far as I can interpret this, you mean that "access always defaults to yes *except on motorways" -- Is this correct? > So why on earth you think that highway=cycleway;foot=yes is still required, > I have no idea. Unless, of course, you do actually go around tagging > highway=secondary;motorcar=yes;foot=yes etc. etc., in which case full marks > for consistency albeit no marks for clue. Well, either you're tagging foot=yes+horse=yes+ski=yes+moped=yes+snowmobile=yes on a large subset of paths, or you're tagging foot=no+horse=no+ski=no+moped=no+snowmobile=no on a large subset of paths. I find that most paths have a list of what is allowed to use them, so between a bunch of yes values and a bunch of no values, "yes" makes more sense IMO. Roads are not the same, they should be "default access yes". But at least around here, paths -- including those for bicycles, horse, or foot -- should be "default no" > But, you know, well done on finally uploading some GPS tracks in the last > few weeks (http://www.openstreetmap.org/user/Hawke/traces). Maybe actually > doing some mapping will give your opinions some weight, rather than just > being another tedious wikignome. We live in hope. For what it's worth, I've had my city essentially complete[1] for about 2 years, and created my own render of the local paths and truck routes[2]. So I hope that my opinions carry at least some weight, and I'll thank you not to insult my contributions. 1. http://wiki.openstreetmap.org/images/b/b3/Hawke_northwestportage.png 2. http://web.hawkesnest.net/osm.html signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Ed Loach wrote: >> So you're saying that highway=cycleway is not intended for ways >> which >> are for bicycles? What an ... interesting interpretation! > > I think mainly/exclusively may overstress the exclusively bit. In a few jurisdictions and a few cases, they're exclusive; in most jurisdictions some other traffic may use it. Hence "mainly" (most jurisdictions) or "exclusively" (a few jurisdictions). > I see > highway=path as a handy shortcut like highway=road for tagging > something until a 'proper' tag can be assigned, though I realise not > everyone will agree... Yes, we'll have to agree to disagree on that one. http://wiki.openstreetmap.org/images/8/84/Designatedsigns.jpeg is an example I keep coming back to for this kind of thing. It's quite clearly not a cycleway, a footway, or a bridleway. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Richard Fairhurst wrote: > Richard Mann wrote: >> Map Features says that highway=cycleway should be used for ways that >> are mainly/exclusively for bicycles. > > Map Features is wrong. :) So you're saying that highway=cycleway is not intended for ways which are for bicycles? What an ... interesting interpretation! -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Note that Richard's is not a definitive answer (not that this one is either). My own interpretation is: 1. path: a route, 2-4 meters wide, possibly paved, possibly with a slightly wider shoulder. Too confined or narrow for a car to navigate safely, especially if there are other people using it (no passing room at all). 2. footway: same as a path, but no provision is made for any traffic besides pedestrian. (bridges may not be strong enough to support a horse, walls/fences crossed by stiles, narrow gates, etc.) 3. bridleway: same as a path, but no provision is made for any traffic besides equestrian. 4. cycleway: same as a path, but no provision is made for any traffic except bicycles. 5. track: a road which is not graded or paved, but created by people driving along it. It might be built to the extent that trees have been removed and grass or brush cleared. At its simplest, it is just a pair of wheel ruts. Definitely intended for four-wheeled motor vehicles, though it may be risky to drive a normal car along it. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] mapnik riverbank problem
The large cluster of islands within a riverbank visible here on the osmarender layer: http://www.informationfreeway.org/?lat=44.559416836708124&lon=-89.63008108668645&zoom=14&layers=BF000F ...does not show up properly on Mapnik. As far as I can tell, it's tagged entirely correctly. I've managed to get a few islands to render correctly by loading and then saving them without making any actual changes. Is there something weird with mapnik where the order in which the ways are stored in the database would matter? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] place=island rendering
Ted Mielczarek wrote: > I've noticed that there's a GNIS import going on in the USA recently, > and one of the types of POIs being imported are islands, which are > tagged place=island. Of course, the GNIS database contains some very > tiny islands, but Mapnik renders place=island up to z10. For example: I opened ticket #1644 (http://trac.openstreetmap.org/ticket/1644) about the problem. One solution is to apply the tags to the area rather than the node. (and thus render appropriately based on the actual size of the island. Of course, this also implies deleting the place=island node to avoid label conflicts. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] RFC: Highway administrative and physical descriptions
Please read and comment on the following proposal, intended to provide a method to describe the physical road as well as the legal/administrative designation of a road, in more detail than the highway key. http://wiki.openstreetmap.org/wiki/Proposed_features/Highway_administrative_and_physical_descriptions -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSM on LWN
An article about OpenStreetMap was included on this week's Linux Weekly News front page. It's primarily about the relatively recent influx of large amounts of imported data. The article can be read here: http://lwn.net/SubscriberLink/318801/9860286043a9f77c/ -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Key:smoothness, value:Good - summary
Sam Vekemans wrote: > Hi all,1st off I got the page set up better now :) > http://wiki.openstreetmap.org/wiki/Tag:smoothness%3Dgood > > BTW The page http://wiki.openstreetmap.org/wiki/Key:smoothness > and the page http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness > should actually be merged, as the page ALSO lists the values. > > I organized the page so we have 'discussion FOR' and 'discussion AGAINST' > so that should encourage people to list explanations in the right place. I > think that the talk page should be more for the 'Overall Wiki page > discussion', as technically speaking, the 'discussion:For' and 'against' is > actually part of the map feature proposal process. > ::We submit ideas, talk about it with examples, then refine our ideas until > a satisfied answer is found. > (in contrast, submitting ideas like headings to be changed, and > content omitted/added.. is needed for the talk page) I don't understand: the original key:smoothness proposal was accepted, why would we need a new rfc/approval process for each separate value? If you want to propose a slew of new values to replace the good/bad/horrible series for smoothness=*, why not create a new page for that (or contribute to the existing proposed "usability" key or "surface unification") -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki: chriscf vandalism
Richard Fairhurst wrote: > But around here in rural Charlbury, that kind of information is absolutely > crucial when mapping bridleways. As someone on the wiki pointed out, though, > the smoothness tag as currently conceived is near as dammit useless for > these because it offers no chance for differentiating between winter and > summer. There's a very good reason for that: Seasonal changes are not a generally solved problem in OSM, and so smoothness doesn't solve it. Compare the "access" tag series. Similarly, I could say "the access tag is useless because it offers no chance for differentiating between winter and summer". Many trails and some roads have different access in summer vs. winter. But does that mean that the whole access system is useless? No! Some other new system will be needed to handle seasonal differentiation, and it'll need to handle seasonal differentiation of all kinds of features. Tacking it onto an unrelated tag would be a mistake. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google Maps - OSM comparison
> Captials in Europe are done very well (Vaduz is an exception) > > In South America OSM is far behind Google > > In Afrika the winner is OSM > > In Asia it's mixed. > I ran through the whole list, ranking the quality of the map for each of OSM and Google on a scale of 0-5. (0 meaning that the map is blank or only the name appears, 5 meaning that it doesn't seem like anything is missing from the map) Assuming I did a good job of ranking, OSM is slightly ahead of Google worldwide and in in Africa and Asia. In Europe, OSM is well ahead. Google is slightly ahead in Oceania, and well ahead in North and especially South America Here are the results (I can provide my rankings in a spreadsheet as well if anyone is interested): OSM Google World 2.642.50 Africa 2.021.78 Asia2.622.36 Europe 3.903.38 N Am2.172.77 Oceania 2.192.35 S Am 2.363.21 -Alex Mauer "hawke ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Edit war on the wiki "map features"
Ed Loach wrote: > Looks good to me. Describe what the road is like, rather than making > subjective judgments. Every driver/cyclist/vehicle will be different > and will have to make their own choices. You can't tag for that. Or > perhaps usability:kia_cee'd:edloach=good / > usability:unicycle:edloach=can't balance Except that leads to impossibly complex tagging and mapping requirements. pothole_coverage max_pothole_depth= max_pothole_circumference= max_pothole_length= max_pothole_width= average_pothole_depth= average_pothole_circumference= average_pothole_length= average_pothole_width= center_hump_height max_rut_depth max_stone_diameter average_stone_diameter max_root_diameter average_root_diameter minimum_ground_clearance largest_unavoidable_bump_height for a motorcycle largest_unavoidable_bump_height_for_a_car_2m_wide largest_unavoidable_bump_height_for_a_bicycle maximum_mud_depth average_mud_viscosity maximum_rut_depth maximum_puddle_depth_during_rainy_season maximum_puddle_depth_one_hour_after_5_cm_of_rain Get out your measuring sticks and other tools, and be prepared to stop regularly to measure! There's more to surface quality than merely what it's made out of. surface=* just doesn't cut it. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Edit war on the wiki "map features"
Douglas Furlong wrote: > My biggest issues is that smoothness varies depending on the vehicle in > question, and as such it's just to vague to really be of use. No it doesn't. It's not like a paving machine runs just ahead of every off-road vehicle, making the road smoother for them. The smoothness of the way is the same, whether you're using inline skates, or a tank. The vehicle is just a tool for measuring the smoothness. At one end of the scale, you have a perfectly smooth ride (or at least the best the vehicle can give), no matter what vehicle you're in. At the other end, you have total unsuitability for all but a few vehicles. > If you tag a road with smoothness valid for a car user (what type of car? > 4wd big effin thing, or a lotus elise?), Did you even read the smoothness key page? It clearly defines different values for each of them. If it's usable in the former, it's at worst smoothness=horrible. If it's usable in the latter, it's at worst smoothness=intermediate. There is no smoothness "valid for a car user". "bad" is usable by a "normal car", intermediate is usable by a "sports car". (I consider the Elise a sports car). > then what about a cyclist (and lets > not even start looking at the different types of cyclists!). I just perceive > it to be far to vague to cover the average users of that way, it's got > nothing to do with fringe cases at all. There is no generic "cyclist". It depends on type of bicycle they're using. And smoothness takes that into account. A mountain bike (and a suitably skilled rider, presumably) can use routes that a racing bike cannot. > specialist tagging for those who care to do it in > those area's That's not what the smoothness key attempts to accomplish. What it attempts to do is give a simple, single-key estimate of how rough/smooth a road or path is. The various vehicle types are there only to give examples of what sort of vehicles can be expected to tolerate a given class of road (and to say how a road which can be tolerated by a given vehicle should be classified). Are there perhaps two different sets of expectations for the smoothness key? On the one hand, there are people who expect something like mtb:scale and sac_scale, where it defines the quality or difficulty of a given route for a given vehicle type. And on the other hand, there are people who just want to know how smooth the route is (based on what vehicles can handle it), and can judge from there whether they're willing to take their vehicle down it. I think the smoothness key is currently based around the latter, and that the objections come from the former. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Edit war on the wiki "map features"
Pieren wrote: > I would also show the fact that it was approved by > keeping the entry in the "Approved Features" with a note that strong > oppositions and open issues have to be fixed before it goes to the > "Map Features". I agree that would be appropriate if there were any strong oppositions besides chriscf saying "I don't like it". Reading the talk page, there are the following: "smoothness and surface": Addressed by way of explanation: any mentioned surface types are examples, not criteria. Furthermore, they're no longer used in favor of describing what vehicles can use it. "subjective": This is really about being vague. Addressed, in that there are clear criteria for how smoothness should be determined. "catastrophic": The term "catastrophic" doesn't fit. Addressed by using a different term. "impassable": how can a way be impassable -- if it's impassable, it's not a way. Addressed by noting that smoothness only applies to wheeled vehicles. Not all ways are meant to be used by wheeled vehicles. "laterally varying smoothness". This one was not addressed, but is IMO a very minor one, as OSM does not currently have any general way of dealing with anything that differs between left and right on a way. "elaborate on 4wd": Addressed by using more correct term. The rest are not seriously objections. There are: ...various alternate proposals...some vehicles missing from the table...a suggestion to break it up into a bunch of different keys ... discussion of default values...discussion of the deprecation of another tag. So yeah. Only one unaddressed objection, and that one is very minor. If I missed something, I'd love to be pointed at it. If not, it's my opinion that the smoothness tag should stay in map features (assuming that map features is to remain the place for recommended tags to be listed) On the topic of whether that's a good idea and/or fixing the size of map features, I think the thing to do would be to only list keys on map features. Values should be documented on the Key:* pages. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Footpaths (was: Re: Ordnance Survey tries to reinforce its stranglehold over "derived" geographic data in the UK)
Shaun McDonald wrote: > Who stopped rendering highway=footway, and when footway is not the same as footpath. I don't think anyone has stopped rendering highway=footway. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] barrier=gate
Dave Stubbs wrote: > On Sun, Nov 9, 2008 at 8:46 AM, Nic Roets <[EMAIL PROTECTED]> wrote: >> According to the wiki redirects, barrier=gate is replacing highway=gate. >> According to tagwatch, the latter is 10 times more popular than the former. > > Yes, because the barrier=gate people decided it makes more sense. I'm > not sure a wiki redirect is the correct way of going about it... but > they're essentially the same thing. Obviously highway=gate has been > around much longer. Leaving aside barrier=gate vs. highway=gate, there was not a wiki page at Tag:highway=gate until the redirect was added. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] UK Industrial Estate Roads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Scotton wrote: > Hi, > > I added some streets recently on an industrial estate and tagged them > highway=road as I'm not sure what other tag to use. > > They are roads on a uk industrial estate with the normal white lines in > the middle of the road. > > Should I use something like highway=industrial, or something else? highway=service or highway=unclassified, I would say. - -Alex Mauer "hawke" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkUblsACgkQ66h/gpo37v/9ugCfVITF2MIRnRMzZaphA1hlWF8r 5DQAmwZ35tDbVjZ1jreVMgS980EyVo6o =UBwf -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] footway vs. path [Was: highway=track and motorcar=yes/no]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Dorsch wrote: > I am wondering what is the difference between footway and path? sac_scale on > http://wiki.openstreetmap.org/index.php/Map_Features seems to apply for both. > Does that mean a mountain hiking path can be a path or a footway? > > Are paths larger than footways? > > Is it for paths required that any other vehicle/horse can use the path > otherwise it is a footway? There is no defined physical difference between footway and path. The difference is that footways are primarily or exclusively for use by foot traffic, while paths are not. - -Alex Mauer "hawke" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkR/nMACgkQ66h/gpo37v+r0gCg5BPMprzpLilVXCx2W2p0eQ5P bckAn0U51e+jMb4Hdy8cFLqFvao4O19r =gUnO -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=track and motorcar=yes/no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Dorsch wrote: > What is the difference between "access restriction" and "are not allowed" ? None. - -Alex Mauer "hawke" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkR/YIACgkQ66h/gpo37v+Z5QCgwBwLqfqaDxyBE883w82YDFkD irYAoIOws4AUDR0Gk44RLVY9Vzzl3306 =XPnn -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Mapnik Style
Chris Hill wrote: >> Anyone else feels like that? > I agree that some of the roads look washed-out. I think part of the > problem is that there doesn't seem to be a casing any more for trunk, > primary and secondary. I do like the icons. The lack of casing definitely makes the bridges more visible though, which is nice. It is a bit washed out though. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Claudius Henrichs wrote: > Can you tell any advantage of implying highway=motorway_link to be oneway? It depends on what you're comparing it to. versus implying it to be oneway=unknown, there's a reduction in the amount of tagging needed because less than 100% of the ways with highway=motorway_link need to be tagged with oneway=yes/no. And of course, a routing application specifically can't use oneway=unknown (they have only the choice of "use the way for routing" or "don't use the way for routing". So a routing application would have to make their own decision on which assumption to make) versus implying it to be oneway=no, there's *probably* a reduction in the amount of tagging needed, because there are probably more ways with motorway_link that are oneway=yes than oneway=no. In addition, for a routing application it increases safety. It's a lot worse to route someone the wrong way up a one-way motorway_link because it was assumed to be two-way than it is to send someone on a longer/slower route because it was assumed to be one-way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Ian Dees wrote: > there's got to be > somewhere on this great planet of ours where a highway=motorway_link or > highway=motorway is not oneway=yes, but it is safe to assume that when > highway=*, motorcar=yes is always safe to assume. Oh, there definitely are places where highway=motorway is not oneway=yes -- but in those cases they can be tagged with oneway=no. That does put a greater burden of tagging on people in those areas, but IMO it's better to place that burden on 5% or so of mappers than to put it on 100% of mappers. highway=* isn't always motorcar=yes, either. There's a table at http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Access-Restrictions which describes the restrictions. (Note: I did not create it.) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Ian Dees wrote: > On Wed, Oct 8, 2008 at 11:15 AM, Alex Mauer <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Ian Dees wrote: > > +1 here, too. > > > > There should be zero implied tags. Ever. > > Great, you want to go ahead and tag bridge=no,motorcar=yes,hgv=yes, etc. > on every single way where that applies? thanks in advance. > > > No, I'm saying that tags should not be added because they are assumed. Isn't "assumed" the same as "implied" in this context? Are you taking "implied" to mean "It is implied that you must also use this other tag"? Because I've been using it to mean that there is no need to use this other tag because it is implied by the first one. IMO, highway=motorway(_link) is to oneway=yes as highway=* is to bridge=no. (and motorcar=yes, hgv=yes, etc.) in that there is no need to add the latter when the former is there. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Ian Dees wrote: > +1 here, too. > > There should be zero implied tags. Ever. Great, you want to go ahead and tag bridge=no,motorcar=yes,hgv=yes, etc. on every single way where that applies? thanks in advance. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
On 10/3/2008 6:27 AM, Ben Laenen wrote: > Then read the example on > http://wiki.openstreetmap.org/index.php/Tag:highway=motorway_link once. > It says: "The green way in this example can then be a simple junction > withhighway=motorway_link without the oneway tag, as it is supposed to > be used in both directions." > > When you read that, you don't assume there's no implicated oneway value. > It says that by default it's oneway=no like with any other road. Fair enough, though as far as I know it's never stated anywhere else that oneway=no is the default. Certainly it's not on the Key:highway or the Key:oneway page. > Note that the "implies oneway=yes" in the right column wasn't added on > the page until June this year. Only from that point onwards the page > started contradicting itself. Before that it clearly said oneway=no is > implied. Only since October 2007. So there's a seven month window in which it could have been taken to be oneway=no by default, though that was never stated clearly. > Hence the only option is to revisit all motorway links that don't have a > oneway value and add it. After that we may have a oneway=yes > implication. It's really not the only option. We can also just accept that there are a few motorway_link tags that are wrong. Which there probably will be no matter what. I'd much rather have sane defaults and a slight inaccuracy then have to deal with insane defaults forever just because of a short window created by someone who made some bad assumptions. -Alex Mauer "hawke". ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Ben Laenen wrote: >> There are three options: >> 1. make no assumptions: This means every single motorway_link needs >> to have a oneway=yes or oneway=no (or oneway=-1). A pain for >> taggers, and doesn't help makers of routing applications who still >> need to handle the case where there is no oneway tag. > > Given the changing implication of oneway=yes this is actually the only > option left -- like it or not, painful or not -- since they could be > added by people who read that it was implied and by people who read it > wasn't. Nah, it's not that bad. It just means that the only data currently in there is built on the following: Either the person assumed there was no implied value for one-way, in which case they would have explicitly tagged all of them. Or they read that oneway=yes was implied, in which case they would have only tagged the oneway=no and oneway=-1. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Matthias Julius wrote: > I don't. I think it follows the "principle of least surprise" better > if implied values don't change too much. Great, then we should leave this as-is (implied oneway=yes for motorway_link) >If a highway is not oneway >by definition oneway=yes should not be implied. You do realize that "implies" means "if no value is specified, this should be the value that is understood", right? That the actual tags over-ride the implied value? So "the implied value could be incorrect some of the time" is no reason not to have an implied value. That's why it can be over-ridden by applying the appropriate tag. Having the implication is about reducing the effort required for someone to tag a motorway, and making it so that consumers of OSM data can make assumptions about the data. There are three options: 1. make no assumptions: This means every single motorway_link needs to have a oneway=yes or oneway=no (or oneway=-1). A pain for taggers, and doesn't help makers of routing applications who still need to handle the case where there is no oneway tag. 2. Assume oneway=no. This means that 95+% of motorway_links must be tagged. Still a pain for taggers. Makers of routing apps can't safely make this assumption anyway for fear of routing someone the wrong way up the motorway_link. It does mean that motorway_link has the same default as the other highways except for motorway though. 3. Assume oneway=yes. This means only 5-% of motorway_links must be tagged. It's the safe assumption that routers will have to make anyway. And of course it doesn't prevent anyone who wants to from explicitly specifying a oneway key/value for every motorway_link if they feel like it... Looking at the above, assuming oneway=yes seems the only way to go. Am I missing some big problem with it? > Trunk roads are > probably mostly oneway, too ... Off-topic. This is about motorway_link. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] - RFC - Motorway_link implies oneway=??
Nic Roets wrote: > My opinion is that motorway and motorway_link must both default to > oneway=true, as the bi-directional varieties are non-existent / very rare. I agree. Even if they're not "very rare", they're certainly less common than the one-way variety. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FILO patch: color command: make color byte like VGA.
Alex Mauer wrote: > Attached please find a patch for FILO which: > > * Swaps the order of the nybbles in the color setting byte to make it > the same as the traditional VGA BIOS color byte. > > Signed-off-by: Alex Mauer <[EMAIL PROTECTED]> > > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk whoops, wrong list. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] FILO patch: color command: make color byte like VGA.
Attached please find a patch for FILO which:
* Swaps the order of the nybbles in the color setting byte to make it
the same as the traditional VGA BIOS color byte.
Signed-off-by: Alex Mauer <[EMAIL PROTECTED]>
Index: main/grub/grub.c
===
--- main/grub/grub.c (revision 73)
+++ main/grub/grub.c (working copy)
@@ -901,8 +901,8 @@
endwin();
using_grub_interface = 1;
- console_setcolor((COLOR_WHITE << 4) | COLOR_BLACK,
- (COLOR_BLACK << 4) | COLOR_WHITE);
+ console_setcolor((COLOR_BLACK << 4) | COLOR_WHITE,
+ (COLOR_WHITE << 4) | COLOR_BLACK);
/* Initialize the kill buffer. */
*kill_buf = 0;
Index: main/grub/char_io.c
===
--- main/grub/char_io.c (revision 73)
+++ main/grub/char_io.c (working copy)
@@ -746,8 +746,8 @@
void console_setcolor(int normal_color, int highlight_color)
{
- init_pair(1,(normal_color >> 4) &0xf, normal_color & 0xf);
- init_pair(2,(highlight_color >> 4) &0xf, highlight_color & 0xf);
+ init_pair(1, normal_color & 0xf, (normal_color >> 4) & 0xf);
+ init_pair(2, highlight_color & 0xf, (highlight_color >> 4) & 0xf);
/* Make curses update the whole screen */
redrawwin(stdscr);
Index: main/grub/builtins.c
===
--- main/grub/builtins.c (revision 73)
+++ main/grub/builtins.c (working copy)
@@ -166,7 +166,7 @@
auto int color_number(char *str);
- /* Convert the color name STR into the magical number. */
+ /* Convert the color name STR into a VGA color number. */
auto int color_number(char *str) {
char *ptr;
int i;
@@ -188,10 +188,10 @@
str += 6;
}
- /* Search for the color name. */
+ /* Search for the foreground color name. */
for (i = 0; i < 16; i++)
if (strcmp(color_list[i], str) == 0) {
-color |= (i << 4);
+color |= i;
break;
}
@@ -201,10 +201,10 @@
str = ptr;
nul_terminate(str);
- /* Search for the color name. */
+ /* Search for the background color name. */
for (i = 0; i < 8; i++)
if (strcmp(color_list[i], str) == 0) {
-color |= i;
+color |= (i <<4);
break;
}
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] osmarender: islands?
Now that islands are rendering for me with or/p (that is, now that they're tagged properly) I note that they're a different colour from the normal land. Is that expected? -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway = path in mapnik/osmarander
Christoph Eckert wrote: > nothing. But there are paths like hiking paths which have been tagged as > footways in the past. IMO that's wrong. For me, a footway has to be paved. A > path most often isn't. I don't think path or footway say anything about the surface of the route. Just the size and what's allowed to use it. You might want to use the surface=* tag for that. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway = path in mapnik/osmarander
Gregory wrote: > What's wrong with highway=footway ? > Or highway=cycleway if it is mainly for cyclists. because not all such paths are for foot or bicycle, and highway=footway+foot=no is not a good way to do it. (same for highway=cycleway+bicycle=no) And calling something a footway implicitly puts foot above the other uses, even though this may not be the case in reality. The "designated" access value helps with this though. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Nick Whitelegg wrote: >> This is the sort of map I envision: >> http://www.uwsp.edu/cnr/Schmeeckle/Map/images/schmeeckle_map.jpg > > As an aside, I like the style of that map for doing walking routes (e.g. > on Freemap) Wonder how easy it would be to generate using GD / PDF > libraries etc? That I don't know, but if you're curious, here's the same area in my slightly customized mapnik render (modified to understand foot/bicycle/horse=designated, and to render paths on top of roads, and with a catchall rule for any paths which have no designation.) http://web.hawkesnest.net/osm.html?lat=44.53762&lon=-89.56218&zoom=16&layers=B and in osmarender: http://www.informationfreeway.org/?lat=44.53753819714547&lon=-89.56241392105782&zoom=16&layers=B000F000F I tried using generate_image.py to create an image of the same area, but it just showed up blank grey... -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Dave Stubbs wrote: > If the point is to show all possible paths, then you'll also want to > similarly show all the roads as well? In which case an else rule on > highway=* would solve the problem. The point is to show all possible paths and highlight one particular subset of them, yeah. This is the sort of map I envision: http://www.uwsp.edu/cnr/Schmeeckle/Map/images/schmeeckle_map.jpg Note that it is useful to differentiate roads from paths on that sort of map, so a catchall on highway=* wouldn't be sufficient. And before someone says it, I'm not trying to duplicate that map in OSM. > So the only distinction created by highway=path is that it is of type > "path" which is a sufficiently broad spectrum of features from tiny It's not there to distinguish one kind of path from another, it's there to distinguish a path from something which isn't a path, such as a road. > Does anyone know why they might have done this? A preset somewhere > maybe? (anonymous user so I can't ask them). Looks like the JOSM paths preset to me. If someone used that to change it to a path and thought they had to fill in all the access restrictions, that would likely be the result. "no" is probably correct, since it means "not permitted or unsuitable" -- if it gets so little snow, it's probably unsuitable for skiing. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Andy Allan wrote: > What an absolutely terrible idea. This is astounding daft. If I have Yes, I am clearly mad. I appreciate that. > chosen to render paths for cyclists, horse riders and pedestrians on > my map, why on earth would I want to accidentally render every other > variant when someone adds it? If I wanted to render every possible > future linear feature without knowing what it was I would use an > elsefilter on planet_osm_line and be done with it. Huh? There's a difference between "any future linear feature" and "any sort of path". Say you've got a place with a variety of paths: bike trails, walking trails, ski trails. Now say that you want to make a map useful for biking that area, but you still want to show the other paths. (so that turning at the "second left" is still accurate) So you render the bike paths in a green broken line. Now, does it make more sense to have single rule for all the other kinds of path that you don't care about to render as a grey broken line, or does it make more sense to have separate extra rules to render footway, bridleway, and four kinds of skiway all in that way? And then someone maps the snowmobile trail that also goes through the area. Is it better that it's now rendered like all the other special-use paths that you don't wish to highlight, or is it better to have to add another rule for snowmobileways? > There's good reasons why every new feature gets a new tag - it's so > that you don't end up accidentally rendering things in a confusing > manner. There's very little to be gained from lumping lots of things > that you'd never want to render identically - no sane map would render > cycle paths, footpaths and snowmobile-only trails identically. So what Incorrect. See above. If one is making a ski or a horse map, why should one care whether some other paths are for foot, bicycle, or snowmobile? But one would still want to render them just to show that they're there. > you're suggesting actually *raises* the bar for renderers since it's > now twice as hard to render just footpaths. Not really. If it's highway=footway or foot=designated, render it as a footpath. Hey, that's how it already should work. Convenient! >> 1. highway=[anything]way. Renderers need to know about every type of >> [thing]way. Impossible to tag a multiple-use way (or ridiculously >> complex anyway -- highway=bicyclefoothorseskisnowmobileway? > > I'm not going to waste time discussing with someone who can't refrain > from adding strawman arguments to everything he discusses. That's no strawman. See http://wiki.openstreetmap.org/index.php/Proposed_features/Cycle_and_Footway So much for: > the obligation to > research alternative options (rather than just campaigning for one) > surely lies with the proposers. Just by mentioning one of those alternative options, you immediately ignore anything else I have to say. Did you even read the rest of the message? The other two options I considered were much better, and I stated straight away that that one is terrible. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Andy Allan wrote: > highway=footway + foot=no is simply garbage, I agree. > People in charge of renderers being asked why highway=path, > cycleway=designated doesn't show up when highway=cycleway does, when > they could spend time on more useful things which add value to the > maps. The renderers need to accommodate this sort of thing anyway, because of multi-use paths like http://wiki.openstreetmap.org/index.php/Image:Designatedsigns.jpeg -- even if that were to be tagged as footway/cycleway/bridleway renderers would still need to understand the bicycle=*, horse=*, ski=*, snowmobile=*, foot=* tags in order to render the other access methods. In fact, highway=path makes it easier on renderers. Without using highway=path, renderers need to understand every single specialized way. snowmobileway, skiway, nordicskiway, telemarkskiway, alpineskiway, elephantway, etc. When someone introduces a new specialized way, the renderers need to be updated to understand it. *With* highway=path, the renderers only need to understand highway=path. Most renderers can render all paths generically. If a new access method is added, no change is needed. Specialized maps like cyclemap only need to add special rendering for their area of interest. For example, a cycle map can render any highway=path the same, and only highlight those which are for bicycles. > I'm not obliged to spend my time patiently explaining the > counterarguments to every proposal on the wiki - the obligation to > research alternative options (rather than just campaigning for one) > surely lies with the proposers. I did consider several alternatives, and I wouldn't have proposed one if I'd found that another was clearly superior. I'll go over the ones I considered, and their problems and benefits: 1. highway=[anything]way. Renderers need to know about every type of [thing]way. Impossible to tag a multiple-use way (or ridiculously complex anyway -- highway=bicyclefoothorseskisnowmobileway? I hope everyone uses those in the same order.). No good way to tag a "generic" path where the intended/primary use is unknown or unclear. Requires a change to the renderer for every new type of way and a new value for every permutation of access methods. 2. highway=[anything]way plus access tags. This makes it possible to tag the multi-use way, but prioritizes one access mode over the others. Renderers still need to know about every [thing]way. Renderers which don't understand the access tags are likely to render incorrectly. Still no good way to tag a generic path. Still requires a change to the renderer for every new type of way, but no new value for every permutation. 3. highway=path + access tags + existing footway/cycleway/bridleway. No changes required to existing data. Easy to render without knowing about every variation (only four are needed). Easy to tag a single-use way. Easy to tag a multi-use way, and doesn't prioritize one use of the way. Easy to tag a generic path. Renderers which don't understand the access tags can still identify all paths and render with a generic style. Only specialized renderers need to care about the access tags. Requires a one-time change to the renderers to understand highway=path. Clearly the first is a terrible idea. You seem to prefer the second method. It is definitely better than the first. I don't know if you weren't aware of its flaws, or just don't think they're important enough -- or if you have some preferred fourth alternative which I didn't consider and you've never mentioned. I don't see any flaws in the third, and 22 others didn't either, or at least approved it without mentioning them. There were some objections which you can find on the proposal page. In my opinion they're outweighed by the benefits above. Perhaps there's a fourth method which is far superior to the other three. I didn't encounter it though. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Dave Stubbs wrote: > The highway tags are a mishmash of different concepts and properties > of different kinds. There's physical, legal, and intended use jammed > in there in different parts. If you're looking for proper separation Ehh, the stated intent is "a very general and sometimes vague description of the physical structure of the highway." I agree that this is not entirely what it's used for, but I think moving towards that, or at least not moving away, is a good idea. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Stephen Gower wrote: > On Tue, Aug 05, 2008 at 06:33:10PM -0500, Alex Mauer wrote: >> So it really depends on interpretation. In particular, footways have a >> particular legal status in the UK which doesn't apply to every place >> that you can walk. > > call a pavement and you might call a sidewalk. The "particular legal > status" to which you refer is actually applied to the legal term "footpath", You're right, I should have written footpath. My point still stands though. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Andy Allan wrote: > highway tag with more than 100 instances. You can see that the > highway=footway/cycleway/bridleway/pedestrian totals 509,920 instances > (path has a respectible, but tiny by comparision, 2165). And everyone Meh, bridleway/cycleway/footway have been around for at least 2 years, path's been around for what, a few months? Pedestrian's not in the same class at all though, so make that 425756. Not that it reduces your point much. > of renders, routing algorthims and whatnot understand and use them > too. Routing algorithms need to understand the access tags anyway, so no real change there. Renderers should as well (without bringing path into it, it's good to show highway=cycleway+foot=yes on a specialized foot map.) > So what are the advantages of the change? One scheme that covers the > corner cases along with the most common occurences. And the > disadvantages? Confusion for many contributors, every data user > needing to understand two sets of tagging styles, the most common What are these two sets of tagging styles? I only see one new value, not a whole new style. > cases (the 509k) needing twice as many tags as before, and the corner > cases are still fairly corner needing a small handful of tags. So in Incorrect. You neglected to account for the existing tags on those 509k/425k. There's actually a net gain (reduction) in the number of tags needed. The simplest cases (cycleway/footway/bridleway) are identical, obviously. But now a specialty route which is not a c/f/b is both more intuitive (no highway=footway+foot=no needed) and requires fewer tags (highway=path + snowmobile=designated instead of highway=footway + foot=no + snowmobile=designated for example). At worst, there is only one additional tag needed, not "twice as many", and that's only if you choose to use highway=path for something which is also a c/f/b. And of course, non-designated paths (2nd-4th, 6th and 9th on http://wiki.openstreetmap.org/index.php/Tag:highway%3Dpath/Examples for example) are now only one tag instead of two, as well as being much more intuitive. > proposed upheaval and/or dual tagging regimes is overkill. A way to > tag the corner cases that don't fit in well would have been much > preferable. Upheaval? Dual-tagging regime? Neither have happened here: c/f/b are still perfectly viable, and highway=path simply adds a generic path alongside the existing specific-use paths. And IMO if someone knew of a less disruptive, more intuitive change to make, they should have mentioned it during the 6 months that the proposal was in the wiki. Not that I think anything could describe a non-specific-use path in a less disruptive way than highway=path. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Dave Stubbs wrote: > Gotcha. Excepth that, assuming you /can/ walk on it, that's what the > rest of us have been using highway=footway for since the dawn of time > (well, dawn of map features maybe. well, last couple of years at > least). > > If it happened to have another purpose (ie: bikes or horses) then it > got upgraded to cycleway or bridleway. > > If that's not what you thought highway=footway meant then I guess the > docs for highway=footway need updating (again). >From Tag:highway=footway: "For designated footpaths, i.e. mainly/exclusively for pedestrians." That is a perfectly reasonable definition in my opinion. However, I see a distinction among "intended for", "allowed", and "not forbidden". So it really depends on interpretation. In particular, footways have a particular legal status in the UK which doesn't apply to every place that you can walk. And even in the US there's a difference between "a path" and "a path built specifically for people to walk on". > So that means 2 to 9 are fully covered by the existing map features > (ie: footway/cycleway/bridleway/track/service) 2-4: clearly not mainly/exclusively for pedestrians, since it's not for anything in particular. It's just a path; certainly no cycleway or bridleway, even though bicycles and horses don't appear to be forbidden. 5: it's a cycleway and a footway. Calling it only one of those gives a priority which doesn't exist. That problem is fixed with the "designated" value for access. 6: the purpose of the path is impossible to determine. All we can see is what is forbidden. We can perhaps hope that horses and bicycles are allowed to use it, I guess. It's still not a bridleway. 7,8: covered by f/c/b 9: again, we can't tell what it's for, just what's forbidden. Definitely not a bridleway since horses are forbidden. Not a cycleway either though, since it's not /for/ bicycles. Aside: I don't think track/service matter at all for this purpose. > Nonsensical is a matter of opinion clearly. > You can't just say things are nonsensical and hope that means > something. It happens to make perfect sense. You might not like it, > and there might be a better way, but that's not really the same thing. OK, perhaps "nonsensical" was too strong. "Against the intent of the highway tag" certainly, and I'd add "defeating the purpose of the access series of tags" as well. I hope you agree with my point that the legal accessibility of a way doesn't belong in the highway key, especially when we have a separate key for it. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Jon Burgess wrote: > The only thing I see an issue with is introducing the specific > 'highway=path' tag. I see this as an unnecessary complication. I guess it's a matter of perspective. I see it as a simplification: instead of having three categories for one physical feature (and still needing to twist reality in order to fit them in (highway=footway+foot=no+ski=yes, anyone?) you have only one category. >>From a quick glance at the examples given I think they are all covered > with combinations of highway=cycleway|footway|track with the other tags Except the first, second, third, fourth, fifth, sixth, ninth, and tenth. Yeah. > you propose like foot=y/n, motorcar=y/n or tracktype=gradeN etc. I propose none of those tags. the first two are part of the initial revision of access=*, and the last I do not propose nor agree with. > I > really don't see what highway=path adds. To quote the wiki page: "A generic path. Either not intended for any particular use, or intended for several different uses." For the nth time, bridleway/cycleway/footway do not cover these. You can look at the list of path examples referred to above to see ones which are not covered. The only one of them which might be is the fifth, and that one is simply not /adequately/ covered. > The one exception is for > snowmobile, for that I'd suggest possibly adding highway=snowmobile > instead. And three kinds of ski and motorcycle. And I'm sure there's some modes of transport that we're missing. Adding them all as highway values is nonsensical. (highway=elephantway?) -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Igor Brejc wrote:
> Which tag value would I use for a path through the forest that is
> clearly visible, but with no markings? There are a lot of those in Slovenia.
It's probably not necessary to tag it specially at all as I expect this
is the default, but it looks like trail_visibility=excellent
("Unambiguous path or markers everywhere") would be the one to use.
-Alex Mauer "hawke"
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Frederik Ramm wrote: > I've never been a friend of that voting business but it seems to get > more absurd every day. Is it perhaps time now to have a vote on > abolishing votes altogehter - or should we continue to let people vote > on whatever they like and ignore the results? Do you have a better suggestion? I like Andy Allan's modifications to the Key:crossing page, suggesting that it be used for documenting current usage, with renderers working from that. So all you have to do to add a key or value is to use it. It's unfortunate that current usage is so hard to find, particularly outside of Europe... -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Tom Hughes wrote: > It was "approved" on the basis of a tiny vote on the wiki and I would Uh, what? 34 votes is one of the largest votes of any proposed/approved feature on the wiki. > say there is zero chance of most people switching from the tags that > have been in use for several years to some new scheme that, as I > understand it, requires about five tags for each path. Then I think you misunderstand it. Take a look at http://wiki.openstreetmap.org/index.php/Tag:highway%3Dpath/Examples -- most require two tags at most. The only one which reaches five additional tags is the last one. Which doesn't fit into the bridleway/cycleway/footway paradigm anyway, and is one of the most complex examples to be found. You don't like highway=path, fine. If your tagging needs are met by bridleway/cycleway/footway, then I'm glad for you. But it's not adequate for all situations. Don't make up bullshit just to trash-talk that which you don't understand. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tagging trailblazes / marked paths
Brejc wrote: > Hello, > > Now that the highway=path has been moved to the "official" features > page, is there any more or less agreed way of tagging marked paths? I > see a lot of different proposal pages on this, but no real consensus. I > myself have been tagging my local area using trailblazed=yes, but it > would be nice to use some generally agreed tag. Take a look at http://wiki.openstreetmap.org/index.php/Key:trail_visibility Combined with highway=path, does that cover what you need to map? -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] path or byway ?
Frederik Ramm wrote: >> For one, byway was never proposed or described or otherwise documented, >> but instead just plopped into map features. > > Just like them darn motorways... nobody ever put them to vote, it's > a shame ;-) Except that motorways were there on the very first rev (ok, second) of Map Features. And they're documented. And conceptually they're not UK-specific. My gripe is that it was put in there with neither discussion nor description; I never mentioned anything about voting. > There are probably a few more millions who know what a byway is. > In contrast to the generic term "path", a byway is something very > specific in the UK because it has a legal meaning. You are aware that the OSM definitions of things and the UK legal definitions of things are not always the same, right? -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] path or byway ?
Pieren wrote: > Dear talk, > > Could some native english speaker explain the difference between > "highway=path" and "highway=byway" recently introduced in map features ? For one, byway was never proposed or described or otherwise documented, but instead just plopped into map features. So I guess no one really knows except Richard B, who put it there. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Fire break advice
Iván Sánchez Ortega wrote: > El Miércoles, 16 de Julio de 2008, David Janda escribió: >> I cannot find any suitable tabs, and here in Northern Cyprus the fire >> breaks are strips of land with all growth removed. > > I'd just tag a highway=footway, and break up any landuse=forest areas. Are they definitely usable as footways? -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tag:highway=cycleway inconsistency
Andy Allan wrote: > The point that I get concerned about is if it's A 55% of the time and > B 45% of the time and someone says that A should be default. I still see it as an overall advantage if only 45% of ways must have that additional tag, vs. 100%. It's unfortunate that rather than requiring all of the users to place an extra tag 45% of the time, it actually shifts the burden so that a regional 45% of the users must use the extra tag approximately 98% of the time. If it were even across all users it would be much more acceptable. But I still think that it's better than requiring 100% of users to add an extra tag 100% of the time. I like the idea of having country-specific implications/assumptions, but I don't really see a good way to document that. Any suggestions? -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tag:highway=cycleway inconsistency
William Waites wrote: > Possibly it is better to remove implication relationships amongst tags. I doubt it. I think it is safe for highway=cycleway to imply bicycle=yes and motorcar=no, and for highway=motorway to imply foot=no, horse=no and bicycle=no. These are "obviously correct" assumptions, as they are part of the definition of the cycleway, or the motorway. So I think some implications are quite important, as they indicate some tags which it is unnecessary to apply. (I certainly don't feel like tagging oneway=no on most everything, for example). > Cycling is one thing, appropriateness of feet is another, no? There are basically 3 options: Imply foot=yes (and several equivalents) Imply foot=no No implication I feel that leaving it with no implication is a bad idea, because someone wishing to rely on the OSM data for a routing app will need to have a default for it anyway, either to route foot traffic along a cycleway, or not. So OSM might as well indicate which should be assumed. Of course, it would be possible to put an additional foot=* tag on every cycleway, but I think it's better to do this in only half (or less) of the cases, than to have to do it everywhere. That leaves us with yes or no. For the (OSM) definition of a highway=cycleway, it says "mainly or exclusively for bicycles" -- foot=yes would apply to those which are "mainly" for bicycles, while foot=no would apply to those which are "exclusively" for bicycles. The best assumption is the one which applies in the largest number of cases. I think that would be foot=yes. I know Andy disagrees with this, and I can see his point about foot=yes being wrong for some countries -- but I think it's better to have a default so it's easier to make assumptions about routing, than to require that all cycleways be tagged with an additional foot=* tag. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] Current access rules
Dave Stubbs wrote: > Hmm... "with no legal restrictions" is the problem here. It doesn't > say that, and certainly isn't how I've ever thought of it. > It doesn't say anywhere in access tags that they have any bearing on > onewayness at all. As far as I can tell oneway and access are > completely unrelated tags. They are described on the same page, so there's at least some relationship. See http://wiki.openstreetmap.org/index.php/Key:access#Routing_restrictions -- I totally agree with your interpretation though. -Alex Mauer "hawke" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] US county import
Frederik Ramm wrote: > I haven't a clue. I don't know how important county borders are and > whether it would be possible to find a more reliable source for them. I would say the borders in TIGER are probably fairly accurate. In this particular case, it's even possible that that oval of land is outside the county for some reason. > Problem I'm seeing is that it might be difficult for mappers to correct > these borders because they are not visible on the ground (or are there > signposts along a road saying "you are leaving county X/welcome to > county Y"?). There often (usually?) are signposts. Where there aren't, you can sometimes tell where the border is anyway because there's a change in the paving of the road, either to a different composition, different age, different surface entirely, maybe even an unpaved gap in the road in some cases. It helps to know approximately where the county border is beforehand, of course. Counties generally have straight borders too, except when they follow some natural feature such as a river (which is pretty easy to see). -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Rendering of tracktype
Marc Schütz wrote: >> An alternative is to use highway=service, surface=paved since they >> are access roads within a property(?) just the same as universities, >> hospitals and industry. > > No, they are usually public ways, not within a property. I don't think that's necessarily true, and has no bearing on whether it's marked as service. A service road is a service road, regardless of whether it's public or private. From the wiki, Key:highway page: "It is a very general and sometimes vague description of the physical structure of the highway." -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Rendering of tracktype
Sven Geggus wrote: > We have a whole lot of them here in germany and they are usually > paved or asphaltic ways, and they are different from unclassified, because > they are usually narrow and have access for tractors and bykes only. > > They are simular to a highway=service, which I tended to use before somebody > told me that tracktype=grade1 is track with paved surface. I would expect them to be highway=service. Do you have a picture of one? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
Vincent Zweije wrote: > You can only do this in very rare circumstances, otherwise the > errors-to-be-ignored drown out the errors you need to see and fix. An > unnamed street is not such a rare circumstance, IMO. I don't think that's true. There really aren't that many, in my experience. At least roads larger than "service" -- unnamed service roads are very common. So much so that they shouldn't be in warnings at all. Do you have an example of a place with many unnamed roads? -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
Andy Allan wrote: > The issue is the partially-done, somewhat scrappy areas, like > http://dev.openstreetmap.org/~random/no-names/?zoom=15&lat=6718359.62403&lon=859.10713&layers=B000 > > I don't know whether Dave or Shaun or Harry or anyone else has gone > and checked these roads. And there's no point in me checking them, > finding that they don't have a name, and also finding on Wednesday in > the pub that all three of them have also checked these roads in the > last few weeks. That would be a waste of time, and its this > double-over-checking that Dave and SteveC are trying to avoid. That (or the corrected link in the followup) is a better example than Shaun's, but surely more of a coordination problem than a tagging problem. Adding a tag (be it reviewed=no, unnamed=yes, or anything else) cannot solve it, and is simply tagging to remove warnings from the validator. Both examples seem to be "Look at all the streets that show up in the validator: there might be one or two in there that are truly unnamed!". And the solution there is not to mark the ones that are truly unnamed, it's to go and find out the names of the ones that are named. Once that's done, you can probably assume that the one or two roads that still don't have a name are truly unnamed. And if occasionally someone just passing through anyway double checks the roads because they're on the validator, it's no big deal. I could be mistaken there. If all the roads in that link are truly unnamed, then I could see where the validator could mislead someone by suggesting that there's a need to actually go there to fix up the largish cluster of missing road names in the area. And if so, there's probably a need to clean up the validator. But I don't believe that to be the case. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
Dave Stubbs wrote: > Mostly because this is the property that we're most interested in at > the moment. Reviewed feels to me too open ended. It is a bit, but I think it's great for this sort of localized, map party sort of thing. You put the tags on in the area you're about to do and take them off when you're done. Any unreviewed roads remaining in the area you (or the mapping party) is working on, you know still need to be done. > A little like the > concept of completeness. We can't really (easily) mark in the > unreviewed areas because so many have already been added without it, > but we can tell they don't have a name so then we just want to > quickly deal with the false positives that throws up. I think you can fairly easily add a "reviewed=no" tag to all unnamed roads in an area (using JOSM). Then once you've gone through and reviewed them, any unnamed road in that area without a reviewed=no tag can be assumed to be a truly unnamed street (false positive in the no-names map). This does make a couple of assumptions: *The mapping of the area is fairly complete, so you don't have someone adding a bunch more unnamed roads later on. *You're not going to go out of your way into this area again any time soon to check on the very few unnamed roads that are still there. This is fairly likely, since the area in question hasn't been mapped by hand yet (i.e. there is no mapper local to the area) -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
Richard Fairhurst wrote:
> Oh sure, I'm not going to dispute that (things like "work" get in the
> way there too). But to say it's "not conscientious" isn't right.
It may have been a poor choice of words (British/American usage
difference maybe?). I meant that someone leaving off the names is being
less thorough than is possible, not that they are wrong in so doing. In
retrospect, "meticulous" ("marked by extreme or excessive care in the
consideration or treatment of details") would have been a better choice.
> Ultimately many mappers make all completeness issues shallow anyway. ;)
Absolutely, and fortunately for us.
-Alex Mauer "hawke"
signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
SteveC wrote: > Why do you think Richard 'has' to revisit it? He personally doesn't, but if a road has a name, and that name is to be in the database, someone has to go there and find out what it is. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [tagging] noname streets
Dave Stubbs wrote: > We have literally thousands of miles of unnamed roads in London... and > the vast, vast majority of these /should/ have names. And I'm going to > go try and fix them, and would like to know when not to bother. When it's a single road or far out of the way of where you're mapping, would be my suggestion. It's probably fine to go a few blocks out of the way to check out one unnamed road, and probably fine to go few mile or two out of the way to check a whole neighborhood of unnamed roads. I for one will not be going 100 miles out of the way to check an unnamed road (or indeed to map at all). It's a judgment call, so your mileage may vary. No pun intended. > This is one of those cases where we have actually identified a problem > and are figuring out how to fix it, rather than just inventing crap > for the sake of it. Good! Karl suggested using the "reviewed" tag, and I agree with that. Mark all unnamed roads in the area you're mapping with "reviewed=no", and then once you've reviewed them, delete the tag. I just don't see a need to mark out that the name specifically has been reviewed. -Alex Mauer "hawke" signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
