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

[johnw]

> On Nov 17, 2014, at 9:48 PM, Martin Koppenhoefer  
> wrote:
> 
> there will be more people with even more ideas and classification needs. 
> Therefor the foo=bar, bar=x way of subtyping, which implies there is only one 
> kind of subtyping, should generally be deprecated in favor of more verbose 
> subtyping-keys like foo=bar, bar:property=x


Martin - Do you have any suggestion for cleaning up the civic=* subkey I was 
suggesting for building=civic in this way? 

I assume we need a big generic key, and then a many subcategories that fall 
under that key. 

Building=civic
+
civic:legislation=city council ?
civic:administration=motor_vehicles ?

That kind of thing? It would allow for a lot more description with much fewer 
tags. I was thinking of letting the amenity on the building dictate if it is a 
city_hall or a DMV, but this seems to be a good chance to follow the 
key:subkey=subkey_value structure. 

I know it isn’t  Building:civic=city_council, Which seems to be what you are 
advocating (I think), but we have to work within the existing structure for 
building=X  & X=*  still, right? 


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

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

[johnw]

> On Nov 17, 2014, at 11:43 PM, Jean-Marc Liotier  wrote:
> 
> On 17/11/2014 15:14, althio forum wrote:
> 
> I may have been stretching the 'Openstreetmap' case a bit. 

We were discussing how to properly tag kilns, with their method of firing and 
how many chimneys they have, so I don’t think you off in your description OSM 
even a little.

 If they ever retitle it - it would be “Open World map” - because people are 
now trying to tag and describe basically every mappable object in existence.

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

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

[johnw]

> On Nov 17, 2014, at 9:34 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 2014-11-14 5:03 GMT+01:00 johnw mailto:jo...@mac.com>>:
> 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). 
> 
> 
> this can be very different from one country to another. E.g. in Italy there 
> are lots of different kind of police forces, some are military, others 
> aren't, so don't take for granted that all kind of police should get the same 
> landuse.
> 

Well, I was trying to think of something generic that could be flexible to 
adapt to different conditions, as I’m aware there are many different kind of 
police forces, and different levels of them - AKA local, county, Regional, 
national, and Civil and Military - but all of them are geared towards 
“policing” the citizens - not fighting wars, defending land form invaders, etc.

> Also fire departments will not necessarily have the same landuse, dependent 
> on how we will classify them, e.g. in Germany there are volunteering and 
> professional fire fighters.
> 

not sure how what affects the landuse of the stations. In California there are 
similar Volunteer stations, or ones manned only during fire season (they are in 
the countryside). I have heard that some small towns have volunteer-only  fire 
services. But that shouldn’t affect the marking of the landuse as a station, I 
believe - the’re all just buildings holding fire trucks. There is probably a 
way to mark manned or unmanned with existing tags - but if there isn’t maybe 
that is something for a fire=* subtag or something.

> Not sure what "safety" is about in this context, can you give a definition or 
> (less preferably) some examples what to include and exclude? (e.g. road 
> maintenance? snow plowing? putting road signs? monitoring stream gauges? 
> analyzing drinking water? homologating 
> vehicles/machinery/(construction/electrical/toys/clothes/...) products/food? 
> Controlling restaurants for hygiene?)

Definition for the landuse:

I chose Civic_safety thinking that it is for  “services that directly protect 
or safeguard the lives of citizens",  while excluding medical - as Hospitals 
are well established. 


“Safety" seemed to be the right choice, because I’m not implying emergency 
versus non-emergency as in  "someone sole my car, so I need to go to the police 
station to report it.” versus “Someone is stealing my car now, so I need the 
police here urgently!" That is [should be?] a separate tag. Isn’t that covered 
by Emergency=*  ? 

Police vs military police:

Similar with Military forces for military purposes - they are not involved with 
the protection of citizens - but the protection of the state as a whole. A 
Military police HQ for a force that is actually policing the citizens citizens 
(as opposed to the military itself) is still just a police station - it’s 
military roots would show up in the operator or even the name tag, right? an MP 
office would be on a military base, not downtown next to the city hall or the 
rec center. That would be a police station [for the citizens] - The fact that 
they are military or civilian cops are not really pertinent to their mandate to 
protect and serve the citizenry directly. I have very little experience in 
Military policing citizens in a non-emergency manner - but A police station is 
just a police station, right? 

If they were truly military - wouldn’t their facility be treated with 
landuse=military and an amenity=police_station in it instead? 
Either way, if you feel that such a force is worth being recognized as military 
or as a policing body, it is easy to describe the building and land through 
either landuse (=civic_safety or military) and the existing amenity tag.

Examples:

Police, fire, Lifeguards, Ranger stations(?) snow patrol, Highway patrol, etc 
*directly* safeguard the lives of citizens.  People who maintain equipment or 
utilities indirectly do so - the road worker fixing a pothole, or a guy 
trimming trees also is indirectly safeguarding my life (through accident 
prevention) - but the people responding to a burglar or a fire at my location 
is directly safeguarding my well being, as is a lifeguard looking for sharks or 
saving drowning people. People examining pipes are merely safeguarding 
investments, reducing liability, or checking the quality of a product, service, 
or utility. A fire brigade stopping a fire at such a  facility is a whole 
different matter.

As a [former] computer technician, It is my job to safeguard your computer and 
It’s data, and indirectly your life making sure your computer doesn’t burn down 
your house. But I would never consider myself a fireman. I have found stolen 
equipment, but I would never consider myself the police. 

My friend is an electrical inspector/engineer. He verifies the safety of the 
electrical equipment at “high” voltages (~6000v). If he screws up, your factory 
could burn 

Re: [Tagging] Feature Proposal - RFC - Water tap

[Kotya Karapetyan]

What about introducing a name space:
water_source:potable=designated | mineral | heilwasser (I failed to find a
good English-language analogue, could someone help please?)
water_source:sparkling=yes | no | unknown
water_source:nonpotable=compromised | designated

In principle, details regarding the kind of water source could be provided
here as well, to free up the top level a bit and help data users:

water_source:type = tap | fountain | well | spring

Please comment.

Cheers,
Kotya



On Thu, Nov 13, 2014 at 5:07 PM, Martin Koppenhoefer  wrote:

>
> 2014-11-13 6:50 GMT+01:00 Bryce Nesbitt :
>
>> Let's start with the cases:
>>
>> * Designated potable, as in from a city tap.
>> * Designated non-potable, as in from a farm ditch, or purple pipe (USA).
>> This would include designated irrigation water of most sorts.
>> * Potable but with a known defect such as high mineral content.
>> * Unspecified.  This may cover most backcountry springs where no testing
>> is done, but no promises are made.
>> * Compromised.  For example a muddy spring or clearly impacted water
>> source usable only in dire emergencies.
>>
>
>
>
> there are more types of water that might be interesting to people:
>
> - mineral water  http://en.wikipedia.org/wiki/Mineral_water
> - sparkling attribute (if it is naturally effervescent)
> - in Germany there is a subclass of mineral water (~"healing water" in
> German "Heilwasser") which has positive physiologic effects.
>
> 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] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions

[Rainer Fügenstein]

MK> +1, also this way you give information about the direction of flow relative
MK> to the osm way, while flow_direction=oneway doesn't imply any specific
MK> direction, it only states that the direction is not reversible.

proposal updated in this regard.


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

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

[Andreas Labres]

On 17.11.14 16:18, Martin Koppenhoefer wrote:
>
> yes, street cabinet is the actual name for this kind of thing, so using this
> as tag seems best to describe what this proposal aims to describe. Simply
> search for "street cabinet" in google (or another image search engine) then
> research images for "technical cabinet" and you can see that the current name
> is chosen well.

+1.

Street cabinet is a fixed technical term for those outdoor (electrical)
cabinets. Cabinet alone makes no sense as a value as it is too ambiguous (from
furniture to government). And never heard of a "technical cabinet", this looks
to me like beeing invented by somebody here... ;)

/al

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

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

[althio forum]

On Mon, Nov 17, 2014 at 3:43 PM, Jean-Marc Liotier  wrote:
> I agree with your arguments - my personal choice would be technical_cabinet.

> I nevertheless chose to approve the proposal because I considered this issue 
> minor compared
> to all the work that went in organizing the scheme...

> experience in free software projects shows that
> it is usually better to avoid focus on that. I may be wrong - it could also
> be a fundamental modeling issue that we will regret eternally.

I did not vote.
I consider the naming issue minor compared to the scope of the
proposal. I consider the issue important enough since it is the
first-level key of the scheme. Does it make sense...

I feel that (maybe) voters accepted a globally good scheme (just like
you). Also maybe voters are not opposed to further discussion for
refinement once the scheme is accepted but not yet in heavy use.

I raised my concern, documented it on the Talk page, signaled it on
the tag list.
My personal choice would be 'cabinet' for the sake of correctness,
simplicity and potential evolution for uses yet unseen. Otherwise
'technical_cabinet' suits me too.

I will now keep quiet and let others voice their opinion if they want to.

althio

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

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

[Martin Koppenhoefer]

2014-11-17 15:43 GMT+01:00 Jean-Marc Liotier :

> One may have suspected a French telco etymological bias as we call those
> cabinets 'armoires de rue' - literally 'street cabinet'... But as the
> proposal's page history and its approval signatures show, the consensus is
> actually international.
>


yes, street cabinet is the actual name for this kind of thing, so using
this as tag seems best to describe what this proposal aims to describe.
Simply search for "street cabinet" in google (or another image search
engine) then research images for "technical cabinet" and you can see that
the current name is chosen well.

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

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

[Jean-Marc Liotier]

On 17/11/2014 15:14, althio forum wrote:

Martin, Jean-Marc, I appreciate the feedback. You are voicing some
good elements. I am not totally convinced yet about generic vs
specific. Fairly generic tag like 'man_made=cabinet' sounds very
sensible as first level. Furthermore I do feel other proposal I have
seen like 'street_' and 'technical_' are not necessary and not even
useful.

[Derailing a bit]
IMO it is a poor justification to compare a brand new tag (here
'street_cabinet') with the 10-year old established name of the project
'Openstreetmap'.

Even more... Historical justification is sometimes inevitable but
often it is rather unsatisfactory in my mind. [..]


I may have been stretching the 'Openstreetmap' case a bit. I agree with 
your arguments - my personal choice would be technical_cabinet. I 
nevertheless chose to approve the proposal because I considered this 
issue minor compared to all the work that went in organizing the 
scheme... The issue smelt a lot like bikeshedding to me and experience 
in free software projects shows that it is usually better to avoid focus 
on that. I may be wrong - it could also be a fundamental modeling issue 
that we will regret eternally.


One may have suspected a French telco etymological bias as we call those 
cabinets 'armoires de rue' - literally 'street cabinet'... But as the 
proposal's page history and its approval signatures show, the consensus 
is actually international. So for once, the French telco mafia is not to 
blame.



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

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

[althio forum]

Martin, Jean-Marc, I appreciate the feedback. You are voicing some
good elements. I am not totally convinced yet about generic vs
specific. Fairly generic tag like 'man_made=cabinet' sounds very
sensible as first level. Furthermore I do feel other proposal I have
seen like 'street_' and 'technical_' are not necessary and not even
useful.

[Derailing a bit]
IMO it is a poor justification to compare a brand new tag (here
'street_cabinet') with the 10-year old established name of the project
'Openstreetmap'.
Even more... Historical justification is sometimes inevitable but
often it is rather unsatisfactory in my mind.
If the name of the project 'Openstreetmap' could be easily changed or
created today... maybe something else (better?) would appear instead.
Not the subject here.

[Not too serious]
We have street_lamp [could be lamp, lamppost, light_source] and now
street_cabinet [could be technical_cabinet, outdoor_cabinet,
cabinet]...
I don't want street_tree_row, street_pole, street_surveillance,
street_bicycle_parking, street_atm, street_clock, street_post_box, and
street_crossing.
But who want to play street_hockey and enjoy street_art? :)
[/Not too serious]

[/Derailing]

Back to our cabinets?

Have a nice day

On Mon, Nov 17, 2014 at 2:05 PM, Jean-Marc Liotier  wrote:
> On 17/11/2014 13:19, Martin Koppenhoefer wrote:
>
>
>> man_made=street_cabinet
>> is implicitly rejecting 'countryside cabinet' or cabinets in
>> motorways, parks, fields, train stations, airports and so on.
>
>
> IMHO it is not. Don't read this "overliterally".
>
>
> Indeed - like 'Openstreetmap' which, as some may have noticed, is not
> actually all about streets...
>
>
> ___
> 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 - Voting - Tagging for complex junctions

[Lukas Sommer]

We have finally 12 votes: 11 times “yes” and 1 time “no”. I think this
could be considered as approved …

Lukas

Lukas Sommer

2014-11-02 7:57 GMT+00:00 Lukas Sommer :

> Hello.
>
> After commenting period, now is starting the voting for the junction
> (only) tagging at
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions
>
> Lukas Sommer
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jean-Marc Liotier]

On 17/11/2014 13:19, Martin Koppenhoefer wrote:


man_made=street_cabinet
is implicitly rejecting 'countryside cabinet' or cabinets in
motorways, parks, fields, train stations, airports and so on.


IMHO it is not. Don't read this "overliterally".


Indeed - like 'Openstreetmap' which, as some may have noticed, is not 
actually all about streets...


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

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

[Martin Koppenhoefer]

2014-11-17 13:53 GMT+01:00 Tom Pfeifer :

> the value 'waste' is more consistent with existing amenity tagging than
> refuse or garbage.
>



the objects that have been brought up as examples have been of private
nature, i.e. not an amenity for osm terms. I wouldn't include private waste
bin protection structures under the  same tag that we use to describe
switching points of technical infrastructure like the power grid or telco,
but I agree it could also be done. As it wasn't contained in the proposal
the people voted upon, I'd prefer if including them now would be a distinct
proposal.

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

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

[Tom Pfeifer]

street_cabinet=waste had already been discussed during the proposal process,
but not yet added during the voting.

the value 'waste' is more consistent with existing amenity tagging than
refuse or garbage.

I have added it to categories and examples to the wiki, feel free to add a 
picture,
some examples are linked from a search engine.

johnw wrote on 2014-11-17 12:00:

How would I go about documenting the garbage/refuse cabinets? Just get a 
picture and put it into the wiki, or is there some other way?

because it is a brand new proposal, I’m unsure of the procedure to extend it.

Javbw



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

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

[Martin Koppenhoefer]

2014-11-14 12:09 GMT+01:00 Pieren :

> 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".
>


there is no indication of this, the wiki remains very generic and doesn't
say anything useful. "small" is completely ambiguous, is an ant small?
Compared to a bacterion?



> We put "tax",
> "immigration" or "legislative" into the buildings where these services
> are.
>


you are presuming that those have to take place in "buildings"?
I agree with you that we should not use landuse instead of actual keys
which describe (in the end also in a detailed level) functions like a
specific government office. I'd want to use osm to see where I can get a
new passport in the future. There are lots of different government agencies
and offices? So what, let's start and we'll adapt and refine with the time
to come to something useful.



> Otherwise, it is endless. We could create a subkey for
> "landuse=residential" with "residential=home" or "residential=garage"
> or "residential=toilets_in_the_garden"
>


Actually I would prefer a different direction for "residential" subtyping,
something which describes
- the urban structure (might be also done with automatic analysis up to a
certain point, given that a lot of data is available (including building
types and heights, which makes this hard to realistically come true in the
next years).
- the density (could maybe be done with population if data was available,
also )

there will be more people with even more ideas and classification needs.
Therefor the foo=bar, bar=x way of subtyping, which implies there is only
one kind of subtyping, should generally be deprecated in favor of more
verbose subtyping-keys like foo=bar, bar:property=x

More than for residential, I see a missing piece in industrial. In Germany,
there are 2 quite different types of what in OSM both is industrial:
Gewerbegebiet and Industriegebiet, which in OSM could be translated to
industrial subtypes.

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

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

[François Lacombe]

2014-11-17 13:19 GMT+01:00 Martin Koppenhoefer :

>
>
> FWIW, the term "man_made=street_cabinet" has just been approved by almost
> unanimous voting. Why does this discussion start now?
>

Because of some comments written lately on friday evening when the vote was
about to end.

The only one opposition to the proposal was regarding the term "street" in
street_cabinet.
Like you I think we shouldn't read it "overliterally" but I'm not closed to
discuss a little more around it.

The tag is, for now, described as it was voted, strictly.


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

2014-11-14 5:03 GMT+01:00 johnw :

> 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).




this can be very different from one country to another. E.g. in Italy there
are lots of different kind of police forces, some are military, others
aren't, so don't take for granted that all kind of police should get the
same landuse.

Also fire departments will not necessarily have the same landuse, dependent
on how we will classify them, e.g. in Germany there are volunteering and
professional fire fighters.

Not sure what "safety" is about in this context, can you give a definition
or (less preferably) some examples what to include and exclude? (e.g. road
maintenance? snow plowing? putting road signs? monitoring stream gauges?
analyzing drinking water? homologating
vehicles/machinery/(construction/electrical/toys/clothes/...)
products/food? Controlling restaurants for hygiene?)

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

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

[François Lacombe]

Thank you Althio,

2014-11-17 12:10 GMT+01:00 althio forum :

> man_made=street_cabinet
> is implicitly rejecting 'countryside cabinet' or cabinets in
> motorways, parks, fields, train stations, airports and so on.
>

Yeah I would rather agree.
We also have the highway=* tag to describe one and each road, not only
high-speed ways between major cities.



> man_made=technical_cabinet
> is quite generic. Is it excluding any kind of non-technical cabinet? I
> guess containers and collecting points are out of the scope with other
> tagging schemes, aren't they?
>

I agree on this point, any kind of non-technical cabinet won't be covered


> man_made=outdoor_cabinet
> is also quite generic. Is it excluding any kind of cabinet?
>

It is excluding all indoor cabinets, especially when they're underground,
in tunnels or whatever.
We also have a generic tag to describe features' location : location=*


> man_made=cabinet
> is very generic, can serve as basis for a lot of equipment and
> applications, can be refined with namespace/subkey.


That's the simplest indeed.
If a refinement must be done, I would choose this one.


Regards

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions

[Martin Koppenhoefer]

2014-11-15 22:47 GMT+01:00 fly :

> The major advantage about backward/forward is the editor support once
> the way direction is reversed.
>
>

+1, also this way you give information about the direction of flow relative
to the osm way, while flow_direction=oneway doesn't imply any specific
direction, it only states that the direction is not reversible.

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

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

[Martin Koppenhoefer]

2014-11-17 12:10 GMT+01:00 althio forum :


FWIW, the term "man_made=street_cabinet" has just been approved by almost
unanimous voting. Why does this discussion start now?



man_made=street_cabinet
> is implicitly rejecting 'countryside cabinet' or cabinets in
> motorways, parks, fields, train stations, airports and so on.
>


IMHO it is not. Don't read this "overliterally".



>
> man_made=technical_cabinet
> is quite generic. Is it excluding any kind of non-technical cabinet? I
> guess containers and collecting points are out of the scope with other
> tagging schemes, aren't they?
>


it is including all kind of indoor cabinets (which typically serve
different purpose, i.e. are part of a factory or similar and serve a single
client).



>
> man_made=outdoor_cabinet
> is also quite generic. Is it excluding any kind of cabinet?
>


it is including all kind of weather proof cabinets like the one in my
garden or on the balcony to store the tools (I think). Too generic IMHO.




>
> man_made=cabinet
> is very generic, can serve as basis for a lot of equipment and
> applications, can be refined with namespace/subkey.
>


way too generic IMHO. Every tagging scheme has to find the right way
between too generic and too specific, but typically very broad terms that
don't say much and require additional tags to make sense are working less
well in our environment (e.g. highway=bus_stop works better with the common
tools than the newer public transport scheme which still cannot be used by
the osm-cartostyle because of missing information (no bus-key in the
rendering db)). This might be also seen as problem of dataconsumers which
rely on dedicated columns for every single key they want to know about (and
can be resolved by using different data storage methods like hstore
columns).

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

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

[althio forum]

adding to Talk page

On naming of newly voted man_made=street_cabinet
http://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dstreet_cabinet

A few old & new proposals for actual naming are:
man_made=street_cabinet
man_made=technical_cabinet
man_made=outdoor_cabinet
man_made=cabinet

man_made=street_cabinet
is implicitly rejecting 'countryside cabinet' or cabinets in
motorways, parks, fields, train stations, airports and so on.

man_made=technical_cabinet
is quite generic. Is it excluding any kind of non-technical cabinet? I
guess containers and collecting points are out of the scope with other
tagging schemes, aren't they?

man_made=outdoor_cabinet
is also quite generic. Is it excluding any kind of cabinet?

man_made=cabinet
is very generic, can serve as basis for a lot of equipment and
applications, can be refined with namespace/subkey.

On Mon, Nov 17, 2014 at 12:05 PM, François Lacombe
 wrote:
> A large amount of values can be added to street_cabinet key.
>
> I think you should only open a thread on Talk page to let other contributors
> discuss about it and relay the discussion here on @tagging
> http://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dstreet_cabinet
>
> No need to complex proposal process IMHO.
>
> François Lacombe
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux
>
> 2014-11-17 12:00 GMT+01:00 johnw :
>>
>> How would I go about documenting the garbage/refuse cabinets? Just get a
>> picture and put it into the wiki, or is there some other way?
>>
>> because it is a brand new proposal, I’m unsure of the procedure to extend
>> it.
>>
>> Javbw
>>
>>
>> It has been documented as voted yesterday
>> http://wiki.openstreetmap.org/wiki/Street_cabinet
>>
>> A disambiguation chapter has been added to help anyone who want to deal
>> with traffic signals or accepted monitoring stations
>> http://wiki.openstreetmap.org/wiki/Street_cabinet#Disambiguation
>>
>> Feel free to come on Talk page to discuss unclear points
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> 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

[François Lacombe]

A large amount of values can be added to street_cabinet key.

I think you should only open a thread on Talk page to let other
contributors discuss about it and relay the discussion here on @tagging
http://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dstreet_cabinet

No need to complex proposal process IMHO.

*François Lacombe*

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

2014-11-17 12:00 GMT+01:00 johnw :

> How would I go about documenting the garbage/refuse cabinets? Just get a
> picture and put it into the wiki, or is there some other way?
>
> because it is a brand new proposal, I’m unsure of the procedure to extend
> it.
>
> Javbw
>
>
> It has been documented as voted yesterday
> http://wiki.openstreetmap.org/wiki/Street_cabinet
>
> A disambiguation chapter has been added to help anyone who want to deal
> with traffic signals or accepted monitoring stations
> http://wiki.openstreetmap.org/wiki/Street_cabinet#Disambiguation
>
> Feel free to come on Talk page to discuss unclear points
>
>
>
> ___
> 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

[johnw]

How would I go about documenting the garbage/refuse cabinets? Just get a 
picture and put it into the wiki, or is there some other way?

because it is a brand new proposal, I’m unsure of the procedure to extend it. 

Javbw

> 
> It has been documented as voted yesterday
> http://wiki.openstreetmap.org/wiki/Street_cabinet 
> 
> 
> A disambiguation chapter has been added to help anyone who want to deal with 
> traffic signals or accepted monitoring stations
> http://wiki.openstreetmap.org/wiki/Street_cabinet#Disambiguation 
> 
> 
> Feel free to come on Talk page to discuss unclear points
> 

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

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

[François Lacombe]

Hi all,

Thank you Martin

It has been documented as voted yesterday
http://wiki.openstreetmap.org/wiki/Street_cabinet

A disambiguation chapter has been added to help anyone who want to deal
with traffic signals or accepted monitoring stations
http://wiki.openstreetmap.org/wiki/Street_cabinet#Disambiguation

Feel free to come on Talk page to discuss unclear points


All the best

*François Lacombe*

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

2014-11-17 10:25 GMT+01:00 Martin Koppenhoefer :

>
> 2014-11-14 10:57 GMT+01:00 François Lacombe :
>
>> 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.
>>
>
>
> I prefer the street cabinet term to a more generic "technical cabinet", as
> it gives approximative information both on size and that it is an outdoor
> facility.
>
> 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 - Street cabinet - Voting

[Martin Koppenhoefer]

2014-11-14 10:57 GMT+01:00 François Lacombe :

> 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.
>


I prefer the street cabinet term to a more generic "technical cabinet", as
it gives approximative information both on size and that it is an outdoor
facility.

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