Re: [Tagging] Feature proposal - Street cabinet - Voting

[François Lacombe]

Hi there,

The vote process of the street cabinet mapping proposal has been closed
yesterday evening.
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_cabinet

27 users said yes against 1 no, this proposal is accepted :)
Thank you to everyone who gave feedbacks on vote and talk page.


Nevertheless, user verdy_p - who didn't make any contribution to Talk:
since RFC start - has edited the document last night as for commenting tags
usefulness.
We can't accept such methods which ruins any common efforts to get a
consensus.
I strongly encourage any responsible person of the proposal/vote process to
explain it to Verdy_p please.

I personnaly find some interest in man_made=technical_cabinet instead of
man_made=street_cabinet
The "street" term is certainly restrictive when such cabinet can be found
far from streets.

man_made=street_cabinet should be documented as expected regarding the vote
but we also should deal with mistakes before widely use keys.
I'm really puzzled and sorry regarding this particular point.


Best regards


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

2014-11-02 13:23 GMT+01:00 Tom Pfeifer :

> Yes I agree, though making the definition more precise by adding the
> worker-can-enter criterion should be fine.
>
> Further examples for the street_cabinet=* vlues can be collected
> on the discussion page meanwhile.
>
> Marc Gemis wrote on 2014-11-01 23:30:
>
>> I wouldn't touch the page until the voting is over. One can always add
>> new values when the tag is in use and document them when needed. New
>> building types are also added all the time. No need to document it right
>> away.
>>
>> just my .5 cents
>>
>> m
>>
>> On Sat, Nov 1, 2014 at 11:05 PM, François Lacombe  wrote:
>>
>> Hi,
>>
>> I've already edited Rational paragraph to give a better description
>> with distinction between buildings where workers can enter.
>>
>> Secondly, ok for street_cabinet=waste (and maybe 
>> street_cabinet=waste_management
>> if cabinets are encountered with devices to manage waste transit or storage)
>>
>> man_made=street_cabinet isn't incompatible with amenity=waste_* and
>> street_cabinet=waste should concern anything regarding waste.
>>
>> I'm not so friendly with proposal editing while voting.
>> Nevertheless, with such extensive keys like street_cabinet=* I think
>> users won't mind if we document additional values.
>> Is everybody ok with it ?
>>
>> *François Lacombe*
>>
>> francois dot lacombe At telecom-bretagne dot eu
>> http://www.infos-reseaux.com
>>
>> 2014-11-01 11:04 GMT+01:00 johnw :
>>
>> Well, they re not open to the public - only the designated houses
>> in the area can use their station, not anyone else. You don’t use other
>> people’s stations. There is one closer to my house, but I’m not allowed to
>> use it, because the one pictred is
>> “ours”. it is regualrly maintained, on rotation, by the users of
>> it.
>>
>> These are not public garbage cans, they are a drop-off point
>> between specific customers and the garbage pickup.
>>
>> They are not completely private, like a mail transfer box, but
>> they are not public either.
>>
>> Javbw
>>
>>  > On Oct 31, 2014, at 7:01 PM, Tom Pfeifer wrote:
>>  >
>>  > 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

Re: [Tagging] governmental / public_administrative landuse are not commercial

[Pieren]

On Fri, Nov 14, 2014 at 5:03 AM, johnw  wrote:
> A couple more landuse cases were added. I’m going to ask now if it is a good
> idea to specifically exclude Police/fire/safety and give them their own
> landuse(s).

I don't think we need a civic subkey in landuse. When I see the
growing list, it will finally generate very small landuse polygons in
OSM. This is not the intend of the OSM "landuse". We put "tax",
"immigration" or "legislative" into the buildings where these services
are. Otherwise, it is endless. We could create a subkey for
"landuse=residential" with "residential=home" or "residential=garage"
or "residential=toilets_in_the_garden"

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] governmental / public_administrative landuse are not commercial

[johnw]

> On Nov 14, 2014, at 8:09 PM, Pieren  wrote:
> 
> On Fri, Nov 14, 2014 at 5:03 AM, johnw  wrote:
>> A couple more landuse cases were added. I’m going to ask now if it is a good
>> idea to specifically exclude Police/fire/safety and give them their own
>> landuse(s).

these are just use cases for when to use the generic landuse=civic. Still 
trying to figure out what to exclude or to make another landuse tag for.

> 
> I don't think we need a civic subkey in landuse. 

it is a subkey for the buildings, to go with building=civic. 

From the page:  
 it might be best to create a civic 
=*
 subtag that goes with building 
=civic 
 

wondering if is good to give some basic types of civic buildings through a 
subkey. 

Javbw___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] governmental / public_administrative landuse are not commercial

[Pieren]

On Fri, Nov 14, 2014 at 12:29 PM, johnw  wrote:

> it is a subkey for the buildings, to go with building=civic.

My concern is about splitting a landuse polygon just to refine
information that could be stored on buildings themselves for instance.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Pipeline Extensions

[Rainer Fügenstein]

I'd like to bring the following proposal to your attention:
https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension

it describes a set of tags in addition to the existing
man_made=pipeline and pipeline=marker tags.

thnx for your attention

best regards


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions

[fly]

Am 14.11.2014 um 16:08 schrieb Rainer Fügenstein:

Hey

> I'd like to bring the following proposal to your attention:
> https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension
> 
> it describes a set of tags in addition to the existing
> man_made=pipeline and pipeline=marker tags.
> 

After a quick look I have two small issues.

1. Please do use type (it should by used only for relations) but add
some works like medium_type or pipeline_type.

2. We already have support=* which is used with man_made=surveillance
and is much more in use than mount=*. Do we really need two almost
identical tags ?

Cheers
fly

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions

[fly]

Am 14.11.2014 um 16:43 schrieb fly:
> Am 14.11.2014 um 16:08 schrieb Rainer Fügenstein:
> 
> Hey
> 
>> I'd like to bring the following proposal to your attention:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension
>>
>> it describes a set of tags in addition to the existing
>> man_made=pipeline and pipeline=marker tags.
>>
> 
> After a quick look I have two small issues.
> 
> 1. Please do use type (it should by used only for relations) but add
> some works like medium_type or pipeline_type.

Bad typo, I meant:

Do **not** use type.

fly


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions

[Rainer Fügenstein]

hi,

f> 1. Please do [not] use type (it should by used only for relations) but add
f> some works like medium_type or pipeline_type.

"type" was largely in use at the time the proposal draft was started,
therefore I kept it, but I see the point of changing it.
"pipeline_type" rather implies what's now proposed as "network",
something with "medium" is more appropriate.

I wonder if it may just be "medium=*"?

f> 2. We already have support=* which is used with man_made=surveillance
f> and is much more in use than mount=*. Do we really need two almost
f> identical tags ?

I agree with you on that. any chance to list it on the
man_made=surveillance wiki page?

cu


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Pipeline Extensions

[Holger Jeromin]

Rainer Fügenstein wrote on 14.11.2014 17:42:

> f> 2. We already have support=* which is used with man_made=surveillance
> f> and is much more in use than mount=*. Do we really need two almost
> f> identical tags ?
> I agree with you on that. any chance to list it on the
> man_made=surveillance wiki page?

support is used for clocks, too. Perhaps this is the origin :)


-- 
regards
Holger


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] governmental / public_administrative landuse are not commercial

[johnw]

> On Nov 14, 2014, at 9:56 PM, Pieren  wrote:
> 
> On Fri, Nov 14, 2014 at 12:29 PM, johnw  wrote:
> 
>> it is a subkey for the buildings, to go with building=civic.
> 
> My concern is about splitting a landuse polygon just to refine
> information that could be stored on buildings themselves for instance.
> 
Do you mean the split between Civic_service and Civic_admin, or seperating out 
emergency, judicial, and penal?

because if the subkey is for the building, a complex would have 1 single 
landuse_admin, and the building=civic differentiated with civic=* key, 
including a civic=mixeduse value for when everything is jammed together in a 
single building (in El Cajon, Califonia for example, the city offices, 
courthouse, and Jail are all a single building). 

Javbw


> Pieren
> 
> ___
> 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] governmental / public_administrative landuse are not commercial

[johnw]

Updated and clarified the split of civic into 3 separate keys - civic_admin, 
civic_service, and civic_safety. Also discussed judicial and penal. 

civic_safety and penal are interesting, because there is no landuse for police 
stations, fire stations, jails or prisons. Martin suggested splitting out 
courthouses as well (landuse=judicial). 

I look forward to responding to everyone’s feedback here in the mailing list. 


http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/landuse%3Dcivic&action=submit
 



Javbw. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging