Re: [Tagging] RFD Camp ground Kitchens and their fittings

[ross]

Had thought about this myself as we also tend to look for camps with 
kitchens.


So on a tourism=camp_site or tourism=caravan_site node or way

kitchen=yes
kitchen:stove=yes
kitchen:bbq=yes
kitchen:microvave_oven=yes
kitchen:fire_place=yes
etc...

Cheers
Ross

On 31/01/15 13:55, Warin wrote:

Hi,

Follow a thread on another forum (non OSM, but talking about side 
issues) I think the following things should be mapped to add 
information to the map in regards some, mainly commercial, camp 
grounds that have communal kitchens;


stove top (no, not a bbq)
microwave_oven
fridge (or refrigerator to give it a fuller name?)
sink

Most of these have a simple roof structure, leaving all or most sides 
open, a few tables and chairs. But it is the above features that make 
it better and something I'd look for.


These features may eventually make there way onto indoor mapping too.

They are all man_made so could go there. So all those features under 
'man_made'? What ideas/preferences are there? I, as a beginner, could 
simply slot them in there .. but I don't like it .. but have no better 
idea.


___
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] RFD Camp ground Kitchens and their fittings

[Warin]

On 31/01/2015 3:18 PM, David Bannon wrote:

On Sat, 2015-01-31 at 14:55 +1100, Warin wrote:

... I think the following things should be mapped to add information
to the map in regards some, mainly commercial, camp grounds that have
communal kitchens;

Warin, I recently was looking at  Tag:tourism=camp_site and thinking it
lacked a lot of detail.

There is a proposal to extent at
http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
that appears to have run out of steam. But a reasonable start. Would the
features you want to add be more appropriate there ?
Thin end of wedge ... the things I've stated go in any kitchen .. thus 
can be used by the indoor mapping group too.Thus not specific to a camp.

I'd have a few things I'd like to add, mainly concentrating on
facilities at what are called "Free Camps" in Oz, generally no (or very
little) charge, remote, basic facilities for well equipped campers.
Opposite end of your target .

But could be turned into a nice package IMHO.
I'm less inclined to a package .. someone objects to bit z, another to 
bit t .. and you get too many people voting against all of it due to 
their one gripe. So I'll try for one at a time approach and see if they 
go through that way. My thread is about man_made .. or some other 
starter to these kind of kitchen things..


The 'fee camps' in Oz are very free form .. in Germany you must place 
your tent in an area  .. at say section G53 ... they are very 
regimented.. when you get your site allocated at the front office you 
don't just go wandering around and select what you want, those were at 
paid sites .. free sites in Germany .. not found by me, well before OSM. 
Generally remote OZ = find your own site somewhere, bury your human 
waste and carry out the rest. If your taking National Parks, State 
Forests .. some have very nice facilities .. they usually charge at them 
though.


What other non tagged facilities are you thinking off? Toilets + 
benches, taps are done. Fire places? Oh .. washing lines? Most of Europe 
don't know what they are - they use dryers .. not the climate for a 
washing line.  Laundry .. usually in a building and can be tagged 
shop=laundry think that exists.



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

Re: [Tagging] RFD Camp ground Kitchens and their fittings

[David Bannon]

On Sat, 2015-01-31 at 14:55 +1100, Warin wrote:
> ... I think the following things should be mapped to add information 
> to the map in regards some, mainly commercial, camp grounds that have 
> communal kitchens;

Warin, I recently was looking at  Tag:tourism=camp_site and thinking it
lacked a lot of detail.

There is a proposal to extent at
http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
that appears to have run out of steam. But a reasonable start. Would the
features you want to add be more appropriate there ?

I'd have a few things I'd like to add, mainly concentrating on
facilities at what are called "Free Camps" in Oz, generally no (or very
little) charge, remote, basic facilities for well equipped campers.
Opposite end of your target .

But could be turned into a nice package IMHO.

David 

> 
> stove top (no, not a bbq)
> microwave_oven
> fridge (or refrigerator to give it a fuller name?)
> sink
> 
> Most of these have a simple roof structure, leaving all or most sides 
> open, a few tables and chairs. But it is the above features that make it 
> better and something I'd look for.
> 
> These features may eventually make there way onto indoor mapping too.
> 
> They are all man_made so could go there. So all those features under 
> 'man_made'? What ideas/preferences are there? I, as a beginner, could 
> simply slot them in there .. but I don't like it .. but have no better 
> idea.
> 
> ___
> 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] Temperature tag

[Warin]

The wiki page for temperature 
https://wiki.openstreetmap.org/wiki/Key:temperature has been empty for 
some time.. I've taken the plunge and made some entries .. see what you 
think!


Any ideas for improvements will be gratefully recived. Critisium without 
a suggestion as to how to improve, less so, but better than nothing.


You can, of course, make you own entries directly to the page.

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

[Tagging] RFD Camp ground Kitchens and their fittings

[Warin]

Hi,

Follow a thread on another forum (non OSM, but talking about side 
issues) I think the following things should be mapped to add information 
to the map in regards some, mainly commercial, camp grounds that have 
communal kitchens;


stove top (no, not a bbq)
microwave_oven
fridge (or refrigerator to give it a fuller name?)
sink

Most of these have a simple roof structure, leaving all or most sides 
open, a few tables and chairs. But it is the above features that make it 
better and something I'd look for.


These features may eventually make there way onto indoor mapping too.

They are all man_made so could go there. So all those features under 
'man_made'? What ideas/preferences are there? I, as a beginner, could 
simply slot them in there .. but I don't like it .. but have no better 
idea.


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

Re: [Tagging] length=

[Mike Thompson]

Here I diverge. If the hedgerow is an improtant part of the landscape
then I'd map it .. even if it is not at your required level of
'accuracy'. Reason: it is the relationship between the objects on the
map that is important rather than the absolute accuracy of any one
object.
+1

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

Re: [Tagging] length=

[Warin]

On 31/01/2015 1:47 AM, SomeoneElse wrote:

On 30/01/2015 14:12, St Niklaas wrote:

> From: François Lacombe 
>
> Since OSM editing tools aren't AutoCAD you can't be 100% precise on the
> geometry.


Exactly so.



Francois if you’re using JOSM you’re be able to work up till 0,06 - 
0,04 =0,02 m accuracy




No.  Unless you can measure accuracy on the ground to that level of 
precision, you simply can't*.


And you should not use anything, AutoCAD included, to enter data at a 
greater precision (accuracy) than what is available. Unfortunately the 
data is stored as being absolutely accurate and precise so if the end 
user is so inclined they could try to use it as such. They would quickly 
be disappointed with OSM! OSM is not a source of absolute accuracy.



On 31/01/2015 1:47 AM, SomeoneElse wrote:
A good rule of thumb for OSM is "don't try and map more accurately 
than your sources".  If you only have aerial imagery, or only have a 
few GPS traces, don't try and map every last hedgerow, since you 
simply don't know how accurate the sources that you're working from 
are.  Instead, go out and collect more data.  For example, once you 
know how aerial imagery compares to lots of GPS traces (and vice-versa 
- GPS traces can have a systematic offset due to terrain and even 
"what side of a road people are allowed to walk down") you're in a 
much better position to contribute.


Here I diverge. If the hedgerow is an improtant part of the landscape 
then I'd map it .. even if it is not at your required level of 
'accuracy'. Reason: it is the relationship between the objects on the 
map that is important rather than the absolute accuracy of any one 
object. If the relationship between the objects is representative of 
what is on the ground then it conveys usefull information to the end 
user and should be mapped.


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

[Tagging] Feature proposal - Power transmission refinement - Abandon

[François Lacombe]

Hi,

Due to the large amount of key modified / created in the power transmission
refinement proposal, it has been decided to split it in 2 subsequent
proposals.
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement

I've already created the Power supports refinement proposal regarding power
towers, poles and 2 new types of support.
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement

As usual, example section need to be filled. There are another photos I
haven't already uploaded but feel free to complete it with yours if you
want.


Another document, Power paths refinement proposal will come before the end
of this week end.

This will allow a simpler and more detailed vote (I hope).


All the best


*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] RFD pipeline sub tag substance

[althio]

> Sorry, I was thinking of gas as a product (as in natural gas), not a
state of matter.

Confusing, so I proposed natural_gas for natural gas.

> I was thinking of substance=* as a category (water, fuel, oil, gas,
coolant, etc etc

I think we need (as often as possible) to tag separately nature and
purpose, otherwise it gets messy.

* nature, matter, substance, with eg. substance:name = *
* use, usage, purpose... with eg. pipeline:usage = drinking_water,
wastewater/sewage, drain/irrigation, transport/transmission, heating,
coolant, industrial, communication...

The categories with only one key are not well cut. Water can be coolant,
oil can be fuel, ...
We should not mix nature and purpose. And it should be clear in the keys.
The mapper could fill what he knows (nature and/or purpose) and leave what
is unknown.

> substance:state=* one of the 3 states, along with multi and slurry. Solid
is assumed to be pneumatic then?

I would prefer another term than solid.
state=solid is apparently a match for cables...
so it implies static=yes ;) ;)
maybe "powder" or something like "particles_in_gas"
if substance:moving=yes ;) ;) ;)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lifecycle concepts, "REMOVED"

[sly (sylvain letuffe)]

Hi,


dieterdreist wrote
> thank you all for your comments, user:RicoZ, the creator of that page also
> agreed and has changed the description.

In fact, the creator of the above mentionned wiki page copy/pasted the page
I originally created to document the removed: prefix here :
http://wiki.openstreetmap.org/wiki/Key:removed

The goal was to describe an allready in use practice about the removed:
prefix which I thought defered from the destroyed: prefix which was intended
for features that once were, but were destroyed, while the removed: prefix
is a more generic case where some mapper discover on the ground that a real
life object in fact does not exists (and that mapper does not know if that
real life object once existed or not), and after removing it, is faced with
another (harmchair) mapper re-adding again that feature.



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Lifecycle-concepts-REMOVED-tp5831677p5831969.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] length=

[SomeoneElse]

On 30/01/2015 14:12, St Niklaas wrote:

> From: François Lacombe 
>
> Since OSM editing tools aren't AutoCAD you can't be 100% precise on the
> geometry.


Exactly so.



Francois if you’re using JOSM you’re be able to work up till 0,06 - 
0,04 =0,02 m accuracy




No.  Unless you can measure accuracy on the ground to that level of 
precision, you simply can't*.  The imagery sources availble to OSM 
aren't that accurate, and even the aggregated traces of many, many 
consumer GPS units won't hit that accuracy.  0.06m is a tiny amount 
compared to the amount that natural processes can cause a particular 
"location" to move**.


A good rule of thumb for OSM is "don't try and map more accurately than 
your sources".  If you only have aerial imagery, or only have a few GPS 
traces, don't try and map every last hedgerow, since you simply don't 
know how accurate the sources that you're working from are.  Instead, go 
out and collect more data.  For example, once you know how aerial 
imagery compares to lots of GPS traces (and vice-versa - GPS traces can 
have a systematic offset due to terrain and even "what side of a road 
people are allowed to walk down") you're in a much better position to 
contribute.


Cheers,

Andy

PS:  Please don't reply to digest posts largely unedited.  The very 
first line in your reply mail was, quoted, "When replying, please edit 
your Subject line so it is more specific".  Even if you do edit a digest 
post down it'll still destroy the threading of the mailing list.  Many, 
many people rely on this to make the process of reading lists such as 
"tagging" less of a chore (it's much easier to "mark a thread as read" 
than it is to go through every post about semicolons, patron saints or 
pipelines one by one).  If you don't have a mail reader than can handle 
non-digest mail, you probably need to change the way that you read mail.


* The exception is where you're triangulating from points measured with 
an accuracy beyond what consumer kit can provide.  I'm looking forward 
to seeing "triangulation via theodolite from X" in an OSM source tag :)


** http://www.bbc.co.uk/news/science-environment-12732335
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] ContentsTagging Digest, Vol 64, Issue 138, length= Francois

[St Niklaas]

>When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> Today's Topics:

>5. Re: length= (François Lacombe)

> Message: 5
> Date: Wed, 28 Jan 2015 09:13:38 +0100
> From: François Lacombe 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] length=
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Since OSM editing tools aren't AutoCAD you can't be 100% precise on the
> geometry.
> Some small features can actually be summarized as nodes when drawing their
> shape sounds irrelevant regarding the cluttering it introduces.
> 
> I'm sorry that was trivial for me.
> I won't draw a circle for a 5cm diameter pole and so on...
> 
> That's why tags are intended for several kind of primitives instead of only
> one sometimes.
> *François Lacombe*



Francois if you’re using JOSM you’re be able to work
up till 0,06 - 0,04 =0,02 m accuracy and with the other tools flip, turn and so
on the complete structure, so I don’t agree, your able to work quit accurate up
to building standards. 
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Contents of Tagging Digest, Vol 64, Issue 148, discussion, strategy and related tools

[St Niklaas]

Today's Topics:
> 
>2. Re: Lifecycle concepts, "REMOVED" (althio)
> 
> Message: 2
> Date: Thu, 29 Jan 2015 18:58:27 +0100
> From: althio 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] Lifecycle concepts, "REMOVED"
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Mateusz Konieczny  wrote:
> > Yes, feature that does not exist anymore (or even never existed!) or
> > is only proposed has no place in OSM.
> 
> +1. No place on rendered map and apps. +/-1. No place on DB.
> 
> > With possible caveat that features that are extremely likely to be added
> > (recently destroyed building visible on aerial images etc) element with
> note
> > explaining situations makes sense.
> 
> +1. Tag:note=* is useful for such cases.
> 
> > But not a full tagging scheme!
> 
> -1. If you keep the outline in OSM database, removed:building=* instead of
> building=* is efficient, can be quicker than free-form note=*, clear and
> informative.
 
Hi,


Just a link we had the same discussion earlier this year, link 
http://forum.openstreetmap.org/viewtopic.php?id=29723 in
Dutch sorry.


The outcome was tag or ad plans if there’s any kind of activity, signs (?)
,  but measuring, groundwork and so on is
sufficient to mark an area as landuse=construction and make a start drawing the
supposed trace, step by step.


OSM is not an official planning’s map for anyone, don’t start drawing if
there nothing out there to see.


Greetz



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

Re: [Tagging] RFD pipeline sub tag substance

[johnw]

> On Jan 30, 2015, at 6:51 PM, althio  wrote:
> 
> John Willis  wrote:
> 
>> Substance=gas
>> Substance:detailed:multiphase_gas
>> Substance:state=multi
> 
> That is not coherent. Do you mean that (substance=gas) is for mainly
> gas or gas-only?
> If it is gas only (substance=gas), it can be multiple gaseous
> products. But it is not multiphase.
> And then state=gas, not state=multi.
> 

Sorry, I was thinking of gas as a product (as in natural gas), not a state of 
matter. 

I was thinking of substance=* as a category (water, fuel, oil, gas, coolant, 
etc etc

State would be multi. 



> 
>>> substance=multi is about OK as a shorthand. Using multi -- instead of
>>> actual values -- may also imply you are not going to give further
>>> detailed tagging.
>>> substance=multiphase is really awkward.
>> 
>> I think it would be substance:detailed:multiphase_gas for a particular item, 
>> not as a general description.
>> 
>> Otherwise, it is multi for the state or matter... Right?
> 
> Right, multi for state. My previous proposals were:
> 
> 1.
> substance:state = * or substance:phase = *
> values limited to list eg.: gas, liquid, solid (cables), slurry
> (=liquid+solid particles), multi (=multiphase, mostly gas and liquid,
> possibly particles)
> 
> 2.
> I advocated for
> phase/state=multi or multiphase
> substance=[multi-valued] eg. substance=oil;gas;water

+1

Substance=* should be a category
Substance:detailed=* exact value that is easily added by taggers
substance:state=* one of the 3 states, along with multi and slurry.  Solid is 
assumed to be pneumatic then?

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

Re: [Tagging] RFD pipeline sub tag substance

[althio]

John Willis  wrote:

> Substance=gas
> Substance:detailed:multiphase_gas
> Substance:state=multi

That is not coherent. Do you mean that (substance=gas) is for mainly
gas or gas-only?
If it is gas only (substance=gas), it can be multiple gaseous
products. But it is not multiphase.
And then state=gas, not state=multi.


>> substance=multi is about OK as a shorthand. Using multi -- instead of
>> actual values -- may also imply you are not going to give further
>> detailed tagging.
>> substance=multiphase is really awkward.
>
> I think it would be substance:detailed:multiphase_gas for a particular item, 
> not as a general description.
>
> Otherwise, it is multi for the state or matter... Right?

Right, multi for state. My previous proposals were:

1.
substance:state = * or substance:phase = *
values limited to list eg.: gas, liquid, solid (cables), slurry
(=liquid+solid particles), multi (=multiphase, mostly gas and liquid,
possibly particles)

2.
I advocated for
phase/state=multi or multiphase
substance=[multi-valued] eg. substance=oil;gas;water

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

Re: [Tagging] patron saints

[Jo]

I think that when it gets really that complex, it's best to create a
wikidata item for the shrine (and probably a Wikpedia page as well, I guess
at least on ja.WP they are noteworthy enough to deserve a page), then
simply refer to that using the wikidata tag itself.

and maybe a comma delimited list of wikidata Q-refs in the
dedication:wikidata tag, for people who want to rely on only OSM data for
statistics purposes.

Jo



2015-01-29 13:24 GMT+01:00 Satoshi IIDA :

>
> +1 to use wikidata.
> I had once thinking about same purpose. :)
> https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine
>
> But many place of worship in Japanese have multiple dedication gods.
> And when we would like to express using semi-colon (;),
> multi-lingual approach would be fail into complex array.
>
> e.g.
> If a shrine dedicates 3 gods.
> in Japanese Kanji = 天照大御神; 月讀命; 素戔嗚尊
> in English = Amaterasu-Oomikami; Tsukuyomi-no-Mikoto; Susanoo-no-Mikoto
>
> And each gods has "loc_name", "alt_name", or alternated writings.
> I was thinking about "dedication:N" (like Addr:N) once, but it is a bit
> troublesome.
>
>
>
> 2015-01-29 2:10 GMT+09:00 Martin Koppenhoefer :
>
>>
>> 2015-01-28 17:12 GMT+01:00 André Pirard :
>>
>>> Speaking of Vatican, i.e. Roman Catholic Church, Mary is Blessed, not
 Saint. Her title is Beata Virgo Maria (Beata Vergine Maria in Italian,
 Blessed Virgin Mary in English). She is an unordinary Blessed, as she and
 her feasts are more important than those of the Saints; anyway, "Saint
 Mary" is nothing but a popular name :-)
>>>
>>>
>>>
>>>  Are you sure about this? Because I have heard about "Santissima Madre
>>> di Dio" (holiest mother of God)
>>>
>>> My reply was of course kidding. That, in Simone's terms, the Vatican use
>>> a popular language ;-)
>>> The fact is that in French, we use no such words as "Blessed".
>>>
>>
>>
>> the correct term in French is "bienheureux ou bienheureuse, le
>> qualificatif donné à une personne qui a été béatifiée"
>> http://fr.wikipedia.org/wiki/B%C3%A9atification
>>
>> cheers,
>> Martin
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
>
> ___
> 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] RFD pipeline sub tag substance

[John Willis]

Is there some decision on helping it all in one tag - 

Btw - isn't it states of matter? 
Substance:state= solid liquid gas (plasma?) multi

would a pneumatic garbage pipe be gas or solid, since it moves solid stuff (and 
implies pneumatic or such ?) 

Substance=gas
Substance:detailed:multiphase_gas
Substance:state=multi

Substance=water
Substance:detailed=grey_water
Substance:state=liquid

Substance=other
Substance=poodles
Substance:state=solid (pneumatic implied?)



>>> , 
> 
> Not so good. ;)
> substance=multi is about OK as a shorthand. Using multi -- instead of
> actual values -- may also imply you are not going to give further
> detailed tagging.
> substance=multiphase is really awkward.
> 

I think it would be substance:detailed:multiphase_gas for a particular item, 
not as a general description. 

Otherwise, it is multi for the state or matter... Right?

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