Re: [Tagging] Feature proposal - Street cabinet - Voting
I was going to suggest Waste Transfer station http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_transfer_station But after reading the wiki for it, it was not at all what I expected. In America, at least in most suburban areas, waste is collected from individual residences via bins/cans on the street with(enormous) trucks, so there is no static transfer points whatsoever, it goes from curb to landfill directly. In Japan, There are static waste collection Garbage stations [ゴミ ステーション] per street or area, and are often large, steel, screened cages that are stuffed full of 45 liter bags. There is no possible way fro a truck to service the myriad of little tiny buildings, some of them only on walking paths - even in cities of 100K people, so there is a garbage station for every 20-30 houses or so, or one for a large apartment or company. Temporary ones are merely nets to keep the crows off the bags, but most are permanent ones worth mapping. My local garbage station (2 cabinets) http://goo.gl/maps/VLgMP a full one nearby http://goo.gl/maps/eqVS3 although some are old and look disused, they are used daily or weekly by the populace, and mapping them would be useful on a very local level (like the cabinets in general). Please add a line item for waste transfer, similar to the postal transfer - this is a missing step in the garbage collection, and a cabinet that have been overlooked. Also, I suggest also adding sliding for the door hinge option (as the second one has no hinges) Javbw On Oct 31, 2014, at 6:08 AM, Tom Pfeifer t.pfei...@computer.org wrote: François Lacombe wrote on 2014-10-30 21:42: I would suggest street_cabinet=garbage for the equipment you've mentioned. maybe =waste is more consistent with existing tags such as amenity=waste disposal, amenity=waste basket or generator:source=waste Garbage is less used in tags so far. A cabinet is a feature where workers can't enter. A building is the opposite. Then, substations and other stuff can be divided between those two sorts. That's a very plausible distinction and should be documented. tom ___ 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 - Street cabinet - Voting
2014-10-31 7:00 GMT+01:00 johnw jo...@mac.com: I was going to suggest Waste Transfer station http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_transfer_station But after reading the wiki for it, it was not at all what I expected. The containers in your photos would IMHO qualify for street cabinet. A waste transfer station I would expect to be some biggish plant where trucks unload the waste, and where eventually recyclable ressources like metal are removed before it goes to the landfill / waste incinerating plant. something like this: https://www.stadt-werther.de/typo3temp/pics/84cad4e180.jpg http://in1.bilderbuch-koeln.de/bilder/k%C3%B6ln_ehrenfeld_entleeren_eines_m%C3%BCllwagens_awb_m%C3%BCllwagen_29fa427248_600x450xcr.jpeg this is (or was) a plant from the 80ies for sorting waste into different fractions of reusable material, it started as a pilot project but is unused for more than 20 years now because the federal government was pursuing a different strategy how to deal with waste then (they let citizens sort the waste beforehand and collect it already seperated rather than collecting a mixture and do the sorting in the plant): http://www.tagblatt.de/cms_media/module_bi/279/139768_0_org_640_434_18012_.jpg cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Street cabinet - Voting
I would distinguish between an amenity=waste_* for structures that are open for everybody to bring their waste, with or without fee, thus as a POI somebody would navigate to (where can I bring my waste), and the cabinet=waste merely describing the street inventory (what is that odd locked box for). johnw wrote on 2014-10-31 07:00: I was going to suggest Waste Transfer station http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_transfer_station But after reading the wiki for it, it was not at all what I expected. In America, at least in most suburban areas, waste is collected from individual residences via bins/cans on the street with(enormous) trucks, so there is no static transfer points whatsoever, it goes from curb to landfill directly. In Japan, There are static waste collection Garbage stations [ゴミ ステーション] per street or area, and are often large, steel, screened cages that are stuffed full of 45 liter bags. There is no possible way fro a truck to service the myriad of little tiny buildings, some of them only on walking paths - even in cities of 100K people, so there is a garbage station for every 20-30 houses or so, or one for a large apartment or company. Temporary ones are merely nets to keep the crows off the bags, but most are permanent ones worth mapping. My local garbage station (2 cabinets) http://goo.gl/maps/VLgMP a full one nearby http://goo.gl/maps/eqVS3 although some are old and look disused, they are used daily or weekly by the populace, and mapping them would be useful on a very local level (like the cabinets in general). Please add a line item for waste transfer, similar to the postal transfer - this is a missing step in the garbage collection, and a cabinet that have been overlooked. Also, I suggest also adding sliding for the door hinge option (as the second one has no hinges) Javbw On Oct 31, 2014, at 6:08 AM, Tom Pfeifer wrote: François Lacombe wrote on 2014-10-30 21:42: I would suggest street_cabinet=garbage for the equipment you've mentioned. maybe =waste is more consistent with existing tags such as amenity=waste disposal, amenity=waste basket or generator:source=waste Garbage is less used in tags so far. A cabinet is a feature where workers can't enter. A building is the opposite. Then, substations and other stuff can be divided between those two sorts. That's a very plausible distinction and should be documented. tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane
Hallo, I have a quick question. How should I proceed with a voting that is a tie? Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane
On 31 October 2014 12:02, Hubert sg.fo...@gmx.de wrote: I have a quick question. How should I proceed with a voting that is a tie? In my opinion, tags need to be approved by a majority approval, and a tie is not a majority. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane
On 31/10/2014 12:02, Hubert wrote: Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane Ihave a quick question.Howshould I proceed with a voting that is a tie? Invoke the spirit of Groucho Marx? http://www.youtube.com/watch?v=e7cry-4pyy8 :-) Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane
Hi Hubert First of all I big compliment for bringing up the issue and tying to work towards a solution. If I look at the voting I see quite a few that would approve if it would be tagged with a sub-tag. My guess is that most voters that approved will also approve if the sub-tag would be proposed. So maybe you should propose with a sub tag and have a new vote. Cheers PeeWee32 2014-10-31 13:45 GMT+01:00 SomeoneElse li...@mail.atownsend.org.uk: On 31/10/2014 12:02, Hubert wrote: I have a quick question. How should I proceed with a voting that is a tie? Invoke the spirit of Groucho Marx? http://www.youtube.com/watch?v=e7cry-4pyy8 :-) Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Verbeter de wereld. Word mapper voor Openstreetmap http://www.openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - cycleway=soft_lane
@ Matthijs: Not a tie anymore :-(. Clean up of the proposal page is in progress. @ Andy: That made me smile. Thank you. @ Peewee: I'll probably do that. See new discussion thread. Thank you all for your support. Even if you voted against the proposal, it is still helpful. Best regards Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] sub key for cycle ways
Hallo, since a new main value for UK:advisary cyclelane, DE:Schutzstreifen, A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable conseillée et réservée, CZ:cyklistický jízdní pruh didnt get approved, Im thinking of introducing a sub key for that. (Like many of you already suggested.) As a start Im thinking of cycleway=lane + lane=soft_lane for that purpose. However just a key for that one occasion doesnt seem logical, so a set of keys defining different types of on lane/on road surface cycle infrastructure should be developed, to keep the tagging consistent or to create a structured concept. In order to do that, Im thinking of introducing lane=strict_lane, soft_lane, suggestive_lane for lane like cycle ways where bicycles are encouraged to stay on one side of the road and shared_lane=sharrows, pictogram, busway for roads/lanes where bicyclists are not separated from other traffic. The in my opinion the main problems in that idea are the use of lane=suggestive_lane and shared_lane= busway. lane=suggestive_lane because it is in contrast of the current tagging as cycleway=shared_lane in the Netherlands. At least as far as I can remember. Im also not sure whether smurf lanes in the UK are tagged as cycleway=shared_lane. shared_lane= busway since this is currently tagged as cycleway=share_ busway. I think that in favor of structure, shared_lane= busway should be allowed. However, I havent made up my mind about that yet, or whether cycleway=share_ busway should be deprecated or just be discouraged. This would leave cycleway=track, lane, shared_lane, opposite_track, opposite_lane, opposite as the main values, lane=strict_lane, soft_lane, suggestive_lane and shared_lane=sharrows, pictogram, busway. Not part of the sub key discussion: As an addition one could say that a cycleway=track is also a lane like cycle infrastructure, which would make it a lane=track sub key. Also any cycleway=opposite(_*) could be represented by, for example, highway=* + oneway=yes + oneway:bicycle=no + cycleway=right/left/both cycleway:right/left =lane + cycleway:right/left:oneway= yes/-1 (assuming right hand traffic) What are your thoughts on this tagging scheme? Im sorry, if this is a bit confusing. Its late but I just couldnt wait writing. Best regard Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sub key for cycle ways
Can we move towards using the lanes tagging used for every other mode already? It's much more precise and can deal with situations like where the bike lane is not the extreme left/right lane. On Fri, Oct 31, 2014 at 7:43 PM, Hubert sg.fo...@gmx.de wrote: Hallo, since a new main value for UK:advisary cyclelane, DE:Schutzstreifen, A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get approved, I’m thinking of introducing a sub key for that. (Like many of you already suggested.) As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that purpose. However just a key for that one occasion doesn’t seem logical, so a set of keys defining different types of “on lane”/”on road surface” cycle infrastructure should be developed, to keep the tagging consistent or to create a structured concept. In order to do that, I’m thinking of introducing “lane=strict_lane, soft_lane, suggestive_lane” for lane like cycle ways where bicycles are ‘ encouraged’ to stay on one side of the road and “shared_lane=sharrows, pictogram, busway” for roads/lanes where bicyclists are not separated from other traffic. The in my opinion the main problems in that idea are the use of “lane= suggestive_lane” and “shared_lane= busway. “lane=suggestive_lane” because it is in contrast of the current tagging as “cycleway=shared_lane” in the Netherlands. At least as far as I can remember. I’m also not sure whether “smurf lanes” in the UK are tagged as “cycleway=shared_lane”. “shared_lane= busway” since this is currently tagged as “cycleway=share_ busway”. I think that in favor of structure, “shared_lane= busway” should be allowed. However, I haven’t made up my mind about that yet, or whether “cycleway=share_ busway” should be deprecated or just be discouraged. This would leave “cycleway=track, lane, shared_lane, opposite_track, opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane, suggestive_lane” and “shared_lane=sharrows, pictogram, busway”. Not part of the sub key discussion: As an addition one could say that a “cycleway=track” is also a lane like cycle infrastructure, which would make it a “lane=track” sub key. Also any “cycleway=opposite(_*)” could be represented by, for example, “highway=* + oneway=yes + oneway:bicycle=no + cycleway=right/left/both cycleway:right/left =lane + cycleway:right/left:oneway= yes/-1” (assuming right hand traffic) What are your thoughts on this tagging scheme? I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait writing. Best regard Hubert ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
