Re: [Tagging] Change of rendering: place of worship and, terminal without building tag
2015-02-16 14:20 GMT+01:00 John Willis jo...@mac.com: So far I have not experienced a problem with adding religion and denomination tags to features operated by a religious community and have continued to use the same landuse I'd use otherwise on the same kind of feature (if any). What would I gain by adding landuse=religious? To map the _grounds_ of religious facilities where the predominant use is worship, and support facilities for the meeting and rituals and various things happen. OK, I think I finally understood the definition, and I agree that landuse=religious is a fine tag for these (e.g. including the parking of the church). IMHO the wiki page https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreligious should be corrected to be as explicit as you have been here today. The words ground of religious facilities and predominant use of worship are crucial here IMHO --- for instance a place where the politics or administration of a church are managed won't qualify under this definition (but should be tagged as commercial I guess, right? We could still add a religion tag there). Still there will be some strangeness in some cases, as we already have established landuse=cemetery, which might also qualify in some cases for landuse=religious. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Fri, Feb 13, 2015 at 4:02 PM, David Bannon dban...@internode.on.net wrote: To summarise discussion, structures like - amenity=campsite campsite=waste_disposal waste=chemical_toilet is a bit clumsy given how many tags are needed and how often it _should_ be tagged. Further, many sites be they mining, camping, whatever are large and identifying the particular node where the disposal point is is of value. rubbish=chemical_toiletis, perhaps ambiguous. Do we like rubbish_disposal= waste_disposal= ??? Lets see some hands please ? The mapping of potability for drinking water is in flux. However, toilet and drinking water tagging are well established already: amenity=campsite toilets=yes toilets:disposal=pitlatrine toilets:wheelchair=no drinking_water=yes These are appropriate for a campsite marked as a node. For a more detailed mapping the node can be expanded to an area, and each individual toilet and drinking water source mapped. For waste disposal I would suggest: amenity=campsite toilets=yes toilets:disposal=pitlatrine toilets:wheelchair=no drinking_water=yes *waste_disposal=yes*recycling:gas_bottles=yes Anything more complicated, and perhaps it's time for separate nodes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bus route relations. Forward/backward tag
2015-02-16 13:03 GMT+01:00 fly lowfligh...@googlemail.com: There are still cases where forward/backward are useful with P2-routes. E.g. a route with a loop and some members used twice but different directions. Shouldn't one just duplicate the stop_positions in the relation, and add ways twice in order, without roles ? Also, as Jo said, the public transport v2 scheme is cleaner as each variant of the route have its own relation, making loops in routes a rare case. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
Intermittent is an attribute, not a top level value. For example, it should be possible to tag a NEMA 5-15 as intermittent. 2015-02-16 11:47 GMT-08:00 Jan van Bekkum jan.vanbek...@gmail.com: Please comment the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/power_supply%3Dintermittentto add the value *intermittent *to the key* power_supply.* Met vriendelijke groet/with kind regards, *Jan van Bekkum* www.DeEinderVoorbij.nl ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] building=yes on nodes?
I would like to return to the original question: 1.) I think it is confusing to have building=cowshed allowed on nodes, but building=cabin not allowed. We should unify this. Either _all_ building=* keys can be used on nodes, or _none_. 2.) If we agree on 1.), would we opt to allow nodes or to disallow nodes? After reading the previous comments, I would tend to allow it. Best regards Lukas 2015-02-16 12:12 GMT, fly lowfligh...@googlemail.com: Am 14.02.2015 um 23:06 schrieb Tobias Knerr: On 14.02.2015 22:11, SomeoneElse wrote: ... it also says that it shouldn't be used on relations, which would exclude perfectly valid multipolygons, such as this one: Multipolygons are a means to map areas. So they are covered by the area icon. The relation icon stands for relations that are not areas, just as the way icon stands for ways that are not areas. How about type=building ? It appears that again people are trying to use the wiki to tell other people how to map rather than describe how things tend to be mapped. Nobody is telling anyone not to use multipolygons. This is totally misleading as the type of the object is still a relation. Once we introduce an area object we might cover closed ways and multipolygones as one category. For now we depend on the object type or e.g. editor software already need to implement the area type to offer proper presets. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - power_supply=intermittent
Please comment the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/power_supply%3Dintermittentto add the value *intermittent *to the key* power_supply.* Met vriendelijke groet/with kind regards, *Jan van Bekkum* www.DeEinderVoorbij.nl ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bus route relations. Forward/backward tag
Loops and spoons are still quite common, even when each variation gets its own route relation to describe which ways are used from beginning to end. What is better in v2 is that the way to describe each of the variations, is completely unambiguous. To me they are easier to fix when they get broken. Or at least it's easier to notice that they are broken and where, as long as the ways are ordered. Jo 2015-02-16 18:58 GMT+01:00 Éric Gillet gill3t.3ric+...@gmail.com: 2015-02-16 13:03 GMT+01:00 fly lowfligh...@googlemail.com: There are still cases where forward/backward are useful with P2-routes. E.g. a route with a loop and some members used twice but different directions. Shouldn't one just duplicate the stop_positions in the relation, and add ways twice in order, without roles ? Also, as Jo said, the public transport v2 scheme is cleaner as each variant of the route have its own relation, making loops in routes a rare case. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] building=yes on nodes?
All building=* on nodes is fine. As others have pointed out, it is often necessary in HOT aerial mapping when we have low-resolution imagery to work from. Also, for humanitarian purposes there are serious uses for node-only buildings, for estimating the population or the population distribution in a place. I've edited the wiki to set onNode=yes. I hope that doesn't lead to a storm Best Dan 2015-02-16 18:10 GMT+00:00 Lukas Sommer sommer...@gmail.com: I would like to return to the original question: 1.) I think it is confusing to have building=cowshed allowed on nodes, but building=cabin not allowed. We should unify this. Either _all_ building=* keys can be used on nodes, or _none_. 2.) If we agree on 1.), would we opt to allow nodes or to disallow nodes? After reading the previous comments, I would tend to allow it. Best regards Lukas 2015-02-16 12:12 GMT, fly lowfligh...@googlemail.com: Am 14.02.2015 um 23:06 schrieb Tobias Knerr: On 14.02.2015 22:11, SomeoneElse wrote: ... it also says that it shouldn't be used on relations, which would exclude perfectly valid multipolygons, such as this one: Multipolygons are a means to map areas. So they are covered by the area icon. The relation icon stands for relations that are not areas, just as the way icon stands for ways that are not areas. How about type=building ? It appears that again people are trying to use the wiki to tell other people how to map rather than describe how things tend to be mapped. Nobody is telling anyone not to use multipolygons. This is totally misleading as the type of the object is still a relation. Once we introduce an area object we might cover closed ways and multipolygones as one category. For now we depend on the object type or e.g. editor software already need to implement the area type to offer proper presets. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] high mobile masts on man_made=mast
2015-02-16 13:33 GMT+01:00 fly lowfligh...@googlemail.com: Thought antenna vs mast might be a problem but not mast vs tower. antenna and mast are orthogonal concepts, a mast is defining the shape, an antenna the function, that's easy ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Change of rendering: place of worship and, terminal without building tag
Sent from my iPhone On Feb 17, 2015, at 1:50 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-16 14:20 GMT+01:00 John Willis jo...@mac.com: So far I have not experienced a problem with adding religion and denomination tags to features operated by a religious community and have continued to use the same landuse I'd use otherwise on the same kind of feature (if any). What would I gain by adding landuse=religious? To map the _grounds_ of religious facilities where the predominant use is worship, and support facilities for the meeting and rituals and various things happen. OK, I think I finally understood the definition, and I agree that landuse=religious is a fine tag for these (e.g. including the parking of the church). IMHO the wiki page https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreligious should be corrected to be as explicit as you have been here today. I'll try to update the wiki today (though I wasn't involved with this page's creation) and I'll ask for feedback here when I am done. The words ground of religious facilities and predominant use of worship are crucial here IMHO --- for instance a place where the politics or administration of a church are managed won't qualify under this definition (but should be tagged as commercial I guess, right? We could still add a religion tag there). Still there will be some strangeness in some cases, as we already have established landuse=cemetery, which might also qualify in some cases for landuse=religious. Although the churches in California I know of do not have a cemetery on the grounds, every single temple here in Japan does - even the ones in Tokyo, so finding a very old cemetery hemmed in by a 25 story building, a train line, a river, and residential housing (and still on the temple grounds) is common. There are stand-alone cemeteries as well, and most neighborhoods have little tiny 5x5m or so somewhat private cemeteries everywhere (every 2-300m or so) over all of Japan, so I am not saying they are all landuse=religious, but some larger ones on the temple grounds certainly are, and it is an amenity of the temple - it's a big deal/expense to have a family grave on the temple grounds. Can you have nested landuses? It is clearly part of the temple grounds, and clearly a cemetery. I would tag it that way, but I don't know if I'm breaking done rule by doing that. Javbw cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Mon, Feb 16, 2015 at 8:07 PM, David Bannon dban...@internode.on.net wrote: On Tue, Feb 17, 2015 at 8:54 AM, Bryce Nesbitt bry...@obviously.com ..For example: a commonly needed and commonly mapped feature is an RV dump station, for emptying sewage holding tanks. On Tue, 2015-02-17 at 10:39 +0700, Dave Swarthout wrote: .. discussion are resisting it as a top level tag (amenity=dump_station) Dave, a more consistent approach would be - amenity=waste_disposal waste=chemical_toilet The real question is what type of tag would attract rendering support. amenity=dump_station is easier to deal with, as it's a single level that maps to the commonly understood function of a place to dump a sewage holding tank. There is a common icon: http://www.broomfield.org/images/pages/N331/blue%20heading%20icons_rv%20dump.png amenity=waste_disposal + waste=chemical_toilet is a nested tag, and far less clear. Someone searching for a preset for this might not find it. And it's not entirely clear exactly what the waste is (the toilet or the contents of the toilet)? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
- The community supply is not reliable and fails at random moments *during the day...* On Tue Feb 17 2015 at 7:09:33 AM Jan van Bekkum jan.vanbek...@gmail.com wrote: The proposal comes from experience while traveling through Africa. Electricity failing three times per year probably isn't very valuable information to campers. We ran into three situations I would like to cover: - The community supply is not reliable and fails at random moments - The camping operates a generator that runs between 19:00 and 23:00 - The camping operates a system with solar cells and batteries. They allow you to use electricity (at least for larger devices like fridges) from an hour after sunrise to sunset. I think it is not that important to know that electricity comes from solar power, but it is important its availability limits as set by the camping operator, although it may mean that supply is worse in the rainy season I agree that a structure that maintains power_supply=nema_5_15 is preferable. Trying to invent as few new tags as possible the updated proposal would become: - power_supply=nema_5_15 - power_supply:schedule= [...] - has syntax as defined for opening_hours Or - power_supply=nema_5_15 - power_supply:schedule= intermittent Or do you feel that power_supply:intermittent=yes is better than power_supply:schedule= intermittent? Regards, Jan van Bekkum On Tue Feb 17 2015 at 4:32:54 AM David Bannon dban...@internode.on.net wrote: On Mon, 2015-02-16 at 20:47 +0100, Jan van Bekkum wrote: Please comment the proposal to add the value intermittent to the key power_supply. Jan, good move, just wondering what you mean by 'intermittent' ? Two cases may need to be enlarged on - 1. Where I live, power goes off, typically due to weather, three or four times a year. Thats occasional failure rather than intermittent ? 2. At a place I like to camp at in Central Australia, power is provided during particular times of the day, from memory, 7:00am-9:00pm and 5:30pm-8:30pm. That also is probably not intermittent ? David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] building=yes on nodes?
On Tue, Feb 17, 2015 at 1:30 AM, Dan S danstowell+...@gmail.com wrote: All building=* on nodes is fine. As others have pointed out, it is often necessary in HOT aerial mapping when we have low-resolution imagery to work from. Agree. As for the Wiki editing, I too hope it doesn't lead to a storm. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On 17/02/2015 6:45 AM, Bryce Nesbitt wrote: On Fri, Feb 13, 2015 at 4:02 PM, David Bannon dban...@internode.on.net mailto:dban...@internode.on.net wrote: To summarise discussion, structures like - amenity=campsite campsite=waste_disposal waste=chemical_toilet is a bit clumsy given how many tags are needed and how often it _should_ be tagged. Further, many sites be they mining, camping, whatever are large and identifying the particular node where the disposal point is is of value. rubbish=chemical_toiletis, perhaps ambiguous. Do we like rubbish_disposal= waste_disposal= ??? Lets see some hands please ? The mapping of potability for drinking water is in flux. However, toilet and drinking water tagging are well established already: amenity=campsite toilets=yes toilets:disposal=pitlatrine toilets:wheelchair=no drinking_water=yes These are appropriate for a campsite marked as a node. For a more detailed mapping the node can be expanded to an area, and each individual toilet and drinking water source mapped. For waste disposal I would suggest: amenity=campsite toilets=yes toilets:disposal=pitlatrine toilets:wheelchair=no drinking_water=yes *waste_disposal=yes *recycling:gas_bottles=yes Anything more complicated, and perhaps it's time for separate nodes. ___ Waste colleting is wider than just camping sites. And that is the point of consdering it as a new high level tag. The porposal may have come out of consderation of camp sites .. but it has much wider use and so should not be considered as just for camping sites. Your suggested tag waste_disposal=yes .. would need further expansion .. bin for 'household refuse'?, bin for recycling, human waste collection point from a chemical toilet, etc, etc ... --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
On 17/02/2015 6:47 AM, Jan van Bekkum wrote: Please comment the proposal http://wiki.openstreetmap.org/wiki/Proposed_features/power_supply%3Dintermittentto add the value /intermittent /to the key/power_supply./ Met vriendelijke groet/with kind regards, /Jan van Bekkum/ www.DeEinderVoorbij.nl http://www.DeEinderVoorbij.nl humm power_supply=intermittent For solar only supply (no battery back up for night time).. add \ power_supply:intermittent=solar ? - If the power supply has scheduled hours of operation then perhaps this should be another key. For example power_supply=scheduled power_supply:scheduled=9.00-20:00 For a scheduled supply from 9 am to 8 pm. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
On 17/02/2015 6:50 AM, Bryce Nesbitt wrote: Intermittent is an attribute, not a top level value. For example, it should be possible to tag a NEMA 5-15 as intermittent. so a tag sequence of power_supply=nema_5_15 power_supply:intermittent=yes ? And then for my previous comments become; power_supply=nema_5_15 power_supply:solar=yes power_supply=nema_5_15 power_supply:schedule=9:00-20:00 Much better .. and constant with the present use of the tag power_supply= key describing the connector used. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
How in hell did the term pitlatrine get in there 1500 times? A weird construction of a multi-word term IMO. If anything it should be pit_latrine. As far as that goes, the tag toilet:disposal seems, to this reader at least, to indicate a place to discard toilets and be limited to the values yes or no. Are the people who dream up these tags speaking English? On Tue, Feb 17, 2015 at 6:46 AM, Warin 61sundow...@gmail.com wrote: On 16/02/2015 11:26 PM, Martin Koppenhoefer wrote: 2015-02-08 23:15 GMT+01:00 Warin 61sundow...@gmail.com: A proposal for a new high level tag of .. Rubbish :-) https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish At present there as a number of 'waste' values under the amenity key. sorry for commenting a bit late on this. If I saw a tag like rubbish=transfer_station I would maybe expect a broken transfer station or something similar. A key should somehow describe what is tagged, i.e. which property, or what kind of object, but if I understand your proposal right, you want to tag an ashtray with rubbish=cigarettes, and with rubbish=transfer_station a facility? IMHO this is mixing up concepts. Using rubbish as an attribute and have a scheme such as (just an example): amenity=generic_waste_disposal and add then rubbish=cigarettes (i.e. ashtray) rubbish=oil (a place to put old oil) etc., i.e. using this as an attribute. This is also introducing the problem, that you will have to know whether your used materials/trash will get recycled or otherwise brought away (incinerated or buried etc.). cheers, Martin Moved on while you weren't looking. .. see [Tagging] Waste_collection - a new Feature Proposal - RFC though it has no page as yet.. waste-collection= .. is a fair description for most waste/rubbish points that are mapped and also covers recycling .. as it is waste and is usually collected for the mapped point. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Mon, Feb 16, 2015 at 3:27 PM, Warin 61sundow...@gmail.com wrote: Waste colleting is wider than just camping sites. And that is the point of consdering it as a new high level tag. The porposal may have come out of consderation of camp sites .. but it has much wider use and so should not be considered as just for camping sites. It was unclear from the discussion and examples if the existing tagging was understood! --- While toilet drinking water tagging is reasonably stable, there are several camping waste related tags that are not. For example: a commonly needed and commonly mapped feature is an RV dump station, for emptying sewage holding tanks. There is a pretty standard symbol for this activity on rendered maps. Communities of RV'ers may well be attracted to mapping in OSM, if this feature type were widely rendered. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On 16/02/2015 11:26 PM, Martin Koppenhoefer wrote: 2015-02-08 23:15 GMT+01:00 Warin 61sundow...@gmail.com mailto:61sundow...@gmail.com: A proposal for a new high level tag of .. Rubbish :-) https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish At present there as a number of 'waste' values under the amenity key. sorry for commenting a bit late on this. If I saw a tag like rubbish=transfer_station I would maybe expect a broken transfer station or something similar. A key should somehow describe what is tagged, i.e. which property, or what kind of object, but if I understand your proposal right, you want to tag an ashtray with rubbish=cigarettes, and with rubbish=transfer_station a facility? IMHO this is mixing up concepts. Using rubbish as an attribute and have a scheme such as (just an example): amenity=generic_waste_disposal and add then rubbish=cigarettes (i.e. ashtray) rubbish=oil (a place to put old oil) etc., i.e. using this as an attribute. This is also introducing the problem, that you will have to know whether your used materials/trash will get recycled or otherwise brought away (incinerated or buried etc.). cheers, Martin Moved on while you weren't looking. .. see [Tagging] Waste_collection - a new Feature Proposal - RFC though it has no page as yet.. waste-collection= .. is a fair description for most waste/rubbish points that are mapped and also covers recycling .. as it is waste and is usually collected for the mapped point. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] high mobile masts on man_made=mast
On 16/02/2015 11:33 PM, fly wrote: Be careful some mast as support for wind generators might be entered. Thought antenna vs mast might be a problem but not mast vs tower. Cheers fly An antenna is not a mast nor a tower, just as a wind generator is not a mast nor a tower. They may be mounted on top of a mast of tower .. but they are not towers nor masts themselves. - I like the easy distinction between mast and tower by the guy wires. If it is technically correct .. Some structures (masts?) supported by guy wires, have internal ladders .. for maintenance of the supported item. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Change of rendering: place of worship and, terminal without building tag
Sent from my iPhone On Feb 16, 2015, at 7:56 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-15 13:44 GMT+01:00 John Willis jo...@mac.com: Landuse=religious is a generic version of churchyard. I agree that a churchyard could have a dedicated tag like amenity=churchyard (similar to amenity=graveyard) or historic=churchyard. IMHO landuse shouldn't define a feature, but be used as an attribute (the usage of the land). It is the grounds used by the POW or building=church/temple/ whatever It's just a more religious agnostic term - as a Buddhist temple doesn't have church grounds, a church doesn't have mosque grounds. And neither of them are commercial or retail grounds. I can think of several large church complexes in California - a massive Mormon temple, a Presbyterian church ground a with a small preschool, a couple Catholic Churches, a Jehovah's Witness hall, a big mega-church hall, a cult-like church that meets in a house (registered as a church so it shows up in google maps as one), a mosque, a Greek Orthodox something church, a Jewish community center, and now about 100 Buddhist temples and Shinto shrines. let's take a look at the community center: do we want different landuse for a community center operated by a religious community compared to a profane one? (This is a question we have to ask ourselves in order to find tagging definitions, it is not a rhetorical question) You caught my error - I wanted throw the JCC on the list because I have been inside, but the better choice for inclusion would have been the synagogue (temple?) a few blocks away that is affiliated with it (I believe) But it is a good point to bring up, but because of my error, it is not an easy question. IMHO, if it's name is the Jewish community center, and its access restricted because it is for Jewish people and no one else - it is a religious facility imho, though not a POW. I visited most of these facilities as a repairman - I would not be welcome to wander in to this particular place. It is not in service of the local community - just as the Fellowship Hall at my parent's Presbyterian church is not a church and is used _exactly_ as a community center - but is operated for the benefit of the patrons of the church. But let's say that we do consider both sites - the massive JCC and the small fellowship hall a community center - Then: Landuse=religious + Building=yes Amenity=community_centre it seems straight forward to me now, but didn't envision the landuse=religious for this purpose. The main church in my example (which is the centerpiece of the complex, across the courtyard) would have the POW tag and building=church or whatnot. Shall we have different landuses for schools operated by a religious community compared to a government school? I think we have decided that the deciding factor for a schools primary tagging and repentant ion in OSM is if it is a school or not (k-12, higher Ed), and the rest goes under operator Just as a sidenote: if I were to tag all residential places in Rome which belong to the catholic church, 25% of Rome would be landuse=religious. If I tagged the land owned by the temple that operates my school, then the electrician shop and a cafe that were out front would be religious too, but they clearly are not. It was loaned to my friend a long time ago, and he built a bookstore and an office on the space. It is not part of the temple grounds. It is not part of the school. It is not part of the preschool. It was landuse=commercial when it was (in the end) the office of an electrical engineer. Recently the temple requested the land back. He moved and they bulldozed the building and are constructing a new wing to the private Buddhist high school they operate. Which would be school landuse or whatever. But the temple across the street - with the big Buddha worship hall, big bell, giant graveyard (yes, with a few samurai in it), and a tall wall around the whole mess - landuse=religious. So far I have simply added religion=christian, denomination=catholic to universities, schools and kindergardens operated by the catholic church, because they are mainly universities, schools and kindergardens, not religious places in my eyes. There are also banks operated by the church, is this religious landuse? This seems perfectly reasonable, because we have decided (and I agree) that the important sorting bit is the fact that it is a school, which is why I would do the same to the schools grounds of the private Buddhist high school. So far I have not experienced a problem with adding religion and denomination tags to features operated by a religious community and have continued to use the same landuse I'd use otherwise on the same kind of feature (if any). What would I gain by adding landuse=religious? To map the _grounds_ of religious facilities where the
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Tue, Feb 17, 2015 at 8:54 AM, Bryce Nesbitt bry...@obviously.com wrote: While toilet drinking water tagging is reasonably stable, there are several camping waste related tags that are not. For example: a commonly needed and commonly mapped feature is an RV dump station, for emptying sewage holding tanks. @Bryce, +1 That's what I've been saying all along. The term dump_station is widely used in the U.S., even to the extent that official signs use the term (without the underscore, of course). People in this discussion are resisting it as a top level tag (amenity=dump_station) but it's one I think is very appropriate. And much better than waste=chemical_toilet, which is ambiguous (is the toilet the waste or its contents?) I have a similar objection to the term toilet:disposal=* Neither phrase is in common use in the U.S. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Tue, 2015-02-17 at 10:46 +1100, Warin wrote: ... though it has no page as yet.. True, and given the lack of support, I don't think it is likely to need one ! Lets drop this proposal. This particular proposal started when Dave S complained about multi tags needed but even he is distancing himself. I'm back to refining docs about using existing tags. David waste-collection= .. is a fair description for most waste/rubbish points that are mapped and also covers recycling .. as it is waste and is usually collected for the mapped point. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
On Tue, Feb 17, 2015 at 8:54 AM, Bryce Nesbitt bry...@obviously.com ..For example: a commonly needed and commonly mapped feature is an RV dump station, for emptying sewage holding tanks. On Tue, 2015-02-17 at 10:39 +0700, Dave Swarthout wrote: .. discussion are resisting it as a top level tag (amenity=dump_station) Dave, a more consistent approach would be - amenity=waste_disposal waste=chemical_toilet I have a published list of maybe 450 AU Dump Points and all are suited to large RV holding tanks and the small cassette systems. Sigh, no, three allow only the small cassettes !! What the ??? Anyway, if we accept the argument that amenity already has too many tags (not sure I do but..) all that needs happen is better docs relating to existing tags and, if you really don't like using chemical_toilet, some new waste= tag. I'd be happy to support waste=dump_station . David but it's one I think is very appropriate. And much better than waste=chemical_toilet, which is ambiguous (is the toilet the waste or its contents?) I have a similar objection to the term toilet:disposal=* Neither phrase is in common use in the U.S. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
On Mon, 2015-02-16 at 20:47 +0100, Jan van Bekkum wrote: Please comment the proposal to add the value intermittent to the key power_supply. Jan, good move, just wondering what you mean by 'intermittent' ? Two cases may need to be enlarged on - 1. Where I live, power goes off, typically due to weather, three or four times a year. Thats occasional failure rather than intermittent ? 2. At a place I like to camp at in Central Australia, power is provided during particular times of the day, from memory, 7:00am-9:00pm and 5:30pm-8:30pm. That also is probably not intermittent ? David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] high mobile masts on man_made=mast
Am 16.02.2015 um 11:32 schrieb Martin Koppenhoefer: 2015-02-16 4:25 GMT+01:00 Dave Swarthout daveswarth...@gmail.com: On Mon, Feb 16, 2015 at 4:23 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: I've been taught that a mast is usually not self supporting, ie. has guy wires while a tower is self supporting. +1 -1 Usually depends on the construction and height. Also, the wiki definition needs changing IMO. Maybe they meant to say, a few meters in diameter. +1 We have height=*. How to we define the difference between mast and pole ? Do we need support=mast ? Thing is that in German we have (slightly) different usage of these terms, there are the words - Turm (tower in some cases): typically something accessible by humans (with stairs, not just a ladder), if its masonry it will always be a Turm, while steel lattice could be either, but for power towers, these will never be called Turm in German but Mast - Mast something not accessible (except maintenance by technicians, typically no stairs but just a ladder), can be guy wired, but doesn't have to (used e.g. for most technical installations like support for antennas, street lamps (i.e. also cases where English uses the words pole, pylon or rod), ships, flags, telco wires, power towers, ... de:Mast is always something tall and thin, while de:Turm is always accessible, but can also be not very high (e.g. defensive towers of ancient fortifications in some cases). The current definition in the wiki almost reflects this German usage 100% (no wonder, apparently written by a German), but not completely because there are very high guy wired structures like antennas, e.g. this one would be called Mast in German: http://en.wikipedia.org/wiki/KVLY-TV_mast I think the main difference is that a Mast cannot be entered, while a Turm is intended to be entered by humans. Be careful some mast as support for wind generators might be entered. Thought antenna vs mast might be a problem but not mast vs tower. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bus route relations. Forward/backward tag
Yes, I'm reconsidering my POV. It will probably make sorting the members automatically a lot easier than it is atm. /me is off to go and convert some route relations... :-) (Helped by a script ofc, doing it manually is a chore. So I'll adapt the script and let you know when it's ready to be used.) Jo 2015-02-16 13:03 GMT+01:00 fly lowfligh...@googlemail.com: There are still cases where forward/backward are useful with P2-routes. E.g. a route with a loop and some members used twice but different directions. Personally, I still use forward/backward on any member of a route which is only used in one direction and for all P2-routes as it makes it much easier to get the direction of the route with incomplete data. cu fly Am 16.02.2015 um 08:40 schrieb Jo: On the one hand I'm not adding roles to the ways in PT routes relations anymore, instead I add all the ways in the correct order. Some ways are included twice. But if you prefer to add them, you have to know forward/backward relates to the direction of the way itself. If it follows the arrow: forward, if it goes against it: backward. If you do it right, JOSM is able to sort your ways automatically. If you're still on the v1 scheme, where there is only one route relations doing a futile attempt to describe all variations, I suggest you switch to the new scheme where a route_master describes the line and route relations describe each variation from beginning to end. This is how we do it in Belgium: http://www.openstreetmap.org/user/Polyglot/diary/28401 There are some links to Youtube videos included in that article. 2015-02-16 5:52 GMT+01:00 Hans De Kryger hans.dekryge...@gmail.com: Me and a fellow mapper are adding bus routes to are city and are confused about the Forward/backward tag you use on relations. I think I'm using it right yet every time i check ÖPNVKarte, it shows the route going the opposite way in which i intended. Just looking for any help i can get. I'm quite confused on the usage of the tag especially the use of it on a two way street. Which way is forward and which way is backward. Thanks in advance. ÖPNVKarte - ( http://xn--pnvkarte-m4a.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - key:rubbish=
2015-02-08 23:15 GMT+01:00 Warin 61sundow...@gmail.com: A proposal for a new high level tag of .. Rubbish :-) https://wiki.openstreetmap.org/wiki/Proposed_features_key%3Drubbish At present there as a number of 'waste' values under the amenity key. sorry for commenting a bit late on this. If I saw a tag like rubbish=transfer_station I would maybe expect a broken transfer station or something similar. A key should somehow describe what is tagged, i.e. which property, or what kind of object, but if I understand your proposal right, you want to tag an ashtray with rubbish=cigarettes, and with rubbish=transfer_station a facility? IMHO this is mixing up concepts. Using rubbish as an attribute and have a scheme such as (just an example): amenity=generic_waste_disposal and add then rubbish=cigarettes (i.e. ashtray) rubbish=oil (a place to put old oil) etc., i.e. using this as an attribute. This is also introducing the problem, that you will have to know whether your used materials/trash will get recycled or otherwise brought away (incinerated or buried etc.). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] high mobile masts on man_made=mast
Am 16.02.2015 um 13:33 schrieb fly: Am 16.02.2015 um 11:32 schrieb Martin Koppenhoefer: 2015-02-16 4:25 GMT+01:00 Dave Swarthout daveswarth...@gmail.com: On Mon, Feb 16, 2015 at 4:23 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: I've been taught that a mast is usually not self supporting, ie. has guy wires while a tower is self supporting. +1 -1 Usually depends on the construction and height. Sorry, tried to write: Usually depends on the construction and diametre but not height. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] building=yes on nodes?
Am 14.02.2015 um 23:06 schrieb Tobias Knerr: On 14.02.2015 22:11, SomeoneElse wrote: ... it also says that it shouldn't be used on relations, which would exclude perfectly valid multipolygons, such as this one: Multipolygons are a means to map areas. So they are covered by the area icon. The relation icon stands for relations that are not areas, just as the way icon stands for ways that are not areas. How about type=building ? It appears that again people are trying to use the wiki to tell other people how to map rather than describe how things tend to be mapped. Nobody is telling anyone not to use multipolygons. This is totally misleading as the type of the object is still a relation. Once we introduce an area object we might cover closed ways and multipolygones as one category. For now we depend on the object type or e.g. editor software already need to implement the area type to offer proper presets. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Change of rendering: place of worship and, terminal without building tag
Am 16.02.2015 um 11:56 schrieb Martin Koppenhoefer: 2015-02-15 13:44 GMT+01:00 John Willis jo...@mac.com: Landuse=religious is a generic version of churchyard. I agree that a churchyard could have a dedicated tag like amenity=churchyard (similar to amenity=graveyard) or historic=churchyard. IMHO landuse shouldn't define a feature, but be used as an attribute (the usage of the land). +1 I can think of several large church complexes in California - a massive Mormon temple, a Presbyterian church ground a with a small preschool, a couple Catholic Churches, a Jehovah's Witness hall, a big mega-church hall, a cult-like church that meets in a house (registered as a church so it shows up in google maps as one), a mosque, a Greek Orthodox something church, a Jewish community center, and now about 100 Buddhist temples and Shinto shrines. let's take a look at the community center: do we want different landuse for a community center operated by a religious community compared to a profane one? (This is a question we have to ask ourselves in order to find tagging definitions, it is not a rhetorical question). Shall we have different landuses for schools operated by a religious community compared to a government school? Just as a sidenote: if I were to tag all residential places in Rome which belong to the catholic church, 25% of Rome would be landuse=religious. So far I have simply added religion=christian, denomination=catholic to universities, schools and kindergardens operated by the catholic church, because they are mainly universities, schools and kindergardens, not religious places in my eyes. There are also banks operated by the church, is this religious landuse? So far I have not experienced a problem with adding religion and denomination tags to features operated by a religious community and have continued to use the same landuse I'd use otherwise on the same kind of feature (if any). What would I gain by adding landuse=religious? +1 I usually use amenity=place_of_worship for the whole area similar to amenity=school and amenity=hospital. Do not think landuse=religious is any landuse. The problem with the numbers are that a small number of users did introduce it and iD and JOSM way to early introduced presets for it, even when the tag was by far established and the discussion about it on this list was not finished, yet. cu fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - power_supply=intermittent
The proposal comes from experience while traveling through Africa. Electricity failing three times per year probably isn't very valuable information to campers. We ran into three situations I would like to cover: - The community supply is not reliable and fails at random moments - The camping operates a generator that runs between 19:00 and 23:00 - The camping operates a system with solar cells and batteries. They allow you to use electricity (at least for larger devices like fridges) from an hour after sunrise to sunset. I think it is not that important to know that electricity comes from solar power, but it is important its availability limits as set by the camping operator, although it may mean that supply is worse in the rainy season I agree that a structure that maintains power_supply=nema_5_15 is preferable. Trying to invent as few new tags as possible the updated proposal would become: - power_supply=nema_5_15 - power_supply:schedule= [...] - has syntax as defined for opening_hours Or - power_supply=nema_5_15 - power_supply:schedule= intermittent Or do you feel that power_supply:intermittent=yes is better than power_supply:schedule= intermittent? Regards, Jan van Bekkum On Tue Feb 17 2015 at 4:32:54 AM David Bannon dban...@internode.on.net wrote: On Mon, 2015-02-16 at 20:47 +0100, Jan van Bekkum wrote: Please comment the proposal to add the value intermittent to the key power_supply. Jan, good move, just wondering what you mean by 'intermittent' ? Two cases may need to be enlarged on - 1. Where I live, power goes off, typically due to weather, three or four times a year. Thats occasional failure rather than intermittent ? 2. At a place I like to camp at in Central Australia, power is provided during particular times of the day, from memory, 7:00am-9:00pm and 5:30pm-8:30pm. That also is probably not intermittent ? David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] high mobile masts on man_made=mast
2015-02-16 4:25 GMT+01:00 Dave Swarthout daveswarth...@gmail.com: On Mon, Feb 16, 2015 at 4:23 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: I've been taught that a mast is usually not self supporting, ie. has guy wires while a tower is self supporting. +1 Also, the wiki definition needs changing IMO. Maybe they meant to say, a few meters in diameter. Thing is that in German we have (slightly) different usage of these terms, there are the words - Turm (tower in some cases): typically something accessible by humans (with stairs, not just a ladder), if its masonry it will always be a Turm, while steel lattice could be either, but for power towers, these will never be called Turm in German but Mast - Mast something not accessible (except maintenance by technicians, typically no stairs but just a ladder), can be guy wired, but doesn't have to (used e.g. for most technical installations like support for antennas, street lamps (i.e. also cases where English uses the words pole, pylon or rod), ships, flags, telco wires, power towers, ... de:Mast is always something tall and thin, while de:Turm is always accessible, but can also be not very high (e.g. defensive towers of ancient fortifications in some cases). The current definition in the wiki almost reflects this German usage 100% (no wonder, apparently written by a German), but not completely because there are very high guy wired structures like antennas, e.g. this one would be called Mast in German: http://en.wikipedia.org/wiki/KVLY-TV_mast I think the main difference is that a Mast cannot be entered, while a Turm is intended to be entered by humans. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Change of rendering: place of worship and, terminal without building tag
2015-02-15 13:44 GMT+01:00 John Willis jo...@mac.com: Landuse=religious is a generic version of churchyard. I agree that a churchyard could have a dedicated tag like amenity=churchyard (similar to amenity=graveyard) or historic=churchyard. IMHO landuse shouldn't define a feature, but be used as an attribute (the usage of the land). I can think of several large church complexes in California - a massive Mormon temple, a Presbyterian church ground a with a small preschool, a couple Catholic Churches, a Jehovah's Witness hall, a big mega-church hall, a cult-like church that meets in a house (registered as a church so it shows up in google maps as one), a mosque, a Greek Orthodox something church, a Jewish community center, and now about 100 Buddhist temples and Shinto shrines. let's take a look at the community center: do we want different landuse for a community center operated by a religious community compared to a profane one? (This is a question we have to ask ourselves in order to find tagging definitions, it is not a rhetorical question). Shall we have different landuses for schools operated by a religious community compared to a government school? Just as a sidenote: if I were to tag all residential places in Rome which belong to the catholic church, 25% of Rome would be landuse=religious. So far I have simply added religion=christian, denomination=catholic to universities, schools and kindergardens operated by the catholic church, because they are mainly universities, schools and kindergardens, not religious places in my eyes. There are also banks operated by the church, is this religious landuse? So far I have not experienced a problem with adding religion and denomination tags to features operated by a religious community and have continued to use the same landuse I'd use otherwise on the same kind of feature (if any). What would I gain by adding landuse=religious? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! 2015-02-16 10:58 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: * maxwidth:physical: according to the wiki page: a physical limit IIRR there were users of latin american countries telling that their bridges sometimes had 2 height informations signposted: maxheight and maxheight:physical and that this was the reason for the introduction of maxheight:physical (I assume that maxwidth is working just the same). The width of a feature in my understanding is a physical limit. -1, the width is one dimension of a feature (depending on the kind of thing you are describing, there are other dimensions like height, length, diameter, depth, etc.), I wouldn't call this (in all cases) a limit Ok. But that didn't really answer my question. When should maxwidth:physical be used? Does this have to be signposted? Measured? What exactly does it describe? When should one use it and when should width or maxwidth be used? So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). if there was something tagged like (example made up): barrier=bollard width=0.2m maxwidth=1.2m What about maxwidth:physical in this example? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Martin Vonwald wrote: My understanding so far: * width: this is the actual width of a feature * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature * maxwidth:physical: according to the wiki page: a physical limit The width of the vehicle that could use the way can be wider than the way itself, even if it depends on the conditions whether they're allowed to. For an example, a way in a park might be, say, 2 meters wide, but if there's just grass around it, a maintenance or construction vehicle or what ever could use that way even if all wheels don't fit on the intended surface (supposing the soil isn't too soft). Or a cycleway; the asphalt is 2.5 meters (width), but if there's no guard rail, a police van can use it even if they're wider than that (with mirrors included) - but if there's a guard rail on one side and a hedge on the other side, the physical maximum width could be just 2.6 meters (numbers off the top of my head.) Another likely case is when the width of a gate is, say, 3 meters (the whole structure), but the gap between the sides is only 2 meters: width=3 + maxwidth:physical=2 Less likely cases could be a road with trees next to it, such that the road is 6 meters wide, but for a section the branches limit the physical width usable for vehicles to, for example, 4 meters. Or a divider on the pedestrian crossing limits the physical width of passing vehicles to x meters, yet the road is more than 2*x wide. I haven't looked up if the maximum legal width sign refers to the actual width (with mirrors etc) or to the width stated in the vehicle's registration documents. Nevertheless, a road with a width of 2.6 meters (e.g. a narrow old town alley or a courtyard entrance) may, or may not, physically allow a vehicle with a width of 2.55 m + mirrors to pass. It's true that good example photos would be a nice touch to the documentation. Considering the possibilities of different special loads, with the transported object surpassing the width of the vehicle, should IMO be beyond the applicability of these tags as such; a 4 meter wide load supported 2 meters above the road surface could or would, for example, just go over the pedestrian crossing middle island traffic signs, whereas a four meter wide harvester couldn't navigate that location at all. I don't yet have an idea how that should be best spelled out in the wiki. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Maybe it's for special cargo. If you are a regular truck, you have to use maxwidth. But if you are a truck that has oversize load[1] you use maxwidth:physical. [1] https://en.wikipedia.org/wiki/Oversize_load Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! I just stumbled upon the wiki article regarding maxwidth:physical. From reading it - and the articles about maxwidth and width - I don't really understand when to use each key. My understanding so far: * width: this is the actual width of a feature * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature * maxwidth:physical: according to the wiki page: a physical limit The width of a feature in my understanding is a physical limit. So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). Is this the intention of maxwidth:physical? Some additional examples and a section When to use might be helpful. best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
2015-02-16 10:42 GMT+01:00 Martin Vonwald imagic@gmail.com: Hi! I just stumbled upon the wiki article regarding maxwidth:physical. From reading it - and the articles about maxwidth and width - I don't really understand when to use each key. My understanding so far: * width: this is the actual width of a feature +1 * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature +1, there is also the synonym maxwidth:legal (IMHO not advisable, as this is the same than the more used maxwidth) * maxwidth:physical: according to the wiki page: a physical limit IIRR there were users of latin american countries telling that their bridges sometimes had 2 height informations signposted: maxheight and maxheight:physical and that this was the reason for the introduction of maxheight:physical (I assume that maxwidth is working just the same). The width of a feature in my understanding is a physical limit. -1, the width is one dimension of a feature (depending on the kind of thing you are describing, there are other dimensions like height, length, diameter, depth, etc.), I wouldn't call this (in all cases) a limit So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). if there was something tagged like (example made up): barrier=bollard width=0.2m maxwidth=1.2m I'd expect the width to be the width of the bollard and maxwidth the (in theory legal) width of the vehicle that can pass through (e.g. number taken by reading off a sign) and you might want to add maxwidth:physical=1.22m (the actual maximum width of a vehicle or person that can pass through). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
In the UK frequent use is made of legal weight and width limits, often to keep heavy traffic out of residential areas or away from country lanes. In this case the road sign usually has a qualifier except for access. An emergency vehicle can ignore these legal limits of course, but they would be ill-advised to ignore physical limits. So a clear definition and consistent usage is definitely a good idea. On 2015-02-16 10:58, Martin Koppenhoefer wrote: 2015-02-16 10:42 GMT+01:00 Martin Vonwald imagic@gmail.com: Hi! I just stumbled upon the wiki article regarding maxwidth:physical. From reading it - and the articles about maxwidth and width - I don't really understand when to use each key. My understanding so far: * width: this is the actual width of a feature +1 * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature +1, there is also the synonym maxwidth:legal (IMHO not advisable, as this is the same than the more used maxwidth) * maxwidth:physical: according to the wiki page: a physical limit IIRR there were users of latin american countries telling that their bridges sometimes had 2 height informations signposted: maxheight and maxheight:physical and that this was the reason for the introduction of maxheight:physical (I assume that maxwidth is working just the same). The width of a feature in my understanding is a physical limit. -1, the width is one dimension of a feature (depending on the kind of thing you are describing, there are other dimensions like height, length, diameter, depth, etc.), I wouldn't call this (in all cases) a limit So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). if there was something tagged like (example made up): barrier=bollard width=0.2m maxwidth=1.2m I'd expect the width to be the width of the bollard and maxwidth the (in theory legal) width of the vehicle that can pass through (e.g. number taken by reading off a sign) and you might want to add maxwidth:physical=1.22m (the actual maximum width of a vehicle or person that can pass through). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
2015-02-16 11:12 GMT+01:00 Martin Vonwald imagic@gmail.com: if there was something tagged like (example made up): barrier=bollard width=0.2m maxwidth=1.2m What about maxwidth:physical in this example? Like I wrote above: I'd expect the width to be the width of the bollard and maxwidth the (in theory legal) width of the vehicle that can pass through (e.g. number taken by reading off a sign) and you might want to add maxwidth:physical=1.22m (the actual maximum width of a vehicle or person that can pass through). If there were maxwidth=1.2 and maxwidth:physical=1.22 tagged (e.g.), I'd expect the 1.2 coming off a sign and the 1.22 being measured. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! 2015-02-16 11:16 GMT+01:00 Kytömaa Lauri lauri.kyto...@aalto.fi: The width of the vehicle that could use the way can be wider than the way itself, even if it depends on the conditions whether they're allowed to. For an example, a way in a park might be, say, 2 meters wide, but if there's just grass around it, a maintenance or construction vehicle or what ever could use that way even if all wheels don't fit on the intended surface (supposing the soil isn't too soft). Or a cycleway; the asphalt is 2.5 meters (width), but if there's no guard rail, a police van can use it even if they're wider than that (with mirrors included) - but if there's a guard rail on one side and a hedge on the other side, the physical maximum width could be just 2.6 meters (numbers off the top of my head.) Another likely case is when the width of a gate is, say, 3 meters (the whole structure), but the gap between the sides is only 2 meters: width=3 + maxwidth:physical=2 Less likely cases could be a road with trees next to it, such that the road is 6 meters wide, but for a section the branches limit the physical width usable for vehicles to, for example, 4 meters. Or a divider on the pedestrian crossing limits the physical width of passing vehicles to x meters, yet the road is more than 2*x wide. I haven't looked up if the maximum legal width sign refers to the actual width (with mirrors etc) or to the width stated in the vehicle's registration documents. Nevertheless, a road with a width of 2.6 meters (e.g. a narrow old town alley or a courtyard entrance) may, or may not, physically allow a vehicle with a width of 2.55 m + mirrors to pass. Thanks for all the examples. It's true that good example photos would be a nice touch to the documentation. That was the original intention of my question ;-) Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
2015-02-16 11:18 GMT+01:00 Janko Mihelić jan...@gmail.com: Maybe If you read a documentation and afterwards you maybe know what it means, the documentation might need some kind of improvement. ;-) I think we got enough good examples in this thread. Anyone willing to update the wiki? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Bus route relations. Forward/backward tag
There are still cases where forward/backward are useful with P2-routes. E.g. a route with a loop and some members used twice but different directions. Personally, I still use forward/backward on any member of a route which is only used in one direction and for all P2-routes as it makes it much easier to get the direction of the route with incomplete data. cu fly Am 16.02.2015 um 08:40 schrieb Jo: On the one hand I'm not adding roles to the ways in PT routes relations anymore, instead I add all the ways in the correct order. Some ways are included twice. But if you prefer to add them, you have to know forward/backward relates to the direction of the way itself. If it follows the arrow: forward, if it goes against it: backward. If you do it right, JOSM is able to sort your ways automatically. If you're still on the v1 scheme, where there is only one route relations doing a futile attempt to describe all variations, I suggest you switch to the new scheme where a route_master describes the line and route relations describe each variation from beginning to end. This is how we do it in Belgium: http://www.openstreetmap.org/user/Polyglot/diary/28401 There are some links to Youtube videos included in that article. 2015-02-16 5:52 GMT+01:00 Hans De Kryger hans.dekryge...@gmail.com: Me and a fellow mapper are adding bus routes to are city and are confused about the Forward/backward tag you use on relations. I think I'm using it right yet every time i check ÖPNVKarte, it shows the route going the opposite way in which i intended. Just looking for any help i can get. I'm quite confused on the usage of the tag especially the use of it on a two way street. Which way is forward and which way is backward. Thanks in advance. ÖPNVKarte - ( http://xn--pnvkarte-m4a.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
