Re: [Tagging] [OSM-dev] Super-relations or not
On Tue, 2 Nov 2010 01:02:37 +0800, Eugene Alvin Villar sea...@gmail.com wrote: On Tue, Nov 2, 2010 at 12:25 AM, Peter Budny pet...@gatech.edu wrote: As far as I'm concerned, the difference in what's required to tag things is minimal between these concerns. Therefore, wouldn't it make the most sense to choose whichever is programmatically the easiest and most flexible to deal with? It depends on what the you want to use route relations for. It's quite possible that different uses would demand different ways of structuring the route relation(s). I would sey they should be set up that is best for mappers to deal with. Software can be made to deal with any scheme as long as there is a consistent scheme. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is highway=service, service=drive_thru a good idea?
Eugene Alvin Villar sea...@gmail.com writes: On Mon, Apr 12, 2010 at 1:10 AM, Pieren pier...@gmail.com wrote: On Sun, Apr 11, 2010 at 5:56 PM, Anthony o...@inbox.org wrote: I have indeed tagged a couple of these, using highway=service, service=drive-through, access=private, oneway=yes. highway=service + oneway=yes + access=destination Pieren An explicit tag would be better since routers can then let the user filter for fast food restaurants that have drive-throughs and then route them to the selected drive-through entrance appropriately. Whether or not a restaurant (or pharmacy, or bank, or whatever) has a drive-through should be a property of the restaurant and not of the street, IMO. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is highway=service, service=drive_thru a good idea?
John Smith deltafoxtrot...@gmail.com writes: On 12 April 2010 02:33, Anthony o...@inbox.org wrote: Now, if we really want to start a flame war, maybe I should ask whether or not to include bicycle=no :). While your comment is tongue in cheek, most drive throughs have height/width restrictions and usually don't allow towed vehicles to be taken through either, not sure if anyone has come up with suitable tagging for this. maxheight + maxwidth and maybe a new trailer=no? Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is highway=service, service=drive_thru a good idea?
John Smith deltafoxtrot...@gmail.com writes: On 13 April 2010 06:02, Matthias Julius li...@julius-net.net wrote: maxheight + maxwidth and maybe a new trailer=no? I was hesitant to use the word 'trailer' since it means different things in different variations of English, and it's not the only thing that could be towed, things like caravans also have multiple meanings differently versions of English. And so have other tags in OSM. And there are tags that only have a meaning to someone from UK (or other places). It is just a matter of a proper definition. What is the BE equivalent for a trailer? Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Is highway=service, service=drive_thru a good idea?
Ulf Lamping ulf.lamp...@googlemail.com writes: Am 12.04.2010 19:54, schrieb Anthony: Well, I now see that there are a few. I still don't understand why, though, and I don't think we should keep doing something which makes no sense just because we've done it in the past. It's not (only) because we've done it in the past, it's just a lot easier to type because you don't have to remember if it was a space, a hyphen or an underscore - you can simply type an underscore and you're done. And this is precisely because we've done it in the past. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag proposal image=http:/... .jpg
Ulf Lamping ulf.lamp...@googlemail.com writes: Am 05.02.2010 12:26, schrieb Tobias Knerr: My opinion is that personal preferences like that shouldn't be part of the OSM database. No my favourite Sunday walk route relations, no subjective food=extremely_tasty for restaurants, and no my favourite image of the object either. There's a big difference between the subjective my favourite walk and the objective this is a picture of the object. This is true. But, I agree that it would be better if there was a separate database (table) linking images or other data to OSM objects. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Offices/non-shop businesses
Emilie Laffray emilie.laff...@gmail.com writes: 2010/1/27 Liz ed...@billiau.net I've started office= tags and have put in something simple for what I have found office=accountant office=solicitor office=secretarial services office=insurance I do find that some period of experimental tagging helps me sort out what categories are going to be useful. I'm not capable of putting together a fully-fledged proposal for every sort of office I'm likely to find from the start. What you have done looks good. I think it makes sense. Would you tag a business facility that is not really an office like a machine shop or other production facility as office=* as well? Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dutch cafes
Martin Koppenhoefer dieterdre...@gmail.com writes: 2010/1/20 Peter Childs pchi...@bcs.org In my book its easy. Cafe Usually Unlicensed. Definitely I would not put licenses and other legal stuff into the definition. They differ almost certainly in different countries, are of no importance to the client and hard to research. They might even differ from one city / state to another. The primary point is actually not about the license but whether or not they serve alcohol. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dutch cafes
Roy Wallace waldo000...@gmail.com writes: On Thu, Jan 21, 2010 at 9:17 AM, Erik Johansson erjo...@gmail.com wrote: ... To meet both problems you can only do this: alcohol=yes coffee=no pastries=yes egg chips=yes I like this approach. I don't. I don't want to revisit each place each week to see whether the menu has changed. It makes much more sense than either of the other suggestions, i.e.: 1) inventing complex explicit definitions of what a cafe is, internationally or 2) assuming complex (implicit) definitions of what a cafe is, and having this differ from place to place Well, that's the way it is. The definitions have to be general enough so that they can be finetuned to match local circumstances. It would be foolish to assume that a café in Hongkong looks exactly the same as in Vienna. Also, if you only tag the menu instead of categorizing the place you only put the burden on the consumer of the data. Otherwise you get 10 icons on the map for each café (coffee, pastries, eggchips, ...). Or, you have to ask your router to guide you to a place where they have beefsteak, beer and rum if you feel like that. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What's a power=station?
Anthony o...@inbox.org writes: On Mon, Jan 18, 2010 at 8:50 AM, Dave F. dave...@madasafish.com wrote: To me power is energy. It's not a physical entity. That's just silly. Energy is a physical entity. Well, I guess he meant physical in the sense of a physical object - something you can touch, see and has a volume and mass. Anyway, I would interpret power as a shorthand for electrical power related facility. While it might not be the most perfect tag (is there such a thing?) it certainly works and should not be changed unless there is a really, really good reason. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What's a power=station?
John Smith deltafoxtrot...@gmail.com writes: 2010/1/19 Matthias Julius li...@julius-net.net: Well, I guess he meant physical in the sense of a physical object - something you can touch, see and has a volume and mass. Ummm... electrons have mass... But electrons are not power. If you want to have electrons from a power plant you have to give them the same amount back. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using relations to group highways
John Smith deltafoxtrot...@gmail.com writes: 2010/1/7 Matthias Julius li...@julius-net.net: John Smith deltafoxtrot...@gmail.com writes: Well relations aren't ways, the ways go through/under/ buildings. Do they? Did I miss something? Last I know is that they are rendered on top of buildings even if they are on a lower layer. How is that rendering bug related to using relations to group ways? From a previous post of yours: , | As for the shields this is deviating from the topic at hand but for it | the shield can be derived from the lookup table on the wiki and then | extra preprossesing in osm2pgsql to assign a shield based on admin | polygons + info from the lookup table ` If osm2pgsql can be taught to detect in which admin polygon a way is maybe it can then also notice when a way intersects a building. Or any other area. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using relations to group highways
John Smith deltafoxtrot...@gmail.com writes: As for the shields this is deviating from the topic at hand but for it the shield can be derived from the lookup table on the wiki and then extra preprossesing in osm2pgsql to assign a shield based on admin polygons + info from the lookup table Does osm2pgsql have that capability already? Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using relations to group highways
Mike N. nice...@att.net writes: As for the shields this is deviating from the topic at hand but for it the shield can be derived from the lookup table on the wiki and then extra preprossesing in osm2pgsql to assign a shield based on admin polygons + info from the lookup table What is the advantage in separating the shields from their associated features in the DB? The mapper does not need to worry about them if the renderers just do the right thing. The shields are not really a property of the highway. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using relations to group highways
John Smith deltafoxtrot...@gmail.com writes: Well relations aren't ways, the ways go through/under/ buildings. Do they? Did I miss something? Last I know is that they are rendered on top of buildings even if they are on a lower layer. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using relations to group highways
Alex Mauer ha...@hawkesnest.net writes: On 01/05/2010 01:32 PM, John Smith wrote: Currently there is discussion on using relations to group segments of a highway occurring: http://trac.openstreetmap.org/ticket/2599 In that ticket, you wrote: “we think administrative polygons should be used for custom highway shields, instead of trying to tell the rendering software explicitly which shield to use” How might this work? Presumably there’s some idea of linking primary/secondary/tertiary each with an administrative level, using that to determine which of the administrative polygons applies to the route in question, and then deciding from there which shield to use. Do I have it right? This could be derived from the ref tag and administrative boundary. A 2 should get a different shield in Germany than in the UK. Same goes for M 5 in Michigan or UK. The road classification is not always linked to highway type. In the US a primary road can be a US or state highway for example and a US highway mey be a primary, trunk or motorway. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Roy Wallace waldo000...@gmail.com writes: On Wed, Dec 30, 2009 at 3:01 AM, Matthias Julius li...@julius-net.net wrote: If you know the actual incline you can tag it with its value. If you have to estimate it anyway then a hard definition on what is steep is not worth that much anymore. It is a subjective classification - not more and not less. One could think it implies a FIXME: check for actual value. I have no problem with using a FIXME. But performing even a subjective classification still requires criteria as to how to make that classification. I.e. it is steep if __. If you want to define steep by saying, on the wiki, incline=*_steep means the mapper personally thought the incline was steep, go ahead - but IMHO that's not a good definition. OK, that certainly makes sense. It still is an estimate. So, what is steep then? 15% or more? What I mean to say is, unless you can think of a better way to tag incline=* on nodes, we should encourage the use of incline=* for this purpose (as opposed to some other tag like inclination=* or steepness=*, or node_incline=* etc., which would just be silly). I would say all the incline tags should be moved to the ways. As Anthony said, this isn't equivalent, unless it's moved to a new way with infinitesimal length. or to a relation that indicates that a way has an incline at a certain node. You could call this overkill, of course, but it has the advantage to be more robust when the data is changed, especially when another way is added to that node. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Roy Wallace waldo000...@gmail.com writes: On Tue, Dec 29, 2009 at 2:09 PM, Matthias Julius li...@julius-net.net wrote: But that's my point - sure, you don't want to lose semantics i.e. meaning. But IMHO steep is *meaningless*. Why? Because it's not well defined. If you want to define steep as meaning greater than or equal to 15% incline, THEN it has meaning. But until then, it's meaningless. If you know the actual incline you can tag it with its value. If you have to estimate it anyway then a hard definition on what is steep is not worth that much anymore. It is a subjective classification - not more and not less. One could think it implies a FIXME: check for actual value. What I mean to say is, unless you can think of a better way to tag incline=* on nodes, we should encourage the use of incline=* for this purpose (as opposed to some other tag like inclination=* or steepness=*, or node_incline=* etc., which would just be silly). I would say all the incline tags should be moved to the ways. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Roy Wallace waldo000...@gmail.com writes: On Tue, Dec 29, 2009 at 10:30 AM, Matthias Julius li...@julius-net.net wrote: I would also add the values 'up_steep' and 'down_steep' to 'incline=*' for this to be a equivalent replacement of the highway tags. -1. This is like having width=wide - this should be discouraged. 'up/down' is in there to be able to tag an incline where the exact value is not known. Adding '_steep' would allow to differentiate a little. Of course, what is steep and what is not is subjective - just like surface quality. I just don't want to loose any semantics compared to the highway=incline tags. I would also like to change 'incline=*' so it does not apply to nodes anymore. But, if there are objections I will hold off on this one. It may be enough to say something like This can be applied to a node only when the node is part of a single way, exclusively (otherwise the direction of incline is ambiguous). This might be good enough for the one applying the tag. But when the next person is connecting a cross way he is unlikely to check whether the node has an incline tag. Editors might help here (like JOSM does by default) by putting an icon on the node or so. Validators could warn about ambiguous incline tags, though. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Roy Wallace waldo000...@gmail.com writes: On Tue, Dec 29, 2009 at 11:47 AM, Matthias Julius li...@julius-net.net wrote: 'up/down' is in there to be able to tag an incline where the exact value is not known. Adding '_steep' would allow to differentiate a little. Of course, what is steep and what is not is subjective - just like surface quality. I just don't want to loose any semantics compared to the highway=incline tags. But that's my point - sure, you don't want to lose semantics i.e. meaning. But IMHO steep is *meaningless*. Why? It is at least as meaningful as 'smoothness=good|bad|horrible'. Validators could warn about ambiguous incline tags, though. Yup I think this is the best solution. Unless, of course, nobody *wants* to tag incline=* on nodes :) But assuming they do, they should be able to. Of course, everyone can tag what he wants anyway. The question is what we want to encourage. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Steve Bennett stevag...@gmail.com writes: On Tue, Dec 29, 2009 at 3:09 PM, Matthias Julius li...@julius-net.netwrote: Of course, everyone can tag what he wants anyway. The question is what we want to encourage. This is like saying Anyone can drive at whatever speed he wants, the question is what we want to encourage. - ie, true, but fairly meaningless. I think we'd all be better off with a clearly defined set of standard tags with definitions of where they're appropriate, what they mean, etc. Well, that's a different battle. Map Features and friends try to be just that. Of course, there are shortcomings and improvements are welcome, but the mantra in OSM is something like You can tag however you want, but, please consider the tags described in Map Features. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag highway that goes through/under a building
John Smith deltafoxtrot...@gmail.com writes: 2009/12/27 Roy Wallace waldo000...@gmail.com: therefore there must be some tag I have missed)? Are there really no ways already mapped (and rendered correctly) that pass through a building? Undercover service=parking_aisle's, for example? No? Probably not, at least not buildings, since most of the time it's difficult/impossible to do accuracy mapping under cover, so most people probably just draw the buildings and skip the highway=service ways... One example where this would not be a good idea is Park Avenue in New York which splits around Grand Central Station and then goes through the center of the building behind the station. The rendering of this is not only a matter of z-ordering since we probably don't want those roads to be simply covered up by the building. Instead they should be rendered similar to roads in tunnels. Without a special tag it is hard to define render rules for a road that is covered by a building. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Should 'highway=incline[_steep]' be discouraged?
The tags 'highway=incline' and 'highway=incline_steep' only apply to nodes. Therefore, they are prone to become ambiguous when more than one way use that node. Also, they don't have a reversed counterpart and when the way is reversed there is a problem. IMO, inclines should always apply to ways only and there is already a tag for that: 'incline=*'. This also applies to nodes currently and I would discourage this practice as well. Only a few nodes exist with this tag anyway. 'incline=*' can have the values 'up/down' for cases when the exact value is unknown. It does not currently have an equivalent for 'highway=incline_steep'. We can extend 'incline=*' to also allow 'up_steep/down_steep' as values. I propose to change Map Features and the tag pages in this respect if there are no major objections. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag highway that goes through/under a building
Roy Wallace waldo000...@gmail.com writes: On Mon, Dec 28, 2009 at 2:17 AM, Matthias Julius li...@julius-net.net wrote: The rendering of this is not only a matter of z-ordering since we probably don't want those roads to be simply covered up by the building. Instead they should be rendered similar to roads in tunnels. Agreed! Do you have an example you could link to? An example for what? It looks like a ticket has already been filed for mapnik: http://trac.openstreetmap.org/ticket/2394 Without a special tag it is hard to define render rules for a road that is covered by a building. Is it? Can you explain why? Conceptually, all you need is layer=* and the ability to detect the overlap of the building=yes area and the highway=* way. But I guess you're saying this is hard to encode with render rules? Exactly. As someone today already stated in the ticket mentioned above you can not do this with the render rules both for mapnik and osmarender. This needs to be done in the pre-processor. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Should 'highway=incline[_steep]' be discouraged?
Roy Wallace waldo000...@gmail.com writes: Also, incline=* is still mathematically valid for nodes to indicate the instantaneous incline at that point, so I don't see a problem with that. The problem with nodes is that you can't tell to which way the incline applies when there is more than one connecting to the node. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Post_Box and addr:* nodes
Randy rwtnospam-new...@yahoo.com writes: Martin Fossdal Guttesen wrote: Well i got a list from the postal service over all the postal boxes the list is like this Postal nr | City | where it is | Address and the column where it is is an ordinary description of where it is,possible values are attached to building, on fence, built inn, on pole, inside shop and so on and the address is almost always an address of a way name and an number, but not always there are some rare exceptions where only an name is given, and that is alway some locale well known location the thing i was thinking about was well we allredy got a address node close by. the postal office is saying the postal box is belonging to it would'int it be nice/better/convinient to have some kinde of relation from the postal box to the address node then it wouldn't be that hard to make a map where you could find the nearest postal box In Mike's situation, where the post box address is similar to but not identical to the addr:housenumber, then I think it's valid to include it. And, even if it is identical to a building address, ref= is probably a better method than addr:housenumber=. To map a post box in OSM you need a latitude and longitude for it. To state additionally that it is near a certain address is redundant. And to tag the post box with the address from the list mentioned above is probably wrong because this is not the address of the box but some nearby address. You need to somehow translate that reference to an actual location on the globe (lat/lon). You wouldn't be able to route to a specific post box (or mailbox as we call them in the States) with a general purpose navigator program, but I think the need to route to a specific post box across town, would be a pretty unique need that could be met with a special purpose router that searched for ref=* instead of addr:housenumber=*. A router just needs to treat post boxes just like any other POI. You don't necessarily need an address to be able to route to it. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle=no
Anthony o...@inbox.org writes: On Fri, Dec 4, 2009 at 12:54 AM, Steve Bennett stevag...@gmail.com wrote: As in, bicycle=carriage_prohibited. You can't have bicycle=carriage_prohibited along with bicycle=no. It needs to be a different tag altogether, because it represents something different. I guess it is implied that when you are not allowed to carry a bike you are not allowed to ride it neither. One should avoid the temptation to make everything as complex as possible. - bicycle=no - you are not allowed to ride a bike - bicycle=prohibited - the presence of bikes is not allowed - bicycle=folded_only - you can have a folded bike I would hope this covers most cases. Matthias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
