[Tagging] relation type for raceways
as i go forward mapping raceways in north america, one of the issues is modeling multi configuration courses such as Watkins Glen and Lime Rock. one solution is to use route relations, and add a new route type, route=raceway in this model, i would use forward and backward roles where necessary. right now the best example of this i have is of my model of the Thompson road courses over the years at Thompson Speedway in Connecticut, which is in OHM. some sections of the raceway were used in different directions in different variations of the course, hence the need for forward backward. also, it would be useful to have ref tags or some equivalent id tag on the relations to facilitate querying, e.g. WGI1 for the first Glen circuit, WGI2 for the second, and perhaps suffixes for the multiple configurations of WGI4 (WGI4.Short, WGI4.Long, WGI4.Short.InnerLoop, WGI4.Long.InnerLoop or something like that.) this isn't really a formal proposal right now, i'm just looking for input/suggestions on how to approach this, and to see if anyone has thought about this and maybe has better ideas. thanks, richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search signature.asc Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Resubmitted proposal: mechanically removing all denotation=cluster and fixme=set_better_denotation tags worldwide
The mechanical edit has completed. If you have a favorite landmark tree in your area, consider checking the tagging. A number of those were tagged denotation=cluster and historic=yes, tags with essentially opposite meaning. Minor cleanup remains, along with oddities: http://www.openstreetmap.org/way/247452828 and http://www.openstreetmap.org/way/264900753 and http://www.openstreetmap.org/node/774726428 (a broad-leaved shop) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deleting private objects in private spaces
On 17/03/2015 10:46 AM, Bryce Nesbitt wrote: Please do not map private objects in private space. In general if the object could create a privacy concern, or is just not useful to a member of the public, please don't add it to the database. Note it is fully OK to map facilities within membership or fee based venues, as long as the facilities are reasonably available to members of the public. *Examples not to map*: toilets in homes, employee only toilets in businesses, private recycling bins, playgrounds in private homes or day care facilities. *Examples to map: *toilets inside DisneyLand, buildings visible from air photos, private facilities with a history of public permissive use. If OSM encourages others to use the OSM data base.. why cannot they add data that is 'private' to them? If renderers were not to render any access=private object then the general public would not be aware of these 'private' objects and those who want them may enter them and configure there own render to show 'their' data alongside OSM data. One idea is to only map stuff that is 'publicly viewable'. Some define this as 'from a public place' such as a street. However with satellite views being publicly available then mapping things that are not viewable from a public street becomes possible with more accuracy than that of a visual estimation from a public street. I think that mapping stuff that is not usefull, in some way, is a waste of time, public stuff or private stuff. If a person with authority wants to map private stuff .. then I think that is OK. The key is the authority. And then the definition of 'private' is? Are Universities 'private'? Are bicycle repair stations inside university grounds private? Are private swimming pools in backyards to be mapped as they may be used in an emergency to fight fires? The boundaries between private and public are grey ... and then their is community emergency use. Murky waters. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tagging earthquake vulnerabilities of buildings: Developing world
Near Kathmandu, there's a series of tags relating to surveys of quake status of buildings. Would someone be interested in helping working out a proper tag scheme, and proposing it to whatever groups are doing this data collection? aware=abit aware=dont_know bldg_eq_Res=Dont Know bldg_eq_res=no bldg_eq_res=yes bldg_slope_land=no boat=no building:overhang=no building:soft_storey=no building:structure=load_bearing_brick_wall_in_cement_mortar building:structure=load_bearing_brick_wall_in_mud_mortar building:use=Bihar building:use=educational building:use=Factory building:use=GO/NGO/INGO building:use=Guthi building:use=Mixed building:use=Others building:use=Public service building:use=residental building:use=School Cantilever=No Cantilever=yes Cantilever=Yes CONS_TYPE=RBC CONS_TYPE=RCC D/P awarness=yes DP-E/Q resistance=yes Dp-)pen space=No D/P risk zone=No D/P - safe place=No DP-toolkit=No Earthquake Resistance=Yes Earthquake_Resistant_Bldg=May be Emergency_toolkit=no Emergency_toolkit=No Emergency_Toolkit=No emergency=yes Engin_Noneng=Engineered Engin_Noneng=Noneng Engin_Noneng=Non-Eng Engin_Noneng=Non Engineered Engin_Noneng=Owner_Built E/Q Resistance=May be EQ_RESISTANT=no Expansion joint for building 30 m long=No Expansion Joint for building 30m long=No ExpansionJoint=no ExpansionJoint=No flood/landslide_risk=no Flood/landslide_risk=no Flood/Landslide_risk Zone=No Flood/Landslide_Riskzone=No FLOOD_RISK=no Front Road=8m Ground_Settlement=No G_SETTLEMENT=no H_CANTILEVER=no Heavy overhang and cantilever=No Heavy Overhangs and Cantilever=No heavy_overhangs=no Heavy_overhangs=no Heavy_overhangs=No Heavy_Overhangs=Yes House No=31 HOUSE_NO=38 House_No=61 House_No=797 House_No.=96 House_type=Row Housing House_type=Row_Housing Housing Type=Row Housing H/w no=20 Identification_Safe Places=No MASS_ON_ROOF=no NO_OF_STOR=2 opening_hours=ujjwal's time (5-7pm) Open_space=yes Open_space=Yes Open Space=Yes *Owner*=Ajaya Kumar Sherstha Physical_condition=Good Physical_condition=Poor Physical_condition=Satisfactory Ponding Possibility=No Ponding=Yes Pounding_Possibility=No Pounding_Possibility=Yes Pounding_Poss=yes Pounding_Poss=Yes Poundings Possibility=Yes poundings=yes Poundings=yes Poundings=Yes POUNDING=yes REMARK=Underconstruction Risk Zone=No Rooftoptank=No Rooftoptank=yes Rooftoptank=Yes Roof top water tank , heavy machinery or other large mass=yes Roof top Water Tank, heavy machinery or other large mass=Yes rooftop_water_tank=no Rooftop_ Watertank=No rooftop_water_tank=yes Roof_top_watertank=yes Rooftop_water_tank=yes Rooftopwatertank=Yes Rooftop_ Watertank=Yes ROOF_TYPE=Rcc slab ROOF_TYPE=Weak Tile Safe_place=yes Safe place=Yes Safe Place=Yes SAFEPLACE=yes seismic_resistance=no Settlement=No Shape in elevation=Regular Shape of building in plan=Rectangular *Short_coloumn=no* *short column=no* *short_column=no* *Short_column=no* *Short_Column=no* *Short Column=No* *Short_Column=No* *ShortColumn=No* *SHORT_COLUMN=no* *short column=yes* *Short_column=Yes* *ShortColumn=yes* *Short Column=Yes* *Short_Column=Yes* *ShortColumn=Yes* SLOPE_LAND=no Sloping=No *soft/weak storey=No* *soft:weakStorey=no* *Soft/Weak Storey=No* *soft/weak _storey=yes* *soft/weak_storey=yes* *soft:weakStorey=Yes* *Soft/weak Storey=Yes* *Soft/Weak_storey=yes* *Soft/Weak_Storey=yes* *Soft/Weak_Storey=Yes* *Soft/weak_story=no* sorey=3 Sufficient_Openspace=No Sufficient_Openspace=Yes Sufficient_Openspace=Yes(Araniko_highway) SUF_OPEN_SPACE=yes SW_STOREY=no Tole=Chadani Chowk Tole_Name=Bakhu Tole tole_name=chandanichowk Tole_Name=Chandanichowk TOOLKIT=no Types of Cracks=No Cracks USE=Residental V/F - cantilever=No V/F - ponding=No V/F - settlement=No V/F - short column=No V/F - sloping=No VF_Softstorey=No V/F soft weak storey=No V/F -water tank=Yes Visible_grd_settlement=no Visible_grd_settlement=No visible_grd_settlement=yes Visible_grd_settlement=yes visible ground settlement=No Visible_GroundSettlemt=no Visible_GroundSettlemt=No Visible_GroundSettlemt=NO Visible Physical Condition of the building=Good Visisble Ground Settlement=No vulnerability=yes Vulnerability=Yes *ward_no=08* *Wardno=08* *Ward_No=08* *ward no=10* *ward no=8* *WardNo=8* *WARD_NO=8* The intent is great, the execution... um... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
For boat navigation purposes this should be crosslinked: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Gates Isn't it the other way around? That is, the people who tagged seagate:category:gate=lock (24 objects) should be making sure to also tag waterway=lock_gate (15K objects), not vice versa. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
On Mon, Mar 16, 2015 at 11:31 AM, Warin 61sundow...@gmail.com wrote: Approval and rejection at the moment are only tagging group indicators.. the best 'indicator' is that it is rendered. And that is not a function of JOSM nor iD .. but the renderers .. there are a few of them .. if they all render some OSM object then that tag has 'made it'. I think the 'approval' and 'rejection' should stay where it is .. it is not the be all and end all of a tag. -1, Think about the surface, the turn:lanes, destination or 3D buildings keys. They are not rendered on all few renderers. Still they are important enough to keep (just assume they just past your approval process), as some navigation software will rely on them or specialized maps. I don't think being rendered on all renderers is a proper decision criteria. regards m ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-15 17:58 GMT+01:00 Kytömaa Lauri lauri.kyto...@aalto.fi: So far, nobody has proposed what I have come to think would be the most exact and most usable bit of information a _mapper_ can provide: Did you get through with transport mode x? Possible answers are: - no - just barely - with extra effort/concentration/some difficulty - yes while I believe this is a working approach, I think it should be (in some cases that come to mind) more granual spatially: often ways tend to be not uniform but have changing surface and other characteristics along the way, so I would split the way into smaller parts with common attributes / properties. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] waterway=lock_gate - is it only for nodes?
According to wiki[1] waterway=lock_gate should be used only on nodes. Some are tagged on ways[2]. Why wiki considers node as the only valid element where this tag may be used? Is it because page is older than mapping rivers also as areas? Routing for boats? Some other reason? Is it a good idea to change wiki and mark tagging on nodes as a good idea? Is it a good idea to promote tagging also on ways[3]? [1] http://wiki.openstreetmap.org/wiki/Tag:waterway=lock%20gate [2] http://taginfo.openstreetmap.org/tags/waterway=lock_gate [3] https://github.com/gravitystorm/openstreetmap-carto/pull/991 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
This is something worth considering IMO. We can't seem to come to an agreement on which system to use, numeric or descriptive, and perhaps part of the problem is the difficulty in deciding exactly which grade to pick. Maybe having fewer choices would result in more agreement and make the tag easier to use. On Mon, Mar 16, 2015 at 4:28 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-15 17:58 GMT+01:00 Kytömaa Lauri lauri.kyto...@aalto.fi: So far, nobody has proposed what I have come to think would be the most exact and most usable bit of information a _mapper_ can provide: Did you get through with transport mode x? Possible answers are: - no - just barely - with extra effort/concentration/some difficulty - yes while I believe this is a working approach, I think it should be (in some cases that come to mind) more granual spatially: often ways tend to be not uniform but have changing surface and other characteristics along the way, so I would split the way into smaller parts with common attributes / properties. Cheers, Martin ___ 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] waterway=lock_gate - is it only for nodes?
2015-03-16 10:53 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: According to wiki[1] waterway=lock_gate should be used only on nodes. Some are tagged on ways[2]. Why wiki considers node as the only valid element where this tag may be used? Is it because page is older than mapping rivers also as areas? Routing for boats? Some other reason? Is it a good idea to change wiki and mark tagging on nodes as a good idea? Is it a good idea to promote tagging also on ways[3]? I think both, nodes and ways are valid approaches, and indeed, if the waterway is mapped as an area, a way for the lock gate might be the better representation. If the wiki should get amended, it should be pointed out, that the way for the lock gate should be orthogonal to the waterway and not in the same direction (i.e. the lock gate should be mapped with this tag and not the area inside the lock). Not sure about doing both: we do it for waterways mapped as an area (there is an area and there is a center line for the waterway). Doing both will add redundancy but will be easier to evaluate (consumers will less likely miss the feature). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
2015-03-16 11:55 GMT+01:00 Marc Gemis marc.ge...@gmail.com: I don't think being rendered on all renderers is a proper decision criteria +1, the list of tags mostly not rendered but well established is long: opening_hours wikipedia start_date operator (population) (is actually taken into account when rendering) turn_restrictions routes (well, some renderers do show them, but osm carto doesn't) description inscription note website phone url ... plus all other keys that don't even get imported into most of the rendering databases. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
On 16/03/2015 7:11 PM, Friedrich Volkmann wrote: On 14.03.2015 21:27, Clifford Snow wrote: I would suggest adopting Conditional Approval approach. If the proposal receives sufficient votes, it becomes Conditionally Approved. Only after it becomes widespread and adopted by JOSM and iD it becomes an Approved tag. No. Editor developers aleady have too much power. Editor support often depends on the mood of one single person. I would rather say that, for a given number of occurrences, editor support should be considered a counter indicator for approval. When usage spreads in spite of no editor support, that means that mappers choose the tag on purpose. When usage remains intermediate in spite of editor support, that means that mappers use the tag only because it is imposed by the editor. Mappers don't use a tag .. even ones 'suggested' by an editor unless they 'fit'. Beginner mappers, like me, use the wiki in searching for a suitable tag, it aids understanding. They don't rely on the editor to find suitable tags as it does not provide enough information. If the wiki description is a poor match but no other tag is found you may find that tag is used or the data is not entered. Few beginner mappers will make a new tag. They may make a node with a note.. but that is about it. Approval and rejection at the moment are only tagging group indicators.. the best 'indicator' is that it is rendered. And that is not a function of JOSM nor iD .. but the renderers .. there are a few of them .. if they all render some OSM object then that tag has 'made it'. I think the 'approval' and 'rejection' should stay where it is .. it is not the be all and end all of a tag. As for increasing the 'approval' vote to a minimum of 10 with 75% .. ok .. as long as there is a time limit on the minimum number of 10, at the end of, say 6 weeks, the number requirement needs to be dropped altogether. This would encourage people to vote as after 6 weeks their lack of voting does not matter. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Mon, Mar 16, 2015 at 10:53:21AM +0100, Mateusz Konieczny wrote: According to wiki[1] waterway=lock_gate should be used only on nodes. Some are tagged on ways[2]. Why wiki considers node as the only valid element where this tag may be used? Is it because page is older than mapping rivers also as areas? Routing for boats? Some other reason? Is it a good idea to change wiki and mark tagging on nodes as a good idea? Is it a good idea to promote tagging also on ways[3]? I think it makes sense to tag them as ways, analogous to weirs and dams. For boat navigation purposes this should be crosslinked: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Gates Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On 16/03/2015 10:37, Richard Z. wrote: I think it makes sense to tag them as ways, analogous to weirs and dams. +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On Mon, Mar 16, 2015 at 3:14 AM, Dave Swarthout daveswarth...@gmail.com wrote: On the other hand, these features are actually a linear barrier with a finite length that extend across a channel or canal. It makes sense to allow tagging them as ways as well as nodes. If you're a router following a way, having the node marked makes the job easier. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
On 16/03/2015 16:35, Bryce Nesbitt wrote: If you're a router following a way, having the node marked makes the job easier. Is that not tagging for an app? A similar case is bridges. Here the bridge tag could be on a segment of the way over the bridge, the way under the bridge, a node on either or and area round the bridge structure. Any of these may carry attributes such as weight limit, headroom, etc. A smart routing app ought to be able to work with any of these cases, using the headroom for a route that passes under the weight limit for routes that pass over. This is the same for lock gates, which is a similar class of object - the waterway passes through (when open) and footways, etc pass over the gate (when closed). Wherever the tags are placed, any consumer app should be able to cope. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Deleting private objects in private spaces
so the driveways are bad, but the powerlines are good? Aren’t the driveways in a substation part of the stubsation, just like like all the other detail that is recorded for the powerline system or fence for the substation? I am against rendering.. umm.. “distribution” lines, but if mapping them is your thing, then go ahead. the power lines, especially the transmission lines, are totally, utterly private , off-limits, and lethal. And mapped. The driveway seems to be much less… dangerous or clutter inducing. Unless it is lawfully off-limits (AKA military installations in certain countries) or behind private doors, then anything is mappable. It may not be good to map it, but it is mappable. Just like the trees or the tracks around the substation. Once we start doing indoor mapping, then the same thing will apply as well - the examples listed below are for private spaces inside a building, and those “backroom” or “private” spaces of homes and publicly accessible buildings will have to be unmapped in some way. The mapping notes below sound good. However even indoors, the paths connecting to fire escapes, hoses, and other safety items in public accessible buildings should be mapped, even if they go through a private loading dock or hallway, maybe. just another case where mapping a private path might be a good idea even in the future for indoor stuff. some kind of exception for safety or somewhat visible to the public - especially if it is part of the road network. Deleting a driveway seems a bit too much. Javbw On Mar 17, 2015, at 8:46 AM, Bryce Nesbitt bry...@obviously.com wrote: I almost, but not quite, pressed delete on these: https://www.openstreetmap.org/way/272142910/history https://www.openstreetmap.org/way/272142910/history https://www.openstreetmap.org/way/272142911/history https://www.openstreetmap.org/way/272142911/history They're private objects within a private gated electrical substation. Similar to toilets inside people's homes, it feels like these should not be mapped. Scattering access=private tags on the dumpsters and enclosing ways feels like a hack. The dividing line set by the community remains murky. How about: Please do not map private objects in private space. In general if the object could create a privacy concern, or is just not useful to a member of the public, please don't add it to the database. Note it is fully OK to map facilities within membership or fee based venues, as long as the facilities are reasonably available to members of the public. Examples not to map: toilets in homes, employee only toilets in businesses, private recycling bins, playgrounds in private homes or day care facilities. Examples to map: toilets inside DisneyLand, buildings visible from air photos, private facilities with a history of public permissive use. ___ 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] Accepted or rejected?
On 16/03/2015 10:05 PM, Martin Koppenhoefer wrote: 2015-03-16 11:55 GMT+01:00 Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com: I don't think being rendered on all renderers is a proper decision criteria +1, the list of tags mostly not rendered but well established is long: opening_hours (used by some renderers into GPS 'maps' such as OSMAnd) wikipedia start_date operator (population) (is actually taken into account when rendering) turn_restrictions (used by at least some routers on GPS 'maps') routes (well, some renderers do show them, but osm carto doesn't) (Rendered by some as you say) description inscription note (not rendered .. for use by mappers to make notes to other mappers ? thus not required to be rendered?) website phone url ... plus all other keys that don't even get imported into most of the rendering databases. cheers, Martin I think most, if not all, of the tags you list .. I'm not using... other than the ones I've made notes on... while they may be long established they may not be used by new mappers and thus be less populated than they could be. Hard to measure, but that is my take on it. I think there are keys that could be rendered that simply miss out because they are not frequently used or are not present as a tag option. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Deleting private objects in private spaces
I almost, but not quite, pressed delete on these: https://www.openstreetmap.org/way/272142910/history https://www.openstreetmap.org/way/272142911/history They're private objects within a private gated electrical substation. Similar to toilets inside people's homes, it feels like these should not be mapped. Scattering access=private tags on the dumpsters and enclosing ways feels like a hack. The dividing line set by the community remains murky. How about: Please do not map private objects in private space. In general if the object could create a privacy concern, or is just not useful to a member of the public, please don't add it to the database. Note it is fully OK to map facilities within membership or fee based venues, as long as the facilities are reasonably available to members of the public. *Examples not to map*: toilets in homes, employee only toilets in businesses, private recycling bins, playgrounds in private homes or day care facilities. *Examples to map: *toilets inside DisneyLand, buildings visible from air photos, private facilities with a history of public permissive use. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On Mar 16, 2015, at 2:49 PM, Warin 61sundow...@gmail.com wrote: On 16/03/2015 2:27 PM, johnw wrote: These obvious receptions are not crucial to be mapped, but receptions in business parks, large office complexes, individual companies’ large business campuses, etc are important, and this is what it is for. (I think) Javbw Obvious things are not critical to be mapped. ? Umm well .. I'd not put it that way … Sorry, I said it in a bad way. the “obvious” reception desks I was speaking of smack you in the face - the ones I was thinking of are like, the elevator doors open, and there is a reception desk in your face for the 11th floor “Baka, Inc” office. There is no possible path to follow except through reception, so it is “obvious” because there is no way to access the location without going through it. But of course I would want any reception mapped if you can, and eventually if you are doing indoor multi-floor mapping, mapping these as well in the future (which I don’t think is possible now?). “We” are in agreement on the rest. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Taginfo challenge
I don't know about this specific case, but if a key /by definition/ can be used only in places where language X is spoken, then I think it would make sense to have them in language X I know at least one tag that works like that: http://wiki.openstreetmap.org/wiki/Key:py%C3%B6r%C3%A4_v%C3%A4ist%C3%A4%C3%A4_aina_autoa -- View this message in context: http://gis.19327.n5.nabble.com/Re-OSM-talk-Taginfo-challenge-tp5837149p5837425.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] waterway=lock_gate - is it only for nodes?
I'm embarrassed to admit I have tagged 82 of those features as ways here in Thailand. I guess I simply never thought to look at the Wiki because it seemed so obvious to me that most lock_gates cross the waterway. These features are not rendered on any OSM map I've seen so my mistakes never came to light until just now. On the other hand, these features are actually a linear barrier with a finite length that extend across a channel or canal. It makes sense to allow tagging them as ways as well as nodes. On Mon, Mar 16, 2015 at 5:02 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-16 10:53 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: According to wiki[1] waterway=lock_gate should be used only on nodes. Some are tagged on ways[2]. Why wiki considers node as the only valid element where this tag may be used? Is it because page is older than mapping rivers also as areas? Routing for boats? Some other reason? Is it a good idea to change wiki and mark tagging on nodes as a good idea? Is it a good idea to promote tagging also on ways[3]? I think both, nodes and ways are valid approaches, and indeed, if the waterway is mapped as an area, a way for the lock gate might be the better representation. If the wiki should get amended, it should be pointed out, that the way for the lock gate should be orthogonal to the waterway and not in the same direction (i.e. the lock gate should be mapped with this tag and not the area inside the lock). Not sure about doing both: we do it for waterways mapped as an area (there is an area and there is a center line for the waterway). Doing both will add redundancy but will be easier to evaluate (consumers will less likely miss the feature). Cheers, Martin ___ 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] Accepted or rejected?
On 14.03.2015 21:11, Bryce Nesbitt wrote: On Sat, Mar 14, 2015 at 12:13 PM, Kotya Karapetyan kotya.li...@gmail.com mailto:kotya.li...@gmail.com wrote: Proposal: let's change it to 8 unanimous approval votes or 10 or more votes with at least 74 % approval ones? +1 on that. Anything without a super-majority clearly needs more discussion and/or experience. In that case, we shouldn't mark it as rejected, but rather as something like not proven. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Accepted or rejected?
On 14.03.2015 21:27, Clifford Snow wrote: I would suggest adopting Conditional Approval approach. If the proposal receives sufficient votes, it becomes Conditionally Approved. Only after it becomes widespread and adopted by JOSM and iD it becomes an Approved tag. No. Editor developers aleady have too much power. Editor support often depends on the mood of one single person. I would rather say that, for a given number of occurrences, editor support should be considered a counter indicator for approval. When usage spreads in spite of no editor support, that means that mappers choose the tag on purpose. When usage remains intermediate in spite of editor support, that means that mappers use the tag only because it is imposed by the editor. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
